Web服务24小时365天不停机，什么时候成了默认前提？这个问题值得拆开看：常驻在线带来的收益，是否抵得上它对应的安全代价。计划停机在技术上完全可以是一个有效选项，日常演练恢复流程本身也有价值，运维人员的负荷、为无停机付出的复杂度，同样不能忽略。
但现场团队没法自己拍板"这个服务定期停"。一停，用户的操作会中断，营收和业务可能受影响。最终要回答的，是这项服务需要多高的可用性——依据是业务价值与风险，而不是习惯。
可用性不是越高越好
把可用性目标定高，是有成本的：额外的基础设施、运维自动化、验证环境、复杂的切换步骤、为维护增加的额外工作。这笔钱花得值不值，因服务而异。
紧急时刻也必须能用的服务，和用户等到第二天早上也无妨的内部服务，对停机的容忍度完全不同。在线销售类服务同样要比较：无法接单那段时间的损失，与遭遇严重入侵时的损失，哪个更重。
按时间简单折算，年可用性99.9%约等于8小时46分的停机，99.99%约等于53分。这是把计划停机也计入停机时间的前提下的概算；实际SLA里，计划维护有时不计入可用率。只看合同上的数字，不单独掌握用户实际无法使用的时间，服务的真实状况就会失真。
谷歌SRE的思路也是如此：可用性不该无限拔高，而应匹配服务目的与业务可承受的风险。目标越高，能用于其他改进的费用和时间就越少。所以"所有服务都做到99.9%"是错的，"所有服务都做到99.99%以上"同样是错的。要想的是这项服务需要什么水平。
定维护窗口，先过五道问
管理层、服务负责人和运维团队，至少要一起过一遍下面五个问题：
- 停机影响谁、影响什么。用户能否避开停机时段、有没有替代手段、业务中断的损失有多大。影响大的话，考虑非全面停机的方式。
- 更新和修复要多快落地。重大漏洞公开时，未必能等到下一个定期维护。紧急更新的判断标准和执行权限要事先定好，必要时不等常规维护日程。
- 有没有停机之外的选项。分批更新、利用冗余架构、只停部分功能，这些方案要比较。哪个最优取决于系统结构与服务要求。
- 总成本差多少。不只看基础设施费用，还要比开发、验证、运维投入的时间，夜间响应，停机造成的损失，以及故障或入侵后的恢复费用。计划停机不一定更便宜，但把为无停机支付的费用看清楚是有意义的。
- 恢复能力验证过没有。启动步骤能不能跑通、能否从可信状态重建环境、备份能否还原、恢复后的数据能否核对，都要测。测出的问题和整改情况要记录。
对客户的承诺，不能只剩一个数字
把维护窗口纳入日常运营，就要明确告诉用户：什么时候、哪些功能会不可用。SLA和使用条款里怎么处理维护时间，也要结合服务性质和合同理清。
但把计划停机从可用率计算里剔除，并不会自动换来客户信任。用户实际受到的影响、通知方式、停机时长、以及计划外停机时的说明，透明才是关键。
要讲给客户的，不能只有"为了安全所以停"这一句。为什么需要这段维护时间、对用户有什么影响、如何确认恢复，都要讲清楚。管理层也不能只对现场喊"绝对不许停"，而要给出能执行必要维护和紧急响应的判断标准与权限；现场同样不能只用技术术语解释停机必要性，而要换算成业务影响、风险、费用和替代方案。
计划停机的目的不是给停机找理由，而是在守住业务所需可用性的同时，建立能确实完成更新与恢复的运营方式。
要守的不只是那个可用率数字
24/365并非对所有服务都过度。停机影响极大、高可用本身就是业务要求时，为此投入是合理的。
反过来，必要性没弄清就追高可用，压缩维护与更新的余地，把复杂度和运维负荷越堆越高，这种方针就值得重新审视。计划停机不是万能的 security 措施，但"需要时能安全停下、验证、恢复"的设计，会增加组织的选择空间。
真正要回答的从来不是"停还是不停"的二选一，而是这份可用性换来的价值，是否真的对得起额外费用、复杂度、安全约束和运维人员的负荷。把及时完成必要更新、能回到可信环境、以及承担这些的人能可持续地运维，一并纳入判断，24/365才会从惯例变成符合目的的选择。
热门跟贴