主题 3.6 — DevOps 与工程卓越

一句话概括: 在临床系统中,有纪律的工程实践——自动化流水线、小而可逆的发布、基础设施即代码,以及可观测性——是让变更变得更安全、而不是更危险的关键,而把"我们如何构建与运行软件"当作一项安全、公平与公众信任关切来对待,正是一个成熟数字医疗机构的标志。

为什么这在医疗与照护领域很重要#

你如何进行软件工程与运营,本身就是一项临床安全管控。当一位社区护士看不到一次用药变更时,当一次电子转诊悄悄失败时,或当一次中断把临床医生锁在一份共享照护记录之外时,这种伤害不是抽象的不便——它是延迟的治疗、一次遗漏的过敏史、一个保障工作上的缺口。本主题中的工程实践决定了一项所需的修复是在十分钟内还是十周后抵达生产环境,以及一次糟糕的变更能否被干净利落地逆转,还是让临床医生连续几天变通着使用一个损坏的系统。

在受监管的领域,存在一个持久而危险的迷思:变更即风险,因此最安全的系统就是你最少触碰的系统。证据指向相反的方向。很少被变更的系统会累积未打补丁的漏洞、脆弱的手动部署步骤,以及未经记录的部落知识;当变更最终变得不可避免时——一个安全补丁、一个监管期限、一位供应商的撤出——它会以一次庞大的、危险的、理解不足的"大爆炸"形式到来。那些频繁部署小变更、配备自动化与快速回滚的机构,经历的失败更少,恢复速度也更快。在医疗与照护领域,这种差异是以患者安全来衡量的。

工程卓越也是一个公平与公众信任问题。不可观测的软件会掩盖这样一个事实:一项服务对使用老旧设备或身处连接性差地区的用户表现更差。一条不安全的软件供应链,会让保密患者信息面临风险(见主题 1.7——信息治理、数据保护与网络安全)。而由于这涉及公共资金与公共数据,这个领域日益期望代码按开放、可检查的标准构建——有时字面意义上是公开的。因此,你的工作方式不是一件私人的工程事务;它要对患者、临床医生与公众负责。

核心概念#

DevOps。 DevOps 是一种文化与一套实践,打破了构建软件的开发人员与运行软件的运营人员之间传统的隔墙。同一批人不再把代码"扔过墙"给一个独立的团队,而是从设计到线上运营共同拥有一项服务,并由自动化与快速反馈来支撑。它主要是一种工作方式——共同的责任、无咎的学习、小批量——由工具赋能,而不是一个你购买的工具。

持续集成与持续交付(CI/CD)。 持续集成(CI)意味着每一位开发人员频繁地把小变更合并到一个共享的主分支,每一次合并都触发一次自动化的构建与测试运行,让问题在几分钟内浮出水面。持续交付(CD)进一步扩展了这一点,使软件始终处于可发布状态,可以通过一条自动化的、可重复的流水线部署到生产环境。持续部署更进一步,自动发布每一个通过流水线的变更。测试是流水线各个关口的实质内容——在主题 3.7——测试与质量保证中有深入涵盖。

基于主干的开发与小而可逆的发布。 基于主干的开发让每个人都在版本控制中紧密围绕单一主线工作,一天集成多次,而不是维护长期存活、逐渐漂移、痛苦合并的分支。与之配对的纪律,是发布小的、频繁的、可独立回滚的变更。一次小变更容易审查、容易测试,而且——在临床系统中至关重要——如果出了问题,容易干净利落地回滚。

基础设施即代码(IaC)。 与其手动配置服务器,不如在受版本控制的、机器可读的文件中定义基础设施。这个环境变得可复现、可审查、可审计:你能够完全相同地重建它,看到谁改变了什么、为什么,并证明测试环境与生产环境是一致的。这是可靠环境的基础(见主题 4.0——技术架构、云与遗留系统)。

