你好，我是郭东白。从这节课开始，我们就进入到架构活动的最后一个环节：复盘。

当遍历完价值单元的交付树之后，其实也就完成了整个架构活动的交付。到这里，比较普遍的方式是业务方最终验收并庆祝上线。这是个传统的由项目经理主导的步骤，相信你肯定经历过不少，我在这里就不赘述了。

与此同时，大多数产品和研发人员已经进入了一个甚至多个项目，也开始了新一轮的紧张迭代。很多团队主管甚至也以自己团队在连轴加班而生出一种自豪之感。

但作为架构师，我们或许要像卢瑟福一样发问：“如果不停地加班，那你什么时候思考呢？” 是的，当经历了一个充满不确定性、信息不对称、高度紧张的架构项目，我们不能没有一个深度思考的过程。这个过程就是复盘。

复盘是最容易被忽略的环节，但对于架构师和整个团队的成长来说，却有着极其关键的作用。所以在这节课，我会拆解复盘整个环节，确保你跟所有参与者的成长都能最大化。甚至，还可以通过复盘挖掘到更多的架构机会，为未来同类的架构活动沉淀更好的工具。

不过在描述复盘的完整过程之前，我们先要对复盘的定义有个统一的认知。

复盘的目的

需要预先说明的是，我们这两节课要讲的复盘，特指通过还原并深度思考架构活动的完整历程，来寻找可以提升未来架构活动成功概率的过程。

在互联网时代，复盘这个词已经被滥用了，以至于很多人将复盘与总结反思画上了等号。因此我有必要再针对复盘的定义进行详细解释，帮助你更全面地认识复盘。

首先是复盘的目的。我们在复盘的定义中已经给出了，即：寻找可以提升未来架构活动成功概率的机会。大多数复盘其实都偏离了这个目标。在我参与的上百次的复盘中，我也很少见过参与者自始至终都能忠于这个目标的。

我们可以用一个公式来表示，也就是 P(E)

其次是复盘的对象。复盘的对象不仅包括失败案例，还包含成功案例。我们通常对成功案例有着较为主动的学习动机，也就是我们经常提到的路径依赖。而对于失败案例，我们却常常有着自我治愈和选择性遗忘的倾向。

事实上，企业中的架构尝试大多数都是以失败告终的，所以从失败案例中学习的机会其实更为频繁，而且对我们未来避免失败也至关重要。我甚至觉得很多人的成功就是来自对失败案例的高效学习。

最后是复盘的视角。复盘可以有多个视角：一种是对他人的审视；一种是对自我的审视；还有一种是上帝的视角。

上帝视角实施起来会比较困难，有点像历史学家对某个历史事件的审视，需要穷尽信息的收集。在互联网企业，我们不太具备这种严苛的信息收集的条件和所需时间。不过，我们可以通过协调所有参与者来最大化前两种视角，在最大程度上逼近上帝视角。

要怎么理解前两个视角呢？

• 对他人的审视，简单来说就是一句话：谁造成了我的失败？

• 对自我的审视，简单来说也是一句话：我什么地方做得不完美？

除了不同视角的分析外，复盘还需要从不同的维度进行分析，比如决策逻辑层面、执行层面、组织和文化层面等。

一个项目的失败，尤其是灾难性的失败，基本上都是多个维度的因素叠加造成的。如果团队在某个维度上的能力做到了极致，往往可以弥补其他维度上能力的不足。

举个很简单的例子，假设一家公司的研发人员压力大、交付周期短，自动化测试覆盖率也不够高，导致项目发布经常带有故障。如果这家公司在灰度发布、指标监控和自动化回滚等方面做到了极致，那么即便有故障，但靠着发现及时、报警响应快、能做到一键回滚，也能保障项目发布的稳定性。

复盘的三大误区

明确了复盘的定义之后，会发现，你之前所做的大多数复盘其实都走进了误区。我把这些误区归类成三种。

第一个最常见的误区是止于问责。在一个重大问题出现后，很多公司的做法都是先在公司内部找到第一责任人，然后对责任人处以与失败相同量级的处罚，甚至开除。这种机制的目的是防止复盘参与者互相包庇，最后大事化小、小事化了。

