新系统上线前，运维到底要规划什么？

上线不是把服务启动起来，而是把系统从“能用”推到“可控、可观测、可恢复”。

01 系统级别：先定义什么叫做上线成功

新系统上线前期，运维规划不能只盯着服务器、数据库和网络设备，而要先把系统当作一个整体来看。业务规模、峰值并发、数据增长、SLA/SLO、RTO/RPO、合规要求和预算边界，必须在上线前转化成明确的运维目标。

所谓系统级，不是“每台机器都活着”，而是用户完成一次业务操作的全链路是否稳定。入口、网关、应用、中间件、数据库、存储和外部依赖，任何一环出现瓶颈，最终都会表现为业务失败。

上线成功也不是“发布完成”。它至少意味着容量有余量、性能可预测、故障可发现、变更可回滚、数据可恢复、责任可追溯。没有这些前提，系统只是暂时能跑。

02 系统架构：所有风险都藏在依赖关系里

架构规划首先要梳理业务边界、服务拓扑、部署单元、同步与异步调用、数据流向、内外网边界和故障域。架构图、部署图、网络图、依赖清单和单点清单，必须在开发、运维、测试和安全之间形成同一份认知。

重点检查四个问题：某个节点故障时业务是否整体不可用？关键依赖超时后是否形成雪崩？数据一致性是否有明确策略？系统是否支持限流、熔断、隔离和降级？

高可用不是简单堆副本。横向扩展能力、无状态设计、会话处理、服务发现、流量调度、跨可用区部署和数据复制方式，都会决定系统遇到故障时能否真正切换。

03 性能：平均值不是峰值，吞吐量也不是全部

性能规划必须同时看吞吐、延迟、错误率和资源饱和度。平均响应时间没有太大意义，P95、P99、峰值 QPS/TPS、并发连接数和长时间运行后的性能衰减，才是用户真正感受到的风险。

压测不能只压应用接口。全链路压测要覆盖网关、应用、线程池、连接池、缓存、消息队列、数据库、存储和第三方接口，找出真正的瓶颈和最先被打满的资源。

上线前要预留容量余量，明确自动扩缩容规则、扩容上限和云资源配额，并通过长稳测试确认系统在持续高负载下不会出现内存泄漏、连接泄漏、队列堆积或数据库性能下降。

04 存储：容量只是最低要求

存储规划不只是买多大磁盘，还要区分块存储、文件存储、对象存储和本地存储的适用场景。容量、增长率、IOPS、吞吐量、访问延迟、快照能力和跨区复制，都要结合业务读写模型评估。

需要明确 RAID、多路径、LUN、文件系统、配额、扩容、分层、克隆、复制和生命周期策略。存储链路中的控制器、HBA、网卡、驱动和固件版本，也要纳入兼容性验证。

数据必须加密，访问必须受控，快照不能替代备份。对关键系统还要设计防勒索、不可变存储、离线副本和快速恢复能力，并持续监控容量、inode、坏盘、链路和复制状态。

05 操作系统：标准基线决定系统是否可控

操作系统要统一版本、补丁、许可和兼容性，建立标准镜像与安全加固基线。内核参数、文件句柄、进程数、资源限制、交换分区、时间同步、DNS、CA 证书、用户权限、SSH 策略和防火墙规则，都应在部署前固化。

驱动、多路径、系统代理、监控 Agent、日志轮转和崩溃转储不能等到故障时再补。补丁窗口、回滚方式、配置漂移检查和基线核查，也必须形成固定流程。

操作系统层面最怕“每台机器不一样”。一旦配置漂移失控，扩容、排障、灾备切换和故障复现都会变得不可预测。

06 数据库：业务数据的最后防线

数据库规划要覆盖版本、参数、存储引擎、容量、连接数、索引、慢查询、锁、事务和连接池。读写分离、主从复制、分片、分区和缓存策略，必须与业务一致性要求匹配。

高可用不能只看有没有从库，还要验证复制延迟、故障检测、自动切换、脑裂防护、数据补偿和回切流程。任何自动切换都必须经过演练，不能把生产故障当成第一次测试。

备份要覆盖全量、增量、日志和快照，并明确保留周期、加密、异地副本和恢复步骤。恢复演练必须验证整库、单表、单文件和 PITR，确认 RTO、RPO 及恢复后的数据一致性。数据库迁移、DDL、回填和对账，还要有顺序、校验和回退方案。

07 中间件：性能问题经常先在这里被放大

缓存、消息队列、API 网关、注册中心、配置中心、搜索、调度和分布式协调组件，都要明确集群拓扑、版本、参数、持久化、连接数、超时和故障转移策略。

缓存要关注命中率、热 Key、大 Key、穿透、雪崩、预热和一致性；消息队列要关注副本、堆积、死信、重放、顺序、幂等和消费能力；网关要关注路由、限流、熔断、证书和下游健康。

中间件缺的不是组件，而是边界。每个组件都必须说明能承受多大流量、故障后如何降级、数据是否需要持久化，以及恢复后如何补偿。

08 应用：把可控性做进代码和部署

应用层要规划副本数、部署拓扑、进程资源、配置注入和密钥管理。线程池、连接池、超时、重试、退避、熔断、隔离和优雅停机，决定了故障来临时系统会不会被拖垮。

健康检查、就绪探针、启动探针和流量排水要与负载均衡配合。批次任务、定时任务、分布式锁、幂等处理和第三方依赖降级，也必须有明确策略。

发布方式要支持灰度、蓝绿或滚动更新，并通过功能开关实现快速关闭。监控不能只看 CPU 和内存，还要看业务成功率、订单量、支付成功率、任务完成率和接口错误率。

09 容灾与备份：目标必须可验证、可演练

容灾先从 RTO 和 RPO 开始，而不是先选产品。节点、机架、可用区、地域、存储、网络、数据库、中间件、第三方依赖和人为误操作，都要纳入故障场景分析。

双活、主备、温备、冷备和备份恢复各有适用边界。关键在于数据如何复制、流量如何切换、故障如何检测、切换后如何回切，以及是否会出现脑裂和数据冲突。

备份要遵守分层保存、异地保存和恢复优先的原则。备份任务成功不等于数据可恢复，只有经过真实恢复演练、业务校验和定期复查的备份，才算有效备份。

10 可观测性、上线切换与护航

可观测性要统一日志、指标、链路追踪、事件和拨测。仪表盘覆盖入口流量、成功率、延迟、错误率、资源水位、队列堆积和依赖健康，每条告警都必须有负责人、处置手册和升级路径。

上线切换要有分钟级手册，明确数据迁移、并行验证、流量切换、DNS TTL、缓存预热、业务验证和检查点。回滚触发条件必须量化，例如错误率、延迟、数据差异或核心业务失败。

上线期间要设置指挥人、决策人、执行组和观察组。上线后进入护航期，重点观察 T+24 小时、T+72 小时、T+7 天和 T+30 天，只有达到退出标准，才能正式移交日常运维。

11 最后的系统级检查

如果上线前只能保留一页检查表，至少要能回答五个问题：系统由什么组成？峰值容量和瓶颈在哪里？异常发生时如何发现？变更失败后如何回滚？数据损坏或机房故障后如何恢复？

运维规划的价值，不是把文档写厚，而是把风险摊开。架构决定系统的上限，性能决定用户的第一感受，容灾和备份决定最坏情况下的生存能力，监控、值班和演练决定团队能否真正接住故障。

系统上线不是运维的终点，而是运维体系的第一次大考。