平台工程与开发者体验。 平台工程把交付团队所依赖的内部工具、流水线与环境,当作一个产品来对待,团队则是它的用户。一个构建良好的内部平台,能给团队一条"铺好的路"——安全的默认设置、预先批准的模式、一键部署——这样他们就能快速且安全地行动,而不必每次都重新发明合规性。良好的开发者体验不是一种放纵;它是让安全的路径成为容易的路径的方式。

DORA 指标。 DevOps 研究与评估(DORA)确定了区分高绩效团队的四项度量:部署频率(你多久发布一次)、变更前置时间(从提交到生产环境要多久)、变更失败率(多大比例的变更导致问题),以及服务恢复时间(你恢复得有多快)。它们共同揭示出速度与稳定性是同步提升的——最常部署的团队,也是失败最少、恢复最快的团队。

"谁构建,谁运行"、SRE 与可观测性。 由亚马逊推广开来,"谁构建,谁运行"意味着编写一项服务的团队也运营它、携带寻呼机,并感受到它的失败——闭合工程选择与运营现实之间的反馈回路(见主题 3.8——服务管理与线上运营)。站点可靠性工程(SRE)是一种具体的实现方式,把工程应用于运营,拥有明确的可靠性目标与错误预算。可观测性——从一个系统的输出(指标、日志、追踪)理解其内部状态的能力——是让你能够在患者与临床医生之前发现并诊断问题的关键。

安全的软件供应链。 现代软件由许多第三方组件与依赖项组装而成。一次供应链攻击利用一个受信任的组件来危及依赖它的一切。管理依赖项、扫描已知漏洞,并维护一份软件物料清单,是核心的工程卫生习惯,而不是可选的安全附加项。

公开编码与开源软件。 英国政府政策——体现在 GDS 服务标准与 NHS 服务标准中——要求团队默认把新的源代码开放,并使用开放标准。对于由公共资金支持的医疗软件而言,只要严格把患者数据与真正的机密信息排除在公开代码库之外,这能提升审视力度、复用性与信任。

最佳实践#

1. 在构建服务之前先构建 CI/CD 流水线。 从第一周起就建立自动化的构建、测试与部署,让每一次变更都流经同一条可重复、可审计的生产路径。流水线正是你的临床安全、安全性与无障碍性关口以自动化检查的形式存在的地方,给你一份有文档记录的、防篡改的记录,准确说明部署了什么、何时部署的。在一个受监管的系统中,这条审计轨迹不是开销——它是你临床安全论证的证据(见主题 1.6——临床安全与风险管理)。

2. 部署小的、频繁的、可逆的变更。 优先选择许多小发布,而不是偶尔的大发布,并设计每一次变更,使其能够被快速回滚或禁用。一次失败的微小变更容易理解与逆转;一次失败的季度性巨型发布,则是一起有一百个嫌疑对象的临床事故。诸如功能开关、金丝雀发布与蓝绿部署之类的技术,让你能够逐步暴露变更、并立即将其撤回——把部署从一个令人畏惧的事件,变成一个例行的、低戏剧性的行为。

3. 让快速、干净的回滚成为一项头等安全管控。 像演练消防演习那样演练回滚,并衡量它实际需要多长时间。在一个临床系统中,最有价值的单一运营能力,就是当一次变更造成伤害时,能够在几分钟内回到一个已知良好状态的能力。一个从未被测试过的回滚只是一种期望,而不是一项管控;证明它有效,并持续证明它。

4. 把基础设施与配置当作代码来对待。 以声明式的方式定义环境、网络与配置,置于版本控制之下,并自动配置它们。这给了你可复现的环境、经过同行评审的变更,以及在一次故障或灾难之后重建的能力(见主题 3.9——业务连续性与灾难恢复)。手动、精心调校的"雪花"服务器是不可重复的、未经记录的,通常是"在测试中能用、在生产中不行"的原因。

