1.5 运维自动化的方法论
1.?全局驱动
无论是全部自动化管理平台的规划，还是某个平台的规划，都希望大家能够找到一个全局的立足点。比如说我们当时成立持续部署服务平台的时候，大家把全局的目标对齐于提高产品交付的速度和质量，开发、测试、运维很快就达成共识了。目前这个平台建设完成之后，运维已经从发布变更流程中彻底退出了，真正实现了让运维变成审核者。
2.?分而治之
从上面的几个维度中可以看到有很多系统，如果每个系统都要建设的话，那么周期和难度都将很大。所以需要分而治之，特别是线上架构组件的管理系统，更需要随着组件的交付一并交付运维管理能力，比如面向组件的自动化管理能力、运维的监控能力、运维的数据分析能力等。之前我也表达过类似的观点，所有只交付组件，不交付管理能力的研发都是耍流氓。因为从运维的角度来说，这样低价值的交付产品越多，越会导致运维不堪重负。而如果让运维从头去构建这个管理，则他们需要花费很多的时间去了解，从而导致系统建设周期拉长。举个例子，比如说某个分布式cache服务，做得不好的，是通过读取日志然后对其进行监控；做得好的，是给你开启一个管理端口，让你从端口中读取状态信息。这就大大降低了系统的复杂度（不用进行日志采集和处理组件了）。
分而治之，其实就是让不同的团队做不同的事情，不要将所有事情全部压给运维；其次不同的时期建设不同的系统，不要在同一时刻做很多系统，从而避免战线过长。当然如果有很多运维研发人员的话，就另当别论了。
3.?自底向上
自底向上，其实是让大家找到一个更清晰更具体的系统建设目标来展开工作。从系统分解上，来让大家规避被一个庞大而模糊的目标带入歧途。如果一上来，我们就说要做一个全自动的运维管理系统，那样很容易就会让运维研发团队迷失方向。所以这里可以先设定全局和最终目标（全自动化），然后从底层逐步构建地基，做框架，最后再盖一个完整的房子，详见图1-1。
4.?边界清晰
边界有两个维度，一个是管理边界；一个是职能边界。
首先是管理边界，其是从Owner的角度出发的，谁产生服务，谁就是Owner，管理统一都是运维。比如研发提供了一个统一的分布式消息队列服务，那么Owner就是研发，他应该对可运维性负第一责任，不要让运维去承担这个服务的WebAdmin管理系统建设任务。
其次是职能边界，深层次的理解是组件的功能范围。对运维架构师的考验也就在这儿，比如说让LVS去承担业务异常的容灾和容错切换是不合适的；让DNS跨过LVS层，负责后端服务异常的自动容错处理也是不合适的。如果不把职能界定清楚，将会导致系统做很多无用功，这会增加系统建设的复杂度。
5.?插件化
插件化的思维无处不在，在面对纷繁复杂的管理对象时，我们进行抽象，提供管理模式，然后将具体的实现交给用户，这点在我们日常所见的运维系统中经常可以看到，比如说Nagios就是一种插件化的采集思路。对于配置管理来说，Puppet采用的也是这个思路。对于最上层的调度管理系统，可以让运维自己去编写执行器，特别是和业务紧密相关的，但最终运维整个控制权还是要交给平台。我的经验是，在应用服务层和架构服务层，不要引入插件化的管理方案，过多的插件化部署，会让生产环境的管理最终混乱不堪，甚至失控。所以提供类SSH界面的运维发布和部署平台，是没有任何运维价值的。
