D. Google SRE 管理

D. Google SRE 管理
    培训SRE（28）
    管理中断性任务（29）
        运维内容
            紧急警报
            工单
            其他持续性运维活动
        解决中断性任务的措施：轮值 on-call
        制定策略前提
            中断任务的SLO，即预期的响应时间
            排队的中断性任务有多少
            中断性任务的严重程度
            中断性任务的发生频率
            可以处理某种中断性任务的人有多少
    从运维过载中恢复（30）
        第一阶段：了解服务，了解上下文
            确定最大的压力来源
                知识代沟：在大型团队中，团队成员可能会过度专业化
                SRE直接参与开发的功能变得越来越重要
                对“未来的一件大事”的过度依赖：相信未来几个月的新解决方案能够解决该问题，而导致问题没有解决
                开发团队和SRE都视而不见的警报要么将细节查清除，要么调整报警规则让它们不再出现
                任何有客户投诉，并且缺乏一个正式的SLI/SLO/SLA的服务
                任何一个容量规划都是“增加更多的服务器”的服务：“我们的服务器昨天晚上内存不足了”容量规划必须有前瞻性
                事后总结的待办事项仅仅只有“回滚导致服务故障的变更”的服务需要了解故障发生的原因
                现有的SRE以“我们什么也不知道，开发者才明白”来应对的关键组件需要了解当前组件罢工的时候会造成什么样的后果以及需要多快解决
        第二阶段：分享背景知识
            书写一个好的事后总结作为示范
            将紧急时间按类型排序
                区分哪些时间可以自动化，而其他则是运维服务必须承担的工作
        第三阶段：主导改变
            从基础开始：确定SLO
            获取团队成员的帮助
                错误的方式
                    发现运维中的一个问题，想要找人直接修复它，容易给人造成“做改变是比“做改变是别人的事”的印象
                正确的方式
                    找到一个可以由某个团队成员完成的有价值的工作
                    清晰地解释这项工作是如何以一个永久的方式解决时候总结中出现的问题的。就算是一个健康的团队有时候也是比较短视的。
                    自己亲自作为代码更改和文档修订的评审者
                    在两到三个问题上重复这个过程
            解释你的逻辑推理过程：最好有数据支撑，比如说错误预算耗尽，无力支撑新的发布等等。
            提出引导性问题：切忌抱怨的语气
                正例
                    警报不处理，会对SLO有影响吗？
                    这个实例上线，为什么需要这么多的配置文件的更新/创建？
                反例
                    这些旧的，停滞的发布是什么情况？
                    为什么某个组件要做这么多的事情？
    跨团队沟通（31）
        核心：SRE和其他部门沟通的工具（或者说是API吧）
        案例
            沟通：生产会议
                议程，例如
                    即将到来的生产环境变化
                    性能指标
                    故障
                        紧急警报
                        非紧急警报事件
                    之前的待办事项
                出席人员
        SRE的内部协作
        团队构成
            技术负责人
            SRE经理
            项目经理
    SRE参与模式（32）