デジタルヘルスガイド

トピック3.6 — DevOpsとエンジニアリングの卓越性

一文で言うと： 臨床システムでは、自動化されたパイプライン、小さく元に戻せるリリース、Infrastructure as Code、観測可能性といった規律あるエンジニアリングが、変更をよりリスクの高いものではなくより安全なものにします。「どのようにソフトウェアを作り、運用するか」を、安全、公平性、公的信頼の関心事として扱うことが、成熟したデジタルヘルス組織の印です。

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

ソフトウェアをどうエンジニアリングし、運用するかは、それ自体が臨床安全の統制です。地域看護師が薬の変更を見られないとき、電子紹介が静かに失敗するとき、あるいは停止によって臨床家が共有ケア記録から締め出されるとき、害は抽象的な不便ではなく、治療の遅れ、見逃されたアレルギー、セーフガーディングの穴です。本トピックのエンジニアリングの実践は、必要な修正が本番に10分で届くか10週間かかるか、そして悪い変更がきれいに元に戻せるか、臨床家が壊れたシステムを何日も回避して働くことになるかを決めます。

規制された領域には、変更はリスクであり、最も安全なシステムは最も触らないシステムだという、根強く危険な神話があります。エビデンスは逆を指しています。めったに変更されないシステムは、パッチの当たっていない脆弱性、脆い手動のデプロイ手順、文書化されていない暗黙知を蓄積し、変更がついに避けられなくなったとき（セキュリティパッチ、規制の期限、サプライヤーの撤退）、それは、大きく、リスクが高く、よく理解されていない「ビッグバン」として届きます。小さな変更を頻繁に、自動化と素早いロールバックを伴ってデプロイする組織は、失敗がより少なく、そこからより速く回復します。医療・ケアでは、その差は患者安全で測られます。

エンジニアリングの卓越性は、公平性と公的信頼の問題でもあります。観測できないソフトウェアは、サービスが古い端末のユーザーや接続の悪い地域のユーザーに対して、より悪く機能していることを隠します。安全でないソフトウェアのサプライチェーンは、機密の患者情報をリスクにさらします（トピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティ参照）。そして、これは公費と公的なデータであるため、このセクターはますます、コードが、オープンで検査可能な標準、時には文字どおりオープンな場で作られることを期待しています。したがって、どう働くかは、私的なエンジニアリングの問題ではなく、患者、臨床家、国民に対して説明責任を負うものです。

中核概念#

DevOps。 DevOpsは、ソフトウェアを作る開発者と、それを運用する運用担当者の間の、従来の壁を取り払う文化と実践の集合です。別のチームにコードを「壁越しに投げる」代わりに、同じ人々が、設計から稼働中の運用まで、自動化と素早いフィードバックに支えられて、サービスの所有を共有します。ツールで可能になる、共有された責任、非難のない学習、小さなバッチという、主として働き方であり、購入するツールではありません。

継続的インテグレーションと継続的デリバリー（CI/CD）。 継続的インテグレーション（CI）は、すべての開発者が、小さな変更を頻繁に共有のメインブランチにマージし、それぞれが自動のビルドとテストの実行を起動して、問題が数分で表面化することを意味します。継続的デリバリー（CD）は、これを拡張して、ソフトウェアが常にリリース可能な状態にあり、自動化された再現可能なパイプラインを通じて本番にデプロイできるようにします。継続的デプロイは、さらに一歩進めて、パイプラインを通過したすべての変更を自動的にリリースします。テストは、パイプラインの関門の実質であり、トピック3.7 — テストと品質保証で詳しく扱います。

トランクベース開発と、小さく元に戻せるリリース。 トランクベース開発は、全員を、バージョン管理の単一のメインラインの近くで作業させ、乖離して痛みを伴ってマージされる長寿のブランチを抱えるのではなく、一日に何度も統合します。対になる規律は、小さく、頻繁で、独立して元に戻せる変更を出荷することです。小さな変更はレビューしやすく、テストしやすく、そして臨床システムでは決定的に重要なことに、何かがうまくいかなかったときに、きれいにロールバックしやすいのです。

