DevOps之前的部署指标挑战

TL; DR，您如何证明开发人员（特别是部署自动化）提高变更失败率？

我们都在尝试使用当前（主要是手动）方法来获取有关“部署失败”的指标。不幸的是，很少发生“故障”，对吧？因为当出现问题时，团队会聚在一起（通常与英勇专家一起）来解决问题（通常是权限，错过的配置，您知道演练）。所以……当我们询问部署的进行方式时，答案是“有效”。

但是，直觉上我们都知道那不好。2017年devops状态报告说，大约有31-45％的“ 变更失败率”。虽然听起来很正确，但它们是否作为事件进行了跟踪？没事 因为它们通常在验证期间很快就被修复了。实际上回滚部署的情况要少得多。

因此，准确报告故障率需要纪律。我们没有动力进行这样的报告，因为我们希望事情能够正常进行，并且我们会尽一切努力实现这一目标。

那么，如何证明开发人员（特别是部署自动化）提高变更失败率？

（PS尝试使用“＃devops-capability-model”为它添加标签）

我们过去在类似情况下使用的一种技术是获得“管理承诺”，将这些规则强加给每个团队成员：

1. 执行对目标部署区域（即生产）的更新的权限仅限于所选的自动化系统，该系统具有对其所管理区域的任何类型的更新的适当审核记录（=日志记录）。

2. 出于某种原因，过去曾经能够（被授权）执行这些更新的典型团队成员（用户ID）不再允许对目标部署区域进行手动更新。而是将创建新的（附加的）用户ID，该ID将具有所有必要的权限，以便（仍然）在需要时执行此类手动更新。但是要真正能够使用这些新的用户ID（=用它们执行登录），想要使用这样的新用户ID进行登录的团队成员将必须执行“一些”额外步骤才能访问密码这样的新用户ID。理想情况下，此额外步骤也是自动执行的（使用您自己的想象力，看起来应该是怎样的），但是如果其他任何操作失败：只需联系（=电子邮件，致电等）所需密码的网守，包括“他们拥有哪些问题修复”

3. 要找到这样的网守并非易事。而最大的阻力来自……团队成员（出于各种原因）。因此，这些新用户ID的一种变体（如上一步中所述）是，每个团队成员都获得了一个额外的用户ID（使用他们自己决定的密码），但附加了一个附加的字符串：他们仅被允许执行如果确实有充分的理由，请使用该（额外的）用户ID登录。而且，他们每次执行此类登录时，都必须提交有关“他们修复了哪些问题”的某种类型的报告（类似于您的问题）。

有了这些步骤，剩下要做的就是定期查看每个报告/使用特殊用户ID的原因/原因，并提出问题“ 有什么办法可以进一步实现自动化，以便进一步减少了这种特殊登录的需要？ ”。

更新：

在此答案下方引用您的额外评论：

我认为为解决部署问题添加人为障碍会适得其反。

的确，它增加了一个额外的障碍，但我不认为这是“人为的”。据我所知，这是了解这些团队成员否则永远不会告诉您的事情的唯一方法，原因如下：

• 就业保障。
• 他们宁愿隐瞒坏事/做法。
• 他们不想失去权力。

2017年devops状况报告说，大约有31-45％的“变更失败率”。虽然听起来很直率，但它们是否作为事件进行了跟踪？没事 因为它们通常在验证期间很快就被修复了。

快速解决的问题仍然是一个问题。如果您没有这样报告，那就是一个问题。

因此，准确报告故障率需要纪律。我们没有动力进行这样的报告，因为我们希望事情能够正常进行，并且我们会尽一切努力实现这一目标。

如果您的目标实际上是使事情正常进行，那么您就必须诚实对待失败，以便将来能够预防失败。听起来这里的团队正在对失败撒谎（也许对他们自己，对管理人员当然），因为他们的目标是使事情看起来正常。

这些是不同的东西。例如，以一个古老的笑话说QA会产生错误-“我的代码很好，直到QA掌握了它，然后他们制造了所有这些错误！”。这些错误一直存在，但是开发人员对此一无所知。运营团队的目标应该是实际的可靠性，并且他们的管理也需要对此进行激励。这意味着，如果他们进行更多监控以发现新问题，则应该对他们进行奖励，而不是对随后可靠性指标的下降给予惩罚。

TL; DR，您如何证明开发人员（特别是部署自动化）提高变更失败率？

如果您想激励组织中的变革，那么您不应该试图证明任何事情，而应提供其他组织对自己的过渡有何评价的证据。如果您要衡量已经存在的流程并证明其继续存在的合理性，则应该跟踪标准可靠性指标，例如平均维修时间（MTTR）。

但是，发展原则不仅涉及提高可靠性。甚至站点可靠性工程也不仅仅是增加可靠性。相反，您希望达到适当的可靠性水平，这对业务有益，但又不妨碍开发。这就激发了发展的真正动力，那就是促成变革。您想让企业对市场刺激做出更快的响应，这可以通过减少开发人员之间的摩擦，提高部署速度，自动化手动流程等方式实现，同时又要保持在可接受的可靠性范围内。这意味着您需要测量可靠性，但同时也需要测量速度，因为您的目标是在提高速度的同时保持前者相对静态。