トピック3.8 — サービスマネジメントとライブ運用

医療・ケアでは、サービスの寿命、コスト、臨床リスクの大半は稼働後にあります。したがって、稼働中のサービスをどう運用し、監視し、支援するかは、バックオフィスの後回しではなく、患者安全の判断です。

医療・ケアにおいてなぜ重要か#

ローンチは終わりではなく、始まりです。デジタルサービスは、数か月かけて作られ、成功すれば、何年も何十年も運用されます。そして運用こそ、お金の大半がかかり、害が実際に起こる場所です。共有ケア記録、電子処方システム、産科記録のプラットフォームは、稼働し、正確で、応答しているときにのみ、その価値を届けます。それが劣化したり失敗したりすれば、結果は不便ではなく、治療の遅れ、見逃されたアレルギー、中止されたクリニック、そしてプレッシャーの下で不慣れな紙の回避策へと戻る臨床家です。

医療・ケアは、24時間365日動き、止まることができません。スーパーのレジシステムが故障すれば、客は待ちますが、病院の患者管理システムが故障すれば、救急車は迂回し、予定された手術は延期されます。このことが、ライブ運用に独特の重みを与えます。ダウンタイムは臨床安全上の出来事であり、それを検知し、エスカレーションし、伝え、回復する計画は、注意義務の一部です。何千ものNHSの予約と手術の中止を強いた、2017年のWannaCryランサムウェア攻撃は、運用上の失敗が、患者安全と公的信頼の危機になる仕方の基準となる事例です（トピック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は臨床家とともに設定しなければなりません。「許容できる」ダウンタイムは、エンジニアリングだけでなく、安全の判断だからです。

観測可能性と監視。 観測可能性は、システムの内部状態を、その外部への出力、つまりログ、メトリクス、トレースから理解する能力で、理想的には、ユーザーより先に、問題を検知し診断できます。監視とアラートは、そのデータを、オンコールの人々への時宜を得たシグナルに変えます。見えないサービスを、安全に運用することはできません。

オンコール、当番表、サービスデスク。 オンコールの当番表は、有能な人間が、24時間、アラートに対応できるようにします。24時間365日のケアの場では不可欠であり、人道的で持続可能でなければなりません。サービスデスク（またはヘルプデスク）は、エンドユーザー、つまりログインできない臨床家や、予約画面が固まった受付にとっての単一の窓口で、支援を提供し、インシデントを記録し、振り分けます。

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. オンコールを持続可能にし、支援を人間的にする。 十分な人員が配置され、公正に報酬が払われ、人道的で、明確なエスカレーションと現実的な期待を備えたオンコールの当番表を設計します。燃え尽きた対応者は、まさに最も重要な瞬間に、遅く誤りやすい判断を下すからです。サービスデスクに、24時間365日の臨床職員の実際の需要に見合う資源を与え、最前線の職員に、問題を報告するための、速く尊重される経路を与えます。支援の質は、サービスから職員が体験するケアの質です。

10. 廃止を、管理された運用として計画する。 サービスが稼働している間に、それが最終的にどう廃止されるかを決めます。記録の保存に関する法律の下でのデータの移行またはアーカイブ、ユーザーの振り向け、臨床家への通知、ハザードログと監査証跡の保全。計画されていない廃止は、データとユーザーを取り残し、法定の保存義務に違反しかねません。計画された廃止は、後継が届いたときの駆け込みではなく、監査可能な運用プロジェクトです。

チームで話し合うための問い#

1. 祝日の午前3時に重要な臨床システムが停止したとき、正確に誰が何をするのか。そして、それをテストしたことがあるか。 この問いは、文書化された計画と、本物の能力との違いを突きつけます。医療・ケアでは、ダウンタイムは臨床上の出来事です。実務上の問いは、誰がページされるか、どれだけ速く応答するか、誰が重大インシデントを宣言する権限を持つか、臨床職員にどうダウンタイムの手順へ切り替えるよう伝えるか、患者が紙でどう安全を保つか、回復時にデータをどう突合するかです。オンコールの当番表に、夜間や休日に、実際に有能な体制があるのか、それともリスクが最も高いときに、疲れ切った一人に薄まっていくのかを議論してください。臨床家がダウンタイムの手順を知っていて、リハーサルしたことがあるのか、誰も開いたことのないバインダーの中にあるのかを考えます。良い誠実な答えは、検証された対応、つまり名前付きの役割、過去1年での本物の演習、そして行動に移された教訓を説明し、停止に一度も出会ったことのない方針文書ではありません。誠実な答えが「実はよくわからない」であるなら、それ自体が、取締役会に示すべき最も重要な発見です。

