Đo hệ thống bàn giao phần mềm

Bắt đầu từ quyết định cần đưa ra

Nhóm muốn biết AI có cải thiện bàn giao không. Đếm dòng mã được tạo trả lời câu hỏi khác. Xác định kết quả hữu ích và điều kiện chất lượng trước khi chọn chỉ số.

Với dịch vụ xuất dữ liệu giả định, kết quả mong muốn là bàn giao tin cậy các thay đổi được chấp nhận với ít tổng công sức hơn. Ghi công việc chuẩn bị, thực hiện, review, sửa lại và chờ. Bao gồm thay đổi thất bại hoặc bị bỏ.

Dùng một dịch vụ có ranh giới rõ ràng. Gộp website thử nghiệm với dịch vụ thanh toán quan trọng có thể tạo con số không giải thích được hệ thống nào. Mô tả bối cảnh trước khi so sánh giai đoạn hoặc nhóm.

Dùng định nghĩa hiện hành

Mô hình bàn giao hiện tại của DORA gồm năm chỉ số. Phạm vi là hiệu suất bàn giao, không phải giá trị của mọi chức năng hay đóng góp cá nhân. Định nghĩa chỉ số DORA.

Dashboard có thể dùng định nghĩa khác. Đọc định nghĩa trước khi diễn giải kết quả. Tài liệu triển khai hiện tại của Taiga mô tả bốn chỉ số được báo cáo từ bản ghi triển khai của nhà cung cấp. Phép đo khôi phục dùng lần triển khai thành công tiếp theo. Đó không phải hồ sơ đầy đủ của mọi sự cố production. Định nghĩa của Taiga.

Kiểm tra chuỗi thay đổi giả định

Giả sử dịch vụ có mười hai lần triển khai trong một tháng. Tám lần bàn giao thay đổi có kế hoạch. Bốn lần sửa vấn đề từ bản phát hành trước. Tổng là mười hai, nhưng thành phần rất quan trọng.

Tháng tiếp theo, nhóm có mười lần triển khai: chín thay đổi có kế hoạch và một lần sửa lỗi. Ít lần triển khai hơn vẫn có thể đi cùng nhiều công việc hữu ích hơn. Những con số này minh họa cách diễn giải, không phải chuẩn hiệu suất.

Cũng kiểm tra phân bố. Khoảng chờ review dài có thể biến mất trong số trung bình. Phép đo khôi phục từ một lỗi duy nhất là bằng chứng yếu cho độ tin cậy tương lai. Báo cáo số quan sát và ngoại lệ đáng kể.

Xem luồng bàn giao cùng hậu quả

Dùng tín hiệu dịch vụ để kiểm tra thay đổi bàn giao có ảnh hưởng người dùng không. Pipeline nhanh hơn chưa đủ nếu xuất dữ liệu lỗi thường xuyên hơn. Dùng SLO phù hợp hoặc phép đo kết quả khác được định nghĩa rõ ràng. Hướng dẫn SLO.

Công sức review và làm lại giúp giải thích kết quả. Nếu AI rút ngắn thực hiện nhưng tạo diff lớn, review có thể thành nút thắt. Nếu mất nhiều ngày mới có môi trường, viết mã nhanh hơn có thể ít ảnh hưởng tới tổng thời gian bàn giao.

Chọn một cải tiến xử lý nút thắt đã quan sát. Ví dụ, cung cấp môi trường test được hỗ trợ hoặc giảm kích thước thay đổi. Xác định chỉ số chất lượng đối trọng để nhóm phát hiện mức tăng tốc bề ngoài do kiểm tra bị làm yếu.

Giữ phép đo hữu ích

Tránh xếp hạng cá nhân theo số PR hoặc mã được tạo. Những phép đo này có thể khuyến khích chia việc giả tạo, tránh bảo trì khó hoặc chuyển công sức review sang đồng nghiệp.

Review kết quả cùng những người phụ trách toàn bộ dịch vụ. Ghi điều thay đổi ở công cụ, cơ cấu công việc, nhóm và môi trường. Coi so sánh trước và sau là bằng chứng có giới hạn, không tự động là chứng minh nhân quả.

Mục tiêu là quyết định tiếp theo tốt hơn. Phép đo nhỏ, đáng tin dẫn tới cải tiến đã kiểm chứng hữu ích hơn dashboard lớn không có ý nghĩa được thống nhất.

Thực hành với mười thay đổi

Bộ dữ liệu giả định riêng này ghi mười thay đổi có kế hoạch. Mọi thời gian là UTC theo ngày được ghi. Trường sửa lỗi trống nghĩa là bộ dữ liệu không ghi nhận lần sửa nào.

So sánh thời gian từ mã sẵn sàng tới bắt đầu review, rồi từ chấp nhận tới phát hành. Xác định khoảng chờ dài nhất có thể thấy. Điều tra nguyên nhân trước khi gọi nó là có thể tránh. Các mốc này không đo công sức thực tế hay xác định lúc sự cố bắt đầu. Chỉ bản phát hành sửa lỗi không xác lập thời gian khôi phục sau triển khai thất bại.

Tải bộ dữ liệu giả định (CSV)