SRE と DevOps は味方でしょうか、それとも敵でしょうか?未来をリードするのは誰でしょうか？

[[278068]]

序文

サイト信頼性エンジニアリング (SRE) と DevOps は現在非常に人気のある開発および運用文化であり、非常に類似しています。 SRE とは何ですか? DevOps とどのように関係するのでしょうか?この記事では、両者の類似点と相違点について簡単に説明します。

SREの背景

開発中、Google は運用・保守担当者と開発者の間で目標が相反するという問題にも直面しました。開発者は新しい機能を作成し、それを本番環境に導入することに注力し、運用および保守担当者は本番環境の安定性を確保することに努めました。 2つの部門間の対立を緩和するために、Googleのエンジニアリング担当副社長ベン・トレイナー氏は新たな解決策を考案した。採用および社内異動後、R&D のバックグラウンドを持つソフトウェア エンジニアは、システム管理者チームまたは運用チームに独立して所属することはなくなります。代わりに、システム運用を維持し、従来のモデルにおける手動操作を置き換えてソリューションを自動化するためのソフトウェア システムを独自に設計および作成します。

サイト信頼性エンジニアリング (SRE) という役職が誕生しました。 SRE エンジニアは、本番環境の安定性に責任を持ちますが、新機能や運用の改善にも取り組みます。 Google は、SRE チームは 50% のソフトウェア エンジニアと 50% のシステム管理者で構成する必要があると考えます。ソフトウェア エンジニアは、従来は手動で解決していた問題をソフトウェアで実装し、開発者と簡単に統合して、コード品質の向上や自動テストなどを促進します。チームの目標は、Google の運用環境サービスがより安定して堅牢かつ確実に実行されるようにすることです。

DevOps と SRE の違い

SRE 対 DevOps

DevOps の概念は、開発と運用を組み合わせ、システムの動作を定義し、2 つのチーム間の「ギャップ」を埋めるために何を行う必要があるかを理解することです。このコンセプトの背後にある理論は、2 つのチームを 1 つにするために何が必要かというものです。しかし、SRE では「どのように」それを実行するかについて説明します。これは、適切な作業方法やツールなどを使用することで、理論的な部分を効率的なワークフローに拡張することです。また、全員の間で責任を共有し、全員が同じ目標とビジョンを持って同じ方向を向くことも重要です。

DevOps の 5 つの原則を通して、DevOps と SRE の違いを比較してみましょう。

部門間のサイロ化を減らす

大企業は通常、複雑な組織構造を持っています。多くのチームは独立して作業し、独自の製品をリリースし、社内の他の部門とコミュニケーションをとりません。その結果、各部門はお互いを十分に理解できず、全体の状況をコントロールできなくなります。

DevOps の役割は、こうした隔たりを減らし、組織内に会社の他の部分と連携していないチームが存在しないようにすることです。彼らはチームを最小限に抑え、共通のビジョンを持つグループに橋渡しします。

SRE はもはや、会社内にどれだけの溝があるかということではなく、全員を議論に参加させる方法についてです。これは、企業のミドルオフィスなど、会社全体で同じツールとテクノロジーを使用することで行われます。

失敗の受容

SRE 障害識別子

DevOps の概念は、障害が発生する前に処理して対応することですが、現実は常に変化しており、障害を完全に回避することはできません。 DevOps は、失敗を避けられない出来事として受け入れ、事後検証を通じて経験を要約することで、チームの学習と成長を支援します。

SRE の観点から見ると、障害は避けられませんが、インシデントと新しいバージョンの関係のバランスをとる公式を開発することで、この目標を達成できます。言い換えれば、SRE は、たとえ失敗が学習と成長につながる経験であったとしても、失敗や不具合が多すぎないようにしたいと考えています。

SRE は、サービス レベル インジケーター (SLI) とサービス レベル目標 (SLO) という 2 つの主要な識別子を使用してこの式を測定します。 SLI は、リクエストのレイテンシ、1 秒あたりのリクエストのスループット、リクエストあたりの失敗数など、時間の経過とともに変化するメトリックです。これらは多くの場合、時間の経過とともに集計され、しきい値に従って比率、平均、またはパーセンタイルに変換されます。 SLO は、このしきい値、パーセンテージ、または一定期間 (「過去 30 日間」や「今四半期」など) にわたる SLI の累積的な成功の目標を表す数値から導出されます。

Google では、SLO と、サービス プロバイダがユーザーに提供する信頼性の保証であるサービス レベル契約 (SLA) を区別しています。 SLA 内の可用性 SLO は通常、内部可用性 SLO よりも緩やかです。

段階的な改革の実施

