精益化运维的变革

精益化运维的变革

IT运维是在不断的进步的，从传统的被动式运维变为主动式运维几乎是所有的运维部门的共识，这些年来我们的IT运维从完全依靠人响应紧急故障的裸奔到基于网管软件的应急处置，一直都很被动。系统在建设阶段就遗留下来的大量问题得不到及时解决，系统总是三天两头出问题。于是主动式运维就变成了很多企业运维工作中的主要选择，而精益化运维就是主动运维的一种常见方式。7、8年前，我们给客户提出了精益化运维的思路，从他们的几百套数据库中选择二十来套核心数据库，做主动式运维。要做到精益化运维，我们不仅仅要在系统出现故障，宕机的时候及时响应，更多的是要在系统还没有出问题之前发现系统可能存在的隐患，做到消除隐患于其未发生时。

精益化运维确实能够起到立竿见影的效果，我说的那个客户在采用精益化运维之后，那二十多套数据库的运行质量有了质的提升。不论是系统的可用率还是运行性能都得到了极大的提高。不过其成本也是很高的，客户很不客气的和我说，系统运行的是稳定了，不过十来个人的投入有点太大了，今年我们运维的数据库实例要突破1000个，有多少个数据库能享受到精益化运维服务呢？

随着客户运维管理的数据库实例不断地增加，需要精益化运维地数据库也在增加，很快就突破了50个，这十来个人既要负责数据库运维、巡检、优化，又要承担一部分数据库变更、升级、新建等工作，工作压力不断增加。而客户在减员增效的要求下，也无法增加运维费用。于是很多DBA就受不了了，开始出现了人员离职等问题。运维团队的稳定性下降后，运维服务的质量也有所下降了。另外一方面，因为纳入精益化运维的数据库实例的增加，运维人员每天接到的报警短信数量终于超出了团队能够处理的数量。于是对运维报警短信的处理也变得不规范起来。有些重大问题的告警无法得到及时处置，最终导致系统故障的事情也多了起来。后来客户觉得精益化运维的项目的服务质量已经下降到了无法忍受的地步，这个项目就只能终止了。

通过这个项目，老白明白了一个道理，就是完全依靠人以及传统的运维自动化工具，是没办法做到真正的精益化运维的，因为绝大多数企业是无法承担精益化运维所需的成本的。一旦资金不足，人力资源出现不足，精益化运维就会变成一个美好的愿望了。只有依靠具有强大分析能力的自动化运维工具，才能在现时代实现真正的精益化运维。于是2017年开始我们开始基于这个想法，开始了D-SMART的研发工作。2019年的10月，在我们的一个用户那里，开展了一次基于D-SMART的精益化运维工作。对于客户的20多个数据库系统，开展为期一个月的隐患排查工作。在这一个月之内，这个DBA依托自动化工具，通过自动化巡检报告、运维经验告警等，对这20多套数据库的300多个告警进行了分析，发现了其中143个较为重要的运维风险与性能问题，其中107个问题在一个月内得到了整改解决，数据库系统的整体健康情况得到了较大的提升。

随后客户逐步把自己的核心数据库都加入到精益化运维之中，到2020年初，加入这项工作的数据库系统达到200多个实例，其中包括ORACLE、MYSQL、PostgreSQL、Mongodb等。而支撑这项工作的DBA仍然还是原来的那个人。那个DBA也没有感到特别大的压力，每个月发现问题的数量从刚开始扩大运维范围后的2、300个，经过几个月的稳定期后，每个月新发现问题的数量稳定在100以内，而且大多数是SQL的问题，也包含少量硬件故障引发的系统隐患。客户对这项工作的满意度一直没有下降，数据库的整体健康分也有了较大的提高。2021年春节后，我们撤回了这个DBA，派遣了一个不到3年工作经验的年轻人去接替这个老DBA。很快，这个新人在工具的帮助下，在那个老DBA的远程指导下，也很快把工作开展了起来。

