主题 3.8 — 服务管理与线上运营

在医疗与照护领域,一项服务生命中的大部分时间、成本与临床风险都存在于上线之后——因此你如何运行、监测并支持一项线上服务,是一项患者安全决策,而不是后台的事后补充。

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

发布是开始,而不是结束。一项数字服务会花几个月被构建,如果它成功,还会花数年甚至数十年被运行——而运行正是大部分资金流向、也是伤害真正发生的地方。一份共享照护记录、一个电子处方系统,或一个产科笔记平台,只有在它运行、正确、响应迅速的时候才能实现其价值。当它退化或失效时,后果不是不便,而是延迟的治疗、遗漏的过敏史、被取消的门诊,以及临床医生在压力之下退回到不熟悉的纸质变通方案。

医疗与照护一天 24 小时、一周 7 天运转,无法暂停。当一家超市的收银系统出问题时,顾客等待;当一家医院的患者管理系统出问题时,救护车可能要改道,择期手术清单可能被推迟。这给了线上运营一种独特的分量:宕机是一起临床安全事件,而你如何侦测、上报、沟通并从中恢复的计划,是你照护义务的一部分。2017 年的 WannaCry 勒索软件攻击——迫使数千个 NHS 预约与手术被取消——是一次运营失败如何变成一场患者安全与公众信任危机的参考案例(见主题 1.7——信息治理、数据保护与网络安全)。

领导者也需要诚实地为线上运营配置资金与人员。医疗科技领域一个持久的失败,是庆祝上线、解散团队,并把运行中的服务当作"已完成"来对待。一项没有常设团队、没有监测、没有待命保障的线上服务,并不是在省钱——它是在悄悄累积临床风险,直到它有一天轰然失效。服务管理是维持一项线上服务安全的学科,它应得与构建同等的严谨程度。

核心概念#

服务管理与"上线"阶段。 IT 服务管理(ITSM)是一套用于设计、运行、支持并改进 IT 服务、覆盖其整个生命周期的实践。在 GOV.UK 与 NHS 的阶段模型中,上线是服务持续运营的阶段——依然在迭代,依然获得资助,依然被拥有——直到它被退役(见主题 3.5——交付生命周期)。上线不是一个静止状态;它是生命周期中最长、也最昂贵的部分。

ITIL 4。 ITIL 是使用最广泛的 ITSM 框架。它当前的版本 ITIL 4,把旧版本中更繁重的流程重新构建为一个"服务价值系统"与灵活的实践,被设计为与敏捷、DevOps 与精益并存,而不是与它们竞争。把 ITIL 当作一套词汇与一份可相称地采纳的实践清单来对待——而不是一整套要照搬进来的官僚体系。

事故、问题与变更管理。 事故管理在一次计划外中断之后尽可能快地恢复正常服务——优先级是恢复,而不是诊断。问题管理调查一次或多次事故的根本原因,以阻止其重复发生,并维护一份已知错误与变通方案的记录。变更管理(ITSM 意义上的)控制着对线上资产的变更如何被评估、批准与发布,以便修复一件事不会破坏另一件事。这三项实践是运营的核心,它们相互咬合:一次事故可能引出一个问题,而这个问题的修复以一次变更的形式交付。

重大事故管理与业务连续性。 重大事故是一起高影响事件——一个临床系统在一家信托机构范围内瘫痪——需要一个已宣布的、协调一致的响应,拥有明确的事故指挥官、沟通渠道与临床领导。业务连续性规划(BCP)是在中断期间保持以可接受水平持续交付照护的更广泛能力,包括经过测试的临床宕机流程(安全的纸质后备方案)与灾难恢复。在医疗与照护领域,这些不是可选项:在系统宕机时保持患者安全,正是全部意义所在。

