SRE(サイトリライアビリティエンジニアリング)とは？

サイトリライアビリティエンジニアは、ソフトウェア開発とインシデント対応のライフサイクルの信頼性を確保することによって顧客価値を創出し、以下のメリットをもたらします。

• サービスの健全性に対するオブザーバビリティ：SREチームは組織のシステムのさまざまな領域に関与しているため、これらのシステムがどのように接続され、どのように連携しているかについてのインサイトを得ることができます。サイトリライアビリティエンジニアは、多数の異種サービス間でメトリクス、ログ、トレースを追跡し、システムの健全性に関する全体像を把握することができるため、インシデントが発生したときに必要なコンテキストを提供できます。SREメトリクスについて詳しくは、こちらの投稿をご覧ください。 
• 開発者と運用担当者との連携強化：サイトリライアビリティエンジニアは、自動化の導入やコミュニケーションの改善により、開発者とIT運用担当者の関係を強化し、両チームに利益をもたらします。SREは、リリースパイプラインの弱点を明らかにして補強し、オンコールの可用性とインシデント対応に関する説明責任を確立することができます。
• NOCの最新化：ネットワークオペレーションセンター(NOC)は通常、人手による反復作業に大きく依存しながら、インシデントやアラートをトリアージし、それらを適切な担当者にどのように転送するかを判断しています。SREは、自動化と機械学習によってこれらのプロセスを最新化し、問題を修正する担当者に自動的にアラートを送信することができます。
• オンコール体制とアラートワークフローの構築：サイトリライアビリティエンジニアは、効果的なオンコールプロセスを構築し、アラートを最適化する方法についての豊富な知識を備えています。そのため、オンコールスケジュールとアラートルールに関する最善のアプローチを決定し、システムを介してアラートをルーティングするための最適な方法を見極め、オンコールの責任の一部を自ら担うことができます。
• 本番環境における問題の顕在化：サイトリライアビリティエンジニアは本番環境を詳細に把握しているため、システムの健全性やサービスのオブザーバビリティを担当し、顧客に影響を与える可能性のある障害を正確に特定することができます。これらの問題が顕在化した場合、チームはプロダクトロードマップの早い段階で修正に取り組むことができます。
• エンジニアリングチーム全体のスチュワードシップ：このほかにも、サイトリライアビリティエンジニアは、ベストプラクティスの改善、追加、実施を支援し、組織全体における部門間のレジリエンスをサポートするなどの活動も行います。
  

すべてのSREプラクティスはシステムの信頼性を向上させることを目的としており、次の5つの主要なカテゴリに分類されます。

