“糟糕，我破坏了生产”——我们如何确保不再发生这种情况？

实施变革

开始之前，我正在开发https://cloudash.dev，这是一种监控无服务器应用的全新方式🚀。如果你在调试生产事件时厌倦了在 50 个 CloudWatch 选项卡之间切换，可以看看这个。

让我先讲一个故事。

假设你是一名开发人员（如果你正在阅读这篇文章，很有可能），刚刚将这段代码推送到master（希望这一部分不适用于你们中的许多人）：

ReactDOM.render(<OurEntireFrontend />, document.getElementById('ro git pushot'));

（如果您不熟悉 React，重点是我们正尝试在 id 为 的元素中呈现应用程序#root）。

如你所见，当你尝试将更改推送到 时master，焦点放错了地方，git push你没有在终端中写入，而是在代码库中写入。结果显而易见——整个页面都崩溃了，这可不是你职业生涯中最美好的一天。

如果您认为显然没有人会这样做，那么我将类似的东西推送到了远程分支。

今天。

（虽然没有破坏产品，但请继续阅读以了解为什么这是不可能的）

你开始怀疑——“我被解雇了吗？ ”。

不。

我们每个人都会遇到倒霉事，即使是最优秀的人也会遇到。NASA、亚马逊、推特、脸书——随便列举几个公司，如果你深入挖掘，都会发现无数关于他们生产事故的故事。

作为开发人员，这不是你的错，而是你所操作的系统有问题（我不是指 Windows！）。

愿意学习和成长的工程团队与不愿意学习和成长的工程团队的区别在于你对这些事件的反应（尽管你不必使用 React）。

指责

您可能想知道为什么我决定将“您”而不是 Sally、Joe、Samuel 或 Katarzyna 称为编写错误代码的人。

原因很简单——我们根据他人的行为来评判他人，根据自己的意图来评判自己。

如果是别人犯了错，就很容易把责任推到别人身上。如果他们来自不同的团队、组织或公司，那就更容易了。部落主义是一种极其强大的机制，很难挑战这种偏见。

指责毫无意义。

你唯一能得到的就是一个压力重重、精疲力竭的人，他会知道，在面临巨大压力和危险的时候，所有的错误都是他们自己的。

生产环境的崩溃从来不是一个人的错（除非你真的独自工作）。

换句话说 - 成熟的团队可以确保损坏真正支付他们薪水的产品几乎是不可能的。

塔防

还记得那些老式 Flash 游戏吗？游戏中你必须建造塔楼才能阻止入侵者大军？（对于年轻的读者来说，Flash 是有史以来最好的游戏，我们仍在追赶它）

优秀的工程团队每天都会做类似的事情——在代码库中构建稳定的塔。

让我们来谈谈为什么不可能document.getElementById('ro git pushot')向实际用户发布，在这种情况下我们的“塔”将是：

仔细检查即将推送到存储库的提交

我从来没有这样做过，所以我们直接进入下一个

自动化 linter

代码 Linter 应该能够捕获可能破坏代码的奇怪问题。为你选择的编程语言添加 Linter 只需很短的时间，没有理由不这样做（除非你采用了一套过于严格的规则）。

好吧，如果失败了：

代码审查

让（至少）第二个人来检查你的代码是至关重要的，这种问题很可能会被另一个人发现。

如果失败：

单元测试

一个问题如此严重的应用不应该通过单元测试。如果通过了——那说明你已经确定了你的问题（或者至少确定了一个）。像启动应用这样的主要核心流程应该完全通过单元测试。

这或许会引发争议，但开发一款非同寻常的产品却说“我没时间测试”，就像麦当劳说他们没时间做面包，因为他们要运肉一样。没错，我愿意为之付出生命。

假设你的测试通过了，但代码有问题，而且这座塔倒塌了：

端到端测试

这些测试操作级别更高，直接与 UI 交互。如果没有 UI（因为应用完全崩溃了），那么这些测试就会立即失效。

你需要聘请自动化测试工程师来做这件事吗？当然不需要。用 cypress.io 编写一个简单的冒烟测试来检查你的应用是否正常运行（这可能对你有用），你完全可以自己尝试一下。即使是一个简单的自动化测试，也能让你对你的软件更有信心。

但也许你不相信，这座塔失败了：

暂存环境

有些团队/公司有这个，有些没有。我不知道你的基础设施成本，所以不会在这部分花太多时间，但如果你能负担得起，在生产之前建立一个封闭的环境，让它彻底清理干净，通常是一个好主意。（如果你有一个持续交付流程，这显然不适用。）

好的，但是如果没有人注意到暂存已损坏怎么办？

监控

人都会犯错，没有人是完美的。

团队成员不应该被要求每 5 分钟刷新一次暂存环境来了解是否有问题（尽管如果你的提交/功能进入暂存状态，强烈建议至少进行最后一次查看）。

假设某个东西随时都可能出问题（它肯定会出），并让机器在用户之前告诉你软件出了问题。对于用户抱怨无法登录，最好的回应是“我们知道，自从监控告诉我们这个问题以来，我们的工程师一直在努力修复。修复程序将在 5 分钟内部署”。

监控听起来很可怕而且很复杂，但其实不必如此，就我而言，我用过New Relic Synthetics，可以推荐，因为它不是太复杂。

好吧，如果我的监控对我大喊怎么办？

回滚

再说一次，人都会犯错。错误的代码最终会被部署。

一个很好的衡量标准是——我能多快摆脱错误的代码？

将修复程序推送到生产需要多少分钟或几小时（如果真的是几小时 -运行，我们正在招聘）？

交付可靠的软件不仅关乎弹性、质量、检查和测试，还关乎您的团队对需要快速行动的情况做出反应的能力。

实施变革

如果你的团队已经落实了所有这些流程，那么你的状况就很好了。当然，你仍然会遇到生产事故，但这种情况会少得多。

您如何在软件工程过程中实现这些（以及许多其他 - 这绝不是一个完整的列表）实践？

程序分为两个步骤：

• 搭腔
• 从错误中学习

每次事故发生后，大家聚集在一个房间里，试图弄清楚发生了什么，我们的流程中哪个部分出了问题（再次强调，是流程，而不是人），最重要的是，我们如何确保它不再发生。

最后一部分并不容易，但五个为什么至少让它变得容易理解。

优秀的团队不会过多考虑过去，他们考虑的是未来，未来事故会越来越少。

如果你穿衬衫，你可能见过这样一条提示：穿着衬衫时不要熨烫。我是说——谁会这么做呢？！

嗯，人们确实这么做了，所以它就在那里。每个奇怪的规则和警告标志背后都有一个故事。

每一个最佳实践的背后都有一个产品损坏、压力和团队通宵工作试图修复错误的故事。

因此 - 与您的团队会面，在无责备的氛围中进行讨论，弄清楚您可以做些什么来确保这种情况不再发生，最重要的是：

分享

如果你的公司愿意公开分享这样的故事（或者他们有法律义务这样做），这对其他人来说绝对是一个很好的教训。如果不能公开，那么我认为与其他团队分享经验教训是绝对必要的。

不要让别人像你一样受苦，分享最佳实践并相互借鉴。

附言：编写测试