5. 用 DORA 指标来进行诚实的对话,而不是给人排名。 把部署频率、前置时间、变更失败率与恢复时间当作一个系统层面的健康信号来追踪,并观察它们一起朝着更快、更安全的方向移动。要抵制把它们变成个人或团队排行榜的冲动——DORA 自己的作者也警告不要这样做,因为它会驱使人们操纵数字并隐藏风险。正确的用法是诊断性的:上升的变更失败率,正在告诉你一些关于测试覆盖率或批量大小的东西,而董事会应当想听到这些。

6. 采纳"谁构建,谁运行",并以可观测性作为支撑。 让交付团队对自己的生产环境服务拥有真正的所有权,包括待命责任,这样做出设计选择的人就要承受其运营后果。用可观测性来支撑这一点——指标、结构化日志与追踪,加上与用户影响挂钩的、有意义的告警——这样团队能在临床医生报告问题之前就发现问题。这闭合了让工程选择随时间变得更好的反馈回路,并与服务管理(主题 3.8)直接相关。

7. 持续地保护软件供应链的安全。 维护一份依赖项清单,自动扫描已知漏洞,固定并验证版本,并保留一份软件物料清单,这样你就能在下一次广为人知的漏洞曝光后的几小时内回答"我们受影响了吗?"限制谁、什么能推送到生产环境,并严格保护机密信息与凭证(见主题 4.2——身份与访问管理)。在医疗与照护领域,一个被攻破的依赖项就是通往保密患者数据的路径,因此供应链卫生是患者安全与信息治理工作。

8. 设定并强制执行工程标准,刻意地管理技术债。 商定编码标准、自动化代码检查、代码审查与一份清晰的"完成定义",让质量被构建进去、而不是事后才被检查出来。明确地追踪技术债,并把偿还它当作有计划的工作,因为在一个临床系统中,未被管理的债务会悄悄提高每一次未来变更的成本与风险。标准让代码对下一位工程师、以及可能需要阅读它的审计人员、安全官与开源审查人员而言都是可读的。

9. 在能够安全公开的地方,公开地编码。 遵循 GDS 与 NHS 的期望,默认把新的源代码开放,并复用开放标准,通过有纪律的机密信息管理,严格把患者数据与机密信息排除在公开代码库之外。开放的代码会招来提升质量与安全性的审视,使一个资金紧张的系统能够实现复用,并建立起公众对花费公共资金的软件正在做它所声称的事情的信任。在代码真正无法开放的地方(例如某些安全敏感组件),记录理由,而不是出于习惯默认关闭。

与团队讨论的问题#

1. 我们是否真的相信更频繁地变更我们的临床系统会让它们更安全——我们的行为是否与这种信念相符? 这个问题迫使团队直面证据与直觉之间的差距。DORA 的研究清楚地表明,频繁部署小变更的团队失败率更低、恢复得更快,然而许多医疗机构依然以安全的名义,把变更批量积攒成罕见的、关卡重重的发布,无意中让每一次发布都变得更大、更危险。讨论你的变更咨询流程真正降低风险的地方,与它仅仅增加延迟、把团队推向大爆炸式发布的地方。诚实地审视你最近的几次事故:它们是由频繁的小变更引起的,还是由罕见的大变更与未打补丁的疏忽引起的?考虑你的回滚能力是否真实且经过演练,因为频繁变更的论证完全建立在能够快速逆转它的基础之上。一个好的答案不是意识形态化的;它会说出让你能够增加变更频率、同时满足临床安全与保证义务的具体管控措施——自动化测试、金丝雀发布、经过测试的回滚。

