1
2
3
4
5
6
7
8
9

// user_service.proto (v1.5.0) - 変更前
message User {
  string id = 1;
  string name = 2;
  string email = 3;
  int32 age = 4;         // ← これを削除予定
  string department = 5;  // ← これも削除予定
  string legacy_format = 6; // ← これも削除予定
}

1
2
3

git add user_service.proto
git commit -m "Remove unused fields from User message"
git push origin main

1
2
3
4
5
6
7

// user_service.proto (v2.0.0) - 変更後
message User {
  string id = 1;
  string name = 2;
  string email = 3;
  // age, department, legacy_format を完全削除
}

1
2
3
4

🔥 AlertManager
[CRITICAL] user-service: Health check failed
- Error rate: 15% → 45%
- Response time: 200ms → TIMEOUT

1
2
3
4
5
6

🚨 PagerDuty Alert
[P1] PRODUCTION DOWN
- user-service: 100% error rate
- payment-service: dependency failure  
- notification-service: cascade failure
- recommendation-service: data corruption

1

kubectl logs user-service-7d4f8b9c-xh2rl

1
2
3
4
5

ERROR: proto: cannot parse invalid wire-format data
ERROR: field 'age' not found in message User
ERROR: field 'department' not found in message User  
ERROR: unmarshaling failed: unknown field
FATAL: service startup failed

1
2

git revert HEAD
git push origin main

1
2
3

❌ FAILED: Container build failed
❌ Protocol buffer compilation error
❌ Service mesh configuration mismatch

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// user_service.proto (v2.0.1) - 緊急パッチ版
message User {
  string id = 1;
  string name = 2;  
  string email = 3;
  
  // 緊急復旧：削除したフィールドを復活
  int32 age = 4;         // 緊急復旧
  string department = 5;  // 緊急復旧  
  string legacy_format = 6; // 緊急復旧
}

1
2
3
4
5

✅ user-service: Started  
✅ payment-service: Health check OK
❌ notification-service: Still failing
❌ recommendation-service: Data inconsistency
❌ analytics-service: Historical data corruption

1
2
3
4
5

# エラーログの嵐
ERROR: User age calculation failed: field missing
ERROR: Department-based routing failed: null value
ERROR: Legacy format parser: unexpected end of data
ERROR: Cache invalidation failed: schema mismatch

1
2
3
4
5

-- analytics データベース  
SELECT user_id, age, department FROM user_analytics 
WHERE created_at > '2025-08-23 16:30:00';

-- 結果: 3時間分のデータで age と department が NULL

1
2
3

重要データ（決済関連）: バックアップ復旧
分析データ: ML補完
ログデータ: 手動補完

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 決済データの復旧
pg_restore --data-only payment_backup_20250823_1630

# 分析データの ML補完
python ml_data_restoration.py \
  --missing-fields age,department \
  --time-range "2025-08-23 16:30 - 19:30"
  
# ログデータの手動修復  
./manual_log_fix.sh user-service 20250823

1
2
3
4
5
6
7

recommendation-service 
  ↓ (depends on)
user-profile-service
  ↓ (depends on)  
user-service
  ↓ (depends on)
identity-service

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# Phase 1: 基盤サービス
kubectl rollout restart deployment/identity-service
kubectl wait --for=condition=available deployment/identity-service

# Phase 2: コアサービス  
kubectl rollout restart deployment/user-service
kubectl wait --for=condition=available deployment/user-service

# Phase 3: 依存サービス
kubectl rollout restart deployment/user-profile-service
kubectl wait --for=condition=available deployment/user-profile-service

# Phase 4: 上位サービス
kubectl rollout restart deployment/recommendation-service
kubectl wait --for=condition=available deployment/recommendation-service

1
2
3
4
5

✅ user-service: 100% healthy
✅ payment-service: 100% healthy  
✅ notification-service: 100% healthy
✅ recommendation-service: 100% healthy
✅ analytics-service: 100% healthy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

## 破壊的変更チェックリスト

### 事前調査  
- [ ] 影響範囲の完全な調査完了
- [ ] 依存サービスリストの作成  
- [ ] 既存クライアントの特定
- [ ] ロールバック戦略の策定
- [ ] データ移行計画の作成

### リスク評価
- [ ] ビジネスインパクト評価
- [ ] 技術的リスク評価  
- [ ] 復旧時間見積もり
- [ ] 代替案の検討

