IMHO nó không phải là một ý tưởng tốt để trực tiếp và ngay lập tức áp dụng mức tăng của một nhóm nghiên cứu từ chuyển đổi DevOps nó vào mở rộng quy mô đội xuống . Tốt nhất là bạn sẽ chỉ mất động lực của nhóm để thực hiện bất kỳ cải tiến nào như vậy trong tương lai. Nhưng rất có thể bạn sẽ mất hầu hết / tất cả tài năng trong đội đó.
Thay thế:
- cho phép nhóm đánh giá cao lợi ích của việc chuyển đổi khó khăn mà họ đã trải qua, để họ truyền bá cho các nhóm khác của bạn sẽ phải trải qua (hoặc đã đấu tranh với) việc chuyển đổi
- tập trung vào việc cung cấp các sản phẩm / dịch vụ chất lượng tốt hơn, nhanh hơn - với cùng một nhóm - điều này hiện có thể thực hiện được do sự chuyển đổi.
- trong nhiều trường hợp, doanh nghiệp của bạn sẽ tăng tốc vì chuyển đổi - chẳng mấy chốc bạn sẽ cần thuê người - IMHO tốt hơn là sử dụng kinh nghiệm của những người bạn đã có thay vì giáo dục nhân viên mới
- cho phép sự tự nguyện tiêu hao để làm việc cho bạn và có được sự thu hẹp hiệu quả xuống đường.
Nhưng nhìn chung các phép biến đổi DevOps có xu hướng không xảy ra đủ nhanh để cho phép các lựa chọn ở trên :)
Bây giờ lên quy mô lên / ra .
Lý tưởng nhất là việc chuyển đổi DevOps sẽ làm tăng đáng kể khả năng dự đoán về quá trình phát triển và phân phối sw của bạn. Bạn sẽ có thể nói với một mức độ chính xác cao mà năng lực của đội bạn hiện có: bao nhiêu sw / dịch vụ có chất lượng nhất định mà nhóm hiện tại của bạn có thể hoàn thành trong một khoảng thời gian nhất định.
Khi bạn cần nhiều thứ hơn, hoặc hoàn thành tốt hơn / nhanh hơn khả năng của nhóm hiện tại, bạn cần mở rộng nhóm lên / ra. Các chi tiết chính xác đến từ bất kỳ quy trình / phương pháp nào bạn sử dụng cho các hoạt động hàng ngày của mình, có thể là một số biến thể nhanh nhẹn (xem thêm Tổ chức của tôi có cần áp dụng Agile Soft. Dev trước khi áp dụng DevOps không? )
Làm thế nào - rõ ràng dễ dàng: thuê nhiều người hơn để xử lý các hoạt động tràn. Nếu bạn lo lắng về việc bạn có thể đưa chúng lên tàu nhanh như thế nào và thực sự xử lý công việc tràn đó với mức giá dự kiến: bắt đầu tuyển dụng sớm hơn, dựa trên các dự đoán.
Tuy nhiên, thực tế có thể khó khăn hơn một chút. Mở rộng quy mô sản phẩm / dịch vụ hoặc quy trình phát triển và các công cụ hỗ trợ nó không nhất thiết phải đơn giản, ngay cả đối với một tổ chức được trao quyền DevOps.
Một trong những ví dụ yêu thích của tôi là liên kết DevOps yếu nhất khi nói đến khả năng mở rộng : Tích hợp liên tục. Nếu việc xây dựng CI không thành công thì không thể có Giao hàng / Triển khai (loại bỏ điều khoản "liên tục" trong ngữ cảnh CD).
Chỉ vì một nhóm nhất định đang vui vẻ sử dụng CI với kết quả tốt, điều đó không có nghĩa là điều tương tự sẽ xảy ra nếu quy mô nhóm tăng gấp đôi. Không, kết quả có thể bị tàn phá - quá trình giao hàng có thể bị đình trệ (trong trường hợp cực đoan). Tôi đang cố gắng giải thích vấn đề này trong Sự tắc nghẽn trong Hệ thống CI truyền thống ( từ chối trách nhiệm: Tôi là người sáng lập công ty sở hữu trang được tham chiếu và đưa ra giải pháp cho vấn đề này).
Một ví dụ khác có thể là, ví dụ, hệ thống kiểm soát phiên bản (VCS) đang được sử dụng: vì phần mềm được lưu trữ vào kho lưu trữ sẽ phát triển lịch sử thay đổi của nó, đẩy các giới hạn của hệ thống VCS, đôi khi vượt quá mức hiệu suất chấp nhận được. Chuyển sang một hệ thống VCS có khả năng mở rộng hơn hoặc tách codebase thành nhiều kho lưu trữ có thể là một cách tiếp cận để giải quyết vấn đề.
Nhưng phát triển các quy trình phát triển và công cụ hỗ trợ chúng cùng với sự phát triển của các sản phẩm / dịch vụ phần mềm được cung cấp về cơ bản chỉ là những gì một nhóm DevOps trưởng thành làm. Họ cũng chỉ cần được xem xét khi trong chiến lược tăng / giảm quy mô của đội.
Với ý nghĩ đó, làm thế nào có thể, thực sự, giảm xuống chỉ còn tăng quy mô nhóm để trang trải số lượng công việc cần thiết để thực hiện chiến lược nói trên.