2. 谁在凌晨两点运行我们生产环境中的服务?这告诉了我们关于自己工程选择的什么? "谁构建,谁运行"在原则上容易认同,实践起来却很难。这个问题揭示出做出架构与交付决策的人,是否真的感受到了运营后果,还是这种痛苦被转移给了一个无法修复根本原因的独立运营或服务台团队。探索你的可观测性状态:当一份共享照护记录变慢时,你是从仪表盘与告警中得知的,还是从一位愤怒的临床医生那里得知的?也要讨论人的成本——待命必须是人性化的、有资金支持的、共享的,否则它会变成一个倦怠与人员流失问题,而在一个受人力约束的 NHS 中,这是一项严重的风险(见主题 7.2——劳动力规划)。在完整的团队所有权,与一些较小机构和供应商确实需要一个共享平台或托管服务才能可靠地运行的现实之间,存在真实的取舍。一个有力的答案会把运营责任与设计联系起来:它指出构建与运行之间的反馈回路在哪里断裂,以及你会改变什么,让工程选择能够被线上运营的现实所指导。

3. 我们有多少代码与工程实践能够经受住被公开的考验?这个答案揭示了什么? 政府与 NHS 政策要求团队默认公开编码,即使在完全开放尚不可能的地方,这个问题也能用这个透镜作为一种诊断。如果发布你的代码库这个前景引发焦虑,追问确切的原因:是硬编码的机密信息、嵌入的患者数据、缺失的测试、未经记录的决策,还是仅仅是不熟悉?这些每一个都是真实的工程质量或信息治理问题,而封闭只是掩盖了它、而不是解决了它。要权衡真实的约束——一些安全敏感代码应当保持封闭,把机密信息管理做对是一个前提条件——与审视、在一个资金紧张的系统中实现复用,以及公众对医疗软件支出如何被使用的信任之间的收益。考虑外部的眼睛在攻击者之前发现一个缺陷的声誉与安全价值。一个好的、诚实的答案会区分因为站得住脚、有文档记录的理由而封闭的代码,与出于习惯或尴尬而封闭的代码,并无论哪种情况都承诺修复底层的质量与卫生问题。

4. 如果明天早上一个常见依赖项中广为人知的漏洞被公布,我们要花多久才能回答"我们受影响了吗?在哪里?" 这个问题用一种像 Log4j 那样把一个抽象风险变成一场当日紧急事件的、影响整个行业的事件,来检验供应链卫生是一项真实的能力,还是一种愿景。诚实的答案取决于你是否维护着一份准确的依赖项清单与一份软件物料清单,还是你要花几天时间在代码库中反复搜索、并询问可能自己也不知道答案的供应商。探索你的软件有多大比例是由第三方与开源组件组装而成的,以及你实际上用自动化扫描监测了这个界面的多大部分,而不是偶尔的人工检查。也要讨论第三方与供应商的维度,因为在医疗与照护领域,大部分资产是买来的、而不是自己构建的,一个供应商产品中被攻破的依赖项,是通往你无法直接掌控的保密患者数据的路径(见主题 1.7——信息治理、数据保护与网络安全)。考虑你的流水线与生产推送权限是否足够严格,让一个被投毒的组件无法悄悄发货。一个有力的答案会说出一个以小时计的、现实的回答时间,指出让它成为可能的具体工具与清单,并坦率承认资产中哪些部分——尤其是供应商提供的部分——目前可见性薄弱。

5. 我们的工程指标是在告诉我们真相,还是已经悄悄变成了一个人们向上管理的绩效目标? DORA 指标只有作为一个诚实的系统层面信号才有用,这个问题探究你的指标是否经受住了组织激励的考验。古德哈特定律是不留情面的:一旦部署频率或变更失败率变成了一个团队被据以评判的数字,人们就会去优化这个数字、而不是底层的现实——拆分部署以虚增频率,或悄悄地重新分类事故,使其不计入失败。讨论谁看到这些指标、为什么,以及它们是被诊断性地用来推动对测试覆盖率或批量大小的投资,还是被当作一个驱使操纵与隐藏风险的排行榜。也要考虑相反的情况:那些什么都不衡量、依靠轶事的团队,导致失败率上升直到它变成一起临床事故之前都是不可见的。董事会对保证的合理需求,与最有用的指标恰恰是团队感觉可以安全地诚实报告的指标这一事实之间,存在真实的张力。一个好的答案会描述衡量是如何被构建与治理的,使其能够及早揭示令人不安的真相,而不是奖励人们隐藏它们。

