AWSのRDSでメンテナンスの案内が来た時におまえがすること

ここ最近、AWSのRDSでハードウェアメンテナンスに伴う案内が来たやろうと思う。ここにきたんやったらそうやろう。
そしたらお前がせなあかんことは環境によってわかれるんや。

シングルAZ

開発環境とかやな。対応は再起動や。この場合は、お前がせなあかんのは以下の４つや。

1. 再起動完了に１０分くらいかかるのを関係者に説明する
2. その間RDSはつかえやんので関係者に同意を取る
3. AWSでの自動再起動か、手作業で再起動するか決める
4. やる

だいたい１０分くらいかかるんで、その間はRDSがつかえへん。それを何とかせえっちゅうスキルとは全く関係ない話をせなあかんちゅう寸法や。
AWSが通知されたメンテナンス時期（ウィンドウと言うやつや）まで待つか、先にRDSのコンソールからメンテナンス適用するかも関係者で決めやなあかんやろな。まぁ、シングルAZは開発環境やろうからどうでもええやろ。

マルチAZ

本番環境やろな。これもだいたいおんなじや。シングルAZと違ってフェイルオーバが発生する。したがってお前は前項と似たようなことをせなあかん。

1. フェイルオーバに６０秒かかる（AWSの言い分）
2. その間はRDSが使えやんので関係者に同意を取る
3. AWSでの自動フェイルオーバか、手作業でフェイルオーバするか決める。
4. フェイルバックしたいかも関係者で決める。細かいとこやとここまでいるやろ。
5. やる。

しかし現実はメキシコより非常である

再起動にしろフェイルオーバにしろ、これはRDSの標準仕様や。つまりメンテナンスに限らずいつでも起こりうる。RDSのAWS管理部分で障害があったら起こりうる事象や。
具体的にいうと お前んとこのアプリケーションは再起動もしくはフェイルオーバが発生しても自動復旧して稼働し続けるように作られとる のが当たり前っちゅうことや。
また、 シングルAZやったら１０分、マルチAZなら６０秒のシステム停止は想定内 とシステム仕様がなっとるはずや。
つまり前述のお前がやらなあかんことは、システム設計時に決まっとるはずなんや。
これができてへんともめるし、影響調査になるやろな。 しらんけど。