Infrastructure as Code（IaC）。 サーバーを手作業で設定する代わりに、バージョン管理下に置かれた、機械可読なファイルでインフラを定義します。環境は、再現可能で、レビュー可能で、監査可能になります。同一に再構築でき、誰が何をなぜ変更したかを確認でき、テスト環境と本番環境が一致することを証明できます。これは、信頼できる環境の土台です（トピック4.0 — 技術アーキテクチャ、クラウド、レガシーシステム参照）。

プラットフォームエンジニアリングと開発者体験。 プラットフォームエンジニアリングは、デリバリーのチームが依存する、内部のツール、パイプライン、環境を、チームをユーザーとするプロダクトとして扱います。よく作られた社内プラットフォームは、チームに「舗装された道」、つまり安全な既定値、事前に承認されたパターン、ワンクリックのデプロイを与え、それぞれがコンプライアンスを作り直さなくても、素早くかつ安全に動けるようにします。良い開発者体験は甘やかしではなく、安全な道を、簡単な道にする方法です。

DORAの指標。 DevOps Research and Assessment（DORA）は、高い実績を上げるチームを区別する4つの指標を特定しました。デプロイ頻度（どれだけ頻繁にリリースするか）、変更のリードタイム（コミットから本番までの時間）、変更失敗率（変更の何割が問題を引き起こすか）、サービス復旧までの時間（どれだけ速く回復するか）。合わせると、速さと安定性が一緒に高まることがわかります。最も頻繁にデプロイするチームは、最も失敗が少なく、最も速く回復します。

「作った者が運用する」、SRE、観測可能性。 Amazonで広まった「作った者が運用する（you build it, you run it）」は、サービスを書くチームが、それを運用し、ポケベルを持ち、その失敗を感じることを意味し、エンジニアリングの選択と運用の現実の間のフィードバックのループを閉じます（トピック3.8 — サービスマネジメントとライブ運用参照）。サイト信頼性エンジニアリング（SRE）は、運用にエンジニアリングを適用する具体的な実装で、明示的な信頼性の目標とエラーバジェットを備えます。観測可能性、つまりシステムの内部状態を、その出力（メトリクス、ログ、トレース）から理解する能力は、患者や臨床家より先に、問題を検知し診断できるようにするものです。

安全なソフトウェアのサプライチェーン。 現代のソフトウェアは、多くのサードパーティの部品と依存関係から組み立てられます。サプライチェーン攻撃は、信頼された部品を悪用して、それに依存するすべてを危険にさらします。依存関係の管理、既知の脆弱性のスキャン、ソフトウェア部品表（SBOM）の維持は、任意のセキュリティの付加物ではなく、中核的なエンジニアリングの衛生管理です。

オープンな場でのコーディングとオープンソースソフトウェア。 GDS Service StandardとNHS Service Standardに表れている、英国政府の方針は、チームに、新しいソースコードを既定でオープンにし、オープン標準を使うよう求めています。公費で賄われる医療ソフトウェアでは、患者データと本物の機密情報を公開リポジトリから厳格に遠ざけることを条件に、これが精査、再利用、信頼を高めます。

