DevOps là gì? Quy trình, CI/CD, văn hoá và DORA metrics

Mục lục

1. DevOps là gì?
2. DevOps ra đời từ đâu?
3. Văn hoá DevOps gồm những gì?
4. Quy trình DevOps gồm những giai đoạn nào?
5. CI/CD là gì?
6. Bộ công cụ DevOps gồm những nhóm nào?
7. DORA metrics là gì?
8. AI đang thay đổi DevOps như thế nào?
9. DevSecOps là gì?
10. DevOps và Agile khác nhau thế nào?
11. DevOps, SRE và platform engineering khác nhau ra sao?
12. DevOps engineer là gì và cần kỹ năng gì?
13. Lợi ích và thách thức của DevOps là gì?
14. Doanh nghiệp nên bắt đầu DevOps từ đâu?
15. Những sai lầm phổ biến khi làm DevOps
16. Câu hỏi thường gặp

DevOps là gì?

DevOps là từ ghép của Development (phát triển phần mềm) và Operations (vận hành hệ thống). Đây là tập hợp văn hoá, nguyên tắc và thực hành giúp hai nhóm vốn tách biệt cùng theo đuổi một mục tiêu: đưa thay đổi đến người dùng nhanh, an toàn và lặp lại được.

Một định nghĩa hay được trích dẫn là của Len Bass, Ingo Weber và Liming Zhu: DevOps là các thực hành nhằm rút ngắn thời gian từ lúc một thay đổi được commit đến khi nó chạy trên môi trường thật (production), đồng thời vẫn bảo đảm chất lượng cao. Vế sau quan trọng không kém vế trước. Nhanh mà hay sập thì không phải DevOps.

DevOps không phải một công cụ để mua, cũng không chỉ là một chức danh. Việc vận hành vẫn còn, chỉ được chia sẻ, tự động hoá và tính đến ngay từ lúc thiết kế.

Ví dụ minh hoạ. Một công ty thương mại điện tử phát hành mỗi tháng một lần, hôm phát hành thường lỗi vì môi trường thật khác máy lập trình viên. Sau khi áp dụng DevOps, mỗi thay đổi nhỏ được kiểm thử tự động, môi trường được mô tả bằng mã nên giống hệt nhau, đội phát hành vài lần mỗi tuần và quay lui (rollback) bản lỗi trong vài phút.

DevOps ra đời từ đâu?

Trong nhiều năm, phát triển và vận hành có mục tiêu ngược nhau. Đội phát triển được đánh giá bằng tính năng mới nên muốn thay đổi nhiều. Đội vận hành được đánh giá bằng độ ổn định nên muốn thay đổi ít. Phần mềm bị “ném qua tường” kèm tài liệu cài đặt. Khi Agile giúp đội phát triển làm nhanh hơn, nút thắt dồn sang khâu triển khai và vận hành.

• 2008: Patrick Debois trình bày chủ đề “Agile Infrastructure and Operations” tại hội nghị Agile 2008 ở Toronto.
• Tháng 6/2009: John Allspaw và Paul Hammond (Flickr) trình bày “10+ Deploys per Day: Dev and Ops Cooperation at Flickr” tại hội nghị Velocity, cho thấy triển khai hơn 10 lần mỗi ngày là khả thi khi Dev và Ops hợp tác.
• 2009: Patrick Debois tổ chức devopsdays đầu tiên tại Ghent (Bỉ); từ “DevOps” lan rộng từ đây.
• 2018: Sách Accelerate của Nicole Forsgren, Jez Humble và Gene Kim ra mắt, tổng kết nhiều năm khảo sát State of DevOps. Cùng năm, nhóm nghiên cứu DORA (DevOps Research and Assessment) trở thành một phần của Google Cloud.

Văn hoá DevOps gồm những gì?

Nhiều doanh nghiệp bắt đầu bằng việc mua công cụ rồi thất vọng vì không thấy thay đổi. Phần khó nhất của DevOps là văn hoá. Mô hình CALMS, phát triển từ bộ CAMS do John Willis nêu năm 2010 và được Jez Humble thêm chữ L (Lean), là cách gọn nhất để tự kiểm tra.

