メンテナンスウィンドウ

1）「メンテナンスウィンドウ」とは何で、なぜ必要なのか

メンテナンスウィンドウ-可用性/パフォーマンスに影響を与える可能性のあるアクティビティの事前に合意された時間枠。目標は、予測可能なリスク、透明なコミュニケーション、エビデンスに基づいた報告によって変化を制御することです。

• 計画：リリース、移行、証明書/キーの回転、データベース/ブローカーアップグレード。
• 緊急：緊急の安全修正/インシデントロールバック。
• サイレント/ゼロインパクト：ユーザーの影響なし（隠しカナリア、レプリカ、並列入力）
• プロバイダ主導：外部プロバイダ（PSP/KYC/CDN/Cloud）のウィンドウ。

2）原則

SLO-first：ウィンドウの時間/形式の決定は、SLIとエラー予算への影響に応じて行われます。
最小爆発半径：canary→stepwise→full inclusion。
リバーシビリティ：各操作にはバックアウトプランと実績のあるロールバックがあります。
真実の単一のソース：完全なデータパッケージを持つウィンドウのカレンダー+チケット/RFC。
証拠：証拠収集（ログ、グラフ、スクリーンショット、アーティファクトハッシュ）。
SLA通信：事前に、作業中、完了時。

3）計画： タイミングとカバレッジ

ウィンドウの選択：トラフィックが少なく、主要なコホート（リージョン/VIP/パートナー）への影響が最小限に抑えられます。
タイムゾーン：UTC+現地時間（ヨーロッパ/キエフなど）で記録します。
停電期間：ピークシーズン/イベント（マッチ、販売、リリース「死の窓」）中の仕事の禁止。
ブラスト半径：影響を受ける人（サービス、地域、プロバイダ）を明確に定義します。

4）交渉プロセス（RFC/CAB lite）

1.発行元は、リスク分析と計画を持つチケット/RFCを作成します（下のテンプレートを参照してください）。
2.リスク評価（Low/Med/High）およびサービス+SRE/セキュリティの所有者による承認。

3.カレンダー： スロット予約；競合チェック（他のウィンドウ/プロバイダ）

4.Commプラン：事前に合意された通知とステータスページ。
5.ハイリスクな変更のためのGo/No-Go会議（24-48時間）。

5）準備： セキュリティゲート

発射前のチェック：ステージテストの成功、アーティファクトの署名、トータルリスク≤許容されます。
カナリア州：1％→5％→コホート/地域による25％；自動SLO gardrailsおよび自動ロールバック。
劣化フラグと制限は準備ができています。
サンドボックスでチェックされたロールバック/バックアウトプラン；rollbackコマンドはドキュメント化されています。
アラートの抑制：期待されるノイズに対してのみ、SLO信号はマフルされません。
アクセス：業務のJIT/JEAアカウント、必須監査。

6）コミュニケーション（タイミングと内容）

T-14/7/2日（予定）：クライアント/社内チームのヘッドアップ（what/when/impact/contacts）。
T-60/30/15分：内部およびステータスページのリマインダー。
作業中：テンプレートに従って15〜30分ごとに更新（SEV依存）：Impact→Stage→Next update。
After： final「完了/部分完了/ロールバック」、変更のリスト、SLOチェック。

7）作品のパフォーマンス（参考シナリオ）

1.関係のないリリースをフリーズします。
2.カナリア（制限されたコホート）への移行→SLI/p95/p99のメトリックを観察する。
3.緑のガードレールとのシェアの段階的な増加。
4.ビジネスSLIの検証（変換、支払い/登録の成功）。
5.リスト機能検証（ハッピーパス+クリティカルシナリオ）をチェックします。
6.リリース/リリースなしソリューション（IC/SRE/サービス所有者）。
7.抑制の除去、アラートポリシーの返却。

8）ウィンドウの後： 検証とレポート

観察ウィンドウ（例えば、1-24時間）：SLOとエラーを追跡します。
ウィンドウレポート：何が行われたのか、指標、偏差、証拠、合計。
問題があった場合：AAR→RCA→CAPA（ルール、テスト、ドキュメントを修正）。
アーカイブ：チケット、アーティファクト、署名、チェックサム。

9）外部プロバイダーとの連携

確認されたスロットとプロバイダの連絡先；ステータスシステムのウィンドウ。
仕事の期間のための代替プロバイダへのフォールバック/ルーティング。
プロバイダ（チャット/ブリッジ）とSLAの更新を備えたシングルウォールルーム。

10）プロセス成熟度の指標

