10.4 维系大型与长期运行的系统

概述与动机

大多数关于软件工程的论述，讲的都是如何构建新事物。但世界上大多数重要的软件都是古老的、庞大的，并且仍在运行之中：税务系统、福利支付、空中交通管制、核心银行系统、工业控制系统，以及日常生活的各种基础设施。这些系统通常会运行十年、二十年，甚至三十年，这远远超过了任何一位建设者的任职时间，往往也超过了创造它们的公司和编程语言的寿命。维系这样的系统，意味着要让它们在数十年间、跨越一代又一代员工的更替之后，依然保持可靠、安全、可被理解，并且能够变更。这是这个领域中最艰难、也最不光鲜的学科之一，而大型企业和政府在这方面承担着最沉重的负担。

为什么这一点对大型组织而言尤为重要？答案是义务的连续性。一家初创公司可以重写或放弃自己的软件，而一国政府却不能在重构系统的同时停止发放养老金。企业和政府机构拥有的那些系统，一旦出现故障，其后果会以生计、安全或公众信任来衡量。而且它们往往同时拥有许多这样的系统，由数十年间不断有人加入又离开的员工来维护。这里的核心威胁并不神秘：它们是理解系统的人在缓慢流失（巴士系数，即需要有多少人离开，系统的相关知识才会失传）、未被记录的知识不断堆积在少数几个人的脑海中、技术栈逐渐走向生命周期终止，以及当一个系统变得太过关键而不敢触碰、又因为理解得太少而无法安全变更时所出现的瘫痪状态。

本章讲的是”守护”：这是一种有意识的、不光鲜的工作，目的是帮助一个系统体面地活得比它的创造者更久。本章涵盖所有权的连续性与巴士系数的缓解、有计划的弃用与下线、知识转移、长达数十年的系统所面临的特殊挑战，以及在创新与维护公民和客户所依赖的稳定性之间不断进行的平衡。

核心原则

每一个关键系统都需要一个所有者，而且必须始终有人负责。 所有权是一项持续性的指派，而不是”记得是谁写的”这种记忆。
只存在于一个人脑海中的知识是一种风险，而不是一种资产。 要在这个人离开之前，把理解制度化。
“无聊”是一种优点。 对于长期运行的关键系统而言，稳定性和可预测性往往比新颖性更重要。
从一开始就规划好结局。 每一个系统终将被淘汰或替换；要为那一天进行设计和记录。
变更能力是安全的保障。 一个可怕到没人敢碰的系统，其实已经在走向失败；变更能力是一种生存特质。
连续性比个人的任期更长久。 设计团队、文档和流程时，要确保任何单个人的离开都不会演变成危机。
信任才是真正的产品。 对于面向公民和客户的系统而言，长期保持的可靠性与公平性才是使命所在。

建议

建立守护机制与所有权的连续性

为每一个重要系统指派明确的、实时有效的所有者。所有权应落实到团队层面，而不是个人层面，这样即便有人离开，所有权依然能够延续下去。维护一份服务目录，为每个系统记录谁拥有它、它的功能是什么、它依赖什么，以及它的关键程度如何。定期审查所有权，绝不能让任何一个系统变成无主状态。一个无人负责的关键系统，就是一场等待发生的紧急事故。当团队进行重组时，要有意识地转移所有权，进行正式的交接，而不是想当然地默认转移已经完成。对于最关键的长期运行系统，要确保所有权不仅包含运维职责，还包含理解和变更这个系统的能力，这样”守护”才不会退化成单纯的看护工作。

缓解巴士系数与关键人员风险

主动度量并降低知识的集中程度。如果只有一个人能够部署、调试或变更某个系统，那么这就是一个和任何硬件故障一样真实的单点故障。通过结对与轮岗、强制性的代码评审、共享值班安排，以及一条明确的规则（）任何关键任务都不能只有一个胜任的人（）来降低这种风险。开展交叉培训，确保每一项核心职能至少有两个人（最好是三个人）能够胜任。要把关键人员的离开，当作一个可以预见的事件，并持续为之做好准备，而不是一次需要被动承受的冲击。文档确实有帮助，但通过实际操作在团队中传播开来的实操知识，要比从未被演练过的文档更加持久可靠。

让知识转移制度化

