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

🤔 变更管理流程规范（完整阐述分级、评审、实施、回滚、复盘）

• 变更管理是对"生产环境的一切变更"（配置、发布、升级、扩容）进行受控管理的流程，核心环节：①分级（按影响面/风险分 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），且将资产管理与配置管理拆分为独立实践——与事件/变更联动