重要さが増すサービスの「信頼性」を高めるためにSREエンジニアたちが続ける挑戦

ヤフーのPrivate PaaS、KaaS、スタディストのTeachme BizにおけるSREの取り組み

若手向け 2020/09/17 16:00

　SRE（Site Reliability Engineering）は、サービスやインフラの信頼性にまつわる多くの課題を、ソフトウェアの力で解決していこうとするアプローチとして注目を集めています。企業にとって、ITシステムがビジネスに大きなインパクトを与えるようになった現在、多様なシステムの「信頼性」を確保し、高めていくための取り組みは重要性が増しています。今回、ヤフーでSREに向けた取り組みを続けている水落啓太氏、増田彬氏と、スタディストで開発部副部長兼SREを務めている北野勝久氏に、それぞれの企業で、どのようにSREに取り組んでいるのか、今後SREの領域で注目すべきテーマは何かについて語ってもらいました。

Private PaaS、KaaS、B2B SaaS……それぞれのSREの役割

水落：ヤフーの水落です。本日はよろしくお願いします。私は、入社から2年間広告システムを担当し、その後Private PaaSのチームに異動しました。従来どちらかというと運用ではなく開発専門で、恥ずかしながらシステム運用に対して意識が低かったのですが、Private PaaSのプロダクトオーナーとなり、その改良に取り組む中で意識が変わりました。PaaSの最大のプロダクト価値は「安定性」だということに気付き、そこからSREの勉強を本格的に始めていきました。現在は、プロダクトオーナーではないのですが、現場のエンジニアとして引き続きSREへの取り組みを続けています。

増田：ヤフーの増田です。よろしくお願いします。私は、新卒入社から4年間、PaaSのSREチームに所属し、SREのプラクティスを社内に普及する取り組みを続けてきました。昨年の11月からは、KaaS（Kubernetes as a Service）チームへ異動し、サービス開発チームにKubernetesをうまく利用してもらい、より効率的かつ安定的にサービス展開や運用ができるような仕組み作りを進めています。

北野：北野です。B2BのSaaSプロダクト「Teachme Biz」を開発するスタディストで、開発副部長兼SREを務めています。私は、中途でスタディストに入社後、しばらくはアプリケーション開発をメインで手がけていました。以前は、インフラ運用についてCTOが1人ですべてを見ていたのですが、並走者を置いたほうがいいということになった際に、私もそれを手がけるようになりました。その後、徐々に手作業が中心だったインフラ運用を、コードを使って自動化する作業を進めました。そうした経験を通じて、システムの信頼性と、組織のアジリティの実装をソフトウェアで実現していくSREのアプローチに強く関心を持つようになりました。

　社内でSRE的な取り組みを始めたのは2017年くらいからになります。並行して、SREの勉強会「SRE Lounge」や、日本初のSREのカンファレンス「SRE NEXT」といったコミュニティ活動も行っています。よろしくお願いします。

増田：今年1月の「SRE NEXT」では、私も「40000コンテナを動かすPaaS SREに至るまでの道」というタイトルで発表をさせていただきました。その際は貴重な機会をいただき、ありがとうございました。（発表資料）

増田彬（ますだ・あきら）氏

　ヤフー株式会社システム統括本部 KaaS CRE。2016年に新卒でヤフーに入社。社内向けPaaSのSREチームを約4年経験した後、社内向けKaaS（Kubernetes as a Service）チームのSREへ異動。現在は、KaaS CRE（Customer Reliability Engineering）チームのメンバーとして社内のKubernetesユーザーのサポートやコンサルティングを行っている。また、PaaS、KaaSで培ったGo言語の経験を活かし、ヤフーのGo言語サポートチームにも所属している。

ヤフーとスタディストのSRE体制は？

北野：お2人は、社内のPaaSやKaaSといった領域でSREに取り組まれているとのことですが、今、ヤフーのサービスインフラはどのような状況なのでしょうか。