ベストプラクティス#

  1. サービスを作る前に、CI/CDパイプラインを構築する。 最初の週から、自動化されたビルド、テスト、デプロイを確立し、すべての変更が、本番への同じ再現可能で監査可能な道を流れるようにします。パイプラインは、臨床安全、セキュリティ、アクセシビリティの関門が、自動チェックとして置かれる場所であり、正確に何がいつデプロイされたかの、文書化された改ざん検知可能な記録を与えます。規制されたシステムでは、この監査証跡は間接費ではなく、臨床安全性ケースのエビデンスです（トピック1.6 — 臨床安全とリスクマネジメント参照）。

  2. 小さく、頻繁で、元に戻せる変更をデプロイする。 時折の大きなリリースより、多くの小さなリリースを選び、あらゆる変更を、素早くロールバックまたは無効化できるように設計します。失敗する小さな変更は、理解しやすく元に戻しやすいものですが、失敗する四半期ごとの巨大なリリースは、百人の容疑者がいる臨床インシデントです。フィーチャーフラグ、カナリアリリース、ブルーグリーンデプロイといった技法によって、変更を徐々に晒し、即座に引き戻すことができ、デプロイを、恐れられる出来事から、日常的で波風の立たない行為へと変えます。

  3. 素早くきれいなロールバックを、第一級の安全の統制にする。 ロールバックを、避難訓練のように練習し、実際にどれだけかかるかを測定します。臨床システムで最も価値のある運用上の能力は、変更が害を引き起こしたときに、数分で既知の良好な状態に戻れることです。一度もテストされていないロールバックは、統制ではなく願いです。それが機能することを証明し、証明し続けてください。

  4. インフラと設定をコードとして扱う。 環境、ネットワーク、設定を宣言的に、バージョン管理下で定義し、自動的にプロビジョニングします。これにより、再現可能な環境、ピアレビューされた変更、障害や災害のあとの再構築が可能になります（トピック3.9 — 事業継続と災害復旧参照）。手作業で調整された「雪の結晶」のサーバーは、再現不可能で、文書化されておらず、「テストでは動いたが、本番では動かない」のありふれた原因です。

  5. DORAの指標を、人を順位づけるためではなく、誠実な対話のために使う。 デプロイ頻度、リードタイム、変更失敗率、復旧までの時間を、システムレベルの健全性のシグナルとして追跡し、それらがそろって「より速くより安全に」動くのを見ます。それらを、個人やチームの順位表にする誘惑に抵抗してください。DORA自身の著者たちが、これに警告しています。操作と隠れたリスクを生むからです。正しい使い方は診断です。上昇する変更失敗率は、取締役会が聞きたがるはずの、テストのカバー率やバッチサイズについての何かを告げています。

  6. 観測可能性に支えられた「作った者が運用する」を採用する。 デリバリーのチームに、本番でのサービスの本物の所有、オンコールの責任を含めて与え、設計の選択をする人々が、運用上の結果とともに生きるようにします。これを、観測可能性、つまりメトリクス、構造化されたログ、トレースと、ユーザーへの影響に結びついた意味のあるアラートで裏づけ、臨床家が報告する前に、チームが問題を見つけられるようにします。これは、エンジニアリングの選択を時間とともに改善するフィードバックのループを閉じ、サービスマネジメント（トピック3.8）に直結します。

  7. ソフトウェアのサプライチェーンを継続的に守る。 依存関係の一覧を維持し、既知の脆弱性を自動でスキャンし、バージョンを固定して検証し、次に広く公表される欠陥の数時間以内に「私たちは影響を受けているか」に答えられるよう、ソフトウェア部品表を保ちます。誰が、何が、本番にプッシュできるかを制限し、機密情報と認証情報を厳格に保護します（トピック4.2 — IDとアクセスの管理参照）。医療・ケアでは、侵害された依存関係は、機密の患者データへの経路であるため、サプライチェーンの衛生管理は、患者安全と情報ガバナンスの仕事です。

  8. エンジニアリングの標準を定めて徹底し、技術的負債を意図的に管理する。 コーディング規約、自動リンティング、コードレビュー、明確な「完了の定義」に合意し、品質を、後から検査して取り込むのではなく、組み込みます。技術的負債を明示的に追跡し、計画された仕事として返済してください。臨床システムで管理されない負債は、将来のあらゆる変更のコストとリスクを静かに引き上げるからです。標準は、次のエンジニアだけでなく、それを読む必要があるかもしれない監査人、安全責任者、オープンソースのレビュー担当者にとっても、コードを読み解けるものにします。

  9. 安全にできる場合は、オープンな場でコーディングする。 GDSとNHSの期待に従い、新しいソースコードを既定でオープンにし、オープン標準を再利用し、規律ある機密情報の管理を通じて、患者データと機密情報を公開リポジトリから厳格に遠ざけます。オープンなコードは、品質とセキュリティを改善する精査を招き、資金の乏しいシステム全体での再利用を可能にし、公費を使うソフトウェアが主張どおりに機能しているという、国民の信頼を築きます。コードが本当にオープンにできない場合（たとえば、一部のセキュリティに敏感な部品）は、習慣でクローズを既定にするのではなく、その理由を文書化してください。

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

  1. 臨床システムをより頻繁に変更することが、それらをより安全にすると、私たちは実際に信じているのか。そして、私たちの行動は、その信念と一致しているか。 この問いは、チームに、エビデンスと本能の間のギャップに向き合わせます。DORAのリサーチは、小さな変更を頻繁にデプロイするチームが、失敗率が低く、より速く回復することを明確に示していますが、多くの医療組織は、安全の名の下に、変更を、まれで厳重に関門の設けられたリリースにまとめ、意図せず、一つ一つをより大きくリスクの高いものにしています。変更諮問のプロセスが、本当にリスクを減らしている場所と、単に遅れを加え、チームをビッグバンのリリースへ向かわせている場所を議論してください。直近のインシデントを正直に見ます。それは、頻繁な小さな変更によって引き起こされたのか、それともまれな大きな変更と、パッチの当たっていない放置によって引き起こされたのか。ロールバックの能力が本物で、練習されているかを考えてください。頻繁な変更の論拠は、それを素早く元に戻せることに、完全に依存しているからです。良い答えはイデオロギー的ではなく、変更の頻度を上げ、同時に臨床安全とアシュアランスの義務を満たすことを可能にする、自動テスト、カナリアリリース、検証済みのロールバックといった具体的な統制を名指しします。

  2. 午前2時に、本番でサービスを運用しているのは誰か。そして、それは私たちのエンジニアリングの選択について何を語るか。 「作った者が運用する」は、支持するのは易しく、実践するのは難しいものです。この問いは、アーキテクチャとデリバリーの決定を下す人々が、運用上の結果を実際に感じているか、それとも痛みが、根本原因を直せない別の運用やサービスデスクのチームに押し付けられているかを浮かび上がらせます。観測可能性の状態を探ってください。共有ケア記録が遅くなったとき、それをダッシュボードやアラートで知るのか、怒った臨床家から知るのか。人的なコストも議論します。オンコールは、人道的で、資金が付き、分担されなければ、燃え尽きと定着の問題になり、人材が制約されているNHSでは、深刻なリスクです（トピック7.2 — 人員計画参照）。チームによる完全な所有と、一部の小規模な組織やサプライヤーは、物事を確実に運用するために共有のプラットフォームやマネージドサービスを本当に必要とするという現実の間に、本物のトレードオフがあります。強い答えは、運用上の責任を設計へと結びつけ直します。構築と運用の間のフィードバックのループが壊れている箇所を特定し、エンジニアリングの選択が、稼働中の運用の現実によって情報を与えられるよう、何を変えるかを挙げます。

  3. 私たちのコードとエンジニアリングの実践のどれだけが、公開されることに耐えられるか。そして、その答えは何を明らかにするか。 政府とNHSの方針は、チームに、既定でオープンな場でコーディングするよう求めており、この問いは、完全なオープンさがまだ不可能なところでも、そのレンズを診断として使います。リポジトリを公開するという見通しが不安を引き起こすなら、正確になぜかを問ってください。ハードコードされた機密情報か、埋め込まれた患者データか、テストがないことか、文書化されていない決定か、単に不慣れなのか。それぞれが、本物のエンジニアリングの品質または情報ガバナンスの問題であり、クローズしていることは、それを解決するのではなく隠すだけです。本物の制約、つまり一部のセキュリティに敏感なコードはクローズのままにすべきであり、機密情報の管理を正しく行うことが前提条件であることを、精査、資金の乏しいシステム全体での再利用、医療ソフトウェアの支出がどう使われているかへの国民の信頼という利益と比べて議論してください。攻撃者より先に、外部の目が欠陥を見つける、評判上と安全上の価値を考えます。良い誠実な答えは、説明可能で文書化された理由でクローズされているコードと、習慣や気恥ずかしさからクローズされているコードを区別し、どちらの場合も、根底にある品質と衛生の問題を直すことにコミットします。

  4. 明日の朝、共通の依存関係に広く公表された脆弱性が発表されたら、「私たちは影響を受けているか、どこでか」に答えるまでに、どれだけかかるか。 この問いは、サプライチェーンの衛生管理が、本物の能力なのか願望なのかを、Log4j型の欠陥のような、抽象的なリスクを当日の緊急事態に変える、セクター全体の出来事を使って試します。誠実な答えは、依存関係の正確な一覧とソフトウェア部品表を維持しているか、それとも、リポジトリをgrepで何日も探し、自分たち自身も知らないかもしれないサプライヤーに尋ねることになるかにかかっています。自分たちのソフトウェアのどれだけが、サードパーティとオープンソースの部品から組み立てられているか、その面のどれだけを、自動スキャンで、時折の手動チェックではなく、実際に監視しているかを探ってください。サードパーティとサプライヤーの側面も議論します。医療・ケアでは、環境の多くは作られたものではなく購入されたものであり、サプライヤーの製品の侵害された依存関係は、直接は制御できない機密の患者データへの経路だからです（トピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティ参照）。毒された部品が静かに出荷されないほど、パイプラインと本番へのプッシュの権限が厳格かを考えます。強い答えは、数時間で測られる現実的な回答までの時間を名指しし、それを可能にする具体的なツールと一覧を示し、特にサプライヤー提供のものなど、現在可視性が弱い環境の部分について率直です。

  5. 私たちのエンジニアリングの指標は真実を語っているか。それとも、いつの間にか、人々が上に向けて管理する業績目標になっていないか。 DORAの指標は、誠実なシステムレベルのシグナルとしてのみ有用であり、この問いは、自分たちのものが、組織の誘因との接触を生き延びたかを探ります。グッドハートの法則は容赦ありません。デプロイ頻度や変更失敗率が、チームが評価される数字になった瞬間、人々は根底の現実ではなく数字を最適化します。頻度を水増しするためにデプロイを分割したり、失敗としてカウントされないよう、インシデントを静かに再分類したり。誰がこれらの指標を見て、なぜか、テストのカバー率やバッチサイズへの投資を促す診断として使われているのか、操作と隠れたリスクを生む順位表として使われているのかを議論してください。裏側も考えます。何も測定せず逸話に頼るチームでは、上昇する失敗率が、臨床インシデントになるまで見えません。取締役会の、アシュアランスへの正当な必要性と、最も有用な指標は、チームが安心して誠実に報告できるものだという事実の間に、本物の緊張があります。良い答えは、測定がどう枠づけられガバナンスされて、人々に隠すことを報いるのではなく、不都合な真実を早期に表に出すかを説明します。

  6. 技術的負債を意図的に返済したのは、いつが最後か。そして、臨床システムでの「十分なエンジニアリング」が何を意味するかを、どう決めるか。 臨床システムの技術的負債は、整理整頓の問題ではなく、将来のあらゆる変更のコストとリスクを静かに引き上げるため、1日で済むはずの修正に2週間かかり、誰もリファクタリングしようとしないコードに触れることになります。この問いは、チームに、負債が、見える計画された仕事として管理されているのか、何かが壊れるまで単に蓄積されているのか、そしてコードレビュー、リンティング、明確な完了の定義といったエンジニアリングの標準が、本当に徹底されているのか、デリバリーのプレッシャーの下で免除されているのかに、向き合わせます。サービスがいま必要とする機能を出荷することと、あとで変更しても安全であり続けるよう、内部の品質を維持することの、本物のトレードオフを探ってください。医療・ケアではどちらも正当であり、そのバランスは、スローガンではなく判断だからです。標準が、次のエンジニアだけでなく、それを読む必要があるかもしれない監査人、臨床安全責任者、オープンソースのレビュー担当者にとって、コードをどう読み解けるものにするかを議論します。そもそも自分たちの負債が見えているかを考えてください。名前が付けられ追跡されているのか、どのモジュールが恐ろしいかについての暗黙知なのか。誠実な答えは、実際に行われた、具体的で資金の付いた是正を挙げ、規制されたシステムが求める品質の基準について、共有された説明可能な定義を示します。

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