6. 我们上一次刻意偿还技术债是什么时候?我们如何决定在一个临床系统中"足够好"的工程意味着什么? 一个临床系统中的技术债不是一个整洁与否的问题;它悄悄提高了每一次未来变更的成本与风险,于是一个本应花一天的修复要花两周,还会触及没有人敢重构的代码。这个问题迫使团队面对债务是被当作可见的、有计划的工作来管理,还是仅仅在积累、直到某件事出问题为止,以及工程标准——代码审查、代码检查、一份清晰的完成定义——是否真正被强制执行,还是在交付压力下被放弃。探索现在交付一项服务所需功能、与维护日后保持系统能够安全变更所需的内部质量之间真实的取舍,因为在医疗与照护领域,两者都是合理的,权衡是一种判断,而不是一句口号。讨论标准如何让代码不仅对下一位工程师、也对可能需要阅读它的审计人员、临床安全官与开源审查人员而言变得可读。考虑你是否甚至能看到自己的债务:它是被命名并被追踪的,还是关于哪些模块令人生畏的一种部落知识?一个诚实的答案会指出真正发生过的、有资金支持的具体整改工作,以及一个受监管系统所要求的、共享的、站得住脚的质量标准定义。

实践中:一个医疗与照护案例#

一个整合照护系统(ICS)运行着一项共享的"单一访问点"服务,把紧急社区照护转诊路由到正确的团队。在最初的两年里,这项服务大约每季度手动部署一次:一位开发人员在某个周五深夜按照一个维基页面上的手动步骤操作,每一次发布都是一场紧张的、全员上阵的活动。当一个转诊路由错误浮现——偶尔把复杂需求的转诊发送给错误的团队——这个修复在队列中等待了六周,等待下一个发布窗口,临床医生则用手动变通方案来管理这个风险。

新的工程负责人把这重新界定为一个临床安全问题,而不仅仅是一个效率问题。团队引入了一条 CI/CD 流水线:每一次变更都很小,经过同行评审,并被自动构建与测试,无障碍性与安全检查以及一个临床安全签核步骤被编码为流水线关口,产生一份可审计的记录,供危害日志使用。基础设施被迁移到代码,这样测试与生产环境终于一致了。部署从每季度一次变成了每周多次,首先作为金丝雀版本发布给单一地区,并配有经过测试的回滚机制,能在五分钟内返回到最后一个已知良好状态。

六个月后,DORA 指标用平实的语言向董事会讲述了这个故事:一个修复的前置时间从六周降到了不到一天,部署频率提高了十倍,变更失败率却下降了,因为变更现在很小且可观测。当一个微妙的路由错误再次出现时,可观测性仪表盘在几分钟内就标记出了这个异常,团队在任何转诊被错误路由之前就完成了回滚,第二天早上就发布了修复,并记录了一次无咎的事后事故审查。团队还根据 NHS 服务标准,把这个非敏感的路由规则引擎作为开源发布,一个邻近的 ICS 复用了它。更频繁地变更这个系统,让它变得明显更安全了。

行业视角#

初创企业#

一家数字医疗初创企业可以从第一天起就采用现代工程实践,不需要与一个遗留运营团队协商——基于主干的开发、CI/CD 与基础设施即代码,在一个小型的、白手起家的团队中基本上是免费的默认选项,这是一项真正的优势。风险在于"快速行动"悄悄放弃了医疗领域所要求的那些纪律:当还没有监管机构在关注时,自动化测试、经过测试的回滚、机密信息管理与依赖项扫描,感觉像是摩擦。创始人必须认识到,无论公司规模如何,临床安全与供应链义务都会依附而来,一次泄露的患者数据集或一个未被管理的依赖项就能终结这家公司。务实的路径是依靠托管云平台与一条小型的、有明确主张的"铺好的路",这样一个小团队无需构建一个它尚且负担不起的平台团队,就能获得默认的安全性。