Chữ	Ý nghĩa	Khi làm đúng	Dấu hiệu chưa đạt
C – Culture (văn hoá)	Dev và Ops chung mục tiêu, chung trách nhiệm	Người viết mã cùng trực sự cố	“Code chạy trên máy em mà, lỗi do server”
A – Automation (tự động hoá)	Tự động hoá build, kiểm thử, triển khai, tạo hạ tầng	Triển khai bằng một nút bấm, lặp lại được	Triển khai theo tài liệu 30 bước làm tay
L – Lean (tinh gọn)	Lô nhỏ, giảm chờ đợi, cải tiến liên tục	Mỗi lần phát hành ít thay đổi	Gom 3 tháng thay đổi vào một đợt
M – Measurement (đo lường)	Quyết định dựa trên số liệu thật	Theo dõi thời gian phát hành, tỷ lệ lỗi	Biết hệ thống lỗi khi khách gọi tổng đài
S – Sharing (chia sẻ)	Chia sẻ kiến thức, công cụ, bài học	Bài học sau sự cố được công khai	Chỉ một người biết cách triển khai

Gene Kim bổ sung “Ba con đường” (The Three Ways), công bố năm 2012: tối ưu dòng chảy của toàn hệ thống thay vì từng phòng ban; rút ngắn và khuếch đại vòng phản hồi; nuôi dưỡng văn hoá thử nghiệm và học hỏi liên tục.

Quy trình DevOps gồm những giai đoạn nào?

Quy trình DevOps thường được vẽ thành vòng lặp hình số 8 nằm ngang. Điểm cốt lõi là không có điểm kết thúc: dữ liệu giám sát từ môi trường thật quay về làm đầu vào cho lần lập kế hoạch tiếp theo.

Giai đoạn	Việc chính	Đầu ra
1. Plan	Chọn việc ưu tiên, chia thành thay đổi nhỏ	Backlog đã sắp xếp
2. Code	Viết mã, review chéo, lưu vào quản lý phiên bản	Commit trên nhánh chính
3. Build	Biên dịch, đóng gói	Gói phần mềm hoặc container image có phiên bản
4. Test	Kiểm thử tự động: đơn vị, tích hợp, bảo mật	Kết quả đạt hoặc không đạt
5. Release	Đánh dấu bản sẵn sàng, duyệt nếu cần	Bản phát hành được phê duyệt
6. Deploy	Đưa lên production, thường từng phần để giảm rủi ro	Phiên bản mới đang chạy
7. Operate	Mở rộng tài nguyên, sao lưu, xử lý sự cố	Hệ thống chạy ổn định
8. Monitor	Theo dõi log, chỉ số, truy vết, trải nghiệm người dùng	Cảnh báo và dữ liệu cho vòng sau

CI/CD là gì?

CI/CD là bộ thực hành tự động hoá từ lúc lập trình viên đẩy mã đến lúc mã chạy trên production. Cụm từ này gồm ba khái niệm hay bị dùng lẫn:

• CI – Continuous Integration (tích hợp liên tục): theo Martin Fowler, mỗi thành viên gộp thay đổi của mình vào nhánh chính cùng thay đổi của đồng đội ít nhất mỗi ngày một lần. Mỗi lần gộp đều được build và kiểm thử tự động; hỏng thì sửa ngay.
• CD – Continuous Delivery (phân phối liên tục): phần mềm luôn ở trạng thái có thể phát hành bất cứ lúc nào. Phát hành khi nào là quyết định kinh doanh, thường do một người bấm duyệt.
• CD – Continuous Deployment (triển khai liên tục): mọi thay đổi vượt qua toàn bộ kiểm thử tự động được đưa thẳng lên production, không cần người duyệt.

Không phải doanh nghiệp nào cũng cần triển khai liên tục. Ngân hàng, bảo hiểm hay hệ thống cần kiểm toán thường dừng ở phân phối liên tục, giữ một bước duyệt cuối. Bước duyệt đó nên chỉ là một nút bấm trên bản đã kiểm thử.

Ba thực hành giúp CI/CD chạy tốt:

