Những chỉ số hiệu suất chính (KPI) nào được sử dụng để đo DevOps?

Tôi đang cố gắng điều khiển các hành vi tốt trong chương trình chuyển đổi DevOps, để hỗ trợ điều này, tôi đang xem xét việc xác định các số liệu có thể hành động xung quanh các quy tắc hoạt động:

• Quản lý sự cố và sự cố
• Năng lực quản lý
• Quản lý thay đổi và phát hành

Hoàn toàn rõ ràng, đây là các chức năng từng thuộc về tổ chức hoạt động và hiện thuộc sở hữu của tổ chức Agile / DevOps. Có những KPI hiện có thúc đẩy các hành vi xấu là:

• Đã hoàn thành phân tích nguyên nhân gốc rễ:
  • Ổ đĩa RCAs không đầy đủ chỉ để đưa chúng vào hệ thống đúng giờ.
• Thời gian thực hiện kiểm tra:
  • Vô hiệu hóa các bài kiểm tra chạy dài, bất kể giá trị kinh doanh của họ.
• Sử dụng trung bình các dịch vụ đám mây:
  • Khuyến khích sự cam kết quá mức của các tài nguyên tính toán, dẫn đến thời gian phản hồi chậm

Những chỉ số hiệu suất chính nào có thể được sử dụng để khuyến khích hành vi tốt trong Chương trình DevOps?

Tôi không nghĩ rằng có bất kỳ KPI DevOps "phổ quát" nào. Ví dụ, vận tốc là tuyệt vời, trừ khi nó không phải là động lực chính cho doanh nghiệp của bạn. Amazon quan tâm rất nhiều về vận tốc vì họ có một hoạt động bán lẻ lớn. Điều đó ít quan trọng hơn đối với một ứng dụng nhỏ với 100 người dùng.

Điều này đặt ra câu hỏi: làm thế nào để bạn chọn KPI tốt nhất phù hợp với doanh nghiệp của bạn ? Đó là một quá trình nghiên cứu và khám phá liên quan đến toàn bộ Doanh nghiệp của bạn.

Điều gì làm bạn quan tâm?

• Chất lượng
• độ tin cậy
• Bảo trì
• Vận tốc
• Cải tiến quy trình
• Cấp độ dịch vụ

Điều gì giữ cho các bên liên quan kinh doanh của bạn vào ban đêm? Điều gì quyết định bạn có kiếm được tiền trong quý này hay không? Danh sách trên có thể bao gồm một số trong những điều đó, hoặc có thể không. Lập danh sách của bạn, sau đó tìm ra cách sắp xếp các ưu đãi trên mỗi bộ phận để đạt được chúng.

Ưu đãi thúc đẩy hành vi, do đó quyết định hợp tác về các mục tiêu SMART. Chọn hai hoặc ba mục trong danh sách động não của bạn và bắt đầu một chu trình phản hồi / sửa chữa cho mỗi mục. Đừng chọn quá nhiều cùng một lúc - bạn có nhiều khả năng thành công hơn bằng cách tập trung vào hai hoặc ba điều.

DevOps không có bất kỳ KPI nào . Nó sẽ giống như hỏi KPI của tình yêu là gì. Nhưng một số trong những điều bạn đề cập ( Vấn đề và Incident Management , năng lực quản lý , thay đổi và quản lý phát hành ) làm có tốt KPI, một số trong đó đều dựa trên lý thuyết đằng sau DevOps.

Nói chung, đối với bất kỳ quy trình kinh doanh nào, bạn có thể tạo Bản đồ chuỗi giá trị mô tả cách giá trị chảy từ Khách hàng , thông qua doanh nghiệp trở lại Khách hàng . Toàn bộ vòng lặp luôn phải bắt đầu và kết thúc với Khách hàng, nhưng đôi khi, đối với một tổ chức dịch vụ, Khách hàng có thể là nội bộ. Các thông lượng của giá trị thông qua chuỗi như vậy có thể là một cách tốt để thiết kế KPI của bạn một cách chống trộm. Đo lường bất kỳ KPI nào trong bất kỳ liên kết riêng lẻ nào của chuỗi giá trị chỉ có ý nghĩa miễn là liên kết cụ thể đó là nút cổ chai của quy trình và bạn cố gắng khai thác hoặc nâng cao nút thắt cổ chai.