问责机制的确可以用在复盘环节中，来帮助公司发现问题的真正根因。不过也要明白，找到或惩罚责任人并不是复盘的目标，也不应该是复盘的终点。复盘的目标是寻找可以提升未来架构活动成功概率的机会点。

从这个视角出发，问责制的一些缺陷就会暴露无遗：

• 偏离目标：不少互联网企业会将很大比例的薪酬放在绩效激励上，而维持问责制的有效性，意味着它会与激励相挂钩。那么让其他参与者知道自己的问题，很可能会带来不小的经济损失。此外，还会导致复盘时将大量的时间耗费在问责过程中，甚至就是在讨论“谁的责任更大一些”这个问题。而未来如何改进这个更重要的问题，很容易被大家所忽视。

• 遗留隐患：项目失败后，公司的损失已经是既成事实，靠惩罚一两个责任人并不能挽回什么损失。此外，即使问责处罚完，公司或系统的隐患依然不会消除。反倒因为把责任归属到一两个主要的责任人身上，导致其他人身上所存在的隐患被完全忽视。在崇尚问责制的公司里，你肯定能观察到这样的现象：复盘会上只有一两个人争论得不可开交，其他人都噤若寒蝉，生怕把自己牵扯进来。

• 人才流失：高风险的项目本来就容易失败。一旦斩了先锋，可能再也没人敢为这种项目担责冒险了，望而却步会成为项目参与者的默认选项。

在我看来，失败是一个公司必须要付出的学费。不失败，反倒是公司在行事上过于保守的侧面证明，也会对参与者的冒险精神有所压制。对于一个公司来说，最重要的是从失败中获取能力的提升。

第二个常见的误区就是止于意识提升。在复盘的过程中，肯定会涉及到自我剖析，让参与者寻找各自的提升点。但是项目复盘，更重要的是整个公司的能力提升，而不是参与者个人能力的提升。

这两者的区别在于，个人能力的提升并没有固化到团队或公司中。比如某个参与者离职，对公司来说，就失去了一项能力。要知道，无论是你个人的能力，还是其他人的能力，都属于公司组织能力提升的一部分。但是除了员工能力的提升外，公司其他维度的提升也同样重要，比如系统提升、机制提升、文化提升等。

这里还要插一句。哪怕光做到意识上的提升，其实也非常难。出于对自我的保护和对自尊心的维护，难免会让你放弃反思或者反思不够彻底。所以真正的意识提升，需要参与者都能保持正确的心态。什么是正确的心态呢？我引用印度禅师 Sri Yukteswar 的一句话：“只有靠粗暴的意志才能击碎坚硬的自我 （The hardcore of human egotism is hardly to be dislodged except rudely）。”

第三个误区是止于错误补救。更准确地说，就是止于损失回捞，也就是在最大程度上挽回问题所造成的损失。这是针对已经接近完成的架构活动的补充，是个收尾动作，并不能对未来的架构活动形成任何助力。

通过这三个误区的分析，我想你对我们为什么要做复盘这件事已经有了较为清晰的认知。简单总结一下，复盘的王道就是通过对失败事件的深度剖析，从中寻找一些机会点，从而提升企业未来的架构活动的成功概率。

进入复盘前的准备工作

还是老规矩，在进入复盘环节之前，我们需要做一些准备工作：

• 建设复盘氛围：为参与者提供一个安全且平衡的复盘环境。

• 梳理错失的机会点：从公司层面的宏观视角看，错失的最可惜的机会点是什么？提前梳理重大机会点，可以帮助我们控制复盘节奏，避免复盘成为一个裸心会，被一个麦霸引导到他个人的心灵独白中去。

• 设定目标：引导参会者对复盘目标有个清晰的认知。如果不能拿到一个非常有洞察的、能真正提升未来成功概率的结论和行动点，那么复盘就不能结束。

在这些准备工作中，有两个地方需要格外关注。

第一个是安全的复盘环境。在法则六中我们就拆解过这个话题。如果企业对失败或错误的容忍度极低，那么我们这两节课分享的复盘方法就很难执行到位。

