emergency-release-workflow

緊急リリースワークフロースキル

概要

即時デプロイが必要な重大な本番環境の問題に対応するための迅速なワークフローです。緊急度の評価、迅速な PR プロセス、デプロイの検証、インシデント後の分析を扱います。

使用するタイミング

• ユーザーに影響する重大な本番環境のバグ
• セキュリティ脆弱性（CVE）
• 緊急のビジネス要件
• データ整合性の問題
• サービス停止
• 決済処理の障害

緊急度の評価

優先度レベル

レベル	種類	対応時間	デプロイ	例
P0	セキュリティ脆弱性	< 2 hours	本番環境へ即時	認証のバイパス、データ漏えい、実際に悪用されている脆弱性
P1	本番環境の停止	< 4 hours	当日中	アプリのクラッシュ、機能の完全な停止、決済の停止
P2	重大なバグ	< 24 hours	翌営業日	重要な機能の不具合、ユーザーへの大きな影響
P3	ビジネス上の重大事項	< 48 hours	計画済みのリリース	マーケティングキャンペーンの阻害要因、パートナーとの期限

P0 の基準（即時対応）

• 認証／認可のバイパス
• データ侵害またはデータ漏えい
• リモートコード実行の脆弱性
• 本番サービスが完全に利用不能
• 複数のユーザーに影響するデータ破損
• 決済処理が完全に機能しない

P1 の基準（当日中）

• 重要な機能が完全に動作しない
• 大多数のユーザーに影響するエラー
• 収益に影響するバグ
• データベース接続の問題
• サードパーティ連携の障害（重要なサービス）

P2 の基準（翌営業日）

• 主要機能の一部が動作しない
• 特定のユーザー層に影響する
• 回避策はあるが、理想的ではない
• パフォーマンスの低下（完全な障害ではない）

---

緊急リリースのプロセス

1. ホットフィックスブランチを作成

# Branch from current production (main)
git checkout main
git pull origin main

# Create hotfix branch
git checkout -b hotfix/ENG-XXX-brief-description

# Example:
git checkout -b hotfix/ENG-1234-fix-auth-bypass

2. 最小限の修正を実装

⚠️ CRITICAL: Minimal change only

DO:
✅ Fix the immediate issue
✅ Add regression test
✅ Document root cause in comments

