《SRE Google 运维解密》笔记

指导思想

介绍

Google 生产环境介绍

borg 是 k8s 的前身。

拥抱风险

服务质量

1. 现在的 SLO 没有更细粒度的划分到季度
   1. 如果划分到季度，需要用这个数据来限制什么或者进行什么活动？
2. L1S 链路的 SLA 的签署工作已经做了很多
   1. 对于 SLA 的达成情况数据没有看板现在除了出故障后用这个 SLA 甩锅感觉没有别的作用
   2. SLO 目标制定 -> SLO 目标细化(按季度/按周) -> SLA 签署 -> 爆炸半径控制 -> 线上流量放火验证

减少琐事

1. 琐事不仅仅代表“不喜欢的工作”，也不等于行政杂务或者“脏活累活”
   1. 流程开销是必须的（overhead）例如变更通报、项目会议、ko 材料（项目管理流程也是必须的）
   2. 一些脏活累活通常也具有长期价值（例如 check_status 接入/物理机下线/容量水位指标治理/监控报警治理）
   3. 这些都不是琐事

监控

自动化

1. 人不可靠，没人能像机器一样永远保持一致。
2. 现在工作中有哪些流程可以被自动化的？
   1. 重保后的缩容
      1. 自动记录发单和提单
      2. 人工审批后执行
   2. 限流触发后的自动化流程
      1. 拉群周知业务方
      2. 更改报警等级
      3. 自动化的按比例放大
3. 警惕自动化的权限过大！自动化过程添加合理检查
   1. 速率限制
   2. 权限检查
   3. 幂等性

发布工程

简单化

不是在不能添加更多的时候，而是没有什么可以去掉的时候，才能达到完美。

只有真空中的软件系统才是永远稳定的？我们的工作最终是在系统的灵活性和稳定性上维持平衡。

• 创造流程、工具、输出最佳实践
  • ex 代码膨胀检测
• 同时最小化对开发人员的影响

实际工作中有很多东西是没有条件进行。

具体实践

紧急事件响应

给出了三类故障的案例、做得好的地方、做得不好的地方以及从中学到的。

没有几个人天生就能很好的处理紧急情况，紧急情况下恰当处理需要平时不断进行实战训练。

紧急事故管理流程

处理中断性任务

流状态是一个软件工程行业内普遍接受、人尽皆知的理念。
在流状态里可以提升生产力，提升创造性甚至艺术创造性。
进入“心流”会产生出很强的创造力，这个人也会更满意自己的工作。
进入流状态需要时间进行上下文切换。
工作中应尽量减少中断性任务，比如 on-call 工程师应专注于 on-call 工作，其他项目进度应该把这个工程师进度排除在外。
工单：不要讲复杂分散到整个团队中去，人不是机器，这样做只会干扰员工，降低工作效率。