捕获那些原本会随人离开而流失的知识。首先聚焦于那些难以重建的知识：为什么会做出某个决策、哪些替代方案被否决了以及原因何在、系统中那些危险的边角地带在哪里、系统其余部分悄悄依赖的关键”取巧手段”在哪里，以及系统在高压之下会如何表现。使用架构决策记录，不仅保存决策本身，也保存决策背后的推理过程。把操作手册和运维文档放在贴近系统的地方，并定期演练它们，确保其内容始终准确。构建能让新的守护者真正达到胜任水平的入职路径。把人员离职当作一次需要真正交接时间的知识转移事件来对待。要记住，隐性知识（）那种对系统的直觉和”手感”（）主要通过与掌握它的人一起动手实践来传递，因此要尽可能地让即将离开的守护者与新加入的守护者有一段重叠的时间。

管理弃用、下线与生命周期终止

有意识地规划系统的终结。当你决定淘汰或替换某个系统时，要把”下线”当作一个独立的项目来对待：识别出每一个使用者和依赖项，提供一条迁移路径和一个现实可行的时间表，清晰而反复地进行沟通，并在整个过渡期间为使用者提供支持。要避免这样一个陷阱：新旧系统永远并行运行下去，因为没有人愿意去做关闭旧系统这件苦差事。为完成停用工作明确指派问责人。在系统停止运行之后很长一段时间里，依然要保留数据、记录，以及回答有关这个已退役系统各种问题的能力，尤其是在存在法律保留规定的情况下。一次没做好的下线，会留下一堆”僵尸系统”（）无人维护，却依然有人依赖（）这是所有情况中最糟糕的一种。

让系统维系数十年之久

对于那些必须运行二十年甚至三十年的系统，要规划成能够比一切都活得更久：比最初的团队活得更久，比供应商活得更久，比所使用的语言生态和硬件都活得更久。优先选择开放标准和有文档记录的接口，而不是专有的黑盒子，这样未来的维护者才有机会接手。进行模块化设计，让各个部分能够逐一替换，而不必依赖一次要么全部成功、要么彻底失败、风险高到没人敢真正尝试的重写。让系统持续得到维护：以小步快走的方式保持系统与时俱进，它才能够可持续地运行下去；而一个因为”能用就行”而被冻结的系统，会随着其技术栈逐渐失去支持，在不知不觉中变得无法维护。同时也要保留操作这个系统所需要的技能：对于那些确实老旧的技术，要有意识地培养接班人，而不是寄希望于最后一位专家永远不会退休。

在创新与稳定、信任之间求得平衡

要区分你所拥有的系统资产中，哪些部分是”新颖性能创造价值”，哪些部分是”稳定性本身就是价值”。公民和客户每天都要依赖的核心系统，通常更看重可靠性、向后兼容性和审慎的变更，而不是令人兴奋的重写。把创新投入到边缘地带（新渠道、新功能、新接口），同时让持久的核心部分保持稳定、易于理解。核心当然也需要变更，但应当以小步、可逆、经过充分测试的增量方式进行，而不是靠孤注一掷的壮举。目标是打造一个既可靠又能够演进的系统：既不能冻结到腐化的地步，也不能变动得太过频繁以至于变得不可靠。

权衡取舍：优点与缺点

方案	优点	缺点
保留并维护旧系统	保留了组织知识；干扰小；可靠性已经得到验证	技术栈老化；技能稀缺；一旦缺乏维护，风险不断累积
一次性大重写	技术栈全新；甩掉积累的历史包袱	失败率极高；丢失来之不易的边缘情况知识
渐进式现代化改造	持续降低风险；系统保持运行	速度较慢；需要持续的资金投入和纪律性
以文档为主的知识转移	记录明确、可检索	若无人维护则会失效；无法涵盖隐性知识
以人为主的知识转移（结对/轮岗）	实操知识持久；团队更具韧性	消耗当前的生产力；需要刻意安排
冻结关键核心	短期内稳定性最高	技术栈会老化到无法维护；逐渐变得太可怕而不敢触碰

这里核心的权衡在于稳定性与演进能力之间，而两种简单化的解决方案都会失败。为了保护一个关键系统而将其冻结，你就等于保证了它最终会变得无法维护、也不再安全。为了实现现代化而对其进行彻底重写，你就会招致大规模重写向来以高失败率著称的风险，并且丢弃掉数十年间沉淀下来、如今已无人记得存在的边缘情况知识。持久可行的路径是持续的渐进式变更：以小步快走的方式让系统保持存活和运转，这样它就永远不会因老化而失去支持，也永远不需要一次令人生畏的跳跃。知识转移面临着类似的权衡：文档的便利性与亲身经历的持久性之间的权衡。答案是两者兼顾：以团队掌握的实操知识为骨干，以文档作为参考。

