翻译自《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
-
文档随时要保证最新
-
安全交接每个组的职责
-
在发生故障的时候也是对现有员工进行培训的机会
其他思考
-
没有一份清单是详尽无遗的，这些只是其中的一部分从长期的在线运营生涯中学到的经验。
-
想想明天，下个月，明年 关于你需要在哪里运作你的服务和服务规模，因为一旦落后，解决技术债务是很困难的。
-
为成功而准备和设计—一个服务最危险的时间之一就是他看起来好像挺成功。
-
故障总会发生，最好的学习和提高的方法不是集中精力互相指责，但要共同寻找解决方案避免类似的情况再次发生。