2. 私たちは本当に「運用」に資金を出し、人を配置しているのか。それとも、稼働を祝い、静かに立ち去ったのか。 サービスのコストと臨床リスクの大半はローンチ後にあるのに、資金のモデルは、新しいものを作ることに報い、古いものの運用を飢えさせます。議論すべき緊張は、構築の資金の構造的な引力と、稼働中のサービスを何年も監視し、パッチを当て、支援し、反復するという、地味で不可欠な仕事との間にあります。自分たちの稼働中の環境を正直に見てください。名前のある所有者、資金の付いたチーム、最新のセキュリティパッチ、機能する監視を持つサービスはいくつあり、誰も責任を負わず、サポート切れのソフトウェアで動く、孤児になったものはいくつあるか。「運用部門に壁越しに投げる」パターンと、各サービスを運用する人々が、それがどう作られたかを理解しているかを考えます。良い答えは、保護された運用予算、運用寿命にわたる名前付きのサービス所有者、放棄ではなく意図的なサービス移行を示し、孤児になったサービスを正直に挙げて、失敗するに任せずに、引き取り、置き換え、あるいは廃止できるようにします。

3. 「十分に信頼できる」が何を意味するかを、どう決めるのか。そして、誰が発言権を持つのか。 信頼性は無償ではなく、可用性の「9」をもう一つ追うことは、それが防ぐ害より高くつくことがあります。しかし臨床システムでは、「許容できる」ダウンタイムは、エンジニアだけでは下せない安全の判断です。この問いは、明示的なSLIとSLOがあるか、結果を負う臨床家と運用リーダーとともに設定されたか、そして改善の出荷と安定性の維持のバランスをとるために、エラーバジェットのようなものを使っているかを問います。自分たちが管理する社内の目標と、約束する外部のSLAの違い、そして監視が、臨床家が実際に体験することを測っているのか、単にサーバーが報告することを測っているのかを議論してください。「99.9%を目指す」に、歯があるか、つまり定義された測定、違反したときの結果、行動に移す所有者があるかを考えます。良い答えは、信頼性の目標を臨床安全の根拠に結びつけ、指標が測定され所有されていることを示し、予算が尽きたときにチームが違うことをどうするかを説明し、誰も管理しないスライド上の数字ではありません。

4. 私たちは自分たちが何を運用しているかを本当に知っているか。そして、インシデントの最中に「この変更は何に影響するか」に答えられるか。 大規模な医療・ケアの環境の大半は、まさに最も痛いところで最も弱いのです。何が動き、何が何に依存し、どのバージョンがデプロイされ、誰が各サービスを所有するかについて、正確で最新の全体像を持つ人は誰もいません。この問いは、構成の記録、つまりCMDBか同等のものを維持しているか、その知識が、数人の頭の中と、10年分の文書化されていない連携の中にあるのかを探ります。本物の帰結を議論してください。下流のシステムを静かに壊す変更、何に触れるか誰も知らないために適用できないセキュリティパッチ、故障するか悪用されるまで発見されないサポート切れのサーバー。緊張は、構成管理が地味で、決して終わらず、先送りしやすいのに、安全な変更、パッチ適用、ライセンス、サイバーレジリエンスのすべてを支えていることです。WannaCryを危機に変えたのと同じ盲点です。誠実な答えは、人々が信頼し、インシデントの最中に使う、責任者と依存関係を備えた維持されたインベントリを説明し、大規模な組織が本当に持つことのない完全性を主張するのではなく、環境のうち、まだ暗い部分を名指しします。

