SRE（サイト信頼性エンジニアリング）とは何でしょうか？また、サイト信頼性エンジニアは何をするのでしょうか？

クラウドベースのコンピューティングを採用する組織が増え、デジタルサービスの需要が高まるにつれ、サイト信頼性エンジニアリング（SRE）の実践は不可欠となっています。これらの実践は、可用性、パフォーマンス、ユーザー体験、ビジネスKPIに関するサービスレベル契約（SLA）の達成を支援します。

しかし、SREとは具体的に何であり、サイト信頼性エンジニアはどのような業務を行うのでしょうか？

サイト信頼性エンジニアリングとは？

サイト信頼性エンジニアリング（SRE）とは、ソフトウェアエンジニアリングの原則を運用およびインフラプロセスに適用し、組織が信頼性と拡張性に優れたソフトウェアシステムを構築することを支援する実践手法です。SREという分野では、可用性、パフォーマンス、レイテンシ、効率性、キャパシティ、インシデント対応といった主要なカテゴリーにおけるソフトウェアシステムの信頼性向上に焦点を当てています。関連する業務を担当する人材は、サイト信頼性エンジニアと呼ばれます。

「サイト信頼性エンジニアリング」という用語は、2003年にGoogleのエンジニアリング担当副社長ベン・スロス氏によって提唱されました。同氏は自身のLinkedInプロフィールで「Googleが機能しなくなった場合、それは私の責任です」と有名な言葉を記しています。Googleによれば、「SREとは、運用をソフトウェアの問題として扱うことで得られるものです」とのことです。

組織やソフトウェアシステムはそれぞれ異なりますが、ソフトウェアの信頼性と全体的な品質を最適化することを考える際には、SREの基本原則と、そのエンジニアが持つスキルや考え方を理解することが重要です。

サイト信頼性エンジニアリングのメリット

サイト信頼性エンジニアリングは、信頼性、スケーラビリティ、効率性を重視します。SREのメリットは以下の通りです：

• 信頼性と稼働時間の向上：SREは、システムやアプリケーションが常に利用可能で高性能であることを保証するため、インシデントの予防と軽減に重点を置いています。
• スケーラビリティの向上：リソース使用の最適化と無駄の最小化により、SREは組織がインフラストラクチャとアプリケーションをより効率的に拡張するお手伝いをいたします。
• ユーザー体験の向上：SREはアプリケーションやサービスが常に利用可能で応答性を保つことを保証し、顧客満足度、ブランド評価、収益に直接的な影響を与えます。
• 継続的な改善：SREはデータとメトリクスの活用を重視し、改善領域を特定するとともに、継続的な最適化と革新を推進します。
• セキュリティの強化：SREは、システムやアプリケーションが安全であり、業界標準や規制に準拠していることを保証するのに役立ちます。
• 予測可能なパフォーマンス：SREは使用パターンの監視と分析を通じて、パフォーマンス問題の発生を予測・防止し、システムとアプリケーションが予測可能かつ一貫した動作を保証します。
• コスト削減：SREは、日常業務の自動化とリソース使用の最適化により、手動介入の必要性を減らし、時間と費用を節約することでコスト削減を実現します。
• 開発チームと運用チーム間の連携：SREは、信頼性とパフォーマンスに関する部門横断的なチーム編成と責任の共有を重視し、連携と説明責任の文化を促進します。

サイト信頼性エンジニアリングについて知っておくべき5つのこと

SREの導入は大規模な取り組みのように思えるかもしれませんが、必要な運用上の変化は持続的なメリットをもたらし、効率性の向上と投資対効果の向上につながります。

1. SREは自動化に重点を置きます

SREの主要な目標の一つは、作業の重複や冗長性を可能な限り削減することです。SREチームは、アクセス権やインフラのプロビジョニング、アカウント設定、セルフサービスツールの構築といった手動タスクの自動化に注力します。その結果、開発チームは機能の提供に、運用チームはインフラ管理に集中できるようになります。

組織が新機能の本番環境への迅速な提供を加速する中、プロセスの自動化はさらに重要性を増しています。一方で、スピードはDevOpsチームが自動化を活用して継続的インテグレーションと継続的デリバリー（CI/CD）を強化することで実現されます。他方、マイクロサービスアーキテクチャへの移行や、クラウドネイティブ技術、コンテナ、Kubernetes、サーバーレスアーキテクチャの採用は、より小さな変更をより迅速にデリバリーするさらなる手段を提供します。これらの手法は効率性とスピードを向上させますが、同時にリスクを低減し、運用を測定するためのフィードバックループを提供する、一貫性のある再現可能なプロセスも求めます。これにより、チームは改善すべき領域を特定できるようになります。