小型企业#

一家成熟的小型提供者或供应商——一家全科诊所、一家社区药房、一家养老院、一家单一场所的诊所,或一家已过预收入阶段的小型健康科技供应商——通常有真实的患者与真实的运营,却没有专门的工程或 IT 职能来运行流水线、可观测性或待命。对大多数这样的机构而言,工程卓越的现实形式是买得好、而不是自己构建:选择你能够检查其自身 DevOps 纪律的供应商与托管平台,把自动更新、经过测试的备份与依赖项打补丁当作合同期望、而不是期望。在一个小型供应商确实自己编写软件的地方,一个托管云平台上单一配置良好的 CI/CD 流水线,配有自动化依赖项扫描,机密信息不进入代码库,能以一个精简团队可持续的成本,交付大部分的安全效益。陷阱在于假设规模小就能降低临床安全、安全性与信息治理的门槛——事实并非如此,一个未打补丁的依赖项,或一次手动部署的变更出错,对一家两名临床医生的诊所造成的伤害,与对一个国家机构造成的伤害同样确凿。现实的目标,是从好的平台与好的供应商那里继承默认的安全性,把诊所有限的注意力花在验证这些默认设置确实被打开上。

大型企业#

一家大型 NHS 信托机构或大型健康科技供应商拥有恰当地进行平台工程、可观测性,以及"谁构建,谁运行"的资源,却被遗留系统、孤岛式的开发与运营团队,以及为一个更慢的时代而构建的变更咨询流程所拖累。典型的失败,是一个笨重的变更委员会,在试图控制风险的过程中,强制推行大批量发布,而这比它所担心的频繁小变更更危险。机会在于投资于一个内部开发者平台,把合规、安全与临床安全关口烘焙进一条铺好的路,这样几十个团队就能继承良好实践,而不是各自去协商它。规模在这里是一把双刃剑:一次糟糕部署的波及范围是巨大的,而这正是为什么自动化、金丝雀发布与经过测试的回滚是必不可少的、而不是可选的。

政府机构#

一个国家机构,如 NHS England 或一个权力下放的卫生部门,设定了其他人所遵循的标准——NHS 与 GDS 服务标准、支出控制、公开编码的期望——并对议会与公众负责软件如何被构建与运行。它的工程选择波及整个系统:一个运行良好的国家平台、已发布的开源组件,以及清晰的供应链指导,提高了每一家信托机构与供应商的底线。这里的约束是真实的——多年期资金、采购规则,以及国家数据的规模与敏感性,都意味着部署节奏比在一家初创企业中更为审慎。政府的视角必须在示范性的透明度与复用,与国家级关键系统的安全性之间取得平衡,刻意决定什么被开放、什么被保护,并无论哪种情况都记录理由。

常见失败模式#

• "变更即风险"的瘫痪。 为了感觉安全而很少部署,产生了庞大的、危险的、理解不足的发布,以及未打补丁的疏忽。解药:小的、频繁的、可逆的变更,配有经过测试的回滚。
• 开发与运营之间的隔墙。 开发人员把代码"扔过墙"给一个无法修复根本原因的独立运营团队;没有人拥有整个循环。解药:共享所有权与"谁构建,谁运行",并得到人性化的支持。
• 手动的、雪花式的部署。 发布依赖于一个人与一个维基页面;环境逐渐漂移,"在测试中能用、在生产中出问题"成了家常便饭。解药:CI/CD 加基础设施即代码。
• 指标当作大棒。 DORA 数字被用来给团队排名,驱使操纵与隐藏风险。解药:按照 DORA 自己的指导,把它们当作系统层面的诊断来使用。
• 告警盲目的运营。 没有可观测性,患者与临床医生率先发现失败。解药:指标、日志、追踪,以及与用户影响挂钩的告警。
• 被忽视的供应链。 未打补丁的依赖项与未经扫描的组件成为破绽所在。解药:持续扫描、一份软件物料清单,以及受保护的流水线。
• 意外的暴露。 公开编码做得不严谨,泄露了机密信息或患者数据。解药:严格的机密信息管理与发布前扫描,而不是退回到默认封闭。