5. 何かがうまくいかなかったとき、私たちは学ぶのか。それとも、誰かを責めようとするのか。 インシデントのレビューの文化が、同じ害が繰り返されるかどうかを決めます。この問いは、深刻なインシデントが、システムがどのように失敗を許したかを問う、非難のない、システムとしてのレビューを引き起こすのか、それとも個人の落ち度を静かに探し、報告を地下に潜らせ、繰り返しを保証するのかを問います。ヒヤリハットや小さな失敗が、そもそも表に出るのか、隠せないほど大きな停止だけなのか、レビューの対応に責任者が割り当てられ、クローズまで追跡されるのか、書かれて忘れられるのか、パターンが問題管理と設計にフィードバックされるのかを議論してください。臨床のインシデント報告と「公正な文化」との類比を考えます。同じ組織が、患者安全のインシデントについては成熟した非難のない姿勢を持ちながら、ITの失敗には懲罰的な姿勢を持つ、あるいはその逆ということがありえます。良い答えは、エビデンスを伴う学習の文化、つまりシステムを変えたレビュー、クローズした対応、減っていく再発を示し、恐れがいまだに報告を抑えている箇所を正直に認めます。学習の文化は、それ自体が患者安全の統制であり、付け足しではないからです。

6. このサービスが最終的にどう廃止されるかを、まだ稼働していてそれを計画できるうちに決めたか。 あらゆるサービスは、いつか置き換えられるか停止されますが、廃止は、ほとんど常に後回しにされ、後継が届き、古いシステムがすでに障害になったときに慌てて行われます。この問いは、稼働中のサービスそれぞれについて、安全な引退の計画があるかを問います。記録の保存に関する法律の下でのデータの移行またはアーカイブ、ユーザーの振り向け、臨床家への通知、ハザードログと監査証跡の保全。これを誤ることの、医療・ケア固有のリスクを議論してください。法定の保存義務に違反する、取り残された記録、誰もアクセスできない孤児になったデータ、その終わりを誰も所有しないために、パッチも当たらないまま何年も居座る「一時的な」レガシーシステム。国や大企業の環境では、数十年分の臨床記録が、法的に必要な記録を一件も失わずに廃止しなければならないシステムの中にあることを考えます。誠実な答えは、引退を、後で発見されるコストではなく、稼働時から計画される、名前付きで、資金が付き、監査可能な運用として扱い、終わりがすでに先送りではなく決められている、少なくとも一つのサービスを示せます。

実践例：医療・ケアの事例#

ある統合ケアシステム（ICS）は、地域全体で、病院の臨床家、一般診療医、コミュニティのチーム、時間外サービスが使う、共有ケア記録を運営しています。2年前に稼働し、構築プログラムは終了し、常設のプロダクトと運用のチームがそれを所有しています。そのチームは、サービスマネジメントを、苦労して学びました。

初期には、記録には、サーバーの稼働時間の監視しかありませんでした。ある冬の夕方、サーバーは「緑」でしたが、失敗した連携が、一般診療医の薬剤の更新が流れるのを静かに止め、病院の臨床家は、薬剤師が気づいてサービスデスクに電話するまでの数時間、古い薬剤リストを見ていました。インシデント後のレビューは、非難がなく、システムとしてのものでした。本当の問題は、臨床家の体験を反映するSLIがなかったことだとわかりました。チームは、エンドツーエンドの観測可能性、臨床安全責任者と共同で合意した、データの鮮度についてのSLO、更新が安全の閾値を超えて遅れたときにオンコールをページするアラートを追加しました。このハザードは、臨床リスクのハザードログに追加されました（トピック1.6）。

次に、実践を適切な規模に整えました。日常の低リスクな設定の更新は、標準の事前承認された変更となり、素早いロールバックを備えた自動化されたパイプラインで出荷されます。本当にリスクの高い変更だけが、臨床の代表を含む週次の変更レビューに回ります。人道的なオンコールの当番表が夜間と休日をカバーし、実際の24時間365日の需要に見合う資源を持つサービスデスクに支えられます。決定的に、臨床のダウンタイム手順を書き、いまは年に2回リハーサルしています。主要な記録の読み取り専用のキャッシュされたコピー、紙での代替手段、システムが劣化していることを臨床家に伝えるSMSの連鎖、回復時の突合のステップです。昨春、データセンターの電源障害で主システムが40分間オフラインになったとき、ケアは検証済みの代替手段で続き、インシデント指揮官は落ち着いた調整された対応を行い、患者は誰も害されませんでした。取締役会が見たのは、漠然とした保証ではなく、臨床安全の指標に結びついた信頼性の報告書でした。そして、サービスの、最終的な廃止までの所有は、名前が付けられ、資金が付いています。