• 可用性：SREチームは、システムやサービスの本番稼動後の可用性を維持する責任を負っています。まずは、基盤となるサービスのサービスレベル目標(SLO)、サービスレベル契約(SLA)、サービスレベル指標(SLI)を設定することから始めます。SLIは、稼動時間やリクエスト遅延などのメトリクスの概要を示すもので、企業が顧客に提供するサービスレベルを測定するために使用されます。これらのSLIに基づいて、サイトまたはサービスのパフォーマンス(たとえば、99.99%の可用性)を測定する手段がSLOに定義されます。最後に、これら両方に基づき、サービスの信頼性目標とその目標が達成されなかった場合の対応が明記されたSLAを作成します。 
• パフォーマンス：可用性が安定したら、SREチームはサービスパフォーマンスの改善に目を向けることができます。遅延、ページの読み込み速度、その他のパフォーマンスメトリクスは、必ずしも全体的な可用性に影響を与えるわけではありません。しかし、時間の経過とともに悪化し、頻繁に発生するようになると、サービスの顧客離れにつながる可能性があります。SREチームは、開発チームやアプリケーションサポートの支援、バグの修正を行うほか、システム全体のパフォーマンスの問題も未然に察知します。こうしてパフォーマンスに関する軽微な問題を少しずつ特定して修正していくことで、サービス全体の信頼性が向上します。
• 監視：SREチームは、監視対象を決定し、それぞれのサービスの稼動時間とパフォーマンスをどのように測定するかに基づいて、適切な監視ソリューションを導入する責任があります。最終的には、エンジニアリングチームやITチームがシステムの健全性を包括的に把握できるソリューションを実装する必要がありますが、これはSREの最大の課題の1つといえます。
• インシデント対応：SREチームは、インシデント対応(つまりインシデントに対する動員)において重要な役割を担います(記録および監査証跡の仕組みであるインシデント管理とは異なります)。SREチームのメンバーは、システム内で発生したインシデントへの対応と説明、そしてレビューができなければなりません。これには、本番ワークフロー、プロセス、アラート基準、およびデプロイに関するその他の要因の監査が含まれる場合があります。通常、SREチームは、イベントに対応する際のガイドとしてオンコールプレイブックを使用します。また、誰も責めることのない事後分析を実施して、特定の問題の原因および再発防止策について理解し、必要な改善点を文書化します。
• 環境の整備：SREチームは最終的に、開発チームとITチームの環境を整え、サービスの健全性やインシデントへの迅速かつ効果的な対応方法についての理解を深められるようにします。サイトリライアビリティエンジニアが開発チームやITチームと連携することで、開発者は本番環境について詳しく知ることができます。また、IT運用チームは開発ライフサイクルに早い段階から関与できるようになります。

  この取り組みの大きな部分を占めるのがデプロイ環境の整備です。これは、エンジニアと協力しながら新しいサービスのオブザーバビリティを確保するための活動です。これによって信頼性に関わる問題に対してよりプロアクティブかつ迅速なアプローチをとることができます。

SREのプラクティスには、分散システム内のすべてのサービスとアプリケーションの可視性と透明性が必要です。しかし、こうした環境で異なるサービスのパフォーマンスや可用性を測定するのは複雑な作業です。このプロセスをより取り組みやすいものにするために、Google社のSREチームは4つのゴールデンシグナルを提唱しました。これは、分散システムを効果的に監視するためのフレームワークの1つで、システムが健全であることを示すベンチマークを定めています。

• レイテンシー：リクエストの処理にかかる時間のことです。「健全」と判断できるレイテンシー率のベンチマークを定め、成功したリクエストと失敗したリクエストを区別してレイテンシーを監視し、システムの健全性を追跡します。システム全体でレイテンシーを監視することで、パフォーマンスが悪いサービスを特定し、インシデントをより早い段階で検出できます。
• トラフィック：サービスで処理されるユーザーまたはトランザクションが一定時間にシステムに与える負荷を示す指標です。アプリケーションやサービスで発生する実際のユーザーとの通信とトラフィックを監視することにより、ユーザー視点でエクスペリエンスを把握し、需要の変化がシステムにどのような影響を与えるかを確認できます。
• エラー：リクエストの失敗率を表します。システム全体で発生するエラーの割合を監視し、エラーバジェットを作成して、どのエラーが最も重大であるかを定義する必要があります。これにより、サービスについてユーザー視点で健全性を把握し、頻発するエラーにすばやく対応して修正できます。
• サチュレーション：システムの全体的なキャパシティと利用可能なリソースを表し、特定のサービスのキャパシティを可視化できます。大半のシステムでは、使用率が100%に達する前にパフォーマンスが低下し始めるため、SREチームは「健全」な使用率(サービスのパフォーマンスと可用性が確保される値)についてのベンチマークを設定する必要があります。

DevOpsにおけるSREの役割は、DevOpsチームが開発したアプリやサービスをエンドユーザーが必要なときにいつでも使用できるようにしておくことです。SREとDevOpsは一括りに語られることが多いですが、これらは2つの異なる分野です。

DevOpsは、プラクティスとして、また一連の原則としての両側面から認識されています。プラクティスとしてのDevOpsは、ITデリバリーのためのアプローチであり、人、手法、ツールを連携させることで、開発チームと運用チームのサイロ化を解消します。

