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