做 IT 服务管理这行绕不开 ITIL 这套框架。我最早接触它是在一个运维团队里那时候大家连“事件”和“问题”的区别都说不清出了故障全靠嗓门大的人拍板。后来系统学了 ITIL 4 Foundation考完证最大的感受不是“多了一纸证书”而是手上终于有了一套能跟人讲清楚的共同语言。但紧跟着的问题来了ITIL 4 Foundation 中文版的学习材料实在太散官方术语翻译在不同资料里各说各话笔记记了三四个地方考前想找一条定义得翻半天。这篇就聊我怎么把这堆东西收拾成一个能长期用、能随时查、能直接克隆到本地的资料仓库。它不是什么官方教材的搬运而是一套目录结构、命名规范、术语对照和复习节奏的组合方案适合正在备考 ITIL 4 Foundation 的人也适合已经考完但想把知识沉淀下来的同行。全文讲的是“怎么整理”不是“去哪里拿盗版”这一点我先说在前面。1. 为什么我要自己攒一个 ITIL 4 Foundation 中文资料仓库1.1 散装资料踩过的三个坑第一个坑是术语口径打架。ITIL 4 里 Incident、Problem、Change 这三个词我见过至少四种中文译法。Incident 有人译“事件”有人译“事故”Problem 有的译“问题”有的译“难题”Change 里又分出“变更控制”和“变更实现”。这在英文语境下靠上下文能分辨翻成中文之后“事件”和“事故”在应急场景里完全是两个严重程度。考前刷题时我一度因为把 Incident 当成“事故”去理解连续错了三道关于优先级的题。第二个坑是版本混杂。ITIL 4 发布之后实践指南Practice Guide陆续有更新一些早期整理的思维导图还停留在刚发布时的表述。我的笔记里同时存在“服务价值链有 6 个活动”和“服务价值链包含 9 个要素”两种说法前者是对的后者是把价值链活动和 SVS 的组成要素搞混了。没有版本标记你根本不知道哪份资料是新的。第三个坑是检索成本高。我当时的状态是纸质笔记一本、本地文档一个文件夹、云笔记若干条、手机截图几十张。想查“服务级别管理里的 SLA 和 OLA 区别”得在四个地方各搜一遍。这种状态下复习效率极低一小时里真正在学的时间不到二十分钟剩下全在找东西。1.2 仓库化的核心思路把“找资料”变成“查目录”我后来想明白一件事资料管理的瓶颈从来不是“资料不够”而是“入口太多”。解决办法不是继续收集而是收敛入口。类比一下家里的票据如果水电费单、发票、保修卡全塞在一个抽屉里找的时候就是抓瞎但如果按年份分文件夹、每份文件按“日期-类型-金额”命名你要找什么脑子里先有路径手就能直接伸过去。落到这个仓库上我定了三条原则。单一入口所有资料只在一个根目录下不在别处留副本避免“改了一处忘了另一处”。命名即检索文件名本身携带足够信息多数时候不用打开文件就能判断内容。内容与元数据分离正文只管写知识版本、来源、更新时间这些信息放在文件头部的属性区两者互不干扰。这三条听起来简单但坚持下来效果比装一堆笔记软件强得多。1.3 版权与合规的边界哪些能放哪些坚决不放这一点必须单独讲因为很多人做资料仓库做着做着就越界了。我的划分标准很明确可以放自己手写的学习笔记、自己画的框架图、公开的框架结构描述比如四维模型的四个维度名称、34 个实践的清单名、中英术语对照表、自己总结的记忆口诀、自己做错的题目和自己的解析。坚决不放官方教材的正文扫描件、官方样题的完整题干和选项原文、任何付费课程的讲义原件、别人整理但你不知道来源的“内部资料”。注意仓库里如果混进了来源不明的整本教材一旦分发出去就是实打实的侵权而且这类文件通常体积大、检索差对复习帮助远不如自己写一遍笔记。我见过有人仓库里塞了七八个版本的所谓“精讲”结果考前一个都没看完。我自己的做法是官方材料只保留“我从中提炼出了什么”原文一律不留。比如读完一章我写一页自己的话概括标注“基于某章的自我总结”这样既合规又逼着自己做加工——加工过的知识才是自己的。2. 仓库整体结构设计从目录树到命名规范2.1 顶层目录的五段式划分结构设计的关键是“一眼能看出该往哪放”。我最终定的是五段式用了两年多没改过itil4-notes/ ├── 00-index/ 索引与导航 │ ├── README.md 仓库总说明 │ ├── toc.md 自动生成的目录 │ └── glossary.md 术语中英对照总表 ├── 01-framework/ 框架主干 │ ├── dimensions/ 四个维度 │ ├── value-chain/ 服务价值链活动 │ ├── principles/ 七条指导原则 │ └── svs/ 服务价值系统整体 ├── 02-practices/ 34 个管理实践 │ ├── general/ 通用管理实践 │ ├── service/ 服务管理实践 │ └── technical/ 技术管理实践 ├── 03-cases/ 场景与案例 │ ├── incident/ 故障类 │ ├── change/ 变更类 │ └── improvement/ 改进类 └── 04-review/ 备考专用 ├── cards/ 知识卡片 ├── mistakes/ 错题本 └── exams/ 模拟记录为什么要这么分01到03是知识本体按“框架—实践—场景”三层递进符合人的认知顺序先知道有哪些部件再知道每个部件怎么用最后看部件组合起来在真实场景里长什么样。04是学习过程跟知识本体隔开因为这部分更新频率极高每天都要动混在知识区里会让目录变脏。00是导航层永远放最前面因为它是我打开仓库后第一个要看的东西。用两位数字前缀的好处是排序稳定。不管在什么系统里02-practices一定排在03-cases前面不会因为字母序或者修改时间乱掉。这个细节很小但你文件上到几百个之后排序稳定能省掉大量翻找时间。2.2 文件命名规范让文件名自己说话命名规范我吃过亏。早期我用中文长句命名比如“关于变更控制中紧急变更处理流程的笔记.md”结果在命令行里根本没法敲路径长度也经常超限。后来改成固定格式[编号]-[英文关键词]-[中文短名].md。位置命名格式示例说明实践笔记[两位编号]-[英文]-[中文].md09-incident-事件管理.md编号按清单顺序固定场景案例[日期]-[场景]-[一句话].md20240312-变更失败回滚.md日期用年月日知识卡片[主题]-[序号].md价值链-003.md序号不带前导零术语条目直接放在 glossary.md 表格里不单独建文件避免碎片化关键是编号一旦定了就不改。因为编号会被索引文件、卡片、错题本互相引用改一次编号所有引用全断。我给 34 个实践编了固定号从 01 到 34按三大类顺序排笔记文件名、错题本的“关联实践”、卡片的标签全部用这个号。两年下来新增内容无数编号一个没动过。2.3 元数据区每个文件头部的身份证文件正文之前我加了一小段属性区用三个短横线包起来。格式大概是--- title: 事件管理 practice_id: 09 category: service version: itil4-2023 source: 自整理 updated: 2024-03-12 status: 已复核 ---这一段的价值在于可被脚本读取。后来我写的索引生成脚本就是靠解析这些字段来生成目录和统计报表的。status字段特别有用我设了三个值草稿、已复核、待更新。考前只复习“已复核”的草稿区的内容知道有就行不占用复习时间。这个小机制帮我砍掉了将近三成的无效复习量。3. ITIL 4 核心框架的中文化整理要点3.1 四维模型与服务价值系统先搞清谁包含谁这是最容易记混的地方。我一开始也把四维模型和 SVS 画成并列关系后来才理清服务价值系统SVS是那个大框四个维度是框里的一个要素和治理、服务价值链、实践、持续改进并列。换句话说维度不是独立存在的它是用来审视价值链和实践的四个视角。四个维度分别是组织与人员、信息与技术、合作伙伴与供应商、价值流与流程。记忆上我用了“人、机、外、流”四个字虽然不严谨但比背全称快。更重要的是理解它的用途任何一个服务出问题你都从这四个角度各问一遍。比如服务台响应慢组织与人员角度问“是不是人手不够或者技能不匹配”信息与技术角度问“工单系统是不是卡”合作伙伴角度问“外包的一线支持响应是不是不到位”价值流角度问“这个审批环节是不是本来就不该存在”。四个问题问下来根因基本露头了。我在01-framework/svs/下放了一张自己重画的层级图只用方框和箭头标注了“治理在上、价值链在中、实践在下、持续改进贯穿、四维包裹”的关系。这张图我在考前看了不下二十遍比任何文字描述都有效。自己画一遍的价值在于你会被迫决定每条线的方向画错了说明理解错了改一次就记牢了。3.2 34 个实践的分组记忆法34 个实践硬背是灾难。ITIL 4 本身给了分组14 个通用管理实践、17 个服务管理实践、3 个技术管理实践。但光有分组还不够我在每组里又做了二次聚类。通用管理实践 14 个我按“管方向、管资源、管关系、管人”分成四簇簇包含实践记忆抓手管方向战略管理、架构管理、组合管理、风险管理想清楚做什么、边界在哪、风险兜底管资源服务财务管理、供应商管理、知识管理、度量与报告钱、外援、经验、数字管关系关系管理、组织变革管理对内对人对外对客管人劳动力与人才管理就一个最容易记服务管理实践 17 个我按“服务生命周期”串起来业务分析 → 服务设计 → 服务目录管理 → 服务级别管理 → 服务连续性管理 → 可用性管理 → 容量与性能管理 → 服务配置管理 → IT 资产管理 → 变更控制 → 发布管理 → 部署技术类→ 服务验证与测试 → 服务台 → 事件管理 → 服务请求管理 → 问题管理 → 监控与事件管理。这条链子走一遍17 个基本不会漏。技术管理实践只有 3 个部署管理、基础设施与平台管理、软件开发与管理。数量少但要注意“部署管理”在技术类里跟服务管理里的“发布管理”是两回事——发布是对业务可见的部署是技术动作。这个区分考试爱考。3.3 术语对照表整个仓库的地基术语表是我最花心思的部分因为它决定了所有笔记的一致性。我的做法是给每个术语建一行包含四列英文、仓库统一译名、常见异译、备注。英文统一译名常见异译备注Incident事件事故、突发事件指非计划的服务中断或质量下降不含计划内维护Problem问题难题指事件的一个或多个根本原因Change变更改动指任何可能影响服务的增加、修改或移除Service Desk服务台服务台席、客服中心单一联系点注意别译成“桌面”Workaround临时措施变通方案、绕行方案不解决根因只恢复服务Known Error已知错误已知问题已被识别并记录根因的问题建立这张表之后我给自己定了一条死规矩写笔记时如果表里没有先补表再写笔记。这条规矩一开始很烦因为总在补表但补了大约六十个词之后速度就上来了而且后续所有笔记的术语完全一致检索时一个词能搜全。这叫“前期多花十分钟后期省下十小时”。4. 仓库搭建的完整实操过程4.1 工具选型为什么最后选了“纯文本 版本控制”选型上我试过三种路子各有取舍方案优点缺点适合谁云端笔记软件多端同步方便、上手快数据在别人服务器、导出格式受限、大表格体验差只在手机上看的人本地富文本文档排版自由、能插入图片版本管理困难、检索弱、文件膨胀后很卡只写不长查的人纯文本 Markdown 版本控制全文检索极快、版本可回溯、脚本可加工需要一点命令行基础、图片要单独管理想长期维护的人我选第三种核心理由只有一个可被脚本加工。纯文本意味着我能用几行代码把所有文件扫一遍生成目录、统计覆盖率、检查哪些实践还没写笔记。这种“机器能读懂”的特性是富文本给不了的。图片我单独放在assets/下命名跟笔记文件对应不混在正文目录里。4.2 从零建库初始化与批量导入第一步建目录骨架。我用一条命令批量创建省得一个个点mkdir -p itil4-notes/{00-index,01-framework/{dimensions,value-chain,principles,svs},02-practices/{general,service,technical},03-cases/{incident,change,improvement},04-review/{cards,mistakes,exams},assets}第二步批量生成 34 个实践笔记的空壳文件。手工建 34 个文件是折磨而且容易编号错乱用脚本一次性生成cd itil4-notes/02-practices for i in $(seq -w 1 34); do echo --- ${i}-placeholder.md echo practice_id: ${i} ${i}-placeholder.md echo status: 草稿 ${i}-placeholder.md echo --- ${i}-placeholder.md done第三步把历史散装资料按“内容归类”而不是“来源归类”搬进来。这一步最容易偷懒——很多人直接把原来的文件夹原样拖进来结果仓库里出现五套互相冲突的结构。我的做法是先建一个_inbox/临时区所有旧资料先扔进去然后一条一条读读完一条写一条新笔记旧文件删掉。慢但干净。这个过程我花了三个周末总共处理了大约两百个碎片最后留下的有效内容不到原来体积的三分之一。提示搬家阶段千万别做“留着以后再说”的决定。凡是读完觉得“可能有用但说不清哪里有用”的直接删。仓库的价值在于密度不在于体积。4.3 用脚本自动生成索引这是整个仓库最有价值的一段代码。手工维护目录维护到第三周就会放弃交给脚本每次加完笔记跑一下目录永远是新的。import os import re from pathlib import Path ROOT Path(itil4-notes) def parse_meta(path): 读取文件头部的元数据区 meta {} try: text path.read_text(encodingutf-8) except UnicodeDecodeError: return meta m re.match(r^---\n(.*?)\n---, text, re.S) if not m: return meta for line in m.group(1).splitlines(): if : in line: k, v line.split(:, 1) meta[k.strip()] v.strip() return meta def build_toc(): lines [# 仓库目录, ] for sub in [01-framework, 02-practices, 03-cases]: lines.append(f## {sub}) base ROOT / sub if not base.exists(): continue for f in sorted(base.rglob(*.md)): meta parse_meta(f) title meta.get(title, f.stem) status meta.get(status, 未标注) rel f.relative_to(ROOT).as_posix() lines.append(f- [{title}]({rel}) — {status}) lines.append() (ROOT / 00-index / toc.md).write_text(\n.join(lines), encodingutf-8) def coverage_report(): 统计哪些实践还没有正式笔记 done, todo [], [] for f in sorted((ROOT / 02-practices).rglob(*.md)): meta parse_meta(f) if meta.get(status) in (已复核, 草稿) and placeholder not in f.stem: done.append(meta.get(title, f.stem)) else: todo.append(f.stem) print(f已完成 {len(done)} 个待补 {len(todo)} 个) print(待补清单, , .join(todo[:20])) if __name__ __main__: build_toc() coverage_report()跑完之后00-index/toc.md就是全仓库的导航。这个脚本我只写了不到六十行但它替代了我每天至少五次的翻找动作。coverage_report那个函数尤其好用考前一周跑一次一眼看出哪几个实践还是空白直接定当天的复习计划。4.4 版本管理与备份给自己留后悔药纯文本仓库的最大好处是能上版本控制。我每次完成一个主题的整理就提交一次提交信息写清楚改了什么。这样有两个好处一是改错了能回滚二是一段时间后能看见自己的学习轨迹。cd itil4-notes git add . git commit -m 补完事件管理与问题管理的对比笔记 git log --oneline -10备份策略我用了“三二一”的简化版本地一份、移动硬盘一份、异地一份。备份频率是每周一次用一条打包命令就行tar -czf backup-$(date %Y%m%d).tar.gz itil4-notes/这里有个容易忽略的点备份要验证能不能恢复。我第一次做备份时压缩包里漏了隐藏目录恢复的时候元数据全丢了。后来我加了个习惯每次备份完随机挑三个文件解压出来看看内容对不对。这个动作花不了一分钟但救过我一次。5. 用这个仓库备考的实操节奏5.1 三阶段复习法从铺开到收敛我把备考切成三段每段用仓库的不同区域。第一阶段铺面约两周目标是知道有哪些东西。这一阶段我只做一件事——给 34 个实践各写一页纸每页写清“这个实践解决什么问题、关键概念有哪些、跟哪几个实践关系最近”。写不出来就说明没读懂回去补。这一阶段结束时02-practices/下应该没有placeholder了。这一阶段不刷题刷了也白刷因为概念还没成网。第二阶段织网约一周目标是知道它们怎么连。这一阶段我泡在03-cases/里每天挑一个真实场景写下来然后强制自己用框架语言复述一遍。比如“某系统凌晨批量任务失败导致早班业务卡住”写完之后要能对应到这是一个事件走事件管理流程根因排查后如果发现是配置漂移那就升级为问题修复需要改配置那就是一个变更。这种“场景→框架”的翻译练习比背定义有用十倍。第三阶段收敛约三天只看04-review/。知识卡片过一遍错题本过一遍然后做模拟。这一阶段不碰新内容防止考前焦虑。5.2 知识卡片与错题回灌知识卡片我控制在两百字以内一张卡只讲一件事正面写问题背面写答案。举例正面变更控制的三个变更类型分别是什么背面标准变更预先授权、低风险、可重复、常规变更需评估授权、紧急变更需专门授权流程事后回溯。卡片的价值不在于“看”在于“翻”。我每天通勤路上翻二十张翻到能条件反射说出答案就抽出来放到“已掌握”堆剩下的继续翻。一周下来两百张卡里能留三十张来回翻就不错了。错题本我用的是“回灌”机制每道错题记三样东西——我的错答、正确答案、我错在哪一步。然后最关键的一步把这道题涉及的知识点反向更新到对应的实践笔记里并在笔记里加一行“易错点……”。这样错题就不只是一个孤立的记录它变成了笔记的一部分。下次复习笔记时易错点会自动被看到。5.3 模拟考试的节奏控制模拟我会严格计时但有意识地练三件事。第一是先扫一遍再动笔。四十道题先用两分钟从头到尾看一遍把明显会做的和需要想的分开能省下大量反复读题的时间。第二是关键词圈定法。ITIL 4 的题干普遍较长但决定答案的往往就一两个词。看到“根本原因”基本锁定问题管理看到“单一联系点”锁定服务台看到“预先授权”锁定标准变更。第三是不确定的题标记后置。第一遍只做有把握的标记不确定的最后统一处理。我实考时第一遍做完还剩十八分钟回头改了四道题其中两道是原本想太多改对的。6. 常见问题与排查技巧实录6.1 术语对不上中文资料互相打架怎么办这是最高频的问题。我的处理原则是以英文原词为锚中文译名只是标签。遇到两种译法先判断是不是同一个英文词如果是就在术语表里定一个“仓库统一译名”其他译法写进“常见异译”列如果不是同一个英文词那多半是概念本身不同必须分开建条目。举个典型例子“服务级别管理”和“服务级别协议”经常被混着说但前者是一个实践后者是前者产出的一个文档。这种混淆靠翻译是解决不了的只能靠回到英文去对齐。我在术语表里给这类词加了“易混”标记复习时专门盯。还有一种情况是翻译过度。有些资料把“Value Stream”译成“价值流”也有人译“价值链”但 ITIL 4 里的“服务价值链”Service Value Chain是专有名词不能跟“价值流”混用。这类专有名词我在术语表里加了“专有禁止意译”的备注见到就警惕。6.2 仓库膨胀文件越多越找不到仓库用满半年一定会膨胀。我遇到过两个具体症状一是检索变慢二是同一主题出现三个版本的笔记不知道信哪个。对治第一条我的做法是强制分层。知识本体最多三层目录超过三层就说明分类粒度太细了需要合并。场景案例按季度归档老的打包成压缩包只在需要时解压。_inbox/每周必须清空一次清不掉的就删。对治第二条我用status字段加了一条规则同一主题只允许一个已复核状态的文件。如果写了新版本旧版本立刻改成待更新或者直接删。这条规则执行起来有点痛因为删自己写的东西总有心理负担但留着两份互相矛盾的笔记危害比删掉大得多。6.3 问题速查表现象可能原因处理方法搜不到某个术语的笔记术语表没建条目或者笔记用了异译先搜英文原词仍搜不到就在术语表补一行索引文件内容过期新增笔记后没跑脚本每次改完统一跑一次索引生成笔记之间互相矛盾版本混杂旧笔记没清理查version字段保留新版旧版标待更新复习效率突然下降仓库里草稿太多噪音大只筛status: 已复核的内容复习备份恢复后元数据丢失打包时漏了隐藏目录或点文件备份后随机抽查三个文件的头部是否完整卡片翻了很多但记不住卡片太长一张塞了多个知识点拆成单点卡片正面只问一件事案例写完跟框架对不上场景理解有偏差或框架概念没吃透回到该实践的笔记重读用框架语言逐句复述场景补充两个我踩过的坑。一个是过度追求排版。我有一阵子花大量时间调表格对齐、加装饰线看起来很爽但真正学习的时间被挤压了。仓库是给自己用的能读就行排版够用就好。另一个是卡片只做不翻。我一口气做了两百多张卡结果考前只翻了四十张剩下的全是沉没成本。后来改成边做边翻、做一批翻一批记忆效果才上来。还有一个心得值得一提仓库要定期做减法。我每季度会花半小时把三个月没打开过的文件挑出来看一眼能删的删能合的合。这个动作听起来像浪费时间但每次做完仓库的检索速度和我的使用意愿都会明显回升。资料管理这件事收集是本能删减是本事。我个人在实际操作中的体会是这套仓库最值钱的部分不是那几百份笔记而是那份术语对照表和那几十条易错点。前者保证了所有内容能互相对上后者构成了考前最精准的复习清单。框架会更新版本会迭代但只要这两样东西在换一版资料也只是填空而已。 
长河君 · 2026/11/2 23:04:51 · 阅读 1.2k ITIL 4 Foundation中文版资料仓库：术语对照、索引与备考整理方案
做 IT 服务管理这行绕不开 ITIL 这套框架。我最早接触它是在一个运维团队里那时候大家连“事件”和“问题”的区别都说不清出了故障全靠嗓门大的人拍板。后来系统学了 ITIL 4 Foundation考完证最大的感受不是“多了一纸证书”而是手上终于有了一套能跟人讲清楚的共同语言。但紧跟着的问题来了ITIL 4 Foundation 中文版的学习材料实在太散官方术语翻译在不同资料里各说各话笔记记了三四个地方考前想找一条定义得翻半天。这篇就聊我怎么把这堆东西收拾成一个能长期用、能随时查、能直接克隆到本地的资料仓库。它不是什么官方教材的搬运而是一套目录结构、命名规范、术语对照和复习节奏的组合方案适合正在备考 ITIL 4 Foundation 的人也适合已经考完但想把知识沉淀下来的同行。全文讲的是“怎么整理”不是“去哪里拿盗版”这一点我先说在前面。1. 为什么我要自己攒一个 ITIL 4 Foundation 中文资料仓库1.1 散装资料踩过的三个坑第一个坑是术语口径打架。ITIL 4 里 Incident、Problem、Change 这三个词我见过至少四种中文译法。Incident 有人译“事件”有人译“事故”Problem 有的译“问题”有的译“难题”Change 里又分出“变更控制”和“变更实现”。这在英文语境下靠上下文能分辨翻成中文之后“事件”和“事故”在应急场景里完全是两个严重程度。考前刷题时我一度因为把 Incident 当成“事故”去理解连续错了三道关于优先级的题。第二个坑是版本混杂。ITIL 4 发布之后实践指南Practice Guide陆续有更新一些早期整理的思维导图还停留在刚发布时的表述。我的笔记里同时存在“服务价值链有 6 个活动”和“服务价值链包含 9 个要素”两种说法前者是对的后者是把价值链活动和 SVS 的组成要素搞混了。没有版本标记你根本不知道哪份资料是新的。第三个坑是检索成本高。我当时的状态是纸质笔记一本、本地文档一个文件夹、云笔记若干条、手机截图几十张。想查“服务级别管理里的 SLA 和 OLA 区别”得在四个地方各搜一遍。这种状态下复习效率极低一小时里真正在学的时间不到二十分钟剩下全在找东西。1.2 仓库化的核心思路把“找资料”变成“查目录”我后来想明白一件事资料管理的瓶颈从来不是“资料不够”而是“入口太多”。解决办法不是继续收集而是收敛入口。类比一下家里的票据如果水电费单、发票、保修卡全塞在一个抽屉里找的时候就是抓瞎但如果按年份分文件夹、每份文件按“日期-类型-金额”命名你要找什么脑子里先有路径手就能直接伸过去。落到这个仓库上我定了三条原则。单一入口所有资料只在一个根目录下不在别处留副本避免“改了一处忘了另一处”。命名即检索文件名本身携带足够信息多数时候不用打开文件就能判断内容。内容与元数据分离正文只管写知识版本、来源、更新时间这些信息放在文件头部的属性区两者互不干扰。这三条听起来简单但坚持下来效果比装一堆笔记软件强得多。1.3 版权与合规的边界哪些能放哪些坚决不放这一点必须单独讲因为很多人做资料仓库做着做着就越界了。我的划分标准很明确可以放自己手写的学习笔记、自己画的框架图、公开的框架结构描述比如四维模型的四个维度名称、34 个实践的清单名、中英术语对照表、自己总结的记忆口诀、自己做错的题目和自己的解析。坚决不放官方教材的正文扫描件、官方样题的完整题干和选项原文、任何付费课程的讲义原件、别人整理但你不知道来源的“内部资料”。注意仓库里如果混进了来源不明的整本教材一旦分发出去就是实打实的侵权而且这类文件通常体积大、检索差对复习帮助远不如自己写一遍笔记。我见过有人仓库里塞了七八个版本的所谓“精讲”结果考前一个都没看完。我自己的做法是官方材料只保留“我从中提炼出了什么”原文一律不留。比如读完一章我写一页自己的话概括标注“基于某章的自我总结”这样既合规又逼着自己做加工——加工过的知识才是自己的。2. 仓库整体结构设计从目录树到命名规范2.1 顶层目录的五段式划分结构设计的关键是“一眼能看出该往哪放”。我最终定的是五段式用了两年多没改过itil4-notes/ ├── 00-index/ 索引与导航 │ ├── README.md 仓库总说明 │ ├── toc.md 自动生成的目录 │ └── glossary.md 术语中英对照总表 ├── 01-framework/ 框架主干 │ ├── dimensions/ 四个维度 │ ├── value-chain/ 服务价值链活动 │ ├── principles/ 七条指导原则 │ └── svs/ 服务价值系统整体 ├── 02-practices/ 34 个管理实践 │ ├── general/ 通用管理实践 │ ├── service/ 服务管理实践 │ └── technical/ 技术管理实践 ├── 03-cases/ 场景与案例 │ ├── incident/ 故障类 │ ├── change/ 变更类 │ └── improvement/ 改进类 └── 04-review/ 备考专用 ├── cards/ 知识卡片 ├── mistakes/ 错题本 └── exams/ 模拟记录为什么要这么分01到03是知识本体按“框架—实践—场景”三层递进符合人的认知顺序先知道有哪些部件再知道每个部件怎么用最后看部件组合起来在真实场景里长什么样。04是学习过程跟知识本体隔开因为这部分更新频率极高每天都要动混在知识区里会让目录变脏。00是导航层永远放最前面因为它是我打开仓库后第一个要看的东西。用两位数字前缀的好处是排序稳定。不管在什么系统里02-practices一定排在03-cases前面不会因为字母序或者修改时间乱掉。这个细节很小但你文件上到几百个之后排序稳定能省掉大量翻找时间。2.2 文件命名规范让文件名自己说话命名规范我吃过亏。早期我用中文长句命名比如“关于变更控制中紧急变更处理流程的笔记.md”结果在命令行里根本没法敲路径长度也经常超限。后来改成固定格式[编号]-[英文关键词]-[中文短名].md。位置命名格式示例说明实践笔记[两位编号]-[英文]-[中文].md09-incident-事件管理.md编号按清单顺序固定场景案例[日期]-[场景]-[一句话].md20240312-变更失败回滚.md日期用年月日知识卡片[主题]-[序号].md价值链-003.md序号不带前导零术语条目直接放在 glossary.md 表格里不单独建文件避免碎片化关键是编号一旦定了就不改。因为编号会被索引文件、卡片、错题本互相引用改一次编号所有引用全断。我给 34 个实践编了固定号从 01 到 34按三大类顺序排笔记文件名、错题本的“关联实践”、卡片的标签全部用这个号。两年下来新增内容无数编号一个没动过。2.3 元数据区每个文件头部的身份证文件正文之前我加了一小段属性区用三个短横线包起来。格式大概是--- title: 事件管理 practice_id: 09 category: service version: itil4-2023 source: 自整理 updated: 2024-03-12 status: 已复核 ---这一段的价值在于可被脚本读取。后来我写的索引生成脚本就是靠解析这些字段来生成目录和统计报表的。status字段特别有用我设了三个值草稿、已复核、待更新。考前只复习“已复核”的草稿区的内容知道有就行不占用复习时间。这个小机制帮我砍掉了将近三成的无效复习量。3. ITIL 4 核心框架的中文化整理要点3.1 四维模型与服务价值系统先搞清谁包含谁这是最容易记混的地方。我一开始也把四维模型和 SVS 画成并列关系后来才理清服务价值系统SVS是那个大框四个维度是框里的一个要素和治理、服务价值链、实践、持续改进并列。换句话说维度不是独立存在的它是用来审视价值链和实践的四个视角。四个维度分别是组织与人员、信息与技术、合作伙伴与供应商、价值流与流程。记忆上我用了“人、机、外、流”四个字虽然不严谨但比背全称快。更重要的是理解它的用途任何一个服务出问题你都从这四个角度各问一遍。比如服务台响应慢组织与人员角度问“是不是人手不够或者技能不匹配”信息与技术角度问“工单系统是不是卡”合作伙伴角度问“外包的一线支持响应是不是不到位”价值流角度问“这个审批环节是不是本来就不该存在”。四个问题问下来根因基本露头了。我在01-framework/svs/下放了一张自己重画的层级图只用方框和箭头标注了“治理在上、价值链在中、实践在下、持续改进贯穿、四维包裹”的关系。这张图我在考前看了不下二十遍比任何文字描述都有效。自己画一遍的价值在于你会被迫决定每条线的方向画错了说明理解错了改一次就记牢了。3.2 34 个实践的分组记忆法34 个实践硬背是灾难。ITIL 4 本身给了分组14 个通用管理实践、17 个服务管理实践、3 个技术管理实践。但光有分组还不够我在每组里又做了二次聚类。通用管理实践 14 个我按“管方向、管资源、管关系、管人”分成四簇簇包含实践记忆抓手管方向战略管理、架构管理、组合管理、风险管理想清楚做什么、边界在哪、风险兜底管资源服务财务管理、供应商管理、知识管理、度量与报告钱、外援、经验、数字管关系关系管理、组织变革管理对内对人对外对客管人劳动力与人才管理就一个最容易记服务管理实践 17 个我按“服务生命周期”串起来业务分析 → 服务设计 → 服务目录管理 → 服务级别管理 → 服务连续性管理 → 可用性管理 → 容量与性能管理 → 服务配置管理 → IT 资产管理 → 变更控制 → 发布管理 → 部署技术类→ 服务验证与测试 → 服务台 → 事件管理 → 服务请求管理 → 问题管理 → 监控与事件管理。这条链子走一遍17 个基本不会漏。技术管理实践只有 3 个部署管理、基础设施与平台管理、软件开发与管理。数量少但要注意“部署管理”在技术类里跟服务管理里的“发布管理”是两回事——发布是对业务可见的部署是技术动作。这个区分考试爱考。3.3 术语对照表整个仓库的地基术语表是我最花心思的部分因为它决定了所有笔记的一致性。我的做法是给每个术语建一行包含四列英文、仓库统一译名、常见异译、备注。英文统一译名常见异译备注Incident事件事故、突发事件指非计划的服务中断或质量下降不含计划内维护Problem问题难题指事件的一个或多个根本原因Change变更改动指任何可能影响服务的增加、修改或移除Service Desk服务台服务台席、客服中心单一联系点注意别译成“桌面”Workaround临时措施变通方案、绕行方案不解决根因只恢复服务Known Error已知错误已知问题已被识别并记录根因的问题建立这张表之后我给自己定了一条死规矩写笔记时如果表里没有先补表再写笔记。这条规矩一开始很烦因为总在补表但补了大约六十个词之后速度就上来了而且后续所有笔记的术语完全一致检索时一个词能搜全。这叫“前期多花十分钟后期省下十小时”。4. 仓库搭建的完整实操过程4.1 工具选型为什么最后选了“纯文本 版本控制”选型上我试过三种路子各有取舍方案优点缺点适合谁云端笔记软件多端同步方便、上手快数据在别人服务器、导出格式受限、大表格体验差只在手机上看的人本地富文本文档排版自由、能插入图片版本管理困难、检索弱、文件膨胀后很卡只写不长查的人纯文本 Markdown 版本控制全文检索极快、版本可回溯、脚本可加工需要一点命令行基础、图片要单独管理想长期维护的人我选第三种核心理由只有一个可被脚本加工。纯文本意味着我能用几行代码把所有文件扫一遍生成目录、统计覆盖率、检查哪些实践还没写笔记。这种“机器能读懂”的特性是富文本给不了的。图片我单独放在assets/下命名跟笔记文件对应不混在正文目录里。4.2 从零建库初始化与批量导入第一步建目录骨架。我用一条命令批量创建省得一个个点mkdir -p itil4-notes/{00-index,01-framework/{dimensions,value-chain,principles,svs},02-practices/{general,service,technical},03-cases/{incident,change,improvement},04-review/{cards,mistakes,exams},assets}第二步批量生成 34 个实践笔记的空壳文件。手工建 34 个文件是折磨而且容易编号错乱用脚本一次性生成cd itil4-notes/02-practices for i in $(seq -w 1 34); do echo --- ${i}-placeholder.md echo practice_id: ${i} ${i}-placeholder.md echo status: 草稿 ${i}-placeholder.md echo --- ${i}-placeholder.md done第三步把历史散装资料按“内容归类”而不是“来源归类”搬进来。这一步最容易偷懒——很多人直接把原来的文件夹原样拖进来结果仓库里出现五套互相冲突的结构。我的做法是先建一个_inbox/临时区所有旧资料先扔进去然后一条一条读读完一条写一条新笔记旧文件删掉。慢但干净。这个过程我花了三个周末总共处理了大约两百个碎片最后留下的有效内容不到原来体积的三分之一。提示搬家阶段千万别做“留着以后再说”的决定。凡是读完觉得“可能有用但说不清哪里有用”的直接删。仓库的价值在于密度不在于体积。4.3 用脚本自动生成索引这是整个仓库最有价值的一段代码。手工维护目录维护到第三周就会放弃交给脚本每次加完笔记跑一下目录永远是新的。import os import re from pathlib import Path ROOT Path(itil4-notes) def parse_meta(path): 读取文件头部的元数据区 meta {} try: text path.read_text(encodingutf-8) except UnicodeDecodeError: return meta m re.match(r^---\n(.*?)\n---, text, re.S) if not m: return meta for line in m.group(1).splitlines(): if : in line: k, v line.split(:, 1) meta[k.strip()] v.strip() return meta def build_toc(): lines [# 仓库目录, ] for sub in [01-framework, 02-practices, 03-cases]: lines.append(f## {sub}) base ROOT / sub if not base.exists(): continue for f in sorted(base.rglob(*.md)): meta parse_meta(f) title meta.get(title, f.stem) status meta.get(status, 未标注) rel f.relative_to(ROOT).as_posix() lines.append(f- [{title}]({rel}) — {status}) lines.append() (ROOT / 00-index / toc.md).write_text(\n.join(lines), encodingutf-8) def coverage_report(): 统计哪些实践还没有正式笔记 done, todo [], [] for f in sorted((ROOT / 02-practices).rglob(*.md)): meta parse_meta(f) if meta.get(status) in (已复核, 草稿) and placeholder not in f.stem: done.append(meta.get(title, f.stem)) else: todo.append(f.stem) print(f已完成 {len(done)} 个待补 {len(todo)} 个) print(待补清单, , .join(todo[:20])) if __name__ __main__: build_toc() coverage_report()跑完之后00-index/toc.md就是全仓库的导航。这个脚本我只写了不到六十行但它替代了我每天至少五次的翻找动作。coverage_report那个函数尤其好用考前一周跑一次一眼看出哪几个实践还是空白直接定当天的复习计划。4.4 版本管理与备份给自己留后悔药纯文本仓库的最大好处是能上版本控制。我每次完成一个主题的整理就提交一次提交信息写清楚改了什么。这样有两个好处一是改错了能回滚二是一段时间后能看见自己的学习轨迹。cd itil4-notes git add . git commit -m 补完事件管理与问题管理的对比笔记 git log --oneline -10备份策略我用了“三二一”的简化版本地一份、移动硬盘一份、异地一份。备份频率是每周一次用一条打包命令就行tar -czf backup-$(date %Y%m%d).tar.gz itil4-notes/这里有个容易忽略的点备份要验证能不能恢复。我第一次做备份时压缩包里漏了隐藏目录恢复的时候元数据全丢了。后来我加了个习惯每次备份完随机挑三个文件解压出来看看内容对不对。这个动作花不了一分钟但救过我一次。5. 用这个仓库备考的实操节奏5.1 三阶段复习法从铺开到收敛我把备考切成三段每段用仓库的不同区域。第一阶段铺面约两周目标是知道有哪些东西。这一阶段我只做一件事——给 34 个实践各写一页纸每页写清“这个实践解决什么问题、关键概念有哪些、跟哪几个实践关系最近”。写不出来就说明没读懂回去补。这一阶段结束时02-practices/下应该没有placeholder了。这一阶段不刷题刷了也白刷因为概念还没成网。第二阶段织网约一周目标是知道它们怎么连。这一阶段我泡在03-cases/里每天挑一个真实场景写下来然后强制自己用框架语言复述一遍。比如“某系统凌晨批量任务失败导致早班业务卡住”写完之后要能对应到这是一个事件走事件管理流程根因排查后如果发现是配置漂移那就升级为问题修复需要改配置那就是一个变更。这种“场景→框架”的翻译练习比背定义有用十倍。第三阶段收敛约三天只看04-review/。知识卡片过一遍错题本过一遍然后做模拟。这一阶段不碰新内容防止考前焦虑。5.2 知识卡片与错题回灌知识卡片我控制在两百字以内一张卡只讲一件事正面写问题背面写答案。举例正面变更控制的三个变更类型分别是什么背面标准变更预先授权、低风险、可重复、常规变更需评估授权、紧急变更需专门授权流程事后回溯。卡片的价值不在于“看”在于“翻”。我每天通勤路上翻二十张翻到能条件反射说出答案就抽出来放到“已掌握”堆剩下的继续翻。一周下来两百张卡里能留三十张来回翻就不错了。错题本我用的是“回灌”机制每道错题记三样东西——我的错答、正确答案、我错在哪一步。然后最关键的一步把这道题涉及的知识点反向更新到对应的实践笔记里并在笔记里加一行“易错点……”。这样错题就不只是一个孤立的记录它变成了笔记的一部分。下次复习笔记时易错点会自动被看到。5.3 模拟考试的节奏控制模拟我会严格计时但有意识地练三件事。第一是先扫一遍再动笔。四十道题先用两分钟从头到尾看一遍把明显会做的和需要想的分开能省下大量反复读题的时间。第二是关键词圈定法。ITIL 4 的题干普遍较长但决定答案的往往就一两个词。看到“根本原因”基本锁定问题管理看到“单一联系点”锁定服务台看到“预先授权”锁定标准变更。第三是不确定的题标记后置。第一遍只做有把握的标记不确定的最后统一处理。我实考时第一遍做完还剩十八分钟回头改了四道题其中两道是原本想太多改对的。6. 常见问题与排查技巧实录6.1 术语对不上中文资料互相打架怎么办这是最高频的问题。我的处理原则是以英文原词为锚中文译名只是标签。遇到两种译法先判断是不是同一个英文词如果是就在术语表里定一个“仓库统一译名”其他译法写进“常见异译”列如果不是同一个英文词那多半是概念本身不同必须分开建条目。举个典型例子“服务级别管理”和“服务级别协议”经常被混着说但前者是一个实践后者是前者产出的一个文档。这种混淆靠翻译是解决不了的只能靠回到英文去对齐。我在术语表里给这类词加了“易混”标记复习时专门盯。还有一种情况是翻译过度。有些资料把“Value Stream”译成“价值流”也有人译“价值链”但 ITIL 4 里的“服务价值链”Service Value Chain是专有名词不能跟“价值流”混用。这类专有名词我在术语表里加了“专有禁止意译”的备注见到就警惕。6.2 仓库膨胀文件越多越找不到仓库用满半年一定会膨胀。我遇到过两个具体症状一是检索变慢二是同一主题出现三个版本的笔记不知道信哪个。对治第一条我的做法是强制分层。知识本体最多三层目录超过三层就说明分类粒度太细了需要合并。场景案例按季度归档老的打包成压缩包只在需要时解压。_inbox/每周必须清空一次清不掉的就删。对治第二条我用status字段加了一条规则同一主题只允许一个已复核状态的文件。如果写了新版本旧版本立刻改成待更新或者直接删。这条规则执行起来有点痛因为删自己写的东西总有心理负担但留着两份互相矛盾的笔记危害比删掉大得多。6.3 问题速查表现象可能原因处理方法搜不到某个术语的笔记术语表没建条目或者笔记用了异译先搜英文原词仍搜不到就在术语表补一行索引文件内容过期新增笔记后没跑脚本每次改完统一跑一次索引生成笔记之间互相矛盾版本混杂旧笔记没清理查version字段保留新版旧版标待更新复习效率突然下降仓库里草稿太多噪音大只筛status: 已复核的内容复习备份恢复后元数据丢失打包时漏了隐藏目录或点文件备份后随机抽查三个文件的头部是否完整卡片翻了很多但记不住卡片太长一张塞了多个知识点拆成单点卡片正面只问一件事案例写完跟框架对不上场景理解有偏差或框架概念没吃透回到该实践的笔记重读用框架语言逐句复述场景补充两个我踩过的坑。一个是过度追求排版。我有一阵子花大量时间调表格对齐、加装饰线看起来很爽但真正学习的时间被挤压了。仓库是给自己用的能读就行排版够用就好。另一个是卡片只做不翻。我一口气做了两百多张卡结果考前只翻了四十张剩下的全是沉没成本。后来改成边做边翻、做一批翻一批记忆效果才上来。还有一个心得值得一提仓库要定期做减法。我每季度会花半小时把三个月没打开过的文件挑出来看一眼能删的删能合的合。这个动作听起来像浪费时间但每次做完仓库的检索速度和我的使用意愿都会明显回升。资料管理这件事收集是本能删减是本事。我个人在实际操作中的体会是这套仓库最值钱的部分不是那几百份笔记而是那份术语对照表和那几十条易错点。前者保证了所有内容能互相对上后者构成了考前最精准的复习清单。框架会更新版本会迭代但只要这两样东西在换一版资料也只是填空而已。