SRE（サービス信頼性エンジニアリング）とDevOpsは、それぞれソフトウェア開発と運用管理における異なる手法を表す用語です。両者には重なる部分もありますが、SREは提供するサービスの信頼性をより重視する点で異なります。
一方、DevOpsは開発チームと運用チームの協働により重点を置きます。とはいえ、開発チームのワークフロー全体の効率を高めるために、この2つの手法を組み合わせることには確かなメリットがあります。重要なのは、手法を無理に当てはめるのではなく、両者がうまく連携できるよう統合することです。
SREとは？
サービス信頼性エンジニアリング（SRE）は、Googleが先駆けて導入した、サービスの信頼性を高めるためのエンジニアリングアプローチです。SREの手法は、エンジニアリングのベストプラクティスを通じて、サービスの信頼性と可用性を実現することに重点を置きます。これらのプラクティスは、ダウンタイムを最小限に抑え、スケーラビリティを高め、単一障害点を排除すると同時に、機能設計のシンプルさを維持するよう設計されています。SREの目標は、常にサービスを提供することです。障害が発生する可能性はあらかじめ想定しておきます。障害が発生した場合は記録し、今後のソフトウェア開発イテレーションで同様の問題が起きないよう対処しなければなりません。
SREでは、開発チームが効率性、稼働時間、全般的な使いやすさを考慮するよう徹底します。
SREの原則
SREでは、サービスを本番環境にデプロイする責任を、開発と運用の両者に明確に持たせます。原則として、運用上の責任は開発チームと運用チームが共有します。SREの原則には、次のようなものがあります。
- 部門横断型の自己組織化チームを育成する：SREの実践は、機能とスキルを軸に編成された小規模なグループから始まります。ここでは自己選択が重要な役割を果たします。経験やスキルセットだけでなく、共通の価値観に基づいて、共に働きたい人を選びます。
- マルチテナンシーを優先する：可能であれば、インフラにマルチテナントアーキテクチャを採用します。これによりハードウェアコストを大幅に削減でき、クラウドプロバイダーが各インスタンスのリソースを迅速に増減できるようになります。
- 常に警戒する。障害は発生する：SREとは、二度と障害を経験しないという意味ではありません。障害の発生頻度を下げ、発生したときに復旧する方法を学ぶという意味です。
- すべてを監視する：SREでは、メトリクスとアラートによるリアルタイムの通知を重視します。各メトリクスはインフラの問題を特定する手がかりとなるため、すべてを監視し、そのデータをチームメンバー全員が利用できる一元的なダッシュボードで確認できるようにすることが不可欠です。そこからメトリクスのアラートを設定すれば、状況に異常が生じた際に通知を受け取れます。
DevOpsとは？
DevOpsは、ソフトウェア開発者とIT運用を融合する文化的なムーブメントです。開発者はIT運用チームと協力して、コードの構築、テスト、デプロイ、監視を行います。この協働により、そうでない場合よりも高品質なコードを迅速に提供できます。DevOpsをツールや手法の集合と捉える開発組織もありますが、DevOpsは単にワークフローやソフトウェアツールを改善するものではなく、より良い働き方につながる文化の変革です。
DevOpsの核心は、自動テストと監視によって更新のリリース頻度を高め、フィードバックループを短縮することにあります。継続的インテグレーションや継続的デリバリーだけでなく、開発チーム間のリアルタイムなコミュニケーションも含まれます。
DevOpsの主要な柱
- 速く失敗する：すべての失敗を避けようとするのではなく、エラーから学ぶことがDevOpsの目的です。DevOpsでは、リスクを減らし、エラーの再発を防ぐ方法を見つけることが重要です。
- サイロを作らない：チーム間のコミュニケーションや情報交換が不足すると、本番環境に悪影響を及ぼす可能性があります。チームや部門間の障壁を取り払い、より良い開発パイプラインのためにコミュニケーションと協力を促すことは、DevOpsの重要な要素です。
- 段階的に変える：DevOpsの目標は、すべてを一度に大きく変更するのではなく、小さな漸進的変更をより頻繁に本番環境へリリースすることです。
- 自動化：自動化を活用することで、DevOpsは更新をより迅速にリリースし、膨大な作業時間を削減できます。
- メトリクス：各更新が意図した効果をもたらしたか確認するため、監視することが不可欠です。DevOpsでは、自動化の導入などの活動の成否を測定するために、データと分析を活用する必要があります。
次に読む：DevOps：継続的インテグレーションと継続的デリバリー（CI/CD）を理解する
DevOpsとSREの違い
SREとDevOpsはいずれも目標の似た高度に技術的な手法ですが、両者には違いがあります。
| DevOps | SRE |
|---|---|
| 自動化を促進する | 厳格な品質保証を重視する |
| コミュニケーションを重視する | 説明責任と標準化に重点を置く |
| 開発者が品質保証の責任を負い、テスターは管理者が定めた標準にコードが従っていることだけを確認する | 要件が（開発者によって）満たされた後、テスターが開発者と緊密に連携し、独立したテストを実施するのがより一般的 |
| 主に運用効率に関わる | データベース設計やサーバーアーキテクチャなど、アーキテクチャ上の問題も含む |
| DevOpsの実装では、デプロイ前にすべてのテストケースに合格するため、デプロイはほぼ自動的に行われる | SREモデルでは、本番環境へ移行する前に複数のチームによる承認が必要なため、デプロイはそれほど自動化されていない |
DevOpsとSREの共通点
両方の手法は、運用チームと開発チームの緊密な協働を促します。また、エンタープライズシステムの構築、改善、保守、監視における責任の共有も重視します。SREとDevOpsには、次の5つの共通点があります。
- プロアクティブな監視と対応：SREとDevOpsはいずれも、潜在的な問題が深刻化する前に積極的に特定する自動化プロセスを重視します。
- 手戻りよりも自動化を促進する：たとえば、デプロイ後にアプリで問題が発生した場合、どちらの手法も手作業での修正を推奨しません。その代わり、同様の問題が再発しないよう、開発者には復旧プロセスの自動化が促されます。
- リリース前に欠陥を発見し修正する：自動化（DevOps）を使うか、ライブテスト・監視・発見の手法（SRE）を使うかにかかわらず、どちらの手法も、コードのリリース後にユーザーが遭遇するバグを減らすのに役立ちます。
- チーム内コミュニケーション：DevOpsとSREを比較すると、チーム内のコミュニケーションも注目すべき共通点です。社内ドキュメントや会議などはすべて、ソフトウェアのリリースで何が起きているかをチーム全員が把握するのに役立ちます。
- 多面的な取り組み：DevOpsでもSREでも、成功にはさまざまな部門の参加が必要です。ITだけでなく、財務、マーケティング、営業なども関わります。
こちらも読む：DevOpsに最適なツールとソフトウェア
両方の手法は共存できるか？
SREとDevOpsはいずれも、開発チームの効率と安定性の向上に役立つため、両者は連携できます。一般に、プロセスで2つの手法を組み合わせて使えるならメリットがあります。どちらも既存システムの改善に関わるからです。さらに、適切に実施すれば、SREとDevOpsはコード品質とインフラ品質を兼ね備えた強力な組み合わせになります。SREとDevOpsを連携させることで、次の点が向上します。
効率性
共通の目標に向かう個々人の寄せ集めではなく、1つのチームが一貫性のある製品開発パイプラインを構築します。各メンバーは製品設計やアプリケーション管理など特定分野の専門知識を持つため、効果的に協働できます。
コミュニケーション
チームがSlackで連絡を取る場合でも、メールや対面での議論といった従来の方法を使う場合でも、部門間の断絶をなくすことで、時間、労力、リソースを節約できます。
予測可能性
コミュニケーションと同様に、合理化されたアプローチを使えば、エンドユーザーと開発者の双方が、本番環境の問題や新機能について一貫した見通しを持てます。開発者は、変更同士の干渉を心配することなく、既存のパラメーター内に変更をシームレスに実装できます。
プロセス全体の統合
各手法には、それぞれ固有のプロセス特性があり、他方にはないものもあります。1つの統合された全体として機能させることで、互いの強みを共有し、弱点を最小限に抑えられます。より健全なエコシステムも実現します。DevOpsの専門家の多くは、ツールの種類ごと、あるいは言語ごとにサイロ化するのを避け、現代のビジネスニーズに最適なさまざまなツールを備えた、よく連携する仕組みを構築するよう推奨しています。こうした考え方を、これらの手法を自社の企業文化に統合する際にも取り入れれば、開発者の健全性が高まり、運用全体も改善されるでしょう。
SREとDevOpsは組み合わせることでより良くなる
全体は部分の総和に勝る、という言葉をご存じでしょうか。SREとDevOpsについては、まさにその通りです。この2つの相補的な手法により、コミュニケーションが円滑になり、協働がより効果的になり、システムの機能も向上します。
DevOpsとSREの相乗効果を最大限に引き出すには、慎重に取り組む必要があります。これらの手法は、単独で見ればそれぞれに長所と短所があります。単独の手法としても価値を提供しますが、両者を一貫したソリューションに組み込むことで、どちらか一方だけの場合よりもはるかに優れた、ユーザーへのテクノロジー提供アプローチを実現できます。