IT运维专家Skill it-operations

名称	it-operations
描述	管理IT基础设施、监控、事件响应和服务可靠性。提供ITIL服务管理、可观测性策略、自动化、备份/恢复、容量规划和运营卓越实践的框架。

IT运维专家

一个全面的技能，用于管理IT基础设施操作，确保服务可靠性，实施监控和警报策略，管理事件，并通过自动化和最佳实践保持运营卓越。

核心原则

1. 服务可靠性优先

• 主动监控: 在事件发生前实施全面的可观测性
• 事件管理: 具有清晰升级路径的结构化响应流程
• SLA/SLO管理: 定义和维护与业务需求对齐的服务级别目标
• 持续改进: 通过无责事后分析从事件中学习

2. 自动化优于手动流程

• 基础设施即代码: 通过版本控制的代码管理基础设施配置
• 运行手册自动化: 将手动程序转换为自动化工作流
• 自愈系统: 为常见问题实施自动修复
• 配置管理: 维护跨环境的一致性

3. ITIL服务管理

• 服务策略: 将IT服务与业务目标对齐
• 服务设计: 设计弹性、可扩展的服务
• 服务转换: 以最小中断管理变更
• 服务操作: 有效交付和支持服务
• 持续服务改进: 迭代增强服务质量

4. 运营卓越

• 文档化: 维护当前运行手册、程序和架构图
• 知识管理: 从事件解决方案构建可搜索知识库
• 容量规划: 主动预测和提供资源
• 成本优化: 平衡性能要求与基础设施成本

核心工作流

基础设施操作工作流

1. 监控与可观测性
   ├─ 为关键服务定义SLIs/SLOs/SLAs
   ├─ 实施指标收集（基础设施、应用、业务）
   ├─ 配置具有适当阈值和升级的警报
   ├─ 为不同受众（运维、开发、高管）构建仪表板
   └─ 建立值班轮换和升级程序

2. 事件管理
   ├─ 接收警报或用户报告
   ├─ 评估严重性和影响（P1/P2/P3/P4）
   ├─ 参与适当的响应者
   ├─ 调查和诊断根本原因
   ├─ 实施修复或变通方案
   ├─ 向利益相关者沟通状态
   ├─ 在知识库中记录解决方案
   └─ 进行事件后审查

3. 变更管理
   ├─ 提交带有影响评估的变更请求
   ├─ 通过CAB（变更顾问委员会）审查和批准
   ├─ 计划变更窗口
   ├─ 执行变更，准备回滚计划
   ├─ 验证成功标准
   ├─ 记录实际与计划结果
   └─ 关闭变更票证

4. 容量规划
   ├─ 收集资源利用率趋势
   ├─ 分析增长模式
   ├─ 预测未来需求
   ├─ 计划采购或提供
   ├─ 执行容量增加
   └─ 监控有效性

5. 自动化与优化
   ├─ 识别重复性手动任务
   ├─ 记录当前流程
   ├─ 设计自动化解决方案
   ├─ 实施和测试自动化
   ├─ 部署到生产环境
   ├─ 测量时间/成本节省
   └─ 迭代和改进

决策框架

警报配置决策矩阵

场景	警报类型	阈值	响应时间	升级
服务完全中断	页面	立即	< 5 分钟	立即到值班人员
服务降级	页面	2-3 次失败	< 15 分钟	15 分钟后到值班人员
高资源使用率	警告	> 80% 持续	< 1 小时	2 小时后到团队领导
接近容量	信息	> 70% 趋势	< 24 小时	每周容量审查
配置漂移	票证	任何偏差	< 7 天	月度审查

事件严重性分类

优先级 1（关键）

• 影响所有用户的完全服务中断
• 数据丢失或安全漏洞
• 财务影响 > 每小时 $10K
• 响应：立即，24/7，全员参与

优先级 2（高）

• 影响许多用户的部分服务中断
• 显著性能降级
• 财务影响 $1K-$10K/小时
• 响应：业务时间内 < 30 分钟

优先级 3（中）

• 影响部分用户的服务降级
• 非关键功能受损
• 变通方案可用
• 响应：业务时间内 < 4 小时

优先级 4（低）

• 影响极小的次要问题
• 外观问题
• 增强请求
• 响应：下一个工作日

变更管理风险评估

风险级别 = 影响 × 可能性 × 复杂度

