Cách thành lập các nhóm DevOps trong tổ chức của bạn

0
23

DevOps không có cấu trúc tổ chức lý tưởng. Giống như mọi thứ trong công nghệ, câu trả lời của ngay bên phải liên quan đến cấu trúc của công ty bạn phụ thuộc vào tình huống duy nhất của bạn: nhóm hiện tại của bạn, kế hoạch phát triển, quy mô nhóm của bạn, bộ kỹ năng sẵn có của nhóm, sản phẩm của bạn và trên.

Căn chỉnh tầm nhìn của nhóm DevOps sẽ là nhiệm vụ đầu tiên của bạn. Chỉ sau khi bạn loại bỏ trái cây treo thấp do ma sát rõ ràng giữa mọi người, bạn mới nên bắt đầu sắp xếp lại các đội. Thậm chí sau đó, cho phép một số linh hoạt.

Nếu bạn tiếp cận việc sắp xếp lại với sự cởi mở và linh hoạt, bạn sẽ gửi thông điệp rằng bạn sẵn sàng lắng nghe và trao quyền tự chủ cho nhóm của bạn – một nguyên lý cơ bản của DevOps.

Bạn có thể đã có một nhà phát triển Python hoặc Go đam mê và tò mò về quản lý cấu hình và cơ sở hạ tầng. Có lẽ người đó có thể chuyển sang vai trò tập trung hơn vào tổ chức mới của bạn. Đặt mình vào vị trí của người đó. Bạn sẽ không trung thành với một tổ chức đã mạo hiểm với bạn chứ? Bạn sẽ không hào hứng làm việc chăm chỉ chứ? Và sự phấn khích đó là truyền nhiễm.

Tại đây, bạn tìm hiểu cách sắp xếp các nhóm bạn đã có, dành một nhóm cho các thực tiễn DevOps và tạo các nhóm đa chức năng – tất cả các cách tiếp cận mà bạn có thể chọn để định hướng các nhóm của mình theo DevOps.

Bạn có thể chọn một cách tiếp cận và cho phép nó phát triển từ đó. Đừng cảm thấy rằng quyết định này là vĩnh viễn và không thể thay đổi. DevOps tập trung vào việc lặp lại nhanh chóng và cải tiến liên tục và đó là lợi ích chính của phương pháp này . Triết lý đó cũng áp dụng cho các đội.

Sắp xếp các nhóm chức năng cho DevOps

Trong phương pháp này, bạn tạo ra sự hợp tác mạnh mẽ giữa các nhóm hoạt động và phát triển truyền thống của mình. Các đội vẫn hoạt động trong tự nhiên – một tập trung vào ops, một tập trung vào mã. Nhưng ưu đãi của họ được liên kết. Họ sẽ phát triển để tin tưởng lẫn nhau và làm việc khi hai đội cùng nhau la hét.

Đối với các tổ chức kỹ thuật nhỏ hơn, việc sắp xếp các nhóm chức năng là một lựa chọn vững chắc. Ngay cả khi là bước đầu tiên, sự liên kết này có thể củng cố những thay đổi tích cực mà bạn đã thực hiện cho đến nay. Bạn thường bắt đầu căn chỉnh bằng cách dành thời gian để xây dựng mối quan hệ. Đảm bảo rằng mỗi người trong cả hai đội không chỉ hiểu về vai trò và các ràng buộc của đội kia mà còn đồng cảm với các điểm đau.

Đối với phương pháp này, một ý tưởng hay là thúc đẩy chính sách của Bạn xây dựng nó, bạn ủng hộ nó. Chính sách này có nghĩa là tất cả mọi người – nhà phát triển và người vận hành đều giống nhau đối với bạn trong vòng quay cuộc gọi của bạn.