DevOpsは、その名前が示すように、アプリケーションのコードを作成するソフトウェア開発(Dev)と、それらのアプリケーションを本番稼動させてエンドユーザーに提供し、信頼性の維持を図るIT運用(Ops)との間を隔てるギャップを埋めることを目的としています。

原則としてのDevOps(DevOps文化)は、アジャイルの普及により生まれたものです。アジャイルは、段階的なデリバリー、チームコラボレーション、継続的な計画と学習に焦点を当て、より優れたソフトウェア開発プラクティスを導くための原則を確立しました。ソフトウェア開発とIT運用を連携させることで、DevOpsはソフトウェア開発ライフサイクル(SDLC)全体にわたってアジャイルの原則を拡張し、継続的な改善を目標としてワークフロー全体を最適化します。DevOpsがうまく機能すると、コーディングの反復と導入が迅速化するだけでなく、新しいアイデアを市場に投入するまでの時間が短縮され、バグが減少し、インフラの安定性が向上します。

SREは、DevOpsの原則において重要な機能を果たしており、プラクティスとしてのDevOpsとも重なる部分が多いものの、責任範囲はより限定的です。DevOpsでは、開発者が実際に製品のオーナーシップを持って運用することが求められます。しかし、開発者は絶えずアプリの新機能を開発しなければならないため、そういった取り組みが現実的ではない場合がほとんどです。

サイトリライアビリティエンジニアは、ソフトウェア開発とIT運用の両方の知識を活かして、デプロイ、設定、監視などのコードの管理を監督できます。大まかに言うと、SREは新しいソフトウェアや機能の迅速なデプロイ、およびITインフラの安定性を確保することで、開発と運用間の関係を強化します。

自動化による反復的な手作業の削減は、SREが重点的に取り組むべき課題です。そのために、サイトリライアビリティエンジニアは、ログ分析やパフォーマンス調整などの多くの自動化された運用タスクを活用しています。また、自動化は、MTTR (平均解決時間)の短縮、ダウンタイムやシステム停止による影響の軽減、さらには監視やアラート、パッチ適用などのインシデント対応アクティビティのための詳細なコンテキストを提供するためにも欠かせません。

自動化は、スピード、一貫性、効率、適応性が重要視される最新の開発環境では必須といえます。そして、最も重要なポイントは、日常業務の反復的な運用タスクの数が減り、SREチームのメンバーが新しいツールの作成、インフラの変更の監視、信頼性向上のためのその他のタスクの実行に集中できるようになることでしょう。

SREを効果的に実践するには、システムについて、またそれらがどのように連携しているかについて包括的な視点を持つことが必要です。サイトリライアビリティエンジニアは、システムを全体的に捉え、個々のコンポーネントだけでなく、それらの相互接続も重視しなければなりません。これを踏まえ、『The Site Reliability Workbook』に記載されている以下の7つの原則に従うことで、効果的にSREを実践することができます。

• 運用をソフトウェアの問題として捉える：SREの主な考え方として、ソフトウェアエンジニアリングのアプローチがソフトウェアの問題に対する解決策であるとしています。
• サービスレベル目標で管理する：SREが目指すのは100%の可用性ではありません。障害の発生は想定の範囲内です。SREはプロダクトチームと協力して可用性の合意目標を設定し、そのSLOに基づいてサービスを管理します。
• 手間を最小限に抑えるように努める：反復的で手間のかかる手作業をデフォルトの方法にすべきではありません。自動化できるタスクやオペレーションはすべて自動化するべきです。
• 今年の仕事を自動化する：どのようなタスクやオペレーションを自動化するかを決定し、実装のための戦略を立てます。
• 失敗のコストを抑えて迅速な行動を促す：ライフサイクルの早い段階で問題を特定して修正し、顧客への影響を最小限に抑えます。
• 開発者とオーナーシップを共有する：開発チームとSREチームが可視性とオーナーシップを共有できるように、サイロを解消して境界をなくします。
• 職務や役職にかかわらず、同じツールを使用する：各チームが別々のツールを使用していては、1つのSREチームで複数の開発チームを効果的にサポートすることはできません。ツールセットの標準化が、SREプラクティスを成功させるための鍵となります。
  