オンタイムレート：ウィンドウの％が時間通りに開始/完了しました。
障害率の変更：SLOにロールバック/影響を与えるウィンドウの％。
インシデント中-MW：ウィンドウ中に発生したインシデント。
コミュニケーションSLA：タイムリーなアップデートの共有。
証拠の完全性：完全な証拠パッケージの窓の％。
顧客への影響：1つのウィンドウ、トレンドの苦情/チケット。
7/30日後：SLOの安定性と再発はありません。

11）チェックリスト

ウィンドウの前に

• RFC/チケットは満席です。リスクアセスメントが完了しまし;所有者が割り当てられました。
• キャナリーとバックアウトプランがチェックされています。ロールバックコマンドをテストしました。
• 発行されたJITアクセス；アラートは設定されています（SLOはジャミングされません）。
• カレンダー/ステータスページと通知が用意されています。
• リリース/競合するWindows-凍結/シフト。
• プロバイダが確認しました。連絡先とSLAが記録されます。

期間中

• スケジュールの更新；戦争部屋は活発です。
• SLO/ピークエラーのガードレールは尊重されます。違反の場合-自動ロールバック。
• 証拠が収集されます（スクリーンショット、グラフの前後、アクションログ）。

After

• 観察窓の間の緑の区域のSLO。
• 証拠付き最終報告書；ステータスページを更新しました。
• CAPAが発行されます（偏差があった場合）。ドキュメントを更新しました。

12）テンプレート

メンテナンスウィンドウごとのRFCテンプレート

RFC: MW-2025-11-05-DB-Upgrade
Window: 2025-11-05 00: 00-02: 00 UTC (Europe/Kyiv 02: 00-04: 00)
Service/component: payments-db (PostgreSQL cluster A)
Type: Planned (High)
Target: Upgrade to 15. x for security/bugs
Blast radius: EU region, tenant EU, all write operations
Impact: up to 2 × p99 growth to 400 ms; short-term read-only (≤5 min)
Gardrails: error-rate <0. 5%, p99 <400 ms, SLO not impaired
План: expand→migrate→contract; canary 1 %/5 %/25%; 1..N steps (with commands)
Backout: rolling back replica/slots; TTL DNS does not change; rollback time ≤ 10 min
Suppression: noise of database/replica alerts; SLO alerts are active
Communications: T-7/T-2 days and T-60/15 minutes; war-room #mw-db-a
Owners: @ db-tl, @ sre-ic, @ payments-pm
Evidence: before/after p95/p99 graphs, migration logs, checksums
Risk: High (data) - confirmed by CAB

クライアント通知テンプレート（概要）

Topic: Planned work 05. 11. 2025 02:00–04:00 (Europe/Kyiv)
We will update the payment database. Short delays and read-only mode (up to 5 minutes) are possible.
On-call contacts: status. example. com      support@example. com

抑制ルール（アイデア）

yaml suppress:
- name: db-maintenance when: window("2025-11-05T00:00Z","2025-11-05T02:00Z")
match: [ "db. replica. lag", "db. connection. reset", "migration. progress" ]
keep: [ "slo. payment. success", "api. availability" ]

13）規制されたドメインの機能

監査ログの変更不可能：誰が承認したのか、誰が実行したのか、どのコマンドを実行したのか、アーティファクトのハッシュ。
PII/ファイナンス：証拠のマスキング、レポートへのアクセス制限。
顧客およびパートナーへの通知の条件-契約に従って。
プロバイダのウィンドウ-外部SLAと連絡先で文書化されています。

14）アンチパターン

バックアウトプランと検証済みロールバックなしのウィンドウ。
SLO信号の詰まり「ちょうど」。
同じドメイン/地域のウィンドウを競合します。
Commの沈黙：更新の前/中/後。
監査とスクリプトなしで製品内の手動編集。
不確実な成功基準による「無限」ウィンドウ。
証拠の欠如-品質を確認するものではありません。

15）導入ロードマップ（4〜6週間）

1.ネッド。単一のカレンダーとRFCテンプレートを1-Enterすると、停電期間が定義されます。
2.ネッド。2：ゲート（カナリア、SLO-gardrails、バックアウト）を標準化します。
3.ネッド。3：抑制/リリースアノテーションとステータスページを自動化します。
4.ネッド。4：レポートおよび成熟度の指標；毎週MW-review。
5.ネッド。5-6：プロバイダおよび監査アーカイブとの統合；ハイリスクなウィンドウシミュレーション。

16）ボトムライン

適切に整理されたサービスウィンドウは、管理しやすく、リバーシブルで、確実に変更を保護します。SLOガードレール、カナリアラスプ、厳格な通信、証拠の完全なセットで、ウィンドウは「ひどいダウンタイム」からユーザーやパートナーのための驚きなしに改善のルーチンのメカニズムに変わります。