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

Posted 2021-06-28 韩旭051

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了笔记每一个开发都应该懂得故障处理相关的知识，希望对你有一定的参考价值。

文章目录

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

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

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

恢复系统的手段

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

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

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

以用户功能为索引的服务和资源的全视图
为各个服务指定关键指标一套运维流程和工具应急方案
有导航仪有章法就不会混乱
设置故障等级
1. 全站不可用
2. 功能不可用不可替代
3. 功能不可用可替代
4. 非功能故障
故障演练
见得多了驾轻就熟
灰度发布系统或 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 和测试中的问题和优化点。
软件架构和设计是否可以更好？
对于技术欠债或是相关的隐患问题是否被记录下来，是否有风险计划？
第四，优化团队能力。
如何提高团队的技术能力？
如何让团队有严谨的工程意识？

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

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

三条原则

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

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

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

文章目录

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

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

反躬自省 进行 故障复盘

技术方面 亚马逊COE

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