GitLab SaaS の緊急変更プロセス
GitLab SaaS 環境の管理を担当する Infrastructure 部門には、通常のワークフローの一部として暗黙的な緊急プロセスコンポーネントを持つ複数のプロセスがあります。このページは、それらのプロセスの最も重要なコンポーネントの概要を提供し、各プロセスをより詳細に説明するページへのリンクを含んでいます。
ワークフロー
GitLab SaaS 上で不規則な状況が発生した際の不可欠な部分は、インシデント管理プロセスです。 このプロセスはプラットフォームの劣化や障害イベントに使用されますが、重大な脆弱性への対応などの緊急変更のためのプロセスでもあります。
インシデントが宣言されると、オンコール担当者はインシデント管理プロセスに従い、緊急変更への対応時には追加のアクションセットが必要になることがあります。
オンコール担当者は一般的に、緊急コードパッチの適用、デプロイの要求、または高い重大度の [変更管理プロセス] に従うことができます。
変更管理
緊急事態において設定や環境の変更が必要な場合、オンコール担当者は 変更管理プロセス に従います。基礎インフラに加えられる設定変更はすべて、設定変更がソース管理にチェックインされる通常のマージリクエスト（MR）ワークフローを経ます。
このような状況では時間が重要な要素となるため、オンコール担当者が緊急コール中の他のメンバーとの議論の上で変更を自己承認することが可能です。この場合、変更 Issue は緊急対応が完了した後にログ記録され、対象の MR が参照されます。その MR は、対応中にレビュー・承認が行われなかった場合、事後に別のチームメンバーによってレビューおよび承認されます。
デプロイ後パッチ（ホットパッチ）
アプリケーションのコード変更が緊急のホットパッチを必要とする場合、オンコール担当者は [デプロイ後パッチ] プロセスを活用します。
このプロセスはアプリケーションの問題を迅速に軽減するために使用され、コードパッチがソース管理リポジトリに保存されるマージリクエスト（MR）ワークフローも活用します。
オンコール担当者（SRE のオンコール担当またはリリースマネージャー）は、任意の部門のチームメンバーが提出した MR をレビューします。デプロイ後パッチは、オンコール担当者がレビューおよび承認し、MR がマージされると環境に変更がロールアウトされます。デプロイ後パッチの MR は常に未解決の本番インシデントにリンクされており、インシデント管理プロセスに紐付けられます。
デプロイ
アプリケーションのコード変更が緊急変更プロセスをトリガーし、前述の方法では問題を解決できない場合、オンコール担当者は開発者とリリースマネージャーと協力して標準的なレビュープロセスを早急に進める必要があります。
開発者は標準のレビュープロセスに従い、コードベースのメンテナーが MR をレビュー、承認、マージして問題を解決します。MR の作成者は auto-deploy プロセス に従う必要があり、デプロイの準備ができたら、リリースマネージャーがオンコール担当者と連携して GitLab SaaS へのデプロイを推進します。
緊急変更がセキュリティ脆弱性を修正するためのものである場合は、セキュリティリリースプロセス に従います。