影响 (1-5):
1 = 单个用户
2 = 团队
3 = 部门
4 = 公司范围
5 = 面向客户

问题可能性 (1-5):
1 = 常规，测试过
2 = 熟悉，有文档
3 = 有些不确定性
4 = 新领域
5 = 从未做过

复杂度 (1-5):
1 = 单个组件
2 = 少数组件
3 = 多个系统
4 = 跨平台
5 = 企业范围

风险评分解释:
1-20: 标准变更（预批准）
21-50: 正常变更（CAB审查）
51-75: 高风险变更（广泛测试，高级批准）
76-125: 仅紧急变更（执行批准）

监控工具选择

需求	Prometheus + Grafana	Datadog	New Relic	ELK Stack	Splunk
成本	免费（自托管）	$$$$	$$$$	免费-$$	$$$$$
指标	优秀	优秀	优秀	好	好
日志	通过 Loki	优秀	优秀	优秀	优秀
追踪	通过 Tempo	优秀	优秀	有限	好
学习曲线	陡峭	中等	中等	陡峭	陡峭
云原生	优秀	优秀	优秀	好	好
本地部署	优秀	好	好	优秀	优秀
APM	通过导出器	优秀	优秀	有限	好

常见运营挑战

挑战 1: 警报疲劳

问题: 过多误报警报导致团队疲劳

解决方案:

警报调优过程:
1. 测量基线警报量和误报率
2. 按可操作性分类警报:
   - 可操作 + 紧急 = 保留为页面
   - 可操作 + 不紧急 = 票证
   - 不可操作 = 移除或转换为仪表板指标
3. 实施警报聚合（分组类似警报）
4. 向警报添加上下文（运行手册链接，相关指标）
5. 定期审查会议（每周）调优阈值
6. 跟踪指标:
   - MTTA（平均确认时间）：< 5 分钟目标
   - 误报率：< 20% 目标
   - 每周警报量：趋势下降

挑战 2: 危机期间事件文档化

问题: 团队在高压事件期间跳过文档化

解决方案:

• 分配专门记录员角色（非事件指挥官）
• 使用事件管理工具（PagerDuty、Opsgenie）自动时间线
• 基于模板的事件报告，含必填字段
• 事件后审查自动安排（48 小时内）
• 游戏化文档化（跟踪和认可详尽文档）

挑战 3: 知识孤岛

问题: 关键知识困在个别团队成员脑中

解决方案:

知识转移策略:
- 结对编程/影子: 冲刺容量的 20%
- 运行手册要求: 每个系统必须有运行手册
- 午餐学习会: 每周 30 分钟知识分享
- 交叉培训矩阵: 跟踪谁知道什么，识别缺口
- 值班轮换: 全员轮换以传播知识
- 事件后审查: 强制性团队分享
- 文档冲刺: 季度专注于文档完成

挑战 4: 平衡稳定性与创新

问题: 运维团队为保持稳定抵制变更

解决方案:

• 实施变更窗口（计划维护时段）
• 使用蓝绿或金丝雀部署降低风险
• 建立“创新时间”（谷歌 20% 时间模型）
• 创建沙盒环境供实验
• 测量并奖励稳定性和改进指标
• 将“苦力减少”作为 OKR 目标

关键指标与 KPI

服务可靠性指标

可用性:
  公式: (总时间 - 停机时间) / 总时间 × 100
  目标: 99.9%（每月 43.8 分钟停机）
  测量: 按服务，月度

MTTR（平均恢复时间）:
  公式: 恢复时间总和 / 事件数
  目标: P1 < 30 分钟，P2 < 4 小时
  测量: 按严重级别，月度

MTBF（平均故障间隔时间）:
  公式: 总操作时间 / 故障数
  目标: > 720 小时（30 天）
  测量: 按服务，季度

MTTA（平均确认时间）:
  公式: 确认时间总和 / 警报数
  目标: 页面 < 5 分钟
  测量: 按值班工程师，每周

变更成功率:
  公式: 成功变更 / 总变更 × 100
  目标: > 95%
  测量: 月度

事件复发率:
  公式: 重复事件 / 总事件 × 100
  目标: < 10%
  测量: 季度（相同根本原因在 90 天内）

运营效率指标

苦力百分比:
  定义: 花在手动、重复任务上的时间
  目标: < 团队容量的 30%
  测量: 每周时间跟踪

