Bug Fix 之后的随笔
或许，Zero-Bug 不是一个目标，而是一种奢望。Bug fix 成为了程序员工作中的日常活动，有人说，bug 的堆积导致了经验的积累，真的是这样么？
当然，在bug fix 之后，回顾并不新鲜，至少在软件开发中是这样的。在过去的十几年里，这样或那样的敏捷开发方法一直在赞扬每个开发冲刺阶段结束时固定反思的优点。实际上，这些是否真的发生在实施敏捷的组织中仍然是一个有待解决的问题。影响服务的bug经常轻易地转化为令人瞠目结舌的损失或SLA罚款，Bug fix 之后的谈话可能会趋向于紧张，在某种程度上，要么是为了平息混乱的局面，要么就是为了改变一个没有人愿意深入讨论的话题，讨论转移到补救措施上。
这种模式可能我们彼此都很熟悉。技术公司中的大多数事件分析流程看起来或多或少是类似的。这就引出了一个重要的问题: 是不是忽略了这个反馈循环中的一些东西，即如何处理可能有帮助的事件？
学习的问题
如何学习个人的、单一的经验教训？也就是说，什么构成了一个事件，如何发现自己身处其中，以及这些事件究竟如何成为了个人或整个组织学习的素材。既然可以确定输入是什么样子的， 那么从事故中学习的过程是什么样子的呢？学习的重点大多集中特定的方面，它涉及到如何确定需要学习的经验教训。
本质上， 需要明确促进学习的因素，或者通常是抑制学习的障碍。对组织而言，也是如此。
洞见的类型
洞见或许植根于心理学/认知学的观点，而社会洞察力发生在团队和公司范围内，当我们更多地关注试图理解事件和如何解决问题的群体时，会需要一些社会洞察力。还有所谓的“政治洞察力”，无论是在事件发生的前后。必须承认，在任何系统中，有人的地方就有江湖。
事故的分析
事件验证过程也会产生输出，常见的事故报告、与软件或基础设施相关的补救措施、更新的文档，或其他的团体间通信。事件的其他所有细节都可能被认为是一个黑匣子。事故是严重的Bug， 事故的分析在技术团队有着各自的方式， 在百度叫做case study。
开发人员倾向于使用日志来帮助确定事件的“根本原因”，以及为bug fix 和架构重构生成需求规范。但随着时间的推移，个别工程师已经忘记了程序中的具体细节。复杂的技术系统通常不仅是代码、计算、网络和存储的混合体，也是人和团队的混合体。很多时候，我们必须在极端的时间和压力下作出关键的决定，权衡自己的行动。事故分析的流程可以帮助我们创建和更新心理地图。复杂软件和基础设施系统不断发展，无论是在技术方面，还是在技术背后的团队方面，甚至是组织关于系统如何工作，都会随着时间的推移而退化。任何一个在内部 wiki 上找到四个架构图而感到沮丧的人，都经历过这种情况。
复杂技术系统中看起来互不相干、互不相连的组件之间存在联系，人与团队之间的联系存在未知和缺失，需要建立一个持续的沟通渠道。很多时候，大型事故可以表明组织已经忽视了需要投入更多的领域，因为复杂系统以某种不成熟的方式进化了。
动态修复
如果我们专注于收集、理解和分享一个子系统的技术状态，以及负责运营和维护它的优先级、偏好、激励和约束，对补救项目的静态清单就让位于这种丰富背景的搜索和发布。动态修复的重点在于：
个人和团队如何处理事件以及如何协调
对系统的心理模型是什么，包括代码的状态、基础设施和其他团队的期望，以及这些心理模型如何对决策做出贡献
思维模式的分歧在事件中的影响
导致事件发生的因素有什么样的背景，也就是说，面临的其他压力、激励或环境可能更容易促进与事件相关的因素。
在事故后分析之前已经确定了负责决定这些修复的优先级。在另一些情况下，需要进一步的讨论来获得进一步的背景，来充分理解所有潜在的补救措施以及它们在更广泛背景下的相对优先级。开发、运营和安全团队与系统最为接近，从而推动更具弹性、更灵活的解决方案，即战略责任多于战术责任。我们不仅关注零敲碎打的修复，还要改善工作方式、相互之间及其设备之间的互动，以及对其复杂技术环境中的变化进行有效沟通，这是一个可以产生最大胜利的地方。
小结
分析和理解Bug和故障的认知模型和社会模型在业务中很少得到巩固，而事后分析不只是侧重于补救和预防，但事实并非如此，事后分析的唯一价值并非在于补救的列表。推动事后分析的过程从专注于每个具体事件，发展为揭示我们的实践、过程、激励、局部环境以及复杂系统的真正本质。
【关联阅读】