ある統合ケアシステム（ICS）は、緊急のコミュニティケアの紹介を適切なチームに振り分ける、共有の「シングルポイントオブアクセス」サービスを運営しています。最初の2年間、サービスはおおよそ四半期に一度、手作業でデプロイされていました。開発者が、金曜の遅くに手動の手順のwikiページに従い、各リリースは、緊張した総力戦でした。紹介の振り分けのバグ、つまり複雑なニーズの紹介を、時々誤ったチームに送るバグが表面化したとき、修正は次のリリースの枠を待って6週間キューに置かれ、臨床家は手作業の回避策でリスクを管理しました。

新しいエンジニアリングのリードは、これを、単なる効率の問題ではなく、臨床安全の問題として組み直します。チームはCI/CDパイプラインを導入します。あらゆる変更は小さく、ピアレビューされ、自動的にビルドとテストが行われ、アクセシビリティとセキュリティのチェックと、臨床安全の承認ステップが、ハザードログに監査可能な記録を残すパイプラインの関門として符号化されます。インフラはコードに移され、テスト環境と本番環境がようやく一致します。デプロイは、四半期ごとから週に数回に移行し、最初はカナリアとして一つの地域にリリースされ、検証済みのロールバックで、5分未満で、最後の既知の良好な状態に戻ります。