サイトリライアビリティエンジニアは、さまざまな責任を担っています。SREの一般的な役割には次のものがあります。

• 運用およびサポートチームを支援するソフトウェアの構築：サイトリライアビリティエンジニアは、その開発スキルを活かして、ITスタッフやサポートスタッフの業務の効率化に役立つソフトウェアを構築し、実装します。その範囲は、新しいツールの構築から、ソフトウェアデリバリーの弱点の補強、既存の監視ツールの調整、本番環境のコードの変更まで多岐にわたります。 
• サポートエスカレーションの問題の修正：サイトリライアビリティエンジニアは、初期の段階ではサポートエスカレーションの問題の修正に時間を費やすことになります。ただし、システムの信頼性が向上するにつれて、これに費やす時間は減少します。多様なスキルセットと経験に基づき、問題を適切な担当者やチームに転送するために必要な専門知識を備えているのがサイトリライアビリティエンジニアです。
• オンコールのローテーションとプロセスの最適化：通常、サイトリライアビリティエンジニアにはインシデントの発生に対応できることが求められるため、システムの信頼性を向上させるためのオンコールプロセスを最適化する方法について多くの提言を行います。SREチームは、アラートに自動化とコンテキストを追加してインシデント対応の連携を改善し、ランブックやドキュメントを更新してオンコールチームが今後のインシデントに備えられるよう支援します。
• 知識の文書化：SREチームは、ソフトウェア開発ライフサイクルのほぼすべての側面に関与しているため、サービスやプロセスについて長年蓄積された豊富な知識を有しています。サイトリライアビリティエンジニアは、定期的に学習を繰り返しながらランブックを整備するため、エンジニアリングチームは必要なときに必要な情報を得ることができます。これにより、スチュワードシップが強化され、チーム間の信頼が促進されます。
• インシデント後のレビューの実施：SREチームは、ソフトウェア開発者とIT運用の専門家が誰も責めることのない分析を実施し、調査結果を文書化し、学んだことを行動に活かせるようにする役割を担っています。サイトリライアビリティエンジニアは、インシデント後のアクションアイテムについても責任を負います。これには、SDLCやインシデントライフサイクルの一部を構築したり最適化したりすることが含まれます。
  

SREはDevOpsの活動と密接に連携しており、開発チームと運用チーム間には緊密なコミュニケーションが必要です。そのためこれらのチームが成功するには、信頼、連携、継続的改善の文化が不可欠です。

また、サイトリライアビリティエンジニアは、開発と運用のスキルを兼ね備えていることはもちろん、従来のソフトウェアエンジニアリングのツールとプラクティスを理解している必要があります。システムを包括的に把握することに加え、信頼性を高めるための新しい方法を取り入れる柔軟性も必要とされます。

さらに、SREには積極的なコミットメントが求められます。これは、単にツールやパッチを適用してシステムの欠陥を修正する作業ではありません。SREに求められているのは、文化を変えることや、運用に関する新しいプロセスや考え方を導入することです。他の取り組みと同様に、SREも最初は1人の推進者から始まるかもしれませんが、SREのプラクティスを成熟させていくためには、最終的に上層部からの賛同が必要となります。

稼動時間を長くして維持することは、あらゆる組織が取り組み続けている課題です。しかし、効果的なSREプロセスを有する企業はシステムの回復力が高く、その結果としてリリースの成功率も向上するため、競合他社よりも優位に立つことができます。インシデントが発生した場合でも、短い平均確認時間と平均修復時間(MTTA/MTTR)で対応できます。本番環境の問題の修正に要する時間が減ることで、開発、SRE、運用のすべてのチームは、それぞれの分野でビジネス価値の提供に注力できるようになります。その結果、信頼性はソフトウェア開発を滞らせる要因ではなく、ソフトウェア開発における機能の1つとなるのです。