云服务器运维

1 云服务器运维要守住哪些状态

零售订单 API 的上线截图只能说明某个时刻请求成功。真正的运维问题发生在之后：晚间促销流量上涨，证书即将过期，磁盘被日志写满，某台实例重启后服务没有自动启动。顾客看到的是下单转圈、重复扣库存或支付状态迟迟不更新。方案如果只列出服务器规格、操作系统和部署地址，就没有回答服务怎样持续工作，以及出问题后怎样恢复。

云服务器是可以通过控制面创建、配置和删除的计算资源。控制面负责管理资源，数据面负责实际处理订单请求。实例显示“运行中”，通常只说明虚拟机已经启动，不能证明订单应用、数据库连接和库存接口都健康。运维要把资源状态翻译成业务结果：顾客能否提交订单，订单能否落库，故障时是否避免重复创建，恢复后能否查清受影响的请求。

设想商店平时收到每秒 120 次下单请求，大促时预计达到每秒 600 次。把实例从 2 台增加到 6 台只是准备工作。若每台应用都建立 100 个数据库连接，扩容后可能先压垮数据库；若初始化需要 8 分钟，告警后才创建实例可能赶不上突发流量；若订单文件留在本地磁盘，替换实例又可能带走证据。资源数量必须与应用状态、依赖容量和恢复流程共同设计。

单独谈运维，是为了明确服务目标、责任人、变更方法和故障处置证据。可用性目标可以约定为月度成功率达到 99.9%，但统计口径要说明是否包含维护窗口，以及哪些业务拒绝属于正常结果。库存不足是业务结果，服务器异常导致的提交失败是服务故障。没有统一口径，团队可能同时声称“系统正常”和“顾客无法下单”，却无法判断该采取什么行动。

2 补丁、镜像与变更窗口

首先区分实例、操作系统、进程和服务。实例提供虚拟 CPU、内存、网络与磁盘；操作系统管理这些资源；应用进程运行订单代码；对外服务还包括入口转发、配置、凭据和外部依赖。某个进程存在并不等于服务可用，进程可能卡在数据库等待中。某台实例不可用也不必然导致整个服务不可用，前提是入口能把请求交给其他健康副本，而且剩余容量足够。

运维边界需要落到责任共担。云平台通常负责物理设施和底层虚拟化，团队仍要负责自己管理的操作系统补丁、应用版本、网络访问规则和业务数据保护。使用托管组件可以转移部分维护工作，但不能转移错误配置的后果。订单应用把数据库端口暴露给公网，或者把管理凭据写进启动脚本，都属于方案必须处理的风险。

再区分无状态与有状态。无状态应用并非完全没有数据，而是处理请求所需的持久事实不依赖某台实例独有的本地内容。订单记录保存在数据库，共享文件进入适当的持久存储，实例上的缓存可以重建。这样实例才容易替换。如果购物车会话只放在进程内存，入口切换副本就可能让顾客丢失状态，扩容和故障恢复也会受到限制。

高可用、备份和灾难恢复解决不同问题。高可用通过冗余降低单个组件故障的影响；备份提供历史数据副本；灾难恢复规定重大故障后的恢复地点、步骤和业务校验。2 台实例若共享同一个故障域，仍可能一起中断。数据库有副本也不意味着能找回误删除的数据，因为错误可能同步复制。副本、备份和恢复演练需要分别说明。

恢复时间目标 RTO 表示业务允许中断多长时间，恢复点目标 RPO 表示允许丢失多长时间范围内的数据。例如 RTO 为 30 分钟、RPO 为 5 分钟，是需要通过架构和演练支撑的目标，不能由“每天备份”直接推出。订单场景还要说明支付回调、库存预占和订单状态之间如何对账。数据库恢复成功只是技术检查，业务恢复还要验证这些事实是否一致。

最后区分配置和秘密。应用端口、连接池上限属于配置；数据库密码和访问令牌属于秘密。秘密应通过受控机制获取，限制可读取的身份和用途，并支持轮换。配置变更同样需要版本与审计，因为错误的连接地址也能造成全站故障。让变更可追踪，既便于恢复，也能让排障人员准确回答“故障之前究竟发生了什么”。

