# 运维常见题-运维流程规范


## 🤔 变更管理流程规范（完整阐述分级、评审、实施、回滚、复盘）  
- **变更管理是对"生产环境的一切变更"（配置、发布、升级、扩容）进行受控管理的流程，核心环节：①分级（按影响面/风险分 A/B/C 级）②评审（变更方案评审/审批）③实施（窗口内执行+监控）④回滚（预案兜底）⑤复盘（回顾改进）。核心：让每次变更"有方案、有审批、有监控、有回滚、有总结"，把变更风险降到可控。**  
    - **① 变更分级（常见分级约定，影响不同流程）**
        - A 级（重大）：核心业务/全量发布/架构变更——高管审批 + 专项方案 + 演练
        - B 级（一般）：普通服务变更/版本升级——团队负责人审批 + 方案评审
        - C 级（低风险）：参数调整/非核心配置——直接实施 + 记录备案
        - 分级依据：影响面（核心/外围）、风险（回滚难易）、客户影响
    - **② 变更评审**
        - 变更单：变更内容、影响范围、实施步骤、回滚方案、测试验证、时间窗口
        - 评审：技术评审（方案可行性）+ 审批（按级别授权人）
        - 提前评估：资源影响、依赖影响、安全影响、备份是否就绪
    - **③ 变更实施**
        - 在变更窗口执行（低峰期，减少影响）
        - 按方案逐步实施 + 实时监控（灰度/分批，别一把梭）
        - 执行人 + 复核人（双人确认关键步骤）
        - 变更过程记录（谁做了啥/耗时/结果）
    - **④ 回滚（安全网）**
        - 每个变更必须有回滚预案（回退步骤/旧版本/备份）
        - 失败/异常 → 按预案回滚（快而不纠结）
        - 回滚后验证（恢复可用再继续）
    - **⑤ 复盘**
        - 变更后回顾：成功/失败原因、耗时、问题
        - 失败变更 → 根因分析 + 改进（流程/方案/工具）
        - 沉淀变更知识库（同类变更参考）
    - **配套实践**
        - 变更日历（变更集中/冲突管理）、度量（部署频率与变更失败率分开看，DORA 指标）
        - 自动化变更（流水线）纳入统一管理（CI/CD 变更也走规范）

- **协助记忆**
    - 变更五环节："分级（影响）→ 评审（方案）→ 实施（受控）→ 回滚（预案）→ 复盘（改进）"。
    - 一句话："每次变更都有方案、有审批、有监控、有回滚、有总结"。

- **进阶思考**
    - **变更为什么必须"分级"（不统一流程）？**
        - 核心变更风险大（影响面广/回滚难）需严格流程（审批/演练）；低风险变更（改个参数）也走全流程会拖慢效率。分级让"高风险的严控、低风险的轻放"，兼顾安全与效率。
    - **回滚预案为什么"必须提前写"？**
        - 变更出问题时人最慌（决策能力下降），提前写好回滚步骤（旧版本/备份/开关）能在出问题时"照着做"快速止损。没预案的变更=裸奔，出问题只能现场想（易错）。
    - **变更失败率怎么降？**
        - ①小步变更（小影响高频，失败影响小）②自动化（减少人肉步骤错误）③充分测试/灰度④回滚预案完善⑤复盘改进。DORA 指标里"变更失败率低"是高质量团队标志。

- **扩展信息**
    - **流程落地工具**：变更管理平台/ITSM（Jira Service Management、`ServiceNow`、运维平台工单系统）——变更申请/审批/记录线上化
    - **与发布管理区别**：变更是"广义变更管理"（含发布/配置/升级），发布管理是变更的重型专项（应用上线）
    - **相关标准**：ITIL（信息技术基础架构库：变更管理是核心流程之一）、等保测评也查变更管理记录

## 🤔 应用发布管理流程  
- **应用发布管理是"把应用新版本从开发到上线"的受控流程，核心环节：①准备（代码/制品/发布计划）②测试验证（测试/预发环境）③发布实施（窗口+灰度/分批+监控）④回滚（旧版本就绪）⑤发布后验证与复盘。核心：让每次发布"测过的版本、可控上线、随时能回"。**  
    - **① 发布准备**
        - 版本就绪：代码评审/CI 构建通过、制品（镜像/包）入库（版本可追溯）
        - 发布计划：发布内容（变更点）、时间窗口、影响评估、回滚方案
        - 依赖确认：上下游/数据库变更/配置是否就绪（数据库变更尤其前置）
    - **② 测试验证**
        - 测试环境验证（功能测试/回归）
        - 预发/灰度环境验证（模拟生产）
        - 发布包验证（同一制品 = 测过的东西才上线，Build Once）
    - **③ 发布实施**
        - 按窗口执行（低峰/指定时段）
        - **分批/灰度**：先部分实例/流量验证，再扩大（降低风险）
        - 同步监控：发布期间实时看（错误率/延迟/健康）
        - 双人执行/复核（关键步骤）
    - **④ 回滚预案**
        - 旧版本制品保留（随时可回）
        - 失败信号（错误率异常/健康检查挂）→ 立即回滚（rollback）
        - 回滚后验证可用
    - **⑤ 发布后**
        - 验证：冒烟/健康检查/业务验证
        - 观察期：发布后持续监控（短时观察重要指标）
        - 复盘：发布结果记录（成功/失败/耗时），改进发布流程

- **协助记忆**
    - 发布六步："准备（制品）→ 测试（验证）→ 窗口（执行）→ 灰度（分批）→ 回滚（兜底）→ 复盘"。
    - 一句话："测过的版本、控着上线、随时能回"。

- **进阶思考**
    - **"Build Once, Deploy Everywhere"为什么重要？**
        - 同一制品部署所有环境（不是各环境重build）：保证"测试环境验过的东西 = 生产上跑的东西"，消灭"测试通过生产出问题"（环境/构建差异）。发布管理的关键实践。
    - **发布和"变更管理"什么关系？**
        - 发布是变更的"重型专项"：发布走变更管理框架（分级/评审/回滚），但发布有专门流程（版本/测试/发布窗口/灰度）——可以理解为"变更管理管一切，发布管理管应用上线"。
    - **怎么避免"发布即事故"？**
        - ①测试充分（尤其回归）②灰度分批（别一把全上）③监控就绪（发布中能看见异常）④回滚预案（失败秒回）⑤数据库变更先行验证（最常出问题）。"发布安全 = 验证 + 灰度 + 监控 + 回滚"。

- **扩展信息**
    - **发布类型**：普通发布（停机）、滚动（逐批）、灰度/金丝雀（流量比例）、蓝绿（双环境切换）、A/B（对比）——按场景选
    - **发布工具**：CI/CD（Jenkins/GitLab CI/Argo CD）、发布平台（云发布系统）、脚本自动化
    - **与 Devops 文件交叉**：发布策略细节参考"运维常见题-DevOpsAndCI.CD.md"灰度/蓝绿/滚动题

