Đọc DORA Metrics thời AI: Vì sao không được đo Tốc độ đơn độc? 

Deploy tăng 30%, rollback tăng 50%: thay đổi tư duy đọc DORA metrics khi việc tạo code quá nhanh và dễ dàng với AI 

AI đang được sử dụng để viết code ngày càng nhiều, tốc độ cũng ngày càng nhanh. Đối với vai trò quản lý kỹ thuật hiện nay hầu hết đã từng hoặc sẽ sớm gặp tình huống này: trong hai kỳ có cùng độ dài, một dịch vụ tăng từ 100 lên 130 lần triển khai, nhưng số deployment phải rollback cũng tăng từ 10 lên 15. Người phụ trách phát triển (VP Engineering) nhận định kết quả này là một thành công: tốc độ tăng rõ rệt, còn rollback là "chi phí học hỏi" tạm thời nên cần nhân rộng mô hình ngay. Người phụ trách độ tin cậy (SRE) thì ngược lại, xem đây là tín hiệu báo động hệ thống đang xuống cấp và phải rà soát gấp trước khi có sự cố lớn.  Những tranh luận ngược chiều cho cùng kết quả tương tự này đang diễn ra ở các đội ngũ kỹ thuật khắp thế giới, từ báo cáo DORA của Google đến các bộ benchmark hàng triệu pull request. 

Một người có kinh nghiệm vận hành sẽ hiểu rằng số lần triển khai tăng cùng số lần rollback chưa đủ để kết luận AI đang giúp hay làm khó đội ngũ lập trình, mà cần phân biệt lượng công việc, tỷ lệ triển khai thất bại và mức ảnh hưởng tới người dùng trước khi quyết định mở rộng. Trong ví dụ giả định bên trên, số deployment phải rollback tăng 50%, còn tỷ lệ tăng từ 10% lên 11,54%: chênh 1,54 điểm phần trăm, tương đương tăng khoảng 15,4% tương đối. Phép tính là (1,5 / 1,3 − 1) × 100%. Hai mức tăng mô tả hai khía cạnh khác nhau: tổng số lần cần xử lý và tỷ lệ deployment cần hoàn tác. Kết quả phép tính không thể hiện được bản chất của ảnh hưởng bởi vì 15 lần rollback tự động, ít tác động tới người dùng có thể tạo gánh nặng khác hẳn 10 lần khôi phục kéo dài.  

Để đánh giá hiệu quả của AI, chúng ta còn phải biết những deployment tăng thêm mang lại thay đổi gì và đội ngũ tốn bao nhiêu công sức để đưa chúng vào vận hành. 

Báo cáo DORA 2025 phơi bày sự ảo tưởng về năng suất khi dùng AI 

Báo cáo DORA 2024 ¹ đi ngược kỳ vọng của nhóm nghiên cứu: cứ mỗi 25% tăng mức áp dụng AI đi kèm mức giảm ước tính 1,5% ở throughput (tốc độ/lưu lượng bàn giao) và 7,2% ở delivery stability (độ ổn định phân phối). Trong khi AI giúp tăng năng suất cá nhân (viết code, làm tài liệu), nó lại gây tắc nghẽn ở quy trình kiểm thử/review và đưa code lên hệ thống thật, dẫn tới tốc độ bàn giao chung bị chậm đi nhẹ và độ lỗi/bất ổn định tăng lên. 

Báo cáo DORA 2025 (State of AI-assisted Software Development)² ghi nhận bước ngoặt lớn: việc áp dụng AI đã thực sự giúp tăng tốc độ bàn giao (throughput chuyển từ âm sang dương). Tuy nhiên, mức áp dụng AI vẫn tỉ lệ thuận với tỷ lệ thất bại khi thay đổi (CFR), nghĩa là AI giúp làm nhanh hơn nhưng hệ thống vẫn kém ổn định như trước.  

Một năm nâng cấp công cụ AI giúp tăng tốc bàn giao nhưng lại không giảm bớt lỗi hệ thống, chứng minh rằng nguyên nhân không nằm ở chất lượng công cụ kém hoặc lỗi do lập trình viên “chưa quen tay", mà do quy trình vận hành hiện tại có lỗ hổng về mặt kiến trúc. 

Bất ổn luôn tồn tại nếu quy trình vận hành kiểm thử của con người không theo kịp tốc độ viết code của AI 

Trước khi có AI, viết code là khâu tốn thời gian nhất (bottleneck). Lập trình viên mất nhiều giờ suy nghĩ, viết từng dòng nên họ hiểu rất rõ logic code của mình. Khi họ tạo PR (Pull Request), dung lượng PR nhỏ và dễ review. Khi đưa AI vào làm việc, AI giúp sinh hàng trăm dòng code chỉ trong vài giây. Tuy nhiên, quy trình review code (kiểm thử tự động, đọc hiểu logic, đánh giá bảo mật, chạy thử) vẫn tốn dung lượng bộ nhớ/thời gian suy nghĩ của con người. Việc bơm một lượng code cực lớn vào một quy trình kiểm duyệt có năng lực giới hạn sẽ tự động tạo ra nút nghẽn (bottleneck) mới và bỏ sót lỗi ra môi trường thật. Dữ liệu benchmark độc lập của LinearB (báo cáo benchmark 2026), phân tích 8,1 triệu pull request từ khoảng 4.800 team kỹ thuật tại 42 quốc gia, chỉ đích danh nút nghẽn. PR có AI hỗ trợ chỉ đạt tỷ lệ merge 32,7% trong 30 ngày, so với khoảng 84,5% của PR người viết. Thời gian chờ được review dài gần 5 lần (khoảng 960 phút so với ~200 phút), và PR cũng lớn hơn hẳn: từ 400 dòng trở lên so với 157 dòng ở phân vị 75. Chi phí tạo code đã sụp xuống, còn chi phí kiểm chứng thì không. 

