Một số phương pháp để đo lường ROI cho DevOps là gì?

DevOps rất phức tạp và liên quan đến nhiều khía cạnh không xác định như văn hóa và quy trình.
Một số cách để đo lường các sáng kiến ​​DevOps để thành công là gì?
Làm thế nào để bạn chứng minh cho một doanh nghiệp rằng khoản đầu tư họ đã thực hiện đang trả lại (hoặc tiết kiệm) đô la thật?

Câu hỏi tuyệt vời! Hầu hết chúng ta đều biết đầu tư vào thực tiễn DevOps là một sự theo đuổi rất đáng giá vì vô số lý do; Mặc dù vậy, chúng tôi thường không biện minh cho DevOps về tác động đến điểm mấu chốt.

Lưu ý : đây là một câu hỏi có ý kiến ​​và câu trả lời của tôi cũng tương tự như vậy.

Tensibai khôn ngoan đề nghị chúng tôi tìm ra số liệu phù hợp và ông đã sử dụng thời gian để tiếp thị làm ví dụ. Đây là một cách tiếp cận hình ảnh lớn tuyệt vời.

Là một cách tiếp cận khác, kinh nghiệm của tôi với máy đếm đậu là họ không cần - hoặc nhất thiết muốn - biết bức tranh lớn, họ chỉ muốn bằng chứng về trách nhiệm tài chính. Họ muốn nhìn thấy một xu hướng đúng hướng.

Đây chỉ là một vài chiến thắng tài chính:

• tính toán chi phí máy chủ được tiết kiệm bằng cách tận dụng tự động nhân rộng trong đám mây
• đối với các trang web tạo thu nhập, ngoại suy chi phí mỗi phút ngừng hoạt động, sau đó hiển thị các cải tiến trong MTTI và MTTR
• một lần nữa, đối với các trang web tạo thu nhập, hãy ước tính chi phí mỗi phút được tiết kiệm bằng cách tận dụng kiến ​​trúc khả dụng cao dựa trên các sự cố trong quá khứ
• nếu bạn đã cải thiện đường ống xây dựng và triển khai của mình, hãy cho thấy rằng bạn đã giảm hồi quy và lỗi trong sản xuất do lỗi đã được theo dõi
• nếu bạn đã cải thiện môi trường thử nghiệm của nhà phát triển, hoặc thậm chí các công cụ và cấu hình trên máy tính xách tay của nhà phát triển, hãy xem lịch sử cam kết để xem liệu các kỹ sư mới có đóng góp đầu tiên sớm hơn sau khi tham gia không
• thực hiện so sánh toàn bộ chi phí giữa đám mây và tại chỗ, giống như Gitlab đã làm gần đây , để biện minh cho chi tiêu cơ sở hạ tầng của bạn (còn gọi là tiết kiệm!)

Cho thấy bạn là người có tiền và bạn có một vài chiến thắng rõ ràng thường là đủ. Tôi chắc chắn đã bỏ lỡ một số ví dụ rõ ràng; hãy thêm ý kiến ​​dưới đây.

Số liệu chính cho một đường ống DevOps là Thời gian chu kỳ (còn được gọi là Thời gian dẫn ). Đây là thời gian cần thiết để thay đổi (hoặc yêu cầu thay đổi, theo dõi tất cả các cách để bắt đầu ý tưởng). Minh họa tốt nhất về khái niệm này mà tôi biết là từ cuốn sách "Mục tiêu", nói về nó trong bối cảnh sản xuất.

Tần suất triển khai cũng hữu ích. Chúng tôi muốn triển khai thường xuyên trong một đường ống DevOps. Không có phép đo "1 ngày là tốt, 2 ngày là xấu"; điều này sẽ cần một bối cảnh lịch sử về dự án của bạn để có ý nghĩa.

Kích thước triển khai : Được đo trong tuy nhiên các nhà phát triển của bạn đo lường công việc - câu chuyện của người dùng, điểm câu chuyện, quatloos, bất cứ điều gì. Một lần nữa, bạn muốn xem xu hướng theo thời gian, không phải giá trị tuyệt đối.

Giữa tần số và kích thước có một câu chuyện để kể. Là bản phát hành của chúng tôi trở nên không thường xuyên và lớn hơn? tại sao? Có phải chúng trở nên nhỏ hơn và thường xuyên hơn? Một lần nữa, tại sao?

Giải thích liệu xu hướng tần số / kích thước có tốt không, chúng tôi cũng sẽ cần Tỷ lệ phần trăm không triển khai . Khám phá "lý do" trong ba số liệu đó sẽ cho bạn biết rất nhiều về sức khỏe của dự án.

Sở thích cá nhân của tôi, mặc dù nó là một số liệu phù phiếm, là Thời gian cho một triển khai tầm thường . Nếu bạn tìm thấy điều nhỏ nhất có thể đáng để triển khai lại toàn bộ trang web ... có lẽ là một lỗi đánh máy trong tên của CEO ... bạn có thể nhanh chóng đi từ cuộc gọi điện thoại hoảng loạn đến một trang web được triển khai như thế nào? Tôi nói 'phù phiếm' bởi vì nó thực sự không phải là dự đoán vượt quá những gì các số liệu khác ở trên thảo luận, nhưng làm cho tôi cảm thấy tốt khi tôi thích giá trị.