水落：現在、全社でモダナイゼーションを進めています。従来は、サービスごとに実機や仮想マシン（VM）で構築していたものを、コンテナやサーバレスといった、よりモダンな環境に切り替えていっている状況です。

　ヤフーの各種サービスを動かしている社内向けの基盤としては、主に「IaaS」「PaaS」「KaaS」「FaaS」の4種類があるのですが、モダナイゼーションが終わった際には、全体の7～8割のワークロードがPaaSやKaaSの上で稼働する見込みです。

北野：水落さんは、以前社内PaaSのプロダクトオーナーを務められたそうですが、その時、PaaSの環境をどのように改善されたのですか。

水落：PaaSの導入が始まった今から2～3年前は、まだサービス開発に関わる人たちに「PaaSとは何か」を知ってもらい、使い始めてもらうフェーズでした。それが実を結んで、社内でPaaSのスケールがばく大なものになり始めたころ、プロダクトオーナーを務めることになりました。当時アプリケーション数が1万4000、コンテナ数が5万といった規模で、PaaSの安定性に対する責任が、日に日に重くなっているという状態でした。障害を起こすことが、ビジネス上の大ダメージに直結する状況で、チームとして、組織的に安定性を高められる体制を作ることが課題でした。

北野：KaaSについてはどうですか？

増田：直近でのKubernetesの利用規模としては、使っているチームが約210、Kubernetesクラスタ数が約680、ノード数が約1万3000、コンテナ数が12万以上となっています。ヤフーのKaaSは、サービス開発チームにKubernetesクラスタを払い出す際に、Prometheus やGrafana、Alertmanagerといったスタンダードな監視ツールもセットで提供して、サービス開発チームがKubernetes運用を簡単に行えるということをしています。

北野：ヤフーでは、SREとしての開発をどのように進めているのでしょう。

水落：私が一番大切だと思っているのは、基本ではありますが、きちんとサービスレベルを設計・定義した上で、指標として計測し、その結果を判断や行動に生かしていくということですね。

　PaaSチームでは、SREのエンジニアとプロダクトとしてPaaSを作るエンジニアをチームとして分けていません。ですので、PaaSとしての価値を高めるために、機能を充実させるべきか、安定性を上げるべきかといった議論が常にあります。手法としてはスクラムを取り入れていますが、人数が増えると方向性の認識合わせも難しくなってきます。そのためにも、指標から得られる定量情報をもとに議論と行動ができるチームを作っていくことが大事だと思っています。

増田：KaaSチームでは、ユーザーとなる社内のサービス開発チームに対してKubernetesクラスタを払い出しているため、実際はサービス開発チームがSREの役割を担います。それに加えてKaaSチームではユーザー自身が問題と感じていないような事象も検知して手を打てるような体制を作っています（より具体的な内容についてはKubeFest Tokyo 2020にて発表）。例えば、物理的なサーバを共用しているKaaS上で、特定のユーザーが極端にCPUワークロードを上げてしまうと、他のサービスにも悪影響が出ます。いわゆる「ノイジーネイバー」問題ですが、KaaSチーム側で状況を把握し、もし、そのような使い方をしているユーザーがいれば、状況を確認して、より問題にならないような使い方を提案するといったことも行っています。スタディストでのSRE体制はどのようになっているのでしょうか？

北野：スタディストでは「Teachme Biz」というB2BのSaaSプロダクトを開発しています。これは、SOP（標準作業手順書）のプラットフォームサービスです。利用する企業ごとに契約をしていただくのですが、一社で大規模に利用いただく事例もあり、B2Bサービスではありながらも、トラフィック量はそれなりに大きい点が特徴です。

　開発では、期間を区切り、細かくリリースするよう意識しています。現状は、機能開発を行っているチームと併走しながら実装する機会も多いため、プラットフォーム移行などの中長期にむけた開発は、フレキシブルに動きやすい状態を維持しています。

