Thành thật mà nói, Ivan thường cười nhạo những nỗ lực vô ích của các đồng nghiệp ở bộ phận giám sát. Họ đã nỗ lực rất nhiều để thực hiện các chỉ số mà ban lãnh đạo công ty yêu cầu họ phải đạt được. Họ bận đến mức không muốn ai làm gì cả.
Nhưng điều đó vẫn chưa đủ đối với ban quản lý - họ liên tục đặt hàng ngày càng nhiều số liệu mới, rất nhanh chóng ngừng sử dụng những gì đã được thực hiện trước đó.
Gần đây mọi người đều nhắc đến LeadTime - thời điểm cung cấp các tính năng kinh doanh. Số liệu cho thấy một con số điên rồ - 200 ngày để hoàn thành một nhiệm vụ. Mọi người đều ồ, aah và giơ tay lên trời!
Sau một thời gian, tiếng ồn dần dần lắng xuống và ban quản lý nhận được lệnh tạo ra một số liệu khác.
Ivan hoàn toàn hiểu rõ rằng thước đo mới sẽ lặng lẽ chết trong góc tối.
Quả thực, Ivan nghĩ, biết con số này chẳng nói lên điều gì với ai cả. 200 ngày hay 2 ngày - không có gì khác biệt, vì không thể xác định nguyên nhân bằng con số và hiểu được là tốt hay xấu.
Đây là một cái bẫy điển hình của các thước đo: có vẻ như một thước đo mới sẽ cho biết bản chất của sự tồn tại và giải thích một bí mật bí mật nào đó. Mọi người đều hy vọng rất nhiều vào điều này, nhưng vì lý do nào đó mà không có gì xảy ra. Có, bởi vì bí mật không nên được tìm thấy trong số liệu!
Đối với Ivan, đây là một giai đoạn đã qua. Anh ấy hiểu điều đó để đo lường và tất cả bí mật phải được tìm kiếm trong , I E. là số liệu này được hình thành.
Đối với một cửa hàng trực tuyến, đối tượng ảnh hưởng sẽ là những khách hàng mang lại tiền và đối với DevOps, đó sẽ là các nhóm tạo và triển khai các bản phân phối bằng cách sử dụng một quy trình.
Một ngày nọ, ngồi xuống chiếc ghế thoải mái trong hội trường, Ivan quyết định suy nghĩ cẩn thận về cách anh muốn xem các chỉ số DevOps, có tính đến thực tế là đối tượng ảnh hưởng là các nhóm.
Mục đích của số liệu DevOps
Rõ ràng là mọi người đều muốn giảm thời gian giao hàng. Tất nhiên, 200 ngày là không tốt.
Nhưng làm thế nào, đó là câu hỏi?
Công ty tuyển dụng hàng trăm nhóm và hàng nghìn lượt phân phối đi qua quy trình DevOps mỗi ngày. Thời gian giao hàng thực tế sẽ xuất hiện dưới dạng phân phối. Mỗi đội sẽ có thời gian và đặc điểm riêng. Làm thế nào bạn có thể tìm thấy bất cứ điều gì trong mớ hỗn độn này?
Câu trả lời nảy sinh một cách tự nhiên - chúng ta cần tìm ra các nhóm có vấn đề và tìm hiểu chuyện gì đang xảy ra với họ và tại sao lại mất nhiều thời gian như vậy, đồng thời học hỏi từ các nhóm “giỏi” cách thực hiện mọi việc nhanh chóng. Và để làm được điều này, bạn cần đo thời gian mà các nhóm dành cho mỗi khán đài DevOps:
“Mục đích của hệ thống sẽ là chọn các đội dựa trên thời gian họ vượt qua khán đài, tức là. Kết quả là chúng ta sẽ nhận được một danh sách các lệnh có thời gian đã chọn chứ không phải một con số.
Nếu chúng tôi biết tổng cộng bao nhiêu thời gian đã dành cho khán đài và bao nhiêu thời gian dành cho thời gian ngừng hoạt động giữa các khán đài, chúng tôi có thể tìm các đội, gọi điện cho họ và hiểu lý do chi tiết hơn và loại bỏ họ”, Ivan nghĩ.
Cách tính thời gian giao hàng cho DevOps
Để tính toán nó, cần phải đi sâu vào quy trình DevOps và bản chất của nó.
Công ty sử dụng một số lượng hệ thống hạn chế và thông tin chỉ có thể được lấy từ chúng chứ không phải từ nơi nào khác.
Tất cả các nhiệm vụ trong công ty đều được đăng ký trên Jira. Khi một nhiệm vụ được thực hiện, một nhánh sẽ được tạo cho nhiệm vụ đó và sau khi triển khai, một cam kết sẽ được thực hiện đối với BitBucket và Yêu cầu kéo. Khi PR (Yêu cầu kéo) được chấp nhận, bản phân phối sẽ tự động được tạo và lưu trữ trong kho Nexus.
Tiếp theo, bản phân phối được triển khai trên một số gian hàng bằng cách sử dụng Jenkins để kiểm tra tính chính xác của quá trình triển khai, thử nghiệm tự động và thủ công:
Ivan mô tả từ hệ thống nào những thông tin nào có thể được lấy để tính thời gian trên khán đài:
- Từ Nexus – Thời gian tạo phân phối và tên của thư mục chứa mã lệnh
- Từ Jenkins – Thời gian bắt đầu, thời lượng và kết quả của từng công việc, tên đứng (trong thông số công việc), các giai đoạn (các bước công việc), liên kết đến phân phối trong Nexus.
- Ivan quyết định không đưa Jira và BitBucket vào quy trình vì chúng liên quan nhiều hơn đến giai đoạn phát triển chứ không phải việc triển khai phân phối đã hoàn thiện trên các gian hàng.
Dựa trên thông tin có sẵn, sơ đồ sau được vẽ:
Biết mất bao lâu để tạo các bản phân phối và lượng thời gian dành cho mỗi bản phân phối, bạn có thể dễ dàng tính toán tổng chi phí đi qua toàn bộ quy trình DevOps (chu kỳ đầy đủ).
Dưới đây là các số liệu DevOps mà Ivan đã đạt được:
- Số lượng bản phân phối được tạo
- Tỷ lệ phân phối “đến” gian hàng và “vượt qua” gian hàng
- Thời gian sử dụng trên giá đỡ (chu kỳ chờ)
- Chu kỳ đầy đủ (tổng thời gian cho tất cả các khán đài)
- Thời gian làm việc
- Thời gian ngừng hoạt động giữa các khán đài
- Thời gian ngừng hoạt động giữa các lần tuyển dụng trên cùng một vị trí
Một mặt, các số liệu mô tả rất rõ quy trình DevOps về mặt thời gian, mặt khác, chúng được coi là rất đơn giản.
Hài lòng với công việc được hoàn thành tốt, Ivan thuyết trình và đi trình bày với ban quản lý.
Anh ta quay lại với vẻ mặt ủ rũ và buông tay xuống.
“Đây là một thất bại, anh bạn ạ,” người đồng nghiệp mỉa mai mỉm cười...
Đọc thêm ở bài viết “'.
Nguồn: www.habr.com