Sự tham gia này cho phép các nhà phát triển bắt đầu hiểu được sự bực bội khi bị gọi vào lúc nửa đêm và vật lộn trong khi mắt mù và caffeine bị thiếu để sửa một lỗi gây ảnh hưởng đến khách hàng. Những người hoạt động cũng bắt đầu tin tưởng vào cam kết của nhà phát triển với công việc của họ. Ngay cả sự thay đổi nhỏ này cũng tạo ra một sự tin tưởng phi thường.

Một lời cảnh báo: Nếu các nhà phát triển chiến đấu hết mình để chống lại cuộc gọi, một vấn đề lớn hơn đang diễn ra trong tổ chức của bạn. Việc đẩy lùi không phải là hiếm bởi vì cuộc gọi rất khác với trách nhiệm hàng ngày của họ. Sự đẩy lùi thường đến từ một nơi khó chịu và sợ hãi. Bạn có thể giúp giảm thiểu phản ứng này bằng cách giải quyết thực tế là các nhà phát triển của bạn có thể không biết phải làm gì trong vài lần đầu tiên họ thực hiện cuộc gọi.

Họ có thể không quen thuộc với cơ sở hạ tầng, và điều đó không sao. Khuyến khích họ leo thang vụ việc và trang một người có nhiều kinh nghiệm hơn. Cuối cùng, tạo một cuốn sổ với các cảnh báo phổ biến và những hành động cần thực hiện. Cung cấp tài nguyên này sẽ giúp xoa dịu một số nỗi sợ hãi cho đến khi họ bắt đầu hiểu rõ mọi thứ.

Một chiến thuật khác để giúp thúc đẩy sự hợp tác để thành lập một nhóm DevOps gắn kết hơn là giới thiệu một ngày của bóng tối, với mỗi nhóm giao dịch trực tuyến một đồng nghiệp. Người được giao dịch chỉ đơn giản là che giấu người khác trong đội, ngồi tại bàn của họ (hoặc trong khu vực của họ) và hỗ trợ các trách nhiệm hàng ngày của họ. Họ có thể giúp đỡ trong công việc, thảo luận các vấn đề với tư cách là một nhóm (lập trình cặp) và tìm hiểu thêm về hệ thống từ một quan điểm khác. Phong cách giảng dạy này không quy định.

Thay vào đó, nó cho vay sự tò mò và xây dựng niềm tin. Các đồng nghiệp nên thoải mái đặt câu hỏi – ngay cả giống ngô ngu ngốc – và tự do học hỏi. Không có kỳ vọng hiệu suất tồn tại. Thời gian nên dành chỉ đơn giản là tìm hiểu nhau và đánh giá cao công việc của nhau. Bất kỳ sản lượng sản xuất là một phần thưởng!

Trong phương pháp liên kết này, cả hai đội hoàn toàn phải tham gia vào quá trình lập kế hoạch, kiến ​​trúc và phát triển. Họ phải chia sẻ trách nhiệm và trách nhiệm trong suốt vòng đời phát triển.

Dành một đội DevOps

Một nhóm DevOps chuyên dụng là một sự tiến hóa của Sys Admin hơn là một nhóm DevOps thực sự. Đây là một nhóm hoạt động với sự kết hợp của các bộ kỹ năng. Có lẽ một số kỹ sư quen thuộc với quản lý cấu hình, những người khác là IaC (cơ sở hạ tầng dưới dạng mã) và có lẽ những người khác là chuyên gia về container hoặc cơ sở hạ tầng trên nền tảng đám mây hoặc CI / CD (tích hợp liên tục và phân phối / phát triển liên tục).

Chú ý: Nếu bạn nghĩ rằng việc đưa một nhóm người vào một nhóm chính thức là đủ để phá vỡ các silo, thì bạn đã nhầm. Con người phức tạp hơn bảng tính. Hệ thống phân cấp không có nghĩa gì nếu silo của bạn đã bước vào giai đoạn mà chúng không lành mạnh và bộ lạc. Trong các nền văn hóa độc hại, một phong cách lãnh đạo mạnh mẽ có thể xuất hiện mà hầu như luôn luôn theo sau bởi những người đứng về phía họ. Nếu bạn thấy điều này trên nhóm của riêng bạn, bạn có việc phải làm.

Mặc dù bất kỳ cách tiếp cận nào cũng có thể làm việc cho nhóm của bạn, cách tiếp cận nhóm chuyên dụng này là cách tiếp cận bạn nên suy nghĩ nhiều nhất. Nhược điểm lớn nhất của nhóm DevOps chuyên dụng là nó dễ dàng trở thành sự tiếp nối của các nhóm kỹ thuật truyền thống mà không thừa nhận sự cần thiết phải sắp xếp các đội, giảm silo và loại bỏ ma sát. Rủi ro tiếp tục ma sát (hoặc tạo thêm) là rất cao trong phương pháp này. Bước đi cẩn thận để đảm bảo bạn chọn tổ chức nhóm này vì một lý do cụ thể.

Các lợi ích của việc tiếp cận DevOps này đang có một đội ngũ chuyên dụng để giải quyết những thay đổi cơ sở hạ tầng lớn hoặc điều chỉnh. Nếu bạn đang vật lộn với các vấn đề tập trung vào hoạt động đang làm chậm việc triển khai của bạn hoặc gây lo ngại về độ tin cậy của trang web, đây có thể là một cách tiếp cận tốt – thậm chí là tạm thời.

Một nhóm chuyên dụng nếu bạn dự định chuyển một ứng dụng cũ sang đám mây. Nhưng thay vì gọi nhóm này là nhóm DevOps , bạn có thể thử gắn nhãn cho nhóm đó là nhóm tự động hóa.

Nhóm kỹ sư chuyên dụng này có thể tập trung hoàn toàn vào việc đảm bảo rằng bạn đã thiết lập cơ sở hạ tầng và công cụ tự động hóa chính xác. Sau đó, bạn có thể tiến hành với sự tự tin rằng ứng dụng của bạn sẽ rơi vào đám mây mà không bị gián đoạn lớn. Tuy nhiên, cách tiếp cận này là tạm thời. Nếu bạn giữ đội bị cô lập quá lâu, bạn có nguy cơ đi xuống một con dốc trơn trượt từ sự phát triển nhanh chóng đến silo nhúng.

Tạo các nhóm sản phẩm đa chức năng cho DevOps

Một nhóm đa chức năng là một nhóm được hình thành xung quanh một trọng tâm sản phẩm. Thay vì có các nhóm riêng biệt để phát triển, giao diện người dùng và trải nghiệm người dùng (UI / UX), đảm bảo chất lượng (QA) và hoạt động, bạn kết hợp mọi người từ mỗi nhóm này.

Một nhóm chức năng chéo hoạt động tốt nhất trong các tổ chức vừa và lớn. Bạn cần có đủ nhà phát triển và người vận hành để điền vào các vị trí của từng nhóm sản phẩm. Mỗi nhóm chức năng chéo trông hơi khác nhau.

Đó là một ý tưởng tốt để có tối thiểu một người hoạt động cho mỗi nhóm. Đừng yêu cầu một người hoạt động để phân chia trách nhiệm của họ giữa hai đội. Kịch bản này không công bằng với họ và sẽ nhanh chóng tạo ra ma sát giữa hai nhóm sản phẩm. Cung cấp cho các kỹ sư của bạn đặc quyền có thể tập trung và đào sâu vào công việc của họ.

Ghi nhớ: Nếu tổ chức của bạn vẫn còn nhỏ hoặc đang trong giai đoạn khởi động, bạn có thể nghĩ toàn bộ tổ chức kỹ thuật của mình là một nhóm đa chức năng. Giữ nó nhỏ và tập trung. Khi bạn bắt đầu tiếp cận việc có 10 người12, hãy bắt đầu suy nghĩ về cách bạn có thể sắp xếp lại các kỹ sư.

