可靠性正在减慢您的速度

三个铁的事实

首先，软件系统的复杂性达到了顶峰，并且您拥有比以往更多的外部依赖项。在 51 年接受 SolarWinds 调查的 IT 专业人员中，有 2021% 的人选择 IT 复杂性作为其组织面临的首要问题。

其次，您必须比竞争对手更快地交付，这越来越困难，因为更多的开源和可重用工具可以让小团队行动得非常快。在RedHat调查的950名IT专业人士中，只有1%的人表示开源软件“一点也不重要”。

第三，可靠性正在减慢你的速度。

可靠性/速度的权衡

在过去，我们可以在发布之前测试软件以确保它是好的。我们运行了单元测试，确保 QA 团队查看了一下，然后我们会在计划的维护窗口内仔细推送软件更新，再次测试它，并希望能回到我们的周末。按照 2023 年的标准，这是一个懒惰的步伐！我们希望团队通过最少的专用手动测试不断推送新更新（即使在周五）。他们必须跟上安全补丁，发布最新功能，并确保错误修复流向生产环境。

挑战在于，更快地推送软件会增加出错的风险。如果您采用旧的软件交付方法并加快速度，那么您无疑总是会破坏版本。为了解决这个问题，现代工具和云原生基础架构使交付软件更加可靠和安全，同时减少了手动发布的工作量。

根据 2021 年 DevOps 现状报告，超过 74% 的受访组织的变更失败率 （CFR） 高于 16%。对于寻求加快软件更改速度的组织（请参阅 DORA 指标），其中许多更新导致了需要额外修复（如修补程序或回滚）的问题。

如果您的团队没有投资于提高软件交付工具的可靠性，您将无法快速实现可靠的发布。在当今世界，所有基础结构（包括开发/测试基础结构）都是生产环境的一部分。

要走得快，你还必须安全走。更多微小的增量更改、自动发布和回滚过程、高质量指标和明确定义的可靠性目标使快速可靠的软件发布成为可能。

定义可靠性

通过明确定义的目标，您将知道您的系统是否足够可靠以满足期望。上涨或下跌意味着什么？您在全球云中部署了数十万个服务，并且不断变化。开发人员不再协调发布和推送软件。依赖项因意外原因中断。安全修复迫使团队匆忙更新到生产环境，以避免代价高昂的数据泄露和网络安全威胁。

您需要一种结构化的解释性语言来编码您对系统的期望和限制以及自动纠正措施。今天，定义在代码中。任何不足的东西都是不确定的。另一种方法是手动干预，这会减慢您的速度。

如果您不断尝试找出损坏的内容并修复已经推出的版本，则无法致力于提供新功能。组织中最宝贵的资源是注意力，而创造更多资源的唯一方法是减少干扰。

可靠地加速

服务级别目标 （SLO） 是精确定义的可靠性目标。SLO 包括指向数据源的指针，通常是针对监视或可观测性系统的查询。它们还具有定义的阈值和目标，可在任何给定时间明确定义通过或失败。SLO 包括一个时间窗口（滚动或日历对齐），用于根据预算计算错误。OpenSLO 是用于声明可靠性目标的现代事实标准。

使用 SLO 来描述跨服务的可靠性目标后，情况就会发生变化。虽然 SLO 不会直接提高可靠性，但它们揭示了期望与现实之间的脱节。简单地澄清和发布你的目标有很大的力量。曾经粗略的共同理解变得明确定义。我们可以讨论 SLO，并决定使用提交历史记录中的书面记录提高、降低、重新定义、拆分、组合和修改它。我们可以从失败中学习，也可以从成功中学习。

无论你进行什么其他投资，SLO 都可以帮助你衡量和改进服务。可靠性是经过设计的;如果不了解系统的要求和限制，就无法设计系统。SLO 即代码定义了跨团队、公司、实现、云、语言等的一致可靠性。