DevOpsとITIL 5が融合し、スケーラブルなエンタープライズ運用を実現する
企業がサービス品質の制御を失うことなく、デジタル製品を迅速にリリースするにはどうすればよいでしょうか？
その答えは、チームの働き方の変革から始まります。DevOpsは、共有所有権、自動化、そして迅速なフィードバックを通じて、開発と運用をつなぎます。ITIL 5は、デジタル製品やサービスを全ライフサイクルを通じて管理するためのより広範な構造を追加します。
ITIL 5は、デジタル製品およびサービス管理により強い焦点を当てています。それは、製品の作業、納品、運用、サポート、ガバナンス、改善を1つのシステムで結びつけます。DevOpsは、このシステムを動かすための作業習慣と技術的なフローを提供します。
その結果、アイデアから信頼性の高いユーザー体験への道筋が明確になります。
ハンドオフ（引き渡し）の問題
多くの企業では、まだ仕事を別々の段階に分けています。プロダクトチームは要件を定義します。開発者はコードを書きます。運用チームはシステムの稼働を保ちます。サポートチームはユーザーの問題に対応します。
各役割には正当な目的があります。問題は、共有される指標や共有される文脈なしに、仕事が1つのグループから別のグループへと渡されるときに始まります。
プロダクトチームが新機能のリクエストを行うことがあります。開発者が指定通りにそれを納品したとしても、運用チームはその機能が負荷やサポート上のリスクを生み出すことに気づくかもしれません。ユーザーは最終結果を1つのサービスとして体験しますが、会社側はいくつかの非接続されたタスクとしてそれを管理しています。
これは遅延と手戻りを作り出します。また、技術的な作業とビジネスバリューとの関連性を隠してしまうという問題もあります。
DevOpsは、開発と運用を同じ納品フローに組み込むことで、このギャップを縮小します。ITIL 5は、そのフローに管理構造を与えます。これにより、プロダクトチームは作業を別の技術キューへ渡すのではなく、同じシステムに参加することができます。
主要な質問は、「チームはタスクを完了したか？」から「ユーザーにとってサービスは改善されたか？」へと変化します。
アイデアからサービスまでの単一バリューストリーム
バリューストリームとは、仕事が必要な状態から有用な結果へと移動する方法を記述したものです。デジタル運用において、その経路には発見、設計、構築、テスト、リリース、サポート、改善が含まれる場合があります。
DevOpsは、自動化によってこれらのステップをつなぎます。継続的インテグレーションパイプラインは、コードが変更される際にチェックを行います。自動テストは欠陥を早期に見つけます。セキュリティチェックは、同じワークフロー内で実行されます。納品ツールは承認された変更を制御された環境へと移動させます。
これはガバナンスを排除するものではありません。ガバナンスをプロセス内部へと移動させるのです。
リリースには、リスク、サービスへの影響、またはテストからの証拠に基づいた承認が必要となる場合があります。低リスクの変更は、単純な自動パスを通る可能性があります。高リスクの変更は、より深いレビューを必要とするかもしれません。ルールは明確です。なぜなら、納品システムがその決定を記録しているからです。
ITIL 5は、このフローの目的を定義するのに役立ちます。その指針となる原則は、仕事をバリューに集中させます。ガバナンスは境界を設定します。バリューチェーンは、デジタルサービスを作成し、提供し、サポートする活動を結びつけます。継続的改善は、運用からのフィードバックを次の変更セットに変換します。
この構造は、AI対応の製品にとって重要です。新しいレコメンデーションモデル、検索機能、または自動化ルールは、ユーザーの行動やシステムの需要を変更する可能性があります。リリースプロセスは、パフォーマンス、セキュリティ、信頼性、そしてユーザー体験を同時に考慮に入れなければなりません。
信頼性がプロダクト作業の一部になる
信頼性はしばしば運用部門に委ねられます。それは弱いフィードバックループを生み出します。開発者は、レポートが作成されてからでないとインシデントを目にする機会がないかもしれません。プロダクトチームは、遅れたビジネスレビューを通じてのみサービス上の問題を目にするかもしれません。
サイトリライアビリティエンジニアリング（SRE）は、信頼性を測定可能にすることで、このパターンを変えます。サービスは、可用性、検索速度、再生成功率、あるいはレコメンデーションの鮮度に対するターゲットを使用できます。これらのターゲットは、サービスレベルオブジェクティブ（SLO）と呼ばれます。
SLOは、広範な懸念事項を実用的なシグナルに変えます。チームは、サービスが定義されたユーザーニーズを満たしているかどうかを尋ねることができます。また、納品の速度とサービスのリスクを比較することもできます。
エラーバジェットはこの意思決定を支えます。エラーバジェットは、SLOによって許容される不信頼性の量を表します。サービスがターゲット内でパフォーマンスを発揮している場合、チームは変更をリリースする余地を持ちます。障害がこの許容量を消費した場合、安定性への取り組みが優先されます。
これは、プロダクト、エンジニアリング、運用のための共通言語を作り出します。プロダクトの意思決定にはサービスへの影響が含まれ、エンジニアリングの意思決定にはレジリエンスが含まれ、運用データは将来の設計を形作ります。
オブザーバビリティ（観測可能性）はこのループを強化します。ログ、メトリクス、トレース、そしてユーザー体験のシグナルは、リリース後に何が起きたかを示します。これらのシグナルは、低速なリクエスト、失敗したトランザクション、不適切なモデルの応答、あるいは特定の顧客グループに限定された問題を明らかにすることができます。
その後、自動化が安全なアクションをサポートします。システムはリソースのスケーリング、トラフィックのリダイレクト、フィーチャーフラグの無効化、あるいはリリースのロールバックを行うことができます。これらのアクションには明確なルールとテストが必要です。境界のない自動化は、障害をより速く拡散させる可能性があります。
目標は制御された学習です。各リリースは、実環境下でサービスがどのように振る舞うかについての証拠を提供します。その証拠が、次のプロダクトおよびエンジニアリングの意思決定にフィードバックされます。
小さな例
音楽サービスに新しいレコメンデーションモデルを追加することを考えてみましょう。
プロダクトチームはより良い発見（ディスカバリー）を望みます。エンジニアはモデルを構築し、リリースの準備を整えます。運用チームは、それを実行するために必要な計算リソースとモニタリングを特定します。
分離されたプロセスでは、モデルはすべてのユーザーに対して同時に起動する可能性があります。すると、サポートチケットや突然のパフォーマンス低下を通じて問題が表面化します。
統合されたプロセスでは、モデルはまず本番に近い環境で実行されます。自動チェックがそのコード、セキュリティ、レイテンシ、リソース使用率をレビューします。フィーチャーフラグによって限られたグループにリリースされます。オブザーバビリティは、レコメンデーションの鮮度、リクエスト速度、エラーレート、そしてサービスの可用性を追跡します。
チームはまた、レスポンスパスを定義します。もしモデルが低速なリクエストや不良なサービスシグナルを引き起こした場合、フラグはオフになったり、リリースがロールバックされたりします。既存のサービスは稼働し続けます。
ITIL 5は管理フレームを提供します。この変更はプロダクトゴールをサポートします。ガバナンスはリリースコントロールを設定します。運用はライブサービスを支援します。継続的改善は、結果を用いて次の変更を形作ります。
DevOpsは納品のメカニクスを提供します。パイプライン、テスト、フィーチャーフラグ、モニタリング、そしてロールバックが作業をつなぎます。
単一のチームが、全体の結果を一人で所有するわけではありません。システムが所有します。
このパターンがもたらす変化
DevOpsとITIL 5の融合は、すべてのプロセスが自動化されることを意味しません。それは、チームが仕事を1つの接続されたバリューストリームとして管理することを意味します。
これはいくつかの日常的な習慣を変えます：
- プロダクトチームは、計画段階で信頼性とサポートのニーズを含めます。
- 開発者は、本番環境のシグナルを設計入力として扱います。
- 運用チームは、リリースの決定が固定される前に早期に参加します。
- ガバナンスは、デフォルトでの遅い承認ではなく、リスクと証拠を使用します。
- サポートデータは、サービスを開発・管理するチームに到達します。
- 改善作業は、ライブシステムの動作に従います。
このパターンはまた、弱点を浮き彫りにします。手動のハンドオフが各リリースを停止する場合でも、パイプラインは「継続的」と呼ばれることがあります。モニタリングダッシュボードはインフラストラクチャの健全性を表示していても、ユーザー体験を見逃すことがあります。インシデントプロセスは、失敗を引き起こした設計上の選択に対処せずにサービスを復旧させることがあります。
有用なテストはシンプルです。1つの変更を、その元の必要性から本番環境での結果まで追跡します。情報が流れなくなる場所をメモしてください。その地点は、プロダクト、DevOps、サービス管理の間により良い統合が必要な場所を示していることが多いです。
実践的な教訓は、1つのハンドオフを選び、共有証拠でそれを接続することです。プロダクト要件にSLOを含めることができます。リリースパイプラインにサポートチェックを含めることができます。インシデントレビューにより、明確なオーナーを持つプロダクトバックログアイテムを作成することができます。
その小さな接続が、バリューストリームを可視化します。それはまた、チームが学ぶための共通の場を与えてくれます。
EuroOp LLCはこれを中核的な応用研究開発（R&D）のパターンと見なしています：ビルド、オペレーション、改善が1つのフィードバックシステムで行われるとき、信頼性の高いデジタル製品が生まれます。EuroOp Insightsは、各号で同じ約束を運びます：1つの応用R&Dパターンと、EuroOpのプロダッドの背後にあるパイプラインからの1つの実践的な教訓。