## 🤔 故障处理流程（故障分级、响应、止损、复盘）  
- **故障处理流程是"故障发生后的标准处置链路"，核心环节：①分级（按影响定级 `P0`/`P1`/`P2`）②响应（发现/上报/建群/分工）③止损（先恢复业务，再查根因）④排查（定位根因）⑤复盘（根因/`RCA`/改进）。核心："先止损再排查，恢复优先于问责，事后复盘防复发"。**  
    - **① 故障分级（P0-P3，影响决定响应）**
        - `P0`（紧急）：核心业务不可用（大面积宕机/资损）——立即全员响应/上报高管
        - `P1`（严重）：主要功能受损（部分用户受影响）——快速响应/主要负责人
        - `P2`（一般）：非核心功能异常——正常处理
        - `P3`（轻微）：小问题/有 workaround——常规处理
        - 分级依据：影响范围/业务重要性/用户影响/资损
    - **② 响应（黄金动作）**
        - 发现：监控告警/用户反馈/巡检
        - 上报：按分级通知（`P0` 立即上报负责人/建群）
        - 响应小组：故障群（现场+指挥+协调）、明确角色（处理人/指挥人/通报人）
        - 记录：故障时间线（谁/何时/做了什么）——后续复盘用
    - **③ 止损（先恢复）**
        - **恢复优先**：能回滚回滚、能重启重启、能切流切流——先让业务恢复
        - 止损手段：回滚/重启/切换（备库/冗余）/降级/限流
        - 止损后：确认业务恢复（不纠结根因，先止血）
    - **④ 排查根因**
        - 业务恢复后深入排查：日志/监控/链路/现场
        - 定位根因（直接原因 + 深层原因）
    - **⑤ 复盘（RCA）**
        - 根因分析（`RCA`）：5 个为什么/时间线复盘
        - 改进项：整改措施（代码/配置/告警/流程）+ 落实人/时间
        - 沉淀：故障记录入库（同类故障参考）、优化告警/监控
    - **配套**
        - 值班/on-call 机制、故障预案（`SOP`：每一步该干啥）
        - 故障演练（`GameDay`：提前练，故障时更稳）

- **协助记忆**
    - 故障五步："分级（影响）→ 响应（上报分工）→ 止损（先恢复）→ 排查（根因）→ 复盘（改进）"。
    - 核心："先止损后排查，恢复优先于问责，复盘防复发"。

- **进阶思考**
    - **为什么"先止损"而不是"先查根因"？**
        - 故障中每一分钟都在损失（业务影响）：先恢复（回滚/重启/切换）让损失停止，再慢慢查根因。"先止血、后研究"——在现场纠结根因会拖长业务影响。
    - **P0 故障怎么响应（SOP）？**
        - ①立即建群上报（负责人/高管知情）②双人/多人分工（指挥/处理/通报）③按预案止损（回滚/切备/降级）④同步更新（进展定时通报）⑤恢复后排查+复盘。`P0` 要有"脚本化动作"（不用现场想）。
    - **复盘（RCA）怎么写才有用？**
        - 不只写"直接原因"，要挖"根本原因"（5 个为什么：为什么配置错？为什么没测到？为什么没告警？），每个根因对应改进项（落实人/时间），跟进闭环。"能防复发的复盘才有效"（避免形式主义）。

- **扩展信息**
    - **ITIL 事件管理 vs 故障管理**：事件管理（恢复服务，事件=故障+请求）；问题管理（找根因防复发）——本流程是"事件/故障处置 + 问题分析"结合
    - **工具**：值班系统（告警通知）、故障群（钉钉/企业微信）、`ITSM`（故障单）、事后复盘模板
    - **SRE 关联**：错误预算（=1−SLO，故障消耗后余额即剩余可用额度）、`MTTR`（恢复耗时指标）

## 🤔 监控告警流程  
- **监控告警流程是"监控建设→告警触发→响应处置→优化改进"的闭环，核心环节：①监控覆盖（指标/日志/可用性）②告警规则（阈值/分级/通知）③告警处置（接收/响应/关闭）④告警优化（降噪/收敛/评审）。核心：让告警"打得准（有效告警）、有人接（响应人）、能闭环（处置反馈）"。**  
    - **① 监控覆盖（先有数据）**
        - 基础设施监控（CPU/内存/磁盘/网络）、应用监控（接口/延迟/错误率）、日志监控、可用性探测（探活）
        - 告警来源：Prometheus/Zabbix/云监控/日志系统/拨测
    - **② 告警规则（怎么触发）**
        - 阈值告警：指标超过阈值（CPU>90%、错误率>X）——注意避免一味拍脑袋设阈值（要基于历史基线）
        - 分级：`P0`/`P1`/`P2`（按影响）——不同级别不同通知（`P0` 电话+群，`P1` 群，`P2` 邮件）
        - 通知渠道：钉钉/企业微信/Slack/短信/电话（按级别）
        - 抑制/聚合：同类告警合并（防告警风暴）、依赖抑制（根因告警优先）
    - **③ 告警处置（响应闭环）**
        - 接收：值班/on-call 收到告警
        - 确认：是否真实故障（误报/真故障）、定级
        - 响应：按故障流程处置（止损/排查）——对接故障处理流程
        - 关闭：解决后关闭/归档（记录处理过程）
    - **④ 告警优化（持续改进）**
        - 降噪：减少误报（阈值校准、告警疲劳）——"告警太多=没人看"
        - 收敛：重复告警合并、相关告警聚合（如主机挂了一条告警不要刷屏）
        - 评审：定期告警质量评审（有效的留、无效的删）
        - 度量：告警响应时间/误报率/告警数量趋势
    - **告警原则**
        - "每一个告警都应该能触发行动"（无行动的告警是噪音）
        - 告警分级对应响应（别所有告警都半夜叫人）

- **协助记忆**
    - 告警闭环："监控（有数据）→ 规则（怎么触发）→ 处置（有人接）→ 优化（不误报）"。
    - 一句话："告警要打得准、有人接、能闭环，太多=没人看"。

- **进阶思考**
    - **告警疲劳（Alert Fatigue）是什么？怎么治？**
        - 告警太多（大量误报/低价值）→ 值班人麻木/忽略 → 真故障漏掉。治：①阈值校准/基线化（减少误报）②分级（低级不半夜叫人）③聚合/抑制（减少刷屏）④定期评审（删无效告警）。"告警宁缺毋滥"。
    - **"告警应能触发行动"什么意思？**
        - 每条告警要有明确响应动作（谁处理/怎么办）：无行动的告警（如只看不处理的低危项）应该关掉/降级/自动化处理——否则就是噪音。告警设计=先想"收到后做什么"。
    - **告警和故障流程怎么衔接？**
        - 告警是"故障发现入口"：告警触发 → 值班确认（真实故障）→ 升级为故障流程（分级/止损/复盘）。好的告警=快准的故障发现（早发现早止损）。

