Blameless DevOps 中的失败是一种特性

DevOps 只是价值流开发的另一个术语。价值流是什么意思？

价值是在我们与客户和利益相关者的互动过程中产生的。一旦我们进入价值流开发，我们很快就会意识到价值不是一个实体。价值不断变化。价值是一个过程。价值是一个流。

因此有了流这个术语。只有当价值是一个流时，它才是价值。而这种价值的流动就是我们所说的持续集成 (CI)。

我们如何创造价值？

无论我们多么仔细地定义价值，人们对价值的期望都会发生变化。因此，定义和创造价值的唯一现实方法是征求反馈。

但很明显，没有人主动提供反馈。人们都很忙。我们需要征求客户和利益相关者的反馈，但不知何故，他们总是有更紧迫的事情要做。即使我们发脾气并坚持让他们停止手头的工作，给我们提供急需的反馈，充其量我们也只能得到一些不温不火的评论。几乎没什么可参考的。人们都很忙。

我们慢慢了解到，征求反馈最有效的方式是失败。失败是让我们的客户和利益相关者放下一切，坐起来并注意的最可靠的方法。如果我们拒绝失败，我们将继续自信地沿着开发道路前进，但稍后才会发现我们走错了路。

敏捷 DevOps 文化是关于放弃这种傲慢的姿态，并采取谦逊的态度。我们承认我们并非无所不知，并且我们致力于以更谦逊的方式进行价值流工作。

尽快失败至关重要。这样，失败就不是关键性的；它是无害的，容易克服，容易修复。但我们需要反馈来了解如何修复它。最好的反馈是对失败的反应。

让我们用视觉方式来说明这种动态

图片来源

^{通过持续征求反馈的反馈循环创造价值}

该图说明了通过以持续不断的模式征求反馈来产生价值的动态。

失败在哪里？

在上述过程中，我们在哪里看到失败？是时候再画一张图了

图片来源

^{失败是推动价值流交付的核心驱动力。}

失败是中心舞台。没有失败，任何有用的事情都无法完成。由此，我们得出结论，失败是我们的朋友。

我们如何知道我们失败了？

在瀑布方法美好糟糕的旧时代，首要原则是“失败不是一种选择。” 我们在每一步都必须完全成功的压力下工作。我们竭尽全力避免获得任何反馈。反馈是为重大的大爆炸事件保留的；当我们都听到关于我们构建的系统有多么脱靶的评价时。

简而言之，这就是传统的学习我们失败的方式。随着敏捷和 DevOps 的出现，我们经历了文化转型，并拥抱了增量、迭代的开发流程。每次迭代都从一个小的失败开始，修复它，然后继续前进（小是这里的关键词）。但是我们如何知道我们是否失败了？

唯一确定的方法是进行可衡量的测试或目标。可衡量的测试将让我们知道我们是否以及如何失败。

既然我们已经奠定了基础，并揭示了 blameless、以失败为中心的文化的基本原理，那么本系列文章的下一篇将更详细地阐述如何迭代失败的尝试以满足可衡量的测试和目标。