運用と管理→変更管理

変更管理

1）目的と原則

目標は、変更を迅速かつ安全に実施し、インシデント、ダウンタイム、規制違反のリスクを低減することです。

• 予測可能およびリバーシブル：各変更は計画的、検証可能、およびリバーシブルです。
• リスクベース：コントロールの深さは、リスク（管轄、お金、PII）に依存します。
• Small&Frequent：スモールインクリメントは評価とロールバックが簡単です。
• 最初に自動化：コード、テスト、検証、自動チェックとしてのインフラストラクチャ。
• 単一の真実のソース：単一のRFC/チケット、単一のカレンダーとアクションのログ。

2）スコープ

製品コード（バックエンド/フロントエンド、モバイルSDK）。
インフラストラクチャ（IaC、 Kubernetes/VM/CDN/Edge）。
データ（DB図、移行、ストアフロント/ETL）。
設定とフィーチャーフラグ。
統合（PSP、 KYC、ゲームプロバイダ）。
セキュリティとアクセスポリシー。

3）役割とRACI

所有者責任を変更します。
リリースキュレーター/RelEng-リリーストレインコーディネート。
SRE/Ops-操作、SLO/SLAゲート。
セキュリティ/コンプライアンス-リスクとコンプライアンスを見直します。
CAB （Change Advisory Board）-通常/高リスクの変更の承認。
ビジネスステークホルダー/サポート-お知らせ。

4）変更の分類

標準（標準、事前承認済み）：頻繁、低リスク、既製のプレイブック（例：フラグの更新、キーの回転）。
通常：RFC、評価、可能なCAB、テスト、ロールバック計画が必要です。
緊急：P1インシデントの緊急修正。最小限の官僚的パス、post-factum review/SAW。

5）ライフサイクルの変更

1.トリガー（RFC）：目的、範囲、リスク、影響を受けるサービス/地域、バックアウトプラン。
2.リスクアセスメント：影響×可能性マトリックス、SLO/コンプライアンス/価値への影響。
3.プランニング：ウィンドウ、依存関係、移行、通信、検証テスト。
4.検証：autotests、静的解析、セキュリティチェック、パフォーマンス実行。
5.展開：プログレッシブ戦略（第8条を参照）、テレメトリーおよびガードレール。
6.観察：バーンレートSLO、アラート、ビジネスメトリック（GGR/NGR、変換）。
7.完了：結果の受け入れ、ドキュメントの更新、偏差のための死後。

6） RFC： 最低の構成

コンテキスト：なぜ変化し、仮説に影響を与えるのか。
範囲：システム、地域、顧客のバージョン。
リスク：マトリックスと故障シナリオ、ブラスト半径。
導入計画：段階的に、go/stopの基準を設定します。
バックアウトプラン：コマンド/ステップ、開始条件、RTO/RPOの期待値。
テストプラン：前後にチェックするもの（機能性、性能、安全性）。
コミュニケーション：私たちが通知する人、メッセージテンプレート。
監査：チケット、コミット、CI/CDアーティファクトへのリンク。

7）カレンダーとウィンドウを変更する

シングルカレンダー：すべてのリリース、移行、機能のオフ、外部イベント（スポーツ/マーケティング/休日）。
凍結ウィンドウ：主要な販売/選手権/ピーク時間、税務報告。
干渉ポリシー：同じクリティカルパスに対する相反する変更を防止します。
地域の波：最初の「暖かい」地域/低トラフィック、その後-主なもの。

8）技術的展開戦略

カナリア：トラフィックのシェアが小さい→メトリックの比較（p95レイテンシー、エラー％、変換）。
Blue-Green：パラレル環境、アトミックルートスイッチング。
進歩的な配達：自動停止条件のパーセンテージのロールアウト。
フィーチャーフラグ：ファンクションスイッチ、キルスイッチ、A/B。
Dark Launch/Shadow Traffic：ユーザーに影響を与えずに影をチェックします。
ステップの限界：QPS/競争力の段階的な増加。

Gardrails： p95/error％のしきい値を超えた場合の自動停止、返品/チャージバックの増加、承認/預金の減少。

9）データとスキーマの変更

互換性：古いスキーマと新しいスキーマの両方を読み取るadditive migrations→code。
二相マイグレーション：（1）新しいフィールド/インデックスを追加する→（2）スイッチコード→（3）古いフィールドを削除する。
契約バージョン管理：Avro/Protobufスキームとレジストリ；背部/前方互換性がある。
大容量の移行：バッチ、一時停止、idempotency、チェックポイントと進行。
災害公差：RPO/RTOテスト、スナップショット、回復リハーサル。
BIデータ：ショーケース/メトリクスの変更-MR/SRおよびメトリクス辞書（ID、数式）。

