现在是一个不断创造新名词的时代，周日一个朋友和我讨论一个数字孪生的问题。他们要上一个数字孪生的项目，我听到数字孪生这几个字就对他肃然起敬，居然要干这么前沿的一个事情。我说你们真有钱，居然干得起数字孪生。他很奇怪，说没多少钱啊，也就一百来万的预算。当时我就十分奇怪了，居然有人可以用这么少的钱干一个数字孪生的项目。仔细一问，原来是建一套3D可视化的系统，把生产环境的一些数据传输过来，用3D进行展示。把3D可视化项目包装成数字孪生这种玩法，实际上是这些年我们浮躁的IT界常有的事情。运维自动化领域也是如此，各种新鲜的词汇不断出现，不过老白还是更愿意把这些还是称为运维自动化。
运维自动化工作包含部署自动化、监控自动化、告警自动化、系统优化、SLA保障、IT资产管理等工作领域，要想构建一套完整的运维自动化系统是要做十分大的投入的，很多中小型企业甚至没有经费去构建一个完整的CMDB。另外，运维自动化系统还需要和ITIL等管理流程平台贯通。二十年前，很多大型企业使用PATROL来构建一个运维监控系统，使用REMEDY来进行ITIL流程的管理。
这些年运维自动化也经历了数个阶段，经历了操作自动化、场景自动化、智能化运营等多个阶段。
最早期的运维自动化是操作自动化，把一些需要手工操作的工作固化下来，通过专用系统或者工具脚本实现自动化的执行。这个阶段主要解决一些手工操作效率较低，故障率较高，易误操作的问题。
第二个阶段的运维自动化是场景自动化，就是通过自动化手段实现一些简单或者复杂的运维场景的自动化工作，比如状态巡检、自动化日检、运行日报、故障溯源、主备系统切换、系统扩容等。与第一阶段不同的是，场景自动化不仅仅是提供一些自动化的工作脚本和工具，而是能够根据不同的环境与不同的场景，自动选择相关的分析策略，调用相关的知识点工具进行自动化的工作，完成自动化的处置。
运维自动化的第三个阶段是智能化运营，此阶段的运维自动化系统是以数据与算法为核心的，通过积累历史的运维数据，利用分析算法，能够根据数据进行分析和判断，并做出决策和执行。此阶段的运维自动化系统需要具有比较强大的分析策略，能够实现准确的自动化操作，不过并不是所有的工作都能够以智能分析获得自动化操作的结果，部分关键节点仍然需要进行人工判断。
其实第三阶段就是我们常说的AIOPS，不过因为数据与算法的积累问题，目前AIOPS能够覆盖的场景仍然有限，绝大多数运维自动化仍然停留在第二阶段上。自动运维或者智能运维实际上并不是运维自动化的终极目标，实际上运维自动化是服务于我们的运维业务的，就像运维工作是服务于企业的业务的一样。某个信息系统该如何进行自动化的运维，数据库故障时可以自动切换还是需要人工干预切换，这取决于我们的业务需求和SLA，并不取决于运维自动化系统的能力本身。
运维自动化的目的是尽可能用自动化的系统来替代人的工作，运营和维护的价值最终体现在业务中，而实现此目标的方法是运营服务化，如果用一个目前比较时髦的说法就是“运营即服务”。
IT部门在企业内部能够真正的实现运营服务化，IT部门必须成为一个利润中心，只有如此，在我们的大型企业中，运维自动化才能成为真正的刚需。这些年老白一直在企业内推广运维自动化工具与基于运维自动化工具的服务体系，不过接受这种模式的用户占比并不高。大家都在学习互联网公司的IT运维的技术与理念，但是我们的核心业务并不像互联网企业一样是以IT为核心，因此这种模仿最终只是一种东施效颦的模仿。因为信息系统运行的好坏，性能有没有问题并不是绝大多数领导比较关心的问题。缺乏自动化手段，大不了让弟兄们加加班，出了问题找不到根因，下回再出事的时候领导可能都已经忘了这次故障。系统资源浪费点也没关系，反正每年的IT预算都在增长。
运维自动化建设应该是基于具体的工作目标的，周五参加一个会的时候，客户的领导说了几句十分经典的话。我们建设运维自动化系统，总是基于一个十分全面的设计，然后再去慢慢实现，也许等我们把设计都实现的时候，信息系统已经变得面目全非了。我们应该从我们目前面临的问题入手，解决问题就行。这些年我们发生过哪些故障，总结了哪些经验教训，能不能先不考虑是不是用一些高大上的新技术还是用采用比较低级的比较传统的方法，把这些东西先变成自动化了，解决我们现在的一些关键问题呢？这一点老白是十分赞同的，唯有如此，才能做出真正有用的运维自动化工具，而不是做一些玩具让运维人员多了一些需要运维的系统。
