第1章
自动化运维之深度解码
作者简介
王津银，2005年硕士毕业，参与电信BOSS系统研发两年。而后于2007年进入腾讯公司接触运维，经历服务器从百到万的运维历程，先后在YY和UC参与不同业务形态的运维，期间带过前端运维、数据存储运维、YY语音、游戏运维、运维研发等多种运维团队，对运维有着全面的理解。极力倡导互联网价值的运维理念，即面向用户的价值是由自动化平台来交付和传递，同时由数据化来提炼和衡量的。“精益运维”理论的创始人。个人微信公众号“互联网运维杂谈”（waynewang_ops），粉丝2.5万人，现创办优维科技公司，旨在缩短企业到达互联网运维的路径。
自动化运维是一个人让人兴奋且容易失控的话题！兴奋是因为我想做一次尝试，把它的全貌和细节说清楚；容易失控是因为涉及点太多，一则怕遗漏，二则怕顾此失彼。带着这份复杂的心情，我们来一次自动化运维的解析之旅吧。说实话，一个运维团队的运维能力究竟如何，其实看一个自动化管理系统便可得知！
1.1 概述
作为开篇，首先让我们来熟悉一下运维全平台的规划体系吧，如图1-1所示。
很多人看到这样一个架构图，可能会纳闷，难道对于一个小型企业来说，也要实施如此复杂的运维自动化体系吗？其实，对于不同规模的企业来说，对运维自动化的诉求的确是不同的。对于大规模企业，如BAT，这些能力基本上都是必不可少的；而对于小型互联网企业，比如
图1-1 运维全平台规划体系
说App开发公司，则核心的自动化诉求可能更多的是配置管理工具，比如说Puppet、SaltStack或Jenkins+Rsync等。
我们不禁要问，有什么样的准则可以让我们作为依据来判断何时该如何导入自动化？应该导入自动化的哪些部分？当你需要持续、频繁地进行一些事情时，此时就需要引入自动化，比如说版本发布，如果这个时候你感觉到很痛苦，那么此时就需要引入自动化了。关于应该导入自动化的哪些部分，我个人的经验是根据角色去梳理他的工作现状（持续、频繁的工作），然后引入自动化的能力，再根据角色人数的多与少来确定事情的优先级，比如说系统管理和业务发布，很明显业务发布的优先级更高，因为它的自动化所带来的人力解放的收益更大。当然还有一种更理想的情况，那就是根据整体业务交付流来构建，以它的全流程自动化为目标，此时引入的是该交付链上所有的自动化能力，当然对于很多企业来说，这种自动化实现的代价很高，而得到的收益却很小。
