用Error Budget倒逼开发团队自律

高可用不是所有业务都能做到、也不是所有业务都需要做到的——一个反直觉但很现实的例子是，YouTube这么大量的视频，每个视频的每种格式其实只存了1份，可用性因此必然受影响，但因为数据量实在太大，各种冷门小视频也确实不那么重要；相比之下广告视频往往存了8份，因为这部分内容对商业价值更关键。这说明可用性投入本质上是一个业务优先级问题，而不是”技术能力够不够”的问题——想提高可用性，必须先和开发团队找到一个共同目标，因为高可用是有代价的，”你的业务需要做到什么程度”是一个系统性的权衡，不能只由运维团队单方面决定。落到具体机制上，这里有一个关键工具叫Error Budget（错误预算）：先和开发团队确定一个可用度目标（比如99%），如果业务团队开发的功能出现各种状况、最终达不到这个标准，那么规则就是——暂时不允许发新功能，团队只能专注修Bug，直到可用度重新回到预算范围内。这个机制的巧妙之处在于，它把”要不要为可用性负责”这个抽象的责任问题，转化成了一条具体、可执行、和团队切身利益直接挂钩的规则：可用性目标不再是运维部门单方面的诉求或KPI，而是变成了开发团队自己的”预算”——预算花超了（可用度不达标），发新功能这个开发团队真正在意的事情就会被暂停，这种利益绑定比任何口头强调”要重视可用性”都更有约束力，因为它让”稳定性”和”业务迭代速度”这两个经常互相竞争资源的目标，被绑定进了同一套激励机制里。