主题 10.3 — 知识管理与文档

用一句话概括： 在一项安全攸关的服务中，你的团队知道、却从未写下来的东西是一项临床风险，而不仅仅是一种不便——因此要把文档当作一等交付物，把知识连续性当作一项职责，而不是一种客气。

为什么这在卫生与照护中至关重要#

数字卫生团队规模小、专业化，常常由长期员工、承包商和供应商工程师拼凑而成。理解病理接口为什么在失败前重试三次、或电子病历中哪个标志抑制了一次重复过敏警报的人，常常是单一个体——而那个个体会离职、退休，或在集成于凌晨两点崩溃的那一周请病假。当知识随他们而去时，这个系统不仅变得更难维护；它变得更难安全运营。一位临床医生所依赖的一份未记录的变通做法可能悄悄消失，没有人知道它是承重的。

利害关系是这个行业特有的。一次被误解的配置可能产出一份错误患者的记录、一次错过的警报，或一次断裂的转诊——以患者成果、而不是停机工单来衡量的伤害。公共机构还承担着法定义务：健康记录必须保留明确的期限，关于照护和公共资金的决策必须在数年后可审计，在一位法医、一位监管者，或一份信息自由请求上门时可被找到。因此，良好的知识管理，一部分是临床安全，一部分是治理，一部分是对必须维持服务运行的下一个人的尊重。它与你如何运行实时运营（参见主题 3.8——服务管理与实时运营）以及你如何设计团队（参见主题 7.0——团队结构、角色与责任）密不可分。

核心概念#

知识管理作为一门纪律。 知识管理（Knowledge management）是一个机构创造、捕获、分享和重复使用它所知道东西的一套实践。它平衡三个组成部分——人和文化、流程和结构，以及技术——每当领导者把它当作一次工具购买、而不是一种习惯来对待时，它就会失败。"知识"的范围从一条临床路径在一家给定信托机构中实际如何运作，到一个特定集成引擎是如何配置的。

隐性知识与显性知识。 隐性知识（Tacit knowledge）是存在于人们头脑和手中的东西——判断力、直觉，以及那种难以写下来的、来之不易的"你必须知道这家信托机构对出院的编码方式不同"。显性知识（Explicit knowledge）是已经被阐明并编码进文档、图表和操作手册中的东西。维持一项服务安全的大多数知识都始于隐性；知识管理的工作是把足够多的它转化为显性形式，从而使服务不依赖于任何一个人的头脑。

SECI 知识转化模型。 SECI 模型（SECI model）（社会化、外化、组合、内化），来自野中郁次郎和竹内弘高，描述了知识如何在隐性和显性形式之间移动：通过并肩工作来共享（社会化）、写下隐性知识（外化）、把显性的碎片组合成更大的文档（组合），以及把已文档化的知识重新吸收回流畅的实践中（内化）。它很有用，因为它提醒你，仅靠文档是不够的——配对、跟班学习和社群与维基百科同等重要。

关键人物依赖和公交系数。 公交系数（Bus factor）是在一项服务因没有任何人理解它而停滞之前，必须失去的人数。公交系数为一是大多数小型数字团队的默认状态，也是人们健康所依赖的一项服务的严重运营风险。高员工流动率、大量使用承包商，以及单一供应商锁定，都会把这个数字往下推；有意识的文档记录、交叉培训和配对则会把它往上推。

文档作为一等交付物。 把文档当作产品，而不是副产品。一份服务手册描述了这项服务是什么、它如何表现；一份操作手册（Runbook）（或行动手册）给出启动、停止和恢复它的分步流程；一份架构决策记录（Architectural decision）（ADR）捕捉一个重大选择为什么被做出，从而使未来的维护者不会在不知道理由的情况下拆解它。一个单一真相来源（Single source of truth）意味着每一个事实恰好在一个地方被掌握，从而使人们不会追逐"当前架构"的相互矛盾副本。

Docs-as-code。 把文档保存在与工作相同的、有版本控制的代码库中——用纯文本或 Markdown 撰写，像代码一样被审查，自动发布——使文档保持在它所描述事物的附近，更有可能保持最新。当图表存在于代码旁边、在同一份拉取请求中变化时，它退化得更慢。

