開発者も「ユーザーの信頼性」に着目して、開発を効率的に進めよう
――SREというと「インフラエンジニアに任せておけばいいのでは」と考えがちなアプリケーション開発者もいるかと思います。アプリケーション開発者が主体的に関わることで得られるメリットとかありますか？
山口：開発しているアプリケーションにおいてSLOが緩ければ緩いほど、求められる品質は低くなります。つまりそこまで高品質でなくとも許されるということです。そうなると、アプリケーション開発者にとっては、新機能でリスクを取った開発をしてもSLOに違反する確率が減るというメリットがあります。またSLO違反が起きそうなとき、開発者の立場からでも何が起きているかや原因の切り分けがしやすくなります。
今まではプロダクトを運用側にデプロイしてもらい、CPUやメモリの使用率などのシステムメトリクスやアプリケーションのログなどから勘と経験で推測することが多かったかと思います。しかしSLOを設定し、アプリケーションのテレメトリーを積極的に取得するようになると、自ずとアプリケーション開発者が自分で解決できる確率が高くなってきます。例えばリクエストが来たときにレイテンシが遅くなれば、どの部分が影響しているかはアプリケーション開発者なら分かるので、運用に関わる良さもあるかと思います。
手塚：（SREというより）インフラ側からすると、メトリクスくらいしかフォローできないと思っています。APMなどは開発側が意識して実装しないと……インフラ観点からすると、改善しようがないのが現実です。
インフラエンジニアならインフラのメトリクスやログを監視できますが、アプリケーションレイヤだとケアしきれないので、オブザーバビリティはアプリとインフラで一緒に作る必要があります。実はこのあたりが、明確な線引きがされているケースが多い企業の支援で困るところだったりします。「これはアプリのここを見ないと分からないでしょ」とか「大事なのにデータが取れない」とか。
山口：アプリケーション開発者が自分たちでやるとなると「何をすれば良いのだろう？」と戸惑ってしまいます。そういうときにSREやプラットフォームエンジニアリングなど（呼称は企業によりまちまち）の部署がテンプレートやガイドラインを用意することがあります。最近ではテレメトリー収集に関して、アプリケーション開発者の負担が減りつつあるようです。
――それでは最後に「明日からSRE的な視点で開発を効率良く進めよう」と気づいた読者向けにメッセージをお願いします。
山口：SREは原則が大事であることを改めて認識していただけたらと思います。そうすると自ずとプラクティスも理解しやすいかと思います。興味があればSRE本も読んでみてください。インフラエンジニアやオペレーション経験者なら理解しやすいかと思います。
SREはインフラチームだけではいけないので、それぞれのロールに合わせて理解していただけるといいと思います。例えばCUJを理解していないと、指標の設定ができません。ではCUJを決めるのは誰かというと、会社によりプロダクト責任者、UXデザイナー、ビジネスサイドなどに分かれますが、そうした方々の協力がないと優先度をつけることが難しくなります。ぜひ興味を持ち、ユーザーの信頼性について考えていただけるとSREを導入しやすくなるかと思います。
手塚：SREの中に信頼性は非機能要求ではなく、機能要求だというメッセージがあったかと思いますが、その通りだと思います。いくら素晴らしい機能を開発したとしても使えなければ意味がありません。SREはこうしたときのエンジニアリングの一種のメソッドです。そして信頼性について、エンジニアだけではなく組織全体が向き合ってほしい。そういう組織を一緒に作っていけたらと思います。
SRE総合支援サービス「Sreake（スリーク）」
「Sreake」は、SRE（Site Reliability Engineering）による設計及び構築支援から人材育成まで、クライアント組織に深く入り込んだコンサルテーションを提供しています。AWS/GCPなどのマルチクラウドの導入や、KubernetesやIstioを始めとしたクラウドネイティブに特化した技術に強みを持っております。金融・医療・動画配信・AI・ゲームといったさまざまな業界業種・領域での実績から、最適な課題設定と解決策を提示し、最新技術で、競争力のあるインフラ環境を構築、また維持できるチーム作りをご支援します。
