在无责DevOps中，失败是一种特性

DevOps 只是价值流开发的另一种说法。价值流是什么意思？

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

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

我们如何产生价值？

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

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

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

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

尽早失败至关重要。这样，失败就不是致命的；它是无害的，容易克服，容易修复的。但是我们需要反馈来知道如何修复它。最好的反馈是对失败的反应。

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

图片来源：

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

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

失败在哪里 ？

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

图片来源：

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

失败是中心舞台。没有失败，就什么有用的事情都做不成。由此，我们得出结论，失败是我们的朋友。

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

在瀑布方法的好坏的旧时代，首要原则是“失败不是一种选择。” 我们在压力下工作，每一步都必须是完全合格的成功。我们竭尽全力避免获得任何反馈。反馈是为重要的“大爆炸”事件保留的；即当我们都听到我们构建的系统离目标有多远的时候。

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

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

既然我们已经奠定了基础并揭示了无责、以失败为中心的文化的基本原理，本系列中的下一篇文章将深入探讨如何迭代失败的尝试以满足可衡量的测试和目标。