3 配置基线、漂移检测与登录路径

3.1 从期望状态到可替换实例

可靠运维的基础是描述期望状态：使用哪个系统镜像、运行哪个应用版本、开放哪些端口、从哪里取配置，以及怎样判断启动成功。团队可以用版本化模板和自动化流程重复创建环境。手工登录实例修复虽然可能暂时有效，却容易形成只有某个人知道的差异。下次替换机器时，这些差异消失，故障便会重新出现。

镜像不应包含长期有效的生产秘密。启动流程先取得运行身份，再读取被授权的配置，启动服务并执行就绪检查。就绪检查表示该副本已经能够接收业务流量；存活检查关注进程是否需要重启。若把任何数据库短暂超时都判为进程死亡，所有副本可能一起重启，反而放大依赖故障。检查范围、超时时间和连续失败次数都要明确。

3.2 发布、摘流与回退

滚动发布把变更拆成有限批次。先准备新副本，确认就绪，再逐步承接流量，同时观察错误率和延迟。替换旧副本之前要摘流，即让入口停止分配新请求，并等待已有请求在限定时间内结束。仅仅关闭进程可能中断已经开始的订单提交；无期限等待又会让发布卡住，因此要同时设置请求超时和排空上限。

回退需要可执行的条件，例如新版本接流后，连续 3 个统计窗口内技术错误率超过阈值，且相对旧版本明显上升，就停止推进并恢复旧版本。回退不是把版本号改回去这么简单。若新版本已经删除旧代码依赖的数据库字段，旧版本可能无法运行。数据库结构应采用先兼容扩展、再迁移使用、最后清理的节奏，为应用回退保留空间。

3.3 扩缩容与容量余量

扩容信号应反映实际瓶颈。CPU 使用率适合部分计算密集负载，却不能单独描述订单接口：数据库等待可能让 CPU 很低，而请求队列持续增长。应结合每台实例的请求率、在途请求数、队列等待和尾延迟判断。扩容还要考虑启动耗时、预热耗时以及依赖可承受的连接总数；否则新增实例只是增加等待数据库的进程。

容量估算可以从简化关系开始：平均在途请求数约等于每秒到达请求数乘以平均处理时间。每秒 600 次请求、平均耗时 0.2 秒，对应约 120 个在途请求。这个关系适用于稳定观察区间，不能直接拿平均值保证峰值表现。真实容量要通过压测确认，并为流量波动、请求差异和故障摘除保留余量。接近满载时，排队增长往往比资源指标更早伤害用户体验。

缩容比扩容更需要检查状态。被选中的实例应先摘流，再完成正在处理的任务；后台任务需要确认是否能重新领取。若订单创建已经落库但响应中断，客户端可能重试，因此业务必须使用幂等键，让同一次意图不会创建多份订单。运维流程不能代替业务幂等，但必须知道哪些请求可以重试、哪些任务需要对账。

漂移检测要把「期望基线」与「实机状态」做成可重复 diff。基线至少包括：镜像/版本号、关键配置文件哈希、监听端口、systemd 单元是否 enable、时区与 NTP、以及安装的软件包集合。可用云厂商的配置审计/合规能力，或定期拉取 rpm -qa/dpkg --get-selections 与关键文件校验和，对比上次已批准版本；出现未登记变更时先告警再决定是回滚还是补登记。登录路径同样要基线化：优先云助手/SSM 等托管通道做应急，SSH 仅允许堡垒或短时证书，并关闭密码登录；两边的审计日志都要能回答「谁在何时进入过订单主机」。

4 订单主机：探活、发布与回滚

订单链路通常经过入口、订单应用、数据库，并调用库存或支付相关接口。运维需要识别同步路径和异步路径。顾客提交订单时必须立即完成的动作，应有明确的超时预算；通知、分析等允许稍后完成的工作，可以通过可靠任务机制处理。把所有后续动作都放进同步请求，会让某个次要依赖变慢时拖住整个下单接口。