• Lô nhỏ và kiểm thử nhanh: thay đổi nhỏ dễ review, dễ quay lui; pipeline nên trả kết quả trong vài phút để lập trình viên còn nhớ mình vừa sửa gì.
• Build một lần, triển khai nhiều nơi: cùng một gói đi qua staging rồi production, chỉ khác cấu hình.
• Tách triển khai khỏi phát hành: dùng cờ tính năng (feature flag) để đưa mã lên nhưng chưa bật; triển khai canary (cho một phần nhỏ người dùng dùng trước) hoặc blue-green (chạy song song bản cũ và mới rồi chuyển lưu lượng).

Bên cạnh CI/CD, hệ thống DevOps trưởng thành thường có hạ tầng dưới dạng mã (Infrastructure as Code – IaC), container, khả năng quan sát (observability: log, chỉ số, truy vết) và chính sách dưới dạng mã (policy as code). Vì cần hạ tầng cấp phát được bằng lệnh, DevOps thường đi cùng điện toán đám mây, dù vẫn áp dụng được cho hạ tầng tại chỗ.

Bộ công cụ DevOps gồm những nhóm nào?

Hãy chọn công cụ theo nhóm chức năng, không theo tên sản phẩm. Ví dụ trong bảng chỉ là công nghệ phổ biến để dễ hình dung, không phải khuyến nghị.

Nhóm công cụ	Vai trò	Ví dụ công nghệ phổ biến
Quản lý phiên bản	Lưu mã, lịch sử thay đổi, review	Git
Máy chủ CI/CD	Chạy pipeline build, kiểm thử, triển khai	Jenkins, tính năng CI trong nền tảng Git
Container và điều phối	Đóng gói, chạy, tự phục hồi ứng dụng	Container image, Kubernetes
Hạ tầng dưới dạng mã	Tạo và cấu hình hạ tầng bằng mã	Terraform, OpenTofu, Ansible
Giám sát và quan sát	Chỉ số, log, truy vết, cảnh báo	Prometheus, Grafana, OpenTelemetry
Bảo mật trong pipeline	Quét mã, thư viện, container, bí mật lộ	Công cụ SAST, SCA, quét image

DORA metrics là gì?

DORA metrics là bộ chỉ số đo hiệu quả phân phối phần mềm của chương trình nghiên cứu DORA. Báo cáo năm 2024 cho biết DORA đã thu thập ý kiến từ hơn 39.000 người làm công nghệ qua hơn một thập kỷ. Ban đầu có 4 chỉ số. Từ báo cáo 2024, DORA thêm tỷ lệ làm lại (rework rate) và chia 5 chỉ số thành hai nhóm:

Nhóm	Chỉ số	Định nghĩa theo DORA
Throughput (tốc độ)	Change lead time	Thời gian từ khi thay đổi được commit đến khi được triển khai lên production
	Deployment frequency	Số lần triển khai trong một khoảng thời gian, hoặc khoảng cách giữa hai lần triển khai
	Failed deployment recovery time	Thời gian khôi phục khi một lần triển khai bị lỗi và cần can thiệp ngay
Instability (độ bất ổn)	Change fail rate	Tỷ lệ lần triển khai cần can thiệp ngay sau đó, thường bằng quay lui hoặc vá nóng (hotfix)
	Rework rate	Tỷ lệ lần triển khai ngoài kế hoạch, phải làm do sự cố trên production

Mức tham chiếu theo báo cáo DORA 2024

Báo cáo Accelerate State of DevOps 2024 (công bố tháng 10/2024) là bản gần nhất còn chia người trả lời thành 4 mức dựa trên 4 chỉ số gốc:

Mức	Lead time	Tần suất triển khai	Tỷ lệ lỗi	Khôi phục	Tỷ lệ người trả lời
Elite	Dưới 1 ngày	Theo nhu cầu, nhiều lần mỗi ngày	5%	Dưới 1 giờ	19%
High	1 ngày – 1 tuần	Mỗi ngày đến mỗi tuần	20%	Dưới 1 ngày	22%
Medium	1 tuần – 1 tháng	Mỗi tuần đến mỗi tháng	10%	Dưới 1 ngày	35%
Low	1 – 6 tháng	Mỗi tháng đến 6 tháng	40%	1 tuần – 1 tháng	25%