站点可靠性工程、SLI、SLO、SLA 与错误预算。 起源于 Google 的站点可靠性工程(SRE),把软件工程的纪律应用于运营。它用一个服务水平指标(SLI)——诸如可用性或延迟这样的度量——对照一个服务水平目标(SLO)——该度量的一个内部目标——来衡量可靠性。一份服务水平协议(SLA)是外部的、通常是合同性的承诺,通常设定得比内部 SLO 更宽松。100% 与你的 SLO 之间的差距,就是错误预算:你在必须停止发布新功能、转而稳定系统之前,能够花费的不可靠性额度。在临床系统中,SLO 必须与临床医生一起设定,因为"可接受的"宕机是一项安全判断,而不仅仅是工程判断。

可观测性与监测。 可观测性是从一个系统的外部输出——日志、指标与追踪——理解其内部状态的能力,这样你就能侦测并诊断问题,理想情况下是在用户之前。监测与告警把这些数据转化为给待命人员的及时信号。你无法安全地运行一项你看不见的服务。

待命、轮值表与服务台。 待命轮值表确保一位胜任的真人能够全天候响应告警;在一个全天候的照护环境中,它们是必不可少的,而且必须是人性化、可持续的。一个服务台(或帮助台)是终端用户的单一联系点——那位无法登录的临床医生、那位预约屏幕卡死的前台接待员——提供支持、记录事故并向前转发。

DevOps、配置管理与 CMDB。 DevOps 与 SRE 原则"谁构建,谁运行",让构建一项服务的团队负责运行它,弥合开发与运营之间的差距。配置管理保存着构成一项服务的各个组件及其关系的准确记录,常常存放在一个配置管理数据库(CMDB)中;没有它,在一次事故期间,没有人能够安全地回答"这次变更会影响什么?"

运行与构建的对比与退役。 机构把构建资金(创造新能力)与运行资金(运营既有的东西)分开。运行资金不足,是大多数运营失败的结构性根源。而每一项服务最终都会走到退役——安全的退役,数据依保留法被迁移或归档,用户被重新引导——这本身就是一门运营学科。

最佳实践#

1. 把"运行"当作一项头等承诺来资助与配置人员,而不是一个剩余项。 在上线之前就为服务的运营生命周期做预算——监测、待命、服务台、安全补丁与持续迭代——并保护它不被下一个亮眼的构建项目侵占。行业的经验法则是,运行一个系统在其生命周期内的成本远高于构建它,这在医疗领域同样成立。一项有构建资金、却没有运行资金的服务,是一项带着发布日期的临床风险。

2. 避免"扔过墙给运营"这种反模式。 不要让一个项目团队构建一项服务,然后把它交给一个从未见过它是如何被构建出来的独立运营团队。应用"谁构建,谁运行":让理解这项服务的团队对其可靠性负责,或至少运行一次刻意的、有文档记录的服务过渡,配有共享的待命与一段保修期。构建与运行之间的隔墙,正是知识、所有权与安全性会从中掉落的地方。

3. 与临床医生一起设定 SLO,并管理一份错误预算。 为每一项服务定义"足够可靠"意味着什么,表达为可衡量的 SLI 与 SLO,并与承担后果的临床医生共同设定它们——一个急诊科系统的可用性目标不是一个纯技术性的选择。用错误预算来仲裁发布新功能与保持稳定之间永恒的张力:当可靠性额度用尽时,停止并稳定系统。让外部 SLA 比内部 SLO 更宽松,这样你在违反一项承诺之前还有行动的余地。

4. 在让一项服务变得更大之前先让它变得可观测。 为日志记录、指标与追踪安装仪器,构建反映用户与临床医生体验、而不仅仅是服务器健康状况的仪表盘与告警。针对重要的症状发出告警(患者无法被预约),而不是针对每一个底层的小波动,以避免训练响应者忽视寻呼的告警疲劳。你无法保持一项其失败只能从愤怒的临床医生那里得知的服务的安全。

