全2回　スピードと安定性を両立～新たなシステム運用プロセス「SRE」とは？ 《連載:第1回》 攻めの運用を目指すなら知っておきたいSREの基礎知識

ビジネス環境が加速度的に変化している現在、IT部門に求められる役割も従来の“守りを担う組織”から“ビジネスの成果に貢献する組織”へと大きくシフトしています。もはやあらゆる業務において、これまで当たり前とされてきたやり方を見直すタイミングが来ていると言っても過言ではないでしょう。今回は中でもIT部門にとって重要な業務、システム運用の新たな手法「SRE」の基礎知識を紹介します。

SREはなぜ“新しい”のか？

Google発の手法

SREは元々Googleが提唱した概念で、“Site Reliability Engineering（サイト信頼性エンジニアリング）”の頭文字を取った言葉です。“サイト”という言葉が使われているのはGoogleの検索エンジン『Google.com』の運用管理プロセスをモデルにしているため。ただし実際は、Webサイトに限らずIT環境全般を対象としています。

SREの大きな特徴として、サービス／システムの“信頼性”を最重視している点が挙げられます。信頼性という言葉が抽象的に感じるようなら、“ユーザーエクスペリエンス（UX）”と言い換えても良いでしょう。Googleも『SRE fundamentals 2021: SLIs vs SLAs vs SLOs』というWebページで、「最終目標は、サービスを改善し、ひいてはユーザーエクスペリエンスを向上させること（The end goal of our SRE principles is to improve services and in turn the user experience.）」と述べているからです。

従来の運用との違い

SREと従来の運用とでは、開発に対するスタンスが大きく異なります。従来は開発チームと運用チームは完全に分かれて作業をおこなうのが一般的でしたが、SREでは運用と開発が連携・協力し、「一緒にサービス／システムを作り上げていく」というスタンスが求められます。このスタンスこそが、SREが「攻めの運用」と言われる所以（ゆえん）です。

実際の業務は企業によって様々ですが、例えばアプリケーション開発の場合、運用チームがCI/CD（継続的インテグレーション／継続的デリバリー）を導入し、バグ修正やデプロイ（本番環境への移行）自動化のような開発効率向上のための取り組みを担当することもめずらしくありません。そのため、SREを担当するエンジニア（SREエンジニア）は、インフラの構築・運用だけでなく、ソフトウェア開発に関する知見も必須とされています。

SREが広まっている背景

SREの普及が進んでいる背景としては、システム／サービスにおいて“スピード”とともに“安定性”が重視されるようになったことが挙げられます。スピード向上策として、近年、多くの企業がオンプレミス環境のウォーターフォール型開発からクラウドベースのアジャイル開発への移行を進めていますが、特に大型かつ複雑なシステムの場合、スピードを優先すると安定性が脅かされるというデメリットが生じます。そこでその最適解として、運用・開発が連携することで安定稼働と開発効率向上の両立を実現させるSREに注目が集まっているという訳です。

また、SREを実現する手段として「IoC（Infrastructure as Code：コードとしてのインフラストラクチャ）」の登場も無視できません。IoCとはインフラをコード化し、クラウド環境でシステムインフラの構築・運用を自動化する手法。これまで人が手動でおこなっていたタスクの多くを置き換えることができるため、運用担当者が運用プロセス全体の設計や改善にリソースを割けるようになるというメリットがあります。

SREの重要キーワード

では具体的にSREではどのような取り組みをおこなうのでしょうか。先ほどは例としてCI/CDの導入を挙げましたが、他にも次のような取り組みがおこなわれています。

• 開発・運用効率化のための自動化推進（CI/CD導入、トイル削減など）
• SLI/SLOの策定
• モニタリング（モニタリング基盤の導入含む）
• 障害対応（オンコール対応含む）
• ポストモーテム

これらはあくまで一部であり、実際は組織やシステムの形などによって様々です。ここではそれぞれの取り組みについて詳しく説明する余裕はありませんが、いくつかSREの重要キーワードが含まれているので説明していきます。

●トイル

直訳すると「労苦」。いわゆる割り込みタスクのような作業を指します。Googleの『SREの原則に沿ったトイルの洗い出しとトラッキング』では、トイルに該当する作業として「手作業」「繰り返される」「自動化が可能」「長期的な価値がない」「サービスの成長に比例して増加する」といった特徴が挙げられています。

トイルを削減・最小化するためには、まず業務の中からトイルを洗い出し、その影響（作業に要する時間）を測定し、自動化できるものについてはコードやツールで自動化していくというアプローチが一般的です。ちなみにGoogleのSREでは、サービス拡大や機能リリースなどの重要業務に関わる時間を確保するために、各自トイルに費やす時間を勤務時間の 50% 未満にすることを目指しているということです。

●SLI/SLO

SLIとSLOはシステム／サービスの“信頼性”を測るために策定する定量的な指標です。

・SLI（Service Level Indicator：サービスレベル指標）

サービスの稼働状況を示す指標です。一般的には障害発生件数、正常レスポンス率、システム稼働率など、システムの可用性や待ち時間、耐久性を示すメトリクスを設定します。適切なSLIを選ぶポイントは、ユーザー満足度との関連性が高い、モニタリングが容易など。いたずらに指標の数を多くしないことも大切です。

・SLO（Service Level Objective)：サービスレベル目標）

SLIを計測した上で策定する、一定期間内に達成すべき目標値です。注意点は「可用性100％はNG」ということ。先述の通り、SREでは“安定性”だけでなく“スピード”も重視するため、ある程度の障害や不具合は許容しなければならないからです。通常はSLOと併せて、“特定期間内において許容できるダウンタイム”を示す「エラーバジェット（非信頼性予算）」という指標を設定します。

なお、SLI/SLOは“信頼性”というユーザーに関わる指標のため、策定時にはユーザーとの距離が近いビジネス部門の同意が不可欠です。またプロジェクト開始後も、ダッシュボードで推移を共有し、定期的に「本当にユーザーからの信頼感につながっているのか」と見直すことが欠かせません。

●ポストモーテム

不具合や障害の事後検証として作成するドキュメントを指します。作成目的は、メンバー間でインシデントの再発防止及びサービス改善のための“学び”を得ること。いわゆる上長向けの報告書や謝罪文とは役割が異なります。

一般的な記載内容は、根本原因、影響、アクションアイテム（再発防止策）、教訓など。ただし、ポストモーテムの作成には時間と労力を要するため、あらゆるインシデントについて作成する訳ではありません。事前に作成すべきインシデントの基準を決めておく必要があります。

後半記事では実際の企業事例とともに、SREの最初のステップである“チーム作り”のポイントを紹介します。