与团队讨论的问题

你们哪些关键系统目前没有明确指定的团队所有者？ 所有权是一项持续性的指派，而不是”记得是谁写的代码”这种记忆，一个无人负责的关键系统，就是一场等待发生、只有在出故障时才会被人注意到的紧急事故。梳理你们的服务目录（如果还没有，就建立一份），检查每个系统是否都记录了谁拥有它、它依赖什么，以及它的关键程度如何。拿出证据来说明：挑出三个重要系统，尝试说出对其负责的团队，以及上一次审查所有权是在什么时候。如果某个系统处于无主状态，或者某次重组悄悄把它遗漏了，就要有意识地指派所有权，进行真正的交接，而不是想当然地默认已经有人在管。要确保所有权包含理解和变更这个系统的能力，这样”守护”才不会退化成单纯的看护工作。
当你们替换一个系统时，究竟由谁来负责真正把旧系统关闭？ “永续并行运行”是一种常见且代价高昂的失败模式：新旧系统无限期地并行运行下去，因为没有人负责关闭旧系统，最终让你们同时维护着两套系统，却得不到任何一套系统所带来的安全感。把每一次下线都当作一个有明确问责人的、有管理的项目来对待，包含已梳理清楚的使用者列表、一条迁移路径，以及一个现实可行的时间表。拿出证据来说明：在你们目前的系统资产中，还有多少”临时”的并行运行，或者半退役的系统仍在消耗维护资源？为了满足法律保留规定，即便系统已经停止运行很久，也要保留数据和记录，但不要让”保留”变成永远无法真正完工的借口。一次没做好的下线，会留下一堆无人维护、却依然有人依赖的”僵尸系统”（）这是所有情况中最糟糕的一种。
你们那些长期运行系统所需要的技能，哪些会逐渐从劳动力市场上消失？你们的接班计划是什么？ 那些运行二十年甚至三十年的系统，其寿命会超过它们所依赖的语言生态、供应商，以及理解旧技术栈的那些人的职业生涯，而市场也不会可靠地为你们补充替代人才。要有意识地降低巴士系数，确保没有任何一项关键职能只有一个人能够胜任，并开展交叉培训，确保每一项核心任务至少有两个人、最好是三个人能够胜任。拿出证据来说明：对于每一个正在老化的关键系统，数一数有多少人能够安全地对其进行变更，最懂行的那些人距离退休还有多近。这个答案应当推动有意识地培养接班人，并让即将离开的守护者与新加入的守护者之间有一段真正的重叠时间，因为隐性知识（）也就是对系统的那种”手感”（）主要是通过与掌握它的人一起动手实践来传递的。文档是参考，而团队掌握的实操知识才是骨干。
你们上一次变更最关键的长期运行系统是在什么时候？现在还有人敢动它吗？ 一个一整年都没人碰过的系统，并不是稳定，而是正在滑向”太可怕而不敢触碰”的陷阱（）每一次变更都令人畏惧，于是技术栈就在不知不觉中失去了支持。对于大型组织而言，这一点之所以重要，是因为瘫痪会不断加剧：冻结的时间越长，知识流失得就越多，最终那次不可避免的变更也就变得越危险。拿出证据来说明：对于每一个关键系统，记录上一次有意识变更的日期、如今任何人愿意尝试的最小变更规模，以及一个常规的依赖项或安全补丁能否在本周内不靠英雄式的努力就顺利上线。这里存在真实的相反考量，因为变更本身也会带来风险，所以目标不是频繁折腾，而是保持小步、可逆、经过充分测试的稳定节奏。在企业和政府的系统资产中，一个冻结的核心可能会在某项公民服务之下潜伏长达十年之久，因此要把”我们从不改动它”视为一个危险信号，而不是一种安心的保证，并为持续维护提供资金，从而保留住变更的选择权。
你们的系统资产中，有多少正运行在已经或即将走到生命周期终点的技术之上？又是谁在追踪这个时限？ 老化的运行时环境、不再受支持的数据库，以及停止维护的框架，正是那种缓慢发作的失败模式，一旦某天安全补丁不再发布，它就会突然演变成一场危机。对于大型团队而言，危险之处在于没有人负责关注全局：各个团队各自修补出现问题的部分，却没有人维护一个关于哪些技术栈将在何时失去厂商支持的整体视图。拿出证据来说明：建立一份清单，列出每个关键系统的核心技术、它们公开的生命周期终止或停止支持日期，以及你们当前所运行版本与仍受支持版本之间的差距。这里的张力存在于持续升级的成本与推迟升级的风险之间，而推迟升级通常会占上风，直到它以灾难性的方式落败为止。在企业和政府场景中，采购和认证周期可能长达一年以上，一个看似遥远的生命周期终止日期，往往其实已经落在你们的提前期之内，因此接班和升级工作必须在时限耗尽之前就早早启动。
在你们的系统资产中，哪些地方是”稳定性本身就是价值”、而”新颖性反而是负债”？你们又如何保持这条界限的诚实？ 并不是所有系统都适合用同样的方式对待：公民和客户每天都要依赖的核心系统，通常更看重可靠性和审慎的变更，而边缘地带则更适合鼓励实验，把这两者混为一谈，要么会浪费金钱，要么会招致服务中断。对于大型组织而言，风险在于野心和职业激励，往往会把令人兴奋的重写恰恰推向那些本应保持”无聊”的持久核心地带。拿出证据来说明：绘制一份系统资产地图，标出哪里以可靠性为使命，哪里能靠新颖性创造价值，再加上最近一些跨越了这条界限（无论哪个方向）的变更，以及它们付出的代价。与之相对的考量是，即便是稳定的核心，也依然必须演进，因此”稳定”不能变成冻结的借口。在企业和政府场景中，要把这条界限与明确的关键程度分级绑定起来，并指定一位有权否决对公众无法承受其失败的系统进行冒险重写的负责人，这样这种判断就不会随着这个季度谁的声音最大而随意漂移。