セクター別の視点#

スタートアップ#

小さなヘルステック企業には、別個の運用機能がないことが多く、そのため「作った者が運用する」は、願望ではなく既定です。コードを書いた同じエンジニアが、ポケベルを持ちます。利点は、速いフィードバックと、仕事を投げる壁がないことで、危険は、持続可能でも安全でもない、二人のオンコールの当番表と、「サーバーは動いているか」で止まる監視です。スタートアップは、最初のNHSの顧客から、SLO、基本的な観測可能性、非難のないインシデント後のレビュー、書面のダウンタイム手順を採用すべきです。臨床上の停止は、契約と会社の両方を終わらせうるからです。ITILの儀式がなくても、その意図、つまりサービスを見て、速く対応し、システムとして学び、失敗したときも患者を安全に保つことは、医療では譲れません。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、単独拠点のクリニックは、毎日、稼働中の臨床システムを運用していますが、通常、専任のIT機能も、サービスマネジメントが仕事の人もいません。ここでの「運用」は、臨床と事務の仕事の隙間に押し込まれ、オンコールは実際には「診療所マネージャーの携帯電話」であり、監視は、臨床家が予約画面が固まったことに気づくことです。実務上の優先事項は、患者を安全に保つ少数のことです。書面で、リハーサルされたダウンタイム手順（診療所が紙で診察し、あとで突合する方法）、ホストされたシステムが故障したときに各サプライヤーへエスカレーションする既知の経路、そしてそれらのサプライヤーが実際にどのSLAを負っているかの明確さです。スタートアップ段階を過ぎた小規模の独立したヘルステックのサプライヤーは、鏡像に直面します。自分に依存する実際の顧客がいながら、運用の体制は薄く、資金が乏しくても、信頼できるサポート時間とインシデント対応を提供しなければなりません。注意義務は大きなトラストと同じですが、資源は違うため、規律は、ITILの完全性より、安全に関わる基本を、容赦なく優先することです。

大企業#

NHSトラストや大手サプライヤーは、サービスマネジメントを、最も完全な形で運営します。正式なサービスデスク、ITILに沿ったインシデント/問題/変更のプラクティス、変更諮問委員会、重大インシデントと事業継続の計画、そしてしばしば24時間365日の運用センター。特徴的な課題は、構成の記録が弱く、パッチの当たっていないシステムと、不明確な所有を抱える、広がったレガシー環境であり、これがWannaCryを危機に変えた条件です。典型的な失敗は、職員が迂回するほど重い変更プロセスと、次の構築の資金を出すために、永久に飢えさせられる「運用」です。大企業には、観測可能性、持続可能なオンコール、検証された継続性を適切に行う資源があるため、課題は、実践を比例的に保ち、偽りのアシュアランスを与える書類の儀式ではなく、本当に臨床的に所有されたものにすることです。

政府#

国の機関は、何百万人に触れうるサービスを運営するため、停止は、議会と公的信頼への帰結を伴う国のインシデントであり、信頼性の目標は、公的な説明責任の問題です。政府のデリバリーは、ITSMを、稼働中のサービスが、ローンチ時に凍結されるのではなく、適切に運用され、監視され、反復されるという、GOV.UK Service Manualの期待と、記録の保存とサイバーセキュリティ（NCSC、DSPT）に関する法定の義務と結びつけます。支出管理と複数年の資金の取り決めが、「運用」の資金がどう見えるかを形づくり、規模そのものが、事業継続、調整された重大インシデント対応、数十年分の記録を持つレガシーな国のシステムの安全な廃止の利害を引き上げます。トレードオフは、アシュアランスとレジリエンス対速さとコストで、精査の下でオープンな場で解決されます。

よくある失敗パターン#