实践社群。 一个实践社群（Community of practice）（有时被称为公会）是一个分享一门手艺的跨团队群体——临床安全官、前端工程师、信息治理负责人——他们一起改进它。社群把隐性知识横向传播到整个机构中，否则垂直的团队边界会把它困住。

记录管理和保留。 记录管理（Records management）在信息的整个生命周期内治理它，包括它必须被保留多久、何时可以被销毁。在卫生领域，这部分是法定的：临床记录在 NHS 记录管理实践守则下携带明确的保留期限。这与团队文档不同，混淆两者会造成真正的错误——我们在下面回到这一点。

信息架构和可查找性。 信息架构（Information architecture）是一个信息空间的结构性设计，使人们能够找到他们所需要的东西。一个有一万个页面、没有结构的维基百科不是文档；它是一个垃圾填埋场。可查找性是存在的知识和被使用的知识之间的区别。

最佳实践#

1. 让文档成为完成的定义，而不是事后补充。 一项功能、集成，或配置变更，在它的操作手册条目、它的 ADR（如果做出了一项重大决策）和它的服务手册更新存在之前，不算"完成"。把这烤进你的工作方式中，从而使它在知识还新鲜时、由拥有它的人写下来。数月后从记忆中回溯性地补配一个系统的文档，正是不准确和危险缺口诞生的地方。

2. 保持单一真相来源，从中向外链接。 按领域决定，每一个事实的权威版本存在于哪里——架构、值班轮值表、数据流图——让其他一切都指向它，而不是复制它。重复的文档会漂移，在一个临床背景中，一份说"过敏检查已开启"而实际上已关闭的过时副本，比根本没有文档更糟糕。无情地删除或重定向你已经拥有的过时副本。

3. 采用 docs-as-code，把文档保持在工作旁边。 把操作手册、ADR 和服务手册与它们所描述的系统一起存储在版本控制中，在与代码变更相同的拉取请求中审查文档变更，自动发布。这使更新变得便宜、变更可审查、历史可审计——它还意味着改变系统的人被推动在同一个动作中改变文档。

4. 撰写一位压力重重的陌生人在凌晨三点能够遵循的操作手册。 一份操作手册应该假设读者是疲惫的、对系统不熟悉的、处于压力之下的——因为在一次重大事件期间，他们会是这样。使用编号的、字面的步骤，指明确切的屏幕和命令，说明每一步的预期结果，以及如果它失败该怎么做。通过让没有写它们的人在一次演练中执行一次恢复来测试它们。

5. 用架构决策记录捕捉"为什么"，而不仅仅是"什么"。 一份简短的 ADR——背景、决策、后果——保留了重大选择背后的推理，从而使未来的维护者不会在不理解驱动那个约束的原因的情况下逆转一项决策。在卫生领域，这一点极为重要：一项看起来奇怪的配置可能是因为一次临床安全危害分析或一项信息治理裁定而存在。记录这个原因，能够防止一次善意的"清理"重新引入一个已知的风险。

6. 有意识地在每一个关键系统上提高公交系数。 识别公交系数为一的系统，把它当作你登记册上的一项风险，配有一位具名负责人和一份计划。配对人员，轮换值班知识，运行"回教式教学"环节——专家一边记录文档一边让一位同事跟随，禁止任何单一个人成为唯一能部署或恢复一项安全攸关服务的人。这比在一次中断期间才发现这个缺口要便宜。

7. 运行改变实践、而不是指责人的事后事件审查。 在任何重大事件之后，运行一次无过错的事后事件审查（Postmortem documentation），产出有文档记录的、有归属的、有时限的行动——然后真正地关闭它们。被归档、从不被重新审视的经验教训是表演；这个流程的测试标准是同样形状的后续事件是否被阻止了。把发现直接反馈进操作手册和临床安全案例中（参见主题 3.8——服务管理与实时运营）。

8. 投资于信息架构和可查找性。 构建你的知识库，使一位新加入者能在一分钟内找到值班操作手册，积极地修剪——一个过时的页面是一项负债，不是一项资产。商定命名惯例、一个清晰的层级，以及每个领域的一位负责人，在重要的页面上标注一个"上次审查"日期，从而使读者能够判断新鲜度。搜索不能替代结构；它是结构的补充。

