Các dấu hiệu và tín hiệu điển hình của một nhóm DevOps đang bị bảo vệ là gì? Làm thế nào bạn sẽ biện minh / giải thích một yêu cầu bổ sung mới cho một nhóm?

Tôi rất thích giữ câu hỏi chung chung, nhưng đây là một số thông tin bổ sung:

Chúng tôi hiện có 2 chuyên gia DevOps làm việc cùng nhau trong một nhóm, nhưng nhu cầu cũng như số lượng và độ phức tạp của sản phẩm đang tăng lên. Chúng tôi đang suy nghĩ để yêu cầu một sự bổ sung mới cho đội, nhưng có một số khó khăn để giải thích và chứng minh tại sao nó sẽ là một ý tưởng tốt.

Có bốn lý do chính khiến bạn cảm thấy nhóm của mình bị thiếu:

1. Tổ chức và kế hoạch làm việc kém
2. Làm việc người khác nên làm
3. Làm những việc không nên làm
4. Đang thực sự bị bảo vệ

Bắt đầu với một đánh giá của ba điểm đầu tiên. Đọc Dự án Phoenix về ý tưởng làm thế nào để làm đầu tiên. Hãy tự hỏi mình về mọi nhiệm vụ mà bạn giúp đỡ bất cứ ai nếu nó nên được thực hiện và nếu đó là bạn nên thực hiện nhiệm vụ hoặc nếu bạn chỉ đơn giản là cho phép bất cứ ai cần nó được thực hiện để tự thực hiện. Điều này sẽ cung cấp cho bạn một số tài liệu về lý do tại sao tất cả các công việc bạn làm là cần thiết.

Tiếp theo xem xét bốn loại công việc được đề cập trong dự án Phoenix:

1. Dự án kinh doanh - những gì bạn làm cho các nhóm khác trong tổ chức
2. Dự án nội bộ - những gì bạn làm để làm cho công việc của bạn dễ dàng hơn trong tương lai
3. Bảo trì theo lịch trình - những gì bạn làm để giữ cho đèn sáng
4. Ngắt không có kế hoạch - những gì bạn làm vì đã xảy ra sự cố

Nếu công việc của nhóm của bạn là bền vững, bạn sẽ dành khoảng thời gian tương đương cho mỗi người trong số bốn người. Nếu công việc không có kế hoạch bắt đầu leo ​​lên gần 50% thời gian của bạn, đó là một dấu hiệu bạn chắc chắn bị thiếu.

Bạn sẽ có thể thuê để ở lại về một người trước công việc không có kế hoạch đạt 25% thời gian của bạn, nếu không, một người rời đi sẽ gửi toàn bộ nhóm của bạn vào một cái đuôi mà bạn không bao giờ có thể phục hồi. Việc đánh giá quá cao con người và công nghệ có cùng lý do và lợi ích.

Bối cảnh: Bên cạnh việc cung cấp hỗ trợ cho cơ sở hạ tầng hiện tại và cho Nhà phát triển của chúng tôi, chúng tôi lập kế hoạch hàng tháng với tư cách là nhóm DevOps cho những gì chúng tôi muốn thực hiện trên đầu trang để giúp các nhóm phát triển trong các cuộc đua nước rút và các dự án mới được triển khai. Tuy nhiên, trong tháng chúng tôi thường nhận thấy những điều cần làm thêm và cải thiện, sau đó chúng tôi thêm vào hồ sơ tồn đọng của chúng tôi. Chúng tôi cũng chịu trách nhiệm và hỗ trợ nhiều thứ khác nằm ngoài phạm vi của chúng tôi, nhưng chúng tôi hỗ trợ doanh nghiệp là có thể :)

Trả lời : Ngay khi bạn nhận thấy bạn không hoàn thành hoặc hoãn nhiều nhiệm vụ đặc biệt là bảo trì, tôi nghĩ đó là một chỉ số tốt (từ những gì tôi đã trải nghiệm). Ngoài ra, càng có nhiều dự án và nhóm phát triển mới xuất hiện trong nhóm DevOps mỏng hơn, bạn sẽ càng cần nhiều người hơn.

