金字塔原理中的逻辑顺序

结论先行，至上而下，可以帮助我们确定论点，目标，继而确定大标题，小标题 ，在标题之下的演示文稿的内容的就是分论点或者论据。那么问题来了，多个分论点或者论据，要如何组织和呈现呢。在金字塔原理中，介绍了三种常见的逻辑顺序，包括时间顺序、重要性顺序、内在结构顺序。这次先来重点说说时间和重要性，在日常工作中，最能体现这两个顺序的就是事故复盘。在计算机领域，没有出个运维/运营事故的团队最有可能是没有承担责任的团队，出了事故，没关系，能复盘并不犯相同类似的错误就是好团队的象征。

运营事故复盘中的时间逻辑顺序

复盘的第一步，就是还原事情的真实情况，不用加工和归纳。这时，时间逻辑顺序就非常重要了。事故从问题产生，扩散，到用户投诉或者监控问题开始增加开始，然后紧急排查定位到最终分析解决，一步步列出来。最终形成了时间线，根据时间线我们可以构造出因果线，帮助寻找事故背后的原因。举个例子，大家可以阅读文稿中的我们曾经复盘的一个案例，

跟团队复盘的时候，必须有像上面这样的一份还原事实的时间线，其实并不简单，要追溯缺陷系统，svn提交记录，发布系统，问题的关联分析，还有许多“为什么”需要跟相关干系人了解， 例如补丁准备时间为什么这么长，为什么7月30日10:00会改出空指针问题，为什么出新的安装包时间要相差好几个小时。在这个追溯的过程，其实就是在找问题出现的源头。

这里有个工具介绍给大家，帮助还原清晰的因果线，就是“5个为什么”。这个方法源自丰田汽车公司的创始人丰田喜一郎的父亲丰田佐吉，并且纳入丰田内部培训的课程里面。简单点说就是规范化刨根问底。其实在上面表格的那个真实案例，也是这么问出来的。

当时，我们有个同事布兰特很沮丧地找到我说，我们的随机测试NewMonkey工具有问题，漏出了一个被测产品的TOP Crash。现在想起来，这样的责任心很宝贵的，出问题，测试工具来抗。但是当时我就实验下一下“5个为什么”来还原事实，下面是当时的对话。

当时我不禁发问，“是核心功能吗？”

布兰特答，“嗯，是的。打开聊天窗口”

我又问，“那为什么会Crash呢？”

布兰特翻查了一下svn修复的记录和线上的堆栈，”因为全局变量的空指针问题“

我又问，“嗯，全局变量。那为什么之前没有Crash，现在Crash了，是修改了哪里？”

布兰特又查了一下几天前的修改记录，“天呀，在同一个界面居然还修改了两次空指针错误。7月29日的时候，开发把这个全局变量设置为空之后，我们的工具就发现了两次Crash，开发做空保护，修复了两次。“

我继续好奇地问，“淡定，现在问题找到了。但是为什么开发要把那个变量置空。”

布兰特看了下置空的SVN提交记录中关联的缺陷单说到，“是我们QAPM自动发现的内存泄漏问题，然后开发在反注册之后，把关联的全局变量置空了。“

之后我们据此，出了复盘的邮件，除了帮助提升开发意识的案例培训之外，也给静态扫描等工具提出了针对性的要求。

运营事故复盘中的重要性逻辑顺序

1.png

在复盘中，通常我们需要写改进措施。但是问题来了，对于平日忙到吐血的我们，要确保措施落地，就要思考一件事情，优先级/重要性。所以在改进措施的演示文稿或者表格中，就可以按照重要性/优先级的逻辑顺序来呈现。接着上面的例子，当时我们的重要性排序是，静态检查规则扫描并修复>核心代码更改告警>开发案例培训。

重要性与时间还出现在什么汇报中

除了事故复盘这种悲伤的事情，跟上级汇报中计划与进度、产品Roadmap，通常是按照时间线来展开。当然这个时间线本身就蕴含了对重要性的综合考虑。例如文稿中的演示文稿。

2.png

NewMonkey的进度与规划

另外一个就是，重要性逻辑排序。为了体现你在解决问题上，对关键矛盾/问题的识别是否到位，通常也就在解决方案的陈述中使用。例如文稿中，我曾经汇报的这页演示文稿，陈述的是面对Web性能监控方案的需求压力，我们怎样解决快速补全功能的问题。

3.png

解决方案，解决整合

在紧接着的演示文稿，会先详细说明Web性能监控如何整合。然后再说其他监控能力如何自研和整合配合。这个重要性顺序的安排的思考在于，1. 啄木鸟和伦琴都是现成在公司内成熟的方案；2. 监控与分析的闭环如果没有达成，用户使用的时候就会有发现问题无法修复的困境，体验也没有闭环；

通过这个例子，听众们应该知道时间与重要性逻辑顺序的基本用法和使用的场景。说真的，两个顺序难度不算最大的，只要多想，细心点，就可以写出来。但是下一节，我们介绍另外一个重要的逻辑顺序，内在结构的难度就高多了，敬请期待。