Nhóm Medium có tỷ lệ lỗi thấp hơn nhóm High vì chậm hơn nhưng ổn định hơn. DORA khuyên các đội cải thiện so với chính mình thay vì cố đạt nhãn “Elite”.

Báo cáo DORA 2025 thay đổi gì?

Báo cáo State of AI-assisted Software Development công bố ngày 23/09/2025 là bản mới nhất tại thời điểm viết. Báo cáo dựa trên khảo sát gần 5.000 người làm công nghệ (từ 13/6 đến 21/7/2025) cùng hơn 100 giờ dữ liệu định tính. Thay cho 4 mức, DORA phân cụm thành 7 kiểu đội, kết hợp chỉ số phân phối với kiệt sức (burnout), ma sát công việc và hiệu quả sản phẩm:

Kiểu đội (tên gốc)	Đặc điểm chính	Tỷ lệ
Foundational challenges	Ở chế độ “sống sót”, thiếu hụt lớn về quy trình và môi trường	10%
The legacy bottleneck	Luôn chữa cháy; hệ thống thiếu ổn định chi phối công việc	11%
Constrained by process	Hệ thống ổn định nhưng công sức bị quy trình kém hiệu quả tiêu tốn	17%
High impact, low cadence	Sản phẩm giá trị cao nhưng phát hành thưa, độ bất ổn cao	7%
Stable and methodical	Làm sản phẩm chất lượng với nhịp độ thong thả, bền vững	15%
Pragmatic performers	Giao việc nhanh và ổn định, dù mức gắn kết chưa đạt đỉnh	20%
Harmonious high-achiever	Tốt trên nhiều mặt; ít kiệt sức và ma sát	20%

AI đang thay đổi DevOps như thế nào?

Số liệu chính từ báo cáo DORA 2025:

• 90% người được khảo sát dùng AI trong công việc, tăng 14% so với năm trước; trung vị khoảng 2 giờ mỗi ngày.
• Hơn 80% cho rằng AI giúp họ năng suất hơn; 59% thấy AI tác động tích cực đến chất lượng mã. Nhưng 30% gần như không tin hoặc chỉ tin chút ít vào mã AI tạo ra.
• Khác năm 2024, dùng AI nay gắn với tốc độ phân phối cao hơn, nhưng vẫn gắn với độ bất ổn cao hơn.
• 90% tổ chức đã áp dụng ít nhất một nền tảng nội bộ (platform engineering); chất lượng nền tảng gắn trực tiếp với khả năng khai thác giá trị từ AI.

Kết luận then chốt của DORA: AI là “bộ khuếch đại”, làm mạnh thêm điểm mạnh của tổ chức tốt và làm lộ rõ điểm yếu của tổ chức đang gặp khó. Mô hình năng lực AI của DORA gồm 7 yếu tố: quan điểm rõ ràng về dùng AI, hệ sinh thái dữ liệu lành mạnh, dữ liệu nội bộ AI truy cập được, quản lý phiên bản chặt chẽ, làm việc theo lô nhỏ, lấy người dùng làm trung tâm và nền tảng nội bộ chất lượng. Nói đơn giản: nếu pipeline chưa có kiểm thử tự động tốt, trợ lý viết mã chỉ giúp đẩy thay đổi chưa kiểm chứng xuống production nhanh hơn.

DevSecOps là gì?

DevSecOps là DevOps có bảo mật (Security) được đưa vào mọi giai đoạn của vòng lặp, thay vì để đội bảo mật kiểm tra ở cuối. Ý tưởng này gọi là “dịch trái” (shift left): kiểm tra sớm, nơi sửa lỗi rẻ hơn nhiều. Các bước phổ biến trong pipeline gồm quét mã tĩnh (SAST), phân tích thư viện mã nguồn mở có lỗ hổng (SCA) kèm danh mục thành phần phần mềm (SBOM), quét bí mật bị lỡ đưa vào kho mã, kiểm thử động (DAST) trên staging và quét cấu hình container, hạ tầng dưới dạng mã.