9. 培育实践社群以传播隐性知识。 为重要的手艺——临床安全、安全性、前端、数据工程——建立跨团队公会，赋予一项轻量的使命：分享你正在学习的东西，商定共同的模式，指导新人。这些论坛移动着任何文档都无法捕捉的隐性知识，减少了团队之间重复的错误（参见主题 7.5——人员与组织发展）。给它们在工作周内的时间，否则它们会枯萎。

10. 把团队文档与法定记录分开——两者都要管理。 明确说明什么是团队知识（操作手册、ADR、维基百科）与什么是受法律保留约束的记录（临床记录、照护决策、财务批准、信息治理决策）。对后者应用 NHS 记录管理实践守则的保留时间表，不要让随意的维基百科删除破坏一份你被法律要求保留的东西。同样，不要"为了安全"永远囤积一切——过度保留是它自身的治理和数据保护风险。

11. 让入职成为对你文档的一次测试。 把每一次入职（Onboarding）当作一次实时审计：如果一位胜任的新工程师或临床医生无法从你的书面材料加上一点配对中变得富有成效，你的文档就失败了，他们遇到的缺口就是你的待办事项。要求新加入者把他们遇到的第一件让他们困惑的事情修复，作为他们的第一份贡献。这把入职从一项单向成本，变成了知识连续性的一个持续改进循环。

与团队讨论的问题#

1. 如果理解我们最关键集成的唯一一个人明天离开，我们要多久才会暴露出来——我们具体会不知道什么？ 这把公交系数这一抽象想法，变成对你最重要系统的一次具体压力测试。梳理一个真实的例子——病理数据流、单点登录配置、共享照护记录的匹配逻辑——诚实地问，还有谁能在没有那个人的情况下操作、变更并恢复它。要揭示的张力是，最深的知识通常存在于你最忙、最受信任的个人身上，交付的压力使他们理性地永不停下来把它写下来。把真正隐性、难以编码的知识，与仅仅因为没有人抽出时间而从未被捕获的知识区分开来。一个好的、诚实的答案会大声地指明你的公交系数为一的系统，承认哪些缺口是真实的，产出一份有成本的计划——配对、文档冲刺、交叉培训——而不是一句含糊的安慰，说"这都在人们的头脑里，那没关系"。如果这场对话感觉舒适，你还不够具体。

2. 当我们把某件事写下来时，我们如何知道有人会找到它、信任它，并保持它是最新的——我们的文档已经在哪些地方对我们撒谎了？ 过时的文档不是中立的；在一个安全攸关的环境中，它主动地误导一位承受压力的操作者走向错误的行动。这场讨论应该正视拥有文档与拥有人们能够找到、信任并据以行动的文档之间的区别——这是一个信息架构、所有权和新鲜度的问题，不是数量问题。辩论你的知识库是否有一个真正的结构，还是变成了没有人导航的蔓延，以及文档是否活得足够接近工作（docs-as-code）以保持最新，还是在一个没有人更新的独立工具中漂移。问每个人他们上一次依赖一份内部文档、却发现它是错的是什么时候，那付出了什么代价。一个有力的答案会指明你知道已经过时的具体页面，分配负责人和审查日期，为最重要的事实商定一个单一真相来源——它愿意删除的比添加的更多。

3. 在我们上一次严重事件之后，我们工作方式中实际改变了什么——如果答案是"没多少"，我们为什么还继续运行审查？ 事后事件审查很常见；改变实践的审查很罕见，两者之间的差距正是同样的失败反复出现的地方。这检验的是你的经验教训流程是一个真正的反馈循环，还是一种产出一份文档、却没有变化的仪式。诚实地探讨文化条件：审查只有在无过错时才能揭示真相，如果这个流程惩罚人们，人们就会隐藏真正的原因，因此心理安全是一个前提条件，而不是一种客气（参见主题 8.1——变革管理）。看看你最近的几起事件，追踪每一项行动是否已完成、是否防止了复发。一个好的答案能够指出一项审查产出的一个具体变化——一份重写的操作手册、一个新的警报，一次设计修复——坦率地说明哪些行动被记录了、却悄悄被放弃了，配有一份闭合那个循环的计划。