5. 相称地运行有纪律的事故、问题与变更管理。 为事故设定清晰的严重程度等级、响应目标,为重大事故设一位事故指挥官,并在响应期间保持一个单一权威来源。把严重事故纳入无咎的事后审查,以及一个修复根本原因、而不是反复重启服务器的问题管理流程。通过一个恰如其分的流程来控制变更——为常规低风险工作采用轻量级的、标准的、预先批准的变更;只为真正有风险的变更保留一次变更咨询审查——这样治理才能保护安全,而不会变成一个诱使人们绕过它的瓶颈。

6. 演练重大事故与临床宕机,而不仅仅是记录它们。 编写、测试并定期演练业务连续性与临床宕机流程:照护如何在纸上继续、员工如何被告知系统宕机、数据如何在恢复时被核对,以及谁来宣布并指挥一次重大事故。未经测试的计划会在那一天失败。把这明确地与你的临床风险管理及危害日志联系起来(见主题 1.6——临床安全与风险管理),因为宕机是一项你可以演练缓解措施的临床危害。

7. 把事后学习当作无咎且系统性的来对待。 在每一次重大事故之后,开展一次追问系统如何让这次失败发生的审查,而不是追问该责怪谁——因为追责会把报告驱赶到地下,并让伤害重演。捕捉行动项,指定负责人,并追踪到结案;把模式反馈进问题管理与设计中。一种学习文化是一项患者安全管控,呼应着临床事故报告中的"公正文化"。

8. 维护一份准确的配置记录,管理整个资产。 维护一份 CMDB 或等同的清单,记录正在运行什么、什么依赖于什么、部署了哪些版本,以及每项服务的负责人是谁,这样在一次事故期间,你才能在几分钟内回答"这会影响什么?"这支撑着安全的变更、安全补丁与授权管理,也是大多数大型 NHS 资产最薄弱的地方。一个未知的、未打补丁的系统,既是一次即将发生的中断,也是一起即将发生的网络安全事故(见主题 1.7)。

9. 让待命可持续,让支持人性化。 设计人手充足、报酬公平、人性化的待命轮值表,拥有清晰的上报机制与现实的期望——精疲力竭的响应者,恰恰会在最关键的时刻做出缓慢、易出错的决策。为服务台配置符合一支全天候临床劳动力真实需求的资源,并给一线员工一条快速、受尊重的问题上报路径。你支持的质量,就是照护人员从你的服务中体验到的质量。

10. 把退役规划为一项受控的运营。 在服务运行期间就决定它最终将如何被退役:依据记录保留法进行数据迁移或归档、用户重新引导、临床医生通知,以及危害日志与审计轨迹的保存。一次没有规划的退役会让数据与用户搁浅,并可能违反法定保留职责。一次有规划的退役,是一个可审计的运营项目,而不是替代品到来时的一场手忙脚乱。

与团队讨论的问题#

1. 如果一个关键临床系统在某个银行假日的凌晨三点宕机,究竟谁做什么——我们曾经测试过吗? 这个问题迫使人们正视一份有文档记录的计划与一项真实能力之间的差异。在医疗与照护领域,宕机是一起临床事件:实际的问题是谁会被寻呼、他们响应得有多快、谁有权宣布一次重大事故、临床员工如何被告知切换到宕机流程、患者如何在纸面上保持安全,以及数据如何在恢复时被核对。讨论你的待命轮值表在非常规时段与假期是否真的有胜任的人员覆盖,还是在风险最高时被稀释成一个筋疲力尽的人。考虑临床医生是否知道这个宕机流程、是否曾经演练过它,还是它存放在一个没有人打开过的活页夹里。一个好的、诚实的答案会描述一次经过测试的响应——有具名的角色、去年的一次真实演练,以及被付诸行动的教训——而不是一份从未遇到过中断的政策文件。如果诚实的答案是"我们其实不知道",这本身就是需要向董事会揭示的最重要的发现。

