DevOps thực chiến: từ commit code đến production ổn định

DevOps không chỉ là công cụ#

Nhiều người bắt đầu học DevOps bằng cách cài Jenkins, GitHub Actions, Docker, Kubernetes hoặc Terraform. Cách học đó không sai, nhưng nếu chỉ nhớ tên công cụ thì rất dễ bị rối khi hệ thống gặp sự cố. DevOps trước hết là cách tổ chức vòng đời phần mềm để code đi từ máy của developer đến production một cách có kiểm soát, có khả năng lặp lại và có dữ liệu để sửa lỗi nhanh.

Một pipeline DevOps tốt trả lời được các câu hỏi thực tế: ai thay đổi gì, thay đổi đó đã được kiểm tra chưa, artifact nào đang chạy ở production, nếu deploy lỗi thì rollback bằng cách nào, log nằm ở đâu, metric nào báo hệ thống đang khỏe, và secret có bị lộ trong repository hay image không.

Bản đồ vòng đời delivery#

Hãy xem delivery như một chuỗi các checkpoint thay vì một nút deploy duy nhất. Mỗi checkpoint giảm một loại rủi ro khác nhau.

• Commit: code nhỏ, message rõ, gắn với issue hoặc mục tiêu cụ thể.
• Build: tạo artifact có thể chạy lại, không phụ thuộc vào trạng thái máy local.
• Test: chạy unit test, integration test, lint, type check và các kiểm tra bảo mật cơ bản.
• Package: đóng gói image hoặc bundle với version rõ ràng.
• Deploy: đưa artifact đã kiểm tra vào môi trường đích.
• Observe: theo dõi log, metric, trace, alert và hành vi người dùng sau deploy.

Điểm quan trọng là production không nên build lại từ source theo kiểu thủ công. Production nên nhận artifact đã được tạo bởi CI, đã được gắn tag, đã đi qua test và có thể truy vết về commit gốc.

Thiết kế pipeline tối thiểu nhưng đáng tin#

Với một web app nhỏ hoặc vừa, pipeline ban đầu không cần quá phức tạp. Một cấu trúc hợp lý có thể gồm bốn stage: validate, build, security scan và deploy. Validate chạy nhanh để feedback sớm; build tạo artifact; scan bắt lỗi dependency hoặc secret; deploy chỉ chạy khi nhánh và điều kiện phù hợp.

name: delivery

on:
  push:
    branches: [main]
  pull_request:

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npx tsc --noEmit
      - run: npm test --if-present

Pipeline tốt không phải pipeline có nhiều bước nhất. Pipeline tốt là pipeline bắt được lỗi quan trọng trước khi deploy, chạy đủ nhanh để team còn muốn dùng, và không yêu cầu ai phải nhớ thao tác thủ công.

Environment phải giống nhau ở những điểm quan trọng#

Một câu nói quen thuộc là "máy em chạy được". DevOps cố gắng giảm khoảng cách giữa local, staging và production. Không nhất thiết mọi môi trường phải giống 100 phần trăm, nhưng những thứ ảnh hưởng đến hành vi ứng dụng cần được chuẩn hóa: version runtime, biến môi trường, database migration, command start app, network port, quyền truy cập và cấu hình cache.

Docker giúp chuẩn hóa runtime, nhưng Docker không tự giải quyết toàn bộ vấn đề môi trường. Bạn vẫn cần quản lý secret, migration, storage, backup và cách roll back dữ liệu. Một deployment chuyên nghiệp luôn phân biệt rõ configuration và code. Code nằm trong repository; configuration thay đổi theo môi trường; secret không nằm trong Git.

Chiến lược deploy nên phù hợp quy mô#

Không phải dự án nào cũng cần blue-green deployment hoặc canary release ngay từ đầu. Với một blog, CMS, CRM nội bộ hoặc API vừa phải, rolling deploy kèm health check và rollback artifact thường đã đủ tốt. Với hệ thống có traffic lớn hoặc yêu cầu uptime cao, canary giúp đưa phiên bản mới cho một phần nhỏ request trước khi mở rộng.

• Recreate: đơn giản, phù hợp app nhỏ nhưng có downtime ngắn.
• Rolling: thay instance từng phần, giảm downtime, cần health check tốt.
• Blue-green: chạy song song hai môi trường, switch traffic khi bản mới ổn.
• Canary: phát hành theo tỷ lệ nhỏ, quan sát metric rồi tăng dần.

Dù chọn kiểu nào, hãy viết sẵn kế hoạch rollback. Nếu rollback cần 30 phút suy nghĩ khi production đang lỗi, kế hoạch đó chưa đủ tốt.

Log, metric và alert là một phần của feature#

Deploy xong không có nghĩa là hoàn tất. Một thay đổi chỉ thực sự an toàn khi bạn biết nó đang hoạt động như thế nào. Log trả lời "chuyện gì đã xảy ra"; metric trả lời "hệ thống đang khỏe hay yếu"; trace trả lời "request mất thời gian ở đoạn nào"; alert kéo người phụ trách vào đúng lúc cần can thiệp.

Với backend/API, các metric tối thiểu nên có gồm request rate, error rate, latency p95/p99, CPU, memory, database connection, queue depth và số lần restart. Với frontend, hãy theo dõi Web Vitals, lỗi runtime, tỷ lệ request API thất bại và thời gian tải trang chính.

Checklist DevOps cho một dự án web#

• Repository có README mô tả cách chạy local, test và deploy.
• CI chạy lint, type check và test trước khi merge.
• Artifact được gắn tag theo commit SHA hoặc version.
• Secret được lưu trong secret manager hoặc biến môi trường của nền tảng deploy.
• Database migration chạy có kiểm soát và có backup trước thay đổi rủi ro.
• Health check kiểm tra đúng dependency quan trọng, không chỉ trả về 200 giả.
• Log có request id hoặc correlation id để lần theo lỗi.
• Alert tập trung vào triệu chứng người dùng bị ảnh hưởng, không chỉ tài nguyên tăng nhẹ.

Lộ trình học DevOps thực tế#

Nếu bạn là developer muốn nâng cấp tư duy DevOps, hãy học theo thứ tự: Linux cơ bản, Git workflow, Docker, CI/CD, networking nền tảng, reverse proxy, database migration, monitoring, cloud IAM và infrastructure as code. Kubernetes nên học sau khi bạn đã hiểu container, networking, health check và deployment strategy. Nếu nhảy thẳng vào Kubernetes khi chưa hiểu các khái niệm nền, bạn sẽ chỉ nhớ YAML mà không hiểu hệ thống.

DevOps tốt giúp team ship nhanh hơn nhưng không đánh đổi sự ổn định. Mục tiêu cuối cùng không phải là có pipeline đẹp, mà là mỗi thay đổi đều có đường đi rõ ràng, dễ kiểm chứng, dễ rollback và dễ quan sát sau khi lên production.

Nguồn tham khảo chính#

• Docker Docs: Multi-stage builds
• Kubernetes Docs: Deployments
• OWASP API Security Top 10 2023