とあるSREの一日

著者：

2024-10-01

とあるSREの一日

こんにちは。あおい(@_a0i)です！株式会社リクルートでSREをやっています。私は心身共に女性ですが、エンジニア業界そしてとりわけSREは女性比率が非常に少ないです。なぜ冒頭から性別の話を出したかというと、今回寄稿するにあたり、「SREが普段どういう仕事をしているか紹介したい」以外にも「女性のSREも存在し、楽しく働いていることを示したい」という二つの目的を掲げてこの記事を書くことに決めたからです。

わざわざ女であると明言していますが、このあと綴られる日常としてマイノリティである大変さや女性身体における苦労のような話は含まれていません。私はチームメンバーに恵まれたこともあって、自分の性別を日常的に気にすることなく楽しく働けています。

じゃあどう働いているの？ということで「とあるSREの一日」と題して、私が一日を通してどんな仕事をしているかご紹介できればと思います！

また、SREではない方でもSREについて理解を深めていただけるようなるべく専門用語など丁寧に解説するよう努めています。今までSREに興味なかったよ、SREってよくわかんないという方でも楽しんで読んでいただけるかなと思います！
Sre

前提

まずSREといってもサービスへの関わり方、役割などさまざまです。また、どういうサービスに携わっているかによっても変わります。私は『スタディサプリ』という学習動画配信サービスのSREです。主に日中時間帯がメインに利用されるということもあり、オンコール（システムの安定性や稼働状況を保つため、24時間体制で監視すること）はありません。

ではさっそく一日を見ていきましょう！なるべくたくさんの仕事の説明を盛り込みたかったので、色々と盛り込んだ一日にしました。このようなスケジュールが毎日続くわけではありません。たまにあるよね、ぐらいです。

1日のスケジュール

朝は犬の散歩をします。これはSRE業とは直接関係ありませんが、おかげでフルリモートであるにも関わらず毎日健康です！もりもりご飯美味しい！

8:30 勤務開始

Kaishi

フルリモートなので机の前に向かってPCを立ち上げたら勤務開始です！Slackで勤務開始を宣言し、仕事をはじめます。

アラートの確認

私がいるSREチームはDatadogのMonitorを利用し、Slackの共通チャンネルでアラートの通知を受け取ります。現在アラートをp1~4に分類し、それぞれどれくらいの緊急度で対応すべきか定義しています。もともとは「emergency」と「warning」の二つしかなかったのですが、この二つだと朝早くに出社する人たち数人で午前中かけてアラート対応するという状況になってしまっていました。そこでレベルを4つにわけることで、本当に緊急のもの以外はチームメンバーが揃った状態で、あるいは遅くから出社する人もアラート対応ができるようになりました。

私たちのチームはデイリーミーティングを行うので、緊急度の低いアラートでも1日に1度は確認される運用になっています。緊急度が低いからといって長く放置されることはありません。

また、定期的にアラートを見直す機会を設けることで本当に必要なアラートだけを通知するように改善しました。あまりにアラートの量が多いとアラートを見逃してしまったり、あえてスルーしたアラートが実は重要なものであったということになってしまいます。月に1度、1ヶ月分のアラートも見ています。突発的な障害を除き、1ヶ月を通して件数が多いものの見直しもしています。閾値の調整をしたり、調査した結果根本対応が必要だったというケースにも気づくことができます。アラートに関する考え方や改善の仕方については「入門監視」という書籍を読むとよくわかるのでおすすめです。

09:30 個人作業

アラートの確認が終わったら他のSlackの通知確認後、個人の作業を行います。SREの個人作業というのは同じチームのSREであってもさまざまです。例としていくつか個人作業の内容を挙げてみます。

インフラのバージョン更新

container-magic

インフラのバージョン更新というとWindowsを新しいバージョンにする、みたいなイメージがあると思いますが、必ずしもそれだけではありません。例えばミドルウェアのバージョン更新もあります。Kubernetesのバージョン更新はわかりやすいですが、それ以外にも現代ではたくさんのOSSを使っている現場も多く、それぞれの更新時に時として慎重に時間をかけて行う必要があります。
例えばKarpenterといったOSSは自動でサーバーを起動したり停止したりしてくれるのですが、このOSSを安易にバージョン更新して壊れたら最悪サーバーが全部消える…ということもありえます。そういった最悪な事態が起きないように一旦ステージング環境でテストする、といったことも含めて作業の一環になります。
インフラ環境はサービスを支える基盤となっているため、いかに慎重にかつ効率よく更新作業を行っていくかが工夫のしどころです。
私たちの環境ではRenovateを導入しており、新しいバージョンのOSSがリリースされると自動的にPull Requestが作成されるようにしています。ステージング環境では自動でマージされるようにするなど、なるべく手作業にならないように工夫をしています。
本音でいえばそれこそAIに安全でサクッとバージョン更新をしてくれると嬉しいんですけれどね…。

