目次

●Google発SRE

●SREとは

●SRE誕生の背景

●Google発SRE

SREという言葉を耳にされたことはあるでしょうか。
社会現象にもなった連続テレビドラマ『日曜劇場　半沢直樹』（TBS系）の第3話でも「SREチームをここに呼んで！」で話題になったIT用語です。

SRE (Site Reliability Engineering)は【Reliability＝信頼性】という言葉が使われていることからも分かるように、システムの信頼性に重点を置いたエンジニアの新しい役割です。
2003年Googleで誕生し、2016年に同名の書籍が出版されたことでその考え方やメソッドが広く普及していきました。
2017年8月に日本語版書籍（通称SRE本）が発売されたことにより国内でも徐々に取り入れる会社が増えています。

auカブコム証券では2019年より、この「SRE」を当社流に解釈し、auカブコム流SREを始動させました。
2020年4月には社内で正式にSREグループが発足し、2020年11月現在、すでにチームとしてスタートしてから8カ月立ちました。
7月にはユニリタ社主催「システム管理者感謝の日」にて当社SREのグループ長である道場より【「auカブコム流SRE」とは？　当社の目指すべきサービス運用の形】というタイトルで講演も行い、当社の取り組みをご紹介させていただいております。

さて、本連載(全6回)では日々のシステム運用負荷に課題を抱えていた当社の現場メンバーが、「SREってなに？」というところからスタートし、「auカブコム流SRE」という新しい取り組みを始めたことで、システム運用がどのように変わっていったのか、その成果や実現に至るまでの苦労をご紹介していきたいと思います。
Googleとは企業規模も業界も全く異なる会社ではありますが、SREという運用改善のアプローチを通じて、チームとしての変化や確かな効果を感じています。
すでにSREという言葉をご存じの方も、そうでない方も、連載を読み終えたあとに「当社もSREをやってみよう」と感じていただけるような内容となることを目指しております。
ぜひお付き合いいただけますと幸いです。

では、早速ですが連載第1回となります本記事では以下の２つについてご説明いたします。
●SREとは
●SRE誕生の背景

●SREとは

冒頭でお伝えしたようにSREとはGoogleが提唱した新しいシステム管理者の役割。
「ソフトウェアエンジニアがシステム運用を設計したらどうなるか？」という観点で再定義されたシステム管理者の役割です。
・・・しかし、この説明では具体的な業務をイメージしにくいかと思います。
その役割・業務について理解するにはまず「なぜSREという新しい役割が誕生したか」という背景についてご理解いただく必要があります。
そもそもSREは、Googleが抱えていた「システム運用の２つの大きな課題」に対するソリューションとして誕生しました。

●SRE誕生の背景

当時、Googleではシステムの開発と運用において２つの大きな課題に直面していたそうです。
その２つの課題とは「直接的なコスト」「間接的なコスト」と呼ばれています。

・直接的なコスト
手作業で行っているシステム運用にかかるコスト（システムの大きさに比例して、作業量が増加）

～日々開発しているサービスや製品が徐々にスケール拡大していく過程において、システム管理者として当然管理する対象が大きくなるほど作業量の負荷も比例していきます。
これに対するGoogleの対策は以下です。

【対策】システム運用に伴う作業の多くをエンジニアリングによって効率化・自動化することで、コスト増を低減→GoogleのSREチームは稼働時間の50%以上を自動化等の開発に当てます。
開発の稼働時間が50%を下回る場合、開発チームがSREの仕事に加わります。
また、SREはいつでも開発チームに参加することができます。
誰でもSREの仕事を行い、SREも開発の仕事を行います。

・間接的なコスト
リリース優先の開発担当（DEV）と、安定稼働を目指したい運用担当（OPS）が対立することがあり、利害関係解消のためのコミュニケーションコストが増加

～当然ながらお客さま目線ではサービスの「リリース」と「安定稼働」はいずれも重要です。
新しい製品やサービスは時にその会社を選ぶ決め手にもなるほど重要なものですが、同時に品質・可用性も担保できていることが必要です。
そもそも可用性が保たれていないと、サービス内容以前のところでお客さまに迷惑をかけてしまいます。
開発担当と運用担当は異なる２つの立場から優先順位の非一致が生じ、当社でも度々、開発部隊と運用部隊のコミュニケーションコストが増加してしまうケースが発生します。
これに対するGoogleの対策は以下です。

【対策】エラーバジェット（エラー予算）の考え方を採用し、対立構造を解消。
※エラーが発生すると予算が減り、予算がなくなると開発担当は新しい変更をリリースせず、既存エラーに優先対応する。
予算がなくなるまでは、品質より速度を優先することも可能という開発/運用での取り決め。
→プロダクトマネージャーがSLOと呼ばれる目標値を定義し、サービスの稼働時間を設定。
稼働時間をモニタリングし、エラーバジェットにより、新規リリース可否を管理
※SLOは次回のコラムの中でご説明いたします。

どうでしょうか―「直接的なコスト」「間接的なコスト」という呼び方をしていなくとも、似たような課題がみなさんの会社にもあるのではないでしょうか。

当然ながら当社も類似の課題を抱えておりました。
毎月のように新しく誕生するサービス。そのサービスによってお客さまの願い・思いが実現できるのはうれしいのですが、リリース作業やサービスイン後の臨時的な運用で人的作業が必要になってしまい、運用負荷が増加。
システム規模に対し運用メンバー人数は変わらず徐々に管理しきれなくなってしまう―このようなスパイラルに陥ってしまうこともしばしば・・・。

正直、私は最初にGoogleの２つの課題を聞いたとき、あのGoogleでも当社と同じような課題を抱えているのだと少し意外に思いました。
と同時に、共感できる部分が多いため一層そのソリューションで改善に至った「SRE」に興味が湧いてきました。

2019年秋、当時の運用メンバーで“チームの在り方”を話し合っていた時に、「最初からGoogleのSREのようには動けなくとも、当社流SREをスタートさせてみよう」とメンバーから発案。
まず当社が抱える課題をしっかり見据え、当社の運用に期待されている役割は何か―？お客さま目線・経営者目線で時間をかけて考えました。

おそらく、Googleも最初から理想通りの改善効果が得られたわけではないと思いますが、“既存の仕組みを積極的に変えていくというGoogleの文化はやはり参考になります。

１回目のコラムはこちらで終わります。
SREに関する基本的な説明、なぜSREという役割が誕生したのか、その背景をご説明いたしました。
次回からは具体的にSLI、SLOなどのキーワードと合わせて具体的な「SREのはじめ方」をご紹介していきます。
引き続きよろしくお願いします。