genapohub DevOps / 运维工程师方案产出指南
Overview
本技能将 DevOps 领域的方法论转化为可执行的工作流。当用户提出运维相关需求时，先识别该需求属于 5 类场景中的哪一类，再按对应场景的产出清单生成完整方案——从基础设施搭建到灾备方案，覆盖运维工程的全生命周期。
详细的方法论、各场景产出清单、CI/CD规范、K8s最佳实践、监控SLO、安全基线、质量检查清单均存放在 references/DevOps方法论.md，在执行前必须读取对应章节。
触发条件
- 用户需要搭建 CI/CD Pipeline 或改造现有流程
- 用户需要设计容器化方案或 Kubernetes 配置
- 用户需要搭建监控、日志、告警体系
- 用户需要云基础设施规划或迁移
- 用户提到"CI/CD""DevOps""K8s""Docker""监控告警""日志""灾备""IaC""Terraform""运维"等关键词
记忆系统
本技能的完整记忆管理规则（写日志/轮转归档/自清理）定义在 references/记忆规则.md，执行前必须读取。
- 执行前（必须）：读取
references/记忆规则.md中的 Step 0 加载规范 +.skills-memory/MEMORY.md本技能对应分段 +.skills-memory/YYYY-MM-DD.md（今日日志，如存在） - 执行后（硬性要求，不可跳过）：追加
[devops-guide] 场景描述 → 关键决策到.skills-memory/YYYY-MM-DD.md；如有可复用决策，去重后追加到 MEMORY.md 对应分段。记忆写入是交付物的一部分——如果因环境限制无法写入，必须在最终回复中明确告知用户「记忆未写入」及原因，不得静默跳过 - 轮转检查：
- 独立使用：按
references/记忆规则.md中的触发条件和完整轮转算法执行归档 - 被 team-orchestrator 调度时：跳过全部记忆操作（写入 + 轮转），由调度官 Step 6（写日志）/ Step 7（轮转归档）统一处理
- 独立使用：按
执行流程
按以下 5 步顺序执行，不可跳步。
Step 1: 需求理解
- 解析用户输入的运维需求
- 提取关键信息：基础设施现状、云平台、容器化程度、监控现状、团队规模、可用性目标、预算约束
- 识别缺失的关键信息，主动提问补全（一次最多 2-3 个问题）
Step 2: 场景识别
读取 references/DevOps方法论.md 的"一、场景识别"章节判断场景：
| 场景 | 名称 | 判断条件 | 产出量 |
|---|---|---|---|
| 场景一 | 0→1 基础设施搭建 | 全新项目、无CI/CD、无监控 | 10-12类 |
| 场景二 | 中型运维改造/优化 | 已有基础设施新增模块、CI/CD改造 | 6-8类 |
| 场景三 | 小优化/故障修复 | 单条Pipeline修复、告警调整 | 2-3类 |
| 场景四 | 大版本架构迁移 | 云平台迁移、K8s升级、工具链替换 | 8-10类 |
| 场景五 | 技术预研/选型 | 新工具评估、成本优化PoC | 3-4类 |
Step 3: 与用户确认场景
输出场景判断、判断依据、产出清单、预估周期，确认后进入产出。
Step 4: 按清单产出方案
读取 references/DevOps方法论.md 对应场景章节。
专家蒸馏增量（2026-09-06 并入）：MVP/快速项目的部署交付方案，兜底检查四条底线——部署后可验证（/health + 页面 200 + 核心流程）、可回滚（上一版镜像保留）、数据有备份（每日 + 每月验证）、交付自包含（.env.example + DEPLOY.md + 一键启动）。详见
references/expert-distill/mvp-devops-蒸馏.md。进入生产级基础设施运维（非 MVP 部署）时，另读取references/expert-distill/infra-ops-蒸馏.md（运维通：监控告警量化阈值 CPU>80%/内存>90%/磁盘>85%/服务宕、备份七要素=加密+异地+验证+清理+通知+错误处理+分层、IaC 纪律、健康报告模板、运维量化指标 99.9%/MTTR<4h）。
产出要求：
- 架构图使用 Mermaid 或 ASCII 描述（网络拓扑/部署拓扑/数据流）
- Pipeline 定义给出完整的 YAML 配置示例（GitHub Actions/GitLab CI）
- K8s 配置给出完整的 YAML manifest（Deployment/Service/HPA/PDB）
- 监控告警给出具体指标 + 阈值 + 通知方式
- 遵循"七、DevOps 通用规范"
- 必须读取并应用"十一、超越AI味"章节：产出方案时融入真实岗位经验，拒绝模板化输出
- 优先使用可填空模板：方法论通用规范章节末尾的「### XX模板（可填空）」，直接按占位符填充（无对应模板则按清单产出）
- 产出后保存为 Markdown 文件
Step 5: 质量检查
读取 references/DevOps方法论.md 的"十、产出质量检查清单"：
CI/CD Pipeline 覆盖 Build→Test→Scan→Deploy 全流程
容器化符合最佳实践（多阶段构建/非root/资源限制）
监控覆盖 Metrics + Logs + Traces
告警分级明确 + 通知渠道
灾备方案含 RPO/RTO + 演练计划
安全覆盖镜像/网络/密钥/审计
回滚方案可执行
去AI味：对照"十一、超越AI味"逐条自检，拒绝模板化产出
记忆已写入（
.skills-memory/YYYY-MM-DD.md有本次会话条目，无则立即补写）
资源说明
references/DevOps方法论.md
完整的方法论文档，包含：5个场景产出清单、CI/CD规范、Docker最佳实践、K8s资源规范、监控SLO参考、安全基线、质量检查清单。
注意事项
- 不要跳过 Step 3 的用户确认
- Pipeline 必须覆盖安全性检查（镜像扫描/依赖扫描）
- 容器必须配置资源限制（Request/Limit），不加限制是安全隐患
- 告警必须分级 + 指定通知渠道 + 定义升级策略
- 灾备方案不能停在纸面，必须含演练计划
- 场景四（架构迁移）的回滚预案是硬性要求
岗位职责与产出标准（业界锚点 · 2026-08 学习）
现实岗位职责：①CI/CD 流水线设计与运维——持续集成/持续交付/自动化部署；②基础设施即代码（IaC）——Terraform/Ansible 管理云资源；③容器化与编排——Docker/K8s 部署维护；④监控告警与可观测性——Prometheus/Grafana/ELK；⑤故障响应与根因分析——事故复盘闭环；⑥安全合规——扫描/密钥管理/最小权限；⑦减少 toil——自动化/自助服务/runbook 沉淀。
业界产出标准：CI/CD 模板、IaC 模块与环境栈、Helm charts、监控看板与告警规则、runbook、事故复盘报告（postmortem）、安全扫描集成。质量要求（DORA 指标）：部署频率、变更前置时间、变更失败率、MTTR（恢复时长）持续改善；SLO 达标；告警噪音率低。
交付衔接：运维方案交付给开发（CI/CD配置/环境信息）+ QA（测试环境搭建）+ 项目管理（上线计划）