DevOps 8 — Bảo mật, Vận hành & SRE

Bạn đã biết cách build, đóng gói, triển khai và giám sát ứng dụng qua các bài trước. Nhưng đưa được code lên production mới chỉ là một nửa câu chuyện. Nửa còn lại — và thường là phần khiến người ta mất ngủ lúc 3 giờ sáng — là làm sao để hệ thống an toàn, luôn sống, và phục hồi nhanh khi có sự cố. Bài này đi từ con số 0 đến mức "hero" về ba trụ cột: bảo mật (DevSecOps), khả năng mở rộng & sẵn sàng cao, và kỹ thuật vận hành theo triết lý SRE.

Hãy ghi nhớ một câu thần chú xuyên suốt: bảo mật và độ tin cậy không phải là tính năng bạn gắn vào cuối cùng — chúng là thuộc tính bạn nuôi từ dòng code đầu tiên.

DevSecOps — Dịch chuyển bảo mật sang trái

"Shift left" nghĩa là gì?

Trong mô hình cũ, bảo mật là chốt chặn cuối cùng: đội security audit ứng dụng ngay trước khi go-live, tìm ra lỗ hổng, và bắt dev sửa gấp. Hậu quả là sửa muộn, đắt, và đầy căng thẳng. Một lỗi tìm thấy ở giai đoạn thiết kế rẻ hơn hàng trăm lần so với lỗi tìm thấy ở production.

DevSecOps đảo ngược điều này: đẩy các hoạt động kiểm tra bảo mật về phía trái của vòng đời phần mềm (gần lúc viết code hơn), và tự động hóa chúng trong pipeline CI/CD. Bảo mật trở thành trách nhiệm của mọi người, không chỉ một đội riêng.

Các loại quét tự động trong pipeline

Có bốn nhóm kiểm tra chính, mỗi loại soi một góc khác nhau:

Tích hợp vào CI/CD

Nguyên tắc thực tế: chạy quét nhanh (SAST, dependency scan) ở mỗi pull request để phản hồi tức thì; chạy quét nặng (DAST) định kỳ hoặc trên nhánh chính. Đặt ngưỡng phá build (fail gate) hợp lý — ví dụ chỉ chặn merge khi phát hiện lỗ hổng mức Critical/High, còn mức thấp thì cảnh báo. Nếu chặn mọi thứ, dev sẽ tìm cách bỏ qua, và bảo mật mất tác dụng.

# Ví dụ một stage scan trong GitLab CI
dependency-scan:
  stage: test
  script:
    - trivy fs --severity HIGH,CRITICAL --exit-code 1 .
  allow_failure: false   # Critical/High thì phá build

Mẹo: bật quét lỗ hổng trên image cơ sở (base image) và dùng image tối giản như distroless hoặc alpine để giảm bề mặt tấn công.

Quản lý secret — Đừng bao giờ commit mật khẩu

Vấn đề

Secret là mọi thứ không được lộ: mật khẩu database, API key, chứng chỉ TLS, token. Sai lầm kinh điển và chết người nhất là commit secret vào Git. Một khi đã đẩy lên repo, secret coi như lộ vĩnh viễn — kể cả khi bạn xóa commit sau đó, nó vẫn nằm trong lịch sử và có thể bị bot quét GitHub thu thập trong vài phút.

Các tầng giải pháp

1. Biến môi trường (environment variables) — Mức cơ bản. Code đọc secret từ process.env/os.environ thay vì viết cứng. File .env cho dev local, nhưng phải thêm .env vào .gitignore.

2. Secret manager của nền tảng — Kubernetes Secrets, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault. Tách secret khỏi cấu hình ứng dụng, có phân quyền truy cập.

3. HashiCorp Vault — Mức nâng cao. Vault lưu secret được mã hóa, hỗ trợ secret động (sinh credential database tạm thời, tự hết hạn), xoay vòng (rotation) tự động, và ghi log mọi lần truy cập.

Nguyên tắc vàng

