个人笔记

故障前准备工作

为了能够在面临故障时做得有条不紊，我们需要做一些前期的准备工作。这些准备工作做得越细，故障处理起来也就越有条理。故障来临时，一切都会变得混乱。此时，对于需要处理故障的我们来说，事可以乱，但人不能乱。如果人跟着事一起乱，那就是真正的混乱了

以用户功能为索引的服务和资源的全视图

这就好像一张地图，如果没有地图，我们只能像个无头苍蝇一样乱试了

为地图中的各个服务制定关键指标，以及一套运维流程和工具，包括应急方案

以用户功能为索引，为每个用户功能的服务都制定一个服务故障的检测、处理和恢复手册，以及相关的检测、查错或是恢复的运维工具

这就好像一个导航仪，能够告诉你怎么做。而没有导航仪，就没有章法，会导致混乱

设定故障等级

亚马逊一般将故障分为 4 级：1 级是全站不可用；2 级是某功能不可用，且无替代方案；3 级是某功能不可用，但有替代方案；4 级是非功能性故障，或是用户不关心的故障

故障演练

故障是需要演练的。因为故障并不会时常发生，但我们又需要不断提升处理故障的能力，所以需要经常演练

灰度发布系统

要减少线上故障的影响范围，通过灰度发布系统来发布是一个很不错的方式。毕竟，我们在测试环境中很难模拟出线上环境的所有情况

故障发生时处理流程

在故障发生时，最重要的是快速恢复故障。而快速恢复故障的前提是快速定位故障源

故障源团队通常会有以下几种手段来恢复系统

• 重启和限流
• 回滚操作
• 降级操作

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

故障发生后复盘与整改优化

故障复盘文档 COE (Correction of Errors)

• 故障处理的整个过程。就像一个 log 一样，需要详细地记录几点几分干了什么事，把故障从发生到解决的所有细节过程都记录下来
• 故障原因分析。需要说明故障的原因和分析报告。 Root Cause
• Ask 5 Whys。需要反思并反问至少 5 个为什么，并为这些“为什么”找到答案
• 故障后续整改计划。需要针对上述的“Ask 5 Whys”说明后续如何举一反三地从根本上解决所有的问题

故障整改

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

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

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

• 故障处理时的判断和章法是否科学，是否正确？
• 故障处理时的信息是否全透明？
• 故障处理时人员是否安排得当？

第三，优化开发过程中的问题。

• Code Review 和测试中的问题和优化点
• 软件架构和设计是否可以更好？
• 对于技术欠债或是相关的隐患问题是否被记录下来，是否有风险计划？

第四，优化团队能力。

• 如何提高团队的技术能力？
• 如何让团队有严谨的工程意识？

找到问题的本质

一个技术问题，后面隐藏的是工程能力问题，工程能力问题后面隐藏的是管理问题，管理问题后面隐藏的是一个公司文化的问题，公司文化的问题则隐藏着创始人的问题

整改优化三个原则

• 举一反三解决当下的故障。为自己赢得更多的时间
• 简化复杂、不合理的技术架构、流程和组织。你不可能在一个复杂的环境下根本地解决问题
• 全面改善和优化整个系统，包括组织。解决问题的根本方法是改善和调整整体结构。而只有简单优雅的东西才有被改善和优化的可能

人的学习分为「被动学习」和「主动学习」两个层次。

• 被动学习：如听讲、阅读、视听、演示，学习内容的平均留存率为 5%、10%、20% 和 30%。
• 主动学习：如通过讨论、实践、教授给他人，会将原来被动学习的内容留存率从 5% 提升到 50%、75% 和 90%。

学习不是努力读更多的书，盲目追求阅读的速度和数量，这会让人产生低层次的勤奋和成长的感觉，这只是在使蛮力。要思辨，要践行，要总结和归纳，否则，你只是在机械地重复某件事，而不会有质的成长的。

学习有三个步骤：

• 知识采集。信息源是非常重要的，获取信息源头、破解表面信息的内在本质、多方数据印证，是这个步骤的关键。
• 知识缝合。所谓缝合就是把信息组织起来，成为结构体的知识。这里，连接记忆，逻辑推理，知识梳理是很重要的三部分。
• 技能转换。通过举一反三、实践和练习，以及传授教导，把知识转化成自己的技能。这种技能可以让你进入更高的阶层。

Before You Ask

Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:

1. Try to find an answer by searching the archives of the forum or mailing list you plan to post to.
2. Try to find an answer by searching the Web.
3. Try to find an answer by reading the manual.
4. Try to find an answer by reading a FAQ.
5. Try to find an answer by inspection or experimentation.
6. Try to find an answer by asking a skilled friend.
7. If you’re a programmer, try to find an answer by reading the source code.

When you ask your question, display the fact that you have done these things first; this will help establish that you’re not being a lazy sponge and wasting people’s time. Better yet, display what you have learned from doing these things. We like answering questions for people who have demonstrated they can learn from the answers.

在提问之前

在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前，请先做到以下事情：

1. 尝试在你准备提问的论坛的旧文章中搜索答案。
2. 尝试上网搜索以找到答案。
3. 尝试阅读手册以找到答案。
4. 尝试阅读常见问题文件（FAQ）以找到答案。
5. 尝试自己检查或试验以找到答案。
6. 向你身边的强者朋友打听以找到答案。
7. 如果你是程序开发者，请尝试阅读源代码以找到答案。

当你提出问题的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题。