- **扩展信息**
    - **告警体系工具**：Prometheus + Alertmanager（分组/抑制/静默）、Zabbix、云告警、日志告警（ELK/Loki）、拨测（黑盒）
    - **告警策略**：阈值+时间窗口（持续 N 分钟才告警，防抖动）、分级通知矩阵（级别→渠道→人）、SLO 告警（基于服务目标）
    - **值班机制**：on-call 轮值、告警升级（低级告警未确认逐级升级；`P0` 直接上报最高负责人）、告警日历（重保期间加强监控）

## 🤔 备份恢复流程  
- **备份恢复流程是"数据保护与灾难恢复"的标准流程，核心环节：①备份策略（范围/频率/保留）②备份执行与监控（成功/失败）③恢复演练（验证可用）④恢复处置（故障时恢复流程）⑤备份安全（加密/隔离）。核心："有备份、能恢复、定期验、安全存"——能恢复的备份才是备份。**  
    - **① 备份策略（设计）**
        - 备份范围：数据库/文件/配置/日志（按重要性分级保护）
        - 频率：全量+增量/差异组合（按数据重要性和 `RPO` 需求）
        - 保留：保留周期（N 天/月/年，按合规要求）
        - 3-2-1 原则：3 份数据、2 种介质、1 份异地；离线/气隙（`air-gap`）备份是防勒索的加强项（可另加）
    - **② 备份执行与监控（日常）**
        - 自动化执行（调度系统/cron/备份平台），避免人肉忘了
        - 监控：备份成功/失败告警（"欠备份=没备份"，失败必须发现）
        - 备份日志/记录（可追溯）
    - **③ 恢复演练（定期验证）**
        - 定期在测试环境做恢复演练（实恢复验证可用；也可辅以校验和、定期抽查备份可读性）
        - 演练发现问题（备份损坏/不完整/恢复太久）→ 修复
        - "能恢复的备份才是备份"（备份跑成功≠能恢复）
    - **④ 恢复处置（故障时）**
        - 根据故障场景选恢复点（PITR 到误删前/最新）
        - 执行恢复（按流程：停服务→恢复→校验→启动）
        - 恢复后验证（数据完整性/业务可用）
        - 记录恢复耗时（评估 `RTO` 达标）
    - **⑤ 备份安全**
        - 备份加密（防泄露）、备份与生产隔离（防勒索加密备份）
        - 权限管控（谁能访问备份）、异地/离线（防机房级灾难）
        - 定期验证备份可读性（抽查恢复小部分数据）

- **协助记忆**
    - 备份五环："策略（3-2-1）→ 执行（自动化）→ 演练（能恢复）→ 恢复（按流程）→ 安全（加密隔离）"。
    - 核心："有备份、能恢复、定期验、安全存"。

- **进阶思考**
    - **RPO/RTO 是什么（选备份频率的依据）？**
        - `RPO`（恢复点目标）：以时间量化的可接受数据丢失量（如 ≤15 分钟，决定备份频率）；`RTO`（恢复时间目标）：可接受的最长恢复时间（决定恢复手段：快照回滚/备机切换/恢复流程自动化）。备份策略按 `RPO`/`RTO` 定级。
    - **为什么"恢复演练"那么重要（很多人忽略）？**
        - 备份文件在，但可能：损坏/不完整/太久没验证/恢复方式变了——不演练就不知道"能不能真恢复"。灾难时刻才发现备份废了=最惨。定期演练（低频也可，但必须定期）是备份可靠性的唯一验证。
    - **勒索软件和备份有什么关系？**
        - 勒索会加密一切可写的备份：所以备份要"隔离 + 不可变"（离线/对象锁/`WORM`）——勒索后还有干净副本可恢复。"备份隔离"是防勒索的最后防线。

- **扩展信息**
    - **备份工具**：数据库备份（`xtrabackup`/`pg_dump`/Log PITR）、文件备份（rsync/restic/borg）、云快照、备份平台（Barman/pgBackRest/专业备份软件）
    - **RPO/RTO 概念**：恢复点目标/恢复时间目标（SRE/容灾基础概念）
    - **容灾等级**：本地备份（单机房）→ 异地备份（跨机房）→ 异地双活（同步运行）——按成本/需求选

## 🤔 权限申请流程  
- **权限申请流程是"生产/敏感系统访问权限的受控授予"流程，核心环节：①申请（说明用途/范围/期限）②审批（按权限级别授权人）③开通（最小权限实施）④登记审计（记录/定期复核）⑤回收（过期/离职即收回）。核心：权限要"申请有据、最小授权、可审计、及时回收"。**  
    - **① 权限申请**
        - 申请人填写申请单：系统/资源、所需权限（读/写/执行）、用途说明、期限（永久/临时）
        - 最小权限原则：申请"够用"的权限（不是最大权限）
        - 临时权限：明确到期时间（到期自动回收）
    - **② 权限审批**
        - 按权限级别分级审批：普通权限（直属负责人）、敏感/核心权限（安全/高级审批）
        - 审批人确认：用途合理、权限匹配岗位职责
        - 高风险权限（root/管理员/生产写）单独审批（双人）
    - **③ 开通（实施）**
        - 按审批结果开通（最小权限落地：只给申请的）
        - 开通记录（谁/何时/开了什么）
        - 高权限操作走堡垒机（操作审计）
    - **④ 登记与审计**
        - 权限台账（所有人/系统/权限清单）
        - 定期复核（季度/半年）：权限是否仍然需要（多余权限回收）
        - 审计：权限与实际岗位匹配检查（防越权）
    - **⑤ 权限回收**
        - 离职/调岗：立即回收（离职清单必做项）
        - 过期权限：临时权限到期自动回收
        - 长期未用权限：复核时回收
    - **配套**
        - 权限管理平台（统一申请/审批/回收）、账号唯一（一人一号禁共享）
        - 特权账号管理（`PAM`：托管密码/定期轮换）

- **协助记忆**
    - 权限五环："申请（用途）→ 审批（分级）→ 开通（最小）→ 登记（审计）→ 回收（及时）"。
    - 核心："最小授权 + 可审计 + 及时回收，离职必回收"。

