1.8 运维自动化依赖的团队模型
下面将从能力模型、驱动模型和技能模型三个角度来阐述运维团队和个人的能力要求，最后给出一个参考的组织结构。
1.8.1 团队的能力模型
具体的团队能力模型示意图如图1-15所示。
图1-15 团队能力模型
对于我带过的应用运维团队，我都会从如上三个方面对组员提出运维能力要求。
1）业务运维。因为对这块能力的要求越来越低，因此其在我们的考核体系中所占的比重也越来越低。日常的变更、扩容、故障定位、运维规划对人的能力要求都非常低，这些工作都能模式化且平台化，从而减少了对人的倚重。
2）运维研发。我希望每一个应用运维人员都有运维研发的能力，但这在现实中是不可能的。对于应用运维团队和运维部门来说，运维研发的配备必不可少。在应用运维团队的内部，可以让有研发能力的人迅速承担面向业务运维平台的建设，或者参与到部门的运维系统建设中，可以抽出50%的时间参与研发。运维研发能力是能够让团队价值迅速达成的有效保证，没有研发能力的运维不能成为一个好运维。
3）技术研究。运维是一个技术团队，需要通过技术来体现价值，当找到好的技术时就要想着如何将技术应用到业务上，为用户带来价值，比如说提升用户体验，减少成本等。
这个时候就会产生一个问题，应用运维团队内的人也会运维研发，同时又有专职的运维研发团队，那么他们的职责分工如何解决，在工作上是否会存在重复建设？我的回答是这样的：
首先，可以把运维研发初期定位在公共服务平台的研发上，比如说DNS、LVS、配置管理、监控系统、CMDB、数据分析平台等。
其次，运维研发还需要制定相应的运维研发规范，代码规范、UI规范、测试规范等，让所有参与运维研发的人统一遵守，包括应用运维研发的组员。
最后来说一下应用运维小组内的研发能力该如何发挥的问题。其实在很多运维团队中，运维都是跟随业务的，一则可以让应用运维研发人员开发面向业务的运维系统，因为他们最了解该业务的需求，能够实现自己想要的；另外一种更好的操作方式，是让应用运维小组内的研发人员抽出50%的时间参与到以运维研发牵头成立的虚拟研发小组中。一则可以进一步提高应用运维的研发水平；另外还可以提高运维研发对业务运维的理解，同时还能提高带队作战的能力。
那么，运维研发和应用运维的比例应该设置成多少比较合适？我个人认为3:1比较合适，大家也可以自检一下，自己的运维团队到底设置了多少运维研发人员？另外想要检测运维研发配备是否足够，可以周期性地看看运维团队取得的进步，特别是效率和质量等维度。
一个高性能的运维团队一定是以应用运维和运维研发为核心构建的！
1.8.2 团队的驱动模型
具体的团队驱动模型如图1-16所示。
图1-16 团队驱动模型
团队的驱动力不同，带来结果的就会完全不同。为什么很多运维人员都说自己很辛苦？这时你可以思考一下到底是什么在引导着你进行运维工作？传统的维护，往往都集中在第一阶段和第二阶段，而进入到高阶运维体系之后，我们需要迅速切换到价值驱动和用户驱动的维度上来。有了用户驱动和价值驱动，对运维的效率和质量就都会有更高的要求，对于外部驱动我们必须走自动化和平台这条道路。建议大家在平时的工作中加入质量、效率、成本等一些KPI要求，不要只局限于自己所做的事情，而是要关注自己所做的事情对产品和用户的影响。
1.8.3 团队的技能模型
BAT（百度、阿里、腾讯）很早就实施了职业通道体系，在运维侧细分了多个能力通道，比如说网络运维、业务运维、运维研发、DBA等。对于运维人员的成长也有明确的要求和衡量体系，在此我就不详细介绍了。
1.8.4 参考的运维团队组织结构
我们不一定要按照这个结构明确设置运维小组，但是运维的职能差不多就是这样。我还有另外一个建议，最好将公共服务研发团队和运维团队放在一个组织结构下，这样将会有利于公共化服务的推广，而公共化服务对运维效率的影响是最大的，如图1-17所示。
图1-17 运维团队组织结构
至此，自动化平台的深度解码已经完成。本章从多个层面带领大家了解运维自动化，其实还是希望能给大家带来一点借鉴意义。大胆地往前走吧，一切都有可能，唯独那些实现不了的，都是我们人的问题，无它。