Bản chất Mô hình Ngôn ngữ Lớn (LLM): AI sinh code bằng cách dự đoán từ tiếp theo dựa trên xác suất, không phải bằng tư duy logic hệ thống. Code do AI tạo ra có thể trông rất "mượt" và chạy đúng ở các case cơ bản (happy path), nhưng dễ bỏ qua các trường hợp biên (edge cases), ngoại lệ bảo mật hay tính tương thích với hạ tầng hiện có. Nếu đưa AI vào quy trình theo kiểu "ủy thác viết code" mà không nâng cấp quy trình kiểm thử tương ứng, hệ thống sẽ liên tục dung nạp các đoạn code tiềm ẩn lỗi ngầm. 

Việc đọc hiểu và phát hiện lỗi trong 500 dòng code do AI viết tốn nhiều năng lượng não bộ hơn rất nhiều so với việc review code do đồng nghiệp tự tay viết. Chính DORA chỉ ra cơ chế: thời gian tiết kiệm ở khâu viết code đã bị dồn sang khâu đánh giá và kiểm chứng, khi có tới 30% kỹ sư thừa nhận họ ít hoặc không tin tưởng code do AI sinh ra.³ Khi xảy ra sự cố trên môi trường vận hành thực tế (production), kỹ sư trực ca (SRE/DevOps) phải sửa những dòng code mà chính họ không hề viết từ đầu, điều này làm kéo dài thời gian xử lý sự cố.  

Tóm lại, Bất ổn định là thuộc tính cấu trúc vì chúng ta đang dùng công cụ của kỷ nguyên AI (sinh code cực nhanh) nhưng lại chạy trên quy trình vận hành của kỷ nguyên cũ (review và test thủ công/bằng con người). Nếu chỉ đẩy mạnh dùng AI để tạo code mà không thay đổi cấu trúc quy trình (như tự động hóa test, chia nhỏ PR, tăng cường AI review), thì tốc độ tăng đến đâu, rủi ro và bất ổn sẽ tăng tương ứng đến đó. 
 

Thay đổi tư duy đọc DORA Metrics từ “đo KPI" sang “đo nút nghẽn" 

Trong bộ 4 chỉ số DORA (2 chỉ số Tốc độ + 2 chỉ số Ổn định), công cụ AI chỉ tác động trực tiếp và làm tăng tức thì đúng 1 chỉ số duy nhất là Tần suất triển khai (Deployment Frequency).  

Bảng phân tích trên giải thích lý do vì sao dashboard ở các buổi review quý thường tạo ra hai góc nhìn trái ngược.  

AI không làm cho DORA metrics vô dụng, nhưng nó bắt chúng ta phải thay đổi hoàn toàn cách đọc. Đọc DORA thời AI không phải để đếm xem team bận rộn ra sao, mà là để nhận diện nút nghẽn đã dịch chuyển về đâu và ngăn chặn rủi ro sập hệ thống trước khi quá trễ. Để nhận diện đúng sức khỏe hệ thống, quản lý kỹ thuật cần thay đổi tư duy khi phân tích báo cáo: 

• Tuyệt đối không đọc đơn độc chỉ số Tốc độ (Deployment Frequency / Lead Time): Bắt buộc phải đọc sóng đôi với Chỉ số Ổn định (Change Failure Rate, hoặc Rework Rate — chỉ số bổ trợ ngoài bộ 4 chỉ số DORA) trên cùng một màn hình quan sát. Việc tách rời hai nhóm chỉ số này sẽ tạo ra "ảo tưởng về tốc độ", che đậy rủi ro tích tụ ở khâu kiểm thử. 

• Tách bạch nguồn dữ liệu (AI vs. Non-AI): Bắt buộc phải đo lường riêng biệt các PR có AI hỗ trợ và PR do con người tự viết hoàn toàn. Nếu gộp chung, lãnh đạo sẽ liên tục rơi vào bẫy "nhiễu" số liệu - nơi các chỉ số trung bình làm mờ đi bản chất vấn đề như ví dụ tranh luận ở đầu bài. 

Áp dụng vào hệ thống của bạn:  

Hãy mở dashboard quản lý hiện tại và đếm xem có bao nhiêu chỉ số tốc độ đang đứng đơn độc mà không có chỉ số ổn định đi kèm. Con số đó sẽ cho bạn biết hệ thống đang thực sự đo sức khỏe vận hành, hay chỉ đang "đếm dòng code" cùng AI. 

Nhận diện được nút nghẽn mới chỉ là bước đầu tiên. Làm sao để điều chỉnh quy trình kiểm thử và review code để giải phóng nút nghẽn này mà không làm chậm tốc độ của đội ngũ? Chúng ta sẽ cùng giải bài toán này ở bài viết tiếp theo: "Tái cấu trúc quy trình vận hành khi AI tham gia viết code: 3 nguyên tắc bắt buộc". 

Nguyễn Phương Lan 

Trưởng Phòng Điều Hành Sản Xuất FPT Cloud 

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