服务器SRE稳定性建设：从监控到故障演练的落地清单

服务器SRE稳定性建设不是装一个监控工具就结束，而是把可用性目标、监控告警、容量规划、变更管理和故障演练串成一条能检查、能回滚的流程。
如果你刚开始接手服务器，建议先按本文顺序把最小闭环搭起来，再逐步补细节。

先定义可衡量的稳定性目标

SRE的核心是用工程手段控制风险。
开始动手前，先和业务方确认三个东西：哪些服务最重要、用户能接受多长的故障时间、谁来接收告警。
没有目标，后面的监控和告警就没有判断标准。

常见的做法是给核心服务设定SLI和SLO。
SLI是可观测的指标，比如HTTP请求成功率；
SLO是目标值，比如过去30天成功率不低于99.9%。
可以用下面的方式记录在文档里，方便后续核对：

服务名称：订单API
SLI：HTTP 5xx 比例
SLO：30天滚动窗口内 5xx 比例 < 0.1%
告警接收人：运维值班群

这一步不需要复杂工具，用表格或Markdown文档即可。
关键是目标要能被监控数据验证，否则只是口号。

搭起最小可用的监控与告警

监控是稳定性建设的地基。
对大多数Linux服务器，推荐从主机指标加应用指标两条线入手。
主机侧可以用node_exporter采集CPU、内存、磁盘、网络；
应用侧按语言选择对应的exporter或埋点。
下面以Prometheus加node_exporter为例，说明配置和验证方式。

安装node_exporter后，确认服务在监听：

systemctl status node_exporter
curl -s http://127.0.0.1:9100/metrics | head

然后在Prometheus的prometheus.yml里加入抓取任务：

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['10.0.0.11:9100', '10.0.0.12:9100']

重启Prometheus后，在Web界面的Status > Targets里确认状态为UP。
告警规则不要一上来就写几十条，先从磁盘、内存、服务存活三类开始：

groups:
  - name: host-basic
    rules:
      - alert: DiskWillFull
        expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.1
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "磁盘可用空间低于10%"

告警发出后要能到达人。
Alertmanager可以对接邮件、企业微信或钉钉机器人。告警必须可关闭、可静默，否则值班人员很快会麻木。

变更与容量：稳定性最容易出事的地方

很多故障不是硬件坏了，而是变更引入的。
服务器SRE稳定性建设里，变更管理至少要做到三点：变更前有备份、变更中有观察窗口、变更后可回滚。

以修改Nginx配置为例，推荐流程是：先备份原文件，再用nginx -t检查语法，最后平滑重载：

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%F)
nginx -t
systemctl reload nginx

如果nginx -t报错，不要执行reload，先根据报错行号修正。
重载后观察错误日志和5xx比例：

tail -f /var/log/nginx/error.log

容量方面，至少关注磁盘增长速度和连接数。
可以用df -h和ss -s定期检查，把结果记录到值班表。
当磁盘使用率超过80%或连接数接近上限时，提前扩容或清理，不要等到服务不可用。

用故障演练验证体系是否有效

监控和预案写完不等于有效，需要做小范围演练。
演练不是制造真实事故，而是在可控范围内验证告警和恢复流程。
可以从低风险项目开始，比如手动停止一台非核心服务的node_exporter，观察告警是否在预期时间内触发。

演练前要通知相关同事，演练后要复盘三个问题：告警是否及时、处理步骤是否清晰、恢复时间是否符合SLO。
把结论补回文档，形成闭环。

常见疑问与避坑提醒

告警太多怎么办？ 先按严重程度分级，只把影响用户的告警设为高优先级，其他转为日报或看板。

没有专职SRE能不能做？ 可以。
先从一台核心服务器做起，把监控、备份、变更记录三件事固定下来，再逐步扩展。

稳定性建设要不要一步到位？ 不建议。
优先覆盖核心服务和最近出过问题的环节，迭代比一次性大而全更可靠。

避坑重点：不要只装监控不配告警接收人；
不要把测试环境告警发到生产值班群；
不要在业务高峰期做无回滚方案的变更。

怎么确认这套建设有效

验证方式很直接：随机抽查一条告警，看它是否在承诺时间内到达接收人；
模拟一次配置回滚，看是否能在几分钟内恢复；
查看过去一周的SLO达成情况，确认没有长期偏离目标。
只要这三项能通过，说明最小闭环已经跑通。
后续再根据业务增长补充日志聚合、链路追踪和自动化恢复。