IT 管理与治理速查
ITIL 4 服务管理（事件/问题/变更/配置/SLA）、项目治理与 PMO、团队与 OKR、技术规划与预算、IT 审计与合规：IT 管理速查。
ITIL 与服务管理60 条
服务价值链、事件问题变更与 SLA
事件管理 Incident Management热门
事件管理的目标是以尽可能短的时间恢复约定服务，关注业务影响与恢复速度；根因彻底消除属于问题管理的职责。
错误预算 Error Budget热门
错误预算是 1 减去 SLO 的允许失败额度（如 SLO 99.9% 对应每月约 43 分钟），用于在可靠性与交付速度之间做量化权衡。
变更使能 Change Enablement热门
变更使能负责评估变更风险、授权实施与管理变更日程；目标不是阻止变更，而是让变更在受控前提下更多、更快地成功。
SLI/SLO/SLA 三层体系热门
SLI 是可测量的服务质量指标（如成功率、延迟），SLO 是内部目标值，SLA 是对外承诺；三者数值通常按 SLA 松于 SLO 的原则设计留出缓冲。
服务台 Service Desk
服务台是用户与 IT 之间的单一接触点（SPOC），负责记录、分类、初步处置与转派；常见渠道包括门户、电话、邮件、即时通讯与自助服务。
重大事件管理 Major Incident
重大事件需要预定义触发条件、专属指挥与沟通节奏；用时间线管理处置过程与业务沟通，避免多头指挥与信息断层。
服务请求管理 Service Request
服务请求是用户发起的预定义请求（如权限申请、软件安装、密码重置），按约定流程与时限处理，与故障类事件分开统计。
配置管理数据库 CMDB
CMDB 记录配置项及其关系，是影响分析、变更评估与事件定位的数据基础；数据准确性依赖流程约束与定期核查。
服务级别协议 SLA
SLA 是服务提供方与客户之间的书面协议：约定服务范围、级别目标、双方责任、测量口径与例外情形，是服务预期的基准。
ITIL 4 服务价值体系 SVS
ITIL 4 把服务管理的全部要素整合为服务价值体系（Service Value System）：指导原则、治理、服务价值链、实践与持续改进协同运作，把需求与机会转化为价值。
问题管理 Problem Management
问题管理通过识别事件的实际与潜在根因，管理工作区与已知错误，降低事件再次发生或影响扩大的概率。
可用性几个 9 与停机时长
可用性的几个 9 对应可接受的停机时长：99.9% 每月约 43 分钟，99.95% 约 21 分钟，99.99% 约 4 分钟；每提高一个 9，投入量级显著上升。
事件优先级矩阵
事件优先级由影响（影响多少用户与业务）与紧急度（恶化速度、有无临时方案）共同决定，P1-P4 是行业常见分级实践。
发布管理 Release Management
发布管理把一组变更打包为可交付版本并规划发布时间与内容；发布关注对用户可见的可用性，与部署动作相互独立。
错误预算政策 Error Budget Policy
错误预算政策把预算状态与工程动作绑定：预算充足时正常发布，快速消耗时收紧变更并投入可靠性工作，告急时冻结高风险发布。
RTO 与 RPO
RTO 是灾难后恢复服务的目标时间，RPO 是允许丢失的数据时间窗；两者共同决定灾备架构档次与投入规模，由业务影响分析确定。
服务价值链六项活动
服务价值链（Service Value Chain）用六项活动描述从需求到价值的流动：计划、改进、参与、设计与转换、获取与构建、交付与支持，可组合成不同价值流。
MTTR/MTBF/MTTA 指标族
MTTR 平均修复或恢复时间（口径必须声明）、MTBF 平均故障间隔、MTTA 平均响应确认时间、MTTF 平均到故障时间；口径不声明就没有可比性。
容量与绩效管理
容量与绩效管理通过容量趋势、性能基线与阈值设计，确保资源满足当前与可预见的需求；扩容触发要与业务节奏联动。
ITIL 与 DevOps/SRE 的结合
ITIL 与 DevOps/SRE 互补：变更使能按风险分级，低风险变更自动化直通、高风险保留审批；错误预算为变更控制提供数据化依据。
ITIL 4 七项指导原则
七项指导原则贯穿所有实践：聚焦价值、从现状出发、基于反馈迭代推进、协作并提升可视化、整体思考与工作、保持简单实用、优化与自动化。
变更咨询委员会 CAB
CAB 对常规变更做风险评估与排期协调，成员包含技术与业务代表；重点评审高风险变更，而非所有变更都上会。
部署管理 Deployment Management
部署管理负责把硬件、软件、文档等组件安装或移动到目标环境，强调自动化、可重复、可回退与全程留痕。
IT 资产管理 ITAM
ITAM 覆盖硬件与软件资产从采购、入库、领用到维保、退役的全生命周期，关注资产价值与许可合规，与 CMDB 的配置视角互补。
服务目录 Service Catalogue
服务目录面向用户呈现可以申请什么服务：名称、说明、适用对象、申请方式与时限；与服务请求管理衔接形成自助入口。
首次解决率 FCR
首次解决率衡量一次接触或一次指派内解决的比例，是服务台核心体验指标；统计前必须明确口径是首次接触还是首次指派。
持续服务改进 CSI
持续改进让改进成为常态：识别机会、排定优先级、跟踪落地并验证效果；ITIL 4 中对应持续改进实践，贯穿 SVS 全部组件。
Runbook 值班操作手册
Runbook 是面向值班人员的可执行操作手册：触发条件、前置检查、分步骤操作、验证点与回退路径，目标是让当班工程师安全处置。
ITIL 4 四个维度
ITIL 4 用组织与人员、信息与技术、合作伙伴与供应商、价值流与流程四个维度检查产品与服务的完整性，四个维度失衡会导致服务目标落空。
事件升级机制 Escalation
事件升级分功能升级（需要更高技术能力或权限）与层级升级（需要管理资源与业务决策）；升级规则应写入值班手册并自动化提醒。
变更风险评估方法
变更风险评估围绕影响范围、回退可行性、验证手段与实施窗口展开，输出分级结论以决定审批层级与实施方式。
发布与部署的区别
发布是让用户可用新功能（业务视角），部署是把代码放入环境（技术视角）；两者解耦后可以做到部署完成但暂不发布，降低上线风险。
SLA 达成统计与报告口径
SLA 达成统计需要明确测量点、排除项与争议处理：计划维护是否计入、按分钟还是按工单、部分降级如何折算，都要写进协议附件。
IT 服务连续性管理 ITSCM
ITSCM 保证重大灾难下关键服务在约定时间内恢复；以业务影响分析为输入，产出连续性计划、恢复策略与演练日程，通常纳入 BCM 体系。
值班 On-call 机制
值班机制设计包括轮值表、告警分级与路由、升级路径与补偿；目标是快速响应，同时避免值班人员被噪声打扰到疲劳。
ITIL 4 三十四项管理实践
ITIL 4 把管理能力归纳为 34 项实践：14 项通用管理、17 项服务管理、3 项技术管理，每项实践是人员、流程、技术与信息的组合。
标准变更 Standard Change
标准变更是预授权的低风险、重复性变更，按既定模板执行，无需逐次审批，但要保留执行记录并定期评审清单有效性。
紧急变更 Emergency Change
紧急变更为恢复服务或止损而走快速通道，由指定授权人（或 ECAB）审批；事后必须补全记录、复盘，并评估是否应转为常规流程。
配置项 CI 与关系建模
配置项关系描述服务、应用与组件之间的依赖（如应用依赖数据库与消息队列），是事件影响分析与变更上下游评估的关键数据。
可用性管理 Availability Management
可用性管理确保服务达到约定的可用性水平：制定可用性计划、管理维护窗口、验证冗余切换，并持续分析中断来源结构。
服务转换与上线移交
服务转换把新服务从项目移交给运营：文档、监控、值班、备份、容量与 SLA 承接逐项验收，避免上线即失控。
回退与应急预案设计
回退与应急预案定义变更失败时的止损路径：回退决策人、时间盒（多久未恢复就回退）、回退步骤与验证点，并在事前演练。
已知错误与 KEDB
已知错误是根因已定位、尚未永久修复的问题，需要记录症状、根因与临时方案；集中存放于 KEDB（已知错误数据库）供一线检索。
OLA 与 UC 支撑协议
OLA 是组织内部团队间的支持协议，UC 是与外部供应商的支撑合同；两者共同支撑 SLA 达成，把端到端承诺分解到各个环节。
可用性计算公式与约定服务时间
可用性 = 约定服务时间内的正常服务时长 / 约定服务时间；从组件视角可用性约等于 MTBF / (MTBF + MTTR)，提高可靠性要么拉长故障间隔、要么缩短恢复时间。
业务影响分析 BIA
BIA 识别关键业务功能、评估中断影响随时间的变化、确定恢复优先级与 RTO/RPO，是灾备与连续性投入的决策输入。
供应商管理 Supplier Management
供应商管理对供应商分层（战略/重要/一般）、定期评估绩效与风险、管理合同履约；关键供应商要有替代方案与退出预案。
服务设计（可运营性优先）
服务设计从用户与业务成果出发，把服务设计成可运营的：体验路径、可支持性、可监控性与成本在设计中确定，而不是上线后补救。
ITSM 工具选型要点
ITSM 工具选型看流程可配置性、CMDB 能力、自动化集成、知识库与报表、权限模型；工具是承载流程的容器，不是流程本身。
配置基线与漂移核查
配置基线是经过确认的配置状态快照，用于变更前后对比与合规核查；基线数据与自动发现数据的差异说明存在配置漂移。
服务组合管理 Service Portfolio
服务组合管理对组织全部服务做投资视角管理：区分为规划中、在管与拟退役服务，决定资源投向与退出策略。
需求管理（ITIL 语境）
需求管理理解并影响用户对服务的需求模式：识别波动、引导错峰、设计服务策略；ITIL v3 中为独立流程，ITIL 4 中融入服务级别管理等实践。
服务报告体系
服务报告按受众分层：运营层看工单与事件流水，管理层看 SLA 达成与趋势，战略层看价值与投入结构；报告是决策输入而非流水账。
价值共创与服务关系
ITIL 4 强调价值共创：服务价值由提供者与消费者在服务关系中共同创造；管理用户成果（outcome）比交付输出（output）更重要。
工单字段设计
工单字段遵循最小可用原则：类型、影响、紧急度、分类、渠道、状态与解决代码；字段过多拖慢录入，字段过少无法度量。
工单重开率
重开率是关单后短期内重新打开的比例，反映解决质量；与 FCR 搭配使用可以防止为冲指标而草率关闭工单。
改进登记册 Improvement Register
改进登记册集中记录改进机会：来源、优先级、负责人、目标、状态与验证结果；它是持续改进落地的最小管理载体。
服务验证与测试 SVT
SVT 确认新服务或变更满足业务与用户要求，覆盖功能、性能、安全与运营准备度验证，产出放行结论。
运维交接班管理
交接班保证处置连续性：口头同步加书面记录未闭环工单、进行中变更与已知风险，接班人对关键事项逐项确认。
服务级别评审会议
服务级别评审是客户与服务方定期回顾质量与预期的机制：输入 SLA 达成、重大事件与改进进展，输出优先级调整与改进承诺。
治理与研发流程57 条
项目治理、PMO 与研发度量
DORA 四项指标热门
DORA 四项指标衡量软件交付效能：部署频率、变更前置时间、变更失败率、故障恢复时间；两组分别反映速度与稳定性，可同时改善而非取舍。
无责复盘 Blameless Postmortem
无责复盘聚焦系统与流程而非个人：还原时间线、评估影响、分析根因与触发因素，产出有负责人与期限的行动项，并在组织内共享。
IT 治理 Corporate Governance of IT
IT 治理是指导和控制当前与未来 IT 使用的体系：确保 IT 支撑业务目标、风险可控、资源负责。ISO/IEC 38500 给出原则与模型，COBIT 提供可落地的目标体系。
COBIT 2019 框架概览
COBIT 2019 是 ISACA 的 IT 治理与管理框架：以 40 个治理与管理目标、7 大治理系统组件、设计因素与焦点领域为核心，用于裁剪出适合组织的治理体系。
持续交付流水线
持续交付把构建、测试、安全与部署串成一条自动化流水线，使每次提交都可能发布；部署流水线是生产部署的必经路径，人工操作仅保留在必要环节。
Scrum 框架要点
Scrum 以固定时间盒的 Sprint 组织交付：团队含产品负责人、Scrum Master 与开发者，通过 Sprint 规划、每日站会、评审与回顾运行；工件为产品待办、Sprint 待办与增量。
IT 决策委员会与决策机制
IT 决策委员会（Steering Committee）由业务与 IT 高层组成，对投资、优先级与重大风险做决策；有效运行的关键是议程模板、决策记录与事项闭环。
看板方法与 WIP 限制
看板以可视化流程、限制在制品（WIP）、管理流动为核心：显式流程规则、限制并行数量、度量周期时间与吞吐量，适用于持续流动型工作。
DORA 研究的主要发现
DORA 年度报告持续验证：交付效能与组织绩效相关；速度与稳定性可以兼得；平台工程、云与 AI 采用是近年研究主题；个体效率提升不自动等于交付性能提升。
主干开发 Trunk-Based Development
主干开发要求开发者频繁把改动合并进主干，分支生命期尽量短（理想情况下一天以内）；配合特性开关与自动化测试，减少合并冲突与集成风险。
代码评审机制
代码评审用于找缺陷、传播知识与统一规范；有效实践包括小批量提交（小 PR）、自动化检查先行、明确评审时限与责任，避免评审成为瓶颈。
发布策略：蓝绿、金丝雀与滚动
常见发布策略：蓝绿用两套环境切换流量；金丝雀按比例逐步放量并观察指标；滚动更新逐批替换实例；选择取决于回退要求、资源成本与验证能力。
技术债 Technical Debt
技术债是为短期交付选择权宜方案后需偿还的额外成本。管理要点是让债务可见、可量化、有偿还计划，常见分类包括代码债、架构债、测试债、文档债与环境债。
决策权分配：谁决定什么
决策权分配明确不同事项由谁决策：投资与立项、架构与技术选型、优先级与排期、上线放行；目标是减少等待与重复讨论，同时保留必要制衡。
产品制与项目制
项目制以临时团队交付后解散，产品制以长期团队持续对成果负责；数字化时代更强调产品制：固定团队、持续迭代、端到端负责，减少交接损耗。
敏捷治理：控制与适应性的平衡
敏捷治理用轻量、自动化的控制替代重审批：风险分级、自动化证据采集、可视化度量；目标是既不拖慢交付，又保留必要的监督与追溯。
加速：支撑高绩效的能力
《Accelerate》研究识别出一组支撑高绩效的技术与管理实践：版本控制、自动化测试、持续集成、主干开发、部署自动化、监控、轻量变更审批与 WIP 限制等。
平台工程 Platform Engineering
平台工程把内部基础设施能力做成自助式产品，减少研发团队的运维负担；常见载体是内部开发者平台（IDP）与黄金路径，目标是降低认知负荷并缩短交付前置时间。
三层治理结构：战略-管理-执行
治理落地常用三层结构：战略层定投资与优先级，管理层定流程与资源，执行层交付与运营；关键在于明确各层的决策事项与升层条件。
RACI 责任矩阵
RACI 把每项工作的角色分为负责执行（R）、最终问责（A）、被咨询（C）、被通知（I）；同一件事应有且只有一个最终问责人（A）。
ISO/IEC 20000 服务管理体系
ISO/IEC 20000-1 是服务管理体系（SMS）的要求标准，覆盖组织环境、领导力、策划、支持、运行、绩效评价与改进；它是要求（可认证），ITIL 是指导（非认证标准）。
需求管理流程
需求从收集到交付的流动：收集与澄清、价值评估与分级、排期、验收；每个需求条目要有来源、价值假设与验收标准，避免口头需求与隐形范围。
质量门禁 Quality Gate
质量门禁在流水线关键点设置自动检查并可阻断：单元测试、静态扫描、覆盖率、依赖漏洞、许可证、变更合规；门禁标准要透明、可解释、可申诉。
特性开关治理
特性开关（Feature Flag）解耦部署与发布：发布开关、实验开关、权限开关与运维开关各有生命周期；治理要点是登记、设置过期时间并定期清理。
DevOps 三步工作法 Three Ways
《DevOps Handbook》把 DevOps 改进总结为三个方向：加速从开发到运维的价值流动、缩短并放大反馈回路、建立持续学习与实验的文化，是理解 DevOps 的整体框架。
ISO/IEC 38500 评估-指导-监督模型
ISO/IEC 38500 用评估（Evaluate）、指导（Direct）、监督（Monitor）三个任务描述治理主体对 IT 的作用：评估现状与选项、指导计划与政策、监督绩效与合规。
COBIT 五个治理与管理域
COBIT 2019 用五个域组织 40 个目标：EDM 治理域 5 个，管理域 APO 14 个、BAI 11 个、DSS 6 个、MEA 4 个；域与目标构成治理体系的骨架。
ITSS 运维服务能力四要素
ITSS（信息技术服务标准）面向国内服务提供方能力评价：运维服务能力由人员、过程、技术、资源四要素构成（PPTR），对应 GB/T 28827 系列等标准。
阶段门评审 Gate Review
阶段门在项目关键节点设置评审：立项门、方案门、上线门等，每个门定义交付物与放行标准；未通过则整改或终止，防止问题滚动到下游。
项目组合管理 PPM
项目组合管理按战略价值、风险与资源约束对全部项目排序与调配，持续评估新增、调整与终止；与项目管理的关系是做正确的事 vs 把事做正确。
项目管理约束三角
范围、时间、成本构成传统约束三角，质量是叠加约束；调整任一边都会影响其余边。敏捷方法的取向是固定时间与成本、让范围可调，用优先级换取灵活性。
用户故事与验收标准
用户故事用角色-目标-价值描述需求：作为一个角色，我想要某个能力，以便获得某价值；验收标准用 Given-When-Then 描述可验证的完成条件。
流动度量：周期时间与吞吐
流动度量关注工作项穿越流程的效率：前置时间（请求到交付）、周期时间（开始到完成）、吞吐率与在制品；用分布与散点图展示，避免只看平均值。
分支策略对比与选择
主流分支策略：GitFlow 适合版本化发布与多版本维护；GitHub Flow 简单直接；主干开发配合持续交付；选择取决于发布节奏、版本维护与合规要求。
架构决策记录 ADR
ADR 用轻量文档记录重要架构决策：背景、决策、后果与状态；与代码同库管理，让后来者理解为什么这样设计，避免重复争论。
架构评审机制
架构评审按场景分级：重大变更、例外申请、新技术引入走评审；日常小改动团队自决。评审输入包括影响分析、成本、安全与合规，输出结论与条件。
内部开发者平台 IDP
内部开发者平台把脚手架、流水线、环境、可观测与合规检查封装成自助门户；研发从门户创建服务，默认带上组织标准的工程实践。
COBIT 七大治理系统组件
COBIT 2019 认为治理系统由七类组件构成：流程、组织结构、信息、人员技能、文化行为、服务与基础设施、政策程序；只建流程不建其余组件是常见失败模式。
TOGAF ADM 架构开发方法
TOGAF 的架构开发方法（ADM）用预备阶段与 A-H 阶段组织企业架构工作：从架构愿景到迁移规划与实施治理，再进入变更管理循环。
业务论证 Business Case
业务论证说明为什么做、有哪些选项、投入与收益、风险与时间线；它贯穿立项与结项，并在投资后回顾中验证假设是否成立。
PMO 的三种类型
PMO（项目管理办公室）常见三种定位：支持型提供模板与工具，控制型要求合规与评审，指令型直接管理项目；选择取决于组织治理强度与项目复杂度。
价值流映射 Value Stream Mapping
价值流映射把端到端交付步骤画出来，标注每步的处理时间与等待时间，识别浪费与瓶颈；常配合流动效率（增值时间占比）评估改进空间。
技术雷达 Technology Radar
技术雷达把技术方案分为采纳、试验、评估、暂缓四档，定期更新并公开发布；用于技术选型沟通、收敛技术栈与管理探索风险。
度量反模式与古德哈特定律
当度量指标变成目标时，它就不再是好的衡量（古德哈特定律）。常见反模式：用代码行数评绩效、用缺陷数考核测试、把工时当产出，会诱发数据美化与行为扭曲。
COBIT 设计因素与裁剪
COBIT 2019 设计指南用一组设计因素裁剪治理体系，包括企业战略、目标、风险画像、合规要求、IT 角色、采购模式、实施方法、技术采用策略与企业规模等，据此确定目标优先级。
COBIT 焦点领域 Focus Areas
COBIT 2019 为特定主题提供焦点领域指导，初期覆盖信息安全、DevOps、风险、第三方管理与中小企业，后续持续补充云与人工智能等主题，用于聚焦裁剪与实施。
IT4IT 参考架构价值流
IT4IT 是 The Open Group 的 IT 管理参考架构，按四个价值流组织管理能力：战略到组合（S2P）、需求到部署（R2D）、请求到履行（R2F）、检测到纠正（D2C）。
PMBOK 体系速览
PMBOK 是 PMI 的项目管理知识体系：第 6 版以五大过程组与十大知识领域组织，第 7 版转向 12 项原则与 8 个绩效域，更强调裁剪与交付价值。
MoSCoW 需求分级
MoSCoW 把需求分为必须有（Must）、应该有（Should）、可以有（Could）、本次不做（Won't）；用于时间盒内的范围协商，Must 占比过高则失去分级意义。
利特尔法则 Little's Law
利特尔法则指出在稳定系统中：在制品数量 = 吞吐率 × 周期时间；推论是限制在制品（WIP）可以在吞吐率不变时缩短周期时间，是流动管理的数学基础。
CALMS 模型
CALMS 用于评估组织 DevOps 就绪度：文化（Culture）、自动化（Automation）、精益（Lean）、度量（Measurement）、分享（Sharing）五个维度，强调文化先行。
AI 辅助研发的治理
生成式 AI 进入研发流程后，需要治理代码来源、许可与安全：AI 生成代码同样要过评审与扫描，敏感数据不外发，自动化产物保留人工复核点。
双模 IT 及其演变
Gartner 提出的双模 IT 把工作分为模式一（稳定、可预测、效率优先）与模式二（探索、敏捷、速度优先）；实践提醒：按工作性质选择方式比按组织切分成两套更可持续。
CMMI 能力成熟度模型集成
CMMI 用成熟度等级描述组织过程能力：从初始级到优化级。2.0 版不再强制阶段式，可选择成熟度等级或能力域评估，用于过程改进与供应链评估场景。
规模化敏捷 SAFe 与 LeSS
规模化敏捷框架帮助多团队协同交付：SAFe 强调分层结构与计划节奏，LeSS 强调以更少流程保持简单。选型取决于组织规模、系统耦合度与现有文化。
PI 规划会 PI Planning
SAFe 中的 PI Planning 是周期性多团队对齐活动（常见两天）：梳理特性、拆分依赖、识别风险并确认迭代目标，产出团队级计划看板。
变更冻结窗口 Change Freeze
变更冻结是在特定时段暂停变更的策略：大促、结算、重大活动期间只允许紧急修复。用于降低高峰期风险，但要配套紧急通道，避免冻结期问题无法处置。
团队与人才55 条
组织设计、绩效激励与 OKR
OKR 目标与关键结果
OKR 用目标（Objective，定性方向）与关键结果（Key Results，可验证结果）对齐组织重点，通常按季度设定并公开透明；强调聚焦、对齐与跟踪，不直接挂钩绩效奖金。
心理安全 Psychological Safety
心理安全指团队成员敢于提出问题、承认错误与表达异议而无需担心受到羞辱或惩罚。Google 的 Project Aristotle 研究把心理安全列为团队效能的关键因素之一。
Team Topologies 团队拓扑
Skelton 与 Pais 提出的组织设计方法：以团队为交付单元，按认知负荷与交互模式设计团队边界；四种团队类型（流动对齐型、赋能型、复杂子系统型、平台型）配合三种交互模式使用。
康威定律 Conway's Law
康威定律指出：系统架构会映射组织的沟通结构。因此组织调整与架构演进需要协同进行，否则架构目标与团队实际沟通方式会持续冲突。
绩效管理体系
绩效管理是持续循环：目标设定、过程反馈、周期评估与结果应用。评估周期常见半年或年度，配套自评、同事反馈与上级评估；关键是把日常反馈与期末评估分开。
四种团队类型（Skelton & Pais）
团队拓扑把团队分为流动对齐型（直接交付业务价值）、赋能型（帮助其他团队补齐能力）、复杂子系统型（维护高专业度组件）、平台型（提供自助能力），各自的服务对象不同。
一对一面谈 1:1
一对一会议是管理者与成员之间的固定沟通机制，重点是成员关心的议题：状态、障碍、成长与反馈，而不是任务进度汇报（进度应在日常渠道同步）。
逆康威操作 Inverse Conway Maneuver
逆康威操作是主动调整团队结构以促成目标架构：想让系统按业务域解耦，就按业务域组建团队并赋予其端到端责任。Team Topologies 与 DORA 都将其视为组织设计手段。
KPI 设计方法
设计 KPI 要先明确目标与反例：指标是否可度量、是否可影响、是否会诱发扭曲行为。常用做法是一个北极星指标配若干护栏指标，防止单指标优化损害其他维度。
技术负责人 Tech Lead
技术负责人对一块业务的技术结果负责：技术方案决策、质量与稳定性把关、跨团队技术协调，并培养团队技术能力。与管理者的区别在于重心偏技术与方向，而非人员的行政与绩效管理。
三种团队交互模式
团队拓扑定义三种交互模式：协作（高带宽共同探索）、服务（平台/组件按约定提供能力）、促进（一段时间内结对辅导），同一对团队会随阶段切换模式。
巴士系数 Bus Factor
巴士系数指团队中多少人离开后项目将陷入停滞（数字越小风险越高）。常用做法是识别关键模块与知识持有人，通过文档、结对与后备值班降低风险。
招聘循环 Hiring Loop
招聘循环把面试设计成结构化流程：按岗位能力模型确定考察维度，每个环节有明确考察点与评分表，避免所有面试官问同一问题或凭直觉拍板。
认知负荷 Cognitive Load
认知负荷指团队成员需要同时理解与维护的内容总量。团队拓扑主张限制每个团队的认知负荷：把过重的子系统拆分、把公共能力收敛到平台，避免团队被复杂度压垮。
OKR 与 KPI 的区别
KPI 是持续性健康指标（如可用性、留存率），OKR 是阶段性突破目标。常见组合：KPI 保底监控日常健康，OKR 牵引本季度的改进重点，两者互补不互相替代。
反馈模型 SBI 与情境化反馈
SBI 把反馈拆成情境（Situation）、行为（Behavior）、影响（Impact）三个要素，避免笼统评价人格；有效反馈聚焦具体行为与可观察影响，并说明期望的调整方向。
工程经理 Engineering Manager
工程经理对团队的人员、交付与工程健康负责：招聘与培养、目标管理、跨团队协作、营造健康的工程文化与流程，技术深度用于判断与辅导而非替代团队动手。
团队章程 Team Charter
团队章程明确团队使命、服务对象、职责边界、关键指标与协作约定，帮助新组建团队对齐预期，减少与其他团队之间的灰色地带争议。
OKR 撰写规范
好的 KR 具备三要素：基线（现在多少）、目标值（要到多少）、时间点。写法上避免把 KR 写成任务清单；团队 KR 要能追溯到上级目标，形成对齐链。
职级体系 Career Ladder
职级体系用等级刻画责任范围、影响半径与能力要求，每个级别有对应的期望与晋升标准。透明公开的体系有助于员工理解发展方向，减少晋升争议。
结构化面试
结构化面试指所有候选人接受相同维度、相同评分标准的考察；人员选拔元分析（Schmidt & Hunter）显示结构化面试的预测效度高于非结构化面试与随机提问。
Westrum 组织文化类型
Ron Westrum 把组织对信息流的处理方式分为病态型（掩盖坏消息）、官僚型（各自守规则）与生成型（绩效导向、欢迎新信息）。Accelerate 研究显示生成型文化组织的交付绩效更好。
技能矩阵 Skill Matrix
技能矩阵把团队成员与关键技能交叉列表，用等级标注熟练度，用于识别单点依赖、安排补位培训与项目排兵，是团队能力可视化管理工具。
团队健康检查 Team Health Check
团队健康检查用一组固定维度定期自评（如交付节奏、代码质量、协作、学习、士气），用红黄绿标注并聚焦改进行动，是轻量的团队诊断机制。
能力模型 Competency Model
能力模型按职级与职能定义所需知识、技能与行为标准（如编码能力、架构判断、协作影响），用于招聘、培养、晋升评估的共同语言，需要与职级体系配套维护。
资深专家工程师 Staff Engineer
Staff Engineer 是超越单一团队的技术角色：负责跨团队的技术方向、疑难攻坚与工程师培养，通过技术影响而非管理权限推动组织结果。
新人 30/60/90 天上手计划
30/60/90 天计划把新人上手分解为三个阶段：熟悉环境与流程、独立完成小任务、承担完整职责。每个阶段有明确目标与检查点，减少放养式入职。
T 型人才 T-Shaped
T 型人才指在某一领域有深度专长（竖笔），同时对相邻领域有足够广度（横笔），能在团队内补位协作。团队能力组合常按 T 型结构规划。
Spotify 模型与组织敏捷
Spotify 模型源自公开的 Spotify 工程文化分享：小队（Squad）、部落（Tribe）、分会（Chapter）、行会（Guild）等结构。Spotify 官方多次说明自身仍在演化，不建议直接复制。
绩效校准会 Calibration
绩效校准会是管理者跨团队对齐评价标准的会议：用统一维度与证据对比成员表现，减少因团队差异导致的松紧不一，产出相对一致的评级分布。
管理与专业双通道
双通道指技术与管理两条平行的职业路径：走技术路线同样有高级别与影响力空间，避免“想做技术只能靠转管理升职”的单通道困境，两条通道在薪酬与话语权上尽量对等。
STAR 行为面试
STAR 按情境（Situation）、任务（Task）、行动（Action）、结果（Result）追问真实经历；相比假设性问题，行为面试关注候选人实际做过什么，追问细节可减少空话与包装。
内部技术分享机制
内部分享通过固定节奏与低门槛形式让知识流动：如双周技术例会、午餐分享、专题工作坊；关键在于选题来源真实（来自项目痛点）与分享后有沉淀（文档/录像）。
两块披萨团队 Two-Pizza Team
两块披萨团队是亚马逊的团队规模经验法则：团队小到用两块披萨能喂饱（约 6-10 人），以降低沟通成本并提高自主性；适用于单团队内部沟通效率的衡量。
晋升评审机制
晋升评审由委员会制执行：候选人提交证据材料（重点项目、影响、他人反馈），初审筛选，评审会评议并投票。机制设计重点是统一标准、跨团队评委与申诉通道。
坦诚关心 Radical Candor
Kim Scott 提出坦诚关心：既真心关心对方（Care Personally），又敢于直接指出问题（Challenge Directly）；两个维度都缺位时分别落入虚假和气、厌弃攻击或操纵式关心。
面试决策会 Hiring Debrief
决策会由面试官集体做出录用判断：先各自独立提交书面评价，再汇总讨论分歧点，最后决策人拍板；流程上避免先发言者主导与对候选人的公开负面标签化。
入职伙伴与导师制
入职伙伴（Buddy）负责日常答疑与社交融入，导师（Mentor）负责技能成长与职业建议；两者分离可避免“单点联系人”过载，也降低带教者缺席时的风险。
异步协作
异步协作用文档、工单与讨论区替代大量同步会议：信息可检索、可回溯、跨时区友好；适合需求讨论、方案评审与状态同步，紧急与高歧义场景仍需同步沟通。
离职分析与保留策略
离职分析按团队、职能与司龄分解离职率，结合离职原因访谈识别系统性因素（管理、薪酬、成长、通勤），把保留策略落到可执行项：内部机会、轮岗、导师与弹性安排。
晋升驱动型开发
当晋升与重大项目强绑定，工程师会倾向于追新造复杂系统、避开维护性工作，产生“简历驱动开发”。缓解方式是多元化晋升证据（含稳定性与协作贡献），并让维护工作有可见的激励。
个人贡献者与管理路线
个人贡献者（IC）路线以专业深度与跨团队影响立身，管理路线以团队结果与人员成长立身。选择应基于长期动机（解决问题 vs 成就他人）与组织对两条通道的支持程度。
面试官培训
面试官培训覆盖提问技巧、评分标准、反偏见与法律合规（避免询问与岗位无关的私人信息）；经过培训与跟岗的面试官，评价一致性明显更好。
导师制 Mentorship
导师制通过固定周期的一对一辅导帮助成员成长：导师提供经验视角与反馈，学员负责提出目标与议题；有效运行依赖目标设定、定期会面与效果回顾。
远程与分布式团队
分布式团队协作依赖显式规则：沟通渠道分层（即时/异步/文档）、会议时间轮换照顾时区、决策与进展默认写下来，管理与信任从看工时转向看结果。
小队 分会 部落 行会
Spotify 模型中的四类组织单元各有分工：小队负责交付，部落聚合相关小队，分会负责同职能技能发展，行会负责跨部落的兴趣社区与知识流动。
内推招聘
内推借助员工网络寻找候选人，通常到面率与入职留存较好（多数公司的公开经验），但需要防止同质化与裙带关系：内推应走与普通渠道一致的评估标准。
结对与群体编程
结对编程（两人一机）与群体编程（多人一屏）通过实时协作提升质量与知识扩散，适合高风险改动、新人带教与方案探索；成本是投入更多人力，需要场景化选择。
留任面谈 Stay Interview
留任面谈在员工提出离职之前进行：定期了解其满意度、发展期望与去留风险，把问题暴露在可干预的阶段；与离职面谈相比更有机会挽留与调整。
人才密度
人才密度指团队中高素质成员的比例；Netflix 文化公开材料把人才密度放在管理原则的重要位置——优秀同事互相激励，而低标准会拉低整体。提高密度从招聘标准与绩效管理两端着手。
绩效改进计划 PIP
绩效改进计划（Performance Improvement Plan）是绩效不达标后的正式改进流程：明确差距、设定 30-90 天可衡量的改进目标、提供支持并定期评估，同时遵守当地劳动法规与书面记录要求。
轮岗与角色轮换
轮岗让成员在不同模块或角色间流动：降低单点依赖、拓宽业务理解，常用于值班轮换、模块主备与新人培养；需配合交接规范与学习期缓冲。
敬业度调查
敬业度调查用匿名问卷定期测量团队状态（投入度、协作、成长、认可、管理信任），指标用于发现系统性问题并跟踪改进行动，避免用作对个体的评价工具。
技术雇主品牌
雇主品牌是候选人对公司的认知集合，来自技术博客、开源贡献、面试体验与员工口碑；工程团队可通过输出真实技术内容与规范面试流程来长期积累。
内部转岗机制
内部转岗让员工在组织内寻找新方向：转岗规则（任职时长、交接期、目标团队接收条件）透明可预期，可以减少为换方向而离职的损失，也避免团队间抢人乱象。
技术规划与预算50 条
技术战略、路线图与成本管理
技术战略 Technology Strategy
技术战略描述技术与业务战略的咬合方式：未来 2-3 年技术要支撑哪些业务目标、投入哪些方向、放弃哪些方向，以及需要的组织与平台能力；它约束技术选型与预算分配。
自建与采购 Build vs Buy
自建与采购的决策看四件事：是否属于业务差异化能力、总体拥有成本、上市时间与合规要求。通用能力倾向采购或租用，差异化能力倾向自建并持续投入。
技术路线图 Technology Roadmap
技术路线图按主题与时间窗组织技术演进（如平台化、数据库迁移、可观测建设），与产品路线图对齐节奏；路线图表达方向与顺序，不承诺精确日期。
总拥有成本 TCO
TCO 覆盖资产全生命周期成本：采购、实施、集成、运维、能耗、维保、培训、退役与迁移；用于自建/采购/云方案对比，避免只比标价。
FinOps 云财务运营
FinOps 是把财务问责引入云的运营体系：工程、财务与业务协同，通过数据可见、责任分配与持续优化，让每一份云支出产生业务价值；核心循环是查询、优化、运营。
架构原则 Architecture Principles
架构原则是少数几条可执行的取舍准则（如按业务域解耦、默认复用、数据单一来源、面向失败设计），评审时用于判断方案与例外；原则太多等于没有原则。
IT 预算编制
IT 预算编制自下而上（团队需求）与自上而下（战略额度）结合：按运行（维持现有）、增长（业务增量）与变革（战略项目）分类编制，附假设与敏感性说明。
目标架构 North Star Architecture
目标架构描述未来 2-3 年的系统形态与演进方向（服务边界、数据流向、集成方式、平台依赖），作为当前决策的参照系：权衡“离目标更近还是更远”。
云成本构成与可视化
云成本由计算、存储、网络、数据库、观测与许可等构成，按标签/资源组归集后可定位大头；治理重点通常是计算规格、存储生命周期与跨区流量三类支出。
供应商选型评估
供应商选型用统一评分模型比较候选：功能匹配、技术架构、集成成本、服务能力、合规资质、总成本与锁定风险；评分前先定权重，避免被演示效果带偏。
技术愿景 Tech Vision
技术愿景用简明语言描述未来的技术形态（平台化、自动化水平、数据能力、开发者体验），为路线图与选型提供方向标；愿景要可讨论、可演进，而非口号。
技术栈收敛与标准化
技术栈收敛指控制组织内语言、框架、中间件与工具的多样性：默认技术栈支持有优先，引入新技术需评估与批准，降低维护面与培训成本。
资源规格优化 Rightsizing
规格优化按实际利用率调整实例与数据库配置：采集周期指标（CPU、内存、连接数），选择匹配规格；缩容前评估峰值与增长，扩容同样属于规格管理。
ROI 投资回报率
ROI =（收益 − 成本）/ 成本，用于快速比较投资吸引力；使用时注意口径：收益是否可验证、成本是否含运维与退出，警惕把预期收益当既成事实。
参考架构 Reference Architecture
参考架构给同类系统提供已验证的结构模板与组件清单（含安全、可观测、部署要求），新项目从中裁剪起步，减少重复设计与合规遗漏。
单位经济学 Unit Economics
单位经济学把技术成本摊到业务单位（每订单、每用户、每万次调用），用于判断成本增长与业务增长是否脱钩；是技术预算与业务沟通的共同语言。
预留实例与节省计划
预留实例（RI）与节省计划（Savings Plans）以承诺换取折扣：按 1-3 年承诺用量获得低于按需的价格，适合基线负载；承诺前先识别稳定的基线用量，避免超量承诺。
AI 项目预算与成本管理
AI 项目的成本结构与常规 IT 不同：训练与推理算力、数据标注、模型评估与实验浪费占比高；预算管理要分阶段（探索/验证/生产）设额度，并按推理单位成本持续跟踪。
架构适应度函数 Fitness Functions
适应度函数把架构要求写成可自动验证的检查（如分层依赖规则、性能门槛、安全基线），在流水线中持续执行，防止架构在迭代中悄悄退化。
PoC 验证流程
PoC（概念验证）用受限范围验证新技术的可行性：先定义要验证的假设与通过标准，设定时间盒与资源上限，结束后明确采纳、再验或放弃，避免无限期试用。
IT 采购流程
IT 采购把需求、预算、合规与供应商管理串成流程：需求与预算确认、采购方式选择（询价/招标/单一来源）、合同与审批、验收与付款、资产入账。
开源合规管理
开源合规检查开源组件许可（GPL、Apache、MIT 等）与义务：保留版权声明、满足传染性条款、规避禁用许可证；工具扫描依赖清单并在流水线设置门禁。
FinOps 三个循环阶段
FinOps 框架把运营循环分为三阶段：告知（Inform，可见与分配）、优化（Optimize，降本与提效）、运营（Operate，机制化与目标度量）；三个阶段循环往复持续运转。
GPU 与算力成本管理
GPU 资源贵且紧张，管理重点是利用率与排队：训练任务用抢占式与队列调度，推理服务做批量与量化优化；按业务价值分级分配算力，避免囤卡闲置。
资本支出与运营支出 CAPEX/OPEX
CAPEX 是一次性资本投入并按期折旧（硬件、机房），OPEX 是持续性运营支出（云订阅、服务费）；云化把 CAPEX 转成 OPEX，改变现金流形态与预算管理方式。
IT 组合管理 IT Portfolio Management
IT 组合管理把系统与投资当作组合统筹：按业务价值、风险、成本与生命周期评估每个应用，决定投资、维持、合并或退役，避免系统只增不减。
技术债偿还预算
技术债偿还需要有可执行的预算机制：常见做法是固定比例（如每迭代留出一定容量）或专项计划（大版本停功能窗口），并把偿还与风险数据结合排序。
RFP 与招标流程
RFP（需求建议书）用于正式征询供应商方案：先冻结需求与评分标准再发标，统一答疑、统一截止、独立评审；流程记录保存以备审计。
供应商锁定与议价
供应商锁定来自数据迁移成本、专有接口与商业条款；缓解手段包括标准化接口、数据导出能力、多云/多供应商策略与合同退出条款，同时保留一定议价空间。
IT 合同评审要点
IT 合同评审关注交付物与验收标准、付款节奏、知识产权归属、数据与保密、SLA 与违约、变更与终止条款；法务与安全团队按清单并行评审，避免只审价格。
云成本分摊与归集
成本分摊把共享资源（网络、日志平台、Kubernetes 集群）按合理规则摊到业务方：常见方法有按用量、按权重与固定比例；规则需公开透明且定期校准。
竞价实例 Spot 与弹性成本
竞价/抢占式实例价格低于按需，但可能被回收：适合可中断任务（批处理、CI 构建、渲染），配合检查点与自动重试；不可用于无容错能力的核心在线服务。
Run/Grow/Transform 预算结构
IT 预算常分三类：Run 维持现状（运维、订阅、折旧），Grow 支撑业务增长，Transform 战略变革项目；健康的结构需要为变革留出可见额度，并逐年把变革成果转入运行。
收益实现管理
收益实现管理在投资立项时定义预期收益与度量方式，交付后按节点核对实际收益（成本节省、效率提升、风险降低），未达预期时启动分析与纠偏。
基准测试与技术验证
基准测试用可复现的实验比较候选技术：明确负载模型、硬件环境与度量口径，报告原始数据与置信区间；避免用厂商单方发布的数字直接决策。
软件许可管理 License Management
软件许可管理跟踪授权类型（按用户/按核/按实例/订阅）、用量与续费节点，防止超用与漏续：常见做法是建立许可台账、定期盘点实际用量、集中管理采购入口。
单笔交易成本优化
单笔交易成本优化通过三类手段推进：架构效率（缓存、批处理、异步化）、资源效率（规格与弹性）、采购效率（折扣与承诺），并用基线对比验证效果。
闲置资源治理
闲置资源包括未挂载磁盘、空闲负载均衡、零流量环境与过期快照等；建立定期扫描清单，区分保留（归档、合规）与清理（测试残留），避免为沉睡资源持续付费。
预算偏差分析
预算偏差分析比较实际与计划：按科目与团队分解差异，区分用量、价格、汇率与一次性因素；差异超阈值时启动解释与调整流程，为下期预算提供依据。
NPV 与 IRR 财务评估
NPV（净现值）把未来现金流按折现率折现后求和，NPV>0 通常表示创造价值；IRR 是使 NPV=0 的折现率，用于与资本成本比较。多项目比较时注意规模与期限差异。
应用精简与退役
应用精简识别功能重叠与低使用率的系统：合并同类工具、退役无人使用的旧系统，降低许可、运维与安全维护面；退役需完成数据归档、接口下线与用户迁移。
新技术评估与引入机制
新技术引入需要流程：来源收集（社区、会议、供应商）、初步筛选（成熟度、生态、团队能力）、小范围试点、评估结论与推广决策；用机制替代个人偏好驱动。
IT 资产折旧与账期
IT 资产按会计准则计提折旧（常见 3-5 年）：服务器、网络设备、终端按类别设定年限与残值，折旧影响年度成本与更换决策，与云资源的费用化形成对比。
Showback 与 Chargeback
Showback 只向团队展示其成本（透明与教育），Chargeback 把成本实际计入团队预算（强约束）。多数组织从 Showback 起步，数据可信、规则被认可后再过渡到 Chargeback。
投资优先级模型
投资优先级用结构化模型平衡价值与成本：如价值/复杂度矩阵、加权评分（价值、风险、战略一致性、投入）；模型用于对齐讨论，决策仍保留人工判断空间。
供应商退出策略
退出策略在签约前就规划好如何在未来停止使用该供应商：数据导出格式与期限、并行运行期、接口切换方式、费用结算；合同谈好退出条款，避免被事实绑定。
硬件更新周期管理
硬件更新周期按设备类型与关键性设定（如核心网络 5-7 年、终端 3-4 年、服务器 4-5 年），到期前评估性能缺口、维保成本与安全支持状态，列入年度预算滚动执行。
Serverless 成本模型
Serverless（函数计算）按请求次数与执行时长计费，闲置不付费；但当调用量大、执行时间长时，成本可能高于常驻服务，需按真实调用画像测算再选型。
零基预算 Zero-Based Budgeting
零基预算要求每笔支出从零开始论证而非沿用去年基数，适合结构性调整期：识别低价值延续性支出；执行成本高，通常几年一次或针对特定科目实施。
绿色 IT 与能效管理
绿色 IT 关注数据中心能效与环境成本：PUE（电能利用效率）衡量制冷与配电损耗，常见治理手段包括提高机架密度、自然冷却、关闭闲置设备与迁移到能效更好的区域。
流程与知识管理50 条
SOP、复盘机制与知识库建设
SOP 标准作业程序
SOP 把重复性作业固化为步骤化文档：适用场景、前置条件、操作步骤、验证方法与异常处理；目的是让训练有素的人员按文执行得到一致结果。
知识库建设
知识库把解决过的问题与验证过的方案沉淀为可检索条目：来源包括工单解决方案、故障复盘与操作经验；目标是让同类问题再次出现时不需要重复摸索。
流程管理基础
流程管理通过分级与责任人把跨部门协作固定下来：常见分 L1 流程域、L2 流程组、L3 流程、L4 子流程、L5 活动与作业指导，越往下越具体、改动越频繁。
流程裁剪 Tailoring
流程裁剪按项目规模与风险调整流程强度：小改动走简化通道，高风险变更走完整评审；裁剪规则要预先定义（按影响范围、金额、风险分级），而非临时特批。
Runbook、Playbook 与 SOP 的区别
Runbook 面向系统操作（如故障处置步骤），Playbook 面向场景决策（如大促保障、安全事件响应的决策树），SOP 面向日常重复作业的标准化执行；三者常配合使用。
文档即代码 Docs as Code
文档即代码把文档与代码放在同一仓库流程：版本控制、分支评审、CI 检查与自动发布；适合工程文档，让文档更新随代码变更一起完成，减少漂移。
迭代回顾会议
迭代回顾让团队定期检视协作与流程：结构上先回顾事实与数据，再找根因，最后收敛少量可执行的改进项；节奏常见每 1-2 个迭代一次。
流程简化原则
流程简化先做减法：合并审批、删掉无人使用的字段与报表、把串行改并行；判断标准是每个环节是否创造可验证的价值（控制风险、记录证据、传递信息）。
SOP 编写规范
SOP 编写强调可执行性：用祈使句、一步一动作、标注预期结果与失败分支；涉及路径与命令要可直接复制，变量用占位符标注；发布前经非作者试跑验证。
流程自动化
流程自动化把重复性人工环节交给系统：表单触发、自动流转、通知与归档；先标准化再自动化，选择高频、规则清晰、量大的环节优先，收益较易量化。
Playbook 场景手册
Playbook 描述特定场景下的应对框架：触发条件、角色与职责、决策树、沟通模板、升级路径与事后动作；用于重大故障、数据泄露、大促保障等需要多方协同的场景。
KCS 知识中心服务
KCS（Knowledge-Centered Service）主张在解决问题的同时沉淀知识：解决者即作者，按“捕获、结构、复用、改进”循环运转，用复用率与贡献度衡量而不是行政摊派。
流程责任人 Process Owner
流程责任人负责一条流程的设计、运营与改进：定义与发布流程、监控度量、处理例外与评审变更；责任人应是流程的实际利益相关方，而非名义挂名。
审批链设计
审批链设计遵循“最少必要”：按金额与风险分级设定审批层级，明确每级审什么（合规、预算、技术），避免逐级重复审同一内容；审批 SLA 与超时升级要写清楚。
知识转移 KT 流程
知识转移（KT）指把特定领域的知识从一方系统化传递到另一方：制定 KT 计划（主题清单、讲解、跟做、验收），适用于项目移交、外包回收与团队重组。
知识条目模板
知识条目模板统一结构：标题（含关键词）、适用场景、症状、环境、原因、解决步骤、验证、相关问题；模板降低写作门槛，也让检索与复用更顺畅。
会议纪要规范
好的纪要记录决策与行动项：时间、参与人、议题、结论（含决议人）、行动项（内容/负责人/期限）与待决问题；会后当天发出并在下次会议核对闭环。
决策日志 Decision Log
决策日志记录重要决策的上下文与理由：日期、决策、背景、备选方案、依据、影响范围与状态；帮助后来者理解决策为何如此，避免反复推翻与重复讨论。
变更日志 Changelog
变更日志按时间记录系统或产品的显著变化：新增、修改、修复与废弃，写用户可理解的影响描述并标注日期与版本；比代码提交历史更适合对外沟通。
流程成熟度评估
流程成熟度描述流程从依赖个人到持续优化的演进：常见模型分为初始、可重复、已定义、已管理、优化五级；评估用于定位改进起点，避免跳跃式追求高等级。
交接文档 Handover
交接文档用于人员轮换、项目移交与假期代班：系统现状、账号与权限清单（不含明文密码）、在办事项、风险与联系人、历史决策索引；交接要双向确认并留记录。
知识分类体系
知识分类决定检索效率：常用维度包括领域（网络/数据库）、场景（故障/操作/选型）与对象（产品/系统）；分类宜浅而稳定，配合标签做灵活补充。
知识库度量
知识库健康度用使用数据说话：检索命中率、条目复用次数、工单自助解决率、更新频率与无结果词清单；避免只统计条目数量这类易注水的指标。
文档债
文档债指文档与实际不一致的积累：过期步骤、缺失的变更说明、只在个人脑中的隐性知识；治理方式是随变更同步文档 + 定期对账 + 把文档纳入完成定义。
技术写作要点
技术文档服务读者完成任务：先写结论与直接可执行的路径，再补背景与原理；面向对象与前置条件明确，示例可复制可验证；一件事说清楚，胜过面面俱到。
单一信息源 SSOT
单一信息源原则：每类信息只有一个权威来源，其他位置引用而非复制；减少多副本口径冲突与更新遗漏，常见于配置、指标定义、术语与文档权威版本。
实践社区 CoP
实践社区（Community of Practice）由跨团队的同领域成员组成：定期交流、共建标准与工具、维护知识资产；与行政团队正交，靠共同兴趣与产出维系。
流程绩效指标
流程指标衡量流程的效果与效率：周期时间（从发起到关闭）、一次通过率、返工率、积压量；指标用于发现瓶颈与改进点，避免变成对个人的考核工具。
内部 FAQ 管理
内部 FAQ 收拢高频重复问题（权限、环境、报销、发布流程），答案保持短与最新；从群聊提问与工单中定期提炼，能显著减少重复答疑的隐性成本。
ChatOps 运维协作
ChatOps 把常用操作与信息汇聚到聊天渠道：查询状态、触发发布、审批、告警聚合都在群内完成并留痕；权限与审计要同步设计，避免把危险操作开放给所有人。
知识检索设计
检索是知识库的使用入口：关键词、全文、同义词与别名都要覆盖；检索无结果时提示相关分类与求助路径，并用搜索日志反哺词条建设与标题优化。
知识保鲜与复审
知识需要保鲜：按主题设定复审周期（高频内容季度、低频年度），由责任人核对版本与步骤有效性；过期条目降权或标注，避免误导使用者。
文档责任人 Owner
每篇关键文档有明确责任人：负责内容准确、按周期复审、处理反馈；责任人列表公开可见，人员变动时随交接更新，避免出现无人维护的孤儿文档。
模板库建设
模板库集中沉淀高频文档模板：方案设计、故障复盘、变更申请、项目立项、评审记录；模板减少从零撰写成本，也统一了要素与质量下限，需指定维护者持续更新。
术语表与统一语言
术语表统一组织内的叫法：业务概念、系统名、缩写与别名；统一语言减少沟通歧义，也是领域建模与知识检索的基础，需要随业务变化维护。
团队手册 Team Handbook
团队手册集中记录运作方式：使命与目标、职责边界、流程约定、会议节奏、工具入口与常见问题；用可搜索的在线手册替代口口相传，新人自助上手更快。
回顾行动项跟踪
回顾的价值在行动项落地：每项有负责人与期限，进入日常看板跟踪，完成情况在下期回顾核对；连续未完成的行动项要降级或升级处理，而不是照抄。
经验教训登记册
经验教训登记册汇总项目与运维中的可复用经验：背景、问题、做法、结果与建议；在项目收尾与阶段节点更新，供新项目检索复用，避免重复踩坑。
发布说明编写
发布说明面向用户与支持团队：本次发布包含什么、如何使用、有何影响、需要注意什么；与变更日志的区别是更侧重引导与支持信息（已知问题、升级路径、常见疑问）。
队列与批次管理
队列管理让工作流动可视：限制在制品（WIP）、先进先出与优先级规则明确、队列长度监控；积压是流程问题的信号，先看瓶颈环节而不是催人加班。
工作流编排与引擎
工作流编排引擎用状态机或流程定义描述多步骤任务：支持重试、补偿、人工审批节点与超时处理；适合订单、审批、数据处理等跨系统流程的可靠执行。
知识资产盘点
知识资产盘点定期梳理既有内容：识别重复、过期、无主与缺失主题；产出清理清单与新建清单，让知识库保持可用而不是持续膨胀。
文档流水线 Docs CI
文档流水线自动检查常见问题：链接失效、拼写与术语规范、示例代码语法、目录结构；失败即阻止合并，减少人工评审负担，保持文档质量稳定。
文档控制与版本管理
受控文档需要版本管理：编号规则、版本历史、审批记录、发放与回收；质量体系与合规场景要求的受控文档，与工程文档的自由协作流程要区分处理。
Wiki 治理
Wiki 的开放编辑需要治理：明确空间与权限、命名与建页规范、责任人机制与归档策略；否则页面越建越多、重复与过期内容混杂，可信度下降。
知识分享激励
分享激励把沉淀与复用纳入评价：如复盘质量、文档贡献、答疑活跃度作为晋升与评优的参考维度；避免按字数数量的机械计分，防止灌水。
技术写作规范 Style Guide
写作规范统一术语、人称、格式与语气：如术语表、数字与单位写法、代码与界面元素标注方式、标题层级规则；团队统一规范能明显降低阅读与翻译成本。
答疑时间 Office Hours
固定答疑时间让专家集中处理问题：公开日程、参与者带具体问题、现场解决或转跟进；比随时打断更高效，也让经验以问答形式沉淀为知识条目。
内容生命周期管理
内容有生命周期：创建、评审、发布、使用、复审、归档与销毁；每个阶段有责任人与动作规则，避免过期内容长期在线误导使用者，尤其是合规敏感内容。
录屏与视频知识
录屏适合演示类知识：操作过程、界面路径、复杂配置；通常 5-15 分钟，配章节与文字摘要，长期价值取决于可检索（标题与摘要含关键词）与是否随版本更新。
审计与合规50 条
IT 审计、内控与数据合规管理
IT 审计基础
IT 审计独立评估信息系统相关控制的设计与运行有效性：覆盖治理、开发、运维、安全与合规；产出审计发现与整改建议，为管理层提供保证与改进输入。
IT 一般控制 ITGC
ITGC 是支撑应用控制可靠运行的基础控制：访问管理（账号与权限）、变更管理（审批与测试）、运维（作业与备份）、系统开发生命周期；财务审计依赖 ITGC 判断自动化控制能否信赖。
网络安全等级保护（等保 2.0）
等保 2.0（GB/T 22239-2019）按系统重要程度定级（一级至五级），在安全通用要求上叠加云计算、移动互联、物联网等扩展要求；定级备案、建设整改、等级测评与监督检查构成闭环管理。
权限复核 Access Review
权限复核按周期核对“谁拥有什么权限、是否仍然需要”：由业务负责人确认用户清单与角色授权，移除离职与转岗残留权限，保留复核记录作为审计证据。
ISO/IEC 27001 与 ISMS
ISO/IEC 27001 规定信息安全管理体系（ISMS）要求：建立、实施、维护并持续改进体系，覆盖组织环境、领导作用、策划、支持、运行、绩效评价与改进，附录 A 提供控制项参考。
个人信息保护法要点
《个人信息保护法》确立告知同意、最小必要、目的限制等原则：处理前明确告知并取得同意（法定情形除外），敏感个人信息单独同意，并保障个人查阅、更正、删除等权利。
特权账号管理 PAM
特权账号（管理员、数据库超管、云账号 root）是审计重点：管理要求包括专人审批开通、定期改密或密钥轮换、操作留录、离岗即回收；共享特权账号应整改为个人账号。
审计日志与留痕
审计日志应记录谁在何时对什么做了什么：身份认证、权限变更、数据修改、配置调整与管理操作；日志集中收集、防篡改（只读或哈希校验）并限制访问。
数据分类分级
数据分类分级按敏感度与影响划分等级（公开、内部、秘密、机密等），并制定对应管控（访问、加密、外发、留存）；分级结果是权限、加密与审计策略的基础。
SOX 与 IT 控制要点
SOX 法案要求美国上市公司管理层对财务报告内部控制负责：IT 侧需覆盖财务相关系统的访问、变更、运维与外包控制，并由审计师测试；非上市公司客户也可能按此标准提出要求。
变更管理审计要点
变更审计检查变更流程的执行一致性：申请与审批、测试与回滚预案、发布记录、紧急变更的事后补审；抽样覆盖各类型变更与全年度，重点看“紧急变更”占比与留痕。
配置基线与配置核查
配置基线定义系统应有的安全设置（口令策略、服务端口、权限、日志开关），配置核查用工具比对实际配置与基线差异，输出偏差清单并整改；变更后复核，防止漂移。
信息安全风险评估
风险评估识别资产、威胁与脆弱性，评估可能性与影响得出风险值：常用方法包括定性矩阵（高/中/低）与定量分析；产出风险清单并按优先级处置。
审计流程
典型审计流程：计划（范围与标准）→ 准备（资料清单与访谈安排）→ 现场（访谈、测试、抽样）→ 报告（发现分级与建议）→ 整改（计划、验证、关闭）。
审计发现与分级
审计发现描述“准则要求—实际状况—影响—原因—建议”；按严重程度分级（重大/重要/一般），并与被审方确认事实与整改方向，避免定性用语含糊。
IT 应用控制 ITAC
ITAC 是业务流程中依赖系统的控制：如三单匹配、金额阈值审批、接口对账；审计要点是验证配置参数正确、例外报告被处理、变更后控制仍有效。
职责分离 SoD
职责分离防止不相容职责集中于一人：如申请与审批、开发与生产发布、对账与资金操作；系统层面用角色互斥矩阵控制，无法分离时以补偿性控制（复核、抽查）替代。
日志留存与周期
日志留存期限按法规与业务要求设定（如网络安全法要求网络日志留存不少于六个月）；分级设定：安全与审计关键日志更长，调试类日志更短，到期按流程销毁。
漏洞管理审计要点
漏洞管理审计检查闭环：资产覆盖（是否漏扫资产）、扫描频率、评级与修复时限、例外审批、复测验证；重点看“超期未修复”清单与例外管理。
审计类型与触发场景
常见审计类型：内部审计（自查与治理）、外部审计（财务审计中的 IT 部分、认证审核）、专项审计（安全、外包、合规）；触发场景包括法定要求、认证周期、重大事件与并购。
审计证据与抽样
审计证据要相关、充分、可靠：系统截图、配置导出、审批记录、访谈纪要都可作为证据；抽样需覆盖关键风险与全期间，重大事项全查而非抽样。
风险处置与接受
风险处置四选项：降低（加控制）、规避（停止活动）、转移（保险/外包）、接受（书面批准）；接受要有授权层级与期限，并纳入监控清单定期回顾。
渗透测试与安全评估
渗透测试以授权方式模拟攻击验证防护效果：需书面授权范围与时间窗，测试后提交报告与修复建议，修复后复测；测试过程避免影响生产与真实数据。
供应商与外包审计
第三方审计评估供应商的安全与服务水平：合同条款（数据保护、审计权、SLA）、准入评估（资质与能力）、持续监控（报告与事件通知）与年度复审，重点是数据与关键依赖。
数据留存与销毁
数据留存规则按类型设定最短与最长保留期（合同、财务、日志、个人信息各有要求）；到期执行删除或匿名化，销毁需记录（对象、方式、执行人、时间）。
GDPR 合规要点（出海）
GDPR 适用于处理欧盟数据主体个人数据的组织：要求合法性基础、数据主体权利响应、数据处理记录、数据保护影响评估与 72 小时事件通知等；域外适用与重罚是其特点。
安全事件报告义务
安全事件按法规与合同要求对外报告：面向监管的通报（如个人信息泄露、关键信息基础设施事件）与面向客户的告知不同主体与时限；内部先按应急流程处置并留存证据。
数据泄露应对与通知
数据泄露应对包含：控制与取证、影响评估（是否达到通知门槛）、通知个人与监管、补救措施（改密、监控欺诈）与复盘整改；通知措辞需清晰说明风险与行动建议。
整改跟踪与验证
整改台账记录每项发现的整改措施、责任人、期限与状态；到期未改的要升级说明，完成后由审计方验证（复测证据）再关闭，形成闭环。
安全基线标准参考
CIS Benchmarks 等公开基线标准给出操作系统、数据库、中间件的加固建议（分等级）；使用方式是按业务场景选取条目、记录裁剪理由，而非全量照搬。
数据跨境传输合规
数据跨境传输需满足适用法域要求：中国法下涉及安全评估、标准合同、认证等路径（按情形选择并履行义务）；GDPR 下需充分性认定、SCC 或 BCR 等机制，并完成传输影响评估。
隐私影响评估 PIA/DPIA
隐私影响评估在项目早期分析个人数据处理的风险：数据流、合法性基础、最小化、留存、共享与跨境；高残余风险需处置（降险或不予开展），评估记录留存备查。
控制测试方法
控制测试验证控制是否按设计持续运行：穿行测试（走一遍流程）、抽样测试（核对执行记录）、重新执行（独立重跑控制）与系统配置检查；测试要留底稿。
合规与安全意识培训
合规培训按角色分层：全员覆盖基础安全与行为准则，开发与运维补充数据保护与操作规范，管理层覆盖治理责任；培训有签到与考核记录供审计。
数据处理协议 DPA
数据处理协议约定委托处理关系：处理目的与范围、安全措施、子处理者管理、协助义务（权利响应与事件通知）、审计与删除返还条款；采购云服务与外包时随合同签署。
合规要求映射
合规映射把多套要求（等保、ISO 27001、法规条款、客户问卷）映射到统一控制矩阵：一条控制对应多项要求，减少重复建设；映射表是应对多标准审计的工作底座。
合规证据收集
合规工作日常化要求证据随时可取：权限复核记录、变更审批、培训签到、演练报告按目录归档；建立证据清单与更新节奏，避免审计期集中补材料。
认证审核流程
管理体系认证（如 ISO/IEC 27001）通常分两阶段：阶段一审查体系文件与准备度，阶段二现场核查运行证据；通过后进入三年周期，年度监督审核保持证书有效。
合规文化建设
合规文化的标志是员工按规范行事而非仅在检查前应付：领导者示范、规则与现实匹配、违规一致处理、正负激励并用；文化薄弱时，制度再厚也会被绕过。
数据保护负责人 DPO
DPO（数据保护官）负责监督数据保护合规：参与评估、对接监管与数据主体请求、开展培训与审计；需要独立性（不受业务线干预）与必要的资源支持。
内审职能与独立性
内部审计的独立性与客观性是价值前提：报告线独立于被审业务、轮换审计人员、与被审方无直接利益关系；独立性受损时结论可信度与改进推动力同步下降。
外部审计配合
与外审高效配合：提前对齐范围与时间表、指定对接人、按清单备证据、对差异当场澄清；外审意见需内部评审后再回应，避免口径不一致。
法规与监管动态跟踪
合规职能持续跟踪适用法规变化（数据、安全、行业监管）：订阅权威来源、评估影响、更新内部制度与控制，形成“变化—评估—落地”的闭环记录。
利益冲突申报
利益冲突申报要求员工披露可能影响公正履职的关系（亲属供应商、兼职、投资）：定期申报 + 事项触发申报，由合规部门评估并采取回避或批准措施。
记录管理
记录管理覆盖记录的创建、分类、留存、检索与销毁：明确各类记录的责任人、介质与期限，保证完整、可用、可追溯；电子与纸质记录按统一规则管理。
审计自查清单
用自查清单在正式审计前完成准备：按控制域列出要求、责任人、证据位置与状态；自查发现的缺口优先整改，避免在审计现场被动应对。
审计委员会与治理层对接
审计委员会代表治理层监督审计与内控：审议审计计划与报告、跟踪重大缺陷整改、协调内外部审计；IT 重大风险与合规事项应定期上报委员会。
举报与投诉渠道
举报机制提供独立、保密的上报渠道（如举报邮箱、第三方热线）：接收、调查、反馈与保护举报人免受报复；处理记录受控保存，供治理层监督。
员工行为准则
行为准则规定员工与合作伙伴互动的基本规则：利益冲突、礼品与招待、数据与资产使用、信息保密与对外沟通；需配套培训、确认签署与违规处理流程。
监管检查应对
面对监管检查：指定统一对接人，按检查提纲准备材料，如实回答，不擅自扩大或缩小口径；现场问题记录在案，限期整改并书面向监管反馈。