- **进阶思考**
    - **为什么"最小权限"是权限管理第一原则？**
        - 权限越大风险越大（泄露/滥用/越权影响大）：只给够用的权限，把"被攻破/被滥用后"的破坏面降到最小。这也是等保/信息安全的基础要求。
    - **离职权限为什么"必须立即回收"？**
        - 离职人员掌握旧权限 = 潜在风险（不满员工/账号被其他人拿去）：离职当天回收（离职流程红线）。权限回收不及时是常见安全漏洞。
    - **权限审计怎么做（能不能"过度授权"被发现）？**
        - 定期（季度/半年）把权限台账与岗位对照：发现"岗位不需要的权限/多余账号/长期未用权限"→ 回收。配合登录日志（谁用权限干了啥）审计。

- **扩展信息**
    - **权限管理模型**：RBAC（基于角色授权，主流）、ABAC（基于属性，细粒度）；最小权限/按需申请/定期复审是落地要点
    - **工具**：权限/工单系统（ITSM）、堡垒机（操作审计）、`PAM`（特权账号：托管密码/轮换/双人）、LDAP/AD（统一账号）
    - **合规**：等保 2.0 对访问控制（最小权限/三员分立）有明确要求

## 🤔 事件管理流程  
- **事件管理流程是"恢复被中断/降级的 IT 服务"的标准流程（`ITIL` 事件管理），核心环节：①事件发现（告警/用户报障/巡检）②事件记录（登记信息/优先级）③分类与支持（分线支持/分派）④处理与恢复（处置/解决）⑤关闭与回顾。核心：尽快恢复服务（优先级按影响），记录全过程（可追溯）。**  
    - **① 事件发现**
        - 告警（监控触发）、用户报障（工单/电话）、巡检发现
        - 事件来源多，统一入口（服务台/工单系统）
    - **② 事件记录**
        - 登记：事件描述、影响范围、优先级（`P1`-P4）、发生时间
        - 单据：事件工单（编号可追踪）
    - **③ 分类与分派**
        - 分类：按系统/类型（网络/服务器/应用/数据库）
        - 分线支持：一线（服务台：答疑/简单处理）→ 二线（技术团队）→ 三线（专家/厂商）
        - 分派：按分类派给对应负责人
    - **④ 处理与恢复**
        - 按优先级响应（`P1` 立即、P4 常规）
        - 诊断/处理（接故障处理流程：止损/排查）
        - 解决后验证（服务恢复确认）
    - **⑤ 关闭与回顾**
        - 关闭：确认恢复 + 记录解决方案（知识库沉淀）
        - 回顾：重要事件回顾（根因/改进）；普通事件归档
    - **事件 vs 故障 vs 问题（ITIL 概念区分）**
        - 事件（Incident）：计划外服务中断或质量下降（恢复动作）；服务请求（Service Request）非故障引发（如申请权限），走独立的请求履行流程——二者并列
        - 问题（Problem）：一个或多个事件的（潜在）原因（问题管理：预防动作）；"故障"是国内俗称，对应事件的"原因"层面，非 `ITIL` 独立类目
    - **配套**
        - 服务台（统一入口）、工单系统（记录流转）、`SLA`（响应/解决时限）、知识库（解决方案沉淀）

- **协助记忆**
    - 事件五步："发现（入口）→ 记录（单据）→ 分派（分线）→ 恢复（处理）→ 关闭（沉淀）"。
    - 核心："快点恢复（优先级）+ 留痕迹（全程记录）+ 沉淀（知识库）"。

- **进阶思考**
    - **事件管理和故障处理什么关系？**
        - 事件管理是"流程框架"（发现→记录→分派→关闭）；故障处理是"事件里的技术处置"（分级→止损→排查→复盘）。事件管理管"单子的流转"，故障处理管"现场的技术动作"——事件启动故障处理流程。
    - **一、二线支持怎么分（为什么分层）？**
        - 一线（服务台）：接单/答疑/简单修复（快速响应常见问题）；二线（技术团队）：技术故障处置；三线（专家/厂商）：疑难/产品缺陷。分层让"普通问题快速处理（一线），复杂问题专家接手（二线/三线）"——效率与资源匹配。
    - **SLA（服务级别协议）在事件管理的意义？**
        - `SLA` 定义响应/解决时限（如 `P1` 响应 15 分钟、解决 4 小时）——事件管理按优先级对照 `SLA` 响应，防止"重要事件被慢处理"。`SLA` 达成情况也是 IT 服务质量考核。

- **扩展信息**
    - **ITIL 事件管理**：ITIL 是 IT 服务管理最佳实践框架；`ITIL` 4（2019）改为 34 项实践（事件管理/问题管理/变更使能 Change Enablement 等，不再称"五大流程"），事件管理是"恢复服务"核心实践
    - **工具**：工单/ITSM 系统（Jira Service Management/`ServiceNow`/自建运维平台）、服务台、知识库
    - **指标**：事件量/平均响应时间/平均解决时间（MTTR，此处取 Resolve 义）/`SLA` 达成率/重复事件率

## 🤔 应急响应流程  
- **应急响应流程是"突发重大事件（安全事件/重大故障/灾难）的紧急处置流程"，核心环节：①启动（判定/拉响/建组）②控制（隔离/止损/防扩散）③处置（恢复/加固）④取证与分析（安全事件）⑤恢复与事后（复盘/改进/报告）。核心："快速控制事态 + 按预案处置 + 保留证据 + 复盘改进"。**  
    - **① 启动（应急响应触发）**
        - 触发条件：重大故障（`P0`）/安全事件（入侵/勒索/数据泄露）/灾难（机房/自然灾害）
        - 拉响应急：建应急组（指挥/处置/联络）、上报管理层
        - 按应急预案（预案要有：角色/步骤/联络方式）
    - **② 控制（先控事态）**
        - 隔离：断网/隔离受影响系统（防扩散，尤其安全事件）
        - 止损：暂停服务/切备份/降级（业务影响最小化）
        - 防扩散：封锁入口（安全事件：改密/封 IP/下线
    - **③ 处置（恢复/加固）**
        - 恢复业务：按预案恢复（备份/切换/重建）
        - 加固：修补漏洞/清理后门/变更口令（防止二次入侵）
    - **④ 取证与分析（安全事件重点）**
        - 保留现场（日志/内存/磁盘快照，勿急着重启）
        - 取证分析（入侵途径/影响范围/数据是否泄露）
        - 法律/合规（泄露上报监管）
    - **⑤ 恢复与事后**
        - 业务恢复确认、观察期（防复发）
        - 复盘（`RCA`）+ 改进（流程/防护/预案更新）
        - 报告：向上级/监管汇报（安全事件）
    - **与故障处理的区别**
        - 故障处理：以技术恢复为主（业务视角）
        - 应急响应：更高规格（重大/安全事件：建组/上报/取证/报告——流程更官方/更重）

- **协助记忆**
    - 应急五步："启动（建组上报）→ 控制（隔离止损）→ 处置（恢复加固）→ 取证（安全事件）→ 复盘（改进报告）"。
    - 核心："快控事态、按预案走、安全事件保证据、事后改进"。

