系统崩了怪运维?别闹了,你该问问有没有自动化!
今天咱不讲高深理论,就聊聊一个你我都绕不开的大实话:
运维自动化,不是为了炫技,而是为了“业务不断、老板不吼、团队不掉头发”。
你可能也经历过这些瞬间:
- 系统挂了,排查时所有日志都没了,监控没告警,电话直接打爆;
- 半夜上线,配错了 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脚本吧兄弟!
自动化,不仅是工具升级,更是工作方式的革命。
当你有了“系统自己会救自己”的能力,你就离真正的运维工程师越来越近了。