北野勝久（きたの・かつひさ）氏

　株式会社スタディスト開発部副部長兼 SRE。日本タタ・コンサルタンシー・サービシズでERPシステムの構築等に携わった後、スタディストに入社。SOP（標準作業手順書）のプラットフォームサービスである「Teachme Biz」の新規機能開発や、システム運用業務自動化の実装等を担当した後に現職。コミュニティ活動として、SREの勉強会「SRE Lounge」や、日本初のSREのカンファレンス「SRE NEXT」を主宰する。

信頼性目標の設定と活用が共通の課題

北野：ヤフーでSREを進めていくにあたって、現在特に課題と感じていることはありますか。

水落：「エラーバジェット」という概念の活用が課題です。エラーバジェットは、SLO（サービスレベル目標）に基づいて算出される「損失可能な信頼性」のことなのですが、一般的には、余ったエラーバジェットを利用して、新機能リリースのようなアグレッシブなことをやります。エラーバジェットの活用はサービス開発のアジリティに影響します。

　特に課題と感じているのは、高いSLOについてのエラーバジェットです。例えば月間SLO 99.99%のサービスについてエラーバジェットはわずか4分半です。4分半とは、実質的には「落としたら終わり」であり、保守的にならざるを得ません。せっかくのエラーバジェットをなかなか活用できない訳ですね。

　ただ、この課題は改善できるかもしれないと思っており、SLI（Service Level Indicator）を使った自動検知による自動ロールバックといった手法を駆使することで、わずかなエラーバジェットでも、できることを増やせるのではないかと思っています。そうして積極的なエラーバジェット活用を実現し、アジリティが向上した体制を、今後1年くらいで作っていきたいですね。

増田：ヤフーの場合、プラットフォームの規模が大きいので専任チームでプラットフォームの運用を行っています。そのような事情で、どうしてもプラットフォームチームとサービス開発チームとの距離が遠くなりがちなのが課題だと思っています。

　また、私はSREの本質的な功績は「運用」を科学したことだと思っています。サービスを運用していく上での「信頼性」に対して、合理的な理由で判断が行える仕組みを作れるというのが、SREの真骨頂ですよね。プラットフォームが止まることで、ビジネスにどのくらいのインパクトがあるのかが客観的に判断できれば、サービスのアプリケーションごとにサービスレベルを設定し、運用時の判断軸にできます。

　現状の課題は、動いているサービスに関わるビジネス的なKPIと、SREのSLIとのひも付けが十分にできていないことだと感じています。それがないと、ビジネス側から信頼性を高めてほしいとの要求があれば、どんな状況でも対応せざるを得ず、オペレーターは疲弊する一方になってしまいます。スタディストではどうですか。

北野：ビジネスとSREのひも付けに対する課題感は、スタディストでも同じですね。SREの取り組みの成果が、ビジネスKPIにどう結びついているかが分かる仕組みは作っていきたいと思っています。特にTeachme Bizの場合はB2Bのサービスなので、B2Cのサービスと比べて、サービスのダウンタイムと機会損失規模の関係が見えづらく、そのあたりから考えていく必要性を感じています。

　スタディストの場合、信頼性の目標については、プロダクトマネージャーと議論して決めたのですが、ビジネスに関する機能開発の優先順位付けに権限を持つ人と、あらかじめ合意形成をするのはポイントだと思っています。SREの醍醐味はリライアビリティとアジリティの双方を制御することですが、ビジネスとSREの成果の関係性を透過的に見られる仕組みがあるとよいな、と思っています。

水落：ビジネスと信頼性との関係を議論する時、ビジネス側の立場としては、どうしても「落ちたらダメでしょ」になってしまうので、そこでやり合ってしまうと勝てないですよね（笑）。私のチームでは、ユーザーからの問い合わせ内容を判断根拠にして、信頼性の目標値を適正値に変更することがあります。例えば、目標値を変更してもそのサービスに関する問い合わせが発生しないということはビジネスに影響がないなど、ユーザーからの問い合わせはビジネスと信頼性の相関を見るのにある程度使えるのではないでしょうか。また、問い合わせ数として指標化も比較的容易ですので、信頼性目標に関する定量的な議論にも役立てやすいですね。

