27故障管理：对故障的理解
- 系统正常，只是该系统无数异常情况下的一种特例
- Design for Failure 理念：我们的目标和注意力不应该放在消除故障，或者不允许故障发生上，因为我们无法杜绝故障。所以，我们更应该考虑的是，怎么让系统更健壮，在一般问题面前，仍然可以岿然不动，甚至是出现了故障，也能够让业务更快恢复起来。
故障永远只是表面现象，其背后技术和管理上的问题才是根因
- 技术和管理上的问题，积累到一定量通过故障的形式爆发出来，所以故障是现象，是在给我们严重提醒
- 理解一个系统应该如何工作并不能使人成为专家，只能靠调查系统为何不能正常工作才行
- 作为管理者，需要时常问自己：下次出现类似问题，怎么才能更快地发现问题，更快地恢复业务？即使这一次的故障应对已经做得非常好了，下次是否可以有更进一步的改进？
反省
- 出问题，管理者要先自我反省
- 强调技术解决问题，而不是单纯地靠增加流程和检查环节来解决问题，技术手段暂时无法满足的，可以靠管理手段来辅助
- 必须尽快将人为动作转化到技术平台中去。（随着系统复杂度越来越高，迟早有一天会超出单纯人力的认知范围和掌控能力，各种人力的管理成本也会随之上升）
28故障定级和定责
故障的定级标准
- 相关参与人员：技术支持团队，HRBP，人力
- 制定标准相关相关要素：
- 等级 p1~p5
- 业务线：不同的业务线有不同的业务定级标准
- 参考指标：影响时间，交易量，
- 制度：技术支持团队与业务研发团队，细分标准；按需修订与完善
故障定责的标准
- 定责主要目的是判定责任方，避免扯皮推诿；正视问题严肃对待
- 定责判定维度（故障类型）：变更执行，服务依赖，第三方责任
39 故障管理：鼓励做事，而不是处罚
关于定责和处罚
- 定责的过程，是找出根因，针对不足找出改进措施，落实责任人。定责的目的，是责任到人，并且责任人能够真真切切地认识到自己的不足之处，能够主导改进措施的落地。同时，也让整个团队认识到，我们对于故障的态度一定是严肃严格的
- 定责：对事不对人
- 处罚：对人不对事
- 对于有明确底线，坚决不允许触碰的规则，如果因不遵守规则，故意触犯，导致了严重故障的出现，这种情况是要处罚的。
- 高压线原则：
- 未经发布系统，私自变更线上代码和配置；
- 未经授权，私自在业务高峰期进行硬件和网络设备变更；
- 未经严格的方案准备和评审，直接进行线上高危设备操作，如交换机、路由器防火墙等；
- 未经授权，私自在生产环境进行调测性质的操作；
- 未经授权，私自变更生产环境数据信息。
鼓励做事，而不是处罚错误
- 故障的发生、处理、复盘和改进有助于团队能力提升，对于故障要保持容忍度和耐心
- 发现不足
- 未来改进方向
- 团队和个人综合能力提升
- 技术依赖员工的创新和创造
- 员工积极性
- 作为管理者：
- 将规则和标准定义清楚，在执行时才能够做到公平公正
- 故障发生，要关注更全面的内容，关注人（状态，情绪），事情背景和前因后果
处罚的负作用
- 不能将定责与绩效强挂钩，会出现
- 团队互不信任
- 宁可少做，不愿多做多错，团队沟通成本上升，运作效率下降
- 更好的方式：专门系统记录，将评估放到一季度，半年，或一年表现中进行判断
30故障管理：故障应急和故障复盘
故障应急
- 业务恢复预案：
- 第一原则：优先恢复业务，而不是定位问题
- 业务应急预案：
- 凡是没有演练过的预案，都是耍流氓：日常没演练过的，都没执行，应急情况下执行更容易出错，导致次级故障。
- 故障模拟类型：
- IDC层面：ups切换，电力切换，交换机，路由器
- 系统层面：cpu，io，disk
- 应用层面：RT，499，5xx
- 有效组织协调；故障发生后关键事项：
- 故障通告
- 组织应急小组
- 恢复业务
- 信息汇报
- 总结：故障应急过程就是功夫要下在平时，注意建设各种工具和平台，同时要尽可能地考虑和模拟各种故障场景
故障复盘
- 复盘的目的是为了从故障中学习，找到我们技术和管理上的不足，然后不断改进
- 切忌将复盘过程和目的搞成追究责任或实施惩罚，这对于团队氛围和员工积极性的打击是非常大的
- 复盘过程：
- 召集复盘会议：准备要讨论的问题，邀请相关人员
- 组织复盘会议
- 故障简单回顾
- 故障处理时间线回顾：尽可能细
- 针对处理时间线讨论：对事不对人，针对性提问
- 确定故障根本原因：就事论事
- 故障定级与定责：依据规范定级与定责
- 发出故障报告：详细的故障信息，故障原因，后续改进措施，总结问题与建议。跟进后续的改进措施
- 定期总结故障案例：从更高层面分析故障，发现自身架构与业务层面的问题