Về khung tham chiếu, nhiều tổ chức dùng Khung phát triển phần mềm an toàn (SSDF) phiên bản 1.1 của Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ (NIST), tài liệu SP 800-218 ban hành ngày 03/02/2022, áp dụng được cho mọi mô hình vòng đời phần mềm. DevSecOps là một mảnh trong bức tranh an ninh mạng doanh nghiệp, khác ở chỗ gắn bảo mật vào chính dây chuyền làm phần mềm.

DevOps và Agile khác nhau thế nào?

DevOps và Agile không đối lập. Agile giúp đội phát triển làm theo vòng lặp ngắn và phản hồi nhanh với người dùng; DevOps mở rộng tinh thần đó sang khâu phát hành và vận hành. Nếu cần nền tảng, bạn có thể đọc thêm về tuyên ngôn và 12 nguyên tắc Agile hoặc khung Scrum với sprint và các sự kiện.

Tiêu chí	Agile	DevOps
Vấn đề giải quyết	Khoảng cách giữa khách hàng và đội phát triển	Khoảng cách giữa phát triển và vận hành
Phạm vi	Lập kế hoạch và phát triển sản phẩm	Toàn bộ dòng chảy từ mã đến vận hành
Nhịp làm việc	Sprint vài tuần hoặc dòng chảy liên tục	Phát hành liên tục, có thể nhiều lần mỗi ngày
Thực hành chính	Backlog, sprint, demo, nhìn lại	CI/CD, tự động hoá hạ tầng, giám sát, xử lý sự cố
Thước đo điển hình	Giá trị giao cho người dùng	5 chỉ số DORA, độ sẵn sàng hệ thống

DevOps, SRE và platform engineering khác nhau ra sao?

SRE (Site Reliability Engineering) do Ben Treynor Sloss khởi xướng tại Google năm 2003. Theo sách SRE của Google, SRE là “điều xảy ra khi bạn giao cho một kỹ sư phần mềm thiết kế đội vận hành”, và có thể xem là một cách hiện thực DevOps cụ thể. SRE dùng mục tiêu mức dịch vụ (SLO) và ngân sách lỗi (error budget). Ví dụ minh hoạ: SLO 99,9% trong 30 ngày cho phép gián đoạn khoảng 43 phút; dùng hết ngân sách, đội ưu tiên độ ổn định thay vì tính năng mới.

Platform engineering là một đội xây nền tảng nội bộ dạng tự phục vụ (pipeline mẫu, môi trường chuẩn, giám sát sẵn) để các đội sản phẩm tự triển khai mà không phải hiểu hết hạ tầng. Đây là cách mở rộng DevOps khi có nhiều đội.

DevOps engineer là gì và cần kỹ năng gì?

DevOps engineer (kỹ sư DevOps) là người xây và duy trì hệ thống tự động hoá giúp các đội đưa phần mềm lên production nhanh, ổn định, an toàn. Công việc thường ngày gồm thiết kế pipeline CI/CD, viết hạ tầng dưới dạng mã, thiết lập giám sát và cảnh báo, trực và xử lý sự cố, tối ưu chi phí hạ tầng, đưa kiểm tra bảo mật vào pipeline.

Nhóm kỹ năng	Nội dung cần nắm
Nền tảng hệ thống	Linux, mạng (DNS, HTTP, cân bằng tải), phân quyền
Lập trình và script	Ít nhất một ngôn ngữ như Python hoặc Bash để tự động hoá
CI/CD và Git	Chiến lược nhánh, thiết kế pipeline, chiến lược triển khai
Container, đám mây, IaC	Điều phối container, dịch vụ đám mây, khai báo hạ tầng bằng mã
Quan sát và bảo mật	Chỉ số, log, truy vết; quản lý bí mật; quyền tối thiểu
Kỹ năng mềm	Giao tiếp nhiều đội, viết tài liệu, bình tĩnh khi có sự cố

Lợi ích và thách thức của DevOps là gì?

Lợi ích	Thách thức
Ra mắt nhanh hơn, phản ứng kịp thị trường	Thay đổi văn hoá mất thời gian, cần lãnh đạo ủng hộ
Ổn định hơn: thay đổi nhỏ thì rủi ro nhỏ, dễ quay lui	Hệ thống cũ khó kiểm thử tự động, khó tách nhỏ
Khôi phục nhanh nhờ giám sát và quy trình sự cố rõ	Thiếu người hiểu cả phát triển lẫn hạ tầng
Đội ít kiệt sức hơn khi ma sát công việc giảm	Ngành tài chính, y tế cần thiết kế bước duyệt và lưu vết phù hợp

