コンテキストの SRE

• 10 分

SRE に関連するいくつかのプラクティスを学習する前に、前のユニットで学習したアイデアをいくつか状況に当てはめてみるとよいでしょう。 この短いユニットでは、SRE の背後にある歴史の一部と、慣れ親しんだその他の方法と SRE がどのように関係しているかについて学習します。 このような知識を得て準備しておくことで先々での理解がさらに深まります。これらのプラクティスは状況に当てはめた方がわかりやすいためです。 また、友人から「SRE はどのように違うのか」と聞かれたときに、答えられるようになります。

履歴

かなり簡略化された SRE の歴史は、2003 年の Google から始まります。 Ben Treynor (現在は Treynor Sloss) は Google の "制作チーム" (当時は 7 名のソフトウェア エンジニアのみ) のリーダーを任されました。 Treynor がこの概念を生み出し、「ソフトウェア エンジニアに運用機能の設計を依頼したときに起きること」と説明したのは有名です。 この歴史は、初めて SRE に接する運用担当者にとって、SRE が非常に "ソフトウェア エンジニアリング" 的であると感じられる理由をよく説明しているため、理解に役立ちます。 SRE は、基本的なツールとしてのコーディングおよびソース管理システムの重要度のような分野から、値とツールを採用しています。 Google SRE の初期および現在の実装は、O'Reilly から出版されている 2 冊の本にきちんと説明されています (概要のユニットを参照)。

Google に勤めていた人たちが会社を辞めたため (および Google の人たちが自分のプラクティスについて公に話すことが増えたため)、SRE は業界内の多くの組織に広がり始めました。 SRE が新しい組織に広がると、それらの組織が SRE の原則とプラクティスを採用して、それを自身のローカル カルチャに合うように調整しました。 この拡大プロセスにより、現場にさまざまな SRE の実装が数多く生み出されました。

DevOps と SRE

より広範な業界が、スケーリング、開発速度と運用上の安定性、およびサイト リライアビリティ エンジニアリングのムーブメントを生み出したその他のソフトウェア配信の問題に関する同様の課題に直面していました。 そうした問題点に対する Google の外部 (およびその当時の大企業数社) で並行して行われていた取り組みが、DevOps を生み出しました。

DevOps に関する多くの適切な情報については、DevOps リソース センターをご覧ください。

現場では、SRE と DevOps の違いは、いまだに重要な議論の的になっています。 大まかに合意されている相違点には、次のようなものがあります。

• SRE は、信頼性に重点を置いたエンジニアリング規範です。 DevOps は、個別の開発組織と運用組織の間に存在しやすいサイロを取り払おうという動きから生まれた文化的なムーブメントです。
• SRE は、"私はサイト信頼性エンジニア (SRE) です" というように、役職の名前として使用できますが、DevOps は使用できません。 厳密に言えば、"DevOps" を仕事にしている人はいません。
• SRE はより規範的になる傾向がありますが、DevOps は意図的にそうならないようにしています。 この点に関して最も近いのが、継続的インテグレーション/継続的配信とアジャイルの原則の極めて一般的な採用です。

DevOps と SRE の 2 つの操作プラクティスは、監視/可観測性と自動化への愛を相互に共有しています (おそらく異なる理由で)。 このような共通点が、DevOps プラクティスが既に存在している組織に SRE プラクティスと原則をインポートしやすい理由の 1 つです。 このプロセスは、注意と意図を持って行う必要があります。 また、突然切り替えなくて済むように、このプロセスは段階的に実装することが可能で、またそのようにすべきです。

まとめ

この短いユニットでは、SRE と DevOps を取り巻く状況を少し理解することを目指しました。 SRE と DevOps は、運用プラクティスにおける隣接する学派と考えるのが最適です。

SRE の背景の一部を簡単に確認したので、その中核となる原則の一部に移りましょう。

自分の知識をチェックする