- **进阶思考**
    - **应急响应和"故障处理"什么时候切换（边界）？**
        - 普通故障走故障处理（技术处置）；升级到"重大/安全/危机"（`P0`、安全事件、影响面大）→ 启动应急响应（建组/上报/官方记录）。边界 = 严重程度/事件性质（安全事件几乎都走应急）。
    - **安全应急为什么"先保留证据"？**
        - 入侵/勒索等要溯源追责/法律诉讼：日志/镜像/现场是证据（被清理就没了）。处置顺序：先隔离（防扩散）+保全证据（快照/日志备份）→ 再处置。"别急着重启"（清掉现场）。
    - **应急预案为什么必须"定期演练"？**
        - 预案不练=纸上谈兵（真出事时手忙脚乱/预案过时）。演练暴露问题（角色不清/步骤不通/联络失效）→ 修订预案。`GameDay`/安全演练让应急"肌肉记忆"化。

- **扩展信息**
    - **应急响应框架**：NIST SP 800-61 Rev.2 四阶段（准备；检测与分析；遏制/根除/恢复（合并为一阶段）；事后活动）——国际通用安全应急标准
    - **安全事件分类**：入侵/勒索（Ransomware）/数据泄露/DDoS/钓鱼内鬼——按类型预案不同
    - **配套**：应急预案库（分场景 SOP）、应急小组名单/联系方式、应急物资（备用机器/离线备份）；
        - 注：`GameDay` 源自 AWS，属故障注入式弹性演练（非安全应急演练专属术语），安全应急演练另称桌面推演/应急演练

## 🤔 巡检管理流程  
- **巡检管理流程是"通过定期检查发现隐患、保障系统健康运行的预防性流程"，核心环节：①巡检计划（范围/频率/清单）②巡检执行（按清单检查）③记录与异常（发现/登记问题）④处理闭环（异常跟进解决）⑤报告与改进（周报/月报/优化）。核心："有计划、按清单、发现问题、闭环处理"——变被动救火为主动预防。**  
    - **① 巡检计划（定什么/多久）**
        - 范围：基础设施（机房/电源/硬件）、系统（主机/服务）、业务（应用可用性）、安全（日志/漏洞）等
        - 频率：日检（核心资源）、周检（基础设施）、月检（全面）——按重要性
        - 清单化：每个巡检项有明确标准（检查什么/正常标准/异常判断）
    - **② 巡检执行（按清单）**
        - 按巡检清单逐项检查（人工或工具辅助）
        - 工具化：监控指标核对/巡检脚本（自动出报告）/拨测
        - 巡检注意：轻影响（巡检别搞挂业务）
    - **③ 记录与异常**
        - 巡检结果记录（巡检表/系统留痕）
        - 异常登记：发现问题（现象/影响/疑似原因）→ 转问题/工单
        - 重大隐患立即上报（不等巡检结束）
    - **④ 处理闭环**
        - 巡检发现问题进入处理流程（工单/变更/维护）
        - 跟踪：问题关闭确认（处理完验证）
        - 防止"巡检发现问题没人管"（登记→跟踪→闭环）
    - **⑤ 报告与改进**
        - 巡检周报/月报（健康度/问题统计/趋势）
        - 持续优化巡检项（新增风险点/去掉无用项）
        - 隐患预防（巡检发现的趋势性问题提前处理）
    - **巡检价值**
        - 预防性维护：隐患早发现（比故障后处理成本低）
        - 数据积累：健康度趋势（容量规划/老化预判）

- **协助记忆**
    - 巡检五步："计划（清单）→ 执行（按项）→ 记录（异常登记）→ 闭环（处理跟进）→ 报告（改进）"。
    - 核心："有计划按清单、发现即登记、处理必闭环"。

- **进阶思考**
    - **巡检和监控什么区别（都要吗）？**
        - 监控：实时自动（指标/告警，7x24 值守、被动等告警触发）；巡检：定期主动探测（人工/脚本按清单检，查监控覆盖不到/静态项：硬件/机房/配置/安全）。互补：监控看"实时的"，巡检看"周期性的/摸不到的"。
    - **巡检怎么"不流于形式"（走过场）？**
        - ①清单要具体（检查项带正常标准，不是"看看"）②记录留痕（可追溯/可审计）③异常闭环（发现必处理，不是记了就完）④巡检项定期更新（跟系统演进）。"有标准的检查 + 闭环的处理"才有效。
    - **巡检发现问题的"优先级"怎么定？**
        - 按影响/风险：高危隐患（安全/可用性）→ 立即处理；中危（性能隐患/隐患）→ 排期处理；低危（优化项）→ 记录跟踪。巡检项不同级别对应不同响应。

- **扩展信息**
    - **巡检工具**：人工巡检表、巡检自动化脚本（采集指标出报告）、监控系统（Prometheus/Zabbix 做基线核对）、机房巡检（温湿度/电力/硬件灯）
    - **巡检项示例**：磁盘空间、服务状态、日志错误、备份结果、证书有效期、硬件状态、安全补丁
    - **结合 CMDB**：巡检对象从 CMDB 取配置项与关系（结合资产系统确定巡检范围）——与配置管理联动

## 🤔 工单管理流程  
- **工单管理流程是"IT 服务请求/问题的统一受理、流转、处理与关闭"流程（服务台核心），核心环节：①工单创建（用户提交/系统生成）②分派（按类别派给处理人）③处理（按 `SLA` 处理/沟通）④关闭（解决方案记录）⑤统计改进（工单数据分析）。核心："统一入口、过程留痕、`SLA` 保障、可统计改进"。**  
    - **① 工单创建（统一入口）**
        - 用户提交（门户/工单系统/电话转人工创建）
        - 系统生成（告警自动建单）
        - 记录要素：描述、影响、优先级、提交人/时间
    - **② 分派**
        - 按类别/系统分派（网络/主机/应用/权限/需求）
        - 派给对应处理组/人（按负载/技能）
        - 自动分派（按规则）或人工（服务台）
    - **③ 处理（按 SLA）**
        - 响应：确认收到（`SLA` 时限内响应）
        - 处理：诊断/操作（普通处理 or 升级为事件/变更）
        - 沟通：处理进展反馈用户（重要工单）
    - **④ 关闭**
        - 解决后用户确认（满意度）/处理人关闭
        - 记录解决方案（知识库沉淀——同类问题可复用）
    - **⑤ 统计与改进**
        - 工单分析：数量/类型分布/处理时长/`SLA` 达成率
        - 发现高频问题（重复工单多 = 需要根因处理/自助化）
        - 改进：服务优化（高频问题做知识库/自助、工具优化）
    - **工单类型**
        - 服务请求（Service Request：非故障的用户诉求，如申请权限）与事件（Incident：计划外中断/质量下降，如故障报修）走服务台工单；变更走独立变更流程（可同平台）——不同类型不同流程

