SREの概要と役割
こんにちは、シニアソフトウェアエンジニアのriddleです。
このポッドキャストは、IT業界のいろんな話やリアルをお届けします。
今回はですね、お便りをいただきましたので、お便りについて回答していきたいと思います。
aptさんかな、apatsさん、もしくはaptさん、ちょっとわかんないんですけれども、いただきましてありがとうございます。
いただいた内容としてはですね、SREってどんな仕事してんの?とか、SREって夜中に叩き起こされたりすんの?みたいな。
まあちょっとその辺のリアルな話をいろいろ聞きたいというところで、ちょっと回答できればと思っています。
はい、SREですね、サイトリレイアビリティエンジニアリングの略で、Googleが提唱したやつですね。
2001年、いくつだろうな、15年くらいからいろいろ言われてたのかな。
もうちょっと後ろかもしれませんが、最近はCREとかね、カスタマーリレーションシップエンジニアリングだったかな。
SREから発展したのか、プラットフォームエンジニアリングみたいな感じで、より細分化していくというか、いろんな同系統、似たジャンルのものができてきたかなというふうに思っています。
SREですね、どういう人がなるかというとですね、結構インフラエンジニアからキャリアアップでやる人が多いかなという印象ですね。
もちろんバックエンドエンジニアからインフラの方にも手を出して、どっちもわかる人ということでSREになる人もいるんですけれども、
インフラレイヤーの方が多いかなという印象はあります。
さて、SREは何をする仕事なのかというと、本当これ会社によって定義が若干違ったりするんですけれども、
概ね統一的な見解としては、会社で提供しているサービスがあるとしましょうと、そのサービスが正しく動いていることを保証するというか、
正しく動くようにいろいろ活動する人たちという感じですね。
なので仕事の幅はすごく広くてですね、そのサービスがうまく動かなくなってしまわないようにいろんな先回りして、
ツールを作ったりとか、エラーを回収したりとか、そういうことをやったりします。
ただですね、これだけ言っても具体的に何すんねんっていう話だと思いますので、ちょっとSREの立ち上げから含めて話したいと思います。
SREですね、メインのミッションとしては先ほど申し上げた通り、サービスの安定に寄与するんですけれども、サービスの安定って何やねんって話じゃないですか。
SLOとエラーバジェットの重要性
それはですね、SLOっていうものがありまして、サービスにおいてどれくらいの品質を保ちましょうっていう内部の合意みたいなものですね。
これが外部向けになるとSLAっていうサービスレベルアグリーメントってものがあるんですけども、そうじゃなくてSLOというのはですね、社内に向けたものですね。
我々はこれぐらい自社のサービスを安定して運用しますよってやつですね。
このSLO、例えばいろんな尺度はあるんですけども、例えばサービスを99.9%稼働してる状態、ここで言う稼働してるというのは、
例えばECサイトであればユーザーが問題なく購入できる。問題なくってちょっと抽象的な表現なので、もうちょっと本当は具体化する必要があるんですけども、
そういうSLOを決めます。これはSREが決めるというよりかは、ビジネスサイドと話し合ってどういうところをSLOにしましょうかっていうのを決める感じですね。
これを決めたらですね、次はSLOをちゃんと観測できるようにしなければならない。
これはいわゆるログとかメトリクスとか他のイベントとかトレーシングとか様々なデータを使って、
どういう状態であればSLOが乱されていると言えるのかどうかっていうのをいろいろ確認した上で、いろんなツールを使いながら自分たちで見える化しますと。
SLOを測定していって一定の期間内でですね、SLOがちゃんと達成できているかどうかとか、
もしSLOが達成できないようなインシデントが発生した場合には今後はどうしていくべきなのかみたいなことを日々考えていくという感じでしょうか。
SLOの話が出たので、また教科書的な話をしますが、エラーバジェットという概念がありまして、
エラーバジェットというのはですね、さっきのSLOで99.9%という話をしましたが、
99.9%ということは0.1%かな。0.1%はエラーが出たりとか、そういうちょっと問題があったとしても許容しますよという感じなんですけれども、
逆に言うと0.1%を超えてしまうとそれってもうSLOを達成できていないので、そうなったらもうエラーをどんどん潰していかないといけないんですよね。
なので簡単に言うとエラーバジェットというのはこの0.1%以下に抑えるためのいろんなことですね。
なのでエラーバジェットは例えば今は0%だとか0.5%だって余裕がある場合はどんどん開発を進めていったらいいですし、
エラーバジェットが深くなったらちょっと開発止めて一回自社のサービスのクオリティを上げようとか品質を上げようみたいなことをやっていくみたいな活動ですね。
これはSREがやるというかSREが見える化してその見える化の結果開発チーム側が手動かして直していくみたいな連携プレイやっていくことが多いかなと思いますね。
もちろんその会社によって立ち回りがいろいろあったりするのでSREがバグを直したりするケースも全然あるかなと思います。
オンコール体制の実際
結構ですねSREの方って多芸というかインフラもアプリも分かるよみたいな人が結構多いので、
まずドメイン知識があるかどうかはまた別ですけれども結構コードの中見て直すとかそういうことは結構よくやったりしますね。
またですねSREの仕事としてよく挙げられるのがエンベディットなSREみたいなものもあります。
SREっていうのもなかなかこう独特なカルチャーだったりだとかSREがうまく機能しているチームだとSREがインフラの設備の用意とか、
例えばどっかのファイル書いてくれたりとかアプリケーションのデプロイまでやってくれたりとかするので、
本当にアプリケーションを書くエンジニアがですねインフラのことを全然知らなくてよかったりですね。
あと今どういうサービスの状況、こういう状況っていうのは売り上げというよりかはどれくらいトラフィックが集中しているのかとか、
理想的に問題があるのかとか、エラーレポートがどうなっているのかみたいなところの細かいところを把握しなくても良くなってしまうみたいなところがあって、
どうしても目の前の開発にかかりきりになってしまって、プロダクト全体のこと、これいう全体というのは安定性みたいな観点ですね。
そこが見えなくなってしまうということがまあまああります。
そういうところでですね、SREの文化というか考え方みたいなのを啓蒙していくみたいなミッションを背負ってですね、
開発チームの方に入っていくSREの方もいらっしゃいまして、これのことをエンベデッドのSREと言ったりしますね。
ちょっとこれも立ち回りはいろいろなんですけれども、開発チームの中に入って開発をやりつつ啓蒙活動する人もいれば、
開発はやらずにですね、インフラとちょっとしたツールの作成、SREの中にもですね、トイルの削減とよく言われますが、
手動で行っているような業務をどんどん自動化していく、そのためにいろんなツールを導入したり作っていくみたいな仕事もあったりするので、
それをドメインチーム側に入って一緒にやっていくみたいなこともありますね。
そういった感じでですね、SREっていうのは、すごいざっくり言うとサービスの可用性をどんどん上げていくというところがメインのミッションになっていて、
それを達成するためにいろんなことをやっていく。それは文化の啓蒙もしかり、ツールの作成もしっかりという感じです。
ではですね、実際に何か問題が起こった時のケースを考えたいんですけれども、APTさんが懸念されていた深夜に呼び出されるのかみたいな話ですけれども、
これはですね、会社によります。どういうことかというと、サービスを運用していて、このサービスがどれくらいクリティカルなものなのかによって、
オンコールの体制といったものをどれくらいのレベル感で敷くかっていうのが変わってきます。
例えば、全然売れてないものだったら、最悪翌朝直せばいいかなみたいな感じになるんですけれども、
ユーザーが筆記なしに使っているサービスだと、夜間もそれなりのトラフィックがあるので対応しないといけないよねみたいなケースですよね。
そうなるとですね、大体なんですけれども、夜中になるんですよ、電話が。
それは何をするかというと、アラートとかエラーが結構上がってて、こういうトリガーに引っかかったら電話を鳴らすみたいなものを決めとくんですけど、
それで当番と呼ばれる人に飛んでくるんですね。当番と呼ばれる人はオンコール対応といって、電話がかかってきたら電話出て、
一時的な切り分けとかして、解決に導ければ解決に導いてもいいし、チームのやり方によるんですけれども、
とりあえず気づいてから誰かにエスカレーションして、一旦終わりみたいな感じもあります。
基本的にはですね、チームで体制組んでやるんで、ローテーション制とかになっていて、
この1週間はAさん、次の1週間はBさん、その次はCさんみたいな感じですね。
こういうオンコール体制は業務でもあるので、結構オンコールの手当とか出たりすることもありますね。
8時間ぐらいの勤務扱いみたいな感じですね。
あと別に電話が仮にならなかったとしてもお金もらえるみたいなことも多いかなと思います。
これどれくらいの頻度になるのかってちょっと難しくてですね、マルプチュアサービスの規模にもよるんですよ。
全然問題ないサービスもありますし、頻繁になってしまうサービスもあるかなと思います。
ただですね、頻繁になってしまうサービスは状況にもよりますけどあまりよろしくないので、
根本的な改善か、そもそもそんなに頻度高くアラートのある人あるんだっけみたいなところをSREが詰めていくというような感じですね。
なのでSREって結構いきなりチャレンジする領域ではないんですけれども、一定のキャリアや経験を積んでから飛び込むと、
インフラもできるし、ある程度行動もかけるし、楽しいんじゃないかなと思いますね。
コードを書くというのは先ほど説明したようなアプリケーションコードを実際に書く人もいますし、
あとはトイレの削減ということで何かを便利にしていくようなツールを作成したりみたいなところもやったりしますし、
最近はLLMがあるので、LLMとうまく組み合わせて問題があった際のトラブルシューティングを早くしたりとか、
そういったことに使う人もいるかなと思います。
ということで今回はSREについてどういう仕事をやっているのかというのと、
具体的にオンコールというものがどうやって発生して、どうやって解決して、
誰が担当しているのかについて簡単にご紹介しました。
このポッドキャストはハッシュタグURLITで皆様からの感想やコメント募集しております。
またチャンネルの概要欄にGoogleフォームのリンクもありますので、そちらからのご投稿も大歓迎です。
ありがとうございました。