• Không hardcode, không commit, không log secret ra console.
• Xoay vòng định kỳ và xoay ngay khi nghi ngờ rò rỉ.
• Dùng công cụ quét secret như gitleaks hoặc truffleHog trong pre-commit hook và CI để chặn từ gốc.
• Cấp quyền theo phạm vi nhỏ nhất: mỗi dịch vụ chỉ thấy secret nó cần.

Bảo mật mạng

TLS/HTTPS ở khắp nơi

Mọi lưu lượng — cả bên ngoài lẫn nội bộ giữa các dịch vụ — nên được mã hóa bằng TLS. Dùng Let's Encrypt để cấp chứng chỉ miễn phí, tự động gia hạn (qua certbot hoặc cert-manager trên Kubernetes). Bắt buộc HTTPS, redirect mọi HTTP sang HTTPS, và bật HSTS.

Reverse proxy & firewall

Đặt một reverse proxy (Nginx, Traefik, hoặc API Gateway) trước ứng dụng để: kết thúc TLS, giới hạn tốc độ (rate limiting) chống tấn công brute-force/DDoS, ẩn cấu trúc nội bộ, và thêm header bảo mật. Cấu hình firewall để chỉ mở đúng cổng cần thiết — ví dụ chỉ 443 ra Internet, còn cổng database (5432, 3306) tuyệt đối không phơi ra ngoài.

Least privilege & Network Policy

Least privilege (đặc quyền tối thiểu) là nguyên tắc nền tảng: mỗi tài khoản, dịch vụ, container chỉ được cấp đúng quyền tối thiểu để làm việc của nó — không hơn. Container không chạy bằng root. Service account chỉ đọc đúng bucket nó cần.

Trên Kubernetes, NetworkPolicy kiểm soát luồng giao tiếp giữa các pod theo mô hình "default deny" — mặc định cấm hết, rồi mở từng đường cụ thể:

# Chỉ cho pod 'api' nói chuyện với pod 'db'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-api
spec:
  podSelector:
    matchLabels: { app: db }
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: api }
      ports:
        - port: 5432

Scaling — Mở rộng để chịu tải

Dọc vs Ngang

• Scale dọc (vertical / scale up): tăng sức mạnh cho một máy — thêm CPU, RAM. Đơn giản nhưng có trần phần cứng và là điểm chết đơn lẻ. Phù hợp database truyền thống.
• Scale ngang (horizontal / scale out): thêm nhiều bản sao (instance) chạy song song sau một load balancer. Gần như không có trần, chịu lỗi tốt hơn, nhưng đòi hỏi ứng dụng stateless (không lưu trạng thái cục bộ trên từng instance — session để ở Redis/DB chung).

Quy tắc thực dụng: thiết kế stateless ngay từ đầu để scale ngang dễ dàng. Đây là điều kiện tiên quyết cho cloud-native.

Autoscaling

Tự động tăng/giảm số instance theo tải, giúp tiết kiệm chi phí lúc vắng và chịu được lúc cao điểm. Trên Kubernetes:

• HPA (Horizontal Pod Autoscaler): thêm/bớt pod theo CPU, memory, hoặc custom metric (ví dụ độ dài hàng đợi).
• Cluster Autoscaler: thêm/bớt node (máy) khi pod không có chỗ chạy.

Load balancer, CDN, Cache

Ba thành phần phối hợp giảm tải và tăng tốc:

• Load balancer phân phối request đều ra các instance (round-robin, least-connections) và bỏ instance hỏng ra khỏi vòng (qua health check).
• CDN (Content Delivery Network): đặt nội dung tĩnh (ảnh, JS, CSS) ở các điểm gần người dùng trên toàn cầu, giảm độ trễ và tải cho server gốc.
• Cache (Redis, Memcached): lưu kết quả truy vấn đắt đỏ trong bộ nhớ. Nguyên tắc: cache giảm tải database mạnh nhất, nhưng phải xử lý đúng việc vô hiệu hóa cache (cache invalidation) — một trong hai bài toán khó nhất của khoa học máy tính.

High Availability & Disaster Recovery

Tư duy: chấp nhận mọi thứ sẽ hỏng