Nếu chúng ta theo dõi, có rất nhiều thứ khác nhau mà chúng ta có thể theo dõi ... từ những thứ bao gồm tất cả như ' Thời gian hoạt động ', đến những thứ thực sự ở mức độ thấp như thời gian tái tạo HTML tùy chỉnh theo chu kỳ phản hồi yêu cầu ... nhưng những điều đó không cụ thể để thiết lập một nền văn hóa DevOps.

Chúng không liên kết trực tiếp với đô la ... làm như vậy sẽ đòi hỏi nhiều kiến ​​thức về org của bạn hơn tôi có thể cung cấp trong một diễn đàn như thế này; nhưng chúng là chìa khóa để BEGIN trả lời câu hỏi đó. Một khi bạn biết rằng bạn có thể thường xuyên phát hành công việc vào sản xuất như một sự kiện không, bạn có thể bắt đầu thấy bạn đã lãng phí bao nhiêu công sức trước đây. Như cuốn sách "Mục tiêu" dạy (về việc sản xuất các đường ống - có liên quan), tối ưu hóa cục bộ có thể trông giống như bạn đang tiết kiệm tiền, nhưng cuối cùng, nó chỉ tạo ra giá trị gắn liền với hàng tồn kho (các tính năng không được triển khai).

Ngoài lời khuyên này, bạn nên xem Báo cáo của State Of DevOps trong vài năm qua. Đây là đầy đủ các phép đo về các dự án trong thế giới thực mà bạn có thể mô phỏng.

Captain rõ ràng: bằng cách giảm thời gian tiếp thị và khiếm khuyết trên các bản phát hành.

Để mở rộng trên một lớp lót này, cạm bẫy thông thường là thay đổi tổ chức mà không có bất kỳ tham chiếu nào.

Tham gia vào một sự thay đổi về văn hóa hoặc tổ chức bao hàm một số chi phí để đào tạo và giới thiệu cho mọi người về phương pháp mới này, điều này có chi phí đào tạo nhưng cũng có nghĩa là mất năng suất vì mọi người trong một chuyến tàu sẽ không tạo ra bất cứ điều gì. Đây là phần đầu tư của sự thay đổi văn hóa.

Để đo lường ROI, trước tiên bạn phải tìm một số số liệu có liên quan cần được cải thiện (hiểu chi phí tốn kém, tốn kém hoặc nguồn gốc của tổn thất lợi nhuận). Đây có thể là thời gian ngắn hơn để tiếp thị, ít bản vá hơn sau mỗi lần phát hành, thu hút khách hàng tốt hơn trong sản phẩm của bạn. Các số liệu liên quan sẽ phụ thuộc rất nhiều vào (các) sản phẩm của bạn.

Đo lường ROI (bạn đã trang trải chi phí đào tạo nhanh như thế nào) ngụ ý rằng bạn thực sự có thể trình bày một sự tiến hóa trên các số liệu đó, vì vậy trước khi thực hiện bất kỳ thay đổi nào, bạn phải xác định các số liệu đó và đo lường chúng theo cách khách quan.
Một khi bạn có một sự tiến hóa thực sự để cho thấy bạn có thể biết liệu bạn đã cải thiện điều gì theo cách đã trang trải chi phí đào tạo và trở nên có lợi hơn so với trước đây.

Cạm bẫy thông thường là tham gia vào thay đổi trước khi xác định bất kỳ số liệu nào và do đó đánh giá ROI theo cảm tính chứ không phải trên dữ liệu thực tế.

Năng suất có thể là một số liệu, nhưng phép đo của nó thường rất khó thực hiện theo cách khách quan và không nên là số liệu hạng nhất cho loại nghiên cứu này.

Muộn trò chơi ở đây nhưng nghĩ rằng tôi sẽ hòa nhập.

Bạn không thể quản lý những gì bạn không đo lường, vì vậy, đối với người mới bắt đầu, đây là các nhóm đo lường chính mà các nhóm nên theo dõi để ứng phó sự cố:

• Thời gian hoạt động% : tổng% thời gian khả dụng = [tổng thời gian - thời gian chết] / [tổng thời gian]
• MTTR : thời gian trung bình để giải quyết = [thời gian chết] / [# sự cố]
• MTTA : có nghĩa là thời gian để xác nhận = [tổng thời gian xác nhận] / [# sự cố]
• MTBF : thời gian trung bình giữa các lần thất bại = [tổng thời gian - thời gian chết] / [# sự cố]

Các số liệu này cung cấp cho bạn kiểm tra sức khỏe ở mức độ cao đối với các hoạt động của bạn và giúp bạn xác định nơi bạn cần đào sâu hơn.

Hãy xem hoạt hình bảng trắng ở đây để có cái nhìn sâu hơn về chủ đề này.

Một khi bạn biết số liệu của mình, bạn có thể tăng chúng lên so với chi phí thời gian chết . Bạn có thể bắt đầu xây dựng ROI nhóm của mình từ đó và đặt một số số liệu định lượng để cải tiến liên tục.