Hình ảnh dưới đây cho thấy các nhóm chức năng chéo của bạn có thể trông như thế nào. Nhưng hãy nhớ rằng thành phần của họ thay đổi từ nhóm này sang nhóm khác và từ tổ chức này sang tổ chức khác. Một số sản phẩm có trọng tâm thiết kế mạnh mẽ, có nghĩa là bạn có thể có nhiều nhà thiết kế trong mỗi nhóm. Các sản phẩm khác là những sản phẩm kỹ thuật được thiết kế cho các kỹ sư không quan tâm nhiều đến tính thẩm mỹ. Các nhóm cho loại sản phẩm đó có thể có một nhà thiết kế – hoặc không có ai cả.

Nếu tổ chức của bạn đủ lớn, bạn chắc chắn có thể tạo nhiều nhóm bằng các ý tưởng và cách tiếp cận DevOps khác nhau. Hãy nhớ rằng tổ chức của bạn là duy nhất. Cảm thấy được trao quyền để đưa ra quyết định dựa trên hoàn cảnh hiện tại của bạn và điều chỉnh từ đó. Dưới đây là một số kết hợp có thể có của các loại nhóm sản phẩm.

  • Nhóm sản phẩm kế thừa: Quản lý dự án (PM), Nhà phát triển giao diện người dùng, Nhà phát triển phụ trợ, Nhà phát triển phụ trợ, Kỹ sư tin cậy trang web (SRE), Kỹ sư tự động hóa, QA Tester
  • Nhóm chuyển đổi đám mây: SRE, SRE, Kỹ sư vận hành, Kỹ sư tự động hóa, Nhà phát triển phụ trợ
  • Nhóm MVP: PM, Nhà thiết kế, Kỹ sư UX, Nhà phát triển Front-end, Nhà phát triển cuối cùng, Kỹ sư vận hành

Nhược điểm của một nhóm sản phẩm đa chức năng là các kỹ sư mất đi tình bạn của các kỹ sư với bộ kỹ năng và niềm đam mê của họ. Có một nhóm các cá nhân có cùng chí hướng với bạn mà bạn có thể giao tiếp và từ đó bạn có thể học hỏi là một khía cạnh quan trọng của sự hài lòng trong công việc. Kiểm tra một giải pháp cho vấn đề này dưới đây.

Như được hiển thị dưới đây, bạn có thể cung cấp cho các kỹ sư của bạn thời gian làm việc dành riêng cho bộ lạc của họ. Bạn có thể làm điều gì đó hào phóng như trả tiền cho bữa trưa mỗi tuần một lần để họ có thể gặp nhau và nói chuyện. Hoặc bạn có thể cung cấp 10 phút20 phần trăm thời gian làm việc để họ làm việc trong các dự án như một bộ lạc. Dù bằng cách nào, bạn cần các kỹ sư của bạn để giữ sắc nét.

Bộ lạc chia sẻ kiến ​​thức ngành, cung cấp thông tin phản hồi tốt và hỗ trợ sự phát triển nghề nghiệp. Cung cấp thời gian để các kỹ sư của bạn học hỏi từ những người mà họ chia sẻ giáo dục, kinh nghiệm và mục tiêu. Thời gian này cung cấp một nơi an toàn nơi họ có thể thư giãn và cảm thấy như ở nhà.

Không có số lượng hoàn hảo hoàn hảo sẽ khắc phục những thiếu sót của một nền văn hóa tổ chức xấu . Nhưng nếu bạn đã chú ý cho đến nay và có những bước tiến phù hợp, bước tiếp theo là thành lập các đội củng cố những lý tưởng văn hóa mà bạn đã đặt ra.

Nếu cần bổ trợ về kiến thức, bạn có thể tham khảo các khóa học lập trình Fullstack ngay hôm nay!

Xem thêm: 7 kỹ năng dành cho nhà phát triển web

LEAVE A REPLY

Please enter your comment!
Please enter your name here