2. 我们是否真的在为"运行"提供资金与人员,还是我们庆祝了上线之后就悄悄走开了? 一项服务的大部分成本与临床风险存在于发布之后,然而资金模式却奖励构建新事物,让运营旧事物挨饿。值得讨论的张力,是构建资金的结构性拉力,与监测、打补丁、支持,并让一项线上服务持续迭代多年这项不光鲜、却必不可少的工作之间的矛盾。诚实地审视你的线上资产:有多少服务有具名的负责人、一支获得资助的团队、最新的安全补丁,以及正常运作的监测——又有多少是无人认领的、运行在不受支持的软件上,没有人负责?考虑"扔过墙给运营"的模式,以及运行每一项服务的人是否理解它是如何被构建出来的。一个好的答案能够指出受保护的运行预算、为运营生命周期指定的服务负责人,以及一次刻意的服务过渡、而不是一次遗弃,并能诚实地说出无人认领的服务,这样它们才能被认领、被替换,或被退役,而不是被放任失败。

3. 我们如何决定"足够可靠"意味着什么——谁有发言权? 可靠性不是免费的,追求额外一个"9"的可用性,成本可能超过它所防止的伤害;但在临床系统中,"可接受的"宕机是一项安全判断,工程师无法独自做出。这个问题追问你是否有明确的 SLI 与 SLO,它们是否是与承担后果的临床医生及运营领导一起设定的,以及你是否使用类似错误预算的东西来平衡发布改进与保持稳定。讨论你所管理的内部目标,与你所承诺的外部 SLA 之间的区别,以及你的监测衡量的是临床医生实际体验到的东西,还是仅仅是服务器报告的东西。考虑"我们的目标是 99.9%"是否有任何实际约束力——一个明确的衡量方式、一次违反时的后果、一位会采取行动的负责人。一个好的答案会把一个可靠性目标与一个临床安全理由联系起来,展示这项指标被衡量并有人拥有,并描述当预算用尽时团队会做出什么不同的事情,而不是一份没有人真正管理的幻灯片上的数字。

4. 我们是否真的知道自己在运行什么——我们能否在一次事故正在发生的过程中回答"这次变更会影响什么?" 大多数大型医疗与照护资产恰恰在最痛的地方最薄弱:没有人持有一幅关于什么在运行、什么依赖于什么、部署了哪些版本,以及每项服务由谁负责的准确、最新的图景。这个问题探究的是,你是否维护着一份配置记录——一个 CMDB 或等同物——还是这些知识存在于少数几个人的脑海中,以及十年未经记录的集成之中。讨论真实的后果:一次悄悄破坏了下游系统的变更,一个因为没有人知道它会影响什么而无法应用的安全补丁,一台只有在失效或被攻击时才被发现的不受支持的服务器。张力在于,配置管理不光鲜、永远做不完、容易被推迟,却支撑着安全的变更、打补丁、授权管理与网络韧性——正是这同一个盲点,把 WannaCry 变成了一场危机。一个诚实的答案会描述一份被维护的、有负责人与依赖关系的、人们在事故中信任并使用的清单,并说出资产中仍然黑暗的部分,而不是声称一种任何大型机构都不曾真正拥有的完整性。

5. 当出问题时,我们是在学习,还是在寻找一个人来责怪? 你事故审查的文化,决定了同样的伤害是否会重演。这个问题追问的是,严重事故是否会触发一次无咎的、系统性的审查,追问系统是如何让这次失败发生的——还是它们悄悄地寻找一个人来追责,这会把报告驱赶到地下,并保证重演。讨论未遂事件与小失败是否真的会被揭示出来,还是只有大到无法隐藏的中断才会;审查的行动项是否被指定负责人并追踪到结案,还是被写下之后就被遗忘;以及模式是否反馈进问题管理与设计中。考虑与临床事故报告及"公正文化"的类比:同一个机构可能对患者安全事故持有一种成熟的、无咎的立场,却对 IT 失败持一种惩罚性的立场,或者反过来。一个好的答案会用证据展示一种学习文化——改变了系统的审查、结案的行动项、下降的复发率——并诚实地承认恐惧仍然抑制报告的地方,因为一种学习文化本身就是一项患者安全管控,而不是一种软性的附加项。

