本文最初发布于goiabada博客，经原作者授权由InfoQ中文站翻译并分享。

理想中的部署是小型、精简、易恢复、快速的，并且只能占据数据库较小的空间，甚至是零占据。然而，不管我们怎么努力，有时候都无法达到这些目标，你的部署最终是恰恰相反的，是大型、复杂、难恢复、痛苦且缓慢的，并且占据了很大一部分数据库空间。如果你要部署的是软件的关键部分，那就更糟糕了。

但是实际上有更多方式，可以让这些情况变得更糟。下面这些点，如果你遵守了，就能保证部署就像一场噩梦，带来的后果会困扰你和你的同事好几天。

1. 不制定计划

计划真是烦。它们要花时间和精力，也不给你的软件添加新的功能。要计划一次部署，需要考虑清楚部署的范围，更重要的是，要考虑清楚不应该部署的部分（指的是虽然不应该部署，但可能会部署到的内容）。好的部署计划需要简单明了地列出每个步骤，然后尽量将可能发生的问题也列举出来。制定部署计划的目的是在开始之前尽可能多地覆盖盲点。当然了，如果你的团队里有代码忍者、软件大师，或其他什么高级的人物，那你就不需要计划了，尽管随意发挥吧。

2. 不规划停机

停机也好烦，通常在奇怪的时间发生，比如说深夜或一大早，在客户睡着的时候发生（当然你也非常希望是这样的）。为什么要切断公开访问，将客户重定位到完美的“计划维护页面”？在和现场客户在对生产的交流中感到崩溃的时候，为什么还要给你和团队制定平缓、清晰的时间表呢？生产调试是最棒的调试！当你的团队在尝试修复上周五晚上已经修复过的bug时，给客户提供不一致的产品状况，把他们晾在一边让他们云里雾里试试？

3. 摒弃好的日志系统

只有错误不断的软件才需要日志，你的软件并不需要。为什么要花时间和金钱在登录即服务平台上（LaaS）？就让整个团队ssh进入生产环境，观察日志尾部。或更好的选择是用缓慢、不可靠、用户界面混乱的LaaS，这样在部署的时候所有人的工作都是在找bug。

4. 丢掉错误跟踪器

看一下上面的图片，就像日志一样，错误跟踪器也很烦。相信自己不会有任何错误发生的是吧！在你的手中，绝对不会发生回归。而且，在你已经有日志的时候，谁还需要用强大、快速、可靠的错误跟踪平台来追踪异常？你拥有足够的能力，可以在任何异常出现的时候grep，妥妥搞定。

5. 抛弃开发用服务器

开发用服务器是对资源的浪费，它浪费时间又浪费金钱。要一个完全接近生产服务器的副本有什么用？有了它和开发环境还有什么区别？当然，容器化已经抽象出了其中许多区别，但你（最好）有和开发环境中不同的网络设置、第三方API和其他的东西，甚至是容器也好。所以我们要胆子大一些，实现从开发到生产的飞跃！

6. 别检查环境变量

你的项目大概有80个访问令牌、API密钥、数据库证书以及缓存存储凭证，遍布在6个左右的YAML上。它们超级容易跟踪，超难弄乱你的生产、开发和开发用环境（希望有）。不要再三检查部署中已经变更的变量，你能避免几个小时的痛苦调试。

7. 别管部署后的数据一致性

在前面的步骤中，我们已经知道了在部署中客户依旧可以使用软件，所以在保证数据不一致性的道路上我们已经走了一半了。请保证不要让新的代码接触到数据库，特别是数据库结构本身。如果有问题发生，只要回复提交并回滚，这样你就不用担心不一致了。

8. 别为后面的回滚做准备

如果所有都失败了，额等等，这不会发生！在部署的时候可能会出现一些问题，但在完成之后我们就不需要回滚了，是吗？真的是吗？在所有事搞定之后，你制定了一个计划（其实你不需要制定计划，还记得吗？），按照计划一步步执行，一切顺利，你就不需要回滚。但假设在部署后几小时（或几天），你需要回到之前提交或标记或任何地方。新的数据可能需要你手动切换回之前软件版本可控的内容。别想，别计划，这不太可能发生。如果发生了，你需要一个夜深人静的夜晚，埋头苦干才能完成。累感不爱。

9. 拒绝和团队高效地交流

现在你已经知道了，你要有可怕的日志和错误跟踪系统。雪上加霜的是不和同事进行快速、直接和清晰的交流。如果你的同事等待你的及时回复，你长时间不理他一定会有很戏剧性的效果。含糊地交代你在做的事情。点了回滚按钮，但不小心“忘记”告诉其他人。总而言之，越装傻越好。

只要你好好遵守上面的所有点，你就可以造成“完美的风暴”，如果你不遵守它们，你和你的团队就能更容易地完成任务。但即使你有很好的部署时间，有时候情况也会突变。永远会有盲点存在，它们多半是不可预知的。这就是软件开发会遇到的情况，从它我们可以得出获得糟糕部署的第10点，也是最后一点：

10. 如果所有事情都失败了，不要对你的同事有耐心，不要理解他们！

本文作者

是Guava的Ruby开发人员。

查看英文原文：

感谢对本文的审校。