誰デキ データベース運用との付き合い方9 アラート・障害対応の作業手順

障害対応は、どんなベテランでもあせるものよ
私の場合は、手順を丸暗記するんじゃなくて、
チームの体制図と役割を頭の片隅においておくことで、
あせった状況でも、作業の漏れ、報告の漏れを防ぐようにしているの

もちろんそれでもいいと思う。

自分に合ったやり方が一番いいと思うわよ

ではさっそく
夜中にアラートの連絡で起こされた。
さて、マナブくんなら、何をする？

そうね。

では、データベース運用における、「重大障害」ってどんなことだと思う？

そうね、DBサービスが停止した状態ね。
その他にも性能が悪化して、
性能要件を満たさなくなった場合も「重大障害」と判断する場合があるわね

ただし、性能問題を夜中に即時対応するのって、非常に難易度が高いことなの。
なので、あらかじめ性能系の問題についての、対応スコープをお客様と合意しておくといいわね。

重大障害発生の確認をした後は、何をすればいいかな？

そうそう。
でも、マナブくんには、もうすこし詳細までイメージしてもらいたい

重大障害の原因がデータベースだった場合は、
「再起動」や、「DRへの切り替え」、「障害ノードの切り離し」などをためして、「復旧優先」対応をする。

復旧したら、他チームにすぐさまDBへの接続確認をしてもらって、問題なければ、とりあえず対応はここまでにする。必要に応じて障害報告書は書いてね。

この辺りは、チーム構成、役割分担をイメージしていれば問題ないわよね。

深堀り調査、再発防止策については、後日、平日の日中帯に実施することにする。夜中にサポート利用できないケースもあるんで、サポート問合せを起票したりログをサポートへ連携するところまでにして、あとはさっさと寝る。

（とはいえ、こういう時はなかなか寝付けないんだけどね）

あたしなら「切り戻し」はしない
原因が判明したり、対応策が確定してから、計画的に「切り戻し」をする

では、話を戻して、
重大障害の原因がデータベース以外だった場合を考えてみようか
DBより下のレイヤ（ネットワークやH/W）で障害が発生した場合は、
「障害箇所の復旧」と「DBサービス復旧」を並行に検討する。

「DBサービス復旧」とは、具体的には、「DRへの切り替え」、「障害ノードの切り離し」などの検討ね

障害箇所が復旧したら、DBの正常性確認をする
DR切り替えなどで、DBサービスが復旧したら、他チームへDBへの接続確認をしてもらう。この日の対応はここまで。あとはもう寝る。

運用は、各チームが自分たちの役割を果たす共同作業。障害復旧もしかり。
重大障害の原因が「DBの場合」と「DB以外の場合」とでやることは大きくかわらないことを理解してもらいたい。