打破贝特里奇标题定律，简短的回答是肯定的。但如今凡是涉及技术的问题，详细答案都要复杂一些。
我认为，DevOps已在各行各业得到相当广泛的应用。虽然并非每个组织都会采用这种方法的方方面面，也不会像Netflix那样积极践行其原则，但DevOps无疑已成为一种趋势。
虽然这并非直接证据，但在《2018 年应用交付现状》调查中，当我们询问3,000多名受访者数字化转型如何影响其应用决策时，排名前三的回答中有两项是“在IT系统和流程中采用自动化和编排”以及“改变应用开发方式（例如转向敏捷开发）”。在我看来，这两项都可以视为采用部分DevOps方法，在现代架构中开发和交付应用所带来的反应。
因此，如果组织正在采用一些与DevOps相关的工具和技术，或许可以推测，它们也在采用其他工具和技术。其中甚至可能包括（此处响起戏剧性音乐）：以故障为前提进行构建。
不过，这种说法不太准确，因为没有人会专门设计注定发生故障的系统。实际上，人们设计的是能够从故障中恢复的系统。例如，如果某个实例（服务器）崩溃，系统应能自动处理这种情况，移除已失效的实例，并启动一个新实例来替代它。
瞧！这就是“为故障而设计”。
虽然这无疑是理想的响应方式，尤其是在系统承受高负载和高需求时，但这种方法也存在需要考虑并有望随后解决的风险。
以2017年初的Cloudflare漏洞为例。Cloudflare在自身发布的问题报告中保持了值得肯定的透明度。该公司指出，问题本质上是HTTP解析器扩展中的缺陷引发内存泄漏（可能导致数据泄露）。简而言之，缺陷导致内存泄漏，进而造成实例崩溃。由于系统采用容错设计，这些实例随后被终止并重启。
需要说明的是，这篇文章并不是要“因为一个漏洞而抨击Cloudflare”。作为开发者，我非常理解自身缺陷被如此公开曝光的处境。但如果有人不重视查明系统崩溃、内存泄漏或彻底失效的原因，我就不太能理解了。
这正是今天这篇文章要讨论的重点。因为有时，DevOps理念会让其拥护者对故障后的调查采取放任态度。
服务或应用发生故障时，为确保可用性而终止并重启服务是完全合理的，前提是随后要调查崩溃原因。应用不会无缘无故崩溃；一旦崩溃，必有诱因。十有八九只是无法被利用的错误，没什么值得专门写篇博客。但只要有一次是尚未被利用的严重漏洞，就值得为此投入精力，即使另外九次看似白费功夫。因为这种情况确实值得写篇博客。
忽视这一问题并不可取。
对故障及其他问题进行监控和告警，也是完善DevOps体系的关键组成部分。这正是构成整体DevOps方法的CAMS中的“S”：文化、自动化、度量和共享。Damon和John（两人于2010年提出了这一缩写）所说的不只是披萨和啤酒（不过，这确实有助于促进DevOps文化，也就是其中的“C”）。共享还涉及数据和系统状态，旨在确保能从相关信息中受益的人员及时知情，其中也包括系统故障信息。
故障，尤其是崩溃，不应无人过问。如果流水线中的系统崩溃，应有人知晓并进行检查。忽视此类故障会带来安全风险。更糟的是，这种风险本可避免，因为相关环境、系统和代码均由您掌控。既然拥有完全控制权，就没有理由置之不理。
简而言之，“为故障而构建”可能会使应用乃至业务面临安全风险。好消息是，只要确保这一理念不只是纸面上的“为故障而构建”，实际执行时也不会变成“构建后却忽略故障”，这些风险就完全可以管控。
请关注发生崩溃的系统，即使为了保持高可用性而将其重启，也不能忽视。这样或许能避免您和企业因负面事件登上Twitter热搜。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。