engineering-emergency-changes

エンジニアリングにおける緊急変更

緊急レビューは、通常のレビューの深さよりも変更全体のスピードが重要となる、まれなケースを対象とします。「エンジニアリング上の判断を省略する」という意味ではありません。変更範囲を絞り、緊急性を確認し、正確性を優先したうえで、フォローアップレビューを予定するという意味です。

Google Engineering Practices Documentation、特に「Emergencies」とレビュー担当者が迅速に対応するためのガイダンスを参考にしています。出典：https://google.github.io/eng-practices/review/emergencies.html。ライセンス：CC-BY 3.0。

緊急変更の判定基準

変更が小規模で対象を絞ったものであり、次の条件のうち少なくとも1つに当てはまる場合に限り、緊急変更として扱います。

• ロールバックが適切な選択肢ではない状況で、大規模なローンチの失敗を防ぎます。
• 本番環境のユーザーに大きな影響を与えているバグを修正します。
• 差し迫った法的問題またはコンプライアンス上の問題に対処します。
• 重大なセキュリティ脆弱性を解消します。
• 厳格な外部期限を守ります。期限を逃すことで、契約上、法的、セキュリティ上、本番環境のユーザーに関する問題、またはローンチに明らかな甚大な悪影響が生じる場合です。

通常、以下の理由だけでは緊急変更に該当しません。

• もっと早くローンチしたい。
• 機能の開発に時間がかかっており、作成者がマージを望んでいる。
• レビュアーが就寝中、休暇中、または別のタイムゾーンにいる。
• 金曜日の遅い時間である。
• マネージャーが、柔軟な期限に間に合わせるため今日中の対応を望んでいる。
• チームが通常のレビューで生じる負担を避けたい。

期限の多くは柔軟なものです。柔軟な期限のために、コードの健全性を犠牲にしないでください。

緊急時のワークフロー

1. 緊急とする理由を1文で述べます。
2. 緊急変更の判定基準を満たすか判断します。
3. 変更を必要最小限の修正に絞ります。
4. その変更が緊急の問題に直接対処していることを確認します。
5. 正確性、影響範囲、ロールバック、明らかな安全上の問題を優先してレビューします。
6. 現時点で実施できる、最も迅速で有意義な検証を実行します。
7. 省略した通常のチェックと、その理由を記録します。
8. 緊急事態のリスクがコードのリスクを上回る場合に限り、マージまたはリリースします。
9. 緊急事態の解決後、通常の深さでフォローアップレビューを実施します。
10. クリーンアップ、テスト、ドキュメント、事後検証のタスクをすぐに登録し、抜け落ちないようにします。

緊急レビューのチェックリスト

• 範囲：緊急の問題を解決するための最小限の変更ですか？
• 正確性：本番環境、セキュリティ、法務、またはローンチの問題を実際に解決しますか？
• 封じ込め：すぐにロールバックまたは無効化できますか？
• テスト：今すぐ実施できる自動または手動のチェックのうち、最も確信を得られるものは何ですか？
• 可観測性：修正が機能したかどうかをチームはどのように把握しますか？
• 副作用：どのユーザー、データ、ジョブ、API、またはデプロイに悪影響が及ぶ可能性がありますか？
• フォローアップ：通常のレビュー項目、テスト、ドキュメント、クリーンアップのうち、後で実施すべきものは何ですか？

出力テンプレート

## Emergency Decision
QUALIFIES | DOES_NOT_QUALIFY | NEEDS_MORE_INFO

## Reason
[Concrete reason tied to production user impact, security, legal/compliance, major launch, or hard external deadline.]

## Minimum Safe Change
- ...

## Immediate Verification
- ...

## Release / Rollback Notes
- ...

## Follow-up Required
- Normal-depth review:
- Tests:
- Cleanup:
- Documentation:
- Owner:

よくある間違い

• 緊急性を緊急事態として扱う。
• ホットフィックスの範囲を広げ、周辺のクリーンアップまで含める。
• レビューの焦点を変えるのではなく、レビューをすべて省略する。
• 事態の解決後に通常のレビューを行うのを忘れる。
• 緊急時の例外を、チームの通常のリリースプロセスにしてしまう。