运维的自动化驾驶

白鳝的洞穴 2022-06-02

366

上周五子衿技术论坛的主题是数字化转型，下午的运维数字化转型分会场是我主持的，不少厂家、用户、高校都参加了这次活动，受疫情影响，下午分会场不能超过25人，不过最终进场的人员超过了30人。线上还有而是多人参与了分会场。

在上午的主会场上我分享了IT运维数字化转型的几个探索案例，其中也提到IT部门是不是会成为企业里最晚实现数字化转型的部门。这个观点得到了参加下午分会场讨论的朋友的广泛认同。大家一起分析了业务部门与IT部门在数字化方面的差异，现在的业务部门离开IT系统基本上就不能办理或者处理业务了，因此数字化程度是很高的，而现在IT部门很少有完整的管理系统，大部分工作都是离开运维专业的管理系统手工进行的。在数字化程度上，IT部门已经远远落后于其服务的业务部门了。

另外一个大家十分关注运维数字化转型中的数据问题，目前实际上IT部门对自己运维的环境的数据的掌握并不强。几年前我们在做“IT健康管理”方案的时候，很多客户的IT主管都对我们需要采集大量的系统运行指标数据感到十分不解。我拼命解释说，只有采集了充足的指标，才能构建出高质量的分析模型，才能更好的掌握系统的运行情况。不过大部分人都对我的说法不理解，觉得目前他们这样运维系统也没有什么大问题，他们也已经建立了网管监控系统，采集了一些指标，为什么我们不能把这些指标充分利用起来，用现有的指标去构建分析模型，非要再增加这么多指标呢？实际上每个人都有惯性，习惯了二十年前网管思路的运维人员有时候很难接受我们现在的自动化驾驶的理念的。

就像对于特斯拉这样的数字化的汽车，我们很习惯把它当成普通的车辆来驾驶，用传统的驾驶方式肯定也能开的不错。不过如果你只想用普通的驾驶方式去驾驶特斯拉的时候，可能花了不少冤枉钱了，因为马赛克在各种自动化辅助手段的支持上花了不少心思，这辆车的很多钱也花在了这方面。

如果把运维比作驾驶汽车也是如此，你可以采用传统的方式来运维你的IT系统，也可以尝试使用新的自动化驾驶的方式来进行运维。不过随着企业的IT系统越来越复杂，数量也越来越多，什么事情都要靠传统的手工模式来做已经变得不大可能了。运维自动化、运维智能化越来越成为企业运维部门关注的方向。

我们经历过以人为中心的手工运维阶段，可能现在大多数企业也还停留在这个阶段，不过随着企业数字化转型的不断深入，我们面临更为复杂的运维需求。

企业将面对更为复杂的IT环境，面临更昂贵的运维成本，业务部门对IT部门的运维要求也越来越高。如果我们还死守传统的以人为中心的手工运维模式，肯定是要出问题的。提高自动化、智能化的方式，把一些十分消耗人力资源的数据采集、分析、监控、巡检工作用高效的自动化作业替代，提高生产力，解放人力资源会成为未来企业IT运维中十分重要的一项工作。不过在这里我们需要的是真正自动化作业工具，而不是一些花架子工具。

很多人觉得只有自动化处置工具才是真正有效的工具，其他大多数都是花架子。这实际上也并不奇怪，因为在以前，确实很少存在真正有效的能够防患于未然或者能够完成根因定位的运维工具。不过现在自动化处置能够完成的事情还十分有限，大部分局限于系统的自动化部署。在自动化处置上要复杂的多，因为从自动化问题发现，到自动化处置策略产生，到自动化处置完成，再到自动化效果评估，是一套十分复杂而存在一定风险的闭环流程。哪怕很多标榜自动化处置的产品能够举出的比较有说服力的例子，不外乎自动空间扩容而已。

上面是我画的一张自动化处置的时序图，自动化处置过程分为多个阶段：

（1）通过大量的有效的数据采集进行自动化的分析，实现问题发现，比如通过IT健康管理的模型发现系统存在的缺陷；

（2）通过智能化诊断实现自动化的根因定位；

（3）评估缺陷可能产生的风险，并根据风险产生消缺方案，同时评估故障自动化消除的风险。想要做好这个并不容易，哪怕是空间扩容大家任务可以完美解决的自动化处置问题也是如此。以Oracle数据库的表空间容量管理为例，表空间使用率超过99%了必须扩容吗？不一定的，因为数据文件可能是自动扩展的。设置了自动扩展的数据文件，只需要监控ASM磁盘组的容量了吗？也不一定，因为普通8K数据文件自动扩展到32GB就无法再扩展了。只有把这些都分析清楚了，才能真正的发现容量风险。能够发现真正的风险就能做好自动处置了吗？如果我们要扩容ASM磁盘组，我们从哪里获得新的磁盘呢？事先准备好磁盘吗？如果都提前准备好了磁盘，为什么不马上加进去还要系统去冒风险自动化加入呢？这不是为了自动化而自动化吗？哪怕这种做法被认为是不错的自动化处置，从哪去分配磁盘呢？ASM磁盘组里最好每块盘的大小都是符合FAILGROUP的成员盘大小的，而且性能也最好接近，我们如何保证这些呢？

（4）对于风险可控的作业自动处置，当我们通过评估这个工作可以自动化执行，那么就会根据预案设置自动化执行作业，并把这个作业的工作内容推送给管理员；

（5）持续监控执行过程，并持续进行风险监控，一旦发现问题及时终止，并通知运维人员；

（6）执行完毕进行效果评估，并将评估结果通知运维人员；

（7）根据不同的自动化处置类别，在预定的时间内对执行效果进行持续监控，发现问题及时通知运维人员。

实际上汽车的自动化驾驶和运维的自动化驾驶一样精密，汽车的自动化驾驶是依赖于大量的视觉和距离传感器以及汽车自身运行的大量数据的，没有这些，自动驾驶的汽车就是杀人和自杀的利器。运维的自动化驾驶也是如此。在业务数字化的过程中，第一步和第二步永远是“业务的数字化描述”和“业务的数字化建模”，不能自动化描述某个业务的数字模型，就无法进行真正的进行自动化处置。

不幸的是，我们的大多数IT主管并不理解或者并不接受这个观点，他们总是希望看到他们想要看到的结果，而并不愿意接受达到这些结果所需要的成本。如果这个问题不改变，那么运维的自动化驾驶就只是一句口号了。

自动化运维

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

运维的自动化驾驶

评论