10）構成および秘密管理

データとしての設定：バージョン管理された構成、スキームによる検証、環境を通じたプロモーション。
秘密：主要なローテーション、最小特権の原則、要求の監査。
リージョナルオーバーライド：リミット/パートナー（PSP/KYC）-パラメータ化を通じて、コードのフォークを介してではありません。

11）コンプライアンスと監査（iGamingコンテキスト）

変更の痕跡：who/when/what switched（フラグ、configs、 routes、 migrations）。
職務の分離：著者、レビュアー、およびデプロイ（SOXのような）のための異なった役割。
規制レポート：固定リリース、和解のバージョン管理（GGR/NGR、ボーナス）、PIIへのアクセスの制御。
プロバイダ：固定バージョンのSDK/プロバイダ証明書、SLA義務。

12）コミュニケーション

アラートテンプレート：リリース前（what/when/risk）、中（status、％ traffic、 metrics）、後（totals）。
外部メッセージ：顧客に影響を与えるときのバナー/ステータスページ。
コーディネート：#release-war-roomチャンネル、リリースオーナー、更新頻度。

13）パフォーマンスメトリック

DORA：展開頻度、変更のリードタイム、Change Failure Rate （CFR）、 MTTR。
SLOインパクト：リリースの前後にSLOで時間を共有します。
「バックアウトレート」（Backout Rate）-変更カテゴリによるロールバックの頻度。
リリースデット：limboで保留中の移行/フィーチャーフラグ。
ビジネスへの影響：転換、KYC TTV、成功率PSP、圧延時のGGR/NGRドリフト。

14）アンチパターン

ビッグバンのリリース：一度に多くの変更があります-回帰の原因を理解するのは難しいです。
互換性のないマイグレーション：フィールドを二重読み取りなしで削除/名前変更します。
削除のための所有者と締め切りなしのフラグ：「永遠の」ロジックの枝。
テレメトリーおよび停止基準のないリリース：「目で」および損傷の遅延検出。
カレンダーを無視：ピークイベント/キャンペーンとの交差。
プレイブックと監査のない手動手順：高い変動性とリスク。

15）チェックリスト

開始前（RFC準備完了）

• 目的の変更とKPIの策定
• リスクとブラスト半径の評価、選択したクラスの変更
• 展開計画とバックアウトはステップバイステップで書かれています
• ステージ/カナリアにテストプランと結果があります
• コミュニケーションとカレンダーの更新、ステークホルダーに通知

圧延中

• p95/error％メトリック、ビジネス信号、ログをリアルタイムで監視
• 進捗状況の確認はチェックポイントで行います
• gardrailsの動作時-自動停止とロールバック

After

• リリース結果の記録（changelog、バージョン、アーティファクト）
• 偏差のための死後（≤ 5営業日）
• 負債（フラグ削除、最終的な移行）は所有者で記録されます

16）ミニテンプレート

• 目的/仮説
• 範囲と影響（サービス、地域、データ、顧客）
• 影響×可能性と緩和措置
• ローリングプラン（ステップ、％トラフィック、go/no-go基準）
• バックアウトプラン（ステップ、RTO/RPO、データ）
• テストプラン（機能/性能/安全）
• コミュニケーション（チャネル、頻度）
• アーティファクト（チケット、PR、ビルド番号）

• 変更："Payments-Service v2。14+psp_limits移行"
• ウィンドウ：2025-11-02 00： 00-01：00 EET
• 影響を受ける地域：EU、 LATAM （10％→50％→100％）
• リスク/ガードレール：エラー％>2％10分-停止およびロールバック
• お問い合わせ：@オーナー、@SRE-on-call、@Support-lead

• トリガー：p95>+25％10分、PSP成功<97％
• ステップ：（1）トラフィック−→v2の0％。14;（2）フラグをv2に切り替えます。13;（3）スナップショット/チェックポイントによる移行ロールバック。（4）煙試験；（5）報告書。

17）解放列車との統合

リリーストレイン：固定スロット（例：2 ×週あたりの）、マージカットのSLA。
Hotfixポリシー：個々の列車/支店、プロッドへの高速トラック。
バージョン管理：semver、アーティファクトと環境のラベル、SBOM。

18）ボトムライン

変更管理は速度のブレーキではなく、安全な加速のためのメカニズムです。リスクベースの分類、優れたRFC、プログレッシブローリング、互換性のあるデータ移行、明確なコミュニケーション、測定可能なエフェクトにより、リリースは管理可能で再現性があり監査可能なプロセスに変わります。