水落啓太（みずおち・けいた）氏

　ヤフー株式会社システム統括本部 Private PaaS SRE。2015年4月にヤフー入社。マーケティングソリューション部門で広告システム開発に従事した後、システム統括本部Private PaaSチームへ異動。Private PaaS基盤についてSREの取り組みを推進している。

SREを広く知ってもらう「草の根活動」が成果を高める

増田：今、スタディストでは何人くらいのエンジニアでSREに取り組んでいますか。

北野：Teachme Bizだと3名ですね。

増田：サービス開発側とのSREに関する意識の共有はどういう形でやっているのでしょう。

北野：SREとサービス開発の人とでいっしょに課題を解消するためにペアプログラミングをしたり、社内勉強会でSREの取り組みを発表して関心を持ってもらったりといった形が中心です。ヤフーではどうですか。

水落：ヤフーのエンジニアは数千人いるのですが、組織として意識共有を目指すとき、一番効果が出やすいのは「事例」を作って共有することだと思っています。私のチームでは、ポストモーテム（障害の事後検証）を公開して、障害の再発防止策の共有だけでなく、SREとそれに取り組んでいるチームが社内にあることをなるべく広く知ってもらえるようにしています。

増田：KaaSチームの場合は、PaaSと同様に事例も共有しつつ、例えば、Grafanaをどう使えば、システムが安定していると判断できるのか、サービス開発チームと一緒に確認する機会を作っています。そのほかにも、例えばLinuxの特定のメトリクスがあるサービスで問題になったら、それが他のチームのナレッジとしても生かされるように情報共有するといった啓蒙活動をしています。

水落：そのあたりは、CRE（Customer Reliability Engineering）と呼ばれる領域になりますね。

北野：あるチームで問題になった事例をプラットフォームに展開するのは、サービス開発チームがプラットフォームのリポジトリにプルリクエストを送ることもできると思うのですが、そのあたりの運用はどうされているのでしょうか。

増田：実際のところ、ユーザーからアラート設定ファイルへのプルリクエストで改善されるというのが理想ではあります。ただ、ヤフーの場合、SREのノウハウがまだ十分には社内に浸透していないことに加えて、KaaSがヤフーの子会社であるZ Labで開発されているということもあり、開発形態的にも難しいという事情があります。

　SREにとってメトリクスはとても重要で、あるサービスが安定しているかどうかは、そのサービスを運用しているチームが一番よく理解しています。ですから、サービス開発チーム側でメトリクスを設計してアラーティングを改善できるというのが、本当は一番良いのですよね。将来的には、そうしたことができる環境にしていきたいと考えています。

Kubernetesを活用するメリットと「難しさ」

増田：北野さんにお伺いしたいのですが、スタディストではKubernetesを使っていますか。

北野：ちょうど移行を行っている最中です。現在は、Amazon EC2と一部機能の提供にECSを利用していて、それぞれを独立してデプロイできるようになっています。今後も新機能をコンテナとして内部的には分割されたサービスとして提供することを予定しているため、それらを一つのプラットフォーム上に集約するべく、Kubernetesを採用しました。Kubernetesの「Platform for building platforms」という思想が、私たちのチームの目指す姿に近いと感じており、今後、活用を本格化させていく意向です。

水落：デプロイまでのプロセスの迅速さという点でも、コンテナ化のメリットは大きいですよね。障害対応の際にも、VMよりコンテナのほうが、復旧までの時間を短縮できます。

