日中に本番DBでフェイルオーバー実施した話
アソビュー Advent Calendar 2020の17日目です。
アソビュー株式会社でSREをやっているzurausaです。
はじめに
当記事は人生で一番やらかしてしまったことに対して、詳細、
どういった対応をしたか、どのように対策したかを記載してます。
なにをやらかしたか
タイトルで完全に落ちてますが、日中に開発環境と間違えて、
本番環境でフェイルオーバーを実施してしまいました。
弊社はAWS上でサービスを立てており、DBに関してもそちらで管理しております。
そのため、スケールアップを行う際には、上記のサービスから書き込み用のインスタンスを作成した上で、フェイルオーバーを実施して、入れ替えるのが基本的な手段となっております。
どうなった&どうした
フェイルオーバーを実施した直後、本番環境のcluster名が見えた瞬間、走馬灯が走りました😇
そして、ひたすらに本番のアプリからコネクションエラーの通知が飛んでくるのを見て、意識を失いそうになりました😇😇😇
とりあえず、関連サービスの中から重要度の高いサービスから再起動して、接続の再確立を行いました。
再起動している間に、関係者各位に報告をしました。
報告内容があれなのは、ひたすらに焦っていたためです…
その後、詳細な報告、全体的な復旧、影響範囲の確認(購入や、商品の利用時において発生したかなど)を
関係者各位の協力のもと対応し、30分程度ですべての復旧が完了しました。
業務時間の終了位の時間帯にご迷惑をおかけした関係者各位には、
頭があがりません…
なぜ起こったか
その週は開発環境の負荷検証のため、スケールアップ、スケールアウト、その戻し作業を何回も何回も行っておりました。
それまでは指差し確認していたが、疲れからかその時だけ、指差し確認せずに実施してしまい、発生した次第です。
ﾕﾋﾞｻｼｶｸﾆﾝﾀﾞｲｼﾞ
二度と起こらないためになにをしたか
前提として、弊社では障害が発生した際に、必要に応じてポストモーテムを記載し、チーム内で読み合わせをします。
テンプレートは下記の通りです。
再発防止策は下記4点(全てでなくても良い)を軸にそれぞれ考えます。
- 予防（こうした障害の再発をポジティブに防ぐにはどうしたらいいか）
- 検出（同様の障害を正確に検出するまでの時間を減らすにはどうすべきか）
- 緩和（次回この種の障害が起きたときの深刻度や影響度の％を減らすにはどうしたらいいか）
- 修正（次回障害が検出されたときにどうすればより速く回復できるか）
今回のケースでは、検出、緩和、修正よりも予防の観点が重要なため、以下のような対応をするように、チーム内で話して決めました。
本番環境と開発環境のAWSアカウントを別離させることで、根本的に発生させないようする。
ここに関しては別理由もあり、ちょうど進めていた内容であったため、
わりかしスムーズに進みはしました。
とはいえ、別離(移行)させることが難しいものもあるため、それらに対しては下記のようなルールを定めました。
1.関連チームに対して作業の事前相談
2.開発環境も含めて作業前の告知の徹底
3.作業手順の明確化
4. 複数人での作業の徹底
ただ、これをすべての作業において、行う必要はないため、ダウンタイムが発生するものに関してのみ、実施するよう定めております。
現在、上記のルールに則って作業をすることで同様の事案に関しては発生していないため、十分な内容であったのではないかと感じております。
まとめ
ヒューマンエラーに関して、注意不足だったとすることは簡単です。
ただその場合、対応策として、個人単位のものになりやすかったり、コストの重たいルールが作成され、結果的に形骸化するケースは往々にしてよくあることです。
十分かつ、過大すぎない方針を決めるためには、ポストモーテムという考え方は非常に良いものだと感じております。
SRE本にもあるように、
人を「修正」することはできませんが、システムやプロセスを修正して、複雑なシステムの設計やメンテナンスを行う際に、人々が正しい選択をすることをうまく支援するようにはできます。
最後に
アソビュー！では一緒に働くメンバーを募集しています。
少しでもご興味がありましたらお気軽にご応募ください！
