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