6か月後、DORAの指標が、取締役会に平易な言葉で物語を語ります。修正のリードタイムは6週間から1日未満へ、デプロイ頻度は10倍に、変更失敗率は、変更が小さく観測可能になったため低下しました。微妙な振り分けの誤りが再発したとき、観測可能性のダッシュボードが数分で異常にフラグを立て、チームは、どの紹介も誤って振り分けられる前にロールバックし、翌朝修正を出荷し、非難のないインシデント後のレビューを記録します。チームはまた、機微でない振り分けルールエンジンを、NHS Service Standardの下でオープンソースとして公開し、隣のICSがそれを再利用します。システムをより頻繁に変更することが、明らかにそれをより安全にしたのです。

セクター別の視点#

スタートアップ#

デジタルヘルスのスタートアップは、交渉すべきレガシーな運用チームがなく、初日から現代的なエンジニアリングの実践を採用できます。トランクベース開発、CI/CD、Infrastructure as Codeは、小さなグリーンフィールドのチームでは、ほぼ無償の既定値であり、これは本物の強みです。リスクは、「素早く動け」が、医療が求める規律を静かに落とすことです。自動テスト、検証済みのロールバック、機密情報の管理、依存関係のスキャンは、まだ規制当局が見ていないときには、摩擦のように感じられます。創業者は、臨床安全とサプライチェーンの義務が、会社の規模にかかわらず課されること、そして一度の患者データの漏えいや管理されない依存関係が、会社を終わらせうることを認識しなければなりません。現実的な道は、マネージドクラウドのプラットフォームと、小さく意見の定まった「舗装された道」に頼り、まだ負担できないプラットフォームのグループを作らなくても、小さなチームが、既定で安全を得られるようにすることです。

