文章目录
- 眼疾手快 悬崖勒马 故障发生时 做紧急处理
- 居安思危 未雨绸缪 做故障前的准备
- 反躬自省 进行 故障复盘
- 技术方面 亚马逊COE
- 管理方面 阿里故障责任人机制
- 故障整改方法
- 提出问题的逻辑
- 识微见几 药到病除 根除问题的本质
- 相关链接
眼疾手快 悬崖勒马 故障发生时 做紧急处理
亚马逊能够快速定位故障源，被影响的团队做处理 控制故障的范围不被扩散
出现故障时，最重要的不是 debug 故障，而是尽可能地减少故障的影响范围，
并尽可能快地修复问题。
恢复系统的手段
- 重启限流：解决可用性问题
- 回滚：解决新代码 BUG
- 降级：停止服务故障公告 不把事态扩大
- 紧急更新：需要有自动化系统 进行 自动化测试 自动化发布
运维团队通常只能处理一些基础设施方面的问题，或是非功能性的问题。对于一些功能性的问题，运维团队是完全
没有能力处理的，只能通过相应的联系人，把相关的开发人员叫到线上来看。
居安思危 未雨绸缪 做故障前的准备
- 以用户功能为索引的服务和资源的全视图
为各个服务指定关键指标 一套运维流程和工具 应急方案
有导航仪 有章法 就不会混乱 - 设置故障等级
- 全站不可用
- 功能不可用 不可替代
- 功能不可用 可替代
- 非功能故障
故障演练
见得多了 驾轻就熟灰度发布系统 或 A/B 测试
反躬自省 进行 故障复盘
解决一个故障可以通过 技术和管理两个方面入手
技术方面 亚马逊COE
亚马逊会编写 COE（Correction
of Errors）文档
- 故障处理过程 log
- 故障原因分析
- Ask 5 Whys 至少问五个为什么
- 整改计划：举一反三 根本上解决所有问题
管理方面 阿里故障责任人机制
- 阿里会将向上操作改成两个人完成 一人操作一人检查 增加审批环节
- 阿里会 编写一个新的系统 监控原来不好的系统
- 阿里也会 通过灰度发布减少故障
不认同 阿里 惩罚故障责任人 的机制
- 做的越多错的越多 只会让人更保守
- 惩罚责任人对 解决故障没有帮助
故障整改方法
慢 SQL 的故障复盘
- 为什么从故障发生到系统报警花了 27 分钟？为什么只发邮件，没有短信？
- 为什么花了 15 分钟，开发的同学才知道是慢 SQL 问题？
- 为什么监控系统没有监测到 Nginx 499 错误，以及 Nginx 的
upstream_response_time 和 request_time？ - 为什么在一开始按 DDoS 处理？
- 为什么要重启数据库？
- 为什么这个故障之前没有发生？因为以前没有上首页，最近上的。
- 为什么上首页时没有做性能测试？
- 为什么使用这个高危的 SQL 语句？
- 上线过程中为什么没有 DBA 评审？
提出问题的逻辑
第一，优化故障获知和故障定位的时间。
- 从故障发生到我们知道的时间是否可以优化得更短？
- 定位故障的时间是否可以更短？
- 有哪些地方可以做到自动化？
第二，优化故障的处理方式。
- 故障处理时的判断和章法是否科学，是否正确？
- 故障处理时的信息是否全透明？
- 故障处理时人员是否安排得当？
第三，优化开发过程中的问题。 - Code Review 和测试中的问题和优化点。
- 软件架构和设计是否可以更好？
- 对于技术欠债或是相关的隐患问题是否被记录下来，是否有风险计划？
第四，优化团队能力。 - 如何提高团队的技术能力？
- 如何让团队有严谨的工程意识？
识微见几 药到病除 根除问题的本质
技术问题 隐藏着工程能力的问题
工程能力的问题背后是 公司管理的问题
公司管理问题 隐藏着 公司文化 创始人的问题
三条原则
- 举一反三解决当下故障。
赢得更多时间 - 简化负责不合理的技术架构、流程、组织
无法在复杂环境解决根本的问题 - 全面改善优化系统 组织
根本上 改善调整整体结构
要想本质解决问题 就需要 大扫除 但要想做到简化 非常难 在烂摊子中解决问题 几乎不可能
相关链接
笔记课程 左耳听风 :故障处理最佳实践：应对故障 和 18 | 故障处理最佳实践：故障改进
2017-11-28 陈皓
