Session 08 - Change Management

"Thay đổi là không thể tránh khỏi. Quản lý thay đổi tốt là sự khác biệt giữa dự án thành công và thất bại." - ITIL v4

1. Change Control Process

Ba loại Change

2. Change Advisory Board (CAB)

Thành viên CAB

CAB Meeting Format (30 phút, weekly)

1. Review pending change requests          (10 min)
   - Requester trình bày: What, Why, Impact, Rollback
2. Discussion & questions                  (10 min)
   - Risk assessment
   - Resource availability
   - Scheduling conflicts
3. Decision: Approve / Reject / Defer      (5 min)
4. Review kết quả changes đã deploy tuần trước (5 min)

Tip thực chiến: CAB không nên thành bottleneck. Nếu team mature, dùng lightweight CAB - async review qua PR comments, chỉ họp khi có high-risk changes.

3. Impact Analysis Template

Change Impact Assessment Form

markdown
## Change Impact Analysis

### 1. Change Overview
- **Change ID:** CHG-2025-042
- **Requester:** [Tên]
- **Date:** [Ngày]
- **Description:** Migrate user authentication từ cookie-based sang JWT tokens

### 2. Technical Impact
- **Services affected:** AuthService, UserAPI, WebApp, MobileAPI
- **Database changes:** Thêm bảng RefreshTokens, thêm column TokenVersion vào Users
- **API changes:** Response header thay đổi, new /auth/refresh endpoint
- **Configuration changes:** Thêm JWT_SECRET, TOKEN_EXPIRY environment variables

### 3. Risk Assessment
- **Probability of failure:** Medium (3/5)
- **Impact if failed:** High - tất cả users không login được
- **Risk score:** 3 x 4 = 12 (Critical)

### 4. Dependencies
- [ ] Mobile team cần update app (2 Sprint lead time)
- [ ] Third-party SSO providers cần reconfigure
- [ ] Load balancer cần update để không strip auth headers

### 5. Testing Plan
- [ ] Unit tests cho JWT generation/validation
- [ ] Integration tests cho auth flow end-to-end
- [ ] Load test: 5000 concurrent auth requests
- [ ] Security test: Token tampering, expiry, refresh flow

### 6. Rollback Plan
- **Trigger:** Error rate login > 5% trong 10 phút đầu
- **Steps:** Revert deployment, rollback database migration
- **Time to rollback:** < 15 phút
- **Data impact:** RefreshTokens table sẽ bị drop, users cần re-login

### 7. Communication Plan
- [ ] Notify users 1 tuần trước: scheduled maintenance window
- [ ] Notify mobile team 2 Sprint trước: breaking API change
- [ ] Notify support team: new login flow FAQ

4. Emergency Change Procedure

Khi nào trigger Emergency Change?

• Production outage ảnh hưởng > 10% users
• Security vulnerability đang bị exploit
• Data corruption đang diễn ra
• Compliance violation cần fix ngay (legal deadline)

Emergency Change Workflow

1. DETECT    → Alert từ monitoring / user report
               ↓
2. ASSESS    → On-call engineer xác nhận severity
               (P1 = Emergency, P2+ = Normal process)
               ↓
3. APPROVE   → Verbal approval từ 1 CAB member + Engineering Manager
               (Document sau, approve trước)
               ↓
4. IMPLEMENT → Hotfix branch → minimal code change → fast-track review
               ↓
5. VERIFY    → Deploy staging → smoke test → deploy production
               ↓
6. DOCUMENT  → Tạo Change Request retroactively trong 24h
               ↓
7. REVIEW    → Post-incident review trong 48h

Emergency Change Rules

5. Change Request Form Template

markdown
## Change Request

### Basic Information
| Field | Value |
|-------|-------|
| **CR ID** | CHG-[YYYY]-[NNN] |
| **Title** | [Mô tả ngắn gọn] |
| **Requester** | [Tên, Team] |
| **Date Created** | [DD/MM/YYYY] |
| **Priority** | [ ] Critical  [ ] High  [ ] Medium  [ ] Low |
| **Type** | [ ] Standard  [ ] Normal  [ ] Emergency |
| **Target Date** | [DD/MM/YYYY] |

### Change Description
**What:** [Mô tả chi tiết thay đổi gì]
**Why:** [Business justification - tại sao cần thay đổi]
**Who is affected:** [Users, teams, systems bị ảnh hưởng]

### Technical Details
- **Systems/Services affected:** [List]
- **Database changes:** [Yes/No - details]
- **API changes:** [Yes/No - breaking/non-breaking]
- **Infrastructure changes:** [Yes/No - details]
- **Configuration changes:** [Yes/No - details]

### Risk & Impact
- **Risk Level:** [ ] Low  [ ] Medium  [ ] High  [ ] Critical
- **Rollback Plan:** [Steps cụ thể để rollback]
- **Rollback Time:** [Ước tính thời gian rollback]
- **Testing Done:** [Summary test results]

### Approval
| Role | Name | Decision | Date |
|------|------|----------|------|
| CAB Chair | | [ ] Approve [ ] Reject | |
| Tech Lead | | [ ] Approve [ ] Reject | |
| QA Lead | | [ ] Approve [ ] Reject | |

### Implementation
- **Scheduled:** [Date/Time - maintenance window]
- **Implemented by:** [Tên]
- **Verified by:** [Tên]
- **Status:** [ ] Planned  [ ] In Progress  [ ] Completed  [ ] Rolled Back

6. Configuration Management Basics

Configuration Items (CI)

Mọi thứ cần version control và tracking:

Configuration Management Rules

1. Mọi thay đổi qua version control - không manual edit trên server
2. Infrastructure as Code - reproducible environments
3. Secrets không bao giờ commit - dùng Azure Key Vault / AWS Secrets Manager
4. Environment parity - dev/staging/production dùng cùng config structure

csharp
// .NET configuration hierarchy (override từ trên xuống)
// 1. appsettings.json          ← base config
// 2. appsettings.{Env}.json    ← environment-specific
// 3. Environment variables     ← deployment-specific
// 4. Azure App Configuration   ← dynamic, no redeploy
// 5. Key Vault                 ← secrets only

7. Rollback Planning

Rollback Strategy Matrix

Expand-Contract Pattern cho Database Changes

Tránh big-bang migration. Chia thành 3 releases:

Release 1 (Expand):
  - Thêm column mới "FullName"
  - Code viết vào cả "FirstName"+"LastName" và "FullName"
  - Backfill data: UPDATE Users SET FullName = FirstName + ' ' + LastName

Release 2 (Migrate):
  - Code chỉ đọc từ "FullName"
  - Code vẫn viết vào cả hai (backward-compatible)
  - Verify data consistency

Release 3 (Contract):
  - Xoá columns "FirstName" và "LastName"
  - Code chỉ dùng "FullName"

Lợi ích: Mỗi release có thể rollback độc lập mà không mất data.

Pre-Deployment Rollback Checklist

• Rollback steps đã document và review
• Database backup đã chạy và verify
• Previous version artifact vẫn available
• Rollback đã test trên staging environment
• Team biết ai trigger rollback và khi nào
• Monitoring alerts đã set cho rollback triggers
• Communication plan cho users nếu cần rollback

Kết thúc chuỗi SDLC Sessions. Xem thêm: Technical Leadership để nâng cao kỹ năng lãnh đạo kỹ thuật.