小規模事業者#

確立した小規模の提供者やサプライヤー、つまり一般診療所、地域薬局、介護施設、単独拠点のクリニック、収益前の段階を過ぎた小規模なヘルステックのベンダーには、通常、実際の患者と実際の運営がありますが、パイプライン、観測可能性、オンコールを運営する専任のエンジニアリングやIT機能はありません。そうした組織の大半にとって、エンジニアリングの卓越性の現実的な形は、作るのではなく、うまく買うことです。自分たちが検査できる、DevOpsの規律を持つサプライヤーとマネージドプラットフォームを選び、自動更新、検証済みのバックアップ、依存関係のパッチ適用を、願いではなく契約上の期待にします。小規模なベンダーが実際にソフトウェアを書く場合、マネージドクラウドのプラットフォーム上の、よく設定された一つのCI/CDパイプラインと、自動の依存関係スキャン、リポジトリの外に置かれた機密情報が、無駄のないチームが維持できるコストで、安全上の利益の大半を届けます。罠は、小さな規模が、臨床安全、セキュリティ、情報ガバナンスの基準を下げると想定することです。そうではなく、パッチの当たっていない依存関係や、手作業でデプロイされてうまくいかなかった変更は、2人の臨床家の診療所でも、国の機関と同じように確実に患者を害します。現実的な目標は、優れたプラットフォームと優れたサプライヤーから引き継ぐ、既定での安全であり、診療所の限られた注意は、それらの既定値が実際に有効になっていることの検証に費やします。

