Product & Business Thinking for Engineers

Business Goal:
  "Tăng revenue 30% YoY"
        │
        ▼
Company OKR:
  O: Expand into enterprise market
  KR1: 10 enterprise customers paying $50K+ ARR
  KR2: NPS enterprise customers > 50
        │
        ▼
Product Metrics:
  - Enterprise conversion rate (trial → paid)
  - Feature adoption rate (SSO, audit logs)
  - Time-to-value (từ signup đến first "aha moment")
        │
        ▼
Engineering Metrics:
  - Uptime SLA (99.9% → enterprise requirement)
  - API latency p99 < 200ms
  - Time-to-deploy (deploy cycle ảnh hưởng feature delivery)
  - MTTR (Mean Time To Recover) sau incidents

Metric kỹ thuật          → Business impact
────────────────────────────────────────────────────────────────
API availability 99.9%   → Downtime = 8.7 giờ/năm
                            Enterprise SLA yêu cầu ≥ 99.9%
                            Dưới ngưỡng = breach contract, churn risk

P99 latency 800ms (login) → Friction ở critical path của user
                             Mỗi 100ms latency tăng → conversion giảm ~1% (Google research)
                             Login là cửa ngõ → impacted toàn bộ funnel

Deploy cycle 2 tuần       → Feature cycle 2 tuần
                             Competitor với CI/CD tốt ship 10x/ngày
                             Product feedback loop chậm 2 tuần

MTTR 4 giờ               → Mỗi giờ downtime = $X revenue lost (tùy business)
                             + reputational damage + customer trust

Before State:
  - Deploy manual: 2 giờ/deploy × 3 deploys/week = 6 giờ/week
  - Incident rate: 2 incidents/month từ human error trong deploy
  - MTTR: 3 giờ/incident
  - Team size: 5 engineers × $60/giờ

Current costs per month:
  Manual deploy: 6h × 4 weeks = 24h × $60 = $1,440/month
  Incident cost: 2 × 3h × 5 engineers × $60 = $1,800/month
  Total: ~$3,240/month

After CI/CD (optimistic):
  Automated deploy: 15 min × 15 deploys/week = 3.75h/week (review time)
  Incident rate: giảm 80% → 0.4 incidents/month
  
Monthly costs after:
  Deploy: 3.75h × 4 = 15h × $60 = $900/month
  Incident: 0.4 × 3h × 5 × $60 = $360/month
  Total: ~$1,260/month

Savings: $3,240 - $1,260 = $1,980/month
Investment: 2 engineers × 2 months × 160h × $60 = $38,400
Payback period: $38,400 / $1,980 ≈ 19 months

Additional benefits không đo được:
  + Faster feature delivery (competitive advantage)
  + Dev experience → retention
  + Scalability (deploy cost không tăng khi team grow)

Ví dụ: Implement "forgot password" feature

Engineer thinking (what):
  "Tạo endpoint POST /auth/reset-password
   Generate token, lưu vào DB với TTL 1h
   Gửi email với reset link
   Validate token khi user click"

Product thinking (why + how):
  "User đã bị lock out, frustrated, cần reset nhanh.
   
   Edge cases cần nghĩ đến:
   - User click link lần 2 sau khi đã reset? → Token đã invalidated, message rõ ràng
   - Email không đến? → Resend option, check spam folder instruction
   - User reset trên mobile, click link mở trên web → vẫn phải work
   - Kẻ xấu nhập email người khác? → Không reveal email có tồn tại không (timing attack)
   - User đang logged in request reset? → Logout hết sessions cũ sau reset?
   
   Success state:
   - User nhận email trong < 1 phút (không phải 10 phút)
   - Link hoạt động trên mobile browser
   - Sau reset, user được log in ngay thay vì phải đăng nhập lại"

Reach: Bao nhiêu users/requests bị ảnh hưởng?
  "Feature A affect 100% users, Feature B chỉ affect 5% enterprise users"

Impact: Impact mạnh đến đâu nếu làm?
  (3 = Massive, 2 = Significant, 1 = Moderate, 0.5 = Low)

Confidence: Bạn chắc chắn bao nhiêu phần trăm về estimate?
  "90% confident về impact estimate → 0.9"

Effort: Mất bao nhiêu person-months?

RICE Score = (Reach × Impact × Confidence) / Effort

Ví dụ:
  Tăng tốc login (giảm latency 300ms → 100ms):
    Reach: 10,000 login/day
    Impact: 2 (significant, ảnh hưởng conversion)
    Confidence: 0.8
    Effort: 1 person-month
    RICE = (10,000 × 2 × 0.8) / 1 = 16,000

  Optimize rarely-used admin report page:
    Reach: 50 requests/day
    Impact: 1
    Confidence: 0.9
    Effort: 1 person-month
    RICE = (50 × 1 × 0.9) / 1 = 45

  Clearly: invest 1 tháng vào login, không phải admin report.