成熟度模型#

检查清单#

• 一条 CI/CD 流水线通过一条可审计的路径构建、测试并部署每一次变更,并编码了安全/安保/无障碍性关口。
• 变更是小的、频繁的,并可独立回滚(功能开关、金丝雀或蓝绿发布)。
• 回滚到一个已知良好状态定期被测试,并在一段有文档记录的短时间内完成。
• 基础设施与配置被定义为受版本控制的代码;测试与生产环境一致。
• 四项 DORA 指标作为一个系统层面的信号被追踪,而不是用来给个人或团队排名。
• 交付团队在生产环境中拥有自己的服务,配有人性化、有资金支持的待命机制,以及有意义的可观测性(指标、日志、追踪、告警)。
• 依赖项被清点并自动扫描;存在一份软件物料清单,机密信息受到保护。
• 工程标准、代码审查与完成定义已被商定;技术债被追踪并作为有计划的工作偿还。
• 新的源代码在安全之处默认开放,并有严格的检查确保没有患者数据或机密信息被暴露。
• 工程实践被记录在案,以便一位新工程师、审计人员或安全官能够理解正在运行什么、为什么(见主题 10.3)。

关键来源#

• Nicole Forsgren、Jez Humble 与 Gene Kim,《加速:精益软件与开发及 DevOps 的科学》——DORA 研究与四项关键指标。
• DORA(DevOps 研究与评估)——年度 DevOps 状态报告与能力目录——dora.dev。
• Jez Humble 与 David Farley,《持续交付》——部署流水线与发布自动化。
• Betsy Beyer 等(编),《站点可靠性工程》——Google 关于运行生产系统的 SRE 著作。
• NHS England ——NHS 服务标准与 NHS 数字服务手册(包括公开编码与开放标准)。
• GOV.UK 服务手册 / 政府服务标准(GDS)——"让新源代码开放"、持续交付,以及运营一项服务。
• 国家网络安全中心(NCSC)——关于安全软件开发与供应链安全的指导。
• NHS England ——临床风险管理标准 DCB0129 与 DCB0160(工程变更作为临床安全论证的一部分)。

参考文献#

1. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
2. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
3. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
4. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
5. Version control — Wikipedia — https://en.wikipedia.org/wiki/Version_control
6. Infrastructure as code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
7. Platform engineering — Wikipedia — https://en.wikipedia.org/wiki/Platform_engineering
8. DevOps Research and Assessment (DORA) — Wikipedia — https://en.wikipedia.org/wiki/DevOps_Research_and_Assessment
9. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Supply chain attack — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_attack
12. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
13. Accelerate: The Science of Lean Software and DevOps — Nicole Forsgren, Jez Humble & Gene Kim (IT Revolution) — https://itrevolution.com/product/accelerate/
14. DORA — DevOps Research and Assessment — Google Cloud / DORA — https://dora.dev/
15. Continuous Delivery — Jez Humble & David Farley — https://continuousdelivery.com/
16. Site Reliability Engineering — Google (O'Reilly) — https://sre.google/books/
17. NHS Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard-points
18. Making source code open and reusable — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable
19. Secure software development and supply chain security — National Cyber Security Centre (NCSC) — https://www.ncsc.gov.uk/collection/developers-collection
20. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety