こんにちは、Mackerel CREチームの 
id:kmuto です。
先日のMackerel Meetup #15 Tokyoの開催レポートはいかがでしたか？
今回は、その中でも当日大いに熱量を高めていた、豪華SRE陣によるパネルディスカッションを、書き起こしスタイルでご紹介いたします。ぜひお楽しみください！
- モデレーターとパネリストのご紹介
- アラートが来たときはどういうアプローチをしたらいいの？
- SREを立ち上げるにあたって会社の理解を得るには？
- エラーバジェットが余っていたらどうする？
- バッチシステムでのSLI/SLO運用は？
- SLOドキュメントの作成を進めるには？
- おわりに
モデレーターとパネリストのご紹介
モデレーター、パネリストは以下の方々でした。
- モデレーター
- Have Fun Tech LLC 代表社員 曽根 壮大 氏（@soudai1025）［以降曽］
- パネリスト
- 株式会社Topotal CTO 吉川 竜太（@rrreeeyyy）［以降吉］
- 面白法人カヤック SREチーム 池田 将士 様 （@mashiike) ［以降池］
- 株式会社はてな SRE 古川 雅大（
id:masayoshi）［以降古］
各方のプロフィールについては、過去記事をご覧ください！
アラートが来たときはどういうアプローチをしたらいいの？
曽：はい、パネルディスカッションということで、気になるな〜とか、深掘りしたいな〜とかあればリアルタイムで拾っていきます。
曽：最初のテーマは「アラートが来たときはどういうアプローチをしたらいいの？」ということで。
古：誰もが迷うことなんですが、どうアプローチしたらいいかについては、そもそもそのアラートがユーザー影響がなくて無視してもいいことなのか、それともユーザー影響があるから設定しているのか、設計意図がはっきりしていないと意味がないです。たとえばCPU使用率60%でアラートを出すとして、そのアラートが出たら何なのか？ どう対応したらいいのか？ 最初はわからないというのはそうで、わかるようにしていく必要があると思います。
曽：アラート対応じゃなくて、アラート自体を見直そうということですね。
吉：チームとしてどう対応するかを考えてほしいですね。アラートの意図を汲んで、チームでどう動くか。ユーザーサポートにコミュニケーションをとる人や、インシデントコマンダーを立てる。現状をまとめる書記役（スクライブ）、実際に調査をする人、別のコンポーネントがあればそこに連絡もしないと、といろいろなロールがあります。
吉：「どう対応したらいい？」に近いですが、SLOに違反したので調べるというのが多くなりがちなので、誰がどのロールを行うかを決められる体制作りが大事になります。
曽：各々の会社でやり方があって、たとえば障害が発生したときにはボットがissueを立ててくれるので、状況調査結果を記入して30分後に集まろうね、みたいな運用をしているところもありますが、何か皆さんで便利なTipsなどはありますか？
池：カヤックはプロジェクトの数が多くて、プロジェクト専任のSREというのはなく、アプリケーションエンジニアがSRE的なこともします。その過程で、自動的に応答したりすることで人間がやらなくても済むようにOSSを作ったりもします。まずは何か対応する、そして自動化する。
曽：どっから自動化するか、という点で障害起因、アラート起因というのはよさそうですね。
曽：アラート対応のときに、だいたいSlackを暇だからと見ている私が対応して、と属人化しやすいんですが、ほかの皆さんはどうですか？ 毎回同じ人がアラート対応をしている……みたいな。
池：だいたいうちも同じですね……（笑）。定例ミーティングでふりかえり、ほかの人も対応できる、自動化するというようにして、2回目・3回目と再発したときに備えています。
吉：ポストモーテムを作って、他チームとの垣根を越えて対応できるようにします。ほかの人も把握しておくことが第一歩ですね。「手が早い人がとる」は開発でも大きなテーマではあるんですが、「（アラート対応に走ってしまわないよう）重要な仕事をさせておく」といったマネージメントによる手法がありますね（笑）。組織としてインシデント対応できるようにすることです。
古：私も手を動かしがちなんですが（笑）。オンプレミスの運用をしていて、いろいろ普通の人が触らないようなもの（VRRPとか）に詳しくて、自分がやってしまっていました。ほかのアプリケーションエンジニアにとっては「初めて聞きました」という感じで、キャッチアップが大変です。
古：便利なツールに揃えておくのが1つですね。「使いこなせると便利」系は広めるのが大変……Jenkinsとか……。APIなどを調べればシュッとわかる、オープンなドキュメント、OSSといった形の知見にしておいて、共有する。障害対応を事前説明が難しい状態にしないことです。そうでないと、「これは説明が難しいから」とわかる人がいつまでも手を動かすことになってしまう。たとえばRDSがフェイルオーバーしたときはこんな風に対処する、AZ障害のときはこうする、といったオープンで職人不要な状態にする必要があります。
曽：シンプルなツールを使うのは重要そう。シンプルなツールこういうのを作っている使っているという話だと……はい、カヤックさんですね。
池：OSSを作っています。たとえばECSのコンテナイメージがないとデプロイ失敗するんですが、オートスケールで登録されていないのがあって失敗したということがありました。ECRのレジストリをライフサイクルで消しちゃったんですね。そこで、使っているものを保持するecrmというOSSツールを、@fujiwaraさんが用意してくれました。単一のことだけをするツールを作ると、わかりやすいです。
古：ECRのライフサイクル……と見て探すと、だいたいなんか（カヤックさん・fujiwaraさんが作ったものが）ある（笑）。GitHub Actionsでできるものはそれを使えばいいんですが、シンプルにECSだけをコードデプロイできる何かないかな〜と探すとecspressoとか。シンプルにデプロイだけをしたいのであって、TerraformやIAMなどまで責務範囲広げたくないですよね。ということで、作っているというより使わせてもらっています。OSSなのでコントリビュートもしたいと思っています。
吉：ecspressoなど使わせてもらっています。隙間家具、良いですね。アプリケーションエンジニア目線でどんどんできるようになってほしいですし、権限移譲したいときにありがたいです。障害対応目線でも1つのことをうまくやるツールというのは大事です。ガードレールを作るのはSREの仕事ですね。
曽：1つのアラートで1つのことを直せばいい、にしておけるのは理想的ですね。あちこちのログを漁る必要はなく、コンポーネントを複雑にならないようにする、と。
SREを立ち上げるにあたって会社の理解を得るには？
曽：続いて人気が高かった質問ですが、SREを立ち上げるにあたって会社の理解を得るには？というご質問です。
吉：何がしたいのか、が大事ですね。SREの看板がほしいわけではないはずですし、SREがやっていればいいでもないはずです。日々運用していく中でのIaC化やSLI/SLO設計はいくらでも自由です。まずやってみて、成功例を見せて、立ち上げる。信頼性の成功例を見せていくのが、ボトムアップなアプローチとして一般的だと思います。
曽：自分で勝手にやっていい、と。
池：カヤックも、勝手にやります的に手を挙げてできて、そこからチーム化していきました。
曽：この文化に名前を付けるということですね。
古：はてなの場合はインフラエンジニア部署があって、それがSREという名前になりました。私がこれを広げていったんですが、信頼性は対話なので、説明の回数を重ね、何度も言い続けました。インフラエンジニアに言うと「わかる〜」で終わってしまうことが多かったんですが、プロダクトオーナーらに、CPU利用率が60%かどうかじゃなくて、会社にとってはそのトップページをどのくらいの速度で見たいですか、といった話をしていきました。とはいえ「SLOを設定してください」とこちらに言われても困る、それはプロダクトオーナーの役目としてサービス要件を決めてほしいですよね。プロダクトオーナーに役立つアラートを提供してあげたい、CPU利用率60%と言われても困るだろうから、どのくらいでページ表示したいですか〜と聞きました。表示は広告・離脱があるので気をつけたいですよね、ならばレイテンシーに気をつけましょうね、とSLOの考え方に慣らしていき、一緒にアラート作りましょうという話になっていきました。そしてスプリントでふりかえる。自分たちが開発側の気持ちに寄り添っていくことで、開発側もSLOを気にして歩み寄れる。コミュニケーション重要です。
曽：良い話〜。質問スライドに「いいね」してください（笑）。
曽：障害対応するときのノウハウ、準備、Tips、こういう障害があったときにこういうことをした、といった話も聞きたいです。
古：すごい便利なものがあるわけではないんですが、「障害に対応するときにどういう対応をしないといけないか」、たとえば誰に連絡する、MeetやHuddleでどう進める、などの初動については社内Scrapboxに書かれています。アラートに対して何をすればいいのかわからないと、何をすればいいのかわからない（笑）。知っている人が集まって初期情報が完成している、という状態にします。
吉：以前の職場の話になりますが、GitHub上でアラート管理をしていて、Runbook（※注：対応手順書）が付いていなかったらCIをfailにするという運用をしていました。RunbookをSlack通知へ登録させるので、Runbookがないとアラート設定できない。こうしておくと皆、簡単なものだとしてもRunbookを書いてくれます。チームでこうしましょう、やるべきことはわかっている、という状態になるのが、環境として大事です。
池：うちはオペレーションチャンネルが作られることが多いですね。デプロイや障害などの関係情報が、1つのチャンネルにまとまっています。で、障害があるとなんやなんやと集まってくる。そこで話して、問題なさそうなら解散となります。後でふりかえれるようにログを貼り付けるツールを用意していて、まずい障害ならそのチャンネルを見ればふりかえることができます。そこからポストモーテムを書き起こして月次で共有しています。
古：プロダクトにインシデントチャンネルを用意しているんですか？ それとも全部？
池：プロダクトごとです。
古：複数プロジェクトにわたってSRE横断していると、いろんなチャンネルを見ることになって辛くないですか？
池：辛いこともあるけれども（笑）、SREを直接やるというよりは、SRE文化をアプリケーションエンジニアに実装・浸透させることをモットーにしています。横断しているSREチームが中心になってどうこうというよりは、アプリケーションエンジニアがそれぞれ対応しているので、さほど気になってはいないですね。もちろん「全部見るマン」もいなくはないですが。
曽：Runbook強制するの良いですね、パクろう！（笑）
エラーバジェットが余っていたらどうする？
曽：さて、次の質問です。SLI/SLOの確認をイテレーションのミーティング内で定期的にやっていますが、SLO違反がなくて単なる確認の場になってしまっています。エラーバジェットが余っていたらどうしてますか？
古：SLOを確認するときに重要なのは、変更の頻度を見ることですね。1ヶ月何も変更がない……のであればSLOに変化がないのはそれはそうだよね、という感じです。変更するから何か起きる。デプロイしまくってるのにエラーバジェットが余っている、たとえば毎日デプロイして余っているなら「SLOが低すぎないか？」という疑いを持ちます。目標が単純に低すぎ、妥当でない。違反にならないようリリース前に厳しいチェックをしすぎていて、チェックたくさんステージングいくつも、みたいな環境では開発速度が落ちます。リスクをどこまで許容するか、開発サイクルに影響を与えていないかも見たいところです。
吉：指標が正しいかどうかはケアする必要があります。SLOは違反していないけれども、問い合わせが滅茶苦茶来ている、ユーザー満足度が低いですよとか。成功レスポンスは正常だけれどもレイテンシーが一部下がっているとか。SLOが合致しているかは、気をつけて見るポイントです。変更速度も満たしてるなら、それは素晴らしいです。ただ、カオスエンジニアリングを適用して、障害のときにも大丈夫か？も見てみるといいですね。日頃違反していなかったとしても、サービスが落ちたときに復旧時間が滅茶苦茶かかってしまったらまずいですよね。エラーバジェットを障害があったときにどうするかの時間に使ってみるのもいいでしょう。
池：エラーバジェットの20%くらいは消費してもいいのではと思っています。0%だと監視できてない、50%だとゆるすぎです。ケアとしては、カスタマーサポート、ユーザー、プロダクトオーナーに聞きにいったりしています。Meaningful Availabilityもチャレンジしたりしていますね。
曽：確かに、「24xlargeなので大丈夫です」とか言われてもですね！（笑） 月いくらだと思ってるんや〜とか。
バッチシステムでのSLI/SLO運用は？
曽：さて次の質問です。Webリクエストだけでないバッチシステムの場合、1回失敗するとバッチに4時間といった具合に消費してしまいます。どう運用したらいいでしょうか。
池：私はデータエンジニアも名乗っているんですが（※注：データパイプラインも見ていてSLI/SLOの設計もされている）、こういうときは時間ベースで適用することが多いですね。この期間の間に何か問題がありましたか、この時間に何%ダメな時間がありましたか、といった具合です。パイプラインだとSLIを工夫、つまり指標を工夫します。
曽：自分のビジネスにSLIを合わせるの大事ですね。
吉：SLO本（※注：『SLO サービスレベル目標』（オライリー・ジャパン））に書かれていますが、バッチが何時間内に終わることが理想か、たとえばBigQueryへのバッチでデータが何分までにロードされていればいいか、などをSLIとして計測します。SLO本の中では、データのマスキングが何%できているかをSLIにするという話が面白かったですね。何割マスキングできているかを見る。
古：「工夫する」については、ステータスコードが決まっているわけではなく、バッチはビジネスロジックのかたまりですからね。要件をきっちり決めることが大事です。このジョブは何かを出すために何時間で終わらなければならないか？ ジョブが何をしてどうならなければならないか？ このジョブならこれ、このジョブならこれ、というように1つずつ決めていきます。ジョブの要件定義が、SLIを工夫する前に重要ですね。何をするものであり、何がクリティカルであるか。そこからSLIの工夫が生まれます。ユーザーの0.1%については昨日のランキングが出ても許容するが、決済のデータだと許容できないですよね、などなど設計します。
曽：バッチのつきぬけ（※注：バッチ処理が規定時間で終わらない）のMTTR（※注：平均修復時間）など、まれに発生することについて、それは許容範囲か、MTTRに収まっているかを指標にするという運用もありますね。
SLOドキュメントの作成を進めるには？
曽：最後の質問です。「SLOドキュメントを最初に作成するのが大変です。何かコツはありますか。」
古：「書くのが大変」はそうなんですが、どのレベルで始めるか次第ですね。最初は簡単でいいと思います。たとえばALBでステータスコード500のカウントを全体のリクエスト数で割って、明らかにダメなエラーレートをチームで共有してみる。もしそれが発生したらチームで集まろう、でやってみる。次にトップページは遅くてもよくて、/searchのページが重要だとわかったら進化させる、/searchが10秒かかったら対応しましょうみたいな。そうやって改修を回すことで、SLOドキュメントが進化します。
吉：小さく始めて改善するが大事ですね。SLO本の付録にテンプレートが載っているので、わからなければそれを埋めてみるのがいいのではないでしょうか。内容を埋めるのが大変ということになったら、人を巻き込んでみるといいです。開発に聞く、SREの同僚を掴まえる……うちのサービスで重要なのって何だっけ？となったら、プロダクトオーナーや経営者まで巻き込めるとさらにいいですね。皆で考えるSLO。1人で考えて書くのは大変。ともかく小さく始めてやっていくのがいいのかなと思います。
池：小さく始めるときには、経緯を追えることが重要です。README.md、Google Docsなどで経緯を追えるようにしておくことをお勧めします。いつどういう理由で決めたんです、というのがあるといいですね。
古：決めたときにそれが適当だったら「カッコカリ」にしておくといいです。後々で深淵な理由があるのか？で悩まなくて済むので。逆に、決めたらFIXと書いておいてほしいですね。
曽：小さくするの良いですね。カッコカリ、エイヤで決めたというのがわかっていいですね、これは勘で決めたので、違うドキュメント作ればいいんだなとわかります。
おわりに
モデレーターとパネリストの掛け合いがテンポよく進み、あっという間の45分でした。SRE最前線の経験と知見がギュッと詰まった濃密な時間だったと思います。
本記事は、セッションの録音・録画をしなかったことが悔やまれる……と運営一同で残念に思っていたところを、id:kmuto の当日のメモから書き起こしてみました。そのため、当日の熱いライブ感を十分に表現できているとは言えません。
動画やテキストで見るのではなく、その場に立ち合っているからこそ得られる体験があります。今後もMackerelは熱量の上がるイベントの開催を計画しておりますので、開催の折にはぜひご参加ください！
