DevOps 自动化

自动化 DevOps 工作流，包括 CI/CD 流水线、监控、事故管理和基础设施运维。基于 n8n 的 IT 运维工作流模板。

概述

此技能涵盖：

• CI/CD 流水线自动化
• 监控与告警
• 事故管理
• 基础设施自动化
• 部署工作流

CI/CD 自动化

GitHub Actions 集成

工作流: "GitHub CI/CD 通知"

触发器:
  - github_push
  - github_pull_request
  - github_workflow_run
  
推送时:
  操作:
    - 触发 CI: 如果是主分支
    - Slack 通知:
        频道: "#deployments"
        消息: |
          📦 *新推送至 {branch}*
          
          提交: `{commit_sha_short}`
          作者: {author}
          消息: {commit_message}
          
          [查看差异]({compare_url})

拉取请求打开时:
  操作:
    - Slack 通知:
        频道: "#code-review"
        消息: |
          🔀 *新拉取请求*
          
          标题: {pr_title}
          作者: {author}
          分支: {head} → {base}
          
          [审阅 PR]({pr_url})
    - 分配审阅者: 基于代码所有者
    - 运行 CI 检查

工作流完成时:
  操作:
    - Slack 通知:
        消息: |
          {status_emoji} *构建 {status}*
          
          工作流: {workflow_name}
          分支: {branch}
          耗时: {duration}
          
          {如果失败: [查看日志]({logs_url})}

部署流水线

部署流水线:
  阶段:
    构建:
      触发器: 推送至主分支
      步骤:
        - 检出代码
        - 安装依赖
        - 运行测试
        - 构建产物
        - 推送到镜像仓库
        
    预发布:
      触发器: 构建成功
      步骤:
        - 部署至预发布环境
        - 运行集成测试
        - 通知 QA 团队
        
    生产:
      触发器: 手动审批
      步骤:
        - 创建备份
        - 部署至生产环境
        - 运行冒烟测试
        - 通知团队
        
  回滚:
    触发器: 部署失败 或 手动
    步骤:
      - 回滚至上一版本
      - 通知团队
      - 创建事故

监控与告警

告警路由

告警路由:
  数据源:
    - prometheus
    - datadog
    - cloudwatch
    - new_relic
    
  严重级别:
    紧急:
      响应时间: 5分钟
      通知渠道: [pagerduty, slack_urgent, 短信]
      升级策略: 立即
      
    高:
      响应时间: 15分钟
      通知渠道: [slack_alerts, 邮件]
      升级策略: 15分钟后
      
    中:
      响应时间: 1小时
      通知渠道: [slack_alerts]
      
    低:
      响应时间: 24小时
      通知渠道: [slack_logging]
      
  路由规则:
    - 如果: 服务 == "支付"
      团队: 支付值班团队
      严重性提升: +1
      
    - 如果: 服务 == "认证"
      团队: 安全值班团队
      
    - 默认:
      团队: 平台值班团队

告警模板

告警模板:
  基础设施:
    CPU过高:
      标题: "🔥 CPU 使用率过高"
      正文: |
        服务器：{host}
        CPU：{cpu_percent}%
        持续时间：{duration}
        
        阈值: {threshold}%
        
        [查看仪表板]({grafana_url})
        
    内存紧急:
      标题: "💾 内存使用紧急"
      正文: |
        服务器：{host}
        内存：{memory_percent}%
        可用：{available_mb}MB
        
        [SSH 到服务器]({ssh_link})
        
    磁盘满:
      标题: "💿 磁盘空间紧急"
      正文: |
        服务器：{host}
        磁盘：{disk_percent}%
        可用：{available_gb}GB
        
        建议: 清理日志或扩展磁盘容量
        
  应用:
    错误率激增:
      标题: "📈 错误率激增"
      正文: |
        服务：{service}
        错误率：{error_rate}%
        正常基线：{baseline}%
        
        主要错误:
        {top_errors}
        
    延迟过高:
      标题: "🐢 高延迟"
      正文: |
        服务：{service}
        P99 延迟：{p99_ms}ms
        阈值：{threshold_ms}ms

事故管理

事故工作流

