変更管理

目的

変更管理は従来、IT 環境における変更を慎重に管理するために適用されるプロセス、手順、ツール、技術を指してきました。変更チケットや計画書、承認、変更レビュー会議、スケジューリング、その他の形式的な手続きがこれにあたります。

私たちのコンテキストでは、変更管理とは、（優先度の高いものから低いものへ）安全に、効果的に、効率的に行うことを目的として、運用環境の変更を管理するために適用するガイドラインを指します。場合によっては従来の変更管理の要素を使用する必要がありますが、ほとんどの場合、安全な方法でスピードを高めるために従来の変更管理の側面を取り除く自動化を構築することを目指しています。

私たちの最優先目標は、従来の変更管理の側面を回避する変更を最大化することです。これは時間をかけて進化していくイテレーティブなプロセスです。成功の指標は、ビジネスニーズに求められるスピードで安全に変更を実行できる能力です。

スコープ

変更とは、設定の変更、環境へのコンポーネントやサービスの追加・削除、クラウドインフラストラクチャの変更を含む、運用環境への変更として定義されます。私たちのステージング環境は GitLab.com リリースプロセスにとって重要です。そのため、ステージングは GitLab の運用環境の一部として変更管理のスコープ内にあるとみなすべきです。アプリケーションのデプロイは、技術的には変更ですが、変更管理プロセスから除外されています。同様に、ほとんどの（ただし全てではない）フィーチャーフラグのトグルも除外されています。

インシデント解決中に実行する必要がある変更は、インシデント管理の対象となります。

役割と責任

役割責任
GitLab チームメンバーこの手順の要件に従う責任
インフラストラクチャチームこの手順の実施および実行の責任
インフラストラクチャ管理 (コードオーナー)重要な変更およびこの手順の例外を承認する責任

変更リクエストが必要ですか？

あなたの変更は:

  • 何らかのリスクを伴いますか？

    この質問への回答に役立つヒント: この変更は以前に試みられたことがありますか？非本番環境でどれだけ広範にテストされましたか？本番環境で問題が発生しないという証拠にどれだけの確信を持っていますか？

  • デプロイやフィーチャーフラグの一時停止が必要ですか？
  • 手動手順が必要ですか？
  • 複数の部門に影響を与え、可視性の向上が必要ですか？

上記の質問のいずれかに YES（または「おそらく」）と答えた場合は、変更リクエストワークフローに従う必要があります。このワークフローの意図は、悪影響を与える変更が本番環境に到達する可能性を、可視性を高めることで低減することです。そして、この種の変更が実際に本番環境に到達した場合に備えて、レビュー済みのロールバック計画を用意しておくことで、できるだけ早く良好な状態に戻せるようにすることです。

変更リクエストワークフローに従うべき変更の例:

変更リクエストが不要な場合

変更リクエストが不要な変更の種類（非網羅的リスト）:

  • マージリクエストをマージすると自動的にデプロイされ、ロールバックがそのマージリクエストの revert である場合。
  • 低リスクとみなされるマージリクエスト。
  • 環境にとって重要でないマイナーな依存関係の更新。
  • 設定を通じて行われ、リスクがないとみなされるフィーチャーフラグの切り替え。

例:

確信が持てない場合

変更リクエストのワークフロー

計画 Issue は production プロジェクトトラッカーで変更管理 Issue テンプレートを使用して開かれます。各 Issue は、重要度レベル C1、C2、C3、または C4 に対応する Issue テンプレートを使用して開く必要があります。提案された変更の詳細な説明とテンプレートに記載されたすべての関連情報を含める必要があります。すべての計画 Issue は、レビューされてスケジュールが設定されるまで、最初は ~"change::unscheduled" のラベルが付けられます。計画が承認されスケジュールされたら、可視性のために ~"change::scheduled" のラベルを付けます。

Slack から変更管理 Issue を開くには、以下のスラッシュコマンドを使用してください。

/change declare