- **协助记忆**
    - 工单五步："创建（入口）→ 分派（归类）→ 处理（`SLA`）→ 关闭（沉淀）→ 统计（改进）"。
    - 核心："统一入口、全程留痕、`SLA` 响应、数据分析改进"。

- **进阶思考**
    - **工单和事件/变更什么关系？**
        - 工单是"载体"（所有服务请求的单据形式）；事件/变更是"类型"（工单分成：服务请求/故障事件/变更单）。一个故障=一个事件工单；一个发布=一个变更单。工单系统统一承载。
    - **高频重复工单说明什么？怎么处理？**
        - 说明"有反复出现的问题没根治"（或用户不会自助）：①根因处理（问题管理：解决重复源）②知识库/自助（用户自己查：FAQ/自助申请）③工具优化（常见操作自动化）。重复工单是"改进信号"。
    - **SLA 未达标怎么办？**
        - 看原因：人力不足（增员/排班）、流程堵（等待审批/依赖）、工具差（操作繁琐）→ 针对性优化；`SLA` 本身不合理（太紧）也要复盘调整。"`SLA` 是管理抓手，不是摆设"。

- **扩展信息**
    - **工单系统**：ITSM 平台（Jira Service Management/`ServiceNow`）、轻量（自建工单/OA 表单）、客服系统——核心：记录、流转、`SLA`、统计
    - **SLA 要素**：响应时限（首次回应）、处理时限（解决时长）、升级规则（超时升级）
    - **结合知识库**：工单解决 → 记入知识库（solution）→ 下回同类秒答（减少重复工单）

## 🤔 日志管理流程  
- **日志管理流程是"日志全生命周期的规范管理"，核心环节：①日志采集（哪些系统/什么日志）②集中存储（收集到日志平台）③安全与保留（备份/加密/留存期）④分析与告警（排障/安全监控）⑤审计合规（可追溯）。核心：日志"采得到、存得住、查得快、保安全、可审计"。**  
    - **① 日志采集（采什么）**
        - 范围：系统日志（syslog）、应用日志、数据库日志、安全日志（登录/审计）、网络设备日志
        - 采集方式：Agent 采集（`Filebeat`/fluentd）、syslog 转发、云日志
        - 覆盖度：核心系统全采，避免"出事没日志"（排查/取证靠日志）
    - **② 集中存储（存哪）**
        - 日志平台：ELK（`Elasticsearch` + `Logstash` + `Kibana`，严格定义；Loki 属 `Grafana` 栈，配 `Promtail` 采集 + `Grafana` 展示）、`Splunk`、云日志服务
        - 集中管理：分散的日志汇聚到平台（搜索/分析/告警统一）
        - 索引/生命周期：日志量大（索引管理、热冷分层、过期清理）
    - **③ 安全与保留**
        - 保留期：按合规（《网络安全法》第 21 条网络日志不少于 6 个月、等保 2.0 审计记录留存≥6 个月）、业务需求
        - 防篡改：日志权限控制（谁能删/改）、安全日志不可删（审计）
        - 传输/存储加密（敏感日志）
    - **④ 分析与告警**
        - 排障：搜索/关联（排查问题时查日志）
        - 安全监控：日志告警（异常登录/攻击特征/错误风暴）
        - 分析：错误率趋势/慢请求/容量
    - **⑤ 审计合规**
        - 审计日志（谁做了什么）可追溯
        - 配合安全事件取证（日志是证据）
    - **日志管理要点**
        - 日志格式标准化（统一字段：时间/级别/来源）、时间同步（`NTP`，时间戳一致）
        - 别忘"日志本身的安全"（别被攻击者清日志——异地/集中日志更安全）

- **协助记忆**
    - 日志五环："采集（覆盖）→ 集中（平台）→ 安全（保留/防篡改）→ 分析（告警）→ 审计（合规）"。
    - 核心："采得到、存得住、查得快、防篡改、可审计"。

- **进阶思考**
    - **为什么日志要"集中管理"（不只存在本机）？**
        - ①排障效率（一处搜全部，不用逐台翻）②安全（本机日志可能被攻击者清掉，集中日志是安全证据）③分析能力（关联分析/告警）。"日志上收"是运维和安全的基本功。
    - **日志保留期怎么定（合规+成本平衡）？**
        - 合规底线（等保：日志留存≥6 个月；金融/监管有更长要求）+ 业务需要（排障/审计）→ 按级别（安全日志长留、普通日志短期）+ 成本（热冷分层：热日志快查、冷日志归档）。"合规留够、成本可控"。
    - **日志被攻击者清理怎么办（防清日志）？**
        - ①实时上收（集中日志：清本机没用，平台有）②权限管控（谁能删日志）③安全日志独立（防篡改 `WORM`/不可变）④日志完整性校验（检测被改）。集中 + 防篡改是防清日志的关键。

- **扩展信息**
    - **日志工具**：ELK（Elasticsearch+Logstash+`Kibana`，可加 `Kafka` 缓冲）、Loki+`Grafana`+`Promtail`（轻量日志栈）、`Fluentd`/`Filebeat`（采集，`Promtail` 是 Loki 对应采集器）、`Splunk`（商业）、云日志（阿里云 SLS）
    - **日志类型**：系统/应用/安全/审计/容器（K8s：Containers/Loki）/云（云平台日志）
    - **相关**：日志标准化（JSON 结构化）、NTP 时间同步（日志时间一致）、日志脱敏（敏感信息）

## 🤔 日常操作规范流程  
- **日常操作规范是"运维日常操作的标准化行为准则"，核心环节：①操作前（评估/审批/备份）②操作中（按流程/双人/记录）③操作后（验证/总结）④习惯类规范（登录/文档/安全习惯）⑤违规与改进。核心：让日常操作"有章可循、可追溯、不出事"——规范是防"小操作酿大祸"。**  
    - **① 操作前（准备）**
        - 评估：操作影响（改了什么/影响哪些服务）、风险（回滚/备份）
        - 审批：重要操作按权限/变更流程申请（非随意）
        - 备份/预案：关键操作前备份/准备回滚
        - 窗口：影响业务的操作用户操作窗口（低峰）
    - **② 操作中（执行）**
        - 按 `SOP`/操作手册执行（别凭记忆乱来）
        - 双人复核（高风险操作：执行+确认）
        - 实时观察（操作中看监控/日志）
        - 记录（谁/何时/做了什么/结果）
    - **③ 操作后（验证收尾）**
        - 验证：操作结果确认（服务正常/功能可用）
        - 收尾：更新文档/记录、通知相关人员
        - 异常处理：操作失败按预案回滚/上报
    - **④ 习惯类规范（日常遵守）**
        - 登录规范：堡垒机接入（不用 root 直连）、密码/密钥安全
        - 文档习惯：操作留痕（变更记录/维护手册更新）
        - 安全习惯：不明命令不执行、生产操作谨慎、不测试环境混生产
    - **⑤ 违规与改进**
        - 违规纠正（操作事故复盘/教育），规范持续更新（踩坑补规范）

