SRE（サイト・リライアビリティ・エンジニアリング）とは

近年、ITインフラをクラウド上で管理することが一般的になったことに伴い、24時間365日安定的にWEBサービスを提供するための体制づくりがますます重要になってきました。

しかし、高度化・複雑化が進むWEBサービスをセキュアかつ効率的に管理には、部署横断的な管理体制が必要であり、その体制づくりに関しては手探り状態だったという企業も少なくありません。

そんな中、2017年にGoogleはSRE（サイト・リライアビリティ・エンジニアリング）というWEBシステム管理のための一連のメソッドと実践方法をまとめ、セキュアかつ効率的なシステム運用のためのスタンダードを提唱しました。SREは瞬く間に利用が拡大し、システム運用に伴う作業をエンジニアリングによって自動化・効率化するために、様々な企業により採用されることになりました。

海外のテック企業は、ほぼすべてがSRE、あるいはそれに類似する運営体制を整備しており、日本でもメルカリやビズリーチなどが採用しています。従業員の作業効率を大幅に向上させるＳＲＥはＤＸ推進の文脈でも非常に重要な分野であるので、本記事ではSREの基本的な考え方や実践方法を紹介します。

SREとは

Googleは創業以来、WEBシステムの信頼性を担保するための運用モデルを模索してきました。そのような背景の中、Googleのエンジニアリング担当副社長であるBenjamin Treynor Sloss氏によりSREが提唱されました。同氏はSREの目的を「従来の組織でIT運用担当者が通常処理していた作業を、ソフトウェアエンジニアが行うこと」と述べており、これまで技術者により手作業で行われていた管理業務を自動化・効率化することに焦点が当てられています。

SREの基本的な考え方

DevOps

SREでは、サイトの構築を担う開発チームとサイトの運営を担う運営チームとが一丸となって取り組むことが重視されます。開発チームは実装のスピードを重視し、運営チームは安定を重視しているといった齟齬はよくあることであり、両者のチームで連携がとれていないと、組織内での対立の原因となります。

SREは技術者のみならず幅広い部署が一丸となって進める必要があるため、部署横断的なDevOpsの文化を形成することは非常に重要です。日本の組織では欧米に比べて部署横断的な連携が進んでいないことがSREの障壁になっていると度々指摘されてきました。

部署横断的なDevOps体制を構築することによりSREを実現するための土壌が形成されます。Google Cloud Techでは、DevOpsのポイントとして以下の５つを紹介しているので参考になるでしょう。

トイルの削減

SREの進める上でもっとも重要なのがトイルの削減です。トイルとは直訳すると「労苦」ですが、自動化されることが可能であるのにも関わらず、手作業で行われている作業のことを指します。Googleは、トイルの例として「割り当てリクエストの処理」「データベース スキーマ変更の適用」などを挙げており、日々、トイルを洗い出して削減する体制を構築することを推奨しており、トイルに費やされている時間は、日々の業務の50％以下にすることを目標として取り組むと良いでしょう。

（参考：SRE の原則に沿ったトイルの洗い出しとトラッキング）

SLI（Service Level Indicators）とSLO（Service Level Objective）

「SLI(service level indicators) 」とはサービスレベル指標（SLI）のことであり、定量的に測定可能な、サービスレベルに関するユーザーの満足度の指標であり、SLO(Service Level Objective)はSLIの目標値です。SaaSなどのITサービスプロバイダーの評価を測定する方法です。開発サイドとユーザーとのインタラクションを定量評価する上でもSLOの設定は非常に重要であり、SLOを達成している場合は、SREの速度が加速することが期待されます。

（参考：SLOについて）

ポストモーテム（事後検証）

GoogleのLiz Fong-Jonesは、SREを実践する上で「ポストモーテム（事後検証）」の重要性を語ります。　生じたインシデントの文書化とレビューを部署横断的に徹底することでSREを進める文化が定着します。

エラーバジェット

SREを実践する上で、非常に重要なのがSLOのレベルと実行可能性のバランスです。例えば、完璧を目指したSLOを設定して月あたりのダウンタイムをゼロとするのは、現実的ではありませんし、99.99％と目指すのか、99％を目指すのかによっても現場の負担は全く違ったものになります（そして両者の間で顧客満足度に大きな差が見られないことも往々にしてあります）。SREに関するあらゆる変革は、ゆっくりと継続的に進めていくものであるという考えが主流であり、費用対効果に関しても実行可能性を俯瞰してプランニングすることが重要になります。

SREの実践

SREの実勢についてはGoogleがワークブックやチェックリストを公開しています。ワークブックでは、「基礎構築」、「実践」、「運用」のパートに分かれており、「実践」のパートでは、SLOの実行、トイルの除去、モニタリングなどに関して具体的な施策が紹介されています。

今回は、Googleのまとめたチェックリストを紹介するので、SREのスタンダードを把握する上での参考として頂けますと幸いです。

（参考：Google SREワークブック）

初級者チームのチェックリスト

・人員の配置転換と採用のプランがあり予算が用意されていること
・オンコールサポートの体制があると共に、システム運用の一部を担当していること
・プロダクトのリリースプロセスとセットアップ、ティアダウンがマニュアル化されている
・カナリアリリースを評価している。
・ロールバックメカニズムを用意している。
・運用手引きがある
・定期的なリカバリテストの実施

中級チームのチェックリスト

・チームとしてSREの実績と進捗を定量評価している。
・チームとしてSLIとSLOを定期的にブラッシュアップしている。
・改善を前提としたオンコール体制がある。
・カナリアリリース失敗時のロールバックメカニズムがある。
・インシデント管理を定期的にテストしている。
・開発チームとＳＲＥが障害報告書を定期的に見直している。
・ディザスタリカバリテストの定期的な実施
・チームがキャパシティを客観的に評価している。
・ＳＲＥのロードマップがある、

上級チームのチェックリスト

・SREチーム内の複数名が運用や障害の枠組みを超え、ビジネス上での付加価値を生んでいる。
・プロジェクトが部署横断的に実施されている。
・ほとんどのサービスアラートがSLOバーンレートに基づいている。
・自動化されてたディザスタリカバリテストが用意されている。
・SREのオンコールが24時間365日体制であること。

まとめ

今回は、ますますその重要性が高まっているSREについて紹介しました。前述したように日本ではグローバルスタンダードでSREを実行している企業は多くありません。しかし、SREはあらゆるITサービスプロバイダーの生産性を左右する重要な分野であるため、是非、実践していきたいものです。