2. SREは開発と運用間のギャップを埋める

組織がバリューストリームプロセスで行う全ての活動は、「これを本番環境で確実に安定稼働させるにはどうすればよいか」という問いに答えるべきです。SREは回復力に基づくエンジニアリングを推進します。彼らはメンターとなり、開発者と運用双方が回復力を最優先事項と位置付けるよう確保します。

DevOpsの考え方とスキルをソフトウェアの信頼性に適用することで、開発ライフサイクルの早期段階で信頼性やパフォーマンスの問題を検出する責任を共有し、開発チームと運用チーム間のサイロ化を軽減します。開発者、運用担当者、プロダクトオーナー間の連携により、サイト信頼性エンジニアは稼働時間と可用性の目標を定義し達成することが可能となります。

3. SREは「シフトレフト」の考え方を推進します

SREは絶えず進化する分野であり、デリバリーパイプラインに手法・ポリシー・プロセスを組み込み、アプリケーションの「自動修復」やユーザー自身による問題解決を可能にする機会を提供します。「シフトレフト」の考え方は、SREが開発から運用までの各プロセス・アプリケーション・コード変更に信頼性と回復力を組み込み、本番環境に投入されるソフトウェアの品質向上を図ることを意味します。

SREが「シフトレフト」の考え方を推進する具体的な方法をご紹介します：

• 本番環境レベルのサービスレベル目標（SLO）に基づいた品質ゲートを開発し、開発サイクルの早い段階で問題を検出します。
• サービスレベル指標（SLI）およびSLOを用いたビルドテストと検証の自動化
• ソフトウェア開発の初期段階から、アーキテクチャ設計に影響を与え、耐障害性と拡張性を確保します。

目標は、品質と信頼性を最初から組み込むため、早期かつ積極的な対策を講じることです。SREはプロセスに広く影響を与え、CI/CDプラクティスを支援するため、企業全体でのテスト調整へと拡大できます。

4. SREは運用とサポートを支援するサービスとツールを構築します

従来、運用チームの主要な目標は稼働時間の向上でした。この単一的なアプローチでは、理想とされる「99.999%」の稼働率、つまり年間5分強のダウンタイムに相当する「ファイブナインズ」が求められてきました。

しかし、分散型クラウドネイティブ環境における変更頻度の増加に伴い、多次元的なアプローチが必要となります。

SREの目標は、高い変更率を実現しつつ、回復力とあの憧れの99.999%の稼働率を維持することです。マルチクラウド環境では、回復力はパフォーマンス、ユーザー体験、応答性、コンバージョン率などの主要指標を通じて測定されます。SREチームは、これら全ての領域における運用改善とリリースプロセス促進を実現するサービスを構築・実装する必要があります。その内容は、監視やアラートの調整から本番環境でのコード変更まで多岐にわたります。サイト信頼性エンジニアは、ソフトウェアデリバリーやインシデント管理ワークフローにおける特定のニーズを満たすため、カスタムツールを一から構築することも少なくありません。

SREアプローチを採用するには、チームが使用する技術やツールの標準化も必要です。標準化により運用管理が容易になり、互換性のない技術を管理する負担が軽減されるため、チームはより多くの時間をコラボレーションやイノベーションに充てることができます。

5. SREには文化変革が求められます

SREは実践手法であるため、複数の分野にまたがるチーム間のコミュニケーション方法、問題解決手法、ソリューション実装手法の変革が求められます。SRE文化を成功裡に導入するには、組織はリスク管理への新たなアプローチを採用する必要があります。また、ガバナンスプロセスの適応、人材採用への投資、エンジニアリングと運用に精通し、迅速に学び適応できる協働的な人材の育成も不可欠です。

組織はこうした熟練エンジニアをDevOpsライフサイクルの要所に配置できます。開発・テストチームでは、SREスペシャリストが自動化ツールを開発し、開発者がアジャイルなデリバリースケジュールを妨げることなく早期かつ頻繁にテストを実施できるよう支援します。システムレベルでは、リリースとローンチの調整、システムアーキテクチャの準備状況の評価、システム全体のSLO達成を支援するツールを開発します。ガバナンスレベルでは、エンタープライズアーキテクチャの定義と監督、ベストプラクティスの確立、全社的なサイト信頼性を支えるツールとリソースの選定を支援します。

