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