Slack から変更 Issue を作成すると、説明の一部のフィールドが自動的に入力されます。

変更の中止

変更がロールバックされた場合、または完了しない場合は、change::aborted ラベルを適用して Issue をクローズしてください。後日変更が再試行される場合は、新しい変更宣言を行う必要があります。

変更の重要度

C1 および C2 の変更リクエストには、~blocks deploys および ~blocks feature-flags ラベルが自動的に付けられます。これらの重要な変更リクエストが change::in-progress とラベル付けされると、デプロイ、フィーチャーフラグの変更、および潜在的にはその他の操作がブロックされます。このような操作に対しては、適切な時間の見積もりを行い、予想より長くかかる場合でも安全に停止できるポイントやコントロールを設けることに特に注意してください。提案された変更が該当する操作に悪影響を受けない場合は、~blocks deploys や ~blocks feature-flags を削除してください。

特に長時間実行の Rails コンソールタスクについては、承認・認知のために C2 として開始し、実行中に C3 にダウングレードすることが許容される場合もあります。ただし、複数のデプロイにまたがって長時間実行されるコードの影響と、時間の経過とともにコードとデータストレージが不一致になるリスクを慎重に検討してください。このようなラベルのダウングレードには、実行されるコードの安全性を評価するために少なくとも 2 組の目（SRE/開発者）があることが理想的であり、可視性のために管理職の承認を推奨します。

重要度 1

これらは高い影響または高いリスクを伴う変更です。変更が本番環境のダウンタイムを引き起こす場合は、常に C1 に分類されます。

重要度 1 の例:

  1. DB 機能に影響する Postgres ホストへのすべての変更（例: ノード数、バックアップ戦略の変更、レプリケーション戦略の変更、設定変更など）。
  2. Infrastructure as Code (IaC) への主要なアーキテクチャ変更。
  3. ペット（Postgres、Redis、その他の単一障害点）への主要な IaC 変更。
  4. 主要なベンダーまたはサービスプロバイダーの変更（例: CDN、トランザクションメールプロバイダー、DNS など）。
  5. ツールのメジャーバージョンアップグレード（www.semver.org のメジャー定義に従う）（例: HAProxy、AlertManager、Chef など）。
  6. 私たち自身が生成したカスタムビルドの作成とデプロイは一般的に推奨されません。公式のアップストリームリリースに含まれる前にセキュリティまたは安定性パッチを適用する必要がある場合などで必要になる場合があります。重要度 1 ガイドラインに従った場合のみ許可されます。
  7. アラートインフラストラクチャへの主要なアーキテクチャまたはツール変更。
  8. 証明書機関の変更/新しい SSL 証明書のアップロードを含む手順。

承認

  1. Issue に期日が設定され、GitLab 本番カレンダーにイベントが追加されていることを確認する。
    1. 計画可能な C1（プロアクティブなメンテナンス、スケジュールされたアップグレード、計画されたインフラストラクチャ変更を含むがこれに限らない）は、適切なステークホルダー通知を確保するために最低 2 週間のリードタイムが必要です。
  2. ダウンタイムを含む変更はユーザーに事前に通知する必要があります。ダウンタイムが必要な変更の伝達のガイダンスに従ってください。
  3. データベース関連の変更はすべて DBRE のレビューを受ける必要があります。
  4. 変更リクエスト Issue に platform_leadership_approved ラベルを取得することで、インフラストラクチャ Platform リーダーシップ（EM+ またはインフラストラクチャ Platforms の Staff+ IC）による変更の承認を受ける。@gitlab-org/saas-platforms/change-review-leadership にメンションして承認を依頼してください。レビュアーは変更の著者とは異なるチームである必要があります。承認前にプラットフォームリーダーシップレビューガイドラインを確認してください。
  5. 変更時刻にスケジュールされているオンコールエンジニア（EOC）を特定し、スケジュールが設定され次第、変更計画を通知する。 （出典は incident.io。アクセス権がない場合はサポートを受けてください）
  6. デプロイまたはマイグレーションを変更に必要に応じて一時停止できるよう、Slack で @release-managers に、または Issue で @gitlab-org/release/managers にメンションする。
  7. @sre-oncall エイリアスを使用して EOC に直接通知しながら #production Slack チャンネルで計画実行の開始を発表し、変更タイミングに影響する可能性のある進行中のインシデントがないことを確認する。確認後、EOC は eoc_approved ラベルを適用し、変更を進めることができます。
  8. EOC と共に「シチュエーションルーム」Zoom チャンネルに参加し、計画実行開始の口頭承認を得る。