- **协助记忆**
    - 日常操作规范："操作前（评估备份）→ 操作中（按流程双人）→ 操作后（验证记录）+ 习惯（堡垒机/文档）"。
    - 一句话："小操作也要按规来——评估、备份、留痕、验证"。

- **进阶思考**
    - **"操作前备份/回滚预案"为什么不能省（哪怕小操作）？**
        - 很多生产事故是"小操作"引发的（改个配置/删个文件/重启个服务），没预案出错就抓瞎。备份/预案 = 出错的后路；有后路才敢动（无后路的操作=裸奔）。
    - **"双人复核"适用什么操作？**
        - 高风险/不可逆操作（删库/删目录/改生产配置/发布）：一人执行、一人确认（防手滑/防误判）——双保险。普通低频操作可单人+记录。
    - **规范和效率怎么平衡（别让规范拖死）？**
        - 分级：高风险严控（双人/审批/预案）、低风险轻放（记录即可）——规范为"风险"服务不是为"繁琐"服务。谈效率前先保障不失手（事故比慢更贵）。

- **扩展信息**
    - **规范载体**：SOP（标准操作流程）、操作手册（Runbook）、变更流程、堡垒机审计——把规范沉淀成文档+工具约束
    - **关联**：运维操作"留痕可审计"（等保要求）、操作失误复盘（防再犯）、自动化（把常操作脚本化减少人犯机会）

## 🤔 安全运维流程  
- **安全运维流程是"把安全融入日常运维"的流程体系（`DevSecOps`/安全运营），核心环节：①安全基线（加固标准）②漏洞管理（扫描/修复闭环）③安全监控（入侵检测/告警）④安全事件响应（排查/上报/处置）⑤合规审计（等保/安全检查）。核心："运维系统先合规（基线加固），安全风险（漏洞/攻击）及时发现闭环处理"。**  
    - **① 安全基线（默认安全）**
        - 系统加固基线（`CIS` 等）：账号/权限/SSH/防火墙/服务最小化/补丁
        - 新系统上线前按基线加固（安全检查门禁）
        - 定期基线核查（漂移检查）
    - **② 漏洞管理（闭环）**
        - 漏洞扫描（定期）：系统/应用/镜像/数据库扫描（`Nessus`/`OpenVAS`/`Trivy`）
        - 漏洞评估分级（高危/中危/低危）→ 修复排期（高危优先）
        - 修复验证（重扫确认）——"扫描发现≠修完"，要闭环
    - **③ 安全监控（持续防护）**
        - 入侵检测：主机（`EDR`/`HIDS`）、网络（IDS/IPS）、安全告警（异常登录/攻击特征）
        - 日志安全分析（`SIEM`：安全日志关联）
        - 安全告警响应（确认/处置/升级）
    - **④ 安全事件响应**
        - 安全事件（入侵/勒索/泄露）→ 应急响应流程（隔离/取证/处置/上报）
        - 与其他流程衔接（事件→应急）
    - **⑤ 合规审计**
        - 等保 2.0（合规基线/测评）、安全审计（权限/日志/操作记录）
        - 定期安全评估（渗透测试/红队）
    - **配套**
        - 安全意识培训、安全制度（密码/权限/外设）、`DevSecOps`（安全嵌入 CI）

- **协助记忆**
    - 安全运维五环："基线（加固）→ 漏洞（闭环）→ 监控（发现）→ 事件（响应）→ 合规（审计）"。
    - 核心："先合规加固（基线），再持续防护（扫描/监控），事件及时处置"。

- **进阶思考**
    - **"安全基线"和"漏洞管理"的区别？**
        - 基线是"配置标准"（系统怎么配才算安全：权限/SSH/防火墙）——静态预防；漏洞是"软件缺陷"（CVE）——动态修复。基线管"配置"、漏洞管"软件"，两者都要（加固 + 补丁）。
    - **高危漏洞修复为什么"要快但不能乱"？**
        - 高危漏洞（可被利用/已公开）要快速修复（趁攻击者没利用），但也要走流程（测试/灰度/回滚——修复引入新问题更糟）。"快速但受控"：先缓解（`WAF`/禁用功能）再排期修复（补丁测试后上）。
    - **安全监控和运维监控什么关系？**
        - 重叠但不冲突：运维监控管"可用性"（服务/资源）；安全监控管"被攻击"（入侵/异常行为）。一套监控体系两类关注：安全日志/告警（登录/攻击/异常流量）在运维监控上叠加安全视角。

- **扩展信息**
    - **安全工具链**：扫描（Nessus/OpenVAS/Trivy）、`HIDS`（主机入侵检测，以检测为主）/`EDR`（端点检测响应，检测+处置）、`SIEM`（安全日志分析）、`WAF`（Web 防护）、堡垒机（审计）、防病毒
    - **合规**：等保 2.0（《网络安全法》要求开展等级保护与测评）、ISO 27001、`CIS` Benchmarks——安全运维的"标准要求"
    - **与安全文件交叉**：详细安全措施参考"运维常见题-网络安全.md"（入侵排查/加固/基线）

## 🤔 资产管理流程  
- **资产管理流程是"IT 资产（硬件/软件/服务）全生命周期管理"流程，核心环节：①资产入库（登记）②资产分类（类型/归属/重要性）③生命周期管理（领用/变更/报废）④清点核对（定期盘点）⑤与 `CMDB`/财务联动。核心："资产有台账（登记）、状态清楚（在用/闲置/报废）、期期盘点（账实一致）"。**  
    - **① 资产入库（登记）**
        - 新资产登记：服务器/网络设备/软件 license/云资源/终端
        - 登记要素：资产编号/型号配置/IP/位置/负责人/采购信息
        - 入口统一（采购/上架即登记）
    - **② 资产分类**
        - 类型分类：硬件（服务器/网络/存储）、软件（License/中间件）、云资源、终端
        - 重要性分类：核心资产（数据库/核心业务）重点管理/保护
        - 归属：负责人（谁拥有/谁维护）
    - **③ 生命周期管理**
        - 领用/上架（登记使用人/位置）、变更（配置/位置/状态更新）
        - 维修/借用（状态记录）、报废（登记报废/安全处理：数据清除）
        - 关键：状态实时更新（资产状态准确）
    - **④ 清点核对（定期盘点）**
        - 定期盘点（半年/年度）：实物与台账核对（账实一致）
        - 发现差异（丢失/空闲/未登记）→ 处理
        - 自动化辅助（采集系统资产/云资产自动同步）
    - **⑤ 与 CMDB/财务联动**
        - 资产是 CI（配置项）的数据源之一（但不完全等价：资产是财务/实物视角、CI 是配置/服务视角，物理资产与逻辑 CI 常一对多）
        - 与财务联动（资产折旧/成本核算）
        - 与安全联动（报废设备数据清理、退役系统下线）
    - **价值**
        - 资产状况清楚（多少/在哪/谁用）——容量/成本/安全依据

