应对发布带来的各种影响

如果你验收通过了产品，恭喜你。你做得很棒，你的产品也终于发布了！但交付 还没有完成，你还有些事情需要做，比如处理可能涌现出来的危机，向全世界宣传产 品，以及和团队共同庆祝。下面列出五项发布后需要做的事情。

1. 应对回滚。

2. 处理产品危机。

3. 演示产品。

4. 应对媒体。

5. 庆祝发布。

7.8.1  出现问题，回滚软件

这句话值得反复强调：只要成功回滚，发布就还没有失败。回滚是指把软件撤回 到预发布状态。它简直就是家常便饭。我在亚马逊和谷歌都见到过一些发布回滚了5 次甚至更多。大型软件系统的接口和依赖太多太复杂了，你几乎不可能在发布前测试 和验证完所有可能性。如果发生回滚，只要对用户没有产生明显伤害，你就还没有失 败。所以最终你会发现：最好的防守是制定周详的撤退计划。

有时候你可能无法回滚或因为回滚成本太高而不愿回滚，这种情况下你的最佳选 择是确保你的团队能在发布后数天内继续高歌猛进，因为你们需要一段时间来找到问 题、修复问题，同时在修复问题的过程中，你的客户还得继续忍受这些问题。所以从 另一方面讲，如果可以回滚，你就能撤回对产品的改动，从容不迫地修复问题，然后 再试一次。

7.8.2  应对产品危机

危机有时会突然爆发出来，可能是你的网站被瞬间大规模的流量冲垮，也可能是 出现安全漏洞、隐私侵害或者定价事故，又可能是一个实习生把本应重定向到数据中 心的产品站点重定向到他的个人桌面了（真实故事）。像这些情况你都可以参照下面 的这份可靠的行动计划来应对。同时和所有优秀的应对措施一样，下面这份行动计划 也受到童军运动^a的启发：做事之前，先做准备！

先做准备部分意味着你需要事先安排好人员轮班待命并给他们配备寻呼机。我仍 然认为手机不如寻呼机可靠，但我没有找到一个可靠的方法来强制工程师在公司之外 也随身携带寻呼机。因此你需要把团队里每个工程师的手机号码都记在手机或者号码 簿里。

一个准备充足的产品应该拥有可以快捷关闭服务或限制服务速率的软件开关。切 记只要有可能就应该在实验性框架下发布软件，或者软件中带有可禁用特性的标记。

记住，只要成功回滚，发布就还没有失败。

你还可以更早做好应对灾难的准备。在早期软件设计评审会议中，你就可以要求 工程团队针对可能的错误设计应对方案。比如建立一套逻辑来限制对过载服务器的请 求。你需要呈指数级地增加退避（backoff）时间^b，并总是随机修改它的值，这样退避 的行为才不会造成更深层次的破坏。退避的随机修改机制可不是闹着玩的，我曾见到 过被不完善的退避机制拖垮的系统比被原始问题拖垮的还多。确保在交付之前建好退 避机制。

你还可以准备得更好一些，比如取得某个服务器专家的联络方式，哪怕你的团 队里没有这个角色。如果能维护一套紧急联络簿并牢记于心，并在内部公开那自然更 好。你还可以创建一个内部Wiki 来存放公关、法务和跨职能团队的联络方式，这样 在找人方面你就基本不会有什么大问题了。当然你也可能遇到一些小的令人沮丧的事 情，比如当发现某个特定民族的用户因为莫名的原因突然无法正常使用你的产品时，

你可能不知道该找哪个公关的同事帮忙应对。你猜的没错，它在我的身上发生过。

a 可参考维基百科“童军”条目。——译者注

b 退避时间是指网络节点在向服务器发送请求时产生冲突后再次发送请求需等待的时间，如果每次退避时 间都一样，那么之前冲突的请求又会再次冲突。——译者注

你还可以使用另一种方法来提前建立有效的沟通渠道：创建一个危机扩大邮件组

（[email protected]）以便所有相关人员都能被纳入进来。他们包括公关、

客户支持、你自己、你的工程主管、你的产品主管以及重要的跨职能团队负责人等。 急火燎地找人解决后发现唯一的问题只是因为你清空了cookies。你还需要确定这个问 题不止在公司内部用户或内部试用版的用户身上出现。除了使用外部账号验证外，你 还可能需要看一下是否有客户在论坛、Twitter、eHarmony 等任何地方发表过相关的信 息。你要找到一个确实存在该问题的客户。

在主持电话会议的过程中，请不要去掺和讨论解决方案。我再次强调这一点。虽

解决大型危机的最佳方法是撤销任何引发危机的改动。“前滚”（Rolling forward）

需要更多编码，更多测试，因此需要更多时间。而且在重重压力下编码的效率会十分

况，你是什么都不用做，也什么都做不了，你只能把自己添加到他们的Bug 中（假设 在某某时间提供更多信息或解决方案”。Google 应用状态面板（http://www.google.com/

appstatus）就是一个很好的例子。让你的公关 / 客户支持团队帮助你起草公告，这样 可以避免泄露敏感信息或者制造过度恐慌。然而不要避讳承认产品存在问题，用户会