4. 我们所持有的东西中，哪些是我们在法律上有义务保留的法定记录，哪些是我们为新鲜度而管理的工作笔记——我们确信我们没有在删除前者、或囤积后者吗？ 卫生与照护机构承担着保留义务，大多数数字团队凭本能、而不是规则来处理，两个方向的错误都是真实的：随意删除一个结果原来记录了一项照护决策的维基百科页面，或"为了安全"永远囤积一切，创造出一项数据保护和可查找性负债。这场讨论应该在受 NHS 记录管理实践守则约束的记录——临床记录、照护和资金决策、信息治理裁定——与你为新鲜度、而不是为法律保留而管理的团队知识（如操作手册和 ADR）之间划出一条清晰的界线。揭示尴尬的中间案例，例如一份记录了为什么一项临床安全风险被接受的 ADR，可能两者都是。这里的张力是工程师为整洁、当前的文档进行优化，而治理为站得住脚的保留进行优化，两种本能拉向相反的方向。一个诚实的答案能说出谁拥有保留时间表、界限画在哪里，以及如果一份具体记录在数年后被一位法医、一位监管者，或一份信息自由请求所要求，会发生什么。

5. 我们工作方式中，什么真正导致文档在知识还新鲜时被撰写——我们仍然在哪里依赖善意和良好意图？ 每个团队都同意文档很重要；能让它默认发生、而不是靠英雄主义发生的机制少得多。这个问题探讨把事情写下来是否被设计进工作流程——一个没有操作手册条目或 ADR 就阻止"完成"的完成定义、在与变更相同的拉取请求中被审查的文档、docs-as-code 使图表存在于它所描述事物的旁边——还是它取决于个人在交付压力说"发布"时选择停下来写作。诚实面对激励因素：数月后从记忆中回溯性地记录一个系统，正是危险的不准确诞生的地方，因此价值几乎完全在于当下捕捉它。看看你最近的几次变化，问文档是否由拥有那份知识的人、在当时撰写的，还是后来由某人重建的。一个有力的答案会指出已经就位的具体机制，指明流程仍然依赖记忆和意志力的缺口，配有闭合它们的计划。

6. 我们如何移动任何文档都永远无法捕捉的知识——判断力和"你必须知道这家信托机构对出院的编码方式不同"——每次一份承包商合同结束，这是否变得更难？ 维持一项服务安全的大部分东西是隐性的：直觉、模式识别，以及抵制被写下来的、来之不易的背景，SECI 模型提醒我们，文档本身永远无法完全外化它。这个问题问的是你多有意识地通过配对、跟班学习、回教式教学环节，和实践社群来传播那种知识，而不是假设维基百科能完成这项工作。在你依赖承包商和多家供应商的地方，这种张力最尖锐，因为他们最深的知识会在每次雇佣结束时走出大门，除非捕获是一项合同和文化期望，而不是最后一周才要求的一种恩惠。讨论你的手艺——临床安全、集成、数据工程——是否有受保护时间的活跃公会，还是跨团队学习只是偶然发生。一个诚实的答案会区分真正隐性、需要人对人传递的知识，与仅仅未被捕获的知识，能够指出真实的实践——一个配对轮值表、一份为即将离开承包商的知识连续性计划、一个活跃的实践社群——而不是一种抱负。

实践中：一个卫生与照护案例#

一个整合照护系统（ICS）运行一份共享照护记录，从三家急症信托机构、社区服务和一个社会照护个案管理系统中提取数据。这个集成主要由一位合同工程师"Dev"在两年前构建，他理解决定两份记录何时指向同一个人的匹配逻辑的每一个细微差别。Dev 的合同将在六周后结束。有一个维基百科，但它上一次有意义的更新是在建设期间。

交付负责人把这当作一项公交系数为一的风险来对待，把它列进项目群风险登记册，把自己的名字标注在旁边。在六周内，她资助了一项小型的"知识连续性"努力：Dev 每天早上与两位常任工程师配对，他们不是做一次告别式的信息倾倒，而是一边做一边把知识外化——为 Dev 熟记的失败模式撰写操作手册，撰写 ADR 解释匹配逻辑为什么容忍某些不匹配（结果发现一条看似草率的规则的存在，是为了避免原始临床安全案例中标记的一项已知患者安全危害）。这些文档进入与集成代码相同的 Git 代码库，在拉取请求中被审查，因此它们是有版本控制且最新的。