EOC は変更実行全体を通じて関与し続ける必要があります。

重要度 2

これらは高い影響または高いリスクを伴う変更です。変更がステージング環境のダウンタイムを引き起こす場合は、常に C2 に分類されます。

これらは本番環境のダウンタイムを引き起こすことは想定されていませんが、予期しないことが起きた場合の影響のリスクがある変更です。たとえば、過剰プロビジョニングを確認したためカトル（cattle）のフリートのサイズを削減することは通常問題ありませんが、変更の前後で注意深く監視する必要があります。

重要度 2 の例:

  1. 重要度 1 の要件を満たさないデータベース設定の変更は、すべて重要度 2 の変更とみなすべきです。
  2. Infrastructure as Code (IaC) へのほとんどのアーキテクチャ変更。
  3. HTTP ルーターのルーティング変更。
  4. トポロジーサービスのセル設定変更とルーティングロジック変更。
  5. ペット（Postgres、Redis、その他の単一障害点）へのほとんどの IaC 変更。
  6. ロードバランサーの設定 - トラフィックフローの基本となるバックエンドまたはフロントエンドへの主要な変更。
  7. Kubernetes 以外の本番仮想マシンへの IaC 変更（減少がある場合）。
  8. 本番問題のトラブルシューティングに不可欠な Teleport への主要な変更。
  9. アラートルーティングまたはインテグレーションへの主要な変更。
  10. 本番コンサーバー上で gitlab-rails または gitlab-rake を使用して実行する SQL スクリプト、Ruby スクリプトモジュール、rake タスクなどの手続き的な呼び出しは、すべて重要度 2 の変更とみなすべきです。

承認

  1. Issue に期日が設定され、GitLab 本番カレンダーにイベントが追加されていることを確認する。
  2. ダウンタイムを含む変更はユーザーに事前に通知する必要があります。ダウンタイムが必要な変更の伝達のガイダンスに従ってください。
  3. データベース関連の変更はすべて DBRE のレビューを受ける必要があります。
  4. 変更リクエスト Issue に platform_leadership_approved ラベルを取得することで、プラットフォームリーダーシップ（Staff+ SRE、プリンシパルエンジニア、またはシニアスタッフエンジニア）による変更の承認を受ける。@gitlab-org/saas-platforms/change-review-leadership にメンションして承認を依頼してください。レビュアーは変更の著者とは異なるチームである必要があります。承認前にプラットフォームリーダーシップレビューガイドラインを確認してください。
  5. 変更時刻にスケジュールされているオンコールエンジニア（EOC）を特定し、計画をレビューしてもらう。 （出典は incident.io。アクセス権がない場合はサポートを受けてください）
  6. @sre-oncall エイリアスを使用して EOC に直接通知しながら #production Slack チャンネルで計画実行の開始を発表し、変更リクエスト Issue に eoc_approved ラベルを取得することで EOC から変更の承認を得る。

重要度 3

これらはリスクがないかごく低リスクの変更ですが、多少の固有の複雑さがあるか、完全に自動化されて非対話的ではない変更です。

重要度 3 の例:

  1. 手動介入が必要な IaC 変更（例: Terraform ステートの操作）。
  2. 手動の変更（例: Grafana へのプラグインの追加）。
  3. サービスプロバイダーの設定変更（例: CDN、トランザクションメールプロバイダー、DNS など）。
  4. ツールまたはコンポーネントのマイナーバージョンアップグレード（semver.org のマイナー定義に従う）（例: HAProxy、AlertManager、Chef など）。
  5. IaC からの古いホストの削除（例: レガシーインフラストラクチャの削除）。

承認

  1. Issue に期日を追加する。
  2. 計画が Reliability の他の誰かによってレビューされることを確認する。

重要度 4

これらは非常に低リスクで一般的に実行される変更、または完全に自動化された変更です。これらは多くの場合、実質的な管理手段としてというよりも、可視性のために記録されている変更です。

重要度 4 の例:

  1. ライブデータに対して変更操作を実行することになる既存のコードパスの呼び出し。これは、通常、読み取り専用操作に限定すべき診断調査操作とは区別されます。エンジニアの裁量に委ねられており、そのような診断の呼び出しをピアに共同観察してもらう必要があるかどうかは任意です。

承認

承認不要。

変更手順

変更計画には手動タスクが含まれることが多いです。

  • コマンドラインツールの代わりに UI を使用することを避けてください。たとえば、GCP コンソールの代わりに gcloud コマンドラインユーティリティを使用します。
  • 多くの個別シェルコマンドよりもスクリプトの使用を検討してください。
  • スクリプトが必要な場合は、ドライランの機能を追加し、GitLab のスクリプトガイドラインに従うことを検討してください。

変更のスケジューリング

UTC がすべての変更のスケジュール時刻について話す際の標準タイムゾーンです。

変更をスケジューリングする際は、変更の影響を念頭に置き、以下の質問を検討してください。

  1. 同じ時刻前後に他の C1/C2 変更が行われていますか？
  2. 実行される変更に計画されたフェイルオーバーやその他の高リスクコンポーネントが含まれており、低トラフィック期間に変更を実行することで顧客へのリスクを低減できますか？
  3. 変更の DRI として、合意された期間、変更を監視し、EOC にそのステータスを伝えることができますか？
  4. 変更に起因する問題からの回復（つまり変更のロールバック）に適した時刻に変更を実行していますか？変更技術者の業務日の早い時間帯に変更をスケジュールし、予期しない影響が目に見えるようになるまでの数時間後まで対応できるようにすることは、一般的なベストプラクティスです。そうすることで、変更技術者はまだ対応しており、その影響を緩和・対処できます。
  5. 提案された時刻にオンコールエンジニアまたはリリースマネージャーのシフト交代がありますか？

変更の実行

変更がスクリプトによって実行される場合、ターミナルマルチプレクサ（例: screen または tmux）セッションの中で、対象環境の踏み台ホストから実行する必要があります。踏み台ホストを使用すると、意図しない操作（例: スクリプトのバグによる）が他の環境に広がるのを防ぐメリットがあります。ターミナルマルチプレクサは、変更の途中で踏み台への接続が切れた場合や、その予測できない結果から保護します。

sudo は踏み台ホストで無効化されているため、スクリプトが必要とする場合に Chef PEM ファイルをいずれかにコピーしても、盗み見される恐れなく行えます。

スクリプトを実行するための一連のアクションは次のようになります。

your-workstation $ ssh -A bastion-01-inf-gstg
bastion-01-gstg  $ tmux
bastion-01-gstg  $ git clone [email protected]:my-migration/script.git
bastion-01-gstg  $ ./script/migrate

変更レビュー

メンテナンス変更には変更レビューが必要です。レビューは、特定の変更の潜在的なリスクを指摘するためのフォーラムを提供しながら、チームの集合的な経験を活かすことを意図しています。~C1 または ~C2 変更リクエストには複数のレビュアーを使用することを検討してください。

誰にレビューをリクエストすればよいか分からない場合は、#s_production_engineering で SRE に変更リクエストのレビューを依頼してください。

Issue に割り当てられた変更重要度ラベルに基づいて、変更レビュアーチェックリストの各項目を記入してください。

コミュニケーションチャンネル

情報はすべての変更において重要な資産です。情報を意図した宛先に適切に管理することは、タイムリーにステークホルダーに状況を通知するために重要です。変更が実施されているという認識は、ステークホルダーが当該変更のための計画を立てるのに役立ちます。

この情報の流れは以下によって決まります。

  • 情報の種類
  • 意図された対象者
  • タイミングの感度

たとえば、大きなエンドユーザーが、変更によって自分たちのリリースに影響が出る可能性を避けるために、メンテナンスウィンドウ中にソフトウェアリリースを行わないことを選択するかもしれません。

さらに、すべてのステークホルダーの注意を引きつけるために、情報過多を避けることも必要です。

コミュニケーションを改善するために、高重要度の変更に対して以下を推奨します。

  • 変更中にインシデント Zoom チャンネルを使用する
  • さまざまな対象者向けの定期的な更新（CMOC が処理）:
    • エンドユーザー（Twitter）
    • eStaff
    • サポートスタッフ
    • 従業員全体
  • メンテナンス完了後、次のオンコールチームメンバーへの引き継ぎメモを残す。以下の項目を含めること:
    • メンテナンスの状態/成功
    • 無効化されていて引き継ぎ後に発動する可能性のあるアラート
    • 懸念される領域を監視するための特定のグラフへのリンク

ダウンタイムが必要な変更の伝達（「メンテナンスウィンドウ」）

時折、顧客と SLO に影響を与えるダウンタイムが必要な本番変更を実行する必要があります。このセクションでは、このような状況でのコミュニケーションを成功裏に管理する方法について説明します。

参考として、大規模なアーキテクチャ変更を伴わない C1 の場合、変更の 5〜6 週間前にコミュニケーションを行う必要があります。変更に大規模な移行や大きなアーキテクチャ変更が含まれる場合は、より長い準備時間が推奨されます。

手順:

  • 変更 Issue に、外部向けの文章の草稿と共にコミュニケーションのステップを追加する。
  • 変更 Issue に ~Scheduled Maintenance ラベルを追加するか、機密 Issue が必要な場合は external_communication テンプレートを使用して新しい Issue を作成する。
  • 全体的な計画と予想される影響について以下からの承認を得る:
  • 少なくとも変更の 1 か月前（可能であれば）:
    • #customer-success Slack チャンネルで CSM に、主要顧客へのこの変更の伝達方法についての希望を確認する:
      • @cs-tam-mgrs エイリアスを使用して CSM マネージャーに、上位 SaaS 顧客の CSM に通知するよう依頼するようピングする。
      • 彼らが顧客チャンネルで変更の詳細についてコミュニケーションを取ることを提案する場合があります。その場合は、メッセージの草稿を作成し、CSM とその内容について合意し、関連する顧客 Slack チャンネルで共有する（CSM と同期して）。
    • #whats-happening-at-gitlab Slack チャンネルで情報と Issue へのリンクを共有し、可視性と関与のために @release-managers、@db-team、@dbre にメンションする。
  • それから間もなく、コミュニケーションまたは変更 Issue を status.io の簡単な投稿にリンクする（「new maintenance」をクリックして）。status.io でこのメンテナンスを共有し、CMOC を巻き込み、可能なすべてのチャンネル（メール、ツイート、Slack など）を通じて共有します。そこから顧客は質問やコメントができるようになります。[顧客へのダウンタイムの公式な伝達方法は status.io 経由です]。
  • この時点から、予定された変更が公開されている場合は:
    • 顧客からの質問やコメントがあるかを確認するために、定期的にコミュニケーション Issue を確認し、タイムリーに対応する。
    • status.io を通じて、変更時刻の 2 週間前、1 週間前、3 日前、1 日前に顧客に変更を念押しする。

本番変更ロック（PCL）

私たちが行う変更は厳密にテストされ慎重にデプロイされていますが、GitLab サミット、主要なグローバル休日、その他 GitLab チームメンバーの稼働率が大幅に低下する期間などの特定のイベント中は、本番変更を一時的に停止することが最良の慣行です。

チームメンバーのカバレッジが低い場合やプラットフォームが著しく不安定な場合以外は、ハード PCL を作成しません。イベント中のプラットフォームの安定性が心配な場合は、ソフト PCL オプションを検討してください。

このような期間中に本番環境の変更を行うリスクとして、即時の顧客影響や、インシデントが発生した場合のエンジニアリングチームの稼働率低下が挙げられます。そのため、**本番変更ロック（PCL）**と呼ばれるメカニズムを導入しました。PCL 中は自動デプロイが一時停止されます。EOC の判断でデプロイを手動実行することができます。たとえば、EOC は GitLab.com の安定性を確保するため、または PCL 解除後もデプロイが順調に続くようにするためにデプロイを選択する場合があります。

PCL には 2 種類あります: ソフトとハード。

PCL 中に制限される内容

活動ソフト PCLハード PCL
インフラストラクチャ変更（C2+）❌ ブロック❌ ブロック
インフラストラクチャ変更（C3、C4）✅ 許可❌ ブロック
カナリアへのコードデプロイ✅ 許可❌ ブロック
本番へのコードデプロイ（デプロイ後マイグレーションなし）✅ 許可（EOC との調整が必要）❌ ブロック
本番へのコードデプロイ（デプロイ後マイグレーションあり）❌ ブロック（緊急時のみ）❌ ブロック
フィーチャーフラグの切り替え（変更 Issue 不要）✅ 許可❌ ブロック
フィーチャーフラグの切り替え（変更 Issue 必要）変更管理プロセスに従う❌ ブロック
S1/S2 インシデント対応変更✅ 許可（承認を得て）✅ 許可（IM & EOC 承認を得て）

ソフト PCL

ソフト PCL は、すべての本番変更を停止せずにリスクを軽減することを目的としています。

ブロックされるもの:

  • 重要度レベル C2 以上のインフラストラクチャ変更
  • デプロイ後マイグレーション（EOC 承認の緊急時を除く）
  • 変更管理 Issue が必要なフィーチャーフラグの切り替え（変更管理プロセスに従うこと）

許可されるもの:

  • 重要度レベル C3 または C4 のインフラストラクチャ変更
  • カナリアへのコードデプロイ（カナリアの影響をコントロールするツールがある）
  • デプロイ後マイグレーションなしの本番へのコードデプロイ（EOC との調整が必要）
  • 変更管理 Issue を必要としないフィーチャーフラグの切り替え
  • C1 および C2 インフラストラクチャの緊急変更（EOC とオンコールインシデントマネージャーとの連携が必要）

ソフト PCL 中のフィーチャーフラグガイドラインについては、フィーチャーフラグと変更管理プロセスを参照してください。

ハード PCL

ハード PCL はソフト PCL のすべての制限を含み、さらに重要度レベルに関係なくすべてのインフラストラクチャ変更とコードデプロイに追加制限があります。

ブロックされるもの:

  • すべてのコードデプロイ（カナリアおよび本番）
  • すべてのインフラストラクチャ変更（C1、C2、C3、C4）
  • すべてのフィーチャーフラグの切り替え
  • デプロイ後マイグレーション

許可されるもの:

  • アクティブな S1/S2 インシデント対応に必要な変更（EOC とオンコールインシデントマネージャー両方の承認が必要）

S1/S2 インシデント変更の承認プロセス:

アクティブな S1/S2 インシデントの場合、EOC は決定を下す前にオンコールインシデントマネージャーと連携する必要があります。変更を実行するかどうかを承認するかは彼らの裁量に委ねられています。承認された場合、オンコールインシデントマネージャーはこの決定をインフラストラクチャリーダーシップエスカレーションに通知する必要があります（必要に応じて経営陣に通知）。

例外の申請

PCL 中に何かデプロイする必要がある場合:

  1. 本番 Issue トラッカーに、この変更が免除されるべき理由の明確な正当性を含む Issue を作成する
  2. この Issue であなたの作業とプロジェクトを参照し、新しい Issue を関連する PCL Issue にリンクする。推定される nARR への影響を含める
  3. 新しい Issue に VP Infrastructure Platforms（またはその代理人）の承認がコメントに文書化されていることを確認する
  4. EOC とリリースマネージャーと調整してこの変更を出荷する

PCL の宣言

本番変更ロック（PCL）は、計画的（休日などの定期的なイベント向け）または緊急（即時アクションが必要な予期しない状況向け）のいずれかです。感謝祭や年末年始の休暇などの定期的な PCL については、標準的な日程を文書化した直近の PCL テーブルを参照してください。

役割と責任

チーム役割責任
Production Engineering担当 & 説明責任変更ロック Issue とエントリを作成し、変更ロックへの準拠を確保する
Software Delivery相談 & 説明責任リリース活動に基づく日程と実現可能性についてインプットを提供し、準拠を確保し自動デプロイプロセスで強制する
Engineering情報共有開発と計画のために変更ロックを把握する
Product情報共有計画目的で変更ロックを把握する
Security情報共有セキュリティ目的で変更ロックを把握する

計画的 PCL の宣言

定期的な PCL（感謝祭や年末年始の休暇など）の場合は、以下の手順に従ってください:

  1. 追跡 Issue とエントリを作成する（Production Engineering）

    • デプロイとフィーチャーフラグをブロックする C1 変更 Issue を作成する
    • gl-infra/change-lock に対応するエントリを作成する
    • 必要に応じて、このハンドブックページの直近の PCL テーブルに特定の日付を追加する（定期的なエントリはすでに文書化されている）
    • PCL 期間の開始時に Issue を ~change::in-progress としてマークする

  2. レビューと承認を得る（Software Delivery）

    • change-lock マージリクエストのレビュアーとして Software Delivery エンジニアリングマネージャー（EM）を追加する
    • Software Delivery EM が変更をレビューし承認する

  3. ステークホルダーに周知する（Software Delivery）

    • #engineering-fyi Slack チャンネルを通じてエンジニアリング組織に通知する
    • Engineering Week In Review にエントリを追加する
    • ChatOps Notify を使用して関連する Slack チャンネルに PCL を周知する
    • デプロイとリリースプロセスに必要な変更の詳細を提供する

  4. PCL 終了後のクリーンアップ（Production Engineering）

    • C1 変更 Issue をクローズする
    • 直近の PCL テーブルから特定の日付エントリを削除する（定期的なエントリは残す）

緊急 PCL の宣言

計画外の PCL（重大なインシデントや予期しないイベント中など）の場合:

  1. 状況を評価する

    • #releases Slack チャンネルの @release-managers に確認し、月次リリースまたはパッチリリースの状況を確認する
    • #security Slack チャンネルでセキュリティに確認し、リリースマネージャーにまだ通知されていない緊急のセキュリティパッチがあるかどうか確認する
    • #production Slack の @incident-managers と @sre-oncall に確認し、懸念事項があるかどうかを確認する
    • インフラストラクチャリーダーシップエスカレーションに報告する

  2. 迅速な承認で計画的 PCL プロセスに従う

    • 必要性が確認されたら、上記の計画的 PCL プロセスの手順 1〜3 に従う
    • 緊急性に鑑みて、承認とコミュニケーションを迅速化する
    • C1 変更 Issue に緊急 PCL の理由を明確に文書化する

直近の PCL

以下の日程は現在スケジュールされている PCL です。下記の日程の時刻は、特段の指定がない限り、09:00 UTC に開始し翌日の 09:00 UTC に終了します。

日程種別理由
定期: 月次リリース日ソフトリリース日
定期: 予定されたファミリー・アンド・フレンズデーソフトファミリー・アンド・フレンズデー
定期: 毎週土曜 01:00 UTC → 日曜 21:00 UTCソフト週末
定期: 米国感謝祭週（水曜 22:00 UTC から月曜 02:00 UTC）ハード感謝祭、ブラックフライデー、サイバーマンデー
定期: 年末年始休暇（12月20日 23:00 UTC から1月5日 09:00 UTC）ハード年末休暇（チーム稼働率低下）

フィーチャーフラグと変更管理プロセス

フィーチャーフラグは、アプリケーションの変更を本番環境で容易にテストできるようにすることでリスクを低減します。段階的または選択的に有効化でき、素早くオフにできるため、適切な場合はその使用を奨励しています。

ただし、フィーチャーフラグを使用する開発者の数と会社の規模が拡大するにつれて、これらの変更に関連するリスクも管理することが重要になります。開発者はフィーチャーフラグの開発者ドキュメントで定義されたプロセスに従います。

ある日には、数十ものフィーチャーフラグの変更が行われることがあります。これらの多くは、UI の外観変更だけのような低リスクの変更のテストを許可する些細なものです。しかし、一部のフィーチャーフラグの変更は GitLab.com の運用に大きな影響を与え、サービスレベル合意に悪影響を及ぼす可能性があります。これは会社の評判と財務的健全性に悪影響を与える可能性があります。機能をトグルするアプリケーション開発者とオンコールエンジニア（EOC）の間に明確なコミュニケーションがなければ、EOC がどのフィーチャーフラグトグルが高リスクでどれがそうでないかを評価することが困難になる可能性があります。

さらに、インシデント調査中に、どの高リスク機能が最近有効化されたか、その動作をどのように評価するかのドキュメントを知ることが重要です。

このため、以下のいずれかの基準を満たすフィーチャーフラグのトグルは、変更管理 Issue を伴う必要があります:

  • 新しいサービスを有効化する機能: たとえば、フィーチャーフラグトグルが新しくプロビジョニングされたデータベースまたは新しいアプリケーションサービスへのトラフィックを誘導する場合。
  • GitLab.com のサービスレベル可用性に影響を与える可能性のある機能: 合理的な状況下でインシデントにつながる可能性のある機能。
  • フィーチャーフラグ（または関連する機能）が、以前にユーザー影響のあるサービス劣化によりロールバックされた場合、または以前のトグルが本番インシデントにつながった場合。
  • アプリケーション開発チームが変更のリスクが変更管理のオーバーヘッドを正当化すると評価した場合、またはインフラストラクチャチームが特定のリクエストを行った場合。

質問

  • 上記の 本番にはカナリアが含まれますか？

    はい。

  • これは本番環境にのみ適用されますか？

    はい。本番環境のみです。つまり、本番以外の環境への変更とデプロイは引き続き行えます。

  • PCL で適用される変更の正確なスコープは何ですか？（インフラストラクチャ、ソフトウェア、ハンドブック…等）

    GitLab.com SaaS 製品に関連するすべての本番変更。たとえば、設定変更、新しいライブラリのセットアップ、新しいコードの導入、フィーチャーフラグの切り替え。

  • PCL 期間中に変更を行いたい場合はどうすればよいですか？

    プロダクトグループの開発コードの変更は開発 VP の承認が必要です。 その他のすべての変更（すべての基盤となるクラウドおよびインフラストラクチャの変更を含む）は、インフラストラクチャ & 品質 VP の承認が必要です。

  • これは月次リリースにも適用されますか？

    いいえ。月次リリースが PCL 期間中に行われる場合は、中断のない月次リリースを確保するために追加の調整が必要です。

  • ここで回答されていない質問があります。

    インフラストラクチャチームのキューに Issue を起票してください。できるだけ早くご返答します。

例外

このプロセスの例外は追跡され、インフラストラクチャによって承認される必要があります。

参考資料

プラットフォームリーダーシップレビューガイドライン
目的 このページでは、C1 および C2 変更リクエストを承認する際のプラットフォームリーダーシップレビュアー向けのガイドラインを提供します。目標は、レビューの一貫性を確保し、高重要度変更の品質を向上 …
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License