ja.mackerel.io 障害対応をちょっとずつよくしていくための 演習の作りかた 2024.04.24 Mackerel チーム SRE テックリード 井口景子 

　井口 景子 （id:heleeen） ● 2019年9月にはてなに SRE として入社 ● 現在は Mackerel の SRE テックリード ● SRE, Serverless が好き ● カメラも好き 自己紹介 2 素敵な色の季節になりました 

今日はなすこと ● なぜ障害対応演習を行っているか ● 障害対応演習の作りかた ● Mackerel ではどのような演習を実施したか 3 

なぜ障害対応演習を行っているか ● 本番障害は必ず起こるものだから ○ 不具合やオペレーションのミスを無くすのは難しい ○ 障害防止にとても労力を割けば減らせるが, 開発コストが 増えたり開発スピードは悪化したりする ● 障害が起きたときに影響を抑えるための取り組みが重要 ○ 素早くロールバックできる仕組みを利用する ○ カナリアリリースで影響範囲を小さくする ○ 障害対応フローを理解して, 素早く対応できる体制を作る 4 

100% SLO から考える障害対応 ● エラーバジェットはプロダクト開発で利用したい ○ エラーバジェット … サービスの信頼性が損なわれる許容度 ○ 本番障害の頻発や復旧が長引いてしまう => 開発ではないところでエラーバジェットを使い切ってしまう => 機能開発や本番リリースができなくなってしまう... ● 本番障害で消費されるエラーバジェットはなるべく抑えたい 5 0% SLO エラーバジェット 

障害対応をどのように学ぶか ● 本番の障害対応の場ではなかなか難しい ○ 本番の障害対応は本番で障害を収束させるためのものであり, 学びの ためのものではない ■ 得られる学びももちろんあるが, 目的が違う ○ 緊張感のある場で成長する人間ばかりではない ■ 本番障害対応のみでは成長する人が成長するだけの場合が多い ■ ある程度の水準の対応を全員ができるようになるのは難しい 6 

障害対応を効率的に学ぶ ● Mackerel チームでは定期的な障害対応演習を実施 ○ 練習しておくと安心して対応できる ○ オンボーディングやキャッチアップとしても利用できる 7 

演習の作りかた ● 演習の目的を定める ○ この演習で何を学んでほしいかを決めておく ■ 例 ● 規模が大きい障害の対応の仕方 ● 障害頻度の低いコンポーネントの学習機会にする ○ 日頃の障害対応を観察して課題に感じるところを扱う ■ 例 ● 対応に慣れた人と不慣れな人の経験の差が開きつつある ● マネージドサービスを利用することでインフラ系の障害発生 頻度が下がったので, 対応経験が少ない人が増えている 8 

Mackerel チームの場合 ● 目的を定める ○ SRE が日頃クラウドの運用を行っているので, アプリケーション エンジニアはクラウドにふれる頻度が相対的に低い ■ アプリケーションエンジニアにクラウドのオペレーションを ある程度体験してほしい ○ 普段の障害対応で指揮官などの役割に携われていない人が役割を 経験することを優先して, できる人を増やしたい ○ DR 訓練をついでに実施しちゃいたい 9 

演習の作りかた ● チームの状態に合わせて学習の形式を考える ○ 例 ■ 本番の障害対応が学びの中心となっている ● 基礎的な考えかたや慣れている人の考え方を知るとより スムーズに対応ができるようになるかもしれない ■ 実装上の不具合を見つけるのは得意だが, デプロイ後の調査方法は よくわからない ● リクエストの処理の流れの再確認やクラウド上での調査方法 を知ると, より素早く障害の原因を見つけられるようになるか もしれない 10 

演習の作りかた ● 手を動かせる形式だとなおよい ○ 聞いたり読んだりだけより手を動かすほうが身につきやすい ● 自分で考えたり調査したりする時間を少し作る ○ 悩んだほうが印象に残りやすい ○ 考える過程で他の学びを得ることもある 11 

Mackerel チームで実施したパターン ● 5,6人など, 役割に当たる人を増やせる規模にチームをグループ分けする ○ 手を動かす経験を積んだ人を増やせる ○ 大規模なフォーメーションの練習はしづらい ● チーム全体で1つの調査と対応を行う ○ 大きめの障害対応の演習ができる ○ 演習の規模によって, 役割に当たらない出てきてしまうかもしれない 12 

気をつけていること ● 起こり得て対応できる内容をシナリオにする ○ 例 ■ アクセス数が通常時の10倍になった ■ イメージがライフサイクルによって削除されてしまった ■ 設定ミスで特定の経路のみ不通になってしまった ● 詰め込みすぎない ○ 練習しておきたいオペレーションやシチュエーションはたくさんある ○ すべてを一気に演習しても覚えるのは難しいので, 1回の内容は少なく 定期的に何度も行う ■ 人の入れ替わりにも対応できる 13 

Mackerel チームの障害対応演習(講義編) ● 基本的なオペレーションの確認 ○ フェイルオーバー, ロールバックなどを手順書を見ながら実行する ■ 経験済みの操作にして, 操作に対する不安感が減る ■ 日常的ではないオペレーションを試すことができる ■ もし障害発生時に演習で行った操作が必要なら, 演習のドキュ メントを見ればよい 14 

Mackerel チームの障害対応演習(実践編) ● 検証用の環境で障害を発生させ, 調査・対応を行う ○ 障害対応フォーメーションも実施 ○ 学んだことを手を動かして試す機会にする ■ 本番障害ではないので, 学習のチャンスにできる ● 監視設定の検証にもなる ○ 障害が発生したときに適切なアラートが発生するか ○ 素早くアラートで検知することができているか 15 

演習での学び ● 現在のアーキテクチャでの課題が見つかった ● runbook の不足や不備が見つかった ○ runbook にたどり着きにくいというのも見つかってよかった ● 演習後の障害対応フローに今まで以上のスムーズさがあった 16 Slack での状況共有の わかりやすさもあがった 

まとめ ● 障害対応も練習すると上手くなる ● チームの状態を観察して, 学習のテーマと手段を定めるのが大事 ● 先日の障害対応演習の実際の内容は, Hatena Developer Blog にて公開予定です 17