トイルの削減

Site Reliability Engineeringという書籍の中でトイルはつぎのように定義されています：
トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つものです。

この書籍の中でははじめての作業、2回目の作業を手作業で行うことはトイルとはいっていません。しかしはじめての作業は手作業のまま3回目4回目…何度も手作業が当たり前になってしまった経験はありませんか？私はあります！
トイルを見つけ出し、自動化することで削減していくことはサービスの信頼性を向上するにあたって非常に重要な仕事です。なぜかって？人間はミスをするんですよ！人間は、ミスを、する！リピートアフターミー！
ということで私たちSREは信頼性を向上するために日々トイルを見つけること、そして削減することに尽力しています。
せっかくなので「何を」「どう」削減するか検討するにあたってよく話題に上がる指標についてご紹介します。

費用対効果

トイル削減に限った話ではありませんが、「トイルを削減するための費用対効果」について話をすることがあります。例えば削減するために1人のエンジニアが丸々1ヶ月頑張ったとして、そのトイルが発生するのが年に1度だったらどうでしょうか？トイルの内容によるでしょうが、費用対効果があわず削減を諦めるということもあります。

運用のしやすさ

運用のしやすさもまたサービスの信頼性に直結します。自動化した結果、自動化のコードが製作者以外メンテナンスできない内容であったり、「何がどこで動いているかわからない」という経験がある方もいるのではないでしょうか。自動化するツールやコードがどれくらいメンテナンス可能か、あるいはどれくらい運用に耐えられるか、という話は度々されます。

CI/CDの改善

CI/CDは一度導入して終わりではありません。サービスの拡大に伴いテストやデプロイパイプラインが複雑化します。私たちは「開発者体験の向上」を一つの目的として掲げ、開発者がより開発しやすいよう日々努力しています。CI/CDが遅い、使いづらい、なども開発者体験の低下を招く要因の一つです。半年〜1年に一度の開発者アンケートや開発者へのインタビューをもとにCI/CDの改善に努めています。

コスト削減施策

これはわかりやすいですね。昨今円安に伴いクラウドに支払うお金が年々増え…同じように苦しんでいるエンジニアがたくさんいるのではないでしょうか。インフラの観点からできるコスト改善施策をメインに、時にはSREからソフトウェア開発者に対してコスト削減策を提案・推進することがあります。

10:00 開発者からの問い合わせを受ける