为链路分配预算比随意设置超时更有效。例如外层请求总预算为 2 秒，就不能让库存调用单次等待 3 秒，还额外重试 2 次。重试应有次数上限、退避和随机扰动，并且只针对允许重试的错误。多个层级同时自动重试，会把原本少量失败放大成大量请求。处于容量紧张状态的依赖，往往会因此更难恢复。

保护依赖也要落实到连接池。假设数据库允许应用合计占用 300 个连接，正常有 6 个副本，每个副本上限就不能简单设为 100。还要预留发布时新旧副本重叠、后台任务和管理操作的连接。连接数不是越多越好：过高的并发可能增加锁竞争，让吞吐下降。应同时观测连接池等待、数据库活跃连接和查询耗时，找到真实的容量边界。

多可用区部署能够减少局部基础设施故障的影响，但需要检查入口、应用副本和依赖是否都能承受某个区域单元失效。若 6 个副本平均分布在 2 个可用区，失去其中 1 个后只剩 3 个，必须验证剩余容量是否足以承接目标流量。跨可用区也会带来时延和流量费用，方案应记录选择依据，并通过故障演练验证实际切换行为。

实例本地磁盘适合临时数据和可重建缓存，不适合作为订单事实的唯一存放处。应用日志应尽快集中采集，并规定本地轮转和保留上限，避免采集端异常时把系统盘占满。订单号、请求标识和支付关联号有助于追踪，但日志不应记录完整支付凭据、访问令牌或无必要的顾客个人信息。能够排查问题与限制敏感信息应同时实现。

还要提前决定降级策略。促销流量过大时，可以暂停推荐信息或延迟非关键通知，为下单保留资源；对于无法确认库存或支付结果的请求，不能为了让成功率好看而伪造成功。返回“处理中”需要有可查询的状态和后续收敛流程。运维人员必须知道哪些开关可以操作、操作后用户看到什么，以及怎样判断可以恢复正常功能。

5 动手：云助手/SSH 与运行时检查

动手时先使用测试环境，准备 2 个订单应用副本，并为每次请求生成可追踪的请求标识。控制台中先核对项目与环境、实例所属网络、可用区、镜像版本和标签，再查看入口后端列表。标签至少表达环境、服务和责任团队，方便资源盘点与告警路由。不要仅凭实例名称猜测它是否属于生产，更不要在环境未确认时直接重启。

登录系统后，可以用下面的只读命令建立现场印象。命令名称以常见 Linux 工具为例，不同系统可能需要相应权限或软件包。记录采样时间，并把结果与故障时间段联系起来，才能避免拿恢复后的健康状态解释故障发生时的情况。

date -Is
uptime
free -m
df -h
df -i
ss -lnt
systemctl status order-api --no-pager
journalctl -u order-api --since '15 minutes ago' --no-pager

uptime 中的负载不能直接当作 CPU 百分比，等待资源的任务也可能抬高负载。free 的空闲内存少不一定意味着故障，系统可能使用内存缓存文件；要结合可用内存、进程占用和内存不足终止事件。df -h 看容量，df -i 看文件节点，海量小文件可能在字节空间未满时就耗尽节点。这些命令是取证入口，不能靠其中某个数字直接下结论。

ss -lnt 可以确认服务是否监听预期端口，但监听成功仍不代表入口能够访问。可以在应用实例本地、同网络的诊断位置和对外入口分别验证健康检查，逐层定位边界。健康接口最好分清存活和就绪，并限制敏感输出。若使用 curl，应设置连接和总超时，记录状态码与耗时；单次返回 200 只能证明这次检查成功。

curl --connect-timeout 2 --max-time 5 \
  -sS -o /dev/null \
  -w 'code=%{http_code} total=%{time_total}\n' \
  http://127.0.0.1:8080/ready