- **协助记忆**
    - 资产五环："入库（登记）→ 分类（重要性）→ 生命周期（状态更新）→ 盘点（账实一致）→ 联动（`CMDB`/财务）"。
    - 核心："有台账、状态准、定期盘、重点资产重点管"。

- **进阶思考**
    - **资产台账和 CMDB 什么关系？**
        - 资产台账管"实例清单"（有哪些设备/状态）；`CMDB` 管"配置关系"（设备之间的依赖/拓扑/配置项）。资产是 `CMDB` 的"基础数据"（`CMDB` 的 CI 来自资产），`CMDB` 在资产之上加"关系"——互补（台账管资产本身，`CMDB` 管资产间关系）。
    - **盘点为什么必须（不能只建台账）？**
        - 台账不盘会"失实"（设备挪了/闲置/丢失/没登记——台账成了摆设）：盘点发现账实差异 → 修正（保证数据可信；安全上防"影子资产"——不知名的资产=风险）。"不定盘点的台账会烂掉"。
    - **"影子 IT"（Shadow IT）是什么风险？**
        - 员工自己买/薅的未登记资产（设备/云资源/软件）不在管理内：没安全保护/没监控/可能是风险缺口。资产管理要覆盖/发现影子资产（盘点+云账号审计）。

- **扩展信息**
    - **工具**：CMDB（资产配置库）、资产管理软件/ITAM（IT 资产管理）、云资源清单（云控制台）、自动采集（Agent 采集资产信息）
    - **资产属性**：编号/类别/状态（在用/空闲/报废）/位置/负责人/配置/维保/采购
    - **关联**：容量规划（资产现状决定采购）、成本管理（资产清点省预算）、安全（报废清数据）

## 🤔 配置管理流程（`CMDB`）  
- **配置管理流程（CMDB：配置管理数据库）是"管理 IT 配置项及其关系"的流程，核心环节：①配置项（CI）定义（哪些要管）②关系建模（依赖/拓扑）③数据维护（录入/更新/校验）④变更联动（配置随变更更新）⑤消费使用（排障/影响分析）。核心："配置项清楚 + 配置关系可查 = 排障定位/变更影响/合规依据"。**  
    - **① 配置项（CI）定义（管什么）**
        - CI 类型：服务器/网络/应用/数据库/中间件/服务（不只硬件，含软件/服务）
        - 属性：名称/IP/版本/负责人/环境/状态
        - 定级：核心 CI（重点维护准确性）
    - **② 关系建模（关联）**
        - CI 之间关系：依赖（应用依赖数据库）、拓扑（网络连接）、归属（谁部署在哪）
        - 关系价值：影响分析（改 A 影响谁）、排障定位（服务挂了查依赖）
    - **③ 数据维护（数据质量）**
        - 录入：初始盘点录入、自动化采集（Agent/云同步）
        - 更新：配置变更 → `CMDB` 同步更新（防"台账失真"）
        - 校验：定期核查（`CMDB` 与实际一致性）
    - **④ 变更联动（配置随变更新）**
        - 变更流程与 `CMDB` 联动：变更后更新配置项（不然 `CMDB` 过期）
        - 自动化：部署/配置平台自动更新（`IaC` 联动 `CMDB`）
    - **⑤ 消费使用（用起来）**
        - 排障：出问题时查 `CMDB`（服务依赖/影响面）
        - 变更影响分析：改某配置 → `CMDB` 查影响范围
        - 资产/容量规划/合规（配置记录）
    - **CMDB 价值**
        - 数据中心（配置信息统一可信）、关系可查（依赖/影响）、流程联动（变更/资产/排障）

- **协助记忆**
    - `CMDB` 五环："CI 定义（管什么）→ 关系（依赖）→ 维护（数据准）→ 联动（变更更新）→ 消费（排障/影响）"。
    - 核心："配置项准 + 关系可查 = 排障/影响分析靠它"。

- **进阶思考**
    - **CMDB 和资产台账怎么区分（常混淆）？**
        - 资产台账：管"实例本身"（号码/状态/负责人，有多少台）；`CMDB`：管"配置项 + 关系"（服务依赖哪些数据库/网络怎么连）。资产是 `CMDB` 数据源之一，`CMDB` 加上"关系/上下游"——"台账看清单，`CMDB` 看关系"
    - **CMDB 为什么容易"建了没人维护"（失真）？**
        - 录入麻烦/更新不及时/没人负责 → `CMDB` 数据过期 = 没人信 = 没人用（恶性循环）。破局：①自动化采集（少人工录入）②与变更/部署联动（自动更新）③定维护责任人 ④按核心 CI 优先保准。"`CMDB` 成败在数据新鲜度"。
    - **CMDB 在"影响分析"怎么用？**
        - 变更前：查该 CI 的上游/下游（应用→数据库依赖）→ 评估影响面；故障时：从"故障的 CI"顺关系查依赖（服务挂 → 哪个应用受影响/哪里是源头）。关系数据 = 影响分析的基础。

- **扩展信息**
    - **CMDB 工具**：专业 CMDB（ServiceNow、腾讯蓝鲸 `CMDB`、企业自建）、监控系统自带（Zabbix/Prometheus 可做部分 `CMDB`）、云资源管理（云控制台）、开源（`iTop`；`NetBox` 本质是 `DCIM`/`IPAM`，常被借用作 `CMDB`、但缺服务依赖建模）
    - **CI 属性**：标识/分类/状态/关系/负责人/环境/版本——数据质量（唯一标识/规则校验）
    - **与 ITIL**：配置管理在 ITIL v3/2011 的"服务资产与配置管理（SACM）"中是核心流程；`ITIL` 4 改为实践（practice），且将资产管理与配置管理拆分为独立实践——与事件/变更联动




---

> 作者: [0x5c0f](https://blog.0x5c0f.cc)  
> URL: https://blog.0x5c0f.cc/posts/other/%E8%BF%90%E7%BB%B4%E5%B8%B8%E8%A7%81%E9%A2%98-%E8%BF%90%E7%BB%B4%E6%B5%81%E7%A8%8B%E8%A7%84/