私たちの組織は「自己完結チーム」を目指しており、アプリケーション開発者も自分達でKubernetesのマニフェストを書いています。そうはいっても日々進化していくアプリケーション開発に関わる技術に加えて、インフラ周りの技術のキャッチアップを行うのは大変なことです。そのため、開発者の方々には適宜 @sre-jp メンションを行ってもらい、気軽に質問してもらうようにしています。
最近では生成AIを活用してslack上から自然言語でドキュメントを検索できるようにしていたりもします。単に問い合わせを受けて回答するだけではなく、開発者が問い合わせしなくても良いようにドキュメントを整備するのも仕事の一つですね。
問い合わせを受ける、というと一人のSREがなんでも答えられる必要があると思われる方もいるかもしれません。しかし私たちのチームにはSREのメンバーが複数いるため、必ずしもそうではありません。それぞれに得意分野・不得意分野があり、自分では回答できない場合は他の得意そうなメンバーにメンションを飛ばして聞いてみるということもよくあります。
私たちは :ask_sre_jp: というReacji(Slackメッセージにつけられる絵文字のことを指す）をつけると共通の問い合わせチャンネル(#ask-sre-jp)にメッセージが転記される仕組みを入れています。この仕組みのおかげで、デイリーミーティングではその日に受けた#ask-sre-jpの問い合わせをみるという運用が楽にできます。デイリーミーティングで一通り見ることで、問い合わせの見逃しを防止したり他メンバーからのサポートを受ける仕組みにしています。（参考： https://blog.studysapuri.jp/entry/2021/06/28/080000 ）
なんでも答えられる必要は必ずしもないと言いましたが、障害となると少し話が異なってきます。
ということで…

10:30 障害発生

Watawata

障害発生！障害に気づくきっかけとしてはアラートはもちろんありますが、開発者からの問い合わせで気づくこともあります。特に私たちの組織では開発チームごとに運用するマイクロサービスに応じてアラートを指定しています。アプリケーション側でエラー検知した結果、どうも開発者だけでは原因がわからない場合や思い当たる節がない場合、Kubernetesクラスタなどインフラ・CI/CDなどの共通部分に問題がありそうな場合はSREに問い合わせがきます。
障害調査となると、前述した一般の問い合わせに比べて緊急度があがります。そのため、自分が何もわからないとしても、できることを全力で行うこともまたSREの仕事の一つかなと思っています。
障害対応にはいくつかのセオリーやベストプラクティスがありますが、ここで書くには長くなってしまうためおすすめの書籍を載せておきます。
システム障害対応の教科書：https://www.amazon.co.jp/dp/4297112655

障害が起きると、 #incident-ja というチャンネルで障害報告があがり、関係各者とのコミュニケーションがはじまります。私たちはリモート環境で働いているメンバーが多いこともありSlackのチャンネルやGoogle Meetでコミュニケーションを取ることが多いです。
障害が発生すると私は原因を探し当てたくなってしまうものですが、一旦障害の影響を収める（あるいは最小化する）ことが大事です。これをよく「止血対応」と言ったりもします。まずは血を止めましょうね、ということです。障害が起こった時には障害の解消（止血対応）を第一優先にします。そのため、障害の原因がわかっている状態で解消することばかりではありません。インフラの設定をGitHub上で管理している場合、障害が起きたとされるPRをRevertすることで一旦障害を解消させることができることも多いでしょう。一旦障害が解消された後、じっくり原因を調査します。
この日は午前中で止血対応が終わりました。原因調査や根本対応は午後に行うことにして、ゆっくりお昼ご飯を食べましょう。

さて、障害にも深く関わってくるSREの「システムの信頼性を維持・向上する」という仕事ですが、「維持・向上」は何をもって決められるのでしょうか。
ここでSREにとって重要な指標、SLI / SLA / SLOについて簡単に説明します。

SLI、SLO、SLAの違い：
SLI（Service Level Indicator）: 実際に測定されたサービスの性能データや信頼性を示す指標。
SLO（Service Level Objective）: SLIの目標値、つまり「どのくらい良好な状態であるべきか」を定めた基準。
SLA（Service Level Agreement）: 顧客との契約に基づくサービスレベルの合意で、SLOが守られなかった場合にどう対応するかを規定するもの。

もう少し詳細に説明します。

SLI

SLI（Service Level Indicator、サービスレベル指標）は、サービスのパフォーマンスや信頼性を具体的に測定するための指標です。例えば「サーバーが1日24時間中、99%(23時間45分)は正常に動いていた」という数値です。他にも応答時間（ログインにX分かかった）、エラーレート（全リクエストのうち0.01%がHTTP 503エラーだった）などが指標としてあげられます。

SLO

SLO（Service Level Objective、サービスレベル目標）は、サービスが達成すべきパフォーマンスや信頼性の具体的な目標を示したものです。SLOは、サービス提供者が「このくらいのレベルでサービスを提供します」と内部的に決める基準です。
SLIを使用し、後に説明するSLAを下回らない基準を決めます。例えば、「サーバーが1日24時間中、99.9%(23時間58分)は正常に動くことをSLOとして定めることができます。これをよく「uptime 0.999(3nines)」など、9がいくつあるかで表現することがあります。ここでは9がたくさんあればあるほど厳しいSLOになるということを覚えていれば大丈夫です。

SLA

SLA（Service Level Agreement、サービスレベル合意）とは、サービス提供者と顧客の間で合意された、サービスの品質やパフォーマンスに関する契約です。SLAは、提供するサービスの可用性や応答時間、サポート対応のスピードなど、具体的な基準を明確にし、それが守られなかった場合の補償やペナルティを規定します。

例えばSLAを「サーバーが1日24時間中、99%(23時間45分)は正常に動くこと」と定めるとします。もし24時間中23時間40分しか正常に動いていないとすれば、ユーザーに補償する必要がでてきます。
また、先ほどSLOを説明しましたが、SLOはSLAを下回らない基準にする必要があります。言い換えれば「SLOを守れていれば必ずSLAを守れている」状態です。SLOを守れているけれどSLAに違反していた、では本末転倒です。

ここで出したのはあくまで一例です。信頼性として何を指標におくべきか、計算の仕方、あるいは信頼性の使い道についてはここでは説明しません。SRE Magazineには色々な知見が集まっているので、ぜひ参考にしてください。

色々と説明しましたが、個人的に大事なのは「信頼性100％はありえない」ということかなと思っています。SLAでuptime 1.0を定義することはありません。日々ユーザーにとって新しい価値を提供していく中で、障害の発生は避けられないでしょう。テストなどで事前に防げることも多いかもしれませんが、リリーススピードとのトレードオフになります。コードに手を入れなければ障害が起きないのではと思われるかもしれませんが、それもまた違います。例えばサーバーのOSが古くなり、EOL（End Of Life）を迎えてしまえばセキュリティリスクが高まり、下手すると攻撃を受けてしまいます。
では信頼性100%は無理だから頑張ることをどこかで諦めるか？というと、また違います。障害が必ず起きるのだとすれば、いかに復旧を早くするか、いかに原因調査しやすくするか、考えるべき点はたくさんあります。また、トイルの削減で説明したように、信頼性もまたトレードオフがあります。何を重視するか、どこを頑張るか、日々アプリケーション開発者と共に考え信頼性を高めていくことがSREの楽しさかなと思っています。

12:00~13:00 お昼ごはん

13:00 障害発生原因調査

Investigate

午前中には障害の止血対応を行いました。原因が即座にわからず止血対応を行った場合、別途時間を使って原因調査や根本対応の実施を行う必要があります。
私がSREになった直後これらをうまく区別できておらず、もたもたしたり誤った対応を行おうとしたりしてしまったことがあります。止血対応はあくまで一時的な対応です。「なぜ直るかわからないが、これをやれば直る」という止血対応もあり得ます。なぜ直ったか、ひいてはなぜ障害が発生したのかを調査し原因を特定します。
原因を特定できたら、根本対応の検討を行います。原因がわかったからといって根本対応が必ずしも実施できるとは限りません。例えばあるOSSのバージョンを1.0から1.1にあげたときに障害が発生したとしましょう。原因は私たちが使っているほかのOSSとの組み合わせで発生する問題だったとします。この場合、何もせずに1.1にあげることはできないので、issueをあげて対応可能にしてもらったり、自分達でPRを送ったりすることになるでしょう。

原因調査のやり方、考え方、ツールの使い方など人によっても組織によっても色々あるでしょう。ここでは具体的に説明はしません。
ただ一つ言えるのは、大体自分が障害対応するときは自分が原因だということですかね…
「む！この変更が怪しい！」「む！申し訳ないがgit blameさせていただく！」「む！」「…」「すいませんでしたぁあぁぁ！！！！」
この仕事は掘った穴を埋めることだ、と誰かが言っていましたが、そうだよねと思うことしばしです。障害調査は難しいことも多いですが、ヒントから1つ1つ原因を探り当てていくのは探偵のようで面白いなと思っています。

障害の原因が特定できたら、振り返りを行うことも大事です。SREでは障害対応の事後調査報告書を「Postmoterm」と呼び、Postmotermに関する知見がたくさんあります。インターネットを検索すると各社の事例が出てくると思うので、ぜひ参考にしてみてください。（参考： https://speakerdeck.com/chaspy/culture-and-technology-supporting-postmortem-operations ）

17:00 デイリーミーティング

あれ！個人作業の時間がない！？と思ったみなさん、そうです！障害が発生すると一日が潰れてしまうことはよくあります。
あるいは、一日かけても調査が終わらない場合、デイリーミーティングで他のメンバーにヘルプを求めます。

17:30 退勤

以上がわかりやすくイベント盛りだくさんなSREの一日でした。どうでしたか？大変だと思われましたか？こういう日が毎日ではないですが、たまにあるととても疲れるのは間違いないです。けれど意外と障害調査が楽しかったり、問い合わせにうまく回答できると嬉しかったりします。

SREがどういう仕事なのか、少しでも皆さんの参考になればと思います。