DON'T:
❌ Refactor surrounding code
❌ Fix unrelated issues
❌ Add new features
❌ Update dependencies (unless that's the fix)

3. 十分にテスト

# Run full test suite
pnpm test

# Type check
pnpm tsc --noEmit

# Build verification
pnpm build

# Manual testing checklist:
# - [ ] Reproduce original issue
# - [ ] Verify fix resolves issue
# - [ ] Test happy path
# - [ ] Test edge cases
# - [ ] Verify no new issues introduced

4. ラベルを付けて PR を作成

git add .
git commit -m "fix: [brief description of fix]

Fixes critical issue where [description].
Root cause: [explanation].

Ticket: ENG-XXX
Priority: P0"

git push origin hotfix/ENG-XXX-brief-description

PR のタイトルには明確なラベルを使用してください：

• [RELEASE] - 本番環境へ直接リリース
• [HOTFIX] - 重大な修正、迅速なレビュー
• [P0] または [P1] - 優先度の表示

---

ホットフィックス用 PR テンプレート

ホットフィックス PR テンプレート

## 🚨 [RELEASE] ENG-XXX: Brief description of fix

### Urgency
- [x] P0 - Security vulnerability
- [ ] P1 - Production down
- [ ] P2 - Major bug
- [ ] P3 - Business critical

### Impact
**Users affected**: [All users / Premium tier / Specific region / etc.]

**Severity**: [Choose one]
- [ ] Service completely unavailable
- [ ] Critical feature broken
- [ ] Security vulnerability
- [ ] Data integrity issue
- [ ] Degraded performance

**User impact**:
Describe how this affects end users.

### Root Cause
[Brief explanation of what caused the issue]

**How it happened:**
1. [Step 1]
2. [Step 2]
3. [Result: issue manifested]

**Why it wasn't caught:**
- [ ] Missing test coverage
- [ ] Race condition in production
- [ ] External service behavior changed
- [ ] Recent deployment introduced regression
- [ ] Other: [explain]

### The Fix
[What this PR changes to resolve the issue]

**Changes made:**
- Modified `file.ts` to [specific change]
- Added validation for [specific case]
- Fixed logic in [specific function]

**Why this fixes it:**
[Explanation of how the change resolves the root cause]

### Testing
- [ ] ✅ Reproduced issue locally
- [ ] ✅ Verified fix resolves issue
- [ ] ✅ Regression test added
- [ ] ✅ No other functionality affected
- [ ] ✅ Tested edge cases
- [ ] ✅ Deployed to staging and verified

### Regression Test
```typescript
// Test added to prevent recurrence
describe('ENG-XXX: Auth bypass fix', () => {
  it('should reject expired tokens', async () => {
    const expiredToken = generateExpiredToken();
    const response = await fetch('/api/protected', {
      headers: { Authorization: `Bearer ${expiredToken}` }
    });
    expect(response.status).toBe(401);
  });
});

ロールバック計画

問題が発生した場合：

# Option 1: Revert commit
git revert <commit-hash>
git push origin main

# Option 2: Deploy previous version
vercel rollback  # or your platform's rollback command

# Option 3: Feature flag
Set FEATURE_FIX_XXX=false in environment

監視項目：

• Sentry のエラー率
• 監視ダッシュボードの API 応答時間
• サポートチャネルのユーザー報告

デプロイチェックリスト

• 少なくとも 1 人のレビュアーが PR を承認済み（必要に応じて P0 は免除）
• すべての CI チェックに合格
• ステージング環境にデプロイし、検証済み
• 監視アラートを設定済み
• オンコールエンジニアに通知済み
• 本番環境へのデプロイ準備完了

デプロイ後の検証

デプロイ直後に実施：

• 本番環境で修正を確認（エンドポイントを直接テスト）
• エラートラッキングを確認（Sentry など）
• 新たなエラーがないか監視
• ユーザーからの報告が止まったことを確認

監視するメトリクス：

• エラー率（低下するはずです）
• API レイテンシ（安定を維持するはずです）
• ユーザーアクティビティ（正常に戻るはずです）

フォローアップ

• Linear のチケットに解決内容を記録
• インシデント後のレビューを予定（P0／P1 の場合）
• 適切な修正のチケットを作成（応急処置の場合）
• ランブック／ドキュメントを更新

---

## Deployment Steps

### Pre-Deployment
```bash
# 1. Merge PR to main
# (After approval or P0 emergency waiver)

# 2. Pull latest
git checkout main
git pull origin main

# 3. Verify commit
git log -1
# Confirm this is your hotfix commit

# 4. Tag release (if using semantic versioning)
git tag -a v2.3.5 -m "Hotfix: Fix auth bypass vulnerability"
git push origin v2.3.5

デプロイ（プラットフォーム別）

Vercel

# Trigger production deployment
vercel --prod

# Or use Vercel dashboard:
# Deployments → Select commit → Deploy to Production

# Monitor deployment
vercel logs --follow

Netlify

# Deploy via CLI
netlify deploy --prod

# Or trigger from dashboard:
# Deploys → Select commit → Publish deploy

Railway

# Push to main triggers deployment automatically
# Monitor in dashboard: railway.app/project/logs

AWS/GCP/Azure

# Follow platform-specific deployment process
# Example for AWS Elastic Beanstalk:
eb deploy production --staged

# Monitor:
eb logs --follow

デプロイ後の検証

1. スモークテスト

# Test the specific fix
curl -X POST https://api.production.com/auth/login \
  -H "Content-Type: application/json" \
  -d '{"token": "expired_token"}'

# Expected: 401 Unauthorized

2. エラートラッキングを監視

✅ Check Sentry/Rollbar/etc.:
- Error rate should drop
- No new errors introduced

⏱️ Monitor for 15-30 minutes after deployment

3. メトリクスを確認

Check monitoring dashboard:
- API response times (should be normal)
- Error rates (should drop)
- Database performance (should be stable)
- Third-party service health

4. ユーザーからの報告を確認

Monitor support channels:
- Support tickets
- In-app chat
- Social media
- Status page comments

---

コミュニケーション

社内コミュニケーション

Slack/Teams メッセージテンプレート

🚨 **Production Hotfix Deployed**

**Issue**: [Brief description]
**Ticket**: ENG-XXX
**Priority**: P0
**Status**: ✅ Resolved

**Timeline:**
- Issue discovered: 14:23 UTC
- Fix deployed: 15:47 UTC
- Duration: 1h 24m

**Impact**:
[Who was affected and how]

**Root Cause**:
[Brief explanation]

**Fix**:
[What was changed]

**Verification**:
✅ Error rate dropped from 450/min to 0/min
✅ All systems operating normally

**PR**: https://github.com/org/repo/pull/XXX

**Follow-up**:
- [ ] Post-incident review scheduled for [date]
- [ ] Documentation updated

社外向けコミュニケーション（必要な場合）

ステータスページの更新

🟢 Resolved - [Issue Title]

We've resolved an issue that was affecting [feature/service].

**What happened:**
Between 14:23 and 15:47 UTC, users experienced [specific issue].

**Current status:**
The issue has been fully resolved. All systems are operating normally.

**Next steps:**
We're conducting a thorough review to prevent similar issues in the future.

We apologize for any inconvenience.

影響を受けたユーザーへのメール（重大な問題の場合）

Subject: Update on [Service] Issue - Resolved

Hi [User],

We're writing to update you on an issue that affected [feature/service] earlier today.

**What happened:**
Between [time] and [time], you may have experienced [specific issue].

**Resolution:**
Our team quickly identified and resolved the root cause. The service is now operating normally.

**What we're doing:**
We take these issues seriously and are:
- Conducting a full review of the incident
- Implementing additional safeguards
- Improving our monitoring

We apologize for any inconvenience this may have caused.

If you have any questions or concerns, please reach out to [email protected].

Thank you for your patience.

The [Company] Team

---

インシデント後

直ちに行う対応（24 時間以内）

• Linear のチケットに解決内容の詳細を記録
• インシデントログ／スプレッドシートにインシデントを追加
• イベントの時系列を記録
• より早くアラートを出すべきだったメトリクスを特定
• 適切な修正のフォローアップチケットを作成（ホットフィックスが一時的な対応だった場合）

インシデント事後レビュー（PIR）- P0/P1 向け

72 時間以内に実施

PIR テンプレート

# Post-Incident Review: [ENG-XXX]
Date: YYYY-MM-DD
Severity: P0/P1
Duration: Xh Xm

## Summary
Brief description of the incident.

## Timeline (UTC)
- 14:23 - Issue first detected
- 14:25 - On-call engineer alerted
- 14:30 - Root cause identified
- 14:45 - Fix PR opened
- 15:20 - PR approved and merged
- 15:47 - Fix deployed to production
- 16:00 - Verified resolved

## Impact
- **Users affected**: ~5,000 users
- **Duration**: 1h 24m
- **User experience**: Unable to log in
- **Revenue impact**: Estimated $X in lost transactions
- **Reputation impact**: 23 support tickets, 5 social media mentions

## Root Cause
Detailed technical explanation of what caused the issue.

[Include code snippets, sequence diagrams if helpful]

## Resolution
What was changed to fix the issue.

## What Went Well
- ✅ Fast detection (2 minutes after deploy)
- ✅ Clear reproduction steps identified quickly
- ✅ Team collaborated effectively
- ✅ Fix deployed in under 90 minutes

## What Went Wrong
- ❌ Missing test coverage for expired token edge case
- ❌ Staging didn't catch the issue (different token expiry settings)
- ❌ No automatic rollback triggered
- ❌ Monitoring alert threshold too high

## Action Items
- [ ] ENG-XXX-1: Add test for expired token validation (@engineer, by YYYY-MM-DD)
- [ ] ENG-XXX-2: Align staging token expiry with production (@devops, by YYYY-MM-DD)
- [ ] ENG-XXX-3: Implement automatic rollback on error spike (@platform, by YYYY-MM-DD)
- [ ] ENG-XXX-4: Lower monitoring alert threshold (@observability, by YYYY-MM-DD)
- [ ] ENG-XXX-5: Add runbook for similar issues (@oncall, by YYYY-MM-DD)

## Prevention
How we'll prevent this from happening again:

1. **Testing**: Add test coverage for edge cases
2. **Monitoring**: Improve alerting thresholds
3. **Process**: Update deployment checklist
4. **Documentation**: Create runbook for on-call

## Lessons Learned
Key takeaways for the team.

---

バックポート戦略

修正を複数のブランチ／環境に適用する必要がある場合：

複数環境へのデプロイ

# 1. Fix applied to main (production)
git checkout main
git cherry-pick <hotfix-commit-hash>

# 2. Backport to release candidate
git checkout release-candidate
git cherry-pick <hotfix-commit-hash>
git push origin release-candidate

# 3. Backport to develop
git checkout develop
git cherry-pick <hotfix-commit-hash>
git push origin develop

# Create PRs for each backport:
gh pr create --base release-candidate --head backport/rc/hotfix-ENG-XXX
gh pr create --base develop --head backport/dev/hotfix-ENG-XXX

マージ競合への対処

# If cherry-pick fails due to conflicts
git cherry-pick <hotfix-commit-hash>
# CONFLICT in file.ts

# Resolve conflicts manually
# Then:
git add file.ts
git cherry-pick --continue

代替案：パッチファイル

# Create patch from hotfix
git format-patch -1 <hotfix-commit-hash>
# Creates: 0001-fix-auth-bypass.patch

# Apply to other branch
git checkout release-candidate
git apply 0001-fix-auth-bypass.patch

---

まとめ

緊急リリースのクイックリファレンス

判断フロー

Is production broken?
├─ Yes → Severity level?
│  ├─ P0 (security/down) → Deploy immediately, inform after
│  ├─ P1 (critical bug) → Fast-track PR, deploy same day
│  └─ P2 (major bug) → Standard expedited process
└─ No → Use normal deployment process

目標時間

• P0：問題発生から 2 時間未満でデプロイ
• P1：問題発生から 4 時間未満でデプロイ
• P2：問題発生から 24 時間未満でデプロイ

主な原則

1. 変更を最小限にする：差し迫った問題だけを修正します
2. リグレッションテストを追加する：再発を防ぎます
3. 迅速なフィードバック：まずステージング環境にデプロイします（P0 を除く）
4. 明確なコミュニケーション：関係者に状況を随時知らせます
5. 学習と改善：P0/P1 について PIR を実施します

チェックリスト

• 緊急度を正しく評価する
• 本番環境からホットフィックスブランチを作成する
• リグレッションテストを含む最小限の修正を実装する
• 適切な PR ラベルを使用する
• 十分にテストする（P1/P2 はステージング環境でテスト）
• 承認を得る（P0 は省略可能）
• 監視しながらデプロイする
• 本番環境で修正を検証する
• 状況を共有する
• PIR を予定に入れる（P0/P1）
• フォローアップのチケットを作成する

本番環境の問題に迅速な対応が必要で、通常のリリースプロセスを経ずに優先的にデプロイする場合に、このスキルを使用します。