Dev 离开两个月后，一家急症信托机构的数据流开始在夜间产出重复的患者记录。从未见过 Dev 的值班工程师打开操作手册，遵循编号的步骤，在每个阶段确认预期结果，在一小时内恢复了正确的匹配。在无过错的事后事件审查中，团队找到了触发原因（一家信托机构编码 NHS 编号方式的一次上游变化），把它变成了一个监测警报和一份操作手册更新。本会是一场多天、高风险的仓促应对——以及一起真正的患者安全事件——变成了一次有文档记录的、一小时的恢复，因为隐性知识在持有它的人仍在场时就被变成了显性。

行业视角#

初创企业#

一家数字健康初创企业面临着最高的公交系数风险，也拥有最少的余地去应对它：一小撮工程师、深藏在每个人头脑中的知识，以及一种重视发布胜过写作的文化。务实的做法是嵌入工作流程中的轻量级、廉价的文档——代码库中作为简短 Markdown 文件的 ADR、第一次出问题时撰写的操作手册、从第一天起的 docs-as-code，从而使这个习惯在规模使其变得困难之前就已形成。创始人应该抵制把所有文档推迟到"产品市场契合之后"的诱惑，因为一次临床产品的中断，或一次因缺乏证据而失败的临床安全或 DTAC（数字技术评估标准）评估，可能是生死攸关的。目标不是一个精美的知识库，而是确保没有任何单一人员的离开能够拖垮公司。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院，或一家单点诊所——承担着与一家大型信托机构相同的临床安全和记录保留责任，却没有专职的 IT 或知识管理职能，几乎没有余力去建立一个。在这里，实践必须是彻底相称的：为少数几份重要的操作手册（如何恢复临床系统、共享照护记录失败时该联系谁）提供一个可查找的地方，一份简单的具名负责人安排，从而使关键知识不仅仅存在于诊所经理或一位长期服务的护士身上，以及一条在他们在法律上被要求保留的法定记录与他们不被要求保留的工作笔记之间的清晰界线。尖锐的风险是一个公交系数为一伪装成连续性：知道一切如何配置的人也在运行日常工作，一次退休或一次长期疾病可能让没有人能够操作一个安全攸关的系统。在系统由一个供应商供应和托管的地方，小型提供者仍然应该写下自己的本地配置和变通做法，因为供应商不会记录这个机构实际如何使用产品。

大型机构#

一家大型 NHS 信托机构、ICS，或健康科技供应商面临着相反的失败：文档太多，分散在 SharePoint、Confluence、网络驱动器和电子邮件中，没有单一真相来源，可查找性差。企业挑战是信息架构、所有权和修剪——决定每个事实在哪里被掌握、分配负责人、退役重复项，把知识管理与服务管理和变更控制连接起来。实践社群在这里赢得了它们的价值，把模式传播到本会各自痛苦地学到同一个教训的数十个团队中。要管理的风险是大量使用承包商和多家供应商，除非捕获是一项合同和文化期望，否则知识会在每份合同结束时走出大门。

政府#

一个国家或地方公共机构——NHS England、DHSC、UKHSA，或一个地方当局——在法定记录管理义务、信息自由义务，和公共审计审查之下运作，因此知识管理部分是一个法律和公共问责的问题。关于服务、资金和政策的决策必须被记录、保留明确的期限，数年后能为特别委员会、National Audit Office 审查，和公共调查所查找；近期重大调查的历史展示了糟糕的记录保存如何自身变成一起丑闻。政府必须坚守法定记录（依照时间表保留和处置）与工作知识（为新鲜度而管理）之间的界线，有纪律地应用 NHS 记录管理实践守则。透明度是关键字：工作假设应该是文档有一天可能被公众阅读。

常见失败模式#

• 英雄和公交系数为一。 庆祝"就是知道"系统的个人，却从不资助传播那种知识的工作。它感觉高效，直到他们不可用的那一天，一项安全攸关的服务没有任何人能够操作它。
• 一次性文档。 在建设期间创建、之后从未被触及的文档，漂向自信的虚假。过时的文档比没有更危险，因为人们会依据它们行动。
• 维基百科垃圾填埋场。 数千个页面，没有结构，没有负责人，没有审查日期——技术上存在、却无法被找到或信任的知识。数量被误认为价值。
• 远离工作的文档。 在编码时没有人打开的一个独立工具中的文档，保证了它与现实的偏离。Docs-as-code 是解药。
• 经验教训表演。 产出一份文档和一份从未被关闭的行动清单的事后事件审查，因此同样的事件复发。这个流程变成了仪式，而不是改进。
• 混淆记录与笔记。 要么删除了一份你在法律上被要求保留的东西，要么永远囤积一切，创造出一项数据保护和可查找性负债。两者都源于没有区分法定记录和团队文档。
• 审查室里的指责。 惩罚最接近失败的人的审查，教会每个人隐藏真正的原因，摧毁了这个流程所依赖的诚实。