北野：スタディストでは現在、ブルーグリーンデプロイメントを採用しているのですが、VMをベースにしていると新しい環境をリリースして、前のものを消す一連のプロセスにかかる時間が非常に長く感じます。全面的にコンテナを採用することで、より迅速にデプロイできるようにしていきたいですね。

増田：Kubernetesを本格的に使っていく上で、課題と感じていることはありますか。

北野：現在はSREを中心にKubernetes移行の実装を行っていますが、最終的には、サービス開発者が自分たちでマニフェストを書いて運用していく姿を目指しています。その理想を実現するために、Kubernetesに関する知見の共有や委譲を、他の会社ではどうやっているのかを知りたいと思っているところです。

増田：社内のKubernetesユーザーが増える一方で、それを正しく使っていく方法をどう確立するかについては、ヤフーのKaaSチームでも課題と捉えています。現時点でわれわれがとっている戦略のひとつは「使える機能を絞る」ことです。一見、Kubernetesの思想に反していると思われるかもしれませんが、自由度の高いプラットフォームをそのまま自由に使えるようにしてしまうと、対応しなければならないことが多くなりすぎるのですね。ですので、KaaSチームで検証済みの部分に関してのみ、ユーザーに「こういった使い方ができる」と案内する方法をとっています。

　そのため、現時点では社内で提供していない機能もあります。認証関連の機能についてはもっと自由に使いたいというニーズも高いのですが、監査をどうするかといった課題もあり、なかなか難しいですね。これについては、サービス側の要望を聞きながら、提供する範囲を考えていこうと思っています。Kubernetesを本格的に使うにあたっては「少しずつユーザーが使える機能を増やしていく」というのがポイントかもしれません。

北野：非常に参考になります。プラットフォームの提供方法以外で、取り組みは何かされていますか。

増田：現状だと、Kubernetesのハンズオンのチュートリアル動画を作ったり、社内の勉強会で説明する機会を作ったりといったことが中心です。あと、問い合わせ管理ツールを使って、過去にあった質問やFAQなどのナレッジをドキュメントとして公開することもしています。

水落：ドキュメントに関する標準化の取り組みは、KaaSに限らずどのプラットフォームでも力を入れていますね。あと、先ほど「使える機能を少しずつ増やす」という話が出ていましたが、SLOを定義できないまま機能公開するのは絶対的な悪手だと思います。それをやると、結果的に機能の信頼性がガタガタになりユーザーに迷惑を掛けてしまう結果になりがちです。SLOに限らず、きちんとレビューを通ったものを公開するという手順を踏んでいくのが重要ですよね。

SREの領域では「Observability」（可観測性）の動向に注目

北野：みなさんが、SREの領域で最近特に注目されているトピックはありますか。

増田：私としては「Observability」（可観測性）の動向にとても関心があります。Observabilityについて説明するとき、私はいつも「緑色蛍光タンパク質」を例に出すのですが、これは、2008年に下村脩博士がノーベル化学賞を受賞して有名になったテーマです。それまでの生物に関する研究では、例えば投薬に対して生物の体内で細胞がどのような振る舞いをするのかについては、死んだ後にしか調べることができませんでした。しかし、緑色蛍光タンパク質の応用方法が確立されたことで、生物が生きた状態のまま、細胞の振る舞いを目で見える形に「可視化」できるようになったのです。これは、生命科学や医学の分野で画期的なことでした。

　この「可観測性」は、SREにおいても大きなトピックだと思っています。人間が何かを理解するためには「見える」ことが重要ですし、システムに携わる人々が認識を合わせるためには客観的な指標が、みんなに「見えている」ことがポイントです。それに基づいた合理的な判断もしやすくなります。

　Observabilityでは「ログ」「メトリクス」「トレーシング」が3本柱とされていますが、今後、SREがこれらをどのような形で利用していけるかは興味深いですね。現状は、3本の柱それぞれで標準となるツールが個別に出てきていますが、Observabilityという概念のもとに統合され、活用されていくのではないかと考えています。