事故工作流:
  检测:
    来源: [监控系统, 用户报告, 自动化检查]
    
  分类:
    自动定级:
      - 如果: 影响支付
        严重级别: 紧急
      - 如果: 影响认证
        严重级别: 紧急
      - 如果: 影响 API 且 错误率 > 10%
        严重级别: 高
        
  响应:
    紧急:
      - 创建事故频道: "#inc-{时间戳}"
      - 立即呼叫值班人员: 立即
      - 通知干系人: [工程负责人, 产品经理]
      - 启动作战室: 视频会议链接
      - 创建状态页面: 事故公告
      
    高:
      - 创建事故频道
      - Slack 通知值班人员: 通过 Slack
      - 创建工单: Jira
      
  沟通:
    内部:
      频率: 每30分钟
      频道: 事故频道
      模板: |
        📊 *事故更新*
        
        状态: {status}
        影响范围: {impact}
        下次更新: {next_update_time}
        
        当前行动项:
        {action_items}
        
    外部:
      渠道: 状态页面
      模板: 面向客户的更新
      
  解决:
    步骤:
      - 确认已解决
      - 更新状态页面: 已解决
      - 通知干系人
      - 安排事后复盘
      - 关闭事故频道: 24小时后

事后复盘模板

事后复盘模板:
  章节:
    摘要:
      - 事故标题
      - 持续时间
      - 严重级别
      - 影响范围
      
    时间线:
      格式: |
        | 时间 | 事件 |
        |------|-------|
        | {time} | {event} |
        
    根本原因:
      - 发生了什么
      - 为什么会发生
      - 促成因素
      
    影响:
      - 受影响的用户数
      - 收入影响
      - 服务水平协议违约
      
    解决方案:
      - 如何修复
      - 发现时间
      - 解决时间
      
    行动项:
      格式: |
        | 行动项 | 负责人 | 截止日期 | 状态 |
        |--------|-------|----------|--------|
        
    经验教训:
      - 做得好的地方
      - 需要改进的地方
      - 幸运的巧合

基础设施自动化

服务器配置

配置工作流:
  触发器: Jira 工单 或 Slack 请求
  
  步骤:
    1. 验证请求:
        检查项: [预算审批, 安全评审]
        
    2. 创建基础设施:
        Terraform:
          - VPC
          - 安全组
          - EC2 实例
          - 负载均衡器
          
    3. 配置服务器:
        Ansible:
          - 基础配置
          - 安全加固
          - 监控代理
          - 应用设置
          
    4. 验证:
        - 健康检查
        - 安全扫描
        - 性能基准测试
        
    5. 通知:
        Slack: "✅ 服务器 {hostname} 已就绪"
        包含信息: [SSH 访问方式, 仪表板链接]

定时维护

维护自动化:
  任务:
    证书续期:
      调度: "到期前30天"
      操作:
        - 请求新证书: Let's Encrypt
        - 部署证书
        - 验证 SSL
        - 失败时通知: 如果失败
        
    安全补丁:
      调度: "每周"
      操作:
        - 检查更新
        - 如果是关键补丁: 立即打补丁
        - 否则: 安排维护窗口
        
    日志轮转:
      调度: "每日"
      操作:
        - 轮转日志
        - 压缩旧日志
        - 上传至 S3
        - 删除本地文件: 保留超过7天的日志
        
    备份验证:
      调度: "每周"
      操作:
        - 恢复到测试环境
        - 运行完整性检查
        - 报告状态

Kubernetes 自动化

K8s 工作流

Kubernetes 自动化:
  部署:
    触发器: Docker 镜像已推送
    步骤:
      - 更新清单文件: 使用新镜像标签
      - 应用到预发布环境
      - 运行测试
      - 如果成功: 应用到生产环境
      
  扩缩容:
    触发器: 指标阈值
    规则:
      - 如果: CPU > 80%
        操作: 扩容
        最大副本数: 10
      - 如果: CPU < 20%
        操作: 缩容
        最小副本数: 2
        
  回滚:
    触发器: 健康检查失败
    操作:
      - kubectl rollout undo
      - 通知团队
      - 创建事故

输出示例

请求：”为 GitHub Actions 设置部署通知”

输出：

# GitHub Actions 部署通知

## n8n 工作流

```yaml
触发器：GitHub Webhook
事件：[workflow_run]

通知模板

构建开始：

🚀 *部署开始*

分支：main
提交：abc1234
作者：@developer
触发方式：推送

[查看工作流](https://github.com/...)

构建成功：

✅ *部署成功*

环境：生产
耗时：3分42秒
版本：v1.2.3

变更：
• 功能 X
• 错误修复 Y

[查看部署](https://app.example.com)

构建失败：

❌ *部署失败*

阶段：测试
错误：npm test 失败

[查看日志](https://github.com/...)
[重试](https://github.com/...)

Slack 集成

频道: "#deployments"
失败时提及: "@oncall"
线程回复: true

---

*DevOps 自动化技能 - Claude 办公技能套件的一部分*