ITIL、DevOps、SRE が組織でどのように連携するか

あなたの組織はどのタイプの「ショップ」であるかを誰かに尋ねられたら、ITIL、DevOps、または SRE であると自信を持って答えることができますか?

できる人もいるかもしれませんが、大企業の場合、特に SRE が DevOps の重要な実装になっているため、これらの運用モデルのいくつかを組み合わせることで答えが得られる可能性があります。 ITIL は、DevOps および SRE の原則と一緒に効果的に機能しますが、一見、それらは異なる種類のように見えます。

秘訣は、組織のさまざまな運用モデルやツールチェーンに関係なく、チーム間で可視性、コミュニケーション、コラボレーションを共有できるようにすることです。 これにより、それぞれの方法論のベスト プラクティスを使用しながら、異なるチームが足並みをそろえることができます。

ITILとは？ よくわからない場合は…

ITIL はInformation Technology Infrastructure Library の略で、情報技術のベスト プラクティスの単一ソースを作成するために開発された方法論です。 サラ・K・ホワイトとリン・グライナーによると:

「1980 年代に英国政府の中央コンピュータ通信庁 (CCTA) によって開発された ITIL は、最初は 30 冊以上の書籍で構成され、時間をかけて開発およびリリースされ、多くの情報源 (ベンダーのベスト世界中で行われています。」

ITIL は現在第 4 版に更新されており、そのアプローチは 9 冊の本に凝縮されています。 これらの本は現代の技術時代を反映していますが、依然として ITIL の元来の核となる理想に非常に重点を置いています。 これらの理想には、「プロセスの自動化、サービス管理の改善、IT 部門のビジネスへの統合」が含まれます。 ITIL は伝統的に非常にトップダウンで高度に構造化されたプロセス主導の方法論であり、今日でも最も採用されている IT フレームワークの 1 つです。

ITIL の主要なプラクティスには、サービス カタログと設計、監視とイベント管理、インシデントと問題の管理、リリース管理、構成管理などがあります。 これらのプラクティスはすべて運用モデルに関係なく適用されますが、アーキテクチャのニーズやワークフローが異なると、異なる形で現れる可能性があります。 これらのプラクティスは、DevOps または SRE ショップとして強く認識している組織にとっても価値があることがよくあります。

ITIL と ITSM の関係はどのようなものですか?

ITSM (情報技術セキュリティ管理) は、企業が IT サービスを管理する方法のプロセスです。 このプロセスは非常に顧客志向であり、通常は次の 5 つのステップが含まれます。

1. サービス戦略
2. サービスデザイン
3. サービス移行
4. サービス運営
5. 継続的なサービス改善

ITIL は、ITSM プラクティスを実装するためのフレームワークです。 このフレームワークは組織に中立であるため、IT 部門が注目する唯一の顧客が社内の顧客であっても、ほぼすべてのビジネスに適用できます。 ITIL と ITSM は非常に密接に関連しているため、多くの問題で ITIL と ITSM が連携していることは当然のことです。

itiltraining.com によると:

「継続的な改善に大きな重点が置かれています。 これには、プロセス、IT サービス、IT インフラストラクチャの継続的な測定と改善が含まれます。 そうすることで、効率、有効性、費用対効果が最大化されます。」

ITIL と DevOps の連携方法

ITIL プロセスに従うときは、IT を組織のビジネス目標に合わせることに重点が置かれます。 これは、組織全体のサイロを解体するという DevOps の哲学とうまく調和しています。 さらに、これらのサイロを解体することで、コミュニケーションのボトルネックを解消し、チームが顧客が求める機能をより迅速にリリースし、CAMS モデル (文化、自動化、測定、共有) をより厳密に順守できるようにします。 しかし、これを組織に適用すると、実際にはどのように見えるでしょうか?

いつどれを使う？

あなたの組織はおそらく、さまざまな状況で ITIL と DevOps に依存して、さまざまなシナリオで最も効率的なソリューションを考え出すでしょう。 たとえば、開発チームと運用チームの間で DevOps のベスト プラクティスを活用することは理にかなっており、ワークフロー、コード プッシュ、自動化、および監視について調整する必要があります。

ただし、営業と IT など、組織のさまざまな速度で実行されている可能性のある部門間で通信する場合は、ITIL プラクティスが役立つ場合があります。 以下のグラフは、2 つの方法論がさまざまな状況でどのように適用されるかを示すほんの一例です。

IT と組織の他の部分との間の連携

ITIL と DevOps のベスト プラクティスを組み合わせて採用した結果、組織全体の目標に対する整合性が向上します。 IT と組織の残りの部分が完全に独立したエンティティとして機能する場合、一方の側は常に働きすぎでサポートが不十分だと感じる可能性があります。 架空の組織の IT 統合への取り組みを描いた小説「The Phoenix Project」では、これが中心的な対立になります。

この本では、IT は R&D と販売イニシアチブの成功に部分的に責任を負っています。 研究開発では、在庫を補充し、タイムリーに新製品を市場に投入するために、正確なデータと在庫レポートが必要でした。 販売には、効果的な CRM、電話/ボイスメール、および MRP システムが必要でした。 そうしないと、顧客の注文を追加または変更することができず、顧客の健康を管理する方法がありませんでした。

部門間のコミュニケーションがなければ、これらの必要な変更を計画する方法はありませんでした。 代わりに、各部門は互いに不当な要求を行い、ボールが頻繁にドロップされ、会社の収益が大幅に減少しました。

この対立は、IT 部門が組織の他の部門と連携して連絡を取り合い、他の部門の責任者が IT イニシアチブに高レベルの賛同を示したときに解決されました。 サイロを解体して連携することで、これらの問題の多くが解決されました。

IT イニシアチブとビジネス イニシアチブのタイミングが非同期に見える場合があります。 ただし、ITIL と DevOps のベスト プラクティスを利用することで、組織はまとまりのあるタイムラインを作成できます。 以下は、組織全体を満足させるためにこれらのプロセスがどのように同時に機能するかを示すグラフです。

所有権の共有と継続的な改善

プロセスの改善に加えて、組織内で DevOps と ITIL フレームワークを連携させることは、別の重要なメリット、つまり考え方の変化にもつながります。 DevOps は、所有権の共有と継続的な改善を促進することで、ITIL フレームワークに新しいイノベーションをもたらします。

組織のサイロが最小限に抑えられると、組織の目標は個人の目標になります。 全員が同じチームのメンバーであり、同じ結果を目指しているため、ビジネスの成功と失敗の責任は誰にでもあります。 部署同士が対立することはもうありません。 継続的な改善は企業文化の一部となり、失敗は称賛され、学習の機会として認識されます。

ITIL と SRE の連携

DevOps と ITIL がどのように連携するかについて説明したので、今度は SRE と ITIL がどのように連携するかについて説明します。 SRE は DevOps の実装であるため、これらの調整の多くは似ています。 3 つの方法論すべてのベスト プラクティスを使用して、組織が最大の効率で機能するようにすることができます。 実際には、ITIL と SRE を組み合わせることで優れた組み合わせを実現できます。

最初の理由は単純です。すべての組織は顧客の満足を望んでおり、ITIL と SRE はさまざまな部門が連携してそれを実現するのに役立ちます。 ソフトウェアのライフサイクル全体に信頼性を組み込むことで、顧客の満足度を高めることができます。 7 つの指針となる原則を導入する ITIL の最新版では、SRE と ITIL はさらに緊密に連携しています。

ITIL 4 の 7 つの原則

以下に、ITIL 4 の 7 つの原則を示します。これらについて詳しく説明します。

1. 今いる場所から始める

SRE のベスト プラクティスの採用は万能ではなく、誰もがどこかから始めます。 最初の一歩を踏み出し、実装と反復を繰り返すことが最も重要です。

2. シンプルで実用的なものにする

シンプルさに関する Google SRE ブックの章では、次のように述べています。

「人生の他のほとんどすべてとは異なり、「退屈」は、ソフトウェアに関しては実際には肯定的な属性です! プログラムを自然発生的で興味深いものにしたくはありません。 スクリプトに固執し、ビジネス目標を予想通りに達成してもらいたいのです。」

ソフトウェアとビジネス オペレーションの両方をシンプルにすることで、コミュニケーションが合理化され、速度が向上し、信頼性が損なわれないようになります。 少ないほうがいいですね。

3. 最適化と自動化

SRE の目標の 1 つは、労力のかかるプロセスを自動化し、開発者が予定外の作業ではなくイノベーションに集中できるようにすることです。 これにより、ワークフローが最適化され、新機能をより早くリリースできるようになります。

4. フィードバックを繰り返しながら進行する

SRE は、最も重要でユーザー中心の指標に対してアラートを設定します。 それらが関連付けられているメトリック、アラート、および SLO はすべて、顧客のニーズを満たすために繰り返されます。

5. コラボレーションして認知度を高める

SRE は文化的に協力的です。 失敗から学ぶことを重視し、各チーム メンバーが組織にとって最善と考えていることを行っていることを信頼する、責められることのない職場文化に焦点を当てています。

6. 価値を重視する

顧客がいなければ、ソフトウェアの価値はありません。 ビジネス価値は、顧客が必要としているときに、製品から必要なものを手に入れたときに生み出されます。 SRE のベスト プラクティスは、製品が顧客に価値を提供するのに十分な信頼性があることを保証し、したがって組織に価値を提供します。

7. 総合的に考えて取り組む

サイロを解体し、全体的なレベルでスケーラビリティと信頼性に焦点を当てることで、SRE は組織の成熟に大きなメリットをもたらすことができます。 ビジネス全体の成功はすべてのチーム メンバーの手に委ねられており、SRE は、会社の製品、システム、および手順が、顧客の基準を満たすだけでなく、それを超えるのに十分な回復力を備えていることを確認するために働きます。

柔軟で迅速な変更管理

ITIL のベスト プラクティスの 1 つは、変更承認委員会 (CAB) によって監督される調整された変更管理です。 ただし、Mindbridge Kaimar Karu のパートナーは次のように述べています。

「CAB がすべての変更要求をレビューするのは効率的ではありません。また、一部の組織で 1 時間あたり数万回の展開にかかるコストがかかる場合は特に、常識的ではありません。 ただし、影響を受ける可能性があるためにビジネスの一部に相談する必要がある場合、CAB が未知のリスクの変更要求をレビューすることは非常に理にかなっています。」

SRE はこれに役立ち、その中核となる原則は、はるかに柔軟で迅速な変更管理を促進するのに役立ちます。 オンコール プラクティスにより、チームは本番環境のコードに対して 24 時間体制で責任を負うことができます。 ロールバックは、迅速な修正の一部として自動化できます。 インシデントの事後分析は、SLO などの重要な学習洞察を促進し、チームが重要なことを調整し、現代のサービス管理の爆発的な複雑さを切り抜けるのに役立ちます。

さらに、エラー バジェットは、新機能を出荷しても安全な時期に関する開発チームのガイドラインを作成します。 エラー バジェットに十分な余裕がある場合、変更は承認されますが、エラー バジェットが使い果たされているか、ほぼ枯渇している場合、変更は次のウィンドウまで延期されます。

この追加された柔軟性は、SRE リーダーシップの考え方にも影響を受けています。 コマンド アンド コントロールの哲学の代わりに、SRE は絶えず変化する環境における柔軟性の必要性を認識し、制御よりもコンテキストに重点を置いています。 これは、ビジネスに不可欠な機能を出荷する必要がある場合、出荷されることを意味します。

ITIL、DevOps、SRE のドリーム チーム

一部の組織は、これらの方法論の 1 つだけのコンテキストで運用されていますが、多くの組織では、ビジネスと IT の目標を調整して安全で信頼性の高いサービスを作成するには、3 つを組み合わせることが最も効率的な方法であることがわかっています。 以下は、各方法論の強みのグラフです。 それらは同じ原則に基づいており、同じ結果を達成しようとしている可能性がありますが、実際には方法論は異なり、非常に補完的です.

結論

チームにとって最も意味のあるプラクティスを特定し、試行錯誤を繰り返すことで、組織が最大の効率で運営されることを保証する究極の組み合わせを見つけることができます。

その他のコンテンツ:学習を続けます。 あなたの会社が非難の余地のない文化からどのように利益を得ることができるかを発見してください。