Hệ quả của mindset này:
  - Engineer tự nhiên add proper logging vì họ sẽ là người cần debug
  - Feature flag được implement vì engineer biết deploy là risky
  - Health check endpoint được add vì engineer biết K8s cần nó
  - Resource limit được set vì engineer không muốn bị paged lúc 3am

P0 Incident (Production down, severe user impact):

T+0   Incident detected (alert, user report, monitoring)
T+5m  Incident Commander (IC) assigned, #incident channel created
T+10m Initial assessment: Scope, Impact, Hypotheses
T+15m Communication sent: Internal stakeholders, external status page
T+30m Either: Fix deployed hoặc Rollback executed hoặc Workaround active
T+Xh  All-clear, users notified

During incident:
  IC role: Coordinate, không code
  → Assign roles: Investigator, Comms, Customer Support liaison
  → Every 30 min: Update đến stakeholders ("Still investigating, next update in 30min")
  → Document trong war room doc: Timeline, hypotheses, actions taken

Common mistakes:
  → Too many cooks: Nhiều người cùng ssh vào server → chaos
  → Silent investigation: Không update stakeholders → panic tăng
  → Heroics > Process: Engineer fix mà không document → knowledge lost

## Post-Mortem: Authentication Outage — 2024-03-15

**Duration**: 23:05 - 23:47 (42 minutes)
**Severity**: P0
**Impact**: 100% users unable to login, estimated 1,200 active sessions affected

### Timeline
23:05 - Alert fired: login error rate > 5%
23:08 - On-call engineer paged, starts investigation
23:15 - Root cause identified: Redis connection pool exhausted
23:22 - Workaround: Restart auth service (temporary, clears connection pool)
23:30 - Error rate back to normal
23:47 - Root fix deployed: connection pool leak in new JWT validation code

### Root Cause
PR #4521 (deployed 22:50) introduced JWT validation logic that created
a Redis connection per validation but never closed it. Under normal load
(< 100 req/s) this leaked slowly. At 23:05 during peak traffic (350 req/s),
pool exhausted in 15 minutes.

### Why Wasn't This Caught?
- Unit tests mocked Redis connection → leak not detected
- Load test environment capped at 50 req/s → không trigger issue
- Code review missed the unclosed connection (no linter rule for this)

### Action Items
| Action | Owner | Due Date | Status |
|---|---|---|---|
| Add integration test với real Redis, connection pool monitoring | @khoa | 2024-03-22 | TODO |
| Linter rule: detect unclosed Redis connections | @tuan | 2024-03-29 | TODO |
| Load test threshold tăng lên 500 req/s | @DevOps | 2024-04-05 | TODO |
| Add Redis connection pool metrics to dashboard | @khoa | 2024-03-22 | TODO |

### What Went Well
- Monitoring alert fired trong vòng 5 phút
- On-call response nhanh (paged → investigated trong 7 phút)
- Workaround (restart) effective trong vòng 22 phút deployment

### What Didn't Go Well
- Root cause mất 30 phút để identify (Redis connection pool không có metrics)
- No external status page update (customers complained on Twitter trước khi update)

Operational Excellence checklist trước khi ship:
  [ ] Service có readiness + liveness probe không?
  [ ] Timeout được set cho tất cả external calls chưa?
  [ ] Logging đủ để debug production issue mà không cần ssh vào server?
  [ ] Metrics: Có dashboard với key metrics (latency, error rate, throughput)?
  [ ] Alerts: Alert có ngưỡng hợp lý không (không quá nhạy, không miss real issue)?
  [ ] Circuit breaker: Service có graceful degrade khi dependency down không?
  [ ] Runbook: Đã có runbook cho common failure modes chưa?

Nguyên tắc vàng về on-call:
  Nếu alert fire quá thường xuyên (> 1 lần/week) → Alert threshold sai hoặc cần fix
  Nếu alert không actionable → Remove hoặc improve
  On-call fatigue = churn risk. Tốt hơn fix system hơn là chịu đựng noise

Exploration Mode (Innovation):
  - "Could we use LLM để automate X?"
  - "Có architecture tốt hơn cho problem này không?"
  - Appropriate khi: Ổn định, có thời gian, low risk
  - Output: ADR, POC, RFC

Exploitation Mode (Execution):
  - "Ship this feature this sprint"
  - "Tập trung vào production stability"
  - Appropriate khi: Growth phase, competitive pressure, tech debt đang trả giá

Sai lầm phổ biến:
  - Luôn ở Exploration → Never ship, "architecture astronaut"
  - Luôn ở Exploitation → No innovation, knet chuẩn bị cho tương lai

Cách tạo innovation time trong team thực:
  1. "Debt sprint": 1 sprint mỗi quarter dedicated cho refactoring + tech debt
  2. Hackathon: 1-2 ngày/quarter để explore crazy ideas (không cần ship)
  3. "10% overhead": Khi estimate, add 10% buffer cho improvements
  4. Investment items trong backlog: Treat tech investments như features với proper priority
  
Kết quả:
  - Team không bị burnt out với chỉ feature work
  - Innovation opportunities được surfaced
  - Engineer ownership tăng ("Đây là codebase của tôi, tôi muốn nó tốt")