SRE的运维自动化要怎么定方向？

做运维自动化这些年，有些思考，简单总结一下。

自动化的意义是为了提升效率，提高操作的稳定性，降低人工出错的概率，让大家在系统上可以统一制度、流程、规范，简化协作。所以大家都在投人力做自动化，从CI/CD、监控告警、服务治理到应急处理等等，方方面面、无所不在，抛开细节，如果你作为自动化1号位，应该怎么考虑自动化的方向呢？

首先是目标，自动化的北极星一定是一站式、场景化。

何为一站式？就是SRE和研发可以在一个平台上解决所有问题，不需要跳来跳去，操作尽可能优雅丝滑，说起来简单，但真的做到一站式是一个极大的挑战，只有一部分大厂舍得投入资源的在往这个方向收敛，行业整体都是在一个个独立系统阶段，比如需要解决什么问题了，到github找一个开源方案，搭建起来做做二开落地使用，或者让某个团队承接某个场景设计一个系统，系统间的协作、联动是比较弱的。

出现这个局面也很好理解，在资源有限的情况下，没有团队会去挑战大而全的东西，大都找到一个具体的领域做深做透，所以会有各种特定垂域比如监控告警、CI/CD、变更管控、安全堡垒机等系统，普通厂就是把这些五花八门的系统拼凑到一起，缝缝补补，因此也培养出了大量面向API接口编程的工程师。

何为场景化？一站式是场景化的终极形态，场景化是相对单点操作而言的，更多的是从运维的业务场景出发，将多个系统联动起来解决特定的问题，比如说服务下线，需要摘除域名、VIP、SNAT、ACL，单点操作是登陆每个系统搜索、走审批、删除，但场景化是把服务下线当成一个场景处理，形成联动的操作，场景化更多的是一种设计思想，要把各个系统的能力串起来，便捷的解决业务需求，避免技术自high。

自动化的建设原则，为工程师服务，有收有放。

自动化是向善的，为工程师服务是DevOps建设的核心原则。自动化并非为了取代工程师，而是为了更好地支持他们的工作，减轻重复性劳动，让他们有更多时间专注于更高层次的创新和决策。

有收有放，留有创新空间则强调在自动化过程中保持适度的灵活性。一方面，通过标准化流程和工具减少人为错误，提高效率；另一方面，也要为工程师留下足够的创新空间，鼓励他们探索新的技术、工具和方法，不断优化运维流程，掌握好平衡既能保证运维的稳定性和效率，又能激发团队的创造力和活力，弄清楚哪些是要收上来的哪些需要放下去的自动化就成功了一半。

在最佳实践上，自动化一定要以服务（应用）为中心开启建设，SRE的运维动作都是面向服务的，服务可以看成SRE管理的最小原子单元，是实体化部署在容器、部署系统的一个个job，系统从他开始自动化建设也要从他开始，它承上对应业务的各运维场景（CI/CD、容灾、容量、预案…..），启下对应CMDB的资源层，以服务为中心展开建设，在自动化建成后会形成最好的闭环，后附一张AiFault的分层架构示意图。