自动化覆盖率:
  公式: 自动化任务 / 总重复任务 × 100
  目标: > 70%
  测量: 季度审核

值班负载:
  公式: 每班可操作警报数
  目标: < 每班 5 个可操作警报
  测量: 按工程师，每周

运行手册覆盖率:
  公式: 有运行手册的服务 / 总服务数 × 100
  目标: 100%
  测量: 月度审核

知识库使用率:
  公式: 通过 KB 解决的事件 / 总事件 × 100
  目标: > 40%
  测量: 月度

集成点

与开发团队

• 参与设计审查以满足运营需求
• 提供部署自动化和 CI/CD 流水线支持
• 分享监控和日志要求
• 协作事件响应和事后分析
• 共同拥有 SLOs 和错误预算

与安全团队

• 实施安全监控和警报
• 管理访问控制和认证系统
• 协调漏洞修补和修复
• 进行安全事件响应
• 维护安全政策合规性

与业务利益相关者

• 报告服务可用性和性能
• 沟通计划维护窗口
• 提供容量规划预测
• 将技术指标翻译为业务影响
• 参与业务连续性规划

最佳实践

1. 无责事后分析

事件后审查模板:
- 事件摘要（发生了什么、何时、影响）
- 事件时间线（详细年表）
- 根本原因分析（5 个为什么或鱼骨图）
- 做得好（响应中的优势）
- 可改进之处（机会）
- 行动项（含负责人和截止日期）
- 经验教训（可分享见解）

规则:
- 无责或惩罚
- 聚焦系统和流程，非人员
- 人人可自由发言
- 行动项必须跟踪完成

2. 运行手册标准

运行手册内容:
  - 服务概述: 目的、依赖、架构
  - SLIs/SLOs/SLAs: 定义阈值和目标
  - 常见问题: 症状、原因、解决方案
  - 故障排除步骤: 逐步程序
  - 升级路径: 联系谁和何时
  - 有用命令: 复制粘贴就绪命令
  - 仪表板链接: 直接链接到相关仪表板
  - 最近变更: 链接到变更日志
  - 联系信息: 团队、产品负责人、SMEs

维护:
  - 季度或重大事件后审查
  - 低流量期间测试程序
  - 每次重大变更后更新
  - 跟踪使用指标（页面浏览量、有用性评分）

3. 值班最佳实践

值班准备:
  - 带VPN访问的笔记本电脑
  - 带通知应用的移动设备
  - 联系列表（升级路径）
  - 访问所有关键系统
  - 运行手册书签
  - 识别备份值班

值班期间:
  - 5 分钟内确认警报
  - 定期更新事件状态
  - 遵循升级程序
  - 在事件票证中记录所有行动
  - 清晰交接给下个值班

值班后:
  - 完成事件报告
  - 提交苦力减少票证
  - 提供运行手册反馈
  - 更新值班文档

4. 变更管理纪律

标准变更流程:
  1. 创建变更请求（RFC）
  2. 记录:
     - 什么: 具体变更内容
     - 为什么: 业务理由
     - 何时: 建议日期/时间
     - 谁: 变更实施者和批准者
     - 如何: 逐步程序
     - 风险: 评估和缓解
     - 回滚: 详细回滚计划
     - 测试: 验证步骤
  3. 提交CAB审查（提前7天通知）
  4. 批准窗口内实施
  5. 验证成功标准
  6. 记录实际结果后关闭变更
  7. 如有问题，进行实施后审查

紧急变更流程:
  - 需要执行批准
  - 实施时加强监控
  - 全员通知
  - 24 小时内完成文档
  - 强制性变更后审查

参考文件

详细技术指导见:

• reference/monitoring.md - 可观测性、指标、警报和仪表板设计
• reference/incident-management.md - 事件响应、根本原因分析、事后分析
• reference/infrastructure.md - 服务器管理、网络操作、容量规划
• reference/automation.md - 脚本、配置管理、编排工具
• reference/backup-recovery.md - 备份策略、灾难恢复、业务连续性

开始使用

1. 新基础设施: 从reference/infrastructure.md开始获取设置指导
2. 监控设置: 查看reference/monitoring.md获取可观测性策略
3. 事件响应: 见reference/incident-management.md获取程序
4. 自动化项目: 检查reference/automation.md获取工具推荐
5. DR规划: 咨询reference/backup-recovery.md获取恢复策略