6. 我们是否已经决定了这项服务最终将如何退役——趁它还活着、还能规划的时候? 每一项服务最终都会被替换或关闭,然而退役几乎总是一个事后补充,在继任者到来、旧系统已经变成障碍时才被手忙脚乱地处理。这个问题追问,对于每一项线上服务,你是否有一份安全退役的计划:数据依记录保留法被迁移或归档、用户被重新引导、临床医生被通知,以及危害日志与审计轨迹被保存。讨论把这件事做错所涉及的具体医疗与照护风险——违反法定保留职责的搁浅记录、没有人能访问的孤儿数据、一个因为没有人负责它的终结而拖延数年未打补丁的"临时"遗留系统。考虑在国家与企业级资产中,数十年的临床记录可能存放在一个必须被退役、却不能丢失任何一份法律要求记录的系统中。一个诚实的答案会把退役当作一项从上线之日起就被规划的、具名的、有资金支持的、可审计的运营来对待,而不是一笔日后才被发现的成本,并能指出至少一项其生命终结已经被决定、而不是被推迟的服务。

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

一个整合照护系统(ICS)运行着一份共享照护记录,被医院临床医生、全科医生、社区团队,以及一个地区的非工作时间服务所使用。它在两年前上线;构建项目已经结束,一支常设的产品与运营团队现在拥有它。这支团队是靠艰难的方式学会服务管理的。

早期,这份记录只对服务器正常运行时间进行监测。一个冬天的晚上,服务器"一片绿色",而一个失败的集成却悄悄地停止了全科医生用药更新的流动——因此医院临床医生看到的是过时的用药清单达数小时之久,直到一位药剂师注意到并打电话给服务台。事后审查是无咎且系统性的:它发现真正的问题,是缺少一个反映临床医生体验的 SLI。团队增加了端到端的可观测性、一个与临床安全官共同商定的数据新鲜度 SLO,以及一个当更新延迟超过安全阈值时会寻呼待命人员的告警。这个危害被添加进了临床风险危害日志(主题 1.6)。

然后他们把自己的实践调整到恰当的规模。常规、低风险的配置更新变成了标准的、预先批准的变更,通过一条带有快速回滚的自动化流水线发布;只有真正有风险的变更才会提交给一个有临床代表参与的每周变更审查。一份人性化的待命轮值表覆盖夜间与假期,由一个配置了符合真实全天候需求资源的服务台支撑。至关重要的是,他们编写并现在每年两次演练一份临床宕机流程:一份只读的关键记录缓存副本、一个纸质后备方案、一条告知临床医生系统正在降级运行的短信级联,以及一个恢复时的核对步骤。去年春天,当一次数据中心电力故障让主系统离线四十分钟时,照护在经过测试的后备方案上得以延续,事故指挥官运行了一场冷静、协调一致的响应,没有患者受到伤害。董事会看到的是一份与临床安全度量挂钩的可靠性报告,而不是一种含糊的安慰——服务的所有权,直到最终退役,都是具名且获得资助的。

行业视角#

初创企业#

一家小型健康科技公司通常没有独立的运营职能,因此"谁构建,谁运行"是默认选项,而不是一种愿景——编写代码的同一批工程师携带寻呼机。优势是快速反馈,没有隔墙需要把工作扔过去;危险是一个两人的待命轮值表既不可持续也不安全,监测止步于"服务器还在运行吗?"初创企业应当从第一个 NHS 客户起就采纳 SLO、基本的可观测性、无咎的事后审查,以及一份书面的宕机流程,因为一次临床中断可能同时终结合同与公司。即使没有 ITIL 的那些仪式,其意图——看到服务、快速响应、系统性地学习、在失效时保持患者安全——在医疗领域是不容商量的。

