Một chuyển đổi DevOps chuyển đổi có chứa những gì?

Một số công ty tư vấn đang quảng bá một dịch vụ gọi là "Chuyển đổi DevOps". Nhiều công ty lớn đang nói về chủ đề này tại các hội nghị và cuộc họp trên toàn thế giới.

"Biến đổi DevOps" như vậy đòi hỏi gì? Nó trông như thế nào trong các điều khoản có thể hành động, cả cho các chuyển đổi thành công và thất bại.

Tôi cần đặt câu trả lời của mình cho câu hỏi này trong bối cảnh DevOps là gì, cụ thể hơn trong các biến đổi DevOps mà tôi đã tham gia, DevOps là quyền sở hữu Vòng đời phát triển phần mềm đầy đủ. Tất cả các thực tiễn trong biểu đồ là một phần quan trọng của DevOps, và chúng cho phép và củng cố cả Tư duy hệ thống và Khuếch đại các vòng phản hồi .

Tuy nhiên, điểm khác biệt chính giữa CI / CD và DevOps là hoạt động thực sự của phần mềm trong môi trường sản xuất, nơi nó có thể mang lại giá trị cho khách hàng và doanh nghiệp mà nó phục vụ.

Là một nhà tư vấn tham gia hoặc lãnh đạo một chuyển đổi DevOps, tôi có các khía cạnh sau đây trong tâm trí của tôi:

• Văn hóa : Là Dave khá đúng chỉ ra một nền văn hóa của liên tục thử nghiệm và học tập là rất quan trọng cho sự thành công của bất kỳ chuyển đổi. Từ góc độ DevOps, điều này dẫn đến cách chúng ta tạo ra một nền văn hóa ủng hộ mô hình DevOps đã chọn, mô hình này có thể là "Bạn xây dựng nó, bạn chạy nó" hoặc có thể đi sâu hơn vào thực tiễn Kỹ thuật tin cậy trang web của Google .

• Mô hình hoạt động : Đây là một phần của đề xuất kinh doanh cho thấy cách thức tổ chức sẽ mang lại giá trị, nói chung bằng cách nói rõ Con người, Quy trình và Công cụ được sử dụng gắn liền với nhau ở mức cao. Nếu không có mô hình hoạt động, bạn không có kế hoạch chi tiết cho cách tổ chức áp dụng các thực tiễn mà văn hóa định nghĩa, điều này, dẫn đến việc thiếu sự rõ ràng và hành vi khác nhau.

• Máy bay cấp độ C : Công việc của chúng tôi thường là các chuyên gia tư vấn làm việc trong các chương trình chuyển đổi để thực hiện các thay đổi căn bản đối với cách thức kinh doanh. Bạn sẽ làm mọi người khó chịu và một số người sẽ không thích những thay đổi - điều quan trọng là bạn phải có "không khí" từ trên cao để thay đổi mọi thứ và tiến lên phía trước.

Một khi mức độ cao được đặt ra, điều quan trọng là tìm thấy thứ gì đó bạn có thể cung cấp một cách thực tế:

1. Bắt đầu càng nhỏ càng tốt, lý tưởng nhất là khi bạn có một số người hiểu về văn hóa, một bản phác thảo mô hình hoạt động và mua từ các giám đốc điều hành tạo ra "Dự án khả thi tối thiểu", đừng cố gắng làm sôi đại dương bằng cách giới thiệu DevOps đến một khán giả của hàng ngàn. Đặt mục tiêu có thể đạt được:
   • Tự động hóa việc tạo cơ sở hạ tầng từ Sản phẩm X.
   • Tự động hóa việc phân phối Sản phẩm X vào Azure trên tất cả các môi trường.
   • Hỗ trợ trở lại từ người đăng việc Y cho một nhóm phát triển ở London.
   • Tạo một tập hợp các thử nghiệm xung quanh tính năng rủi ro nhất của chúng tôi và chạy chúng trong tích hợp liên tục.
