🚀 Chapter 6 — Enterprise: Từ Platform đến Production Reliability
ShopNow đã có CI/CD, Harbor, Kubernetes, GitOps và ArgoCD.
Nhưng vào một buổi tối thứ Sáu, hệ thống bắt đầu chậm.
Không có deployment nào đang chạy.
Kubernetes vẫn
Healthy.ArgoCD vẫn
Synced.Nhưng khách hàng không thể thanh toán.
Platform đã giải quyết việc deploy. Bây giờ Enterprise phải giải quyết việc vận hành.
1. Vấn đề mới: "Running" không có nghĩa là "Healthy"
Ở Phase 5, ShopNow có:
Git
↓
Azure DevOps
↓
Harbor
↓
GitOps
↓
ArgoCD
↓
Kubernetes
Deployment thành công.
Pod:
Running
ArgoCD:
Synced
Nhưng khách hàng báo:
Checkout rất chậm
Payment timeout
Order thất bại
Đây là lúc Platform Team nhận ra:
Kubernetes biết container có đang chạy hay không.
ArgoCD biết deployment có đúng với Git hay không.
Nhưng không hệ thống nào tự động trả lời câu hỏi: "Người dùng có đang sử dụng hệ thống tốt không?"
2. Enterprise cần một lớp mới: Observability
ShopNow bổ sung:
Kubernetes
│
┌──────────────┼──────────────┐
│ │ │
Metrics Logs Traces
│ │ │
└──────────────┼──────────────┘
▼
Observability
│
▼
Alerting / SLO
│
▼
Incident Response
Ba tín hiệu quan trọng:
Metrics
Logs
Traces
3. Metrics — "Hệ thống đang như thế nào?"
Ví dụ:
CPU
Memory
Request Rate
Error Rate
Latency
Pod Count
Restart Count
Ví dụ:
checkout_requests_total = 1,200,000
checkout_errors_total = 15,000
Ta có thể tính:
Error Rate
= errors / requests
= 15,000 / 1,200,000
= 1.25%
Hoặc:
P95 latency = 850ms
Điều này nói rằng:
95% request nhanh hơn 850ms.
Metrics giúp trả lời:
"Chuyện gì đang xảy ra?"
4. Logs — "Tại sao nó xảy ra?"
Metrics nói:
Error Rate = 8%
Nhưng chưa nói:
Vì sao?
Logs có thể cho thấy:
PaymentService
ERROR
Database connection timeout
Hoặc:
Redis connection refused
Hoặc:
HTTP 503 from payment-service
Architecture:
Application
│
▼
Logs
│
▼
Fluent Bit
│
▼
Loki
│
▼
Grafana
Logs trả lời:
"Tại sao nó xảy ra?"
5. Traces — "Request đi qua đâu?"
Microservices khiến việc debug khó hơn.
Một request:
Client
↓
API Gateway
↓
Checkout
↓
Cart
↓
Payment
↓
Inventory
↓
Database
Nếu request mất 5 giây:
Total = 5s
Nhưng service nào chậm?
Tracing giúp nhìn thấy:
Request
│
├── API Gateway 20ms
│
├── Checkout 50ms
│
├── Cart 30ms
│
├── Payment 4.7s ← Problem
│
└── Database 10ms
Bây giờ ta biết:
Payment Service là bottleneck.
Tracing trả lời:
"Request đã đi qua đâu và chậm ở đâu?"
6. Ba tín hiệu kết hợp
Enterprise không nhìn riêng từng thứ.
Incident
│
┌─────────┼─────────┐
▼ ▼ ▼
Metrics Logs Traces
│ │ │
▼ ▼ ▼
What? Why? Where?
Ví dụ:
Metrics:
Error Rate ↑
↓
Logs:
Payment timeout
↓
Trace:
Payment → Database = 4.8s
↓
Root Cause:
Database latency
Đây mới là tư duy Observability.
7. Monitoring không phải Observability
Đừng đồng nhất hai khái niệm.
Monitoring
Ta biết trước mình muốn theo dõi:
CPU > 80%
Memory > 90%
Error Rate > 5%
Observability
Ta có đủ dữ liệu để điều tra một vấn đề chưa biết trước.
Ví dụ:
"Tại sao checkout của khách hàng Nhật chậm hơn khách hàng Mỹ?"
Đây là câu hỏi mà dashboard CPU đơn thuần không giải quyết được.
8. Alerting
Không thể bắt con người ngồi nhìn Grafana 24/7.
Vì vậy:
Metrics
↓
Prometheus
↓
Alert Rules
↓
Alertmanager
↓
Slack / Email / Pager
Ví dụ:
Error Rate > 5%
for 5 minutes
→ Alert.
Hoặc:
P95 latency > 1s
for 10 minutes
→ Alert.
Nhưng Enterprise cần cẩn thận.
Nếu tạo:
500 alerts/day
thì Engineer sẽ bắt đầu:
Ignore alerts
Đây là:
Alert Fatigue
9. Alert phải gắn với hành động
Một alert tốt phải trả lời:
What?
Why?
Impact?
Who?
What should I do?
Ví dụ:
[CRITICAL]
Service:
payment
Condition:
Error rate > 5%
Duration:
10 minutes
Impact:
Checkout failure increasing
Runbook:
payment-db-timeout.md
Owner:
Payment Team
Alert không chỉ nói:
CPU high
mà phải giúp Engineer biết:
Bây giờ tôi nên làm gì?
10. SLO — Enterprise không chỉ đo Infrastructure
Đây là bước tiến lớn.
Infrastructure metrics:
CPU
Memory
Disk
Network
không trực tiếp thể hiện business impact.
CEO/CPO không quan tâm:
"CPU hôm nay là 72%."
Họ quan tâm:
"Khách hàng có thanh toán được không?"
Vì vậy ShopNow định nghĩa:
SLO
Ví dụ:
Checkout Availability
≥ 99.9%
Hoặc:
95% checkout requests
< 500ms
11. SLA, SLO, SLI
Ba khái niệm rất dễ nhầm.
SLI
Measurement
Ví dụ:
99.95% requests successful
SLO
Target
Target:
99.9% successful requests
SLA
Business commitment
Ví dụ:
99.9% availability
kèm theo điều khoản với khách hàng.
Có thể nhớ:
SLI = Measure
SLO = Goal
SLA = Contract
12. Error Budget
Giả sử:
SLO = 99.9%
Một tháng khoảng:
43,200 minutes
0.1% downtime:
43.2 minutes
Đây là:
Error Budget.
ShopNow có thể "tiêu" khoảng thời gian đó cho:
Deploy
Migration
Experiment
Infrastructure Change
Miễn là vẫn nằm trong SLO.
13. SLO thay đổi cách Release
Ví dụ:
Error Budget còn nhiều
↓
Có thể release nhanh
Nhưng:
Error Budget gần hết
↓
Hạn chế risky deployment
↓
Ưu tiên reliability
Đây là tư duy Enterprise:
Tốc độ release phải cân bằng với độ tin cậy.
14. Incident xảy ra
22:15.
Alert:
Checkout Error Rate > 5%
Incident được mở.
Customer
↓
Checkout failure
↓
Alert
↓
On-call Engineer
Điều đầu tiên không phải:
kubectl delete pod
Mà là:
Xác định impact.
15. Incident Response
Một quy trình cơ bản:
Detect
↓
Triage
↓
Mitigate
↓
Investigate
↓
Resolve
↓
Postmortem
Detect
Monitoring phát hiện:
Error rate ↑
Triage
Xác định:
Which service?
How many users?
Which region?
Since when?
Recent deployment?
Mitigate
Mục tiêu đầu tiên:
Giảm impact cho khách hàng.
Không nhất thiết phải tìm root cause ngay lập tức.
Ví dụ:
Rollback
Disable feature
Scale service
Route traffic
Investigate
Sau khi impact được kiểm soát:
Metrics
+
Logs
+
Traces
+
Recent Changes
để tìm nguyên nhân.
Resolve
Khôi phục hệ thống.
Postmortem
Sau incident:
What happened?
Why?
Why wasn't it detected earlier?
How can we prevent it?
16. Rollback vẫn là vũ khí quan trọng
Giả sử:
10:00
checkout:v1.8.3
Sau deployment:
Error Rate ↑
GitOps cho phép:
v1.8.3
↓
revert
↓
v1.8.2
ArgoCD:
Git
↓
Desired State
↓
ArgoCD
↓
Kubernetes
Rollback không cần:
Rebuild
Retest
Repush
nếu artifact cũ vẫn còn và đã được xác minh.
17. Nhưng Rollback không phải lúc nào cũng an toàn
Đây là nơi tư duy Senior bắt đầu khác.
Ví dụ deployment:
Application v2
+
Database Migration
Database:
v1 schema
↓
v2 schema
Nếu rollback application:
v2
↓
v1
nhưng database vẫn:
v2 schema
có thể xảy ra:
Application v1
↓
Database v2
↓
Compatibility Error
Vì vậy:
Rollback application không đồng nghĩa rollback toàn bộ system.
Enterprise cần thiết kế:
Backward-compatible migration
Expand → Migrate → Contract
18. Deployment Strategy
Không phải lúc nào cũng:
Old Version
↓
New Version
Enterprise có nhiều chiến lược.
Rolling Update
v1 v1 v1 v1
↓
v2
↓
v1 v1 v2 v2
↓
v2 v2 v2 v2
Blue/Green
Traffic
│
┌─────┴─────┐
▼ ▼
Blue v1 Green v2
│
Current New
Test Green.
Sau đó switch traffic.
Rollback:
Green
↓
Blue
Canary
Traffic
│
├── 95% → v1
│
└── 5% → v2
Theo dõi:
Error Rate
Latency
Business Metrics
Nếu tốt:
5%
↓
25%
↓
50%
↓
100%
Nếu xấu:
v2
↓
Rollback
19. Progressive Delivery
Từ đó ShopNow bắt đầu tiến tới:
Deploy
↓
Observe
↓
Evaluate
↓
Promote
Thay vì:
Deploy
↓
Hope
Đây là một thay đổi lớn về tư duy.
20. Security trở thành trách nhiệm xuyên suốt
Enterprise không để Security nằm ở cuối pipeline.
Security bắt đầu từ:
Developer
↓
Code
↓
Dependency
↓
Container
↓
Registry
↓
Kubernetes
↓
Runtime
Có thể gọi là:
Shift Left + Defense in Depth
21. Supply Chain Security
ShopNow cần biết:
Image Production này được build từ đâu?
Ví dụ:
Git Commit
↓
Azure DevOps Build
↓
Test
↓
Security Scan
↓
Docker Image
↓
Harbor
↓
Production
Mỗi bước tạo ra evidence.
Enterprise có thể tiến thêm tới:
SBOM
Image Signature
Provenance
Policy Enforcement
Mục tiêu:
Không chỉ biết image chạy được, mà biết image đáng tin cậy từ đâu.
22. RBAC và Zero Trust
Khi công ty có:
100 Developers
20 Teams
10 Clusters
500 Services
không thể cho tất cả:
cluster-admin
Thay vào đó:
Developer
↓
Namespace / Application
Platform Team
↓
Platform Resources
Security Team
↓
Security Policies
SRE
↓
Production Operations
Nguyên tắc:
Least Privilege
23. Multi-Cluster
Một Enterprise thường không muốn:
One Cluster
│
┌────────┼────────┐
▼ ▼ ▼
Dev Staging Prod
Production có thể được tách:
Kubernetes
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Dev Cluster Staging Cluster Prod Cluster
Thậm chí:
Prod Japan
Prod US
Prod EU
GitOps giúp quản lý desired state cho nhiều cluster.
24. Disaster Recovery
Một ngày nào đó:
Production Cluster
↓
💥
Câu hỏi:
"Có backup không?"
Nhưng Enterprise phải hỏi sâu hơn:
Backup?
Restore?
How long?
How much data lost?
Hai khái niệm:
RPO
Bao nhiêu dữ liệu có thể mất?
RPO = 5 minutes
RTO
Bao lâu phải khôi phục?
RTO = 30 minutes
Nhớ:
RPO = Data Loss
RTO = Recovery Time
25. Disaster Recovery Architecture
Ví dụ:
Primary
Kubernetes
│
│
Backup Data
│
▼
Object Storage
│
▼
Secondary
Kubernetes
Nhưng backup chỉ có ý nghĩa nếu:
Restore đã được test.
Một backup chưa từng restore:
Backup
≠
Reliable Recovery
26. Enterprise Platform cuối cùng trông như thế nào?
Toàn bộ hành trình của ShopNow:
Developer
│
▼
GitHub
│
▼
┌─────────────────┐
│ Azure DevOps │
│ │
│ Build │
│ Test │
│ Security │
│ Package │
└────────┬────────┘
│
▼
┌───────┐
│Harbor │
└───┬───┘
│
▼
┌───────────┐
│ GitOps │
│ Repository│
└─────┬─────┘
│
▼
┌───────┐
│ ArgoCD│
└───┬───┘
│
▼
┌─────────────────────┐
│ Kubernetes │
│ │
│ Dev / Staging / Prod│
└──────────┬──────────┘
│
┌───────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Metrics Logs Traces
│ │ │
└───────────────┼────────────────┘
▼
Observability
│
▼
Alerting / SLO
│
▼
Incident Response
│
▼
Reliability
Đây không còn đơn thuần là:
CI/CD Pipeline
Mà là:
Enterprise Software Delivery & Reliability Platform
27. Nhìn lại toàn bộ 6 Phase
Bây giờ hãy nhìn ShopNow từ ngày đầu tiên.
Phase 1 — Startup
Git
↓
SSH
↓
Docker Compose
Problem: Manual Deployment.
Phase 2 — Automation
Git
↓
Azure DevOps
↓
Build / Test / Deploy
Problem: Pipeline và artifact bắt đầu phức tạp.
Phase 3 — Platform
Reusable Templates
↓
Standardized CI/CD
Problem: Artifact governance.
Phase 4 — Production
Azure DevOps
↓
Harbor
↓
Approval
↓
Production
Problem: VM không còn đủ khả năng scale.
Phase 5 — Platform + GitOps
GitOps
↓
ArgoCD
↓
Kubernetes
Problem: Production ngày càng phức tạp.
Phase 6 — Enterprise
Kubernetes
↓
Observability
↓
SLO
↓
Incident Response
↓
Reliability
↓
Enterprise Governance
Problem cuối cùng:
Làm sao để hệ thống đáng tin cậy ở quy mô lớn?
28. Tư duy Senior DevOps sau 6 Phase
Sau khi học xong roadmap này, đừng tự hỏi:
"Tôi nhớ bao nhiêu câu lệnh kubectl?"
Hay:
"Tôi nhớ bao nhiêu syntax Helm?"
Hay:
"Tôi viết Azure Pipeline YAML giỏi chưa?"
Hãy tự hỏi:
1. Business đang gặp vấn đề gì?
Manual deployment?
Scale?
Security?
Reliability?
Cost?
2. Architecture nào giải quyết vấn đề đó?
CI/CD?
Registry?
Kubernetes?
GitOps?
Observability?
3. Trade-off là gì?
Complexity
Cost
Security
Velocity
Reliability
4. Failure mode là gì?
Deployment failed?
Cluster failed?
Database failed?
Network failed?
Human error?
5. Nếu Production chết lúc 2 giờ sáng?
Detect
↓
Understand
↓
Mitigate
↓
Recover
↓
Learn
Đây mới là tư duy của một Senior DevOps / Platform Engineer / SRE.
29. Toàn bộ roadmap trong một câu chuyện
Cuối cùng, toàn bộ roadmap có thể nhớ bằng một câu:
Manual
↓
Automation
↓
Standardization
↓
Governance
↓
Platform
↓
Reliability
Hay cụ thể hơn:
Docker Compose
↓
CI/CD
↓
Reusable Pipelines
↓
Harbor
↓
Kubernetes
↓
GitOps + ArgoCD
↓
Observability
↓
SRE / Enterprise Reliability
Và đó chính là hành trình:
Từ "tôi có thể deploy một service" → "tôi có thể xây dựng một Platform giúp hàng trăm developer deploy hàng trăm service một cách an toàn, có kiểm soát và đáng tin cậy."
All rights reserved