Rất dễ dàng để bắt kịp công việc hàng ngày, nhưng tôi tin rằng nó cực kỳ quan trọng (thậm chí mỗi tháng một lần) để lùi lại một bước và đánh giá điều này.

Tôi thực sự lấy một trang từ Cẩm nang SRE trên trang này, cái mà tôi nghĩ là rất phù hợp. Đặc sản DevOps không có nghĩa là phát triển theo chiều ngang với một tổ chức. Thay vào đó, nếu bạn thấy rằng mọi thứ không được thực hiện thì đó là tín hiệu bạn không trao quyền cho các nhà phát triển tự phục vụ.

Đánh giá các quy trình của bạn và xem cách chúng phù hợp với Nguyên tắc DevOps thường được chấp nhận và mức độ bạn tuân thủ các thực tiễn tốt nhất trong ngành.

Tôi giả sử nhóm hai người này sẽ đi từ dự án này sang dự án khác và thiết lập công cụ DevOps ở đó (tạo đường ống CI / CD, hỗ trợ các nhà phát triển khác tạo Dockerfiles hoặc bất kỳ công nghệ nào bạn đang sử dụng). Nói cách khác, nhập 3, 4, 5 hoặc 6 theo http://web.devopstopology.com/ .

Trong trường hợp này, một dấu hiệu thiếu chỉ đơn giản là quá nhiều khối lượng công việc cho hai người đó; quá nhiều dự án yêu cầu dịch vụ của họ; quá nhiều vé; tăng ca; căng thẳng, kiệt sức. Những yếu tố này phải là lý do đủ để một lãnh đạo có trách nhiệm tăng thêm năng lực. Tôi không thấy một dấu hiệu cụ thể của DevOps trong đó, đây chỉ là một chức năng chưa được bảo vệ.

Một dấu hiệu khác để thay đổi điều gì đó là nếu bạn có một cái nhìn chăm chỉ và nếu bạn nhận thấy rằng bạn đang tạo ra một "DevOps silo", trong đó tất cả các bí quyết của DevOps đều tập trung ở hai anh chàng / cô gái đó và mọi người khác chỉ lùi lại vì hai người đó đang "làm DevOps". Đó không phải là điểm của DevOps. Nếu đây là trường hợp, hãy suy nghĩ về khía cạnh văn hóa, và sửa đổi chúng để trở thành nhà truyền giáo / giáo viên / huấn luyện viên hơn cho các đội khác.

Trong cả hai trường hợp, lý do sâu xa hơn về việc tại sao có DevOps ở vị trí đầu tiên là một điều tốt (những điều tốt đẹp chung) nên rõ ràng với quản lý cấp trên. Nếu bạn không thể mang thông điệp đó đi, thì hãy thu nhỏ công việc mà nhóm của bạn đang thực hiện, bằng cách chuyển nó sang Devs / Ops thông thường (dù sao cũng nên như vậy, dù sao đi nữa).

Tôi có ấn tượng rằng DevSecOps là một người có suy nghĩ, không phải là một nhóm - nếu bạn có một nhóm "Ops" (bạn) đang làm sai ... Tôi đang cố gắng che giấu hai "Kỹ sư DevOps" cùng nhau và gọi họ là "Nhóm DevOps."

Chúng tôi có các nhóm phát triển, SCM, Bảo mật ứng dụng và Kỹ sư hệ thống cùng làm việc với một mô hình triển khai / phát hành nhanh để đẩy mã và thay đổi cấu hình / hệ thống đến một điểm cuối cụ thể - hoặc dàn dựng hoặc sản xuất

Điều này không có gì để làm với bất kỳ kỹ sư "devOps", như vậy.

Phân nhóm nhiệm vụ

Một cách tiếp cận chúng ta đã sử dụng trong quá khứ trong các tình huống tương tự là tổ chức công việc của một nhóm trong 4 nhóm nhiệm vụ chính và phân bổ tương đương 2 FTE (Tương đương toàn thời gian) để (cố gắng) hoàn thành các nhiệm vụ đó. Trong trường hợp của chúng tôi, nó có liên quan đến việc chạy bộ phận trợ giúp SCM trong môi trường máy tính lớn, với khoảng 300 nhà phát triển yêu cầu tất cả các loại trợ giúp / can thiệp từ 2 FTE đó. Các nhóm nhiệm vụ được tổ chức theo 4 ưu tiên có thể:

• Nhiệm vụ ưu tiên 1 và 2 phải được hoàn thành (không có lý do / thương lượng nào có thể)
• Ưu tiên 3 nhiệm vụ sẽ được hoàn thành " ngay khi thời gian cho phép".
• Ưu tiên 4 nhiệm vụ sẽ được hoàn thành " nếu thời gian cho phép".

Đọc để biết thêm chi tiết về loại nhiệm vụ trong mỗi nhóm trong số 4 nhóm đó ...

Mô tả nhiệm vụ

Ưu tiên 1 - Vận hành bộ phận trợ giúp

• Bởi các chuyên gia dễ dàng truy cập và luôn luôn có sẵn.
• Thông qua điện thoại, email hoặc hệ thống bán vé trong giờ làm việc.
• Tuân thủ SLA được xác định trước.
• Đăng ký dựa trên ITIL của tất cả các cuộc gọi trợ giúp với báo cáo định kỳ của tất cả các cuộc gọi.
• Áp dụng các tùy chỉnh khẩn cấp (xung quanh công việc) cho các vấn đề quan trọng.

Ưu tiên 2 - Xem dịch vụ nhiệm vụ

• 24h / ngày, 7d / tuần sẵn có trong cuộc gọi.
• Tuân thủ SLA được xác định trước.
• Báo cáo của tất cả các cuộc gọi nhiệm vụ xem.
• Quản lý leo thang nơi cần thiết.

Ưu tiên 3 - Bảo trì định kỳ

• Quản trị.
• Ứng dụng nội trú.
• Dịch vụ dọn phòng.
• Cải tiến hiệu suất.
• Quản lý không gian.
• Điều chỉnh tiêu thụ tài nguyên.
• Đề xuất cải tiến cho các tùy chỉnh để giảm số lượng cuộc gọi trợ giúp và / hoặc xem các can thiệp thuế.

Ưu tiên 4 - Sửa lỗi và cải tiến

• Tạo và duy trì tài liệu người dùng.
• Kiểm tra QA của các tùy chỉnh mới.
• Phát triển và thực hiện các yêu cầu nâng cao.
• Tham gia thử nghiệm DRP.

Đánh giá

Nếu bạn đang sử dụng một cách tiếp cận như được mô tả ở trên, nhiều điều có thể (sẽ!) Bắt đầu xảy ra:

• Nếu nhóm bị thiếu, có lẽ phần lớn thời gian sẽ chuyển sang các nhiệm vụ ưu tiên 1 và 2, trong khi có thể mất một thời gian để nhận 3 nhiệm vụ ưu tiên ... và 4 nhiệm vụ ưu tiên có thể bị chết đói (dường như không bao giờ có thời gian những nhiệm vụ đó).
• Càng có nhiều thời gian ( đầu tư ) để " đầu tư " vào 4 nhiệm vụ ưu tiên, thì càng cần nhiều thời gian hơn cho các nhiệm vụ ưu tiên 1 và 2, để có thể đầu tư nhiều thời gian hơn (trong ngân sách có sẵn của 2 FTE) "Trong 4 nhiệm vụ ưu tiên.
• Bạn sẽ ngạc nhiên khi thấy sau một thời gian, số lượng nhiệm vụ ưu tiên 1 và 2 sẽ giảm xuống. Và nếu bạn báo cáo đầy đủ về các nhiệm vụ đó, đó là điều mà ban quản lý rất thích nghe. Trong trường hợp của chúng tôi, con số đó đã giảm từ khoảng 300 / tháng, xuống dưới 100 / tháng ...
• Tuy nhiên, nếu 2 FTE dường như không bao giờ (hoặc hầu như không) có thời gian cho 4 nhiệm vụ ưu tiên, thì bạn có một lời giải thích và bằng chứng hoàn hảo cho quản lý của mình ... rằng bạn đang bị thiếu.