行业视角

初创企业。 你们只有少数几名工程师，跑道也不长，维系风险因此集中在一两个人身上（）他们写出了你们承受不起失去的系统，比如计费或身份认证系统。几乎不要在流程上花钱，但现在就去做那些成本低、价值高的事情：让第二个人结对参与每一个关键系统，为那些出人意料的部分写一份一页纸的架构决策记录，并保留一份你们真正会用到的操作手册。要克制住仅仅因为某个东西”老了”就想重写它的冲动，因为以你们的规模，一次失败的核心系统重写足以终结整个公司。

小型企业。 你们没有专职的维护团队，预算也很紧张，因此应优先选择购买和托管，而不是构建任何需要你们自行维系的东西。优先选择那些能让你们随时离开的供应商和开放标准，并保留一份简单明了的记录，说明哪个外部系统承担哪项关键职能，出问题时该联系谁。如果你们确实拥有自研的代码，要确保至少有两个人（或者一位可信赖的承包商加一名员工）理解它，这样单个人的离职或支持合同的到期，就不会让你们陷入困境。

企业。 你们面临的挑战在于组合规模：众多长期运行的系统、众多团队，以及在数十年间不断轮换的员工。在服务目录中将团队层面的所有权标准化，在整个系统资产范围内度量巴士系数，并为持续的渐进式现代化改造提供资金，而不是把赌注押在一次性大重写上。对生命周期终止的时限进行集中治理，确保没有任何一个关键技术栈会在不知不觉中失去支持，并把每一次下线都当作一个经过审计的项目来运作，为完成停用工作明确指派问责人。

政府。 义务的连续性是绝对的：你们不能在重构系统的同时停止发放福利，也不能停止空中交通管制，而一旦出现故障，后果是公开的，也是有严重后果的。采购规则会推动你们走向开放标准、数据可携带性和有文档记录的接口，让未来的维护者和未来的供应商都有机会接手。为那些劳动力市场已不再供给的老旧技术，提供有计划的接班培训；保留已退役系统的记录，以满足法定保留要求；并把公民服务持续的可靠性，当作需要问责的使命本身，而不是一种额外开销。

案例