问题是在       （时间）发生的，我们预计会有       （用户数量）受到

的支持等。 下载流量分到到阿卡迈^a（Akamai）的内容分发网络（CDN，Content Delivery Network），这样问题就暂时解决了。

危机处理“剧本”：收尾以及撰写事故调查报告

谁受到了影响？

尽可能详细地描述受到影响的客户，包括他们的数量，他们所属的类别以及其他 你知道的关于他们的任何有用的信息。

问题是何时出现，又何时终结了？

你应该提供这场危机的基本时间线。

为什么会发生这个事情？

你需要在这段解释事情发生的根本原因。如果你还没有找到根本原因，继续追问

“为什么”，直到你找到它（参见第10 章关于鱼骨图的讨论）。我在后面的示例中使用 了讨论的方式来阐述根本原因，你不一定要像我这样做，但这么做有利于解释为什么 你会得出那样的结论。

如何防止这类问题再次发生？

如果你彻底解决了这类问题，那自然最好（虽然可能性不大）。不过既然你还在 写事故调查报告，说明你的团队还有很多做法值得改善，你需要让所有人都行动起 来。确保每一个人都负责改善一些东西，从而使更多的改善能够落实。

下面是一个事故调查报告的示例，事故调查报告也被称为“故障原因”（COE，

Cause Of Error）报告。

COE 报告示例 

COE #1 - 令人羞愧的 SQL 注入漏洞。

03/07/12 —— 初稿 —— 克里斯 · 范德 · 梅（cvandermery@）

跟踪 Bug ： http://bugzilla/b=1234

什么问题？ 广告优化团队发布了一个针对优化程序前端的更新，但在更新中 他们没有正确清理搜索语句。同时，数据库运维团队更新了数据库并重写了一些存 储过程，但他们没有正确地防范来自SQL 注入的攻击。一位内部同事在开发入门 示例时发现了该问题。

谁受到了影响？客户在体验过程中感知不到这个漏洞。我们分析了SQL 事务 日志也没有发现任何不规范的INSERT/UPDATE/DELETE/SELECT…INTO 语句，

因此我们认为目前还没有客户在利用这个漏洞。我们也没有收到任何关于此次危机 的客户问题报告。

潜在风险：该漏洞暴露给了约10% 的用户基数，但由于登录用户才能利用该漏 洞，所以风险还会再小一些。

这个问题什么时候发生的？

问题发生： 5/1/08 14:00 问题发现： 5/5/08 15:00

回滚服务器到最近一次正常状态： 5/5/08 16:43 问题解决（推送了新的前端）： 5/6/08 16:00 为什么会发生这个问题？

我们没有对 SQL 注入写单元测试。

为什么？实际上我们无法让构建运行在有SQL 服务器的环境里。

为什么？我们无法模拟SQL 服务器。

为什么？我们的基本测试矩阵里有漏洞。

我们无法协调数据库（DataBase，简称 DB）运维团队。

为什么？为了增加自主性，DB 运维专门从我们前端团队中分离出去了。

为什么？团队讨论效率太低了。

为什么？每个人都有不同的观点，我们无法做出决策。

为什么？没有确定谁拥有查询安全性问题的决定权并承担相应责任。

如何避免这类问题再次发生？ Cvandermey@ ： 编写单元测试，确保 SQL 注入 失败。 Harry_the_db_lead@ ：拟定预部署清单，要求每个需要 DB 运维协助的团队 的产品主管验收确认。所有DB 发布候选版本都要执行清单中提及的测试。 所有的 测试主管：强调代码评审（code review）的重要性。Charlie_tl@ ：尤其是要拟定一 个代码评审中需检查事项的清单。

7.8.3  演示产品

重新回到有趣的事情上来，你的发布正顺利进行，现在需要你投入精力的是通 过一次演示来将产品展现给世人。你的演示需要直截了当，演示的目的在于用讲故事 的方式来讲述产品，并在每一步凸显产品使命。它必须简洁，最好不要超过10 分钟，

这样才能保持观众的注意力。如果你把演示制成视频放在博客中，则这个视频决不能

是10 分钟这种长度的，它需要被压缩在 90 秒以内，否则访客会很快失去注意力。

和撰写博客文章一样，演示也需要遵循既定的策略。先从问题和使命讲起。不断 陈述使命，也许你会觉得啰嗦，但这招很管用。在演示开始时一定要让用户明白他为 什么应该关心这个产品。

接下来以讲故事的方式把演示串起来。好的演讲总是利用一些故事来吸引听众并 让他们产生代入感（第10 章有更多关于演讲的内容）。你的演示也应以一个贯穿始末 的客户故事为主线。用“想象一下”或“人们常会碰到一个问题”这样的句子来开讲

接下来以讲故事的方式把演示串起来。好的演讲总是利用一些故事来吸引听众并 让他们产生代入感（第10 章有更多关于演讲的内容）。你的演示也应以一个贯穿始末 的客户故事为主线。用“想象一下”或“人们常会碰到一个问题”这样的句子来开讲