失败。
这是一个带有负面色彩的词语。在工程和建筑项目中，它让人联想到泰坦尼克号沉没、塔科马海峡吊桥在风中扭曲或挑战者号航天飞机爆炸。这些都是工程设计或管理上的失败。
纯软件领域的多数失败不会像上述事件那样产生直观的画面，但它们同样可能造成广泛的经济和人力成本。想想 Healthcare.gov 网站启动失败事件、塔吉特公司数据泄露事件，或者实际上任何最终基本上没有奏效的数百万美元项目。2012 年，美国空军在花费了 10 亿美元后放弃了一个大型 ERP 项目。
在这些案例中，互相指责是很常见的。即使当大多数相关人员没有像泰坦尼克号事件中那样真正与船同沉时，人们也会被解雇，职业生涯会被缩短，互联网也会对个人和组织机构进行无情的嘲讽。
但是，我们如何将这种情况与 DevOps 文化中经常出现的拥抱失败的告诫 相协调呢？如果我们应该拥抱失败，又怎能惩罚失败呢？
有效失败
并非所有失败都是一样的。理解不同类型的失败，并构建环境和流程以最大限度地减少不良类型的失败，是成功的关键。正如梅根·麦卡德尔在《The Up Side of Down》一书中所写的那样，关键在于“有效失败”。
在那本书中，梅根描述了 棉花糖挑战，这是一个最初由 Palm 前设计副总裁彼得·斯基尔曼构思的实验。在这个挑战中，小组会收到 20 根意大利面条、一码长的胶带、一码长的细绳和一个棉花糖。他们的目标是建造一个结构，使棉花糖离地，尽可能地高。
斯基尔曼对从商学院学生到工程师再到幼儿园小朋友等各类参与者进行了这项实验。商学院学生的表现最差。我曾经是一名商学院学生，这并不让我感到惊讶。根据斯基尔曼的说法，他们花了太多时间争论谁将成为 Spaghetti, Inc. 的首席执行官。工程师的表现不错，但也没有名列前茅。作为一名也拥有工程学位并参与过类似练习的人，我怀疑他们花了太多时间争论要采取的最佳结构设计方法。
相比之下，幼儿园小朋友没有坐下来讨论问题。他们只是开始搭建，以确定哪些有效，哪些无效。而且他们做得最好。
建立一个允许和鼓励此类实验的系统和环境，可以在敏捷软件开发中实现成功的失败。这并不意味着没有人为失败负责。事实上，它使问责制更容易，因为“负责”不必等同于“造成了灾难”。在这方面，它改变了问责制的性质。
为问责制而设计
当我们考虑这样一个系统时，我们应该考虑五个原则：范围、方法、工作流程、激励机制和文化。
范围
正确的范围是限制失败的影响并阻止其他失败的连锁反应。这对于鼓励实验至关重要，因为它最大限度地减少了失败的影响。（而且，如果您没有失败，您就没有进行实验。）一般来说，您希望将活动和决策彼此分离。从 DevOps 的角度来看，这意味着使部署成为增量式、频繁和例行的事件，部分是通过部署小型、自主和有界上下文的服务（即微服务或类似模式）。
方法
正确的方法是不断地试验、迭代和改进。这是 DevOps 和敏捷开发从 丰田生产系统 的 kaizen（持续改进）和其他制造先例中带来的理念。最有效的流程具有持续的沟通——想想 scrum 和看板——并允许协作，从而可以在失败发生之前识别出来。与此同时，当失败确实发生时，该流程允许反馈，以持续改进和培养持续学习。
工作流程
正确的工作流程会反复自动化以保持一致性，从而减少因不可避免的偶然错误（例如 命令输入错误）而导致的失败次数。这使得人们可以更加关注设计错误和其他系统性失败原因。在 DevOps 中，这在很大程度上采取持续集成/持续交付 (CI/CD) 工作流程的形式，该工作流程使用监控、反馈循环和自动化测试套件来尽可能在流程的早期阶段发现失败。
激励机制
正确的激励机制使奖励和行为与期望的结果保持一致。激励机制（例如晋升、金钱、认可）需要奖励信任、合作和创新。关键是个体能够掌控自己的成功。在这里，可能需要指出的是，失败并不总是一个积极的结果。特别是当失败是反复不遵循既定流程和设计规则的结果时，行动仍然会产生后果。
文化
正确的文化至少在一定程度上是关于建立允许有效失败的组织和系统，从而使该框架内的问责制成为一种积极的属性，而不是指责游戏的一部分。这需要透明度。这也需要理解，即使是好的决策也可能产生不好的结果。一项技术没有按预期发展。市场发生转变。一种架构方法被证明无法扩展。事情就是会发生。创新本质上是冒险的。及时止损，继续前进，避免沉没成本谬误。
在敏捷 IT 中正确处理问责制和失败确实需要适当的架构、工具和流程到位。在脆弱的单体应用程序上进行低影响的实验将很困难，并且很难避免代价高昂的失败和随之而来的指责。然而，组织文化仍然起着举足轻重的作用。传奇管理顾问彼得·德鲁克曾经说过一句名言：“文化可以把战略当早餐吃掉。” 文化对软件开发过程的许多方面也有类似的胃口。
本文是 《开放组织 IT 文化变革指南》 的一部分。
5 条评论