RDS メンテナンス通知を読む

本文を読むときに押さえるのは「何が更新されるか」「いつか」「停止を伴うか」の 3 点です。OS の更新（required operating system update）やエンジンのマイナーバージョン更新は、Single-AZ なら数分の停止、Multi-AZ ならフェイルオーバーによる短い切断になります。ハードウェアの入れ替えも同様です。

「いつか」は、そのインスタンスのメンテナンスウィンドウの開始時刻が UTC で書かれています。日本時間に直す必要があり、土曜の深夜と思っていたら日曜の早朝だった、という取り違えが起きやすい箇所です。

多くの通知には「すぐ適用する」「次のウィンドウまで延期する」という選択肢が書かれていて、RDS コンソールから選べます。ただし必須の更新は延期しても消えず、いずれ適用されます。また、1 通のメールに複数のインスタンスが列挙されることがあり、本番と検証が同じ通知に混ざっていると本番の分だけを見落とします。

顧客のアカウントを複数預かっていると、同じ件名のメールが顧客の数だけ届きます。件名のアカウント ID と本文のインスタンス名から「これは誰の本番か」を毎回判断するのが、いちばん時間のかかる作業です。

Sabaki は本文からアカウント ID とインスタンス名を抜き出して顧客に紐付け、メンテナンスの開始時刻を日本時間の期日として表示します。要約には「どのインスタンスが、いつ、どれくらい止まるか」が入り、解説には Single-AZ か Multi-AZ かによる影響の違いと、前倒し・延期の選択肢が日本語で書かれます。

日本語の要約と解説は、そのまま顧客への案内文の下書きになります。顧客の Slack チャンネルを配信先にしておけば、通知が届いた時点で「いつ・どれくらい止まるか」が顧客にも共有され、担当者は補足するだけで済みます。対応の記録は台帳に残るので、あとから「連絡したか」を確かめられます。

通知のたびに日本時間の深夜・早朝を確かめているなら、インスタンスのメンテナンスウィンドウ自体を業務に合わせて設定し直すのが根本的な対策です。解説にはウィンドウの開始時刻が日本時間で書かれているので、見直しの材料になります。