北野：大規模なサービスになると、複数の小さなサービスが連携しあって、あたかもひとつのまとまりとして動くこともあるので、生物や細胞の世界の話と関連付けるのは納得感がありますね。

増田：いわゆる、システムの「マイクロサービス」化ですよね。マイクロサービス化が進めば進むほど、コンポーネント間のつながりは外から見えにくくなっていきます。何か異常が起きた時、長年運用に携わってきた人なら過去の経験による「カン」で、うまく対応ができるかもしれませんが、ビジネスとして運用しつづけるサービスがそれでいいのかという問題はあるわけです。そうした異常を可視化による科学的なアプローチで明らかにし、だれであっても、効率的かつ合理的に対応できるようにしておく必要がある。そうした取り組みは、これからますます重要になるだろうと思います。

水落：先ほど話した「エラーバジェット」にも、Observabilityは関係してきます。障害が発生した時に、いかにエラーバジェットを消費せずに対応ができるか。また障害回復時間を早められるか。障害発生時にObservabilityが確保されていなければ、問題の所在が分からず、どこから手をつけていいのか見当もつけられません。

　また、スキルの高いメンバーに依存しにくいチームを作るという点でも、Observabilityは重要だと思います。高いスキルを持ったSREエンジニアを揃えることが難しい状況でも、システムのObservabilityが確保されていれば、そこから得られる情報を材料としてチームでの議論の質を高められるはずです。SREに携わるエンジニアにとって、Observabilityは無関係でいられないテーマです。

　一方、Observabilityに加えて適切なサービスレベルの設計やSLOについて、いかに改善の議論を活発化していくのかという部分にも関心があります。先ほどと逆にですが、この点についてはハイスキルなエンジニアに依存せざるを得ないなと感じています。そうした議論をリードできるSREエンジニアは、どうすれば育成していけるのでしょう。

北野：うーん、それは私も知りたいですね（笑）。Observabilityが確保されている環境であれば、そういったことが、よりやりやすくなるように思えますよね。ダウンタイムがビジネスと直結するようなサービスであれば、プロダクトマネージャー的な立場にある人が答えを持っていて、そこからの逆算で考えることもできそうです。一方で、「エラーバジェットが少なすぎて、新しいチャレンジができない」という部分については、サービス開発チームとの議論の中で決まっていくようにも思いますし……。いずれにしても、関連する情報を可視化して、整理した上で議論に臨むほうが、チーム内での認識のズレは少なくなる気がします。

リモートワークでのコミュニケーションには思いがけないメリットも？

北野：少し話題は変わりますが、今回のコロナ禍で、みなさんリモートワークが多くなったと思います。リモートワークになったことで、チームに何らかの影響はありましたか。

増田：まず「コミュニケーション」、中でも「雑談」的なものが大きく減ったというのはありますね。もちろん「サービスの信頼性」に関わる部分については、意識的に綿密なコミュニケーションをとりつつ、確実に作業できるようにしているのですが、オフィスだとざっくばらんにできた「気軽な相談」のようなものが、リモートだと難しくなったというのはあると思います。これについては、Slackに「雑談ルーム」を作って補完できないか試みています。

　サービスそのものの信頼性については、リモートワークの開始以降も下がっていません。これについては、以前からいろんな指標を可能な限り「可視化」する取り組みをしていたことが奏功していると思います。新しい何かを始めたり、変化を起こしたりするときのコミュニケーションには特に気を付ける必要があると思いますが、可視化を通じてチーム内の認識を合わせ、プロダクトの信頼性を落とさないことが、引き続き大切だと思っています。

水落：私は、リモート勤務で面と向かって話す機会が減ったことが、逆に「チームのObservability」を上げているのではないかと感じることがあります。業務にまつわるあらゆることをSlackで話さざるを得ない状況になって、色んなやり取りがこれまで以上に見えるようになった気がします。会議をしたら議事録を残したり、何か気付いたことがあればJiraに書いたりといったことはやっていましたが、人とのやり取りや思ったことを「書いて残す」文化は、さらに強まったように思います。