大企業#

大規模なNHSトラストや大手のヘルステックのサプライヤーは、プラットフォームエンジニアリング、観測可能性、「作った者が運用する」を適切に行う資源を持っていますが、レガシーシステム、縦割りの開発・運用チーム、より遅い時代のために作られた変更諮問のプロセスに足を引っ張られます。特徴的な失敗は、リスクを制御しようとして、大きくまとめられたリリースを強い、恐れている頻繁な小さなものより危険なものにする、重い変更委員会です。機会は、コンプライアンス、セキュリティ、臨床安全の関門を、舗装された道に組み込む社内の開発者プラットフォームに投資し、数十のチームが、それぞれ交渉するのではなく、良い実践を引き継げるようにすることです。ここでの規模は、両刃の剣です。悪いデプロイの影響範囲は巨大であり、だからこそ、自動化、カナリアリリース、検証済みのロールバックは、任意ではなく不可欠です。

政府#

NHS Englandや地方分権された保健省のような国の機関は、他者が従う標準、つまりNHSとGDSのService Standard、支出管理、オープンな場でコーディングするという期待を定め、ソフトウェアがどう作られ運用されるかについて、議会と国民に説明責任を負います。そのエンジニアリングの選択は、システム全体に波及します。よく運営された国のプラットフォーム、公開されたオープンソースの部品、明確なサプライチェーンのガイダンスは、あらゆるトラストとサプライヤーの床を引き上げます。制約は現実のものです。複数年の資金、調達のルール、国のデータの規模と機微さそのものが、デプロイの頻度を、スタートアップよりも慎重なものにします。政府のレンズは、模範的な透明性と再利用を、国にとって重要なシステムのセキュリティと両立させ、何をオープンにし、何を守るかを意図的に決め、どちらの場合も、その推論を文書化しなければなりません。

よくある失敗パターン#

  • 「変更はリスク」による麻痺。 安全に感じるために、めったにデプロイせず、大きく、危険で、よく理解されていないリリースと、パッチの当たっていない放置を生む。対策：検証済みのロールバックを伴う、小さく、頻繁で、元に戻せる変更。
  • 開発と運用の間の壁。 開発者が、根本原因を直せない別の運用チームに「コードを壁越しに投げ」、誰もループ全体を所有しない。対策：共有された所有と、人道的に支えられた「作った者が運用する」。
  • 手動の雪の結晶のデプロイ。 リリースが一人の人とwikiページに依存し、環境がずれて、「テストでは動くが、本番で壊れる」が日常になる。対策：CI/CDとInfrastructure as Code。
  • 棒としての指標。 チームの順位づけに使われるDORAの数字が、操作と隠れたリスクを生む。対策：DORA自身のガイダンスに従い、システムレベルの診断として使う。
  • アラートに盲目な運用。 観測可能性がなく、患者と臨床家が最初に失敗に気づく。対策：メトリクス、ログ、トレース、ユーザーへの影響に基づくアラート。
  • 放置されたサプライチェーン。 パッチの当たっていない依存関係とスキャンされていない部品が、侵害になる。対策：継続的なスキャン、ソフトウェア部品表、保護されたパイプライン。
  • 偶発的な露出。 オープンな場でのコーディングが不注意に行われ、機密情報や患者データが漏れる。対策：クローズを既定にすることへの後退ではなく、厳格な機密情報の管理と公開前のスキャン。

成熟度モデル#

