DevOps“注定失败”的理念是否存在安全风险？

打破贝特里奇的头条新闻定律，简短的回答是肯定的。 但正如当今所有涉及技术的事物一样，长远的答案要比这更复杂一些。

我认为，DevOps 已在所有行业中变得相当普及。 虽然并非每个组织都采用该方法的各个方面，或像 Netflix 那样热衷于遵守其原则，但这无疑是正在发生的“事情”。

虽然不是直接的证明点，但当我们向 3000 多名受访者询问数字化转型如何影响他们在 2018 年应用交付状况中的应用决策时，排名前三的答案中有两个是“将自动化和编排应用于 IT 系统和流程”和“改变我们开发应用s的方式（例如，转向敏捷）”。 对我来说，两者都是对采用至少部分 DevOps 方法在现代架构中开发和交付应用s的推断反应。

因此，如果组织采用了一些与 DevOps 相关的工具和技术，人们可能会认为他们也在采用其他工具和技术。 其中之一甚至可能是（提示戏剧性音乐）：建筑物倒塌。

现在，这个说法有点不准确，因为没有人会坐下来设计失败的系统。 然而，他们所做的是设计能够抵御故障的系统。 这意味着，例如，如果一个实例（服务器）崩溃，系统应该能够自动处理这种情况，通过删除死实例并启动一个新的实例来代替它。

瞧！ 注定会失败。

虽然这无疑是一种理想的反应——特别是当系统负载和需求都很重时——但这种方法也存在风险，需要加以考虑，并希望随后得到解决。

考虑一下2017 年初的 Cloudflare 漏洞。 Cloudflare 在报告该问题时表现得十分透明，它指出，该问题基本上是由于 HTTP 解析器扩展中的缺陷而导致的内存泄漏（从而导致潜在的数据泄漏）。 长话短说，错误导致内存泄漏，从而导致实例崩溃。 这些实例被终止并重新启动，因为它们注定会失败。    

需要说明的是，这不是一篇“批评 Cloudflare 存在漏洞”的帖子。 作为一名开发人员，我对于自己的缺陷被如此公开地暴露深表同情。 在很少考虑发现某些系统崩溃、内存泄漏或彻底失败的原因的情况下，我不会那么同情。

这就是今天这篇文章的重点。 因为有时 DevOps 理念会让其追随者采取自由放任的态度来进行故障后调查。

通过终止并重新启动服务来确保可用性来对服务/应用程序故障做出反应是完全合理的 - 只要您调查崩溃以确定导致崩溃的原因。 应用程序不会无缘无故崩溃。 如果它倒了，那一定是有什么东西推了它。 十有八九，这就像一个不可利用的错误。 没什么可写的博客文章。 但有一次，它出现了一个等待被利用的严重漏洞，这使得在其他九次漏洞上浪费的努力变得值得。 因为这是值得写一篇博客文章的内容。

忽视它是不合理的。

对故障和其他问题的监控和警报也是完善的 DevOps 程序的一个关键组成部分。 这就是 CAMS 中的“S”，它构成了整体 DevOps 方法： 文化、自动化、测量和共享。 达蒙和约翰（2010 年创造了这个首字母缩略词）不仅仅是在谈论披萨和啤酒（尽管这是鼓励 DevOps 文化的“C”的好方法）。 它还与数据和系统状态有关。 这是为了确保那些能够从了解中受益的人能够了解。 其中包括系统故障。

故障（尤其是崩溃）不应被忽视。 如果管道中的系统崩溃了，就应该有人知道并且有人去检查。 忽视它会带来安全风险。 更糟糕的是，这是一种可以避免的风险，因为它是您的环境、您的系统和您的代码。 您拥有完全的控制权，因此没有理由忽略它。

所以，简而言之，“构建失败”可能会使您的应用程序和业务面临安全风险。 好消息是，这些风险是完全可控的，只要你确保理念不是在纸面上是‘注定失败’，而在实践中却是‘为忽视失败而构建’。

注意崩溃的事情——即使重新启动它们也能够保持高可用性。 您可以避免自己（和您的企业）因各种错误原因而成为 Twitter 上的热门话题。