初创企业。 一家五人规模的初创公司已经拥有了一个它承受不起失去的系统：由一位创始人在公司成立第一个月写出的计费服务，如今承担着每一笔客户扣费。只有那位创始人理解这个系统，因此团队把这种巴士系数视为一种真实的风险，而不是一种值得夸耀的资本。他们让第二位工程师结对参与完整的一个计费周期，写下一份简短的架构决策记录，解释那段奇怪的重试逻辑为何存在，并在代码旁边保留一份他们在真实事故中确实会用到的操作手册。他们抵制住了仅仅因为这个系统”老旧、不够光鲜”就想重写它的冲动，而是以小步、可逆的方式对其加以改进，这样这个支撑公司存续的服务，就不会只被一个人的头脑所理解。

企业。 一家大型保险公司运行着一套数十年前首次编写、如今仍是其核心业务的保单管理系统。这家公司没有尝试冒险进行彻底重写，而是在定义良好的接口背后对系统进行了模块化改造，如今每次只替换一个组件，每次变更都很小、也可逆。每一项关键职能都至少有三个人能够胜任。值班工作由大家共同分担。架构决策记录保存了系统为何以现在这种方式运作的原因。一套精心设计的内部课程，能让新工程师在这套遗留技术栈上达到胜任水平，即将离开的专家也会与接任者有一段重叠时间，让隐性知识通过实际操作得以传递。

政府。 一家国家社会保障机构运营着已经运行超过三十年、且不能中断的福利支付系统。它在服务目录中记录了明确的团队所有权。它为持续维护提供资金，而不是将系统冻结起来。它有意识地培养接班人，掌握那些老旧技术，因为劳动力市场已不再供给这方面的人才。当它要淘汰一个过时的子系统时，会将下线当作一个有管理的项目来运作：梳理每一个使用者、提供迁移支持、保留记录以满足法律保留规定，并为真正完成停用工作明确指派问责人，从而不会留下任何僵尸系统。

商业论证：动机、投资回报率与总拥有成本

维系长期运行系统所带来的回报，来自于避免了主导其总拥有成本的那两种灾难性失败模式。第一种是突发危机：某个关键人员离职、某个不再受支持的组件遭到入侵，或者一个无主系统出现故障，却没有人理解它。第二种是失败的大型项目：一次仓促的彻底重写，最终超支、交付不足，或者彻底崩溃。这两种情况都代价高昂，而且都可以在很大程度上通过稳健的守护工作加以预防。避免一次重写失败、或避免一次公民关键服务的长时间中断，其所节省下来的成本，通常都会超过多年持续维护投入的总和。

这项投入的成本是持续性的、也是不光鲜的：为不产生任何新功能的维护工作提供资金，为会降低短期产出的交叉培训和文档编写时间买单，并投资于那些永远不会成为头条新闻的渐进式现代化改造。而不采取行动的成本则会被推迟，并且规模更大：随着技术栈老化，风险不断上升，关键人员的风险敞口不断膨胀，最终在紧急状态下被迫进行一次高风险、高成本的替换。在向领导层论证时，要把维护工作从”成本中心”重新定位为”针对组织承受不起失去的系统所做的风险管理”。要呈现的是贯穿数十年整个生命周期的总拥有成本（包括维系工作以及最终的停用），而不仅仅是构建阶段的成本。还要强调这一点：对于面向公民和客户的系统而言，持续的可靠性不是额外开销，它才是真正的产品（）也就是信任本身。

反模式与陷阱

英雄式维护者。 只有一个不可替代的人理解这个系统；这个人的离开是一场关乎生死存亡的事件。
冻结并遗忘。 宣布某个关键系统”已经完工”，停止维护，然后眼睁睁看着它的技术栈老化到无法维护的地步。
注定失败的重写。 把整个组织的命运押注在一次彻底的替换上，丢弃了沉淀下来的知识，而这类项目通常都会超支或失败。
无主系统。 没有当前所有者的关键软件，只有在出故障时才会被人注意到。
文档剧场。 大量的文档早已过时，从未被演练过，也没有人真正信任它们。
永续并行运行。 新旧系统无限期地并行运行下去，因为没有人为关闭旧系统负责。
隐性知识流失。 让专家在没有任何交接重叠的情况下离开，导致对系统的”手感”就此消散。
太可怕而不敢触碰。 一个被理解得如此之少的系统，以至于任何变更都令人畏惧，这就注定了它会走向腐化。

成熟度模型