Một vấn đề phổ biến với KPI là khi nó bắt đầu nửa chừng trong chuỗi. Ví dụ: quy trình Thay đổi và Phát hành thường bắt đầu với các nhà phát triển và kết thúc bằng việc triển khai. Quá trình này loại trừ:

• Khách hàng có vấn đề
• Nhóm hỗ trợ xác định vấn đề
• Nhóm sản phẩm xác định vấn đề tồn đọng
• Nhóm giải pháp tùy chỉnh việc triển khai cho khách hàng
• Khách hàng nhận ra giá trị từ giải pháp

Vấn đề là việc đo thời gian chu kỳ một mình có thể dẫn đến hai vấn đề lớn:

1. Nút thắt nằm ở bất kỳ phần nào bị loại trừ nêu trên và khách hàng của bạn không nhận ra giá trị và bạn không nhận ra doanh thu tỷ lệ thuận với tốc độ của thời gian chu kỳ của bạn. Vì vậy, trong khi kỹ thuật của bạn là tuyệt vời, doanh nghiệp của bạn bị.

2. Việc ngắt kết nối với Khách hàng sẽ khiến chu kỳ phát hành của bạn bị trống - không tạo ra bất kỳ giá trị nào, mặc dù đã thực hiện thay đổi - hoặc thậm chí phản đối nhu cầu của Khách hàng và công việc đang thực hiện có thể có giá trị kinh doanh âm.

Một vấn đề khác với KPI là trong khi bắt đầu và kết thúc với khách hàng, nó có thể không thực sự đo lường giá trị cho khách hàng. Một ví dụ điển hình sẽ là quy trình Xử lý sự cố và sự cố và MTTR (Thời gian trung bình để sửa chữa) là KPI. Có vấn đề thậm chí ảnh hưởng đến bất cứ ai? Giá trị cho khách hàng là gì? Bạn có thể có MTTR xuất sắc trong 3 giờ với hơn 100 sự cố. Nhưng nếu hầu hết trong số họ là nội bộ, không có hoặc có tác động tối thiểu đến khách hàng và được giải quyết trong vài phút, trong khi một sự cố lớn với tác động lớn của khách hàng mất 3 ngày để xử lý, giá trị doanh nghiệp thấp hơn so với nếu bạn có MTTR 1 ngày, bởi vì bạn bỏ qua hầu hết các sự cố nội bộ, nhưng bạn đã phản ứng với sự cố ảnh hưởng lớn đến khách hàng trong vòng 1 giờ.

LƯU Ý: Đối với khách hàng nội bộ, trong trường hợp quy trình kinh doanh của nhóm hỗ trợ, giá trị xuất phát không phải là giá trị của công việc đối với khách hàng nội bộ, mà là giá trị mà doanh nghiệp đạt được trong việc bỏ chặn khách hàng nội bộ trong quy trình kinh doanh của chính họ. Bỏ chặn một nhóm là một nút cổ chai trong quy trình riêng của họ có giá trị cao hơn so với bỏ chặn một nhóm hoặc cá nhân không bị tắc nghẽn. Tất cả KPI của nhóm hỗ trợ như vậy cần bao gồm giá trị doanh nghiệp trong tính toán của họ.

1. Tần suất triển khai
2. Tốc độ triển khai
3. Tỷ lệ triển khai thành công
4. Dịch vụ có thể được khôi phục nhanh như thế nào sau khi triển khai thất bại
   Và cuối cùng,
5. Văn hóa DevOps, mà thực sự không thể đo lường được