接着在测试环境演练摘流：通过入口管理流程把 1 个副本标为不再接收新请求，观察它的新请求数下降，在途请求结束，其他副本承担流量。然后再执行预先审查过的更新流程。不要以直接终止进程代替摘流演练，因为这样无法验证入口传播、连接排空与请求超时之间是否协调。

最后演练备份恢复。将备份恢复到隔离环境，避免测试恢复程序向真实支付或通知系统发出请求。检查备份时间点、订单数量、关键状态和抽样记录，并记录从发起恢复到完成业务校验的耗时。只看到备份任务显示成功，不能证明恢复凭据、加密密钥、网络路径和应用兼容性都能工作。演练结果才是修订 RTO 与 RPO 的可靠依据。

6 观测：CPU steal、磁盘延迟、进程重启

观测应从顾客结果逐层向下展开。先看订单提交量、技术成功率和响应时间，再看入口与应用，最后检查 CPU、内存、磁盘和网络。业务成功率要有清晰分母：有效下单尝试中，哪些请求成功创建订单，哪些因库存不足被正常拒绝，哪些因技术异常失败。若混在一起，大促售罄时可能触发错误告警，而真实服务器故障反而被业务拒绝掩盖。

延迟要同时观察中位数和高分位数。p95 为 800 毫秒表示在该统计范围内约 95% 的请求耗时不超过 800 毫秒，并不表示所有顾客都体验良好。还要保留请求量，因为低流量窗口中的分位数容易波动。聚合多台实例时，应使用可合并的分布数据，不能简单平均各实例的 p95，否则可能掩盖请求分布和单台异常。

告警需要包含阈值、持续时间、最小样本量、影响范围和接收人。例如在有效请求量足够时，技术错误率连续 5 分钟高于 1%，通知值班人员，并附上入口、应用和依赖面板链接。该数值只是示例，正式阈值应由服务目标、正常波动和响应成本决定。面向顾客影响的告警用于推动处置，磁盘增长趋势等预警则用于安排提前维护。

每条可唤醒人的告警都应附有操作说明：先看什么证据，哪些动作已经授权，什么条件下升级处理，以及恢复后如何确认。多个实例因同一个数据库故障同时报警，应按共同原因聚合，避免大量重复通知挤掉关键上下文。告警恢复也要谨慎：资源使用率下降可能是顾客请求全部失败后的结果，应通过真实业务探测与成功率共同确认。

日志、指标和调用追踪各有用途。指标适合发现趋势，日志适合查看具体事件，追踪适合关联请求经过的组件。实例标识、版本和请求标识应在合适位置贯通，但不要把每个订单号都作为指标标签，否则会产生大量时间序列。追踪可能采样，日志也可能丢失，所以“没找到记录”是证据缺口，不能自动等价为请求从未发生。

CPU steal（虚机被宿主机调度抢走的时间份额）升高时，进程看起来「算得慢」但容器/实例内部利用率未必打满。对照云监控的 steal/就绪队列与应用第 95 百分位延迟：若 steal 与延迟同升而业务 CPU 不高，优先考虑换规格族、避开超卖池或限制同宿密度，而不是只加应用线程。磁盘延迟则看 iostat/云盘监控 的 await 与队列深度，避免把 IO 等待误当成需要垂直扩 CPU。

7 常见坑：手工雪花机、无回滚发布、忽略初始化

第 1 个坑是把重启当作默认修复。重启能解除某些临时状态，也可能清掉进程现场、扩大抖动，或者让全部副本同时重新建立数据库连接。应先判断顾客影响和剩余容量，保留最小必要证据，再选择摘流单个异常副本等有边界的动作。如果确实需要快速重启，也应记录执行时间和对象，方便后续区分原始故障与处置引入的变化。

第 2 个坑是只增加资源而不验证瓶颈。磁盘延迟过高、数据库锁等待和应用连接泄漏都可能表现为响应变慢。增加 CPU 未必有效，扩容应用甚至可能增加数据库压力。先查看请求时间分布和等待位置，再选择扩容、限流或修复。容量规划也应包含故障条件，而不能只看所有副本都健康时的压测最高吞吐。

