系统崩了怪运维？别闹了，你该问问有没有自动化！

今天咱不讲高深理论，就聊聊一个你我都绕不开的大实话：

运维自动化，不是为了炫技，而是为了“业务不断、老板不吼、团队不掉头发”。

你可能也经历过这些瞬间：

• 系统挂了，排查时所有日志都没了，监控没告警，电话直接打爆；
• 半夜上线，配错了 config，线上直接白屏，早上客户群炸锅；
• 某服务一个 CPU 飙满导致链路雪崩，最后靠人工重启恢复；
• 运维流程全靠 Excel 和人肉操作，一个忘操作，全链路中断……

这些锅，背多了你会明白：运维要对抗的不是“复杂”，而是“脆弱”。

而真正解决“脆弱”的，不是人多跑得快，而是——自动化。

一、什么是业务连续性？一句话拆开理解

我们常说“业务连续性”，本质上就是：

系统要在任何时候都能“不断服务”，哪怕宕了一台机，系统照跑、客户无感。

自动化运维的目标，就是把人从高频、重复、低效的操作中解放出来，把“人控系统”变成“系统自愈”。

举个简单的例子：

以前服务挂了要人值班：

人工处理流程：
→ 页面502了 → 打电话 → SSH上去看日志 → 重启服务
→ 写日报总结原因 → 被领导骂

自动化之后：

自动流程：
→ 监控发现异常 → Prometheus 触发 Alert → Ansible 自动执行重启脚本
→ 自动上传日志快照 → 飞书自动发报告

这一来一回，从15分钟缩短到30秒内完成，还没人手误点错按钮，多香！

二、打造自动化体系的四大支柱

要让运维真正实现业务的“不断供”，自动化体系必须具备这 四大支柱：

下面就拿实际代码 + 场景说明，来讲讲怎么从**“能跑”到“不断”**。

三、实战：服务挂了自动拉起（自愈能力）

假设我们部署了一个 web 服务 myapp.service，使用 systemd 管理。

我们希望它一旦挂了就自动拉起，超过3次就通知运维群。

第一步：设置 systemd 自愈机制

# /etc/systemd/system/myapp.service
[Unit]
Description=My App
After=network.target

[Service]
ExecStart=/usr/bin/python3 /opt/myapp/app.py
Restart=on-failure
RestartSec=5
StartLimitInterval=60
StartLimitBurst=3

[Install]
WantedBy=multi-user.target

这个配置的意思是：

• 服务失败自动重启；
• 60秒内最多拉起3次，超了就不管；
• 交给我们下一步的告警系统处理。

第二步：用 Prometheus + Alertmanager 触发告警

我们用 node_exporter + systemd_exporter 抓服务状态：

prometheus.yml 配置：

- job_name: 'systemd'
  static_configs:
    - targets: ['localhost:9558']

alert.rules.yml：

groups:
- name: service-down
  rules:
  - alert: MyAppDown
    expr: systemd_unit_state{name="myapp.service",state="failed"} == 1
    for: 30s
    labels:
      severity: critical
    annotations:
      summary: "MyApp 服务宕机"
      description: "myapp.service 挂了，请立即处理"

第三步：让 Alertmanager 自动触发脚本修复 + 飞书告警

alertmanager.yml 配 webhook：

receivers:
  - name: 'feishu-notifier'
    webhook_configs:
      - url: 'http://localhost:9001/alert-handler'

本地运行一个 webhook 接收器（比如 Flask 写个接口）：

from flask import Flask, request
import subprocess
import requests

app = Flask(__name__)

@app.route('/alert-handler', methods=['POST'])
def handle_alert():
    data = request.json
    alert_name = data['alerts'][0]['labels']['alertname']
    
    if alert_name == "MyAppDown":
        subprocess.run(["systemctl", "restart", "myapp.service"])
        requests.post("https://open.feishu.cn/robot/send",
                      json={"msg_type": "text", "content": {"text": "myapp挂了，已自动重启！"}})
    return "OK"

if __name__ == '__main__':
    app.run(port=9001)

到这一步，业务连续性跃升一大截：

• 宕机 → 自动重启 → 自动通知 → 无需人介入
• 有问题也会留下执行记录 + 服务恢复时间指标

四、再上一层楼：CI/CD + 自动回滚

部署不稳定也是业务中断的一大风险，怎么办？

可以结合 GitLab + Jenkins + Ansible + 自动灰度系统，做到：

自动化部署 + 快速发现异常 + 一键回滚

例如：

• 每次上线做灰度部署 → 如果QPS或接口报错超阈值，触发 Ansible 自动回滚上一个版本
• 并通知研发和运维组，附带性能指标截图（Grafana 自动截图）

五、最后唠几句真心话

我见过太多公司，把运维当“修机器的”，出问题了让运维背锅。
但其实，运维真正的价值，不是修系统，是“让系统别出问题”。

而自动化，是我们唯一的“超级外骨骼”——
让我们能在服务风暴中保持稳定、在凌晨爆炸前自动扑火。

所以我想说：

别再用Excel写故障应急预案了，写个Python脚本吧兄弟！

自动化，不仅是工具升级，更是工作方式的革命。
当你有了“系统自己会救自己”的能力，你就离真正的运维工程师越来越近了。