小型企业#

一家成熟的小型提供者——一家全科诊所、一家社区药房、一家养老院,或一家单一场所的诊所——每天都在运行线上临床系统,但通常没有专门的 IT 职能,也没有人的工作是服务管理。这里"运行"被挤压进临床与行政工作的边角,"待命"实际上是"执业经理的手机",监测是一位临床医生注意到预约屏幕卡死了。务实的优先事项是那些保持患者安全的少数几件事:一份书面的、经过演练的宕机流程(诊所如何在纸上问诊、之后如何核对)、一条在托管系统失效时向每个供应商上报的已知路径,以及对这些供应商实际欠了什么 SLA 的清晰认识。一家已过初创阶段的小型独立健康科技供应商面临着镜像问题——依赖它的真实客户,却只有薄弱的运营覆盖——必须在现金紧张的情况下依然提供可信的支持时间与事故响应。照护义务与大型信托机构相同;资源却不同,因此纪律在于对安全攸关的基础事项进行不留情面的优先排序,而不是追求 ITIL 的完整性。

大型企业#

一家 NHS 信托机构或大型供应商以最完整的形式运行服务管理:一个正式的服务台、符合 ITIL 的事故/问题/变更实践、变更咨询委员会、重大事故与业务连续性计划,以及常常有一个全天候运营中心。典型的挑战是一片庞大的遗留资产,配置记录薄弱、系统未打补丁、所有权不清——正是这些条件把 WannaCry 变成了一场危机。经典的失败是变更流程重得让员工绕过它,以及"运行"被永久性地挨饿,以资助下一个构建项目。大型企业拥有恰当地实现可观测性、可持续待命与经过测试的连续性的资源,因此任务是让这些实践保持相称、真正由临床拥有,而不是一种给人虚假安心感的文书仪式。

政府机构#

一个国家机构运营着可能触及数百万人的服务,因此一次中断是一起带有议会与公众信任后果的国家级事故,可靠性目标是公共问责事项。政府交付把 ITSM 与 GOV.UK 服务手册对线上服务被恰当运营、监测与迭代——而不是在发布时被冻结——的期望结合起来,并与围绕记录保留与网络安全(NCSC、DSPT)的法定职责结合起来。支出控制与多年期资金安排塑造着"运行"资金的样子,而巨大的规模提高了业务连续性、协调一致的重大事故响应,以及对拥有数十年记录的遗留国家系统进行安全退役的利害关系。这里的取舍是保证与韧性,与速度和成本之间的对比,在公开的审视下被解决。

常见失败模式#

• 扔过墙给运营。 一个构建团队把一项服务交给一个从未见过它是如何被构建出来的运营团队;知识、所有权与安全性从缝隙中掉落。解药:"谁构建,谁运行",或一次刻意的过渡,配有保修期与共享待命。
• 孤儿式的线上服务。 项目结束,团队解散,运行资金蒸发;服务腐烂,未被打补丁,悄悄累积临床与网络风险。解药:为运营生命周期指定具名的服务负责人与受保护的运行预算。
• 监测服务器,而不是服务。 一切都"一片绿色",而临床医生看到的却是过时或缺失的数据。解药:反映用户与临床医生体验的 SLI,针对重要症状发出告警。
• 未经测试的连续性计划。 一份临床宕机流程存在于纸面上,却从未被演练过,因此它在那一天失败。解药:定期演练重大事故与宕机计划,并修复出问题的地方。
• 由追责驱动的事故审查。 追责把报告驱赶到地下,让伤害重演。解药:无咎的、系统性的事后学习,配有被追踪的行动项。
• 变更流程的表演。 一个笨重到团队绕过它的变更委员会,或一个轻率到有风险的变更未经检查就发布的变更委员会。解药:恰当地设定规模——预先批准标准变更,只为真正有风险的变更保留审查。
• 没有配置记录。 在一次事故期间没有人能够回答"这次变更会影响什么?"解药:维护一份 CMDB 或等同物,记录所有权与依赖关系。