2. Thật tuyệt khi bạn có một số thành công trong vành đai của mình bây giờ đã đến lúc bắt đầu nướng nó thành nhiều đội hơn, thêm một vài đội khác vào hỗn hợp và đưa chúng lên và chạy. Lúc đầu, đừng ngại đưa ra "Hỗ trợ găng tay trắng" để hỗ trợ họ trong quá trình chuyển đổi; họ sẽ cần rất nhiều sự nắm tay trong những tuần và tháng tới.
3. Bây giờ bạn có một vài người chấp nhận sớm theo cách làm việc mới; bạn có một số lượng quan trọng, đã đến lúc bắt đầu truyền giáo cho công việc bạn đang làm với đối tượng rộng hơn:
   • Tổ chức các buổi giới thiệu thường xuyên và yêu cầu những người chấp nhận sớm chứng minh họ đã thành công như thế nào.
   • Cung cấp các phiên thả vào để cho phép các bộ phận khác trong tổ chức khám phá cách họ có thể tham gia với nhóm của bạn.
   • Cho phép tạo Cộng đồng Thực hành tập trung vào các chuyên ngành cụ thể: Triển khai liên tục, Kiểm tra tự động, Giao tiếp kinh doanh, Quản lý rủi ro, Giám sát và cảnh báo, v.v.

4. Duy trì khóa học và kết thúc quá trình chuyển đổi bằng cách đưa lên phần còn lại của tổ chức. Hiểu mối quan hệ giữa Chu kỳ Gartner Hype và Vòng đời nuôi con nuôi . Chuẩn bị cho Chương trình chuyển đổi rơi vào "Mảng vỡ mộng", duy trì khóa học và giữ mục tiêu cuối cùng trong tầm nhìn.

   

Để tìm hiểu sâu hơn về điểm cuối cùng, hãy đọc Geoffrey A. Moore's Crossing the Chasm . Tôi hoàn toàn có thể viết một cuốn sách về cách phân phối chuyển đổi DevOps, tuy nhiên đến khi tôi hoàn thành nó, có lẽ tôi sẽ không còn phải chuyển đổi DevOps nữa.

DevOps có xu hướng phá vỡ trên ba chiều chính:

Văn hóa Văn hóa
DevOps nhấn mạnh mức độ tin cậy, hợp tác và giao tiếp cao giữa tất cả các bên liên quan, đặc biệt là Dev, Ops và Bảo mật. Sự căng thẳng tự nhiên và sự cạnh tranh giữa các nhóm này tạo ra ma sát và thường bị rối loạn chức năng. DevOps là (đầu tiên) được cho là đầu tiên và quan trọng nhất về việc sắp xếp các nỗ lực giữa các đội này.

Quy trình
phát triển DevOps liên kết chặt chẽ với các quy trình Agile. Ops được khuyến khích áp dụng các thực hành giống như Agile để phù hợp hơn với các nỗ lực của Dev. Các quy trình liên kết với DevOps được thiết kế để hỗ trợ các vòng lặp tốc độ cao và phản hồi nhanh trong suốt vòng đời phát triển / phân phối. Tích hợp liên tục, phân phối liên tục và cải tiến liên tục (kaizen) là các lĩnh vực trọng tâm của quy trình DevOps.

Công nghệ
DevOps không phải là một công cụ, nhưng nó được hỗ trợ bởi các công cụ. Có toàn bộ các công cụ hỗ trợ một loạt các lĩnh vực bao gồm Tích hợp liên tục, Kiểm soát nguồn và Quản lý vòng đời ứng dụng.

"Chuyển đổi DevOps" phải giải quyết các yếu tố của cả ba, nhưng không nhất thiết là tất cả đều như nhau cùng một lúc. Có một sự tiến triển tự nhiên và "con đường quan trọng" để chuyển đổi. Đối số có thể được đưa ra, ví dụ, DevOps phụ thuộc vào một số hình thức thực hành Agile, ít nhất là trong nhóm / nhóm Phát triển. Các vấn đề với văn hóa có thể cần được giải quyết trước khi đầu tư vào công cụ.

Tài liệu tham khảo:
Văn hóa: https://www.andykelk.net/devops/USE-the-westrum-typology-to-measure-cocate
Technology: https://xebialabs.com/apseic-table-of-devops-tools/