问题描述
许多团队都在努力通过当前主要是手动的手段捕获”部署失败”的指标，以证明DevOps，特别是部署自动化，如何降低变更失败率。然而，实际上很少会发生”失败”，因为当出现问题时，团队会聚集在一起（通常是通过英雄般的努力）来修复问题（通常是权限、配置缺失等问题）。因此，当询问部署情况时，通常得到的回答是”成功了”。
然而，直观上我们都知道这并不好。2017年的DevOps状况报告称，大约有31-45%的”变更失败率”。虽然这听起来似乎合理，但它们是否被跟踪为事故呢？不会。因为它们通常在验证过程中很快被修复。实际上，真正回滚一个部署是非常少见的。
因此，报告准确的失败率需要纪律。我们不愿意报告这样的数据，因为我们希望事情能够正常运行，并且会尽力让它变得如此。
那么，如何证明DevOps，特别是部署自动化，如何降低变更失败率呢？
解决方案
方案1：管理承诺与权限限制
一种在类似情况下的技术是获得”管理承诺”，并向每个团队成员施加以下规则：
1. 访问执行对目标部署区域（如生产环境）的更新的权限受限于选定的自动化系统。这些系统必须有适当的审计跟踪（即日志），记录管理的任何更新操作。
2. 不再允许典型的团队成员（用户ID）执行目标部署区域的手动更新。相反，将创建新的用户ID，这些用户ID将拥有执行此类手动更新所需的所有权限。但为了实际上能够使用这些新的用户ID（进行登录），想要使用新用户ID进行登录的团队成员必须执行”某些”额外的步骤以获取该用户ID的密码。理想情况下，这个额外的步骤也是自动化的（您可以自行设想其外观），但如果出现任何问题：只需与需要密码的门卫联系（通过电子邮件、电话等），包括”需要修复哪个问题”（类似于您的问题）。
3. 设立这样的门卫并不是一项容易的工作，最大的阻力将来自于团队成员（出于各种原因）。因此，在上一步中，这些新用户ID的一个变化是，每个团队成员都会获得额外的用户ID（以及他们自己决定的密码），但附加一个字符串：只有在他们实际上有充分理由这样做时，才允许使用这个额外的用户ID进行登录。每次他们执行这样的登录时，他们都需要提交关于”修复了哪个问题”的某种类型的报告。
通过这些步骤，只需要定期审查每个报告/使用特殊用户ID的原因，然后询问问题：”是否有任何方法可以进一步自动化这个过程，进一步减少需要使用特殊登录的需求？”。
方案2：实际可靠性与速度的权衡
事实上，一个被快速修复的问题仍然是一个问题。如果你没有将这些问题报告为问题，那就是一个问题。如果你的目标是让事情真正正常运行，那么你需要诚实地报告失败，以便能够在未来防止它们。这听起来像是团队在说谎（也许是对自己，肯定是对管理层）关于失败，因为他们的目标是事情看起来工作。
然而，实际上的目标应该是实际的可靠性，而不仅仅是表面上的可靠性。运维团队的目标应该是实际的可靠性，并且他们需要受到他们的管理层的相应激励。这意味着，如果他们加强了监控，导致发现新问题，导致可靠性指标的下降，他们应该得到奖励，而不是因为可靠性指标的下降而受到惩罚。
综上所述，如果你试图推动组织变革，那么你不应该试图证明任何事情，而应该提供其他组织关于他们自己转变的说法的证据。如果你试图衡量已经存在的流程并证明它们继续存在的合理性，那么你应该跟踪标准的可靠性指标，如修复时间均值（MTTR）。
然而，DevOps原则不仅仅是为了提高可靠性。甚至站点可靠性工程也不仅仅是为了提高可靠性。你的目标是实现合适的可靠性水平，即有利于业务但不会阻碍开发的水平。这意味着你需要测量可靠性，但