【笔记】每一个开发都应该懂得故障处理

文章目录

• • • 眼疾手快 悬崖勒马 故障发生时 做紧急处理
    • 居安思危 未雨绸缪 做故障前的准备
    • 反躬自省 进行 故障复盘
    • • 技术方面 亚马逊COE
      • 管理方面 阿里故障责任人机制
    • 故障整改方法
    • • 提出问题的逻辑
    • 识微见几 药到病除 根除问题的本质
    • 相关链接

眼疾手快 悬崖勒马 故障发生时 做紧急处理

亚马逊能够快速定位故障源，被影响的团队做处理 控制故障的范围不被扩散

出现故障时，最重要的不是 debug 故障，而是尽可能地减少故障的影响范围， 并尽可能快地修复问题。

恢复系统的手段

• 重启限流：解决可用性问题
• 回滚：解决新代码 BUG
• 降级：停止服务故障公告 不把事态扩大
• 紧急更新：需要有自动化系统 进行 自动化测试 自动化发布

运维团队通常只能处理一些基础设施方面的问题，或是非功能性的问题。对于一些功能性的问题，运维团队是完全 没有能力处理的，只能通过相应的联系人，把相关的开发人员叫到线上来看。

居安思危 未雨绸缪 做故障前的准备

• 以用户功能为索引的服务和资源的全视图 为各个服务指定关键指标 一套运维流程和工具 应急方案 有导航仪 有章法 就不会混乱
• 设置故障等级
  1. 全站不可用
  2. 功能不可用 不可替代
  3. 功能不可用 可替代
  4. 非功能故障
• 故障演练 见得多了 驾轻就熟
• 灰度发布系统 或 A/B 测试

反躬自省 进行 故障复盘

解决一个故障可以通过 技术和管理两个方面入手

技术方面 亚马逊COE

亚马逊会编写 COE（Correction of Errors）文档

• 故障处理过程 log
• 故障原因分析
• Ask 5 Whys 至少问五个为什么
• 整改计划：举一反三 根本上解决所有问题

管理方面 阿里故障责任人机制

• 阿里会将向上操作改成两个人完成 一人操作一人检查 增加审批环节
• 阿里会 编写一个新的系统 监控原来不好的系统
• 阿里也会 通过灰度发布减少故障

不认同 阿里 惩罚故障责任人 的机制

• 做的越多错的越多 只会让人更保守
• 惩罚责任人对 解决故障没有帮助

故障整改方法

慢 SQL 的故障复盘

1. 为什么从故障发生到系统报警花了 27 分钟？为什么只发邮件，没有短信？
2. 为什么花了 15 分钟，开发的同学才知道是慢 SQL 问题？
3. 为什么监控系统没有监测到 Nginx 499 错误，以及 Nginx 的 upstream_response_time 和 request_time？
4. 为什么在一开始按 DDoS 处理？
5. 为什么要重启数据库？
6. 为什么这个故障之前没有发生？因为以前没有上首页，最近上的。
7. 为什么上首页时没有做性能测试？
8. 为什么使用这个高危的 SQL 语句？
9. 上线过程中为什么没有 DBA 评审？

提出问题的逻辑

第一，优化故障获知和故障定位的时间。

• 从故障发生到我们知道的时间是否可以优化得更短？
• 定位故障的时间是否可以更短？
• 有哪些地方可以做到自动化？

第二，优化故障的处理方式。

• 故障处理时的判断和章法是否科学，是否正确？
• 故障处理时的信息是否全透明？
• 故障处理时人员是否安排得当？ 第三，优化开发过程中的问题。
• Code Review 和测试中的问题和优化点。
• 软件架构和设计是否可以更好？
• 对于技术欠债或是相关的隐患问题是否被记录下来，是否有风险计划？ 第四，优化团队能力。
• 如何提高团队的技术能力？
• 如何让团队有严谨的工程意识？

识微见几 药到病除 根除问题的本质

技术问题 隐藏着工程能力的问题 工程能力的问题背后是 公司管理的问题 公司管理问题 隐藏着 公司文化 创始人的问题

三条原则

1. 举一反三解决当下故障。 赢得更多时间
2. 简化负责不合理的技术架构、流程、组织 无法在复杂环境解决根本的问题
3. 全面改善优化系统 组织 根本上 改善调整整体结构

要想本质解决问题 就需要 大扫除 但要想做到简化 非常难 在烂摊子中解决问题 几乎不可能

相关链接

笔记源于课程 左耳听风 :故障处理最佳实践：应对故障 和 18 | 故障处理最佳实践：故障改进 2017-11-28 陈皓

在这里插入图片描述