=Start=
缘由：
最近在实际工作中有碰到一些看起来比较低级的问题，但是又实实在在的发生在自己或旁边的人身上。感觉还是总结、思考的不够，需要好好补充、提升一下。这里先从问题原因分析方法开始——「5 Whys分析法」。
正文：
参考解答：
5whys分析法
5whys分析法，又名why-why分析法，它是根本原因分析（Root Cause Analysis） 的一种具体方法，适用于去分析一些简单和难度适中的问题。简单的说，就是针对问题持续的问5个为什么(通常需要至少5个“为什么”，但5个why不是说一定就是5个，可能是1个，也可能是10都没有抓到根原)，通过这样一种分析思路，能很快找到问题深层次的根本原因以及工作流程上的漏洞，并据此再制定预防措施，防止问题重新出现或再次发生，大大降低解决问题的成本。
5whys分析法问题解决方法的基本步骤
步骤 1: 识别问题
在方法的第一步中，你开始了解一个可能大、模糊或复杂的问题。你掌握一些信息，但一定没有掌握详细事实。
问：我知道什么?
步骤 2: 澄清问题
方法中接下来的步骤是澄清问题。为得到更清楚的理解，问：
- 实际发生了什么？
- 应该发生什么？
步骤 3: 分解问题
在这一步，如果必要，将问题分解为小的、独立的元素。
- 关于这个问题我还知道什么？
- 还有其他子问题吗？
步骤 4: 查找原因要点 (PoC)
现在，焦点集中在查找问题原因的实际要点上。你需要追溯来了解第一手的原因要点。问：
- 我需要去哪里？
- 我需要看什么？
- 谁可能掌握有关问题的信息？
步骤5: 把握问题的倾向
要把握问题的倾向，问：
- 谁？
- 哪个？
- 什么时间？
- 多少频次？
- 多大量？
在问为什么之前，问这些问题是很重要的。
步骤 6: 识别并确认异常现象的直接原因。
如果原因是可见的，验证它。如果原因是不可见的，考虑潜在原因并核实最可能的原因。依据事实确认直接原因。问：
- 这个问题为什么发生？
- 我能看见问题的直接原因吗？
- 如果不能，我怀疑什么是潜在原因呢？
- 我怎么核实最可能的潜在原因呢？
- 我怎么确认直接原因？
步骤 7: 使用“5个为什么”调查方法来建立一个通向根本原因的原因/效果关系链。
问：
- 处理直接原因会防止再发生吗？
- 如果不能，我能发现下一级原因吗？
- 如果不能，我怀疑什么是下一级原因呢？
- 我怎么才能核实和确认下一级有原因呢？
- 处理这一级原因会防止再发生吗？
如果不能，继续问“为什么”直到找到根本原因。
在必须处理以防止再发生的原因处停止，问：
- 我已经找到问题的根本原因了吗？
- 我能通过处理这个原因来防止再发生吗？
- 这个原因能通过以事实为依据的原因/效果关系链与问题联系起来吗？
- 这个链通过了“因此”检验了吗？
- 如果我再问“为什么”会进入另一个问题吗？
确认你已经使用“５个为什么”调查方法来回答这些问题。
- 为什么我们有了这个问题？
- 为什么问题会到达顾客处？
- 为什么我们的系统允许问题发生？
步骤 8: 采取明确的措施来处理问题
使用临时措施来去处异常现象直到根本原因能够被处理掉。问：
- 临时措施会遏止问题直到永久解决措施能被实施吗？
实施纠正措施来处理根本原因以防止再发生。问：
- 纠正措施会防止问题发生吗？
跟踪并核实结果。问：
- 解决方案有效吗？
- 我如何确认？
利用5whys分析法进行CaseStudy原因分析的几个步骤
Step 1：对事故进行详细描述
“If I had an hour to save the world,I would spend 59 minutes defining the problem and one minute finding solutions.”
– Albert Einstein
对于事故进行定义和描述比较重要，这一步不可省略。在描述事故时，我们基于5W2H（What，Who，Where，When，Why，How，How much）分析法来对事故进行描述，说清楚事故发生的时间，地点，发现人，怎样解决的，解决的时间等等。
- What：描述下发生了什么问题。
- Who：描述下责任人是谁，谁发现的问题，谁解决的问题。
- Where：描述下在哪里发现的事故。
- When：描述下事故的时间因素，什么时候发现的事故，什么时间解决的事故。
- Why：描述下为什么是个事故，强调事故的影响。
- How：描述下事故是怎样被解决的。
- How much：描述下事故的可量化的影响范围和造成的损失，影响了多少用户，造成了多少损失等等。
Step 2：提问：为什么这问题会发生？
识别并确认导致当前问题发生的直接原因。如果原因是可见的，验证它。如果原因是不可见的，考虑潜在原因并核实最可能的原因。
Step 3：检验上一步中发现的原因是否是根本原因？
检查上一步中的回答的原因是否是导致事故的根本原因，如果不是，则重复Step2和Step3，直至找到事故发生的根本原因为止，最终通过这样一个过程建立一个通向根本原因的原因/效果关系链。这个过程一般需要持续5次为什么（可能少于或多于5个），这也是5whys分析法名字的由来。
Step 4：找到问题发生的根本原因，制定执行计划并修复
找到问题发生的根本原因后，采取明确的措施和手段去处理问题，预防和避免类似问题的再次发生。对于采取的纠正措施和手段，需要问问“采取后能否避免问题的再次发生”，如果不能，再找到其他的解决之道。
纠正措施/执行计划必须遵循SMART原则
即：
1. 目标必须是具体的（Specific）
2. 目标必须是可以衡量的（Measurable）
3. 目标必须是可以达到的（Attainable）
4. 目标必须和其他目标具有相关性（Relevant）
5. 目标必须具有明确的截止期限（Time-based）
参考链接：
=END=
《 “5whys分析法” 》 有 5 条评论
谈谈服务稳定性
https://blog.xizhibei.me/2018/05/06/lets-talk-about-the-service-stability/
`
问题的解决思路
预防问题：
人为疏忽：线上擅自调试代码、擅自动线上数据库；
基础设施：数据库爆了、机房光缆被挖断了；
代码复杂度：欠了太多的技术债；
处理问题：
这里有个原则：故障发生时恢复大于原因查找，也就是说需要通过各种手段，把事故的影响面减到最少，并且尽快恢复服务。
总结问题：
故障处理的整个过程
故障原因分析
问五个为什么
故障后续整改计划
季度回顾会议，这个会议上，主要做的事情是：
1、回顾上个季度中的所有事故；
2、统计所有事故故障后续整改计划执行情况；
3、总结易犯错误，给出解决方案，并完善规范跟流程；
`
黑匣子思维
https://book.douban.com/subject/27077719/
書｜黑匣子思维：我们如何更理性地犯错
https://mp.weixin.qq.com/s/OwT4SZMrhFalL4VWoy4v3g
我要收藏 | 用200本书，建构自己的知识体系
https://mp.weixin.qq.com/s/Xd02yNbM5KmEaH0Hh-Hekw
年度盘点 | 2018年，我们一起读了这些书
https://mp.weixin.qq.com/s/mHsUWaYnfXmYSNiaq26jTA
研发团队之故障定级
http://jiaoblog.cn/%E7%AE%A1%E7%90%86/%E7%A0%94%E5%8F%91%E5%9B%A2%E9%98%9F%E4%B9%8B%E6%95%85%E9%9A%9C%E5%AE%9A%E7%BA%A7/
`
事前预防——规范、流程、制度、工具支持(备份、灰度、监控、回滚、……)；
事中处理——SOP(操作回滚、信息同步/故障通报)；
事后总结——时间线梳理、问题总结、根因分析、反馈优化事前/事中的规范流程制度；
一次线上变更可能涉及的流程有：
代码审查
测试覆盖
操作SOP(数据/配置是否已备份，回滚方案，故障处理，……)
灰度周知
高峰期限制
异常周知
复盘
`
工程师的基本功是什么？该如何练习？听听美团技术大咖怎么说
https://mp.weixin.qq.com/s/vOZb2PUdqMUj17ReMA43GA
`
在美团有一句老话，叫做“苦练基本功”。美团创始人王兴解读的基本功是业务和管理的基本动作。只要能把基本功扎实练好，就能产生巨大价值。然而滴水石穿非一日之功，练好基本功是一个长期的事情。
苦练基本功，我们要调整好心态面对长期的挑战，同时在重复工作中得到自我提升，将简单的事情做到更好，将我们的能力提高一大截。
那么对于技术团队来说，专业基本功是什么？又该如何练习呢？一起听听美团技术大咖是如何理解技术基本功的吧……
# 技术基本功存在于每一行代码中
# 把基础技能练扎实，就能形成肌肉记忆
# 基本功易学难精，并具备持续的可提升性
# 练习基本功没有捷径
# 用最高的工作标准牵引基本功的锻炼
桥水基金创始人雷·达里奥在《原则》一书中写道，我们每个人都应该有自己的原则，当我们需要作出选择时，一定要坚持以原则为中心。这篇文章总结了十条工程师的精进原则：
原则一：Owner意识
原则二：时间观念
原则三：以终为始
原则四：闭环思维
原则五：保持敬畏
原则六：事不过二
原则七：设计优先
原则八：产出/产能平衡
原则九：善于提问
原则十：空杯心态
以上这些原则有的侧重于个人做事情的方法，比如“Owner意识”、“时间观念”、“以终为始”、”闭环思维”等等；有的侧重于团队工作标准规范，如“保持敬畏”、“事不过二”、“设计优先”等等；有的侧重于团队或个人效能提升，如“产出与产能平衡”、“善于提问”、“空杯心态”等等。这些原则也是作者多年在工作与学习中，不断总结得来的经验。希望对大家的进阶成长能够有所帮助。
`
Details of the Cloudflare outage on July 2, 2019
https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/
`
Cloudflare 的故障报告，堪称业界典范，有详细的故障发生背景，故障内容（非常细致），解决过程，为了把过程说清楚，还会附上相应的流程图，内部的 CI 截图等等。而且针对这个正则问题，还挖出了 Ken Thompson 在 1968 年写的一篇论文。
有条理，有过程，有细节，有钻研精神，如果以后你也有类似的需要写事故报告的场景（希望你用不到），可以参考一下。
# The events of July 2
# What happened
# How Cloudflare operates
# WAF Threats
# Quicksilver
# What went wrong
# What’s happened since last Tuesday
# Conclusion
This was an upsetting outage for our customers and for the team. We responded quickly to correct the situation and are correcting the process deficiencies that allowed the outage to occur and going deeper to protect against any further possible problems with the way we use regular expressions by replacing the underlying technology used.
We are ashamed of the outage, and sorry for the impact on our customers. We believe the changes we’ve made mean such an outage will never recur.
# Appendix: About Regular Expression Backtracking
`
“Programming Techniques: Regular expression search algorithm”
https://dl.acm.org/citation.cfm?doid=363347.363387