サイト信頼性エンジニアの仕事内容とは？

サイト信頼性エンジニアの業務内容について専門家の見解を得るため、当社のDevOps推進担当者であるアンディ・グラブナー氏に伺いました。

サイト信頼性エンジニアは、ソフトウェアエンジニアリングにおける優れた実践手法を活用し、組織および実際に新たなアプリケーションを提供する方々に、回復力のあるインフラストラクチャとサービスを提供します」と彼は説明します。また、SREはシステムを稼働状態に維持するシステムエンジニアなど、従来の運用職から転身するケースが多いとも指摘しています。「サイト信頼性エンジニアは、システムが信頼性、回復力、可用性を維持することを保証します」と彼は付け加えています。

SREに求められる典型的な期待

一般的に、SREにはデリバリーのスピードがセキュリティ、サービス、ソリューションの中断を招かないよう確保する責務が課せられます。しかしグラブナー氏が指摘するように、「期待される役割は企業ごとに多少異なります。絶対的なルールはありません。多くのSREは監視と可観測性の確保、システムの維持管理、そして必要な環境を迅速に構築するための自動化提供を担当しています」。

グラブナー氏は、サービスやアプリケーションのデプロイメントのためのフレームワークやプラットフォームを提供するSREの役割を強調しています。「問題が発生した場合、アラートがあればSREはしばしば第一線の防御役を担います」と彼は述べています。「優れた組織では、彼らは単独で対応するのではなく、攻撃を受けているアプリケーションに対処するために、個々のアプリケーションチームと常に連携し、その内部で活動します」。

おそらくSREの最も重要な役割は、回復力を設計することです。「回復力はサービスとして購入できるものではありません」とグラブナー氏は指摘します。「設計段階で回復力を備えたシステムを構築することで、回復力を設計に組み込む必要があるのです」。この設計アプローチにより、Dynatraceは最近ドイツで発生したAWSの障害を乗り切ることができました。自動デリバリー、回復力、自動修復機能により、重要なシステムへの影響を回避できたのです。

SREの役割と責任

テクノロジーの進化とデジタルインフラへの依存度が高まる中、SREの役割は計り知れない価値を持つようになりました。SREの標準的な責任範囲の一部をご紹介します：

1. 監視とアラート
   SRE の主な職務の一つは、企業のデジタルインフラストラクチャを監視することです。これには、問題が深刻化する前に検知するための監視ツールやシステムの設定が含まれます。SRE は、問題が検出された際に適切な担当者に通知するアラートシステムを設定します。
2. インシデント対応
   SREは、問題が検出された際に迅速かつ効果的に対応します。具体的には、根本原因を特定し、計画を策定・実施し、関連するステークホルダーとコミュニケーションを取ります。
3. 自動化とツール構築
   SREは、企業のデジタルインフラを管理するために使用されるツールやシステムを開発・保守します。これには、プロセスを効率化し人的ミスのリスクを低減するための自動化スクリプトの開発も含まれます。また、ツールの改善が必要な領域を特定し、ビジネスの変化するニーズに対応するための新しいツールを作成します。
4. キャパシティプランニング
   SREは、企業のデジタルインフラがビジネスのニーズを満たせるよう保証します。これには、将来の需要に対応するために必要なキャパシティを予測し保証するための利用パターンの分析が含まれます。
5. 連携
   SREは、企業のデジタルインフラが信頼性、拡張性、安全性を備えていることを保証するため、他チームと緊密に連携します。

優れたSREの条件とは？

優れたSREは、リスクを恐れず、試行錯誤を重ね、革新を追求する方々です。稼働時間と回復力を維持しながら、システムを100ユーザーから10万ユーザー、さらに100万ユーザーへとスケールさせるために必要な要素を見極めます。開発段階での意思決定が本番環境に与える影響、また本番システムの要件が設計に及ぼす可能性を考慮する、システム思考の持ち主です。

これには絶え間ないテスト、失敗の受け入れ、適応、そして反復可能なプロセスの自動化が求められます。成功するSREは、あらゆる状況に回復性と適応の考え方を持ち込みます。

グラブナー氏は、SREが自らの過ちから学ぶ必要性を強調しています。「最悪のシナリオに対処し、何が起こり得るか、どう対処すべきかを理解するために『カオスデー』を実施する企業もあります」と述べています。

