昨天谈到故障自愈，写完文章后想起了几年前的一个项目。一个客户想在传统架构上做故障自愈和运维自动化工程。他们的应用基本上都部署在阿里云上，应用架构囊括了从传统集中式B/S/S架构到基于敏捷的微服务架构，种类繁多，不过核心系统的数据库Oracle为主。使用Oracle数据库的应用系统基本上就是前端一个F5，中间一组WEBLOGIC，后面一套Oracle RAC。受到一些互联网公司的忽悠，他们觉得必须上一样套运维自动化工程平台才能满足他们日益加速的数字化转型的需求，对我们那套仅仅是做监控、诊断、预警和巡检审计的D-SMART系统看不上眼了。
我们花了半个月时间梳理他们的需求，他们的自动化工程需求分为安装部署、配置优化、容量管理、数据管理、切换启停、运行优化这几个方面。通过和运维人员沟通需求，以及根据他们的现状，我们列出了35项可以实现的自动化工程项目。他们看了之后觉得很满意，认为项目一旦完成，可以大大提升他们目前的运维水平。实际上我们刚刚开始梳理的时候，他们提出了50多项自动化工程需求，其中多项直接被我们否决了。还有几项经过分析认为风险过大而被删除了。比如自动清理共享池碎片，自动刷出不合理执行计划等。
在这个自动化工程项目中，难点就是故障自愈。Oracle数据库是一个十分复杂的IT系统，故障自愈需要十分严格的保障措施才能完成。经过讨论，我们设计了一套工艺流程。利用D-SMART系统实现基础指标的采集，并利用故障模型发现可能存在的问题。随后使用D-SMART企业版中的自动化分析功能自动进行问题定位，一旦发现自动化工程中可以进行故障自愈的问题项，立即启动自动化处置流程。首先进行风险评估，当系统认为风险过高时，通知运维人员手工实施，否则启动自动执行流程，并将已经启动故障自愈的消息推送到告警平台，让运维人员给予关注。同时启动独立的进程对自动化处置的过程以及结果进行监控。一旦发现问题，立即启动应急处置预案，并通知运维人员发生一级事件，需要人员介入处置。
监督进程在发现自动化处置已经完成后，对执行效果与预期目标之间做评估，确保所有的目标都已经正确达成。如果发现执行效果与预期目标不符，根据自动化处置的风险等级发出响应的告警，推送到告警台，通知人工核查。
当自动化处置工作完成后，部分自动化处置的影响可能会在后续陆续出现(比如表分析，索引重建等)，因此本次自动化处置执行完成后，还需要创建一个事后监督任务，在事后的一段时间内，或者事后的某些特定日期、时间段进行事后监控(比如优化一个与月结相关的参数与索引，其效果需要下次月结时才能体现出来)。
在每天、每周、每月还需要对自动化工程平台所有的自动化处置工作做一个汇总报告，并根据故障自愈的情况进行分析，为运维团队提出集中优化建议等。如果某个系统频繁出现主备切换，那么就要分析更深层的原因，进行及时消缺。如果某个系统经常引发杀会话的操作，那么要分析应用是否存在问题引起了这个问题。
经过分析，大家一致认为这个自动化工程平台需要两百万以上的建设费用，再加上疫情管控日益严格，后续这个项目就没有实施下去了。而随着这两年信创的日益深入，在Oracle数据库上投资变得越来越不可能，于是这个方案也就被放进了我的文件夹里。
昨天不知道什么原因写了一篇关于故障自愈的文章，很巧的是，下午和一个客户做智能化运维交流的时候，有人也提出了Oracle数据库如何做故障自愈这个问题，晚上就想到了3年前的这个方案，于是今天早上就把它写出来和大家分享一下。做一个自动化工程平台实际上并不是把一些自动化脚本整理好，做个工具就可以了。运维生产安全日益被企业所重视的今天，不管是工具化、自动化还是智能化，运维的本质安全是最为关键的。哪怕是人工操作，还要做大量的复核，检查工作，更不要说是故障自愈了。如果蛮干，故障自愈就会变成故障自生了。