サイト信頼性エンジニアリングと DevOps の関係については、よく寄せられる一連の質問があります。たとえば、どのような点が同じでしょうか。 これらはどのように違うのでしょうか。 組織内で両方を使用することはできますか、などです。 この記事では、この関係について理解を深めるために、SRE および DevOps コミュニティによって提供されている回答の一部を共有します。
どのような点が同じか
SRE と DevOps は両方とも、次のような課題に対応するために作成および開発された最新の運用プラクティスです。
- 運用環境と開発プロセスの複雑さの拡大
- これらの環境の継続的な機能に対するビジネス依存度が増加
- これらの環境の規模に比例して要員を拡張できない
- 運用上の安定性を維持した状態での、より迅速な移行の必要性
どちらの運用プラクティスでも、監視または観測、自動化、ドキュメント化、共同作業ソフトウェア開発ツールなど、これらの課題を扱う重要な主題に対応することを重視しています。
SRE と DevOps 間では、ツールと作業分野がかなり重複しています。 『The Site Reliability Workbook (サイト信頼性のワークブック)』に記載されているように、"SRE では DevOps と同じ正当性を信じていますが、その根拠はやや異なっています"。
3 つの異なる方法で 2 つの運用プラクティスを比較する
SRE と DevOps の類似点は明白です。 本当に興味深いのは、両者の相違点です。 ここでは、この質問に少し違った角度で答える方法として、次の 3 つの方法で両者の関係性を考えていきます。 これらの回答に同意できないことがあるかもしれませんが、それぞれ、有意義な議論の出発点を提供しています。
"クラス SRE ではインターフェイス DevOps を実装している"
リソース ブックの一覧に示されている『The Site Reliability Workbook (サイトの信頼性ワークブック)』では、最初の章で SRE と DevOps について議論しています。 その章では、"class SRE implements interface DevOps (クラス SRE ではインターフェイス DevOps を実装している)" というフレーズが、サブタイトルとして使用されています。 これは、(開発者を対象としたフレーズを使用して) SRE を DevOps 理念の具体的な実装と見なせることを示唆しています。 章の中で指摘されているように、運用プラクティスについては SRE ではかなり踏み込んで規定していますが、「DevOps では、詳細なレベルで運用を実践する方法に対しては、どちらかと言えば消極的です」。 そのため、両者の関係についての質問に対して考えられる 1 つの回答は、SRE は想定される多数の DevOps 実装の 1 つと見なすことができるということです。
SRE にとっての信頼性は DevOps にとってのデリバリー
SRE と DevOps の両者に対しては複数の定義が存在するため、この比較はやや曖昧ではありますが、それでも役立つ可能性があります。 まず、「それぞれの運用プラクティスを、その主要な関心を反映した 1、2 語程度で要約しなければならないとしたら、何になりますか」という質問から始めます。
SRE のこの定義を、サイト信頼性エンジニアリング ハブから使用した場合:
サイト信頼性エンジニアリングとは、組織がシステム、サービス、および製品に対して適切なレベルの信頼性を持続的に達成できるようにすることを目的としたエンジニアリング分野です。
したがって、SRE を一言で言うなら "信頼性" でしょう。 名称のちょうど真ん中にこの言葉があるので、この主張に対しては一定の確証も得られます。
DevOps のこの定義を、Azure DevOps リソース センターから使用した場合:
DevOps とは、エンド ユーザーに対する価値の継続的デリバリーを可能にするための、人、プロセス、および製品の結合です。
したがって、DevOps に対する同等の要約は、"デリバリー" になります。
このように、"SRE にとっての信頼性は DevOps にとってのデリバリーです"。
関心の方向性
この回答は、リソース ブックの一覧に示されている『Seeking SRE (SRE の探求)』へのトーマス・リモンチェリ氏による寄稿から引用され、少しわかりやすく言い換えられています。 同氏は、「DevOps の技術者は、状況に応じて実稼働環境の運用責任を伴うソフトウェア開発ライフサイクル パイプラインを大きく重視しているが、SRE では、状況に応じて SDLC パイプラインの責任を伴う実稼働環境の運用を重視している」と記しています。
しかし、さらに重要なのは、同氏が、一方はソフトウェア開発プロセスを始点とし、他方は実稼働環境の運用作業を始点とする図を作成していることです。 2 つは、開発者からコードを取得するために構築された通常のパイプラインで結ばれており、必要なテスト数や段階を通して改善が行われた後、実稼働環境へそのコードが移動されます。
リモンチェリ氏は、「DevOps の技術者は、開発環境から開始して、実稼働環境へ向けて手順を自動化する」と記しています。 それが完了すると、彼らはボトルネックの最適化に戻ります。
一方、SRE では実稼働環境での運用を重視しており、最終結果を向上させる手段として、パイプラインを深く掘り下げています (基本的には、逆方向の対応になっています)。
この SRE と DevOps が重視している方向性の違いによって、両者を区別することができます。
同じ組織内での共存
最後に取り上げる質問は、「SRE および DevOps の両方を同じ組織内で使用できるか」という点です。
この質問に対する答えは、明確に「はい」になります。
前の各回答によって、2 つの運用プラクティスが重複している点、また、両者が明確に補完できる点について、一定の見解を示せていると思います。 DevOps プラクティスが確立されている組織では、SRE に関する職種やチームを作る取り組みを行わなくても、小規模での SRE プラクティス (SLI や SLO を試してみるなど) を試験的に取り入れることができます。 これは、非常に一般的な SRE 導入のパターンです。
次のステップ
サイト信頼性エンジニアリングまたは DevOps について、さらに詳しく知りたい方は、 サイト信頼性エンジニアリング ハブおよび Azure DevOps リソース センターに関するページをご覧ください。