第 1 级：启动级。 维系工作是临时性的、被动应对式的。系统依赖于个别的”英雄式人物”，所有权靠记忆维系，而不是明确指派，知识未经记录地存在于少数几个人的脑海之中。旧系统被冻结，直到出故障为止，老化的技术栈在无人察觉的情况下滑向生命周期终点，退役计划虽被宣布，却从未真正完成。

第 2 级：发展级。 基本的实践开始出现，但各团队之间参差不齐。最显眼的主要系统的所有权被记录了下来，一些操作手册和文档已经存在，少数关键职能有第二个胜任的人。维护工作有资金支持，但仍是被动应对式的，交叉培训在有人想起来的时候才会发生，整个组织也没有一套共同的做事方式。

第 3 级：标准化级。 守护实践在整个组织范围内被记录下来并强制执行。团队层面的所有权被记录在服务目录中，并能在重组之后延续下去。通过轮岗和交叉培训来缓解巴士系数，成为一项常设规则；架构决策记录和经过演练的操作手册成为标配；现代化改造按政策要求以渐进方式进行；每一次下线都作为一个有管理的项目来运作，并为完成停用工作明确指派问责人。

第 4 级：管理级。 维系工作会与基线进行对照，通过数据来度量和控制。你们会追踪每个关键系统的巴士系数、能够安全变更每个系统的人数、每一项核心技术相对其生命周期终止日期的年龄、系统资产中处于持续维护与推迟维护状态的比例，以及停滞不前的并行运行和未完成停用的数量。这些指标带有触发行动的阈值：一旦某个系统的巴士系数跌破下限，或跨过了停止支持的时限，就会获得资金进行补救，守护工作的健康状况也会与交付情况一并汇报给领导层。

第 5 级：协同级。 守护工作在整个组织范围内持续改进并加以整合。没有任何关键系统是单一的人为故障点，包括隐性知识在内的知识转移（通过重叠期实现）已成为常规做法，系统以小步、可逆的方式演进，因此没有任何系统会老化到失去支持。所有权、生命周期终止追踪、接班规划和下线规划，都被编织进组合管理和风险规划之中；系统资产会随着技术和义务的变化而重新平衡；跨越数十年的系统在得以维系的同时，也保住了依赖它们的人们的信任。

讨论议题

你们如何有意义地度量巴士系数？针对不同的关键程度级别，合适的目标值分别是多少？
在什么情况下，渐进式现代化改造确实不可行，以至于重写反而成了风险更小的选择？
你们如何为维护工作提供资金和奖励，使”守护”成为一条受人尊重的职业道路，而不是一条死胡同？
当最后一位专家即将退休、又无法安排任何重叠交接时，保留隐性知识的正确方式是什么？
你们应该保留回答已退役系统相关问题的能力多长时间？这笔成本由谁承担？
在你们的系统资产中，哪些地方是”稳定性即价值”、“新颖性即负债”？你们又如何让这种判断长期保持诚实？

关键要点

大多数重要的软件都是古老且长期运行的；在数十年间、跨越一代又一代员工地维系它，是一门第一等重要的学科。
每一个关键系统都需要实时有效的、团队层面的所有权；无主的关键系统是潜伏的紧急事故。
有意识地降低巴士系数（任何关键任务都不应只有一个胜任的人），并通过重叠期而不仅仅是文档来转移隐性知识。
让长期运行的系统持续地、渐进式地得到维护；将其冻结和押注于彻底重写，都是失败的做法。
把系统的终结规划成有问责制的、有管理的项目，并保留数据和记录以满足各项义务。
对于面向公民和客户的系统而言，持续的可靠性与公平性就是使命所在，而维护工作，就是针对那些你承受不起失去的东西所做的风险管理。

参考资料与延伸阅读

Michael Feathers, Working Effectively with Legacy Code
Titus Winters, Tom Manshreck, and Hyrum Wright, Software Engineering at Google
Frederick P. Brooks Jr., The Mythical Man-Month
Nat Pryce and Steve Freeman, Growing Object-Oriented Software, Guided by Tests
Sam Newman, Monolith to Microservices
Martin Fowler, Refactoring，以及关于绞杀者模式（Strangler Fig pattern）的相关著述
Betsy Beyer et al., Site Reliability Engineering 与 The Site Reliability Workbook（Google 出品）
Diomidis Spinellis, Code Reading: The Open Source Perspective
美国政府问责局（U.S. Government Accountability Office），关于联邦遗留 IT 系统现代化改造的相关报告