観点 着手 発展 標準化 管理 統合
ビルドとリリース 手動で、まれで、一人に依存するデプロイ 部分的な自動化。リリースはまだまとめられ、恐れられる 自動テストと関門を備えたCI/CDパイプライン デプロイ頻度とリードタイムが目標に対して追跡され、パイプラインの関門が保証・監査される 小さな変更の継続的デリバリー。デプロイは日常
変更とロールバック ロールバックの計画がなく、失敗が長引く ロールバックは紙の上にあるが、めったにテストされない 検証済みのロールバック。カナリア/フィーチャーフラグによるリリース ロールバック時間が測定・報告され、変更失敗率が閾値に対してガバナンスされる 実証され訓練された臨床安全の統制としての、素早いロールバック
インフラ 手作業で設定された雪の結晶のサーバー 一部のスクリプト。環境がずれる Infrastructure as Codeで、バージョン管理される ドリフトの検知とコンプライアンス・アズ・コードが徹底され、環境の同等性が積極的に監視される 完全に再現可能で、セルフサービスで、災害から復旧可能
運用と観測 運用チームが別。失敗はユーザーが見つける 基本的な監視。事後対応の火消し チームが自分のサービスを運用し、メトリクス、ログ、トレース、アラートがある SLOとエラーバジェットが追跡され、アラートがユーザーへの影響に合わせて調整され、目標に対してレビューされる SLOと非難のない学習を伴う「作った者が運用する」
サプライチェーンとオープンさ 依存関係が管理されず、すべてのコードがクローズ 時折の手動スキャン。オープンさは場当たり的 自動スキャンとSBOM。安全なところはオープン 脆弱性への露出が測定され、SLAに従って是正され、サプライチェーンの統制が保証される 継続的なサプライチェーンのアシュアランス。再利用を伴う、既定でのオープン

チェックリスト#

  • CI/CDパイプラインが、安全/セキュリティ/アクセシビリティの関門を符号化した、一つの監査可能な道を通じて、すべての変更をビルド、テスト、デプロイしている。
  • 変更が、小さく、頻繁で、独立して元に戻せる（フィーチャーフラグ、カナリアまたはブルーグリーンのリリース）。
  • 既知の良好な状態へのロールバックが、定期的にテストされ、文書化された短い時間で完了する。
  • インフラと設定が、バージョン管理されたコードとして定義され、テスト環境と本番環境が一致している。
  • 4つのDORA指標が、システムレベルのシグナルとして追跡され、個人やチームの順位づけには使われていない。
  • デリバリーのチームが本番で自分たちのサービスを所有し、人道的で資金の付いたオンコールと、意味のある観測可能性（メトリクス、ログ、トレース、アラート）がある。
  • 依存関係が一覧化され、自動でスキャンされ、ソフトウェア部品表があり、機密情報が保護されている。
  • エンジニアリングの標準、コードレビュー、完了の定義が合意され、技術的負債が追跡され、計画された仕事として返済されている。
  • 新しいソースコードが、安全なところでは既定でオープンで、患者データや機密情報が露出していないことを厳格に確認している。
  • エンジニアリングの実践が文書化され、新しいエンジニア、監査人、安全責任者が、何が動き、なぜかを理解できる（トピック10.3参照）。

主要な情報源#

  • Nicole Forsgren, Jez Humble & Gene Kim, Accelerate: The Science of Lean Software and Development and DevOps — DORAのリサーチと4つの主要な指標。
  • DORA (DevOps Research and Assessment) — 年次のState of DevOps報告書とケイパビリティ一覧 — dora.dev。
  • Jez Humble & David Farley, Continuous Delivery — デプロイのパイプラインとリリースの自動化。
  • Betsy Beyer et al. (eds.), Site Reliability Engineering — 本番システムの運用についてのGoogleのSREの本。
  • NHS England — NHS Service StandardとNHS Digital Service Manual（オープンな場でのコーディングとオープン標準を含む）。
  • GOV.UK Service Manual / Government Service Standard (GDS) — 「新しいソースコードをオープンにする」、継続的デリバリー、サービスの運用。
  • National Cyber Security Centre (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

GitHubでこのページを編集 — 本書が信頼できる唯一の情報源であり、このサイトはそれを表示するだけです。