选择DevOps还是SRE

DevOps是人员、过程和产品的结合，使我们的最终用户能够持续地获得价值。

简单而直接，并清楚地表明我们需要解决整个系统。为了简洁起见，让我们看看这些部分在系统中的位置。以下是一些主要的主题。它绝不是详尽无遗的。

产品管理

关键在于改进我们如何交付产品。产品管理需要在球上。我们不能假设我们建造的东西是有价值的。我们需要做我们的研究，做出价值假设，并找到在小价值实验上尽快获得反馈的方法。每一次交付都是对价值和浪费努力的赌注，当我们输掉赌注时，更大的交付更昂贵。当我们试图发明一些我们希望有价值的新东西时，越小越好。

价值流

这就是我们组织团队的方式，而不仅仅是开发。我们有功能筒仓吗？传递某物需要多少切换或通信路径？每次切换都增加了等待时间，在等待时间中，工作处于空闲状态，直到它可以被排队的下一个人接收。阻碍事情发展的瓶颈在哪里？分析这些问题并对其进行重组，可以大大降低交付价值的成本。

安全

如果我们一直在努力为最终用户提供价值，如果它不安全，它有价值吗？安全性一直是DevOps的一部分。这不是一个新的学科。在DevOps中，我们需要“通过设计来确保安全”，而不是传统的手榴弹驱动的开发方法，即构建系统，然后试图在最后通过检查来确保安全。安全应该是一个通过工具和培训实现安全交付的平台，而不是警察调查“新软件犯罪”。

平台和基础设施

我们的DevOps团队负责300多个管道的配置！

DevOps不是一个团队或工作。参见上面的定义。平台和基础结构团队也是价值交付的推动者，应该致力于提供易于使用的自助服务解决方案，这样开发团队就不需要知道他们是如何工作的，他们只是工作。没有这一点，价值交付就会受到影响。

持续交付

它就在定义中，“价值的持续交付”。它甚至是敏捷宣言的首要原则。CD不是工具。CD使用工具来启用一个工作流，该工作流侧重于一个可重复的质量过程，可以在我们交付给最终用户之前可靠地给我们关于已知质量问题的反馈，并发现不可预见的质量问题。此工作流侧重于改进事情，以使交付更小，从而加速来自生产的反馈循环。这不是一种“把它扔过墙”的交付方式。它是一个质量倡议，使我们能够对功能、性能、安全性或任何其他质量问题做出快速反应。它还允许小批量，以实现更小的价值实验，减少风险和损失的大小。

SRE

同样，DevOps不是一项工作。DevOps是提高价值交付的整个运营模式。交付团队需要空中掩护，以确保他们能够专注于他们的质量过程，并且不受最后期限的压力而交付不稳定或不可用的功能。一个现场可靠性组织或类似的能力，能够独立地说，“在您稳定之前，我们将把运行监控责任交还给您”，这是重要的质量反压力，以防止在追求速度的过程中出现偏离轨道的情况。我们需要更小，更快，更稳定。如果不稳定，就不值钱。