Mối quan hệ đúng đắn giữa các số liệu rollback / rollforward và MTTR là gì?

Tôi đang cố gắng hiểu cách tốt nhất để thu thập dữ liệu để bắt đầu đo các số liệu Thời gian sửa chữa trung bình (MTTR) và tôi cần phải xoay quanh việc "rollback" tác động tích cực hay tiêu cực đến MTTR.

cảnh 1

Giả sử đã có giám sát chắc chắn, mã được triển khai gây ra sự cố được phát hiện khá nhanh (MTTI thấp). Tại thời điểm nhận dạng, có hai con đường chính có thể tiến về phía trước (vâng, tôi đang quá đơn giản cho các mục đích thảo luận):

1. Phục hồi việc triển khai, trả lại sự ổn định nhanh chóng, nhưng không có các tính năng dự định trong sản xuất.

2. Chuyển tiếp với các thay đổi bổ sung giải quyết sự cố và giữ cho các tính năng dự định tồn tại.

Trong bối cảnh này, MTTR khá thấp, vì sự ổn định của trang web có thể trở lại khá nhanh. Điều đó nói rằng, kết quả dự định của thay đổi không tồn tại và do đó, mã / tính năng / thay đổi vẫn bị kẹt trong quá trình. Nếu mục tiêu là MTTR thấp, nó dường như khuyến khích roll-back như một cơ chế phục hồi.

Kịch bản 2

Trong kịch bản này, MTTR được đo lường nghiêm ngặt bằng cách mất bao lâu mã / tính năng / thay đổi dự kiến ​​để hoạt động đúng trong sản xuất. Ngay cả khi tôi quay lại, cho đến khi thay đổi mã "cố định" của tôi chuyển sang prod, bộ đếm thời gian MTTR vẫn chạy. Trong trường hợp này, MTTR dường như gắn liền với sự ổn định kết quả kinh doanh thay vì chỉ đơn thuần là "hey, mọi thứ ổn định".

Bây giờ, câu trả lời có thể đơn giản như MTTR không được sử dụng như một thước đo trong chân không, mà kết hợp với Tỷ lệ thất bại thay đổi - một MTTR siêu thấp gây ra bởi các lần quay vòng thường xuyên có thể dẫn đến Tỷ lệ thất bại thay đổi cao ngất trời. Điều đó nói rằng, có một cái gì đó dường như không đúng với tôi trong ý tưởng chia rẽ phép đo MTTR khỏi kết quả kinh doanh.

Tôi có thể đang xem xét lại điều này, nhưng tôi tò mò về cách những người khác đang đo MTTR và thời điểm cuối cùng là gì để "phục hồi". Bạn có đang sử dụng nó đơn giản như sự ổn định hay các yếu tố khác quyết định "thu hồi" nghĩa là gì?

Có, MTTR luôn / nên luôn gắn liền với kết quả kinh doanh: nếu mọi thứ không ổn định, chính doanh nghiệp sẽ gặp rủi ro.

Thực tế là mã / tính năng / thay đổi dự kiến ​​vẫn bị kẹt trong quy trình trong kịch bản 1 là không phù hợp: tính năng này không ổn định, do đó, nó không mang lại doanh nghiệp mới, phục hồi là cách tốt nhất bạn có thể làm lúc đó từ doanh nghiệp tương lai.

Điểm nổi bật là một canh bạc: khiến doanh nghiệp gặp rủi ro khi chờ đợi một giải pháp tiềm năng mà trên thực tế có những thay đổi thành công thấp hơn về mặt thống kê (do sự không ổn định, nó sẽ luôn luôn vội vàng so với thay đổi gây ra sự bất ổn ngay từ đầu mà không cần phải có áp lực như vậy vào nó). Rollforward là một phiên bản mã khác chưa được kiểm tra trước đó.

Nếu bạn muốn giữ MTTR ở mức thấp, bạn có thể quay lại ngay lập tức mà không cần tranh luận. Điều này loại bỏ rủi ro kinh doanh và cho bạn cơ hội kiểm tra xem bản sửa lỗi có thực sự hoạt động hay không trước khi thử triển khai nó. Tôi thực sự khuyên bạn nên biến nó thành một chính sách như có, hầu như luôn luôn có ai đó yêu cầu sửa chữa thay vì quay lại và gọi một cuộc họp để phân tích / quyết định về nó - tất cả trong khi kinh doanh vẫn gặp rủi ro.

Lưu ý bên lề: nếu bạn quan tâm đến Tỷ lệ thất bại thay đổi cao thì tôi khuyên bạn nên kiểm tra tỷ lệ rollback thực tế thay vì lấy nó từ MTRR thấp. Có lẽ bạn muốn thêm một kiểm tra cổng trước khi triển khai cho các lỗi thường xuyên nhất. Nếu bạn đã kiểm tra như vậy đã được tự động hóa - tại sao không đưa nó vào xác minh CI? Nếu bạn không có - có lẽ đã đến lúc bắt đầu nghĩ về nó? :)

Thời gian trung bình để phục hồi có một chủ đề ngụ ý - thời gian trung bình để phục hồi là gì ? Xác định điều này là chìa khóa để sử dụng số liệu một cách hiệu quả.

Bạn đang phục hồi tính khả dụng chung của trang web sản xuất của bạn? Bạn đang phục hồi chức năng của một tính năng cụ thể có lỗi trong đó? Một khi bạn biết những gì bạn đang thực sự đo lường, việc đo lường nó sẽ dễ dàng hơn nhiều!

Lực đẩy chung của câu hỏi của bạn dường như thực sự xoay quanh các mục tiêu cạnh tranh của các tính năng vận chuyển và duy trì độ tin cậy, đó là một trận chiến lâu đời. Theo truyền thống, đó là công việc của các nhà phát triển để thực hiện những điều mới và công việc của hệ thống để ngăn chặn mọi thứ bị phá vỡ, và điều này dẫn đến xung đột giữa các bộ phận, vì sự thay đổi có xu hướng gây ra sự đổ vỡ. Một trong những triết lý liên quan đến DevOps là ý tưởng rằng các nhà phát triển và kỹ sư op nên phối hợp chặt chẽ với nhau để giảm bớt căng thẳng này.

Bạn cũng có thể quan tâm đến cách tiếp cận của Google đối với vấn đề đó, đó là có "ngân sách lỗi" để các nhóm phát triển chi tiêu; một khi họ đã phạt sự ổn định quá nhiều, họ phải dành phần còn lại của quý chỉ làm việc cho sự ổn định. Cùng với điều này, các kỹ sư độ tin cậy của trang web có các mục tiêu khả dụng và nếu họ bắn quá mức , họ được khuyến khích để cho nhiều thay đổi hơn thông qua; ý tưởng ở đây là mục tiêu của họ không chỉ đơn giản là duy trì độ tin cậy cao nhất có thể, vì khi đó họ sẽ có động lực để chống lại sự thay đổi trong mọi tình huống.