• 運用に壁越しに投げる。 構築チームが、それが作られるのを見ていない運用チームにサービスを引き渡し、知識、所有、安全がギャップにこぼれ落ちる。対策：「作った者が運用する」、または保証期間と共有のオンコールを伴う意図的な移行。
• 孤児になった稼働中のサービス。 プロジェクトが終わり、チームが解散し、運用の資金が蒸発する。サービスは腐り、パッチが当たらず、臨床とサイバーのリスクを静かに蓄積する。対策：運用寿命にわたる、名前付きのサービス所有者と、保護された運用予算。
• サービスではなく、サーバーを監視する。 すべてが「緑」でも、臨床家は古い、あるいは欠けたデータを見ている。対策：ユーザーと臨床家の体験を反映するSLIと、重要な症状でのアラート。
• テストされていない継続性の計画。 臨床のダウンタイム手順は紙の上にあるが、一度もリハーサルされたことがなく、当日に失敗する。対策：重大インシデントとダウンタイムの計画を定期的に演習し、壊れたものを直す。
• 非難に駆られたインシデントのレビュー。 落ち度探しが報告を地下に潜らせ、害を繰り返す。対策：追跡される対応を伴う、非難のない、システムとしてのインシデント後の学び。
• 変更プロセスの芝居。 チームが迂回するほど重い、あるいはリスクの高い変更が確認なしに出荷されるほど軽い変更委員会。対策：適切な規模にする。標準の変更は事前承認し、本当にリスクの高いものにのみレビューを適用する。
• 構成の記録がない。 インシデントの最中に「この変更は何に影響するか」に誰も答えられない。対策：所有者と依存関係を備えた、CMDBまたは同等のものを維持する。

成熟度モデル#

チェックリスト#

• すべての稼働中のサービスに、名前のある所有者と、運用寿命にわたる保護された運用予算がある。
• 各サービスを運用するチームが、それがどう作られたかを理解している（あるいは保証と共有のオンコールを伴う、文書化された移行がある）。
• SLIとSLOが定義され、臨床システムの目標は臨床家とともに設定され、外部のSLAは社内のSLOより緩い。
• 観測可能性（ログ、メトリクス、トレース）と症状ベースのアラートが、サーバーの健全性だけでなく、臨床家とユーザーの体験を反映している。
• インシデント管理に、重大度のレベル、対応の目標、インシデント指揮官の役割、対応の間の唯一の情報源がある。
• 問題管理が根本原因を直し、インシデント後のレビューが非難なく行われ、その対応がクローズまで追跡される。
• 変更管理が適切な規模である：標準の変更は事前承認・自動化され、リスクの高いものだけが臨床の入力を伴ってレビューされる。
• 事業継続と臨床のダウンタイムの手順が書かれ、ハザードログに結びつけられ、少なくとも年に一度リハーサルされている。
• オンコールの当番表に十分な人員が配置され、人道的で、公正に報酬が払われ、サービスデスクが実際の24時間365日の需要に見合う資源を持つ。
• 構成の記録（CMDBまたは同等のもの）が、部品、依存関係、バージョン、所有者を一覧にし、セキュリティパッチを支えている。
• 廃止の計画が、保存に関する法律の下でのデータの移行/アーカイブ、ユーザーの振り向け、安全と監査の記録の保全を網羅している。

主要な情報源#

• ITIL 4 — サービスバリューシステムと管理のプラクティス（インシデント、問題、変更、サービスデスク、サービスレベル管理）— PeopleCert / AXELOS。
• Google — Site Reliability EngineeringとThe Site Reliability Workbook（SLI、SLO、エラーバジェット、オンコール、非難のないポストモーテム）。
• GOV.UK Service Manual — 稼働中のサービスの運用と反復、サービスの状況の監視、ローンチ後のサービスの維持。
• NHS England — 臨床リスクマネジメント標準DCB0129/DCB0160と、システムのダウンタイムを臨床上のハザードとして扱うこと（トピック1.6参照）。
• NHS England / NCSC — サイバーセキュリティ運用、Data Security and Protection Toolkit (DSPT)、2017年のWannaCryインシデントからの教訓（トピック1.7参照）。
• ISO/IEC 20000（ITサービスマネジメント）とISO 22301（事業継続マネジメントシステム）。
• DevOps Research and Assessment (DORA) — デリバリーと運用の実績を結びつけるケイパビリティ（監視、変更、信頼性）。
• リーダーシップへの運用と信頼性の報告のためのOKRとKPI（トピック10.0 — Objectives & Key Results (OKRs)参照）。

参考文献#

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/