Phần cứng hỏng, mạng đứt, vùng dữ liệu (region) sập. Hệ thống sẵn sàng cao (HA) được thiết kế để không có điểm chết đơn lẻ (no single point of failure) — luôn có bản dự phòng sẵn sàng tiếp quản.

Các kỹ thuật then chốt

• Replication: nhân bản dữ liệu sang nhiều node/zone. Có thể đồng bộ (an toàn hơn, chậm hơn) hoặc bất đồng bộ (nhanh hơn, có rủi ro mất dữ liệu nhỏ).
• Failover: khi node chính chết, một bản sao tự động được "thăng cấp" thành chính. Có thể tự động hoặc thủ công.
• Backup: sao lưu định kỳ, lưu ở vị trí khác với production. Quan trọng nhất: kiểm tra phục hồi (restore test) thường xuyên — một backup chưa từng được restore thành công thì coi như không có backup.

RTO và RPO

Hai chỉ số định lượng khả năng phục hồi sau thảm họa, và chúng định hình toàn bộ chiến lược của bạn:

• RTO (Recovery Time Objective): Bao lâu để khôi phục dịch vụ sau sự cố? (Ví dụ: 1 giờ.)
• RPO (Recovery Point Objective): Bao nhiêu dữ liệu được phép mất, tính theo thời gian? (Ví dụ: tối đa 5 phút dữ liệu cuối.)

RTO/RPO càng nhỏ thì chi phí càng cao. Hãy chọn con số dựa trên giá trị nghiệp vụ, không phải tham vọng kỹ thuật.

Site Reliability Engineering (SRE)

SRE là cách Google biến vận hành thành một bài toán kỹ thuật phần mềm. Triết lý cốt lõi: dùng code và dữ liệu để quản lý độ tin cậy, thay vì dựa vào nỗ lực thủ công và "anh hùng cứu hỏa".

SLI, SLO và Error Budget

• SLI (Indicator): một số đo thực tế về chất lượng dịch vụ — ví dụ tỷ lệ request thành công, độ trễ p99.
• SLO (Objective): mục tiêu cho SLI — ví dụ "99.9% request thành công trong 30 ngày".
• Error budget (ngân sách lỗi): phần "được phép hỏng". Nếu SLO là 99.9%, thì 0.1% là ngân sách lỗi.

Đây là ý tưởng đẹp nhất của SRE: error budget cân bằng tốc độ phát triển và độ ổn định. Còn ngân sách → đội dev được tự do release tính năng mới nhanh. Hết ngân sách (đã hỏng quá nhiều) → đóng băng tính năng, dồn lực vào ổn định. Không cần tranh cãi cảm tính giữa dev và ops nữa — con số tự quyết định.

Toil — Kẻ thù của SRE

Toil là công việc vận hành lặp đi lặp lại, thủ công, không tạo giá trị lâu dài và có thể tự động hóa (ví dụ: restart service bằng tay, gia hạn chứng chỉ thủ công). SRE đặt mục tiêu giữ toil dưới một ngưỡng (Google: <50% thời gian), phần còn lại dành cho kỹ thuật để diệt tận gốc toil bằng automation.

Postmortem không đổ lỗi (Blameless)

Khi sự cố xảy ra, viết postmortem: mô tả điều gì đã xảy ra, dòng thời gian, nguyên nhân gốc, và hành động khắc phục. Nguyên tắc không đổ lỗi (blameless): tập trung vào hệ thống và quy trình đã cho phép lỗi xảy ra, không phải vào cá nhân. Khi người ta không sợ bị trừng phạt, họ chia sẻ trung thực — và tổ chức mới thực sự học được. Một sự cố là một bài học đắt tiền; lãng phí nó bằng cách đổ lỗi là tệ gấp đôi.

On-call

Chế độ trực sự cố. SRE lành mạnh nghĩa là: lịch trực công bằng, có runbook rõ ràng cho từng loại cảnh báo, cảnh báo phải có thể hành động (không spam báo động giả gây "alert fatigue"), và sau mỗi ca trực mệt mỏi thì cải tiến để lần sau nhẹ hơn.

Chaos Engineering (giới thiệu)