企業は、製品を頻繁にリリースし、継続的に製品を更新し、チームメンバーが新しいテクノロジーに継続的に注目できるようにしたいと考えています。

DevOps と SRE はどちらもこの目標を目指していますが、段階的な方法でアプローチします。 DevOps と SRE はどちらも迅速な対応を望んでいますが、Google は、SRE では迅速な対応を行う際に障害コストの削減を重視していると指摘しています。

ツールと自動化

責任が異なると、2 つの職位の作業内容も異なり、その結果、使用するツールも若干異なります。

DevOpsの業務内容は主に開発連携を行うことです。 DevOps チームは通常、開発ツール、バージョン管理ツール、CI 継続的デリバリー ツール、CD 継続的リリース ツール、アラーム ツール、トラブルシューティングを含む一連のツール チェーンを提供します。

SRE チームは、特定のビジネスに関係する変更、障害、パフォーマンス、容量関連の問題についてより懸念しています。出力ツール チェーンには、容量測定ツール、ログ記録ツール、トレース呼び出しリンク追跡ツール、メトリック パフォーマンス測定ツール、監視アラーム ツールなどが含まれます。

しかし、目的は同じで、手動操作を排除することで開発者とオペレーターに価値を提供することです。

成果指標

DevOps チームと SRE チームの両方が、正しい方向に進んでいることを確認する必要があります。 DevOps メトリクスは自動化とプロジェクト配信のスピードに重点を置く傾向があり、SRE メトリクスは信頼性と安定性に重点を置く傾向があります。

SRE のキーワードは「高スケーラビリティ」と「高可用性」です。高いスケーラビリティとは、サービス利用者数が急増した場合でも、システム構成を調整したりマシン自体の性能を高めたりすることなく、インスタンス数を増やすだけでアプリケーションシステムとそれを支えるサービス（サーバリソース、ネットワークシステム、データベースリソース）を拡張できることを意味します。高可用性とは、アプリケーション サービス、ゲートウェイ、データベース、その他のシステムに障害が発生するなど、アプリケーション アーキテクチャ内のいずれかのリンクが利用できなくなった場合でも、システム全体を短時間で復元し、サービスを再開できることを意味します。

DevOps と SRE の関係

DevOps と SRE はどちらも、改善するには変化が必要であるという哲学を受け入れています。

コラボレーションは DevOps 作業の中核であり、効果的な共有とコラボレーションは SRE がその役割を果たすために必要な条件です。 DevOps と同様に、SRE にも組織全体で共有される強力な価値観があり、チーム間の溝を解消しやすくなります。

本番サーバー障害が発生した場合、SRE と DevOps の両方が独自のインシデントレビューを実施して、無意味な議論や責任転嫁を排除し、知識を蓄積する必要があります。

ツールによって作業効率がある程度決まるため、適切なツールを使用することは非常に重要です。

結果指標は、DevOps と SRE がどのように機能するかの鍵となります。 SRE の場合、SLO (サービス品質目標) によってサービスを改善および最適化するかどうかが決まります。もちろん、メトリクスと、製品、インフラストラクチャ/SRE、ビジネス間のチーム間コラボレーションがなければ、SLO は存在できません。 DevOps では、結果測定動作は、プロセスの出力が何であるか、フィードバック サイクルの期間がどれくらいであるかなどを把握するためによく使用されます。

DevOps または SRE は全体的な行動であり、チーム全体の運営を改善するために特定の方法で協力するというビジョンがあります。

DevOps と SRE は、日常業務において非常に大きな重複部分があります。トルストイはこう言っています。「効果的な方法はすべて似ており、失敗した方法はすべて独自の方法で失敗する。」

結論は

IT 運用分野全体の多くの側面において、両者は多かれ少なかれ異なりますが、実際には、DevOps と SRE は実践と概念において非常に近いものです。どちらも、同様の責任を引き受けながら、開発者と運用スタッフを統合し、自動化と信頼性の実現に重点を置きます。これらのいずれかを実装するのは、より長いプロセスであり、すぐに解決できるものではありません。 DevOps はより広い範囲に焦点を当てているため、各ステップを特定のプロセスに標準化することは困難ですが、広い範囲に焦点を当てているからこそ、初期段階で遭遇する抵抗は小さくなる可能性があります。 SRE は、信頼性の目標を達成するために、他のチームと連携して適切な監視、インシデント対応、管理を提供しながら、技術とプロセスの責任に大部分の時間を費やします。

結局のところ、DevOps であれ SRE であれ、呼び方は何であれ、それらはすべて同じ目標とビジョン、つまり本番環境を改善することに直面しています。