DevOps之前的部署指标挑战
TL; DR,您如何证明开发人员(特别是部署自动化)提高变更失败率? 我们都在尝试使用当前(主要是手动)方法来获取有关“部署失败”的指标。不幸的是,很少发生“故障”,对吧?因为当出现问题时,团队会聚在一起(通常与英勇专家一起)来解决问题(通常是权限,错过的配置,您知道演练)。所以……当我们询问部署的进行方式时,答案是“有效”。 但是,直觉上我们都知道那不好。2017年devops状态报告说,大约有31-45%的“ 变更失败率”。虽然听起来很正确,但它们是否作为事件进行了跟踪?没事 因为它们通常在验证期间很快就被修复了。实际上回滚部署的情况要少得多。 因此,准确报告故障率需要纪律。我们没有动力进行这样的报告,因为我们希望事情能够正常进行,并且我们会尽一切努力实现这一目标。 那么,如何证明开发人员(特别是部署自动化)提高变更失败率? (PS尝试使用“#devops-capability-model”为它添加标签)