第 3 个坑是管理入口长期暴露。为排障临时放开访问后忘记回收，或者多人共享高权限账号，会让访问范围与责任归属都失去控制。日常操作应使用个人身份、最小权限和有时限的授权，必要的管理通道应受网络边界与身份验证共同保护。审计记录至少保留操作者、时间、目标和动作，秘密本身不能进入审计明文。

第 4 个坑是补丁和证书只有日历提醒，没有实际验证。补丁应先在代表性环境验证，再分批应用，留出回退与维护窗口。证书续期要检查完整链路，包含申请、部署、服务加载和外部探测；自动申请成功不代表入口已经使用新证书。时间同步同样需要监控，时钟偏差可能影响令牌校验、日志排序和故障时间线。

第 5 个坑是把监控和备份当成无限容量的配套服务。日志激增可能撑满磁盘并增加费用，备份长时间保留可能超出预算，监控采集异常也会造成盲区。应设置轮转、保留周期和费用归属，并观测采集延迟及备份失败。降低成本时要先明确恢复要求，避免为了节省空间删除唯一可用的历史恢复点。

8 案例：半灰度发布后的间歇 5xx

大促前，订单 API 以半灰度推进：入口把约 20% 流量切到新版本副本，其余仍在旧版本。新版本包含一次序列化字段兼容改动，预发环境单副本压测通过，但预发没有真实的多版本并存与会话黏连。

上线 12 分钟后，总错误率仍低于 1%，值班却收到「偶发下单失败」投诉。按后端拆分后发现：打到新版本的请求中，约 4% 返回 5xx，且集中在带购物车合并逻辑的路径；旧版本几乎无此错误。若只看整体成功率，很容易误判为「噪声」而继续放量。

证据链按版本与副本对齐：入口访问日志带 app_version 与副本名；新版本副本的应用日志出现空指针/字段缺失；旧版本同路径无同类栈。对比说明问题与「新版本 + 特定请求形状」绑定，而不是整池容量不足。团队立即停止灰度、把流量切回旧版本，并保留 1 个新版本副本只接收合成探针以便取证。

根因是新版本假设所有上游都已写入新字段，而半灰度期间旧生产者仍在写旧形状；预发只用新版本自产自销，没覆盖「旧写新读」。修复后先在灰度副本用双读兼容逻辑验证，再按 5%→20%→50% 放量，每档观察按版本的 5xx、成功下单数与回滚开关是否可在 1 分钟内生效。

验收：半灰度必须能按版本切片错误；停止推进与回滚有演练记录；兼容窗口写进发布清单，而不是只写「预发已通过」。

跟随交互走完「按版本切片 → 停灰度 → 回滚旧版 → 保留取证副本」的路径，确认每一步都有日志字段可核对。

9 排查案例：主机层证据链

另一次事件发生在普通工作日。10:02，入口开始报告少量 502，随后部分订单请求超时。团队先确定影响范围：其他接口是否正常，失败是否集中在某个实例、版本或可用区，失败请求是否可能已经创建订单。查询入口记录发现，大多数连接失败指向实例 B，而实例 A、C 的同类请求仍能成功。这让排查从整个集群收敛到实例 B，但尚不能判断根因。

10:04，值班人员先将实例 B 摘流，并确认其余副本还有容量。摘流后总体错误率下降，说明故障与 B 有关联；这仍不能证明 B 的应用代码存在缺陷。接着查看进程与系统事件，发现服务在 10:01 后多次退出。磁盘容量达到 100%，而文件节点尚有余量，日志中出现写入失败，时间早于应用退出。这比单独看到“进程不在”提供了更接近原因的线索。

再检查变更与日志增长趋势：前一日诊断配置开启了详细请求日志，本地轮转上限未生效；凌晨集中采集连接异常，日志积压持续增加。证据链因此形成：配置变化提高日志量，采集异常与轮转缺失导致磁盘耗尽，写入失败后服务退出，入口向 B 建立连接失败。每个箭头都应有时间或记录支持，不能只靠“听起来合理”的故事串联。

