6年ほど無停止のサービスを運用してきた私の経験からすると、メンテナンスウィンドウ、つまり計画的メンテナンスに対するアラート発砲を抑制する機能は、使わないほうがうまくいく。仕事の中でも度々メンテナンスウィンドウの話題が出てきたので、個人の見解としてまとめてみたい。
計画的メンテナンスの手順
対外的に無停止だとしても、内部的には停止を伴うメンテナンスをすることがある。たとえば、MySQLを止めることはたまにある。まずは、どのようにメンテナンスを進めていくのかを整理しよう。
内部的な停止を伴うメンテナンスの際は作業に必要な時間とともに、アラートが起こる範囲を予測し、予告しておく。予告の範囲を決めるのは単純で、アラートが届くだろうチャンネルにお知らせしておけばいい。以前のチームではメールとSlackチャンネルを使っていたので、そこに書いていた。準備はこれでいい。
メンテナンス作業が始まる（たとえばMySQLをフェイルオーバーさせる）と、何らかのアラートが出る。メンテナンスチームはAcknowledgeを送るのも良い。予告通りであれば、アラートを受けた人は作業を気にしつつ、作業がうまく進むことを期待するだろう。作業が終わり、サービスが動き出し、アラートが緑に変わる。平和な世界が戻る。
普通でしょ？
意図的にアラートを出す利点
予めアラートを抑制する手順と比較して、いくつかの利点がある。
アラートが適切に設定されていることを確認できる
内部サービス停止のアラートは滅多に起こるものではない。一度も発砲されていないアラートは適切に設定されていることを確認する手段はない。設定画面を注意深く見るくらい？人間の目は信用しないほうがいい。停止する範囲から期待されるアラートを洗い出して、実際に発砲されることを確かめよう。
メンテナンス終了がすぐに伝わる
予想していたよりも早く作業が終わった場合、アラートが収まることで必要な通知をすることができる。「メンテナンスは無事終わりました！」っていうお知らせを急がなくて良くなる。
手間が減る
メンテナンスウィンドウを適切に設定する手間を惜しむのは悪いことじゃない。俺たちは忙しいんだ！
まとめ
意図的にアラートを出す計画的メンテナンスの手法と利点について書いてみた。
もちろん、メンテナンスウィンドウを欲しているチームはあるだろう。その場合、ここで紹介した手法が適用できないか少し考えてほしい。適用が難しいかもしれない事情には興味があるので、ぜひ共有してほしい。
この話はもしかして、アラートの所有者は誰なのかという議論にもなるかもしれない。