### 承認プロセス
- [ ] テックリード承認
- [ ] CTO承認  
- [ ] ビジネス側承認

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// 新しいアプローチ（段階的変更）
message User {
  string id = 1;
  string name = 2;
  string email = 3;
  
  // 段階1：非推奨マーク（削除予定を明示）
  int32 age = 4 [deprecated = true];         // 削除予定: 2025-12-31
  string department = 5 [deprecated = true]; // 削除予定: 2025-12-31
  string legacy_format = 6 [deprecated = true]; // 削除予定: 2025-12-31
  
  // 新フィールド追加
  string birth_date = 7;      // age の代替
  UserProfile profile = 8;    // department の代替  
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// Phase 2: 移行期間中の設定
message User {
  string id = 1;
  string name = 2;  
  string email = 3;
  
  // 段階2：警告レベル引き上げ
  int32 age = 4 [deprecated = true];         // 警告：2025-11-30削除
  string department = 5 [deprecated = true]; // 警告：2025-11-30削除
  string legacy_format = 6 [deprecated = true]; // 警告：2025-11-30削除
  
  string birth_date = 7;
  UserProfile profile = 8;
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Phase 3: 安全な削除
message User {
  // 削除済みフィールドの番号を予約
  reserved 4, 5, 6;
  reserved "age", "department", "legacy_format";
  
  string id = 1;
  string name = 2;
  string email = 3;
  string birth_date = 7;
  UserProfile profile = 8;
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# Proto互換性チェック  
proto-compatibility-check \
  --old-proto user_service_v1.proto \
  --new-proto user_service_v2.proto \
  --strict-mode

# 出力例
❌ BREAKING CHANGE DETECTED:
- Field 'age' (4) removed from message User
- Field 'department' (5) removed from message User  
- Field 'legacy_format' (6) removed from message User

⚠️  IMPACT ANALYSIS:
- Affected services: 5 services
- Estimated impact: HIGH
- Recommended approach: Gradual migration

🔧 SUGGESTED STEPS:
1. Mark fields as deprecated
2. Add alternative fields  
3. Monitor usage for 3 months
4. Remove after migration complete

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# サービス依存関係の可視化
service-dependency-tracker analyze user-service

# 出力例  
📊 DEPENDENCY MAP:
user-service (Protocol Buffer: user.proto)
├── payment-service (uses: User.age for risk calculation)
├── notification-service (uses: User.department for routing)  
├── recommendation-service (uses: User.age for algorithm)
├── analytics-service (uses: User.department for reports)
└── legacy-system (uses: User.legacy_format for integration)

⚠️  BREAKING CHANGE IMPACT:
- Field 'age': 2 critical services affected
- Field 'department': 2 services affected
- Field 'legacy_format': 1 legacy system affected

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

## 破壊的変更管理ダッシュボード

### 現在のステータス
- Phase 1 (非推奨マーク): user_service v2.1.0
- 削除予定日: 2025-12-31
- 残り日数: 108日

### 移行進捗  
- user_service.User.age使用率: 23% ↓ (目標: <10%)
- user_service.User.department使用率: 15% ↓ (目標: <10%)
- user_service.User.legacy_format使用率: 3% ✅ (目標達成)

### アラート
⚠️  payment-service: age フィールド使用量が増加中
✅ notification-service: department フィールド移行完了

1
2
3

エンジニア: 「ちょっと変更するだけだから大丈夫でしょ」
レビュアー: 「コードは問題ないですね、LGTM」  
リリース: 「金曜の夕方だけど、軽微だからリリースしちゃお」

1
2
3

エンジニア: 「これって破壊的変更になりませんか？影響調査します」
レビュアー: 「依存関係チェックツール回しましたか？段階的移行計画は？」
リリース: 「破壊的変更は必ず月曜午前中。復旧チーム待機で」

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

## Phase 0: 事前準備（必須）
- [ ] 破壊的変更影響調査完了
- [ ] 依存サービス一覧作成（最低10サービス調査）  
- [ ] 既存クライアント使用状況調査
- [ ] ビジネス影響度評価（売上・顧客への影響）
- [ ] テックリード・CTO承認取得

## Phase 1: 非推奨化（3ヶ月以上）
- [ ] deprecated マーク追加
- [ ] 代替手段の提供
- [ ] 移行ガイド作成・共有
- [ ] 使用状況監視開始  
- [ ] 定期的な移行状況レポート

## Phase 2: 移行促進（2ヶ月以上）
- [ ] 使用率50%以下を確認
- [ ] 警告レベル引き上げ
- [ ] 個別チーム移行支援  
- [ ] 削除予定日の明確化・通知

## Phase 3: 削除実行
- [ ] 使用率5%以下を確認
- [ ] メジャーバージョンアップとして実施
- [ ] reserved設定でフィールド保護
- [ ] 復旧チーム待機での実行（平日午前中）
- [ ] 段階的ロールアウト（Canary → Blue-Green）