本期分享主题是《Google SRE工作手册》读书分享，本期分享内容为琐事与自动化、On Call轮值与团队士气、SRE团队生命周期。
一、琐事与自动化
（1）什么是琐事？
1.1手动性：
• 删除日志文件
• 手动取数
• 手动倒换
1.2重复性：
• 目录空间耗尽，过一段时间就要修复
• 周期性报表
• 周期性巡检
1.3 可自动化
• 文档类型的预案
• 伪代码形式的操作指导
1.4 非战术性/被动性
• "磁盘己满"等低价值告警处理
• 分散高价值工程工作的注意力
1.5 没有持久价值
• 完成一项任务通常会给我们带来满足感、成就感,但从长远来看,这种重复的满足感并非是积极的。（抑制告警）
• 解决了这个问题,并不能防止它将来的复发
1.6 与服务规模同步增长
（2）琐事分类有哪些？
l 业务流程：工单、配置、开通
l 生产中断：告警
l 产品发布：发布、回滚、紧急补丁、手动配置
l 迁移：手动方式的大规模迁移
l 工程成本和容量规划
l 不透明架构的故障排查：黑盒、技术债务
图片来源于《Google SRE工作手册》
（3）潜在的收益有哪些？
• 随着时间的推移,伴随着工程项目的进展,其中一些工作还会减少未来的琐事。
• 提高团队士气 ,减少团队人员流失和透支的状况。
• 降低上下文切换的中断,从而提高团队的工作效率。
• 提高流程的清晰度和标准化。
• 提高团队成员的技术水平和职业发展 。
• 更少的培训时间。
• 减少人为错误导致的去机。
• 提高安全性。
• 更短的用户请求响应时间。
（4）琐事与自动化的管理策略
• 作为项目识别和度量
• 工程师撤出琐事系统，全局角度、从源头消灭
• 拒绝琐事密集型任务，故意拖延一次性处理
• 关注服务整体健康度而不是某一部分
• 逐步自动化
• 提供自助服务
• 获得管理层和同事支持
• 大力推广消减琐事
• 从高优先级的小处着手改善
• 增加一致性
• 评估自动化风险
• 形成组件和库，便于复用
• 使用开源和第三方工具
• 使用反馈进行改进
二、On Call轮值与团队士气
（1）控制告警压力
• 手机响个不停，不断收到告警，团队比较烦躁
• 来源：
n 生产环境的bug
n 自动告警
n 人工操作
（2）灵活安排On-call
• 长时间On-call令人精神疲惫
• 不要让一个人24小时On-call
• 公平合理的On-call
（3）提升团队动力
• 压力大，时间紧导致没有安全感，做决定全凭直觉
• 情景：以错误量设置告警，无关紧要的告警杂音
• 鼓舞士气，避免意志消沉
n 更多授权：可自行调整机制或代码
n 加强团队凝聚力：团建--》凝聚力、共情
三、SRE团队生命周期
（1）没有SRE的SRE实践
原则1：S R E需要制定面向后果的S L O
• 可靠性不是100%
• 设定合理的SLO
• 制定错误预算
• SLO可度量
（2）引入SRE角色
• 确定第一位SRE
• 安排第一位SRE（根据权限和挑战）
• 启动第一位SRE工程师
• 分布式SRE
（3）确定第一位SRE
• 有运维经验
• 软件工程经验
• 熟悉监控系统
• 生产自动化
• 了解系统架构
3.1 启动第一位SRE工程师
• 原则2：SRE必须有时间使明天变得比今天更好。
n 在运维职责和项目工作间保持健康的平衡
• 工作聚焦
• 进展不佳的现象
3.2 第一个SRE团队
• 原则3：SRE团队需要有能力调控工作负载。
（4）打造更多SRE团队
• 原因及拆分
• 团队设置
（5）多团队运作实践
• 角色交换
• SRE交换
• 培训
• 横向项目
• SRE流动性
• 出差
• 成立协调工程团队
• 卓越生产
• SRE预算和招聘
四、互动答疑（Q& A）
李佐辉，毕业于浙江大学信电系，高级工程师，15年通信网络运维经验，浙江移动SRE团队发起人，SRE专委会华东区域负责人，通信工程师IT开发转型推动者。
Q1:先前提到的琐事，也包括一些生产运维当中遇到的特别适合去做自动化的琐事，对此能不能举一两个例子，比如降本增效的实现，又或者可以一下子让大家觉得有很大的改善，对此，突破点会在什么地方？
A1:从我的经验上来看，我认为带团队刚开始的时候，要先从一些简单的事情入手。什么是简单的事情？一个就是报表的自动化，因为报表其实很简单，就是取数呈现，做这两个事情。它的频率很高，指标很多，但是经过报表相关工具的培训，员工很容易上手。第一步，我把所有的报表都自动化了。那么第二步我可能会涉及到一些巡检以及应急这些跟设备有关系的脚本，因为这个事情是我们的三方开发团队很难帮我们做的，我们的运维人员更懂这些事情，运维人员的核心竞争力就在这一块。第三步我们会做一些对外的自助服务，减少流程沟通的成本，把一些运维功能直接给前端的人。
Q2:未来有没有可能靠机器人去做一些值班？你对未来怎么看？如果说未来还需要人介入的话，原因是什么？能不能全部都自动化，或者说不要有人来做？
A2:目前的一个趋势是On-call 的人越来越少，大部分的事情都可以都交给机器去办，但是人做什么事情？人做一些判断，特别是一些跟业务相关的，影响比较大的决策和判断。比如说我要解决一个告警，但是我下的一个指令可能会影响用户业务，那到底做不做的这种判断来谁来做？谁来授权？这个目前还是没有办法给机器去做的，所以说我觉得后面的那个人要做的是，按照以他的经验和逻辑判断力来做一些处理和决策。
Q3:应对大项目的新SRE团队组建过程中，存在什么风险？对应的缓解措施有哪些？
A3:关于项目团队的风险，一个是由于一次承担了太多服务责任，导致将自身分散了太多。参与了项目，然后项目时间又太紧，承担了非常非常多的项目工作。第二个是过于内行，过于追求完美，把SLO定得非常的高，但是用户他并没有在这个SLO中获益，又导致了他的事儿非常多。第三个是他没有彻底地审视工作，这需要从用全局的眼光，从整一个项目系统，根据优先级来做事情。第四个是为了实现产品的里程碑，然后放弃SRE的原则和实践。产品的里程碑，一个叫新特性的上线；SLO的达成，是我们的项目里程碑，这会忽略了一些我的架构的调整。架构的调整如果不做，不根据业务的发展做架构的调整的话，到后面可能会形成技术债务。第五个是会与现有的团队产生冲突，导致分心，特别是根据我们的项目来建SRE，那我的SRE团队要去替代团队里面原来的我们的项目开发团队，或者是我们的运维团队的一部分。那原来的项目开发团队和原来的运维团队，他的责任以及权利会被拿过去，这可能会在几个团队之间形成墙，产生一些内耗。最后一个是当我的 SRE 团队组建介入的时候，并不具备必要的技能覆盖。原来的项目运行得好好的，突然SRE去介入了，如果他对项目并不了解，可能会对项目里面的技术并没有吃透。
那该如何缓解？首先SRE的参与要从一项重要的服务开始，就必须要轻装上阵，关注最高优先级的事，第二个是越早参与项目越好，最好在设计阶段，这可以解决我们对项目了解不足的问题，在设计阶段就介入，减少技术债务。第三个是侧重于定义SLO分析以及设计固有的可靠性，降低风险。必须要着眼于 SRE 的初衷，不要让自己的时间被那些新特性上线这种事情给占走了，第四个要致力于特定可靠性的功能以及现有运维平台的集成，其实就是少做事儿，让我的特定的功能进行一个归一化，然后被我们原有的平台去接走，这样的话就不用做一些额外的开发了。第五个是不要在第一天就承担运维的责任，首先我要审视我的项目以及我的运维，先不要去替换，或者说是参与到我的运维团队中去。先把一些先把我们的SLO一些我们的可靠性原则给定好，先做我们的SRE工作，然后逐渐的再去把一些改造过的一些运维的事儿那给接过来。第六个是我们要确立一些SRE接手前所必须满足的前提条件，这个叫SRE的交接规范，必须要有一个明确的交接规范，就是我的SRE要来接你的一些项目开发工作，或者说运维工作的时候，那你的项目开发工作，你的项目或者说你的运维必须要具备什么条件，那我才能接过来。那可能你要形成一些比较详细的文档，或者说你要形成一些培训的资料，那或者说你要在你的代码之间，代码中间写一些跟我的SRE平台对接的一些功能。那你满足这些要求的时候，那我才能把你的那个这事那给接过来。倒数第二个是如果项目涉及迁移，这个团队应该对当前和将来的环境有深入的了解，这个要求SRE发展的眼光看问题，将来是怎么样的？我是不是要预留接口？我是不是要对我的架构进行一些额外的改造？这个是要求我们以发展的眼光看问题。最后一个是要将新员工维持在团队总人数的1/3以下，这个是我以前没有想到的。这个是谷歌对团队的要求，就是新员工必须要在1/3以下，如果有一些培训，如果有一些On-call的，这么一些应急的工作，不会少人，不会缺人。我也不知道它1/3怎么算出来的，应该是一个经验值。
Q4：SRE团队建设大概分几个阶段？
A4: 随着SRE的人员增多，那渐渐地会形成一个SRE的团队，组建SRE团队的时候会用到我们的原则三。SRE团队需要有能力来调控它自身的工作负载。团队建设阶段分为 4 个时期，是组建期、激荡期、规范期和执行期。其中组建期有三种形式，一种形式是作为一个重大项目的一部分，组建一个新的团队。第二个形式是成立一个横向的SRE团队，这个时候一个小的SRE团队会横向的给多个项目团队提供咨询，那以项目的形式，单独的拆分到各个小的项目组去。第三种是转型一个现有的团队，是我们大部分公司做的那样，我们真正移动现在也是这么做的，就是把我们的运维团队转型成SRE团队。那这种情况有一个问题，就是很容易在没有SRE实践以及应用到SRE原则的情况下，只是简单地把运维团队命名成SRE了，要避免这个事情的发生。
Q5：如何对遗留黑盒系统进行SRE？
A5:谷歌讲了一个什么原则？黑盒系统是什么东西？就是 SRE 接手之前这个东西已经没有人开发了，只是处在维护过程中，没有新的需求开发了。那这个时候那个可能慢慢的这个东西就退出历史舞台了。那SRE是怎么介入的？一个是搞一个东西把它包起来， API 对接API，或者说是一个服务对接服务，不去动它。第二个就是如果它非常重要，那SRE介入了以后会对它进行拆分重构或者重新开发。第三个就是如果是个黑盒系统，逐渐地开发一个新的东西，那就不去用它。现在的谷歌是这么做的。
Q6: 一个SRE团队拆分后，原先团队的职责如何拆？
A6: 执行期之后，我们会有一个过程，我们会打造更好更多的 SRE 团队。我们打造更多的 SRE团队有三个原因。首先是服务更加复杂了；第二个是我的第一个团队，SRE效果还不错，那我们其他的项目是不是要建更多的SRE团队进行推广？第三个是我为了服务的安全考虑，或者说是为了On-call的值班时间考虑，我会有地域的分离，比如说我在北京有一个中心，然后我在纽约有一个中心，那我同一个事或者说同一个项目，那部署在两个中心，那我可能会有两个运维团队，就需要分布在这两个中心上去。
那该如何拆分？首先是按照服务复杂度拆分，这里有三种拆分的情景。第一个是按架构拆分，按前端，后端，数据库以及业务系统，还有就是按云平台和业务 APP的架构进行拆分SRE团队的现象。第二个是按语言拆分，那可能是写Java的一个团队，写 Python的一个团队，写底层C++的一个团队。第三个是按地域拆分，比如北京一个团队，纽约一个团队，洛杉矶一个团队，硅谷一个团队，也可以按这种拆分。第二个是因为SRE推广所以需要拆分团队的，有几个方面需要注意，首先是优先考虑可靠性，对财务和口碑方面影响很高的服务，要为这些服务进行拆分，专门搞一个团队去服务于这些比较重要的服务。那第二个是需要定义为了使产品能正常运行与生产环境所需要的最小存活服务集合。我的业务量大了以后，我拆分团队让这些团队去干嘛呢？这些最小存货服务集合是最重要的，所以需要我拆分团队。第三个是仅仅因为一个服务不可靠，是不可以简单地认为这是一个SRE的优先事项，这是一个原则。服务不可靠并不意味着它是优先级高，它可能是一个边缘服务，并不影响全局。
之后是地理隔离，地理隔离的拆分的几个原则，一个是为了服务可靠性，我有两个中心，一个中心挂了，可能还有另外一个，那个中心在为了服务的可靠性需要拆分，那我两个中心各有一个团队。那第二个是轮值压力，比如说我的一个团队在北京，他需要 227* 24 小时值班，太辛苦了。那我在纽约我再设置一个团队，各个团队都 12 小时，我北京 12 个小时白天，我的纽约也 12 个小时白天，是吧？那他们就可以不用值夜班，那这样子的话就加起来就 24 小时，那我可以减轻一下轮值的压力。第三个是招聘和留住人才，那我轮值压力降低了，服务的可靠性也降低了，还能让人才直接待在他喜欢的地方，这样子更容易招聘了，能留住人才。第四个是我可以提升我生产的成熟度。当我有多个团队的时候，因为我的团队之间要进行一些交流，那这个时候我的项目会形成更多的规范性的文档，可以显著地提高我的成熟度。比如我的a团队开发的东西要移交给b团队，因为他们其实是一个整个项目团队，a的事情b也要做，他们甚至是等价，a做的事情怎么移交给b？那就要形成一个文档，内部的API，可能要一些规范的格式，或者说要形成一个规范，那通过这些的文档以及内部的规范，可以提升整个产品的成熟度。
视频回看地址：
1、扫码B站二维码
2、关注微信视频号“SRE专委会 ”