从这个例子可以看出，随着企业数字化转型的深入，信息化系统越来越多，精益化运维仅仅依靠人力是无法持久的，萝卜快了不洗泥的道理永远都是真理。在运维工作量越来越大的今天，只有把深度运维工作完全数字化、自动化、智能化，才能让精益化运维工作能够持续开展起来。去年我去一个制造业企业和客户交流自动化运维的事情，他们的IT主管说，千万别和我谈报警，一方面随着智能化工厂的普及，我们这些年服务器的数量要扩大10倍，报警多了我们的人处理不过来；另外一方面，一旦系统真的出问题了，那就意味着企业的生产受影响，良品率下降，IT部门承担不起这个责任。

精益化运维需要深入的分析系统，找出隐藏较深的系统隐患，这些工作如果都依靠人工去做，就是把人累死，每个人也看不了几套系统。更何况现在企业运维所面临的数据库等IT基础设施环境十分复杂，一个企业里的数据库种类就可能有十多种，一个人水平再高也无法覆盖这么广的知识面。特别是在信创工作中引入的大量国产IT基础设施，想要找到专业的运维人员十分困难，如果不依靠自动化的手段肯定是不行的。

前几天一个客户说我们的系统里缺少一个SQL分析的工具，能不能帮他吗开发一下，把一个SQL在某个时间窗口中的CPU资源开销、逻辑读、物理读等的曲线显示出来，如果某条SQL的执行计划出现问题，就很容易被DBA看出来。我就问他，你看这个的目的是什么？他说一旦某个SQL出问题的时候，他能去分析。我说一个数据库中在跑的SQL语句成千上万，你如何确定就是某条SQL引起的？你们现在有近百套数据库在跑，核心业务的数据库就有三四十套，你需要安排多少人才能盯住那些SQL呢？他想了想，确实不需要这样。如果某条SQL的执行计划发生了改变，因而导致这条SQL的执行开销增加了，那么TOP SQL采集工具其实就可以第一时间捕获，并发出告警。利用TOP SQL预警功能能够直接告警不就行了，还需要人去看曲线来分辨吗？另外如果某个时间段某些问题导致了系统出现异常，那么直接产生一个异常场景告警，而分析工具直接能够帮你扫描出出现异常的时段数据库的哪些方面存在异常，是不是对运维人员更为友好呢？

比如上图就是针对SQL语句的告警，如果发现了某个SQL出现了多个执行计划，并且执行计划恶化了，直接发短信通知运维人员，这样的运维自动化是不是比那些花里胡哨，必须有人去看的运维自动化好呢？

在人力成本日益高涨，运维压力越来越大的时候，自动化运维的收益是巨大的。我们曾经在一个政企用户那边做过一个尝试，针对13个数据库，采用自动化巡检工具自动生成巡检报告，然后由DBA去读一下报告，把其中较为重要的系统隐患分析一下，找出一个重点问题清单。以往这个工作是由一个水平较高的DBA花1星期干的事情，换成这种基于智能化运维工具的方式，只需要一个人不到3个小时就完成了。而且完成的效果远远高于原来5天干出来的效果。是不是很恐怖，有些DBA在担心是不是会下岗了吧。不过DBA们也无需担心，一些可自动化的工作交给AIOPS去做了，DBA可以腾出手来，干一些更为有价值的事情，或者一个DBA可以依托这些工具，管理更多的数据库。DBA的主要工作花在价值不大的重复性劳动上，看似工作十分充实，实际上是很低效的，也是浪费有限的DBA资源。随着企业信息化规模的爆炸性增长，DBA只会成为更为稀缺的资源，DBA这个职业是不会被AI替代的。

精益化运维的发展，必须依赖AIOPS的加持，才能真正有效的开展起来。而对于企业数字化转型而言，精益化运维又是必不可少的。因此我可以断言，随着企业数字化转型的全面展开，AIOPS也将迎来新的春天。