SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

インフラ技術のトップランナーと行く、開発者のためのSRE探求(PR)

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に求められている原則を実践することだと思うので、究極的には組織はあってもなくてもいいというのが個人的な考えです。また、それは必ずしも単一組織の中で行われるものではないと思います。

次のページ
開発効率と開発者体験の向上に繋がるSREのプラクティス

関連リンク

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
インフラ技術のトップランナーと行く、開発者のためのSRE探求連載記事一覧

もっと読む

この記事の著者

加山 恵美(カヤマ エミ)

フリーランスライター。茨城大学理学部卒。金融機関のシステム子会社でシステムエンジニアを経験した後にIT系のライターとして独立。エンジニア視点で記事を提供していきたい。EnterpriseZine/DB Onlineの取材・記事や、EnterpriseZine/Security Onlineキュレーターも担当しています。 Webサイト:http://emiekayama.net

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

丸毛 透(マルモ トオル)

インタビュー(人物)、ポートレート、商品撮影、料理写真をWeb雑誌中心に活動。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/16020 2022/07/07 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング