変更管理

目的

変更管理は従来、IT環境において運用環境の変更を慎重に管理するために適用されるプロセス、手順、ツール、技術を指してきました。これには、変更チケットと計画、承認、変更レビューミーティング、スケジュール設定、その他の煩雑な手続きが含まれます。

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

私たちの最優先目標は、従来の変更管理の側面を回避する変更を最大化することであり、これは時間とともに進化するイテレーティブなプロセスです。成功はビジネスニーズが要求するスピードで変更を安全に実行する能力で測定されます。

スコープ

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

インシデントの解決中に実行する必要がある変更は、インシデント管理に該当します。

役割と責任

私の変更は変更リクエストが必要か？

あなたの変更は:

• 何らかのリスクを伴うか？

  この質問に答えるために: この変更は以前に試みられたか？非本番環境でこの変更はどれだけ広範にテストされたか？これが本番環境で問題を引き起こさないという証拠にどれだけ自信があるか？

• デプロイメントおよび/またはフィーチャーフラグの一時停止が必要か？
• 手動ステップが必要か？
• 複数の部門に影響し、可視性を高める必要があるか？

上記の質問のいずれかに YES（または「たぶん」）と答えた場合、変更リクエストワークフローに従うべきです。このワークフローの目的は、可視性を高めることで、悪影響を持つ変更が本番環境に到達する可能性を減らすことです。また、この性質の変更が本番環境に到達した場合に、レビュー済みのロールバック計画を実行する準備ができていれば、できるだけ迅速に良好な状態に戻すことができます。

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

• Cloudflareでサイト全体のレート制限を実装。
• 本番環境のCSP変更。
• ステージングのテーブルからインデックスを削除

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

変更リクエストが不要な変更タイプの非網羅的なリスト:

• 自動的にデプロイされ、ロールバックがマージリクエストのリバートであるマージリクエストのマージ。
• 低リスクと見なされるマージリクエスト。
• 環境にクリティカルでないマイナーな依存関係更新。
• 設定経由で行われ、リスクが高いとは見なされない機能トグル。

例:

• アラートのサービス依存関係を追加
• 小さなクックブックの更新
  • 判断を使ってください: クックブックのバージョン更新が変更管理ワークフローに従うべきかどうかは、クックブックに加えられた変更によります。

不明な場合

• #infrastructure_platforms または #s_production_engineering で意見を求める
• 変更管理 Issue を開き、慎重を期す。

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

計画 Issue は、変更管理 Issue テンプレート経由で本番プロジェクトトラッカーで開かれます。各 Issue は、対応する重要度レベルの Issue テンプレートを使用して開かれる必要があります: C1、C2、C3、または C4。提案された変更の詳細な説明を提供し、テンプレートのすべての関連情報を含む必要があります。各計画 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. Infra as code (IaC)への重要なアーキテクチャ変更。
3. ペットへの重要なIaC変更 - Postgres、Redis、その他の単一障害点。
4. 主要なベンダーまたはサービスプロバイダーの変更（例: CDN、トランザクションメールプロバイダー、DNSなど）。
5. ツールの主要バージョンアップグレード（主要の定義はwww.semver.orgに従う）（例: HAProxy、AlertManager、Chefなど）。
6. 私たち自身で生成したカスタムビルドの作成とデプロイは一般的に推奨されません。公式アップストリームリリースの一部になる前に適用するセキュリティまたは安定性パッチのために必要となるユースケースがあります。それは重要度1ガイドラインを通じてのみ許可されます。
7. アラート基盤への主要なアーキテクチャまたはツーリング変更。
8. 証明書発行機関の変更/新しいSSL証明書のアップロードを含むあらゆる手順。

承認

1. Issue に期日が設定されていること、およびGitLab Productionカレンダーに登録されていることを確認してください。
   1. 計画可能なC1（プロアクティブメンテナンス、スケジュールされたアップグレード、計画されたインフラ変更などを含むがこれらに限定されない）には、適切なステークホルダー通知を確保するため最低2週間のリードタイムが必要です。
2. ダウンタイムを含む変更は、ユーザーに事前に通知する必要があります。ダウンタイムを必要とする変更の通知のガイダンスに従ってください
3. データベース変更には、変更の種類に応じて適切な専門家からのレビューが必要です:
   • データベースサービス変更（インフラ、設定、レプリケーション、バックアップ戦略など）には、DBREによるレビューと承認が必要です。@gitlab-org/database-team/reliabilityにメンションしてください
   • データベースモデル変更（マイグレーション、スキーマ変更、データモデル変更など）はアプリケーションレイヤーの変更であり、モノリスリポジトリにコミットされ、データベースメンテナーによって承認される必要があります。元のマージリクエストの承認者または別のデータベースメンテナーがCR内でのそのコードの使用をレビューする必要があります。
4. 変更リクエスト Issue でplatform_leadership_approvedラベルを取得して、Infrastructure Platformリーダーシップ（Infrastructure Platformsの EM+またはStaff+ IC）による変更の承認を得てください。承認をリクエストするには@gitlab-org/saas-platforms/change-review-leadershipにメンションします。レビュアーは変更作成者とは異なるチームから選ばれる必要があります。承認前にPlatform Leadershipレビューガイドラインを確認してください。
5. 変更の時間にスケジュールされたEngineer On-Call (EOC)を特定し、スケジュールされ次第、変更計画について担当者に知らせてください。 （ソースはincident.ioです。アクセス権がない場合は支援を得るを試してください）
6. Slack で@release-managersを、Issue で@gitlab-org/release/managersをメンションして、変更で必要に応じてデプロイメントまたはマイグレーションを一時停止できることを確認します。
7. #production Slack チャンネルで計画実行の開始を発表し、@sre-oncallエイリアスを使用して EOC に直接通知し、変更のタイミングに影響を与える可能性のある進行中のインシデントがないことを確認します。確認されたら、EOC はeoc_approvedラベルを適用し、変更を進めることができます。
8. EOC と「Situation Room」zoomチャンネルに参加し、計画実行の開始について口頭での承認を得ます。

変更の実行全体を通して EOC を関与させる必要があります。

重要度2

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

これらは本番環境でダウンタイムを引き起こすとは予想されない変更ですが、予期しないことが発生した場合に影響のリスクをまだ持ちます。例えば、Cattleフリートのサイズを縮小することは、オーバープロビジョニングを特定したため通常は問題ありませんが、前後で慎重にモニタリングする必要があります。

重要度2の例:

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

承認

1. Issue に期日があり、GitLab Productionカレンダーにイベントがあることを確認してください。
2. ダウンタイムを含む変更は、ユーザーに事前に通知する必要があります。ダウンタイムを必要とする変更の通知のガイダンスに従ってください
3. データベース変更には、変更の種類に応じて適切な専門家からのレビューが必要です:
   • データベースサービス変更（インフラ、設定、レプリケーション、バックアップ戦略など）には、DBREによるレビューと承認が必要です。@gitlab-org/database-team/reliabilityにメンションしてください
   • データベースモデル変更（マイグレーション、スキーマ変更、データモデル変更など）はアプリケーションレイヤーの変更であり、モノリスリポジトリにコミットされ、データベースメンテナーによって承認される必要があります。元のマージリクエストの承認者または別のデータベースメンテナーがCR内でのそのコードの使用をレビューする必要があります。
4. 変更リクエスト Issue でplatform_leadership_approvedラベルを取得して、Platform Leadership（Staff+ SRE、Principal Engineer、またはSenior Staff Engineer）による変更の承認を得てください。承認をリクエストするには@gitlab-org/saas-platforms/change-review-leadershipにメンションします。レビュアーは変更作成者とは異なるチームから選ばれる必要があります。承認前にPlatform Leadershipレビューガイドラインを確認してください。
5. 変更の時間にスケジュールされたEngineer On-Call (EOC)を特定し、当該 EOC と一緒に計画をレビューします。 （ソースはincident.ioです。アクセス権がない場合は支援を得るを試してください）
6. #production Slack チャンネルで計画実行の開始を発表し、@sre-oncallエイリアスを使用して EOC に直接通知し、変更リクエスト 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. 提案された時間または期間中にEngineer on CallまたはRelease Managerのシフト変更がありますか？

変更の実行

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

bastionホストではsudoが無効になっているため、スクリプトが必要とする場合は、覗き見されることを恐れずにChef PEM ファイルをそれらの1つにコピーできます。

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

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変更リクエストに対しては、複数のレビュアーの使用を検討してください。

レビューを依頼すべき相手がわからない場合は、Reviewer Rouletteを使用して、Production チームの対応可能なレビュアーを見つけてください。

Issue に割り当てられた変更重要度ラベルに基づいて、Change Reviewer checklistの各項目に記入します。

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

情報はあらゆる変更の間の重要な資産です。意図された宛先に情報の流れを適切に管理することは、利害関係者にタイムリーに進展を知らせる上で重要です。変更が起こっているという認識は、利害関係者がそうした変更を計画するのに役立つ上で重要です。

このフローは以下によって決定されます:

• 情報の種類、
• 意図された対象者、
• そして時間的感度。

例えば、大規模なエンドユーザーは、リリースに問題が影響する可能性を避けるために、メンテナンスウィンドウ中にソフトウェアリリースを行うことを避ける選択をするかもしれません。

さらに、情報過多を避けることは、各利害関係者の集中力を保つために必要です。

通信を改善するために、以下は高重要度の変更に対する推奨事項です:

• 変更中はインシデントzoomチャンネルを使用します
• 場所にいるさまざまな対象者向けの定期的な更新（CMOC がこれを処理します）:
  • エンドユーザー (Twitter)
  • eStaff
  • サポートスタッフ
  • 社員全般
• メンテナンスが完了した後、次のオンコールチームメンバーへの引き継ぎノートを残します。次のような項目を含めます:
  • メンテナンスの状態/成功
  • サイレンス化された可能性があり、引き継ぎになる可能性のあるアラート
  • 注意領域を監視する特定のグラフへのリンク

ダウンタイムを必要とする変更の通知（「メンテナンスウィンドウ」）

時々、顧客とSLOに影響を与えるダウンタイムを必要とする本番変更を実行する必要があります。このセクションでは、これらのタイプの状況で通信を成功裏に管理する方法について説明します。

参考として、重要なアーキテクチャ変更を伴わないC1の場合、変更の5〜6週間前に通信するべきです。変更が大規模なマイグレーションまたは重要なアーキテクチャ変更を含む場合は、より長い準備時間が推奨されます。

ステップ:

• 変更 Issue に外部とのコミュニケーションのドラフト文言を含めるステップを追加します。
• 変更 Issue に~Scheduled Maintenanceラベルを追加するか、機密 Issue が必要な場合は、テンプレートexternal_communicationを使用して新しい Issue を作成します。
• 以下から全体的な計画と予想される影響についての承認を取得します:
  • Director of SRE, Infrastructure
  • VP of Infrastructure & Quality
  • VP of Support
  • Release Managers
• 変更の少なくとも1ヶ月前（可能であれば）:
  • #customer-success Slack チャンネルで私たちの CSM にこの変更を主要顧客に通知する方法についての好みを尋ねます:
    • @cs-tam-mgrsエイリアスを使用して CSM マネージャーにpingし、トップ SaaS 顧客向けに CSM に通知するよう依頼します。
    • 担当者は、顧客のチャンネルで変更の詳細について通信することを提案する可能性があります。その場合、メッセージのドラフトを作成し、CSM とその内容について合意し、関連する顧客の Slack チャンネルでそれを共有します（CSM と同期して）。
  • 可視性とエンゲージメントのために@release-managers、@db-teamおよび@dbreをメンションしながら、#whats-happening-at-gitlab Slack チャンネルで情報と Issue へのリンクを共有します。
• その後すぐに、通信または変更 Issue はstatus.ioの単純な投稿にリンクされるべきです（「new maintenance」をクリック）。私たちは CMOC と連携して、可能なすべてのチャンネル（メール、ツイート、Slack など）を通じてstatus.ioでそのメンテナンスを共有する必要があります。そこから顧客は質問やコメントができるようになります。 [ダウンタイムを顧客に通信するための公式企業方法はstatus.io経由です]。
• この時点から、今度の変更が既に公開されているとき、私たちは以下を行う必要があります:
  • 顧客からの質問/コメントがあるかどうか、それらに適時に対処するために、定期的にコミュニケーション Issue をチェックします。
  • status.io経由で、変更時間の2週間前、1週間前、3日前、1日前に今度の変更について顧客に思い出させます。

Production Change Lock (PCL)

私たちが行う変更は厳密にテストされ慎重にデプロイされていますが、GitLab Summit、主要なグローバルホリデー、GitLab チームメンバーの可用性が大幅に減少する時期などの特定のイベント中に本番変更を一時的に停止することは良い習慣です。

私たちは、低いチームメンバーのカバレッジまたはプラットフォームの大幅な不安定さの期間以外の理由でハードPCLを作成しません。イベント中のプラットフォームの安定性について懸念がある場合は、ソフトPCLオプションを検討してください。

これらの期間中に本番環境変更を行うリスクには、インシデントが発生した場合の即時の顧客影響および/またはエンジニアリングチームの可用性の低下が含まれます。したがって、私たちは**Production Change Lock (PCL)**と呼ばれるメカニズムを導入しました。PCL期間中、自動デプロイは一時停止されます。EOC の裁量でデプロイメントを手動で実行できます。例えば、EOC は、GitLab.com の安定性を確保するために、またはPCLが解除されたときにデプロイメントがスムーズに実行され続けることを確保するために、変更をデプロイすることを選択する場合があります。

PCLには2つのタイプがあります: ソフトとハード。

PCL中に制限されるものは何ですか？

ソフトPCL

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

ブロックされるもの:

• 重要度レベルC2以上のインフラ変更
• ポストデプロイマイグレーション（EOC 承認付きの緊急時を除く）
• 変更管理 Issue を必要とするフィーチャーフラグトグル（変更管理プロセスに従う）

許可されるもの:

• 重要度レベルC3またはC4のインフラ変更
• canaryへのコードデプロイ（canary影響を制御するツールがあります）
• ポストデプロイマイグレーションなしの本番へのコードデプロイ（EOC 調整が必要）
• 変更管理 Issue を必要としないフィーチャーフラグトグル
• C1およびC2インフラの緊急変更（EOC およびIncident Manager On Callのインタラクションが必要）

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

ハードPCL

ハードPCLには、ソフトPCLからのすべての制限に加えて、重要度レベルに関係なくコードデプロイメントとすべてのインフラ変更に対する追加の制限が含まれます。

ブロックされるもの:

• すべてのコードデプロイメント（canaryおよび本番への）
• すべてのインフラ変更 (C1、C2、C3、C4)
• すべてのフィーチャーフラグトグル
• ポストデプロイマイグレーション

許可されるもの:

• アクティブなS1/S2インシデント対応に必要な変更（EOC およびIncident Manager On Callの両方からの承認が必要）

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

アクティブなS1/S2インシデントの場合、EOC は決定を下す前にIncident Manager On Callとインタラクションする必要があります。変更を実行すべきかどうかを承認するかは担当者の裁量です。承認された場合、Incident Manager On Callはこの決定をInfrastructure Leadership Escalationに通知する必要があります（必要に応じてエグゼクティブチームに通知します）。

例外の申請

PCL中にデプロイされる必要があるものがある場合:

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

PCLの宣言

Production Change Lock（PCL）は、（休日のような繰り返しのイベントのための）計画されたまたは（即時のアクションを必要とする予期しない状況のための）緊急のいずれかになります。Thanksgivingや年末の休日のような繰り返しのPCLについては、標準的な日付を文書化した最近のPCLテーブルを参照してください。

役割と責任

計画されたPCLの宣言

繰り返しのPCL（Thanksgivingまたは年末の休日など）については、以下のステップに従います:

1. 追跡 Issue とエントリを作成 (Production Engineering)

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

2. レビューと承認を取得 (Software Delivery)

   • Software Delivery Engineering Managers（EM）をchange-lockマージリクエストのレビュアーとして追加
   • Software Delivery EM が変更をレビューおよび承認

3. ステークホルダーへの通信 (Software Delivery)

   • #engineering-fyi Slack チャンネルを通じてEngineering Organizationに通知
   • Engineering Week In Reviewにエントリを追加
   • ChatOps Notifyを使用してPCLを関連する Slack チャンネルに通信
   • デプロイメントおよびリリースプロセスに必要な変更の詳細を提供

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

   • C1変更 Issue をクローズ
   • 最近のPCLテーブルから特定の日付付きエントリを削除（繰り返しエントリは保持）

緊急PCLの宣言

計画されていないPCL（重大なインシデントまたは予期しないイベント中など）の場合:

1. 状況を評価

   • #releases Slack チャンネルで@release-managersに確認して、月次リリースまたはパッチリリースの状態を確認
   • リリースマネージャーがまだ通知されていない差し迫ったセキュリティパッチがあるかどうか#security Slack チャンネルでセキュリティに確認
   • #production Slack チャンネルで@incident-managersと@sre-oncallに確認して懸念事項があるかどうかを確認
   • Infrastructure Leadership Escalationに通知

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

   • 必要性が確認されたら、上記の計画されたPCLプロセスのステップ1〜3に従う
   • 緊急の性質を考慮して承認と通信を迅速化する
   • C1変更 Issue に緊急PCLの理由を明確に文書化する

最近のPCL

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

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

フィーチャーフラグは、本番でアプリケーション変更を簡単にテストできるようにすることでリスクを低減します。徐々にまたは選択的に有効にでき、迅速にオフにできるため、適切な場合はいつでもその使用が奨励されます。

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

任意の日に、数十のフィーチャーフラグ変更が発生する可能性があります。これらの多くは些細なもので、低リスクの変更（時にはUIの外観への変更のみ）をテストできます。ただし、いくつかのフィーチャーフラグの変更は GitLab.com の動作に大きな影響を与え、私たちのサービスレベル契約にネガティブな影響を与える可能性があります。これは、会社の評判と財務的な健全性にネガティブな影響を及ぼす可能性があります。機能をトグルするアプリケーション開発者とengineer-on-call (EOC)間の明確なコミュニケーションがないと、EOC がどのフィーチャーフラグトグルが高リスクで、どれがそうでないかを評価することが難しくなる可能性があります。

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

この理由により、以下の基準のいずれかを満たすフィーチャーフラグトグルには、変更管理 Issue が伴うべきです。:

• 新サービスを有効にする機能: 例えば、機能トグルが新しくプロビジョニングされたデータベースまたは新しいアプリケーションサービスを通じてトラフィックを駆動する場合。
• GitLab.com のサービスレベル可用性に影響を与える可能性がある機能: 合理的な状況下でインシデントにつながる可能性のあるあらゆる機能。
• 機能トグル、または関連する機能が、ユーザーに影響を与えるサービス劣化のために以前にロールバックする必要があった場合、または以前のトグルが本番インシデントにつながった結果として。
• アプリケーション開発チームが変更のリスクが変更管理のオーバーヘッドを正当化すると評価する場合、またはインフラチームが特にそれを要求する場合。

質問

• 上記の本番にはcanaryが含まれていますか？

  はい。

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

  はい。本番環境のみです。これは、本番以外の環境で変更とデプロイメントをまだ行えることを意味します。

• PCLの下で強制される変更の正確な範囲は何ですか？（インフラ、ソフトウェア、ハンドブックなど）

  gitlab.com SaaS Productに対するおよび/またはそれをサポートするあらゆる本番変更。例えば、設定変更、新しいライブラリのセットアップ、新しいコードの導入、フィーチャーフラグのトグル。

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

  Product Group Developmentコード変更には、Development VPの承認が必要です その他すべての変更、すべての基盤となるクラウドおよびインフラ変更を含む、Infrastructure & Quality VPの承認が必要です。

• これは私たちの月次リリースに適用されますか？

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

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

  Infrastructureチームのキューに Issue を提起してください。できるだけ早く回答いたします。

例外

このプロセスへの例外は、Infrastructureによって追跡および承認される必要があります。

参考文献

• 変更管理ポリシー

ページのソースコードを見る - ページの編集 - please contribute.