风险变更失三线拉扯
DevOps 与 SRE Risk (变更失) Trilemma
三个元素
1
变更失败率
变更失败率
2
可维护性
可维护性
3
可审计性
可审计性
详细描述
风险变更失三线拉扯把决策从“拍脑袋”拉回到“可解释”：为什么要舍变更失败率？为什么不能全都要？哪些场景可以放宽约束？不少团队会用分区/分层/分级把矛盾局部化。
三种情况说明
变更失败率无法满足时
把变更失败率放在次要位置时，最关键的是把影响写清楚：影响谁、影响多大、影响多久、以及如何补偿。这样三角才能变成可管理的工程问题。
可维护性无法满足时
把可维护性放在次要位置时，最关键的是把影响写清楚：影响谁、影响多大、影响多久、以及如何补偿。这样三角才能变成可管理的工程问题。
可审计性无法满足时
为了守住变更失败率和可维护性，可审计性可能被迫变成分层目标：关键路径严格、非关键路径放宽。这样能让代价可控，但要求口径一致、监控到位。
评论区 (0)
暂无评论