Chaos engineering là chủ động tiêm lỗi vào hệ thống production (hoặc gần production) để kiểm chứng nó thực sự chịu lỗi như thiết kế — tắt ngẫu nhiên một instance, thêm độ trễ mạng, lấp đầy ổ đĩa. Tiên phong là Netflix Chaos Monkey. Triết lý: thà tự gây ra lỗi nhỏ có kiểm soát vào giờ hành chính, còn hơn để lỗi lớn tự nổ lúc 3 giờ sáng. Bắt đầu nhỏ, có "blast radius" giới hạn, và luôn có nút dừng.

Checklist vận hành production

Trước khi tự tin đưa hệ thống ra thật, soi qua danh sách này:

Bảo mật

• Quét SAST + dependency + container đã bật trong CI, có fail gate cho Critical/High.
• Không có secret nào trong Git; secret nằm ở Vault/secret manager.
• TLS bật ở mọi endpoint; chứng chỉ tự động gia hạn.
• Firewall mở tối thiểu; database không phơi ra Internet.
• Container chạy non-root; least privilege cho mọi service account.

Độ tin cậy & Scaling

• Ứng dụng stateless, scale ngang được; autoscaling đã cấu hình.
• Load balancer có health check; không có điểm chết đơn lẻ.
• Cache & CDN cho nội dung phù hợp.
• Replication bật; failover đã được test thật.

Disaster Recovery

• Backup tự động, lưu ở vị trí tách biệt.
• Đã restore thử backup thành công gần đây.
• RTO/RPO được định nghĩa và khớp nhu cầu nghiệp vụ.

Vận hành & SRE

• SLO và error budget được định nghĩa và theo dõi.
• Monitoring + alerting hành động được, không spam.
• Runbook cho mỗi cảnh báo; lịch on-call rõ ràng.
• Quy trình postmortem blameless đã có.

Tóm tắt

Bảo mật và độ tin cậy là thuộc tính phải được nuôi từ đầu, không phải gắn vào cuối. DevSecOps đẩy kiểm tra bảo mật (SAST, DAST, dependency scan) vào pipeline và tự động hóa chúng. Quản lý secret đúng cách — không bao giờ commit, dùng Vault/secret manager, xoay vòng — là phòng tuyến cơ bản nhất. Bảo mật mạng dựa trên TLS khắp nơi, reverse proxy, firewall và least privilege. Về độ tin cậy: scaling ngang với ứng dụng stateless và autoscaling giúp chịu tải; HA & DR với replication, failover, backup (đã test restore) cùng RTO/RPO rõ ràng giúp sống sót qua thảm họa. Cuối cùng, SRE biến vận hành thành kỹ thuật: SLO/error budget cân bằng tốc độ và ổn định, diệt toil bằng automation, postmortem blameless để học hỏi, và chaos engineering để chủ động kiểm chứng sức chịu đựng.

Tự kiểm tra

1. "Shift left" trong DevSecOps nghĩa là gì, và tại sao tìm lỗ hổng sớm lại rẻ hơn?
2. Phân biệt SAST, DAST và dependency scan — mỗi loại soi điều gì?
3. Vì sao tuyệt đối không được commit secret vào Git, kể cả khi xóa sau đó? Vault giải quyết vấn đề này thế nào?
4. RTO và RPO khác nhau ở điểm nào? Cho ví dụ một con số cho mỗi chỉ số.
5. Error budget hoạt động ra sao để cân bằng giữa phát triển tính năng và độ ổn định?
6. Tại sao postmortem phải "không đổ lỗi", và điều đó mang lại lợi ích gì cho tổ chức?

Đọc tiếp

Đây là bài cuối của loạt DevOps zero-to-hero. Để nhìn lại bức tranh tổng thể và xâu chuỗi các khái niệm, hãy quay lại DevOps 1 — Giới thiệu. Nếu bạn muốn ôn lại nền tảng đã dẫn tới bài này, gợi ý xem lại các chủ đề về CI/CD và container/orchestration trong những bài trước của loạt, vì chính chúng là nơi bạn tích hợp các bước quét bảo mật và cấu hình autoscaling mà bài này mô tả.