DevOps không phải là “một job title”, mà là một cách làm việc: rút ngắn vòng lặp từ code → deploy → đo lường → học → cải tiến. Mình viết bài này như một bản tóm tắt hành trình thực chiến: những thứ giúp hệ thống ổn định hơn và giúp đội ngũ đỡ kiệt sức.
SEO quick summary (TL;DR): Nếu bạn đang làm DevOps/SRE, hãy ưu tiên: chuẩn hoá deploy bằng CI/CD, quản trị cấu hình bằng IaC, observability tốt (logs/metrics/traces), incident response có quy trình, và security “shift-left”.
Mục tiêu của bài viết
- Giúp bạn có một checklist DevOps để áp dụng dần.
- Chia sẻ các sai lầm phổ biến và cách mình đã sửa.
- Đưa ra ví dụ cụ thể để bạn có thể bắt tay làm ngay.
1) CI/CD: giảm rủi ro bằng các “cửa chặn” nhỏ
Ngày trước mình hay nghĩ CI/CD chỉ là tự động hoá build và deploy. Sau này mới thấy giá trị thật là giảm biến động và chuẩn hoá quy trình.
Thực hành mình thấy hiệu quả:
- Chia pipeline thành các stage rõ ràng:
lint → test → build → security scan → deploy. - Áp dụng progressive delivery (canary / blue-green) thay vì “big bang deploy”.
- Tự động rollback khi SLO/SLA vượt ngưỡng (kết hợp metrics).
Ví dụ checklist:
- [ ] Có unit/integration test tối thiểu cho path quan trọng
- [ ] Có chạy SAST/Dependency scan trong CI
- [ ] Có deploy theo môi trường (dev/stage/prod) tách biệt
2) IaC: hạ tầng là code, nhưng đừng biến nó thành “mê cung”
Infrastructure as Code (Terraform/Pulumi/CloudFormation/Ansible) giúp bạn:
- version control,
- review như code,
- tái tạo môi trường.
Bài học xương máu: IaC rất dễ thành “mê cung module” nếu không có chuẩn.
Mình thường làm:
- Đặt convention naming rõ ràng.
- Tách module theo domain (network, compute, data) chứ không tách theo team cảm tính.
- Mọi thay đổi IaC đều qua PR + plan output.
3) Observability: đừng chỉ có logs
Nếu chỉ có logs, bạn sẽ debug như mò kim đáy bể.
Bộ 3 nên có:
- Metrics (Prometheus/Grafana): xu hướng, ngưỡng, alert.
- Logs (ELK/Loki): chi tiết từng request/job.
- Traces (OpenTelemetry/Jaeger): đường đi request qua service.
Câu hỏi mình luôn đặt:
- Khi hệ thống chậm, mình có biết chậm ở đâu trong 5 phút không?
- Khi lỗi tăng, mình có biết bắt đầu từ phiên bản nào không?
4) Alerting: “ít nhưng chất”
Một hệ thống cảnh báo tốt không phải là hệ thống kêu nhiều, mà là hệ thống kêu đúng.
Nguyên tắc mình dùng:
- Alert theo symptoms (SLO burn rate) thay vì theo causes (CPU 70%).
- Có playbook: alert nào cũng phải có “làm gì tiếp theo”.
- Giảm noisy alert bằng grouping/dedup và thời gian “for”.
5) Incident response: biến sự cố thành dữ liệu
Sự cố chắc chắn sẽ xảy ra. Vấn đề là bạn có học được gì sau đó không.
Mình khuyến nghị:
- Runbook cho các tình huống hay gặp.
- Postmortem không đổ lỗi (blameless), tập trung vào hệ thống.
- Track action items và deadline rõ ràng.
6) Deployment strategy: canary cứu bạn khỏi những cú ngã đau
Mình thích canary vì nó biến deploy thành một phép thử có kiểm soát.
Một flow đơn giản:
- Deploy 1% traffic
- Quan sát error rate/latency
- Nếu ổn → tăng 10% → 50% → 100%
7) Secrets management: đừng để secret “trôi” trong repo và CI logs
- Không hardcode secret trong code/repo.
- Dùng secret manager (Vault, AWS Secrets Manager, GCP Secret Manager).
- Mask logs và hạn chế quyền đọc secret.
8) Security trong DevOps: shift-left nhưng vẫn phải shift-right
Shift-left là đưa security vào sớm (CI scans, policy-as-code). Shift-right là quan sát và phản ứng khi chạy thật.
Nên có:
- Dependency scanning
- Container image scanning
- IaC scanning
- Runtime monitoring
9) Tối ưu chi phí: FinOps “nhẹ nhàng”
Cắt chi phí không phải là tắt hết, mà là đo lường và tối ưu đúng chỗ.
- Autoscaling dựa trên metrics phù hợp
- Dọn tài nguyên không dùng (stale volumes, orphaned IPs)
- Right-size instance theo workload
10) Documentation: viết cho “bạn 3 giờ sáng”
Nếu bạn từng on-call lúc 3 giờ sáng, bạn sẽ hiểu: doc tốt là liều thuốc an thần.
- Runbook phải dễ scan
- Có lệnh mẫu / vị trí dashboard / link log query
11) Văn hoá: DevOps là teamwork, không phải “một người gánh hết”
- Dev hiểu vận hành tối thiểu
- Ops hiểu release cycle
- Có ownership rõ ràng
12) Lộ trình áp dụng (gợi ý)
Nếu bạn đang bắt đầu, mình gợi ý thứ tự:
- CI tối thiểu + deploy staging
- Observability (metrics trước)
- Alerting theo symptoms + playbook
- IaC chuẩn hoá
- Canary/blue-green
- Security scanning
Kết
DevOps thực tế là hành trình “tối ưu liên tục”. Bạn không cần làm hết trong 1 tuần. Chỉ cần mỗi sprint cải thiện một chút: giảm rủi ro deploy, giảm thời gian debug, và giảm số lần trực đêm.
Nếu bạn muốn, mình có thể viết phần 2: một template CI/CD và checklist SRE cho team nhỏ (startup) vs team lớn (enterprise).
Top comments (0)