SREは運用チームだけの問題？ 開発者のメリットをGoogle×スリーシェイクがプラクティスとともに解説！

　もともとSREはGoogleがサイトの信頼性を高めるために、新しい部署を作り、ゼロから作りあげたものだ。今回はGoogleでオブザーバビリティ領域を担当する山口能迪氏とともに、SREの歴史や原則を確認し、アプリケーション開発者にも恩恵がある部分について語り合ってもらった。

株式会社スリーシェイク Sreake事業部 部長 手塚卓也氏

信頼性向上のためにGoogleが作りあげたSRE、その現在地とは

――まずはこれまでのご経歴や現在の役割について簡単にお聞かせください。

手塚：2016年にインフラ系ベンチャー企業に就職しインフラエンジニアとしてキャリアをスタート、スリーシェイクには2018年に入社し顧客企業へのSRE立ち上げ支援などを行ってきました。現在はSRE総合支援やセキュリティサービスを展開しているSreake事業部の部長としてチーム全体を見ています。

山口：前職は外資系パッケージベンダーで製品やソリューションの検証環境構築および運用をしていました。2011年にGoogleに転職し、YouTubeの技術営業を経て、デベロッパーリレーションズエンジニアとしてさまざまな技術領域を担当してきました。2018年からはオブザーバビリティ領域を担当し、Google Cloud Operation Suite（旧：Stackdriver）の普及、オープンソースではOpenTelemetryプロジェクトの推進などに関わっています。

――SRE（Site Reliability Engineering）について、 改めて誕生の経緯や概要を教えてください

山口：かつてGoogleではシステムアドミニストレーション（運用）と開発の部署が分かれていましたが、サイトの信頼性を高めるために新しい手法で取り組もうと、新しい部署が立ち上がったのがSREのはじまりです。Googleの外ではDevOpsも発展していく中で、GoogleはゼロからSREのプラクティスを作りはじめ、後に書籍にあるように体系化し、アプローチを定着させてきました。

――GoogleがSREを始めてから長い時間が過ぎました。これまでに起きた変化や現状をどうご覧になりますか？

手塚：SRE本と呼ばれる『SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム』（オライリージャパン）の原著が出たのが2016年4月、日本語版が2017年8月でした。最初はバズワード的なものでしたが、近年では国内でもさまざまなイベントが開催されるようになり、より実践に焦点があたるように変化したと感じます。

　運用やインフラ担当で、日々アラートや障害対応に追われていた身からすると、SRE本を読んだときに「SREで全部解決できる」と期待してしまいたくなるのですが、実際はそうではありません。本にあることはあくまでGoogleさんの中でのプラクティスなので、当然そのまま適用できるとは限らないですし、実際には泥臭い部分も多くあります。その中で近年では実践にまつわる事例も増えてきた印象があります。スリーシェイクもエンタープライズからスタートアップまで幅広く経験しながら、いろいろと見出しているところです。

山口：最近ではSREに関するカンファレンスや記事、SRE組織を立ち上げたという発表も見るようになりました。Google社内では長らく実践する中でツールや手法の変化はありますが、「ユーザーの信頼性が大事」という原則はぶれずに守られています。

　一方、外部の話を見ていると「自組織においてユーザーの信頼性をどうとらえるか」というようなSREの原則にあたる部分があまりフォーカスされていないのが気がかりです。

手塚：SLO（Service Level Objective：サービス提供側が達成すべき目標）を決めるのは監視ではなくユーザーだというフレーズを見ましたが、そういったユーザー目線を基本にして運用を回していくのがSREの実践に求められる肝の部分だと感じます。その中で、「SREは組織を作れば解決する」という考えには少し違和感があります。本来の目的はSREに求められている原則を実践することだと思うので、究極的には組織はあってもなくてもいいというのが個人的な考えです。また、それは必ずしも単一組織の中で行われるものではないと思います。