成熟度模型#

检查清单#

• 每个关键系统都有一份服务手册、一份最新的操作手册，以及其重大决策的 ADR。
• 文档是你完成定义的一部分，在与变更相同的拉取请求中被审查。
• 每个领域都有一个具名的单一真相来源；已知的重复项被删除或重定向。
• 公交系数为一的系统在风险登记册上，有负责人和一份活跃的交叉培训计划。
• 操作手册已被没有写它们的人在一次演练或一起真实事件中测试。
• 事后事件审查是无过错的，产出被拥有、有时限的行动，并被关闭。
• 知识库有一个清晰的结构、页面负责人，和审查日期；过时的页面被修剪。
• 存在至少一个跨团队的活跃实践社群，为其保护了时间。
• 法定记录与团队文档相区分，依据正确的保留时间表被管理。
• 新加入者被要求把他们遇到的第一个文档缺口作为一次早期贡献来修复。

关键资料来源#

• NHS England / NHSX，《记录管理实践守则 2021（Records Management Code of Practice 2021）》——面向卫生与照护记录的法定保留时间表和生命周期义务。
• GOV.UK Service Manual（Government Digital Service）——关于为数字服务撰写和运行、包括文档记录和运营一项服务的指导。
• NHS Digital Service Standard ——构建和维护可持续、有良好文档记录数字服务的期望。
• Michael Nygard，《文档化架构决策（Documenting Architecture Decisions）》（2011）——架构决策记录（ADR）的起源模式。
• Google，《网站可靠性工程（Site Reliability Engineering）》——无过错事后事件审查（postmortem）、操作手册，以及降低运营关键人物风险。
• Etienne Wenger，《实践社群：学习、意义与身份（Communities of Practice: Learning, Meaning, and Identity）》（1998）——关于实践社群的基础性文本。
• Nonaka & Takeuchi，《知识创造型企业（The Knowledge-Creating Company）》（1995）——隐性到显性知识转化的 SECI 模型。
• Write the Docs 社群——关于 docs-as-code 和把文档当作产品对待的从业者指导。

参考文献#

1. Knowledge management — Wikipedia — https://en.wikipedia.org/wiki/Knowledge_management
2. Tacit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Tacit_knowledge
3. Explicit knowledge — Wikipedia — https://en.wikipedia.org/wiki/Explicit_knowledge
4. SECI model of knowledge dimensions — Wikipedia — https://en.wikipedia.org/wiki/SECI_model_of_knowledge_dimensions
5. Bus factor — Wikipedia — https://en.wikipedia.org/wiki/Bus_factor
6. Runbook — Wikipedia — https://en.wikipedia.org/wiki/Runbook
7. Architectural decision — Wikipedia — https://en.wikipedia.org/wiki/Architectural_decision
8. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
9. Community of practice — Wikipedia — https://en.wikipedia.org/wiki/Community_of_practice
10. Records management — Wikipedia — https://en.wikipedia.org/wiki/Records_management
11. Information architecture — Wikipedia — https://en.wikipedia.org/wiki/Information_architecture
12. Postmortem documentation — Wikipedia — https://en.wikipedia.org/wiki/Postmortem_documentation
13. Onboarding — Wikipedia — https://en.wikipedia.org/wiki/Onboarding
14. Records Management Code of Practice 2021 — NHS England / NHSX — https://www.nhsx.nhs.uk/information-governance/guidance/records-management-code/
15. Service manual — Government Digital Service (GOV.UK) — https://www.gov.uk/service-manual
16. Documenting Architecture Decisions — Michael Nygard — https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
17. Site Reliability Engineering — Google — https://sre.google/books/
18. Write the Docs — docs-as-code guidance — https://www.writethedocs.org/guide/docs-as-code/