处置时先保留必要日志样本和系统事件，再按预案清理可删除的归档或迁移文件，避免误删订单数据与审计记录。释放空间后还要检查进程是否仍占用已删除文件；目录里看不到文件，并不保证空间已经归还。修正日志配置、轮转和采集路径后重启被摘流的服务，在隔离接流或小流量条件下验证，再逐步恢复到入口后端。

验证需要覆盖技术和业务。技术上确认磁盘增长恢复正常、服务稳定、入口连接失败消失；业务上核对故障窗口内的请求标识和订单状态，区分未进入应用、处理失败以及成功落库但响应丢失的请求。对最后一种情况，幂等查询比直接重新创建订单更可靠。没有日志的请求需要结合入口与数据库证据，明确哪些结论仍然存在不确定性。

最终报告把直接原因、促成条件和防止复发的措施分开记录。磁盘耗尽是直接原因，详细日志长期开启、轮转失效和采集告警缺失是促成条件。验收应包含故意中断采集的演练，确认本地日志仍有上限，并验证空间预警能在耗尽前到达责任人。只有证明措施切断了原有故障路径，复盘才真正完成。

放进方案里

订单 API 的云服务器运维应以业务目标开篇：定义有效下单请求的技术成功率、响应时间和统计窗口，列明库存不足等正常业务拒绝的分类，并约定值班责任人与升级路径。目标数值由业务承受能力和验证结果确定，避免把实例运行状态直接当作业务可用性。

应用采用可替换副本，持久订单状态存入受保护的数据系统。方案记录镜像、版本、配置来源、秘密获取方式、网络边界和运行身份；说明副本在可用区中的分布，以及损失部分副本后的剩余容量。容量预算同时覆盖数据库连接、后台任务和发布期间的新旧副本重叠，并写明压测负载、启动耗时与预热条件。

变更流程规定先准备、再验证就绪、逐步接流和观察，旧副本经过摘流后退出。发布门槛包含业务成功率、尾延迟和依赖等待，回退条件及数据库兼容要求形成可执行记录。扩缩容与限流各有触发条件和恢复条件，订单重试使用幂等机制，超时后通过查询与对账确认最终状态。

观测覆盖入口、应用、依赖和主机，使用请求标识关联证据，告警附带责任人、面板和操作说明。日志设置敏感信息限制、本地轮转与集中保留规则；补丁、证书、访问授权和费用检查纳入周期任务，并留下变更审计。

恢复部分分别列出高可用措施、备份保留、RTO 和 RPO，定期在隔离环境恢复并校验订单与支付关联状态。上线验收提交发布回退、摘流、单副本故障、采集中断和备份恢复的演练记录，注明实测耗时、尚存限制及改进责任人，使运维能力成为可以复核的交付结果。

10 小结：走向容量估算（P4）

• 目标：是否用订单结果定义成功率和延迟，并明确统计口径与责任人？
• 实例：是否能从版本化配置重复创建，替换后是否保留正确的业务状态？
• 发布：是否验证就绪、摘流、分批接流和回退，数据库是否保持兼容？
• 容量：是否覆盖依赖连接预算、启动时间、峰值和故障后的剩余能力？
• 观测：是否能从失败请求追到实例、版本和依赖，告警是否对应明确动作？
• 恢复：是否真正恢复过备份，并检查订单、库存和支付状态的一致性？
• 排障：是否区分症状、关联和原因，保留时间线并验证防复发措施？

下一课转向 P4 容量估算。

带走本章的运维验收：镜像/补丁变更窗口、配置基线与漂移信号、探活与回滚门槛、以及半灰度下按版本定位故障的证据。下一课把这些运维约束写成容量与 NFR 数字——副本数、连接预算、排空时间与故障余量——并检查「运维流程正确」是否仍会在峰值被连接池或尾延迟打穿。

作业：把本课的连接预算、摘流/排空上限和回滚演练记录各摘 3 条，作为 P4 容量表的输入；没有演练证据的条目标为待测。