自动化体系在一个技术团队中尤其重要，他代表着效率和未来。在运维团队，我认为SRE自动化的终极目标就是建立一套DevOps体系，能够把所有的运维场景承载下来并全部自动化，全链路的提升SRE的工作效率、解放人力，为此在团队里我提出了自动化的北极星：能自动化的全部自动化。
解放人力不是把自己干掉，我认为自动化的本质是改变了运维团队的工作结构，比如原来需要铺在一线人肉处理的事情改为自动化，鼓励SRE多用工具思维解决业务问题，久而久之团队在研发的投入就会越来越多，人肉做的事情就会越来越少或越来越快，通过工具管理业务，每个人能够管理的业务体量也会越来越大，人力的节省是必然的，当然工具还是需要SRE持续迭代升级的。SRE团队中还有一个必不可少的群体——运维架构师，运维架构师都是从一线磨炼出来的老司机，对运维工作极其熟悉，更偏向业务专家、解决方案专家和团队管理，在运维团队中起到扛大旗的角色，而运维架构师其中一块工作就是要作为产品经理指导参与到各个DevOps功能设计中，这样做出来的系统才会有用好用。
对运维团队的自动化体系建设我有很多心得，首先纯粹的运维剥夺其研发能力的团队我认为是不可取的，SRE用的工具只有SRE最懂做成什么样最好用，多了任何一层沟通都会降低效率、浪费人力，所以SRE担任工具的研发是最合适的，外包给任何一个团队都要出问题，而且SRE还有很多不通用的小工具，别的团队也不好做；其次一般大厂都有纯粹的运维开发（产研）团队，要沟通好哪些底层轮子、通用能力由专职的运维开发团队做，运维开发团队一般负责公司层面全局的通用系统。两个团队在能力上相互补充，目标也是一致的，并不是竞争关系，运维开发为SRE提供通用的基础能力，SRE也要承担起运维开发产品经理的角色，两者协作好会极大提升运维效率。
在运维团队自动化体系的构建上，要充分考虑到SRE全员参与、工具散小多的特点，让团队从低层次的重复建立中摆脱出来，不要每次都在底层平台上花费大量精力，搞一大堆web，最好每个同学直接能基于一个平台开发应用就好，好刀用在刀刃上，所以要解决的两个核心问题就是：共享共建、千人千面。
依托上面的思考，我展开设计了小米AIoT SRE团队的自动化体系，适用任何大厂的场景，用一张图形容：运维的效率从团队中来到团队中去，循环往复。
下面详细介绍一下这个体系。
1. 整体结构
整个体系设计分为4层，从技术到运营做了闭环，分别是轮子层、平台层、运维场景层、运营层，每一层各司其职，最终支撑实现共享共建、千人千面一站式运维的目标。
轮子层
轮子层是指运维垂直领域的通用能力，这一层面向的是单个主题的解决，讲究深度和系统的解决一类问题。
在大厂轮子层一般由专门的团队负责，比如说运维开发团队、安全团队、产研团队等，注意每个系统要为上层提供API调用，便于更上层通过多系统关联集成研发，设计解决更多运维场景的问题。
平台层
平台层就到AiFaut系统了，共享共建、千人千面的目标就在这一层实现。平台层提供统一的基础平台，解决权限、研发规范等基础能力，并将轮子层各系统的API封装好，共享给上层的开发者使用，然后将系统功能插件化，对外提供AiFault插件中心的web界面。
共享共建是指团队内每个SRE都可以在插件中心注册开发插件，而且只专注功能本身的开发即可，不用花精力处理基础平台等其他事务。插件的开发也是相互独立解耦的，互不影响，插件开发完成上线后可以共享给团队所有SRE使用，相当于整个团队共建一个自动化平台，最后依托插件中心形成团队的工具群。
千人千面是指每个用户都可以自定义工作台，安装和卸载各自使用的插件。在考虑上还是以用户体验为出发点，不同SRE研发的插件不是每个自己都能用到，用不到的插件占用控制台空间并不友好，长期看工作台会信息爆炸，所在在设计上，以人为单位，可以在插件中心自由的安装和卸载插件，千人千面自定义工作台。
场景层
场景层以质量为目标，围绕运维质量环，从故障前、中、后全面质量管理的角度对运维工作进行拆解设计。比如故障前的巡检、变更、Oncall、自愈，故障中的发现、定位、预案，故障后的复盘、改进等。
场景层的设计，最底层以SMDB（Service Management Database）为支撑，SMDB将服务的元信息开放给所有上层插件共享使用，每个SRE可以基于这些共同的基础信息开发运维工具。
随着工具越来越多，就会形成一个工具群，每个SRE按自己的习惯做排列组合，就会形成自己的一套工具体系。上图展示了我们目前已经开发的插件，很多插件因其通用性，已开放到全集团业务使用。在插件的研发中我们注重精品插件的设计，即强调每个插件都要把对应场景做深做透，先在自己负责的业务做试点，如有通用性再开放到其他业务使用，自动化的场景是需要持续丰富迭代的，我们现在覆盖的场景还远远不够。
运营层
DevOps+技术运营我认为是SRE的最终归宿。随着IaaS、PaaS层越来越标准，结合公有云的使用，SRE的事情理论上会越来越规整，那么SRE的最终态一定是通过运营的方式、技术的手段牵头协同各部门来保证产品的SLA（服务质量），同时控制产品的成本。
所谓运营就是把有明确目标的事情持续做，比如说质量的终极目标是年可用性100%，但可能永远也达不到，但这个目标可以作为高牵引，从99到999到9999持续努力，通过各种措施不断的对质量进行持续运营。
顺着这个思路，运营的主题可以是变更、成本、技术、容量、效率等等，一般运营首先是建立指标，然后与DevOps平台和制度结合起来，使用组合拳持续往高目标前进。再换个视角，其实SRE是基于DevOps平台的工具、数据、看板结合流程制度，在日常工作中开展对各个运维主题的运营，DevOps平台成为了技术运营的一个基座。
2. 建设原则
建设的整体原则总结后16个字：大胆规划，小心求证，快速迭代，小步快跑。
自动化的的建设一定要敢想，想后马上行动，不能像做菜一样等着所有的材料都备齐了才下锅，最重要的是快速行动起来，有了最小雏形后小心求证、快速迭代、小步快跑。