2026年4月1日

メンテナンスウィンドウの正しい使い方｜計画メンテナンスで誤アラートを防ぐ

メンテナンスウィンドウ死活監視アラート管理運用ノウハウ

メンテナンス中の誤アラート、放置していませんか？

クライアントサイトのサーバー移行やCMS更新を行うとき、監視ツールが一斉にアラートを飛ばしてしまう経験は制作会社なら誰でもあるはずです。深夜のメンテナンス中にSlackが鳴り続け、翌朝にはアラート疲れでチーム全体の対応速度が落ちる——これは大きな問題です。

Miterlのメンテナンスウィンドウ機能を使えば、計画メンテナンスの時間帯を事前に登録し、その間の監視アラートを自動で抑制できます。

メンテナンスウィンドウとは

メンテナンスウィンドウは「この時間帯は計画停止です」と監視システムに伝える仕組みです。設定した期間中は以下のように動作します。

監視チェック自体は継続して実行される
アラート通知は抑制される
メンテナンス終了後にサイトが復旧していなければ即座にアラート発報

つまり、監視の目は止めずに通知だけを止めるため、メンテナンスが想定より長引いた場合も安心です。

設定のベストプラクティス

1. 前後にバッファ時間を設ける

メンテナンスが23:00〜01:00の予定なら、ウィンドウは22:50〜01:15のように前後10〜15分の余裕を持たせましょう。DNS切り替えやキャッシュクリアの反映遅延を考慮するためです。

2. Webhookで自動化する

CI/CDパイプラインにメンテナンスウィンドウの開始・終了を組み込むと、設定忘れを防げます。各モニターには専用のWebhookトークンが発行されるので、デプロイ前にトークン付きURLを叩くだけでウィンドウが開きます。トークンはダッシュボードのモニター設定画面から発行・確認できます。

# デプロイ前にメンテナンスウィンドウを開始（duration_hoursは1〜24、省略時は4時間）
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/YOUR_TOKEN/start \
  -H "Content-Type: application/json" \
  -d '{
    "duration_hours": 1,
    "name": "サーバー移行作業"
  }'

デプロイが完了したら、終了リクエストを送ってウィンドウを閉じます。作業が早く終わった場合でも、待たずに通常監視へ戻せます。

# デプロイ完了後にメンテナンスウィンドウを終了
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/YOUR_TOKEN/end

Webhookトークンはモニターごとに発行されるため、対象サイトだけを正確に抑制できます。複数サイトを同時にメンテナンスする場合は、それぞれのトークンに対して開始リクエストを送ってください。

3. 対象モニターを絞り込む

全サイト一括ではなく、メンテナンス対象のモニターだけに適用しましょう。関係ないサイトの障害を見逃すリスクを避けられます。

4. 繰り返しスケジュールを活用する

毎週水曜深夜に定期バッチがあるなら、ダッシュボードのメンテナンスウィンドウ設定で繰り返しスケジュール（毎週・指定曜日・時刻・継続時間）を登録しておくと、毎回の手動設定が不要になります。一度設定すれば、定期バッチの時間帯のアラートは自動で抑制され続けます。

一方、デプロイのような不定期のメンテナンスは、前述のWebhookトークンを使ってCI/CDから都度開始・終了するのが確実です。「定期作業はダッシュボードの繰り返し設定」「不定期のデプロイはWebhook」と使い分けると、設定漏れを防げます。

クライアント報告にも活用できる

メンテナンスウィンドウの履歴はダッシュボードから確認できるため、「この時間帯のダウンは計画停止です」とクライアントに明確に説明できます。稼働率レポートからも計画停止は自動で除外されるため、正確なSLAレポートが作成可能です。

よくある質問（FAQ）

メンテナンスウィンドウの運用でよく寄せられる質問をまとめました。導入前の検討材料としてご活用ください。

メンテナンス中も監視チェックは止まりますか？

いいえ、止まりません。メンテナンスウィンドウは通知だけを抑制する仕組みで、監視チェック自体はバックグラウンドで継続して実行されます。そのため、メンテナンスが予定どおり完了したか、あるいは想定外のトラブルでサイトが落ちたままになっていないかを、ウィンドウ終了の瞬間に正確に判定できます。監視の目を完全に閉じてしまう運用とは異なり、安全性を保ったまま通知だけをコントロールできる点が大きな違いです。

ウィンドウ終了後もサイトが復旧していない場合はどうなりますか？

メンテナンスウィンドウの終了時刻を過ぎてもサイトがダウンしたままの場合、Miterlは通常どおりアラートを発報します。計画停止の時間を過ぎたダウンは「想定外の障害」とみなされるため、対応の遅れを防げます。バッファ時間を前後に設けておけば、復旧確認のための余裕も確保できて安心です。

複数のサイトを同時にメンテナンスする場合は？

メンテナンスウィンドウはモニター単位で管理します。サーバー移行のように同一インフラ上の複数案件を一度に止めるケースでは、対象モニターそれぞれのWebhookトークンに対して開始リクエストを送ってください。CI/CDのスクリプトに対象トークンを並べておけば、デプロイ時にまとめて抑制できます。逆に、メンテナンス対象でないサイトのモニターには送らないことで、関係ないサイトの障害を見逃すリスクも避けられます。

深夜越え（日付をまたぐ）メンテナンスへの対応

23:00〜翌01:00のように日付をまたぐメンテナンスは、設定ミスが発生しやすい場面です。Miterlのメンテナンスウィンドウは開始時刻と**継続時間（分・時間）**で指定する形式のため、「23:00開始・継続2時間30分」のように指定すれば日付をまたぐ場合でも正しく動作します。

繰り返しスケジュールでも同様で、開始時刻と継続時間の組み合わせで深夜越えを扱えます。「終了時刻が翌日になるかどうか」を意識する必要がないため、設定ミスを防ぐことができます。

複数案件・複数エンジニアで運用するときのルール整備

制作会社が10件・20件のクライアントサイトを管理するようになると、「誰がメンテナンスウィンドウを設定するか」「設定漏れをどう防ぐか」のルール整備が重要になります。

実務でうまく機能しているパターンをいくつか紹介します。

デプロイスクリプトに必ず組み込む: Webhook呼び出しをデプロイシェルスクリプトやCI/CDワークフローのステップとして固定し、手動での設定を不要にする
チェックリストに項目を追加する: 「メンテナンスウィンドウ設定済み」を作業前確認リストに追加し、属人化を防ぐ
Slack通知でウィンドウの開始・終了を共有する: Miterlのアラート連絡先にSlackを設定しておくと、ウィンドウ開始・終了時に通知が飛び、チーム全員が状況を把握できる

稼働率レポートや計画停止の記録とあわせた活用方法は「稼働率レポートの作り方」もご参照ください。

まとめ

メンテナンスウィンドウを正しく設定することで、誤アラートの削減・チームの負荷軽減・クライアントへの説明責任をすべて改善できます。Miterlを使えば、API連携で自動化まで実現できるため、制作会社の運用フローに無理なく組み込めます。計画メンテナンスのたびに発生していたアラート対応の手間を減らし、本当に対応すべき障害だけにチームの集中力を向けられるようになります。

メンテナンスウィンドウと組み合わせたい監視としてハートビート監視があります。定期バッチや自動更新スクリプトが正常に実行されたかどうかを死活確認する仕組みで、「設定が走ったはずなのに動いていなかった」というケースを検知できます。詳しくは「ハートビート監視とは？cronジョブの死活確認を自動化する方法」をご覧ください。

詳しい設定方法はドキュメントをご覧ください。無料プランで実際の動作を試すこともできます。導入事例はユースケースページでご紹介しています。