建设安全的复盘环境的具体方式，可以参照我们在搭建架构环境这节课中提供的方法。 这里就不再重复了。接下来我要特别讲一下，应该如何应对国内互联网企业中常见的问责制。

我们刚才提到，问责机制是比较霸道的做法，可能会导致参与者丧失安全感，互相指责，甚至互相包庇，隐瞒事实。如果公司原本就有问责机制，那我们架构师往往也改变不了这个大环境。

但有个折中的办法，就是把你这个架构师主持的架构活动复盘，与官方正式的架构活动问题复盘隔离。架构活动复盘可以放在问题复盘之后，而且最好在公司外的非正式场所中举行，效果会更好。

如果公司的问责机制比较严苛，那么你主持的这个复盘，无论是定位还是时间，都要跟官方问责机制下的问题复盘完全隔离开。一个行之有效的建议是，把你主持的复盘定位成非官方的共创会，安排在问责会结束一两周之后，邀请参与者对架构活动做出思考，对未来提出有建设性的建议。

另一个是平衡的复盘环境，包含四层含义。第一层是视角的平衡，也就是平衡对他人的审视和对自我的审视。对他人审视和对自我审视其实是一对矛盾，当我们在一个视角上的思考做到极致后，难免忽略另一个视角。很简单的例子，如果我们从他人身上找到了能解释自己失败的充分原因，那我们很难正视自己的失败。反之亦然。

第二层是平衡公司内部不同的决策层。这是对“刑不上大夫”的问责制度的挑战，也就是问责问到屋子里层级最高的人的时候，就戛然而止。同样，这么做也是为了把决策层面和执行层面的问题分开来看，寻找各自的机会。

第三层是平衡不同的维度。技术人员做复盘的时候，话题往往是如何改变设计、如何完善监控发现工具、如何提升工程效率，以及如何提升数字化决策的质量。从公司层面看，通过其他手段也可以达到同样的目标，技术手段只是其中一种。因而在复盘中，需要引导参与者注意平衡思考的维度。

第四层是平衡思考深度和行动时间。很多人做复盘，还没完成全面分析呢，就已经列出了一大串行动点，准备整治了。要知道，复盘不是故障响应，不需要立即止血。复盘的重点在于追寻问题本质，而不是整治现象。

那么下节课，我们就来讲讲在复盘这个节点上该如何行王道，以深度探索来提升公司未来架构活动的成功概率。

小结

架构活动的复盘，是你跟其他参与者深度学习的好时机。这是一个集体思考的过程，不是我们日常的习惯性行为。所以必须通过一系列的方式方法，来确保这个思考过程能够最大化未来架构活动的成功概率。

我认为这种方法的成功关键，就是让所有复盘参与者都能清楚地知道复盘的目标，也就是如何更好地迎接未来。 “所有过往，皆是序章（What’s past is prologue）。”这句话放在互联网这个高速迭代的行业里，是再恰当不过了。

因此我们这节课花了很大的篇幅在强调复盘的误区：止于问责、止于意识提升和止于错误补救。如何避免这三个误区呢？答案就是提供安全和平衡的复盘环境。下节课，我会继续介绍怎么利用好这个复盘环境，来深度探索架构活动中可能的机会点。

思考题

这节课有三个思考题，建议选择比较有感触的一道来回答。

• 你参与过的对公司产生最大价值的复盘是什么？这个价值是怎么被发现的？你认为这种发现方式可以被复用吗？为什么？

• 你参与过的最好的复盘氛围是什么样的？为什么觉得这个氛围好呢？这个氛围是如何搭建的呢？

• 在复盘的过程中，参与者或多或少会有些难以逾越的心理障碍。你有没有什么好的应对办法呢？

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net

相关推荐: 缓存击穿、穿透、雪崩及常用解决方案

缓存击穿、穿透、雪崩及解决方案 Redis是一种高性能的键值型数据库，它可以用来实现缓存功能，提高应用的响应速度和承载能力。但是，使用Redis缓存也会遇到一些常见的问题，比如缓存击穿、缓存穿透、缓存雪崩。这些问题都会影响缓存的效率和稳定性，所以需要了解它们的…