SREの視点で見直すCorporate IT - Google Site Reliability Engineering学習録

はじめに

SREとCorporate ITの類似性から学ぶ

組織の情報資産やデバイス、アカウント管理を行うことはCorporate IT（いわゆる情報システム部門を含む）にとって重要な業務領域の1つです。一方でSREはサービスの信頼度を維持し高めるための活動を行っています。SREの市場価値を考えてみても、その役割の重要性がうかがえます。

SREの観点でCorporate ITの業務を捉え直してみることで、多くの学びがありそうです。そこで今回はオライリーから出ているSite Reliability Engineeringの冒頭の部分を読んで、ざっくりと全体像を学んでみたいと思います。

学んだこと

SRE Handbookを読んで学んだことを3つまとめていきます。

SLA, SLO, SLIの違い

まずは用語の違いです。なんとなく知っているつもりだったのですが、改めての整理しました。

SLAはサービスの提供者と利用者間の契約と言えます。

SLOはSLAの達成のための具体的な目標。

SLIはSLOの達成度を計測するための指標です。

SLAのみサービスの提供者と利用者間の取り決めてあり、SLOとSLIは提供者の内部的な目標や指標になっていることがポイントでしょう。

HandbookではProduct Managerによって、SLOが設定され、サードパーティのモニタリングシステムで稼働時間が計測され、2つの数値の差（Error budget）が非可用性を表すと説明されていました。

また、稼働時間がSLOを上回る時に新しいリリースがなされるということでした。

Error budgetのいいところは、新しいリリースと適切なサービスの稼働状況の正しいバランスが保たれることにあるようです。

新しいリリースばかり続くが稼働が止まったり、バグが多かったりするとユーザー体験が悪くなり、最終的にサービス利用者が離れてします可能性があることを考えると、SLOがSLA達成の目標にもなりつつ、内部的にはサービス管理の目標となっていることも納得できます。

SREにとっての課題はCorporate ITにとっての課題にもなる

2つ目の学びとしては、SREの成り立ちにも関連するです。Googleは2003年にSREを導入したようですが、もともとはサービスの提供に関する課題がありました。

DevとSysadminと表現されていますが、開発し素早く提供しようとするDevelopmentと安定的な運用とシステムが止まらない、壊れないことを目指すSysadminにコンフリクトがあったようです。

また、Sysadmin側の課題としては、すべてのシステムを把握するコストの増大や、システムの増大に対応するためのチーム拡大が必須で、その場合の人件費の増加はもとより、属人化や労働集約的な働き方があります。

これらの対策として、人が行なっていたことをSotwareでデザインし、自動化を導入する。そうすることで、業務量が増加しても人の追加を必要としない仕組みを目指していました。

だからこそ、SREはSoftware Engineerであり、SysadminやOpsの業務は業務全体の50％以下になるようにする必要がありました。

もちろん、何に時間を使っているのか計測する必要もあります。

また手作業を減らし、そもそも手作業が増えるようなサービスや業務を作らないことが大切ということでした。

このたりの考え方はCorporate ITとしても非常に勉強になります。

例えばIT Help Deskはメンバー50名〜100名に1人が主流になっていますが、組織の拡大に従ってチームメンバーを増やす必要があったり、メンバーによって提供できるサービスレベルに差が生まれたりといったことがあります。SREの課題をCorporate ITにとっての課題と捉え直せば、労働集約的な考え方から脱却するための業務設計が必要だと理解できます。

AIエージェントの普及による影響

Help Deskだけでなく、社内でのAI活用を考えてみても学ぶことはあります。

例えば社内のワークフローにAIを組み込む場合には、まさにサービスの社内への提供に関する課題を解決し、サービスの改善をしていくことをCorporate ITが担う必要がありそうです。

このような場合には、ワークロードが増加しても人の追加採用を必要としないだけでなく、サービス稼働状況をモニタリングし、ワークフローの安定的な運用と機能の改善をバランスよく行なっていく必要があります。

この点に関しては、Chapter 3のアベイラビリティ（可用性）に関する説明がわかりやすいです。適正なバランスとは予期しないシステムのダウンを計測することで、可用性の担保を目指す方法です。

分かりやすいのはシステムのダウンタイムを計測する方法だと思いますが、リクエストベースでの計測も紹介されています。リクエストベースの場合は、可用性をリクエストの総数で成功したリクエスト数を除することで求めます。

どちらが正しいということではありませんが、Corporate ITもエンドユーザーの視点で予期しないダウンを計測できるようになるとAIエージェントの活用などでも活用できそうです。

難しかったこと

SLIの設定方法

SLIの設定に関して、機能リリースをCorporate ITがどのように扱うかに関しては、取り扱い方が難しいと感じました。

記事内では、サービスの稼働時間がSLOを上回る時に、新しいリリースが追加されるとなっていますが、Corporate ITにとっての機能リリースを社内へのサービスの導入と捉えると、サービスの可用性をサービスに依存することになり、Corporate IT側でコントロール出来ないことになってしまうためです。

解決方法としては、内製化しているシステムのみサードパティのモニタリングシステムで稼働時間を計測するなどでしょうか。

SLIの設定方法として考えられること

• レイテンシ（内製化しているシステムのリクエスト処理にかかる時間）
• エラー率（システム連携を行ったことことで失敗したリクエストの割合）
• スループット（単位時間あたりのリクエスト処理数）
• 飽和度（システムリソースの使用率）

この辺りはぱっと具体例を出せなかったので、引き続き考える必要がありそうです。

また、モニタリングと記載されていましたが、今のトレンドだとオブザーバリティのことを指していると考えられます。今回触れることはしませんが、ざっくりとした両者の違いとしては、モニタリングが、システムが正常に動いていることを確認するのに対して、オブザーバリティはなぜシステムがその状態にあるのかを理解するということでしょう。

終わりに

今回はSite Reliability Engineeringの冒頭の部分を読んだ感想をまとめました。

SREのコンセプトを学び、Corporate ITの領域に活かしていくことは、社内のSaaS連携やシステムの内製化、AIエージェントの活用増加に伴って求められる動きになりそうです。組織の資産管理だけでなく、信頼性の向上のための活動ができるようになると、Corporate ITとしてのレベルが上がるのは間違いないと感じました。