DevOps之前的部署指标挑战

#1 楼

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


访问权限以对目标部署区域执行更新（例如生产）仅限于选定的自动化系统，该系统对他们管理的区域进行任何类型的更新都具有适当的审核跟踪（=日志记录）。
出于任何原因，不再允许对目标部署区域进行手动更新由过去能够（授权）执行这些更新的典型团队成员（用户ID）提供。而是将创建新的（附加的）用户ID，该ID将具有所有必要的权限，以便（仍然）在需要时执行此类手动更新。但是要真正能够使用这些新的用户ID（=用它们执行登录），想要使用这种新的用户ID进行登录的团队成员将必须执行“一些”额外的步骤才能访问密码这样的新用户ID。理想情况下，此额外步骤也是自动执行的（使用您自己的想象力，它应该是什么样子），但是如果其他任何操作失败：只需联系（=电子邮件，致电等）所需密码的网守，包括“他们拥有哪些问题要修复”（类似于您的问题）。
找到这样的网守并不是一件容易的事。而最大的阻力来自……团队成员（出于各种原因）。因此，这些新用户ID的一种变体（如上一步中所述）是，每个团队成员都获得了一个额外的用户ID（使用他们自己决定的密码），但是附加了一个附加的字符串：他们仅被允许执行如果确实有充分的理由，请使用该（额外的）用户ID登录。而且，他们每次执行此类登录时，都必须提交有关“已解决的问题”的某种类型的报告（类似于您的问题）。

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

更新：

从您的额外评论中引用以下答案：


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


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


工作安全。
他们更喜欢隐藏坏事/习俗。
他们不想失去力量。

#2 楼

2017年devops状态报告指出，“变更失败率”约为31-45％。虽然听起来很直率，但它们是否作为事件进行了跟踪？没事因为通常在验证过程中它们很快就可以解决。


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


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


如果您的目标实际上是使事情起作用，那么您需要老实说失败，所以您将来可以防止失败。听起来这里的团队正在对失败撒谎（也许对他们自己，对管理人员而言），因为他们的目标是使事情看起来正常。

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




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


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

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