笔记每一个开发都应该懂得故障处理
Posted 韩旭051
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了笔记每一个开发都应该懂得故障处理相关的知识,希望对你有一定的参考价值。
文章目录
眼疾手快 悬崖勒马 故障发生时 做紧急处理
亚马逊能够快速定位故障源,被影响的团队做处理 控制故障的范围不被扩散
出现故障时,最重要的不是 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 陈皓
以上是关于笔记每一个开发都应该懂得故障处理的主要内容,如果未能解决你的问题,请参考以下文章