一个系统工程师的 14 条建议

翻译自《Confessions of a Systems Engineer：Learning from 20+ Years of Failures》作者是 David Argent（Amazon）在 SRECon 的演讲

14 条建议

• 没有绝对安全的变更

• 做变更时要控制好变更影响面

• 精准监控，完整度量

• 自动降级

• 预测故障，并使用已定义的降级服务模式进行准备

• 在发布事前，事中，事后使用发布门禁

• 设计满足 SLA，并快速缓解故障

• 定期锻炼流程和工具

• 使用技术加强流程

• 在处理故障的时候要果断切流

• 运维工具也必须具有生产级别的质量

• 对输入要充分验证

• 充分熟悉你所负责的业务场景

• 细心交接工作

1. 没有绝对安全的变更

• 任何变更都是一个潜在的事故

• 进程变更

• 底层代码可能有 bug

• 依赖关系可以不守规矩

• 部署自动化可能会失败

• 人为失误

• 墨菲定律

• 代码不是唯一一个可以影响服务可用的因素

• 代码，配置，数据

• 以上任意一个都会杀死你的服务

• 注意配置中的跨环境污染

• 变更可能会作用于多个环境

• 不要总做测试类型的变更，特别是留下一些默认值

经验教训

• 对变更要谨慎，敬畏生产环境

• 代码，配置，数据以上任意一个都会杀死你的服务

2. 做变更控制好变更影响面

• 分阶段扩大灰度规模

• 从 subset 到单数据中心，到所有的数据中心

• 允许从宕机的数据中心快速切流

• 没有业务流量的话，数据中心回滚速度更快

• 积极验证

• 没有负面反馈不代表成功

• 完全死掉的系统可能不会有任何反馈

经验教训

• 降低风险是成功的变更管理的关键

• 最小化变更范围，慢慢扩大

• 在速度和效率，和风险上做权衡

• 没有负面反馈不代表可以继续变更

3. 精准的可观测性

• 在正常运行期间了解你的服务

• 不熟悉什么是正常的，也就无法理解什么是异常的

• 精准监控

• 为减少不必要的升级减少错误告警

• 直接升级到能缓解和解决问题的人

• 让告警提供足够的信息以指向潜在的问题方便快速定位问题

4. 自动降级

• 不是所有的失败都无法处理

• 建设一个可以针对大部分故障模式的自我诊断系统

• 积极修复失败和性能问题

• 要意识到你的依赖，并对他们的失败做出反应

• 自动化对依赖失败的响应

• 速度很关键

• 自动化响应，越快越好

• 在工程师响应之前自动化解决问题

5. 服务可降级

不完美 有经验的人往往胜过不存在的人

• 不可能永远提供服务，总会有依赖会失败

• 制定标准应急 SOP

• 不要指望在危机中临时想出解决办法

• 不要让自己处于超负荷工作

• 服务一些客户比不服务任何客户要好

• 要有手段能进行降低负载

• 不要依赖合作伙伴和客户去降低负载

• 合作伙伴和客户往往是服务可用性的敌人

• 面向失败设计

• 努力为客户提供有用的体验，即使是在失败的时候

经验教训

• 将服务降级模式直接设计到系统中

• 测试你的降级模式和使用它们的标准操作规程

6. 在事前，事中，事后设置发布门禁

• Good：在部署前测试

• Better：在部署后测试

• Best：在部署中测试

• 越早发现问题越好

• 在爆炸半径越小的时候主动回滚

发布门禁

• 测试和观测你的服务功能

• 准确度量用户体验

• 人肉测试往往是不够的

• 针对“金丝雀”和个别故障的具体监控

7. 设计满足 SLAs，并迅速缓解故障

注意你服务和依赖项的限制

• 当一个单数据中心只有 99.99%可用率的时候，很难设计一个 99.999%可用性的单数据中心程序

• 充分理解你的 SLA 协议

• 设计一个 5 个 9 的程序远比 3 个 9 的程序难的多

• 设计中可以做的比所有依赖项的加起来的 SLA 的和更好

• 缓存可以减少依赖项失败的影响

• 分布式冗余可以减少单 IDC 故障的影响

• 面向失败设计

• 针对已知故障模式的缓解措施不能破坏 SLA 需求

• 通常意味着有快速回滚选项可用

8. 定期锻炼 流程和工具

• 一个没有验证过的备份比没有备份更糟糕

• 没有容灾演练 == 没有自信

• 冷启动和热启动是不一样的

• 你能在流量来之前预热缓存吗?

• 可以通过限流让自己的应用正常启动嚒？

9. 用技术加强流程

• 是人就会犯错

• good：适当的流程会减少人们犯错

• great：适当的技术方案会更好

• 让正确的方式作为唯一的方案

• 假如系统只允许你走正确的方案，那人就不会犯错

• 允许采用 高风险的变更 去处理意料之外的情况

• 好的栅栏或许降低在处理故障的时间

• 平衡随机反应和应对风险的能力

10. 在处理故障的时候要果断切流

• 客人可能不会注意到的宕机总比客户注意到的宕机要好

• 慢的不好的体验 远比 没有体验好

• 服务部分客户 远比 没有服务客户好

• 当遇到平台不可用时要果断切流

• 高延迟或者丢包可以直接切流量

• 低服务质量会影响公司品牌和利润

• 对不可接受的服务标准有定义

• 服务质量和故障定义不是一个东西

经验教训

• 部分服务比没有服务好

• 最小化对用户的影响

• 提前决定对某些服务的全面服务是否比对所有服务的降级服务好，并相应地制定 SOP

11. 生产级的运维工具

• 你依赖的所有工具必须有生产级别的质量

• 故障从来不会按预期发生

• 没有人只想解决 99%的故障

• 超级管理员运维工具可以对生产服务产生巨大的影响

• 假如没有严格的测试覆盖率

• 假如没有频繁演练

12. 严格验证输入

• 不要相信任何人——任何数据都可能是坏的，尽管初衷是好的

• 所有与你沟通的服务都会犯错误

• 问题数据不是你的朋友，并且永远无法摆脱

• 每个人都是你服务质量的潜在敌人，特别是你自己

13. 充分熟悉你所负责的业务场景

• 这不仅仅只是零售（笔者是 Amazon 工程师）

• 了解你所服务的对象和他们的需求

• 了解哪些流量最重要并且为什么最重要

• 这会指导你当发生故障的时候如何处理

• 避免跨区域依赖以隔离故障域

14. 细心交接工作

• 经常为要做交接做工作计划

• 分散的知识是敌人

• 文档和演练你的 SOPs

• 发生故障的时候要用 SOPs

• 文档随时要保证最新

• 安全交接每个组的职责

• 在发生故障的时候也是对现有员工进行培训的机会

其他思考

• 没有一份清单是详尽无遗的，这些只是其中的一部分从长期的在线运营生涯中学到的经验。

• 想想明天，下个月，明年 关于你需要在哪里运作你的服务和服务规模，因为一旦落后，解决技术债务是很困难的。

• 为成功而准备和设计—一个服务最危险的时间之一就是他看起来好像挺成功。

• 故障总会发生，最好的学习和提高的方法不是集中精力互相指责，但要共同寻找解决方案避免类似的情况再次发生。