简单聊聊运维自动化中的自动化处置

简单聊聊运维自动化中的自动化处置

这些年关于自动化处置方面的技术发展的很快，DEVOPS、RPA CENTER等概念层出不穷。作为一个上了点年纪的老派IT人，我还是更喜欢自动化处置这个词。自动化处置是我这个年龄的IT人早年的梦想，二十多年前，老白和客户一起喝酒的时候经常会畅想如果IT系统的故障能够自愈多好。

实际上故障自愈只是自动化处置中的一个极小的分支，只要有足够的资源冗余，一些故障自愈还是不难实现的。最为典型的就是网络的故障自愈、服务器的HA高可用切换等。

互联网公司在自动化处置方面一直走在最前列，作为核心生产力的IT系统是互联网公司最为重要的资产，因此自动化处置已经从最为底层的硬件层到最上层的应用层都做了相当好的架构设计，因此可以完成十分复杂与高效的自动化处置，包括资源动态扩张与收缩、故障自愈、主备切换、在线优化、在线升级等工作。

相对于互联网公司，传统行业的信息化是从土坯砖头开始一点点堆砌起来的，很多楼层之间都不是按照统一设计规格建造的。再加上传统行业信息系统大多数是传统模式开发的，高内聚的集中式架构应用系统。因此在传统行业开展自动化处置是一件十分困难的事情，很多人甚至认为这是一个无法完成的任务。不过以老白的观点，自动化处置，对传统行业信息系统来说并不是不可能实现的事情，而是你有多大的需求和决心去做这件事。2016年，工商银行核心系统异地双活成功上线标志了一件事，那就是超大型的，关键性的信息系统做自动化切换是完全可行的。该系统的上线，使工商银行数据中心灾难切换从小时级缩短为15分钟，这是一个巨大的成功。

自动化切换只是自动化处置中的一个小方面，不过是最为实用的一个方面。实际上自动化处置可以涵盖信息系统建设运行中的所有领域。自动化部署、自动化配置优化、自动化运行优化、自动化启停切换、自动化数据管理、自动化容量管理等。

自动化部署现在已经是云上的标配了，无论是基础设施的自动化编排部署到应用的自动化发布、灰度发布，技术已经十分成熟。一台服务器在机房上架插电到变成云上的一个节点或者系统中的一台服务器，很可能就只差在管理平台上按一下按钮。甚至随着机器人的发展，今后很可能只需要把服务器运到机房门口的叉车平台上，剩下的事情全部可以交给自动化设施去做了。

自动化配置优化、自动化运行优化等相对要复杂一些，因为首先我们要确定哪些配置是不优化的，以及自动优化成什么。要实现这些，其实不需要高深的算法，而是对企业信息系统的准确的，定量的分析经验。信息系统的个性化特征是十分明显的，因此无论别人有多先进的经验，到了你这里仅仅可供参考而已。

无论如何，做自动化处置离不开几方面的配合，一个是基于自身系统的算法与经验，一个是保障自动化处置安全实施的基础框架，一个是相对冗余的IT资源。下面是一个自动化处置的实现概念图：

实际上，企业信息化中的自动化处置是需求驱动的，如果你使用人力手工的方式还能应付手头的工作，那么你在企业里是很难推进自动化处置工作的。只有当你不做自动化处置已经无法完成运维工作了，这时候才是你真正开展自动化处置工作的时机。

另外一点就是自动化处置的开展必须与企业的IT管理流程与考核机制挂钩，否则一切都是空中楼阁。前阵子和一个企业交流DEVOPS，他们说目前推进这项工作最大的问题是软件上线流程，在软件上线流程中，必须经过安全机构的仿真测试，而测试机构的测试环境和他们的K8S环境不兼容，他们打造的一体化工具链被生生的打断了。另外一个案例是和考核机制相关的，客户和老白探讨使用rac onenode资源池改造现有的中小型系统，节约硬件和许可证资源。最后谈到故障切换的时候，客户放弃了RAC ONENODE，因为单实例集群系统在故障切换时会有数秒钟的数据库连接中断，此时如果被他们的考核系统抓到，就会影响可用性考核指标。为了保指标而不敢做某些工作，这也是我们在传统行业中经常遇到的问题。

在运维工作中我们经常遇到这样尴尬的误区，我们如果想保证稳定运行，最好啥事也不做，维持现状虽然可能会面临更大的风险，不过至少当前是安全的。一切革新都是需要试错的，自动化处置也是如此，刚刚开始的时候，我们的算法，框架可能并不完善，可能出现一些小问题甚至惹出大麻烦，不过只要我们坚持，解决方案总是比问题多，这一点还是可以坚信的。