Doanh nghiệp nên bắt đầu DevOps từ đâu?

Lộ trình dưới đây phù hợp với phần lớn doanh nghiệp Việt Nam có đội phần mềm từ vài người đến vài chục người:

1. Đo hiện trạng: chọn một ứng dụng quan trọng, ước lượng 5 chỉ số DORA, tìm chỗ phải chờ lâu nhất.
2. Chọn đội thí điểm: một đội sản phẩm có lãnh đạo ủng hộ, ghép thêm một người vận hành.
3. Đưa mọi thứ vào quản lý phiên bản: mã, kịch bản triển khai, cấu hình máy chủ, lược đồ cơ sở dữ liệu.
4. Dựng CI trước: mỗi commit đều build và chạy kiểm thử; bắt đầu ít nhưng chạy thật, rồi tăng dần.
5. Tự động hoá triển khai: staging trước, production sau, đến khi triển khai chỉ cần một nút bấm.
6. Thêm giám sát, bảo mật và quy trình sự cố: cảnh báo theo trải nghiệm người dùng, quét thư viện và bí mật trong pipeline, họp sau sự cố không đổ lỗi.
7. Nhân rộng bằng nền tảng chung: chuẩn hoá pipeline mẫu để các đội khác dùng lại.

DevOps thường là một phần trong chương trình chuyển đổi số của doanh nghiệp. Với đường ống dữ liệu, cách tiếp cận tương tự được gọi là DataOps.

Những sai lầm phổ biến khi làm DevOps

• Mua công cụ trước, đổi cách làm sau: pipeline không có kiểm thử chỉ tự động hoá việc đưa lỗi lên production.
• Đổi tên đội vận hành thành “đội DevOps”: nếu đội này vẫn nhận mọi yêu cầu triển khai thay các đội khác, bức tường bàn giao vẫn còn.
• Dùng DORA metrics để xếp hạng đội: số liệu sẽ bị làm đẹp và mất giá trị.
• Coi bảo mật là bước cuối: lỗ hổng phát hiện sát ngày ra mắt dễ bị bỏ qua.
• Tưởng AI sẽ thay thế nền tảng: như DORA 2025 chỉ ra, AI khuếch đại cả điểm mạnh lẫn điểm yếu sẵn có.

Câu hỏi thường gặp

DevOps có phải là một nghề không?

DevOps là văn hoá và cách làm, nhưng thị trường tuyển dụng dùng “DevOps engineer” như một chức danh. Người làm tốt vai trò này giúp các đội tự triển khai, chứ không làm thay.

Học DevOps nên bắt đầu từ đâu?

Bắt đầu từ Linux, mạng cơ bản, Git và một ngôn ngữ script, rồi tự dựng trọn một vòng nhỏ: pipeline CI, đóng gói container, triển khai lên đám mây, gắn giám sát. Người từ quản trị hệ thống cần bổ sung lập trình; người từ lập trình cần bổ sung mạng và vận hành.

CI/CD và DevOps có giống nhau không?

Không. CI/CD là nhóm thực hành kỹ thuật nằm trong DevOps, lo phần tự động hoá từ commit đến triển khai. DevOps rộng hơn, gồm cả văn hoá, cách tổ chức đội, vận hành, xử lý sự cố và đo lường.

Doanh nghiệp nhỏ có cần DevOps không?

Có, và thường dễ làm hơn doanh nghiệp lớn vì ít khâu bàn giao. Một đội 3–5 người chỉ cần kho mã chung, pipeline CI đơn giản, triển khai tự động và cảnh báo cơ bản là đã có phần lớn lợi ích.

DevSecOps có làm chậm việc phát hành không?

Nếu làm đúng thì không. Các bước quét tự động chạy trong pipeline và phản hồi trong vài phút. Thứ làm chậm thường là kiểm tra thủ công dồn cuối dự án, dẫn tới hoãn ra mắt vì phát hiện lỗ hổng muộn.