成熟度模型#

检查清单#

• 每一项线上服务都有一位具名负责人,以及为其运营生命周期设立的受保护运行预算。
• 运行每一项服务的团队理解它是如何被构建出来的(或存在一次有文档记录的、配有保修期与共享待命的过渡)。
• SLI 与 SLO 已被定义,临床系统的目标是与临床医生一起设定的;外部 SLA 比内部 SLO 更宽松。
• 可观测性(日志、指标、追踪)与基于症状的告警反映的是临床医生与用户的体验,而不仅仅是服务器健康状况。
• 事故管理有严重程度等级、响应目标、一个事故指挥官角色,以及响应期间的一个单一权威来源。
• 问题管理修复根本原因;事后审查是无咎的,其行动项被追踪到结案。
• 变更管理被恰当地设定规模:标准变更被预先批准并自动化;只有有风险的变更才被审查,并有临床方面的输入。
• 业务连续性与临床宕机流程被书写出来,与危害日志相联系,并至少每年演练一次。
• 待命轮值表人手充足、人性化、报酬公平;服务台配置了符合真实全天候需求的资源。
• 一份配置记录(CMDB 或等同物)列出了组件、依赖关系、版本与负责人,并支持安全补丁工作。
• 一份退役计划涵盖依保留法进行的数据迁移/归档、用户重新引导,以及安全与审计记录的保存。

关键来源#

• ITIL 4 ——服务价值系统与管理实践(事故、问题、变更、服务台、服务水平管理)——PeopleCert / AXELOS。
• Google ——《站点可靠性工程》与《站点可靠性工作手册》(SLI、SLO、错误预算、待命、无咎事后分析)。
• GOV.UK 服务手册 ——运营与迭代一项线上服务;监测一项服务的状态;发布后维护一项服务。
• NHS England ——临床风险管理标准 DCB0129/DCB0160,以及把系统宕机当作一项临床危害来对待(见主题 1.6)。
• NHS England / NCSC ——网络安全运营、数据安全与保护工具包(DSPT),以及 2017 年 WannaCry 事件的教训(见主题 1.7)。
• ISO/IEC 20000(IT 服务管理)与 ISO 22301(业务连续性管理体系)。
• DevOps 研究与评估(DORA)——把交付与运营表现联系起来的能力(监测、变更、可靠性)。
• 向领导层报告运营与可靠性情况的 OKR 与 KPI(见主题 10.0——目标与关键成果(OKR))。

参考文献#

1. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. Incident management — Wikipedia — https://en.wikipedia.org/wiki/Incident_management
4. Change management (ITSM) — Wikipedia — https://en.wikipedia.org/wiki/Change_management_(ITSM)
5. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
6. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Service-level objective — Wikipedia — https://en.wikipedia.org/wiki/Service-level_objective
9. Service level indicator — Wikipedia — https://en.wikipedia.org/wiki/Service_level_indicator
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
12. Configuration management database — Wikipedia — https://en.wikipedia.org/wiki/Configuration_management_database
13. Help desk — Wikipedia — https://en.wikipedia.org/wiki/Help_desk
14. Site Reliability Engineering (SRE book) — Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), Google — https://sre.google/books/
15. ITIL 4 Foundation and service management practices — PeopleCert / AXELOS — https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565
16. Service Manual: operating a service and monitoring its status — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/technology/monitoring-the-status-of-your-service
17. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
18. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
19. ISO/IEC 20000-1 — IT service management systems — International Organization for Standardization — https://www.iso.org/standard/70636.html
20. ISO 22301 — Security and resilience: business continuity management systems — International Organization for Standardization — https://www.iso.org/standard/75106.html
21. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/