关于运维智能化观点

最近好几个朋友和我聊传统金融行业中的运维智能化，如果用gartner创新曲线来映射我对智能化位置的定位，我觉得在传统金融行业中智能运维现在处于期望膨胀期与泡沫破裂低谷期之间（如下图），总体来说我对传统金融行业的运维智能化持保守态度（大概的思路与2年前的一个小结差不多，见《回归ITOA的思考》链接）。

以下摘三个观点：

一、

运维智能化当前的应用领域主要针对业务连续性的故障应急环节，大思路即更快的发现问题与恢复业务：

• 故障发现：主要与监控结合，比如动态基线，多指标监控等；
• 故障定位：故障树或调用链路定位，历史报警关联定位等；
• 趋势预测：机器或业务指标趋势预测，流水或日志数据异常情况预测等；

业务连续性是运维底线，的确值得利用技术手段为运维人员赋能，但是是否将这些问题都寄托于智能运维呢？则要考虑一下以下关于业务连续性保障的几个举措：

• 你所在运维团队的ECC现场或远程应急的协同机制是否己完善？
• 监控对故障的覆盖面怎么样？
• 监控报警后多久会有人介入处理？
• 故障应急过程中相关的人员是否同步知会到？
• 故障应急的人员在介入处理后是否能够快速应急恢复（注意，不是排查原因）？
• 故障应急的措施涉及的高可用应急的三把斧是否有效？
• 应急手册是否可用？是否有自动化手段支持？
• 故障未解决是否有上升机制？上升机制是否有决策团队？
• 故障应急后是否进行复盘？
• 复盘过程中是否对监管、自动化、协同机制是否作为专项分析？
• 分析后得到的问题是否得到有效跟进？
• 是否还有有二线跟进主动的运行分析？
• 主动的运行分析是否有数据支撑？
• 演练、架构评估、补丁升级等等是否有效落实？
• ……

如果上述问题未得到有效解决，我觉得应该先将精力放在上面的应急协同机制的闭环上。因为，在实际工作过程中，可能90%的生产故障，极有可能在ECC喊一下，基本的应急措施就差不多出来了，剩下的10%的疑难杂症，当前的智能化手段也未必能有效解决。

二、

从AIOps最早的意思看，AIOps原指基于算法的运维，与ITOA（IT运营分析）是类似的，并没有说智能两个字。从这个角度看，我觉得现在大家对AIOps，可以考虑保守的方式，从数据运营角度出发，先好好做做“监管控”的工具体系建设，标准化生产机器或应用侧的运行数据，提高CMDB、系统日志、运营日志、监控指标、监控报警、调用链数据（可以划为CMDB）、流程数据、安全日数据等运维数据质量。争取一下老板对于数据驱动的工作模式转型的支持力度，调研一下如何利用运维数据的运营分析支持关于主动运行分析，推动运维提前发现问题，提前解决问题，减少被动应急的工作占比。这些主动进行运营分析的场景，从目前看正是运维人员发挥经验价值沉淀的切入点，比智能化运维的黑盒子更加实在。

三、

从运维团队定位的发展看，我们可以考虑沿着“成本中心--》服务中心--》创新中心--》利润中心”演进。从这个角度看，大部分企业都在成本中心，虽然ITIL V3己快20年，V4也出来了，但是V3的服务中心的思路，又有多少运维组织落实了呢？更不要说创新中心、利润中心了。要走的路还挺长，事还挺多，不如好好补习一下运维体系化的东西，查漏补缺，将这些细节场景线上化，加强运维管理的精细化。在智能化方面，也许当你的团队做好数据标准化与主动性的运营分析后，运维智能化的创新曲线也过了泡沫低谷期，那时也就水道渠成了。