Oracle数据库上的自动化工程

昨天谈到故障自愈，写完文章后想起了几年前的一个项目。一个客户想在传统架构上做故障自愈和运维自动化工程。他们的应用基本上都部署在阿里云上，应用架构囊括了从传统集中式B/S/S架构到基于敏捷的微服务架构，种类繁多，不过核心系统的数据库Oracle为主。使用Oracle数据库的应用系统基本上就是前端一个F5，中间一组WEBLOGIC，后面一套Oracle RAC。受到一些互联网公司的忽悠，他们觉得必须上一样套运维自动化工程平台才能满足他们日益加速的数字化转型的需求，对我们那套仅仅是做监控、诊断、预警和巡检审计的D-SMART系统看不上眼了。

我们花了半个月时间梳理他们的需求，他们的自动化工程需求分为安装部署、配置优化、容量管理、数据管理、切换启停、运行优化这几个方面。通过和运维人员沟通需求，以及根据他们的现状，我们列出了35项可以实现的自动化工程项目。他们看了之后觉得很满意，认为项目一旦完成，可以大大提升他们目前的运维水平。实际上我们刚刚开始梳理的时候，他们提出了50多项自动化工程需求，其中多项直接被我们否决了。还有几项经过分析认为风险过大而被删除了。比如自动清理共享池碎片，自动刷出不合理执行计划等。

在这个自动化工程项目中，难点就是故障自愈。Oracle数据库是一个十分复杂的IT系统，故障自愈需要十分严格的保障措施才能完成。经过讨论，我们设计了一套工艺流程。利用D-SMART系统实现基础指标的采集，并利用故障模型发现可能存在的问题。随后使用D-SMART企业版中的自动化分析功能自动进行问题定位，一旦发现自动化工程中可以进行故障自愈的问题项，立即启动自动化处置流程。首先进行风险评估，当系统认为风险过高时，通知运维人员手工实