自動化もSRE成功の指標です。「自動化可能かつ必須のタスクを全て自動化しようと努める人材がこの役割で卓越します」とグラブナー氏は述べ、「これにより真のイノベーションを実現する余裕が生まれます」と続けます。適切な環境下では誰もが革新を起こせるとしつつも、チームは手作業や反復作業という「労苦」に阻まれることが多いと指摘。「目標は、現在の役割から自動化によって解放され、次の役割へと移行することです」

最後に、グラブナー氏はSREが孤立して活動することはできないと明言しました。「新しい技術や手法について、自ら学びを深める機会を人々に与える必要があります」と彼は述べています。「世界に向けて発信しましょう。秘密にせず、自らの学びや他者からの学びをオープンに共有してください。優れたカンファレンスは数多く存在します。他者の取り組みから刺激を受け、自らの取り組みで他者を鼓舞することは非常に価値があります」

DevOpsとSREの比較

DevOpsチームが変更の効率化に注力する一方、SREはこれらの変更が全体的な障害率を増加させないよう支援します。実質的に両者は表裏一体の関係にあります：DevOpsがスピードを自動化するのに対し、SREは信頼性を自動化するのです。「スピードと安全性のバランスが重要です」とグラブナー氏は述べています。

グラブナー氏は、DevOpsプロセスを開発ライフサイクルに沿って左から右へ進めるものと捉えています。自動化を活用して新機能の導入を加速し、その成果は通常、デプロイ頻度や変更のリードタイムで測定されます。一方、SREは開発段階で本番環境レベルの要件を適用し、右から左へ進みます。障害発生率の抑制とサービス復旧時間の短縮に重点を置いています。「SREの本質は、多くの変更があっても、それらがシステムを壊さないようにすることです」

グラブナー氏は、SLOに関してはSREとDevOpsが重なる領域だと指摘します。「SLOはビジネス目標の達成を支えるものです」と彼は説明します。「企業は99%の信頼性をシステムに求めるかもしれません。ユーザー基盤の拡大やエンドユーザー体験の向上を望むかもしれません」。こうした目標の達成はDevOpsの役割です。「しかし、これらの目標の下には、各社の目的固有の技術的目標が存在します」と彼は述べています。「適切な機能を適切なタイミングで提供することでビジネス成功に貢献し、変化への対応を支援します」。これらの目標達成はSREスタッフの役割です。結果として「SLOはDevOpsとSREを結びつける優れた手法と言えます」。

別のブログ記事では、SREとDevOpsの違いと類似点についてさらに詳しく学ぶことができます。

サイト信頼性の実現に向けて

サイト信頼性は「解決済みの問題」ではなく、今後もそうなることはありません。新たなサービスやアプリケーション、そして進化し続ける企業の要求により、SREチームの仕事は常に存在し、改善の余地も常にあります。

グラブナー氏が指摘するように、SREの影響力を高める上で最も重要なのは、「自ら学びを共有し、他者からも学ぶ姿勢を持つこと」です。「優れたカンファレンスは数多く存在します。他者の取り組みから刺激を受け、自らの成果で他者を鼓舞する価値は十分にあります」と述べています。また、失敗から学ぶ必要性も強調しています。「最悪のシナリオを想定した『カオス・デイ』を実施し、想定される事態とその対処法を検証する企業もあります」。最後にグラブナー氏は、SREが孤立して活動すべきではないと明言しました。「新たな技術や手法について、自ら学びを深める機会を従業員に提供すべきです。成果を広く共有し、秘密主義に陥らず、部門間の壁をなくすことが重要です」。

SREの実践を向上させるソリューションをお探しですか？ダイナトレースがお役に立ちます。最も複雑な分散型クラウド環境においても自動的かつインテリジェントな可観測性を提供するダイナトレース・ソフトウェア・インテリジェンス・プラットフォームは、SREおよびDevOpsチームが問題が発生する前に特定することを可能にします。AIを中核とした継続的な自動化により推進されるDynatraceは、ソフトウェア開発ライフサイクルのあらゆる段階で、サイト信頼性問題の正確な根本原因を明らかにします。プレプロダクション環境での初期開発段階から、プロダクション環境でのデリバリーおよび運用に至るまで、DynatraceはSREチームが信頼性、可用性、レイテンシーを向上させ、サービス停止や速度低下がビジネスに与える影響を軽減することを支援します。