[社内DBaaSで障害対応演習をやってみた - KADOKAWA Connected Engineering Blog](https://engineering.kdx.co.jp/entry/2021/11/17/180000) ## 環境 - プライベートクラウド - 主な利用者はドワンゴの「ニコニコ」 - MySQLのマネージドサービスであるRDB基盤 - MySQL数（概算）：600 - DBaaSの詳細 [がんばらないDBaaSの作り方 - KADOKAWA Connected Engineering Blog](https://engineering.kdx.co.jp/entry/2020/03/30/140000) ## 障害対応のスケーラビリティ - 障害対応だけはスケールしない - 対象のシステムに対する深い理解だけではなく、想定外の事象に対する問題解決力、調査力、判断力、チームワーク力など、様々な力が必要 ## 監視整理 - サービス影響がないのにモニターのアラートが鳴る - モニターのアラートが鳴っても対応手段が不明である - モニターがどのような意味でなぜ設定されているのか曖昧である ### 見直し基準 - SLOへの影響度 - 基盤利用者への価値 - 基盤運用への影響度 - 他のモニターによる検知可否 - 実績の有無 ### アラートレベルの定義 - レベル1: 次の営業日の日礼で確認して対応者をアサインして解決する。 Slackのメンションなしで投稿。 - レベル2: 営業時間内ならばすぐに対応する。営業時間外ならば、次の営業日の日礼で確認して対応者をアサインして解決する。 Slackの@hereメンションをつけて投稿。 - レベル3: 緊急かつ継続性があるので、電話のなった人がすぐに対応する。 Slackの@channelメンション+電話による通知。 特定の時間だけモニターをミュートしたりアラートの閾値などのモニター自体の内容を見直す ## 障害対応演習 - 想定内の障害（対応手順書がある障害）に対する演習 - 新メンバーの増加などなれていないメンバー向け - ディスクフルが起きた場合や再起動からインスタンスが復帰しない場合 - 想定外の障害（対応手順書は存在しない障害）に対する演習 - 既存メンバー向け - ヒューマンエラーにより設定値が不正となりMySQLがエラーとなってしまう場合や外部依存サービス（今回は監視SaaSの[[Datadog]]）がダウンした場合 ### 演習の流れ - 演習手順書を作成する - Sandbox環境で障害を発生させる - ロールプレイ - 振り返り - 意外とチームビルディングに有効だった ## まとめ - 新メンバーに障害対応をお願いできるようになった - 監視整備ができた - 課題：基盤全体にわたる大規模な障害や外部依存サービスと連携して対応する必要のある障害については演習できていない - 緊急時のためだけに、障害対応演習にそこまで工数をかけたくない、という判断がされやすい ## 感想 - 障害対応演習に工数をかけたくない問題を解決するために、新メンバー参入時のオンボーディングの一環として行うのはよいかもしれない。