　あと、これは完全に社内的なことなのですが、以前は3つあるSREチームのうち、1チームだけが別のフロアにあって、気分的に若干の「離れ小島」感があったのですが、リモートになったことでコミュニケーション上の条件は完全に平等になりました。（笑）

　さらに、Zoomですべての会議をやるようになったことで、SREに関する取り組みを他のチームに伝えることも、以前に比べてやりやすくなったかもしれません。とりあえず会議ルームのURLさえ共有すれば、作業しながらでも聞いてもらえるわけです。

北野：リモートならではのメリットもあったということですね。スタディストの場合、チームコミュニケーションの変化という意味では、それまで使っていた「物理カンバン」が使えなくなったことが大きかったですね。あと、先ほど増田さんが言われていた雑談の話に近いのですが、カジュアルなコミュニケーションの機会が減った分、1週間の終わりのミーティングで「金曜日感」を出すことを意識するようになりました。

水落：「金曜日感」ですか？

北野：はい。もともと、開発チームの方針で、楽しく働くことを大切にする価値観を掲げているのですが、リモートでミーティングをすると、淡々と進行しがちなのがちょっと寂しいなと思ったのです。なので、金曜日のミーティングの枠で「パワポカラオケ」（パワーポイントを使って即興でプレゼンをする遊び）をやってみたりしています。……いずれにしても、リモートで「金曜日感」を出すのはなかなか難しいです。

水落：なるほど、「金曜日感」というのは考えたことがなかったので新鮮です（笑）。恐らく今は、多くの企業で、リモートでうまく仕事を進めるためのいろんな工夫がされているのでしょうね。

SREに取り組むエンジニアたちの未来へ向けた「決意」

増田：今日は、SREについて多様な視点からお話ができて大変勉強になりました。最後にひとことずつ決意表明をして終わりましょう。まずは私から。

　SREに関わるエンジニアとして、サービスの価値は「信頼性」にあると、私は考えています。そのプラクティスは、システム的に提供できるものであり、Kubernetesは、そうしたプラクティスを簡単に実践しやすいプラットフォームだと感じています。今後も引き続き、KaaSの提供を通じて、社内で多くの人がSREのプラクティスを活用できるようにし、信頼性とアジリティを両立できるプラットフォーム作りに貢献していきたいと思っています。

水落：ヤフーの中で多様なサービスがPaaS上で稼働するようになり、責任の増大を感じています。PaaSの信頼性を上げていくことを考えた場合、SREを推進すればするほど、チームの誰もがシステムの信頼性制御に貢献しやすくなり、より効率よく安定性と信頼性を高められるようになるに違いありません。PaaSを利用するユーザーは今後も増え続けると思いますが、SREの知見を活用して、ユーザー規模の増加に負けないスピードでチームを成長させていきたい。ひいてはそれが、PaaSの信頼性、そしてPaaS上で稼働する各種サービスを通して、ヤフー全社の「信頼性」を高めることにもつながると信じています。

北野：今日のお話の中で出てきた「ビジネスKPIとSREのKPIとの結びつき」というのは、私自身が最近関心を持っているテーマでもあり、大変参考になりました。「リライアビリティ」と「アジリティ」を制御することと、顧客価値との関係性を可視化したい思いを強くしました。

　まだまだSREという考え方は、多くの人にとって馴染みのない概念だと思います。例えば、中学時代の友人に、自分が今やっている仕事を説明するのって難しいですよね（笑）。私としては、少なくとも自分が携わる組織の中で、同じことが起こらないような環境を作っていきたい。そのためにも、リライアビリティ、アジリティ、ビジネスがどうつながっているかを分かりやすく可視化できる基盤づくりに挑戦したいです。本日はありがとうございました。

著：高橋美津