Tôi vừa nói chuyện với một anh chàng DevOps, người đã nêu ra một số điểm thực sự tốt về các cuộc đấu tranh để trở thành một Kỹ sư DevOps và đôi khi cảm thấy như một đội quân một người, mặc dù anh ta ở trong một nhóm 16 Kỹ sư.

Anh ta đội rất nhiều chiếc mũ khác nhau, nhưng ngồi trong nhóm Phát triển làm công việc cơ sở hạ tầng. Anh ấy yêu công nghệ tuyệt vời mà anh ấy phải làm việc với vô số tự động hóa, đám mây, container, v.v. Nhưng anh ấy đấu tranh rằng anh ấy là người duy nhất làm ops, trong một devnhóm. Anh ta báo cáo cho Giám đốc phát triển, nhưng làm việc chặt chẽ hơn với Giám đốc cơ sở hạ tầng.

Đây có vẻ là trường hợp với rất nhiều chuyên gia DevOps mà tôi nói chuyện. Những gì có thể được thực hiện để giúp các Kỹ sư DevOps cảm thấy không giống như một con sói đơn độc?

Suy nghĩ đầu tiên của tôi là "tại sao anh ấy là người duy nhất làm ops, trong một nhóm phát triển, đặc biệt là khi anh ấy làm việc với vô số tự động hóa?". Tôi nghĩ rằng có một cơ hội ở đó để giải quyết hội chứng sói đơn độc; đặc biệt trong môi trường dev, cơ sở hạ tầng dưới dạng mã cung cấp một khung tuyệt vời để chia sẻ tải. Người Ops nên là chuyên gia trong việc xác định và xác định nhu cầu cơ sở hạ tầng cho ứng dụng, nhưng họ cũng có thể xây dựng một nền tảng để cho các vai trò dev làm nhiều nhất có thể một cách độc lập.

Nghe có vẻ như một silo trong một đội; thói quen cũ khó thay đổi. Một lập trình viên có thể không cảm thấy thoải mái khi quay và làm cứng máy chủ, nhưng trong mô hình devops thuần túy, họ nên có các công cụ để làm việc đó. Một người trong nhóm phát triển không chịu trách nhiệm cung cấp cơ sở hạ tầng cho chính ứng dụng, nhưng họ nên cung cấp một số thông tin chi tiết về những gì cần thiết và một số hướng dẫn về cách các nhà phát triển ứng dụng có thể tự làm điều đó. Nó gần như là một mô hình cơ sở hạ tầng meta; Các kỹ sư của ops xây dựng cơ sở hạ tầng có thể xây dựng cơ sở hạ tầng theo yêu cầu khi nhóm phát triển yêu cầu.

Tư vấn, giao tiếp và pha trộn các trách nhiệm đều rất quan trọng đối với sự thành công của một nhóm sùng đạo.

Tôi nghĩ lỗ hổng đầu tiên là trong câu này:

Anh ta báo cáo cho Giám đốc phát triển, nhưng làm việc chặt chẽ hơn với Giám đốc cơ sở hạ tầng.

DevOps là một sự thay đổi văn hóa nhằm loại bỏ silo. Nếu silo vẫn còn, thì kỹ sư này là bất cứ điều gì bạn muốn đặt tên hãy gọi anh ta; một kỹ sư đang phát triển vận hành, một chuyên gia tự động hóa, một nhà phát triển tự động hóa cơ sở hạ tầng - nhưng kỹ sư này không phải là kỹ sư DevOps.
Trên thực tế, "Kỹ sư DevOps" không phải là một vai trò thực sự , nó giống như một "chapeau" vì nó có thể bao gồm các nhà phát triển, quản trị hệ thống, người kiểm tra QA và kiến ​​trúc sư làm việc trong một nhóm chung.

Một vấn đề tôi thường thấy là mọi người rơi vào việc sử dụng từ thông dụng của DevOps, coi đó là một chức danh công việc, nhưng họ không thực sự hiểu DevOps là gì. Bằng cách xem DevOps theo cách này, họ thường bị cô lập và cảm thấy cô đơn, đổ lỗi cho những thất bại và thiếu sót khi trở thành một "con sói đơn độc" mà không có sự mua lại của người quản lý và tổ chức.

Như bạn mô tả, kỹ sư này là người duy nhất thực hiện Ops trong nhóm Dev. Điều đó không làm cho anh ta trở thành một "kỹ sư DevOps". (Dù điều đó có nghĩa là gì trong tổ chức của anh ấy) Anh ấy làm việc một mình vì công việc được trình bày là "Kỹ sư DevOps" nhưng có vẻ như những người khác trong nhóm của anh ấy không muốn làm việc trên các hoạt động.

Hãy thành thật mà nói, sẽ luôn có ops và dev, ý tưởng chính của các dev là chia sẻ trách nhiệm sao cho không có sự bàn giao sản phẩm nào từ dev đến ops hay chỉ cung cấp nền tảng bởi ops cho dev. Mục tiêu chính là mang lại sự hợp tác nhiều hơn vào một nhóm. Gọi vai trò này là "Kỹ sư DevOps" đang phá vỡ ý tưởng này bằng cách gợi ý trong tên bạn có thể làm cả hai ở cùng một trình độ chuyên môn - điều này hiếm khi đúng.

Theo tôi, việc đầu tiên cần làm là trình bày các công cụ vận hành cho nhóm và cung cấp cho mọi người kiến ​​thức cơ bản về các công cụ, sau đó chuyển giao trách nhiệm cấu hình / mã hóa các công cụ vận hành cho toàn nhóm. Ý tưởng chính đằng sau điều này là chuyển từ "người làm tất cả mọi việc" sang "người hỗ trợ và đưa ra các tham chiếu triển khai cho nhóm".

Điều này bổ sung cho các câu trả lời khác bằng cách cung cấp một cái gì đó có thể hành động theo cách đơn giản như bước đầu tiên hơn là tổ chức lại quản lý.

Điều quan trọng nhất đối với các Kỹ sư DevOps trong các tình huống này, là nhận được (a) Cam kết quản lý và (b) Ngân sách bắt buộc . Đọc để biết thêm chi tiết về cả ...

Nhận cam kết quản lý

Khi đã có, mọi thứ trở nên dễ dàng đối với các kỹ sư DevOps như vậy. Đặc biệt là bất cứ khi nào kháng chiến (từ tất cả các loại bên) vào trò chơi. Tin tôi đi, sẽ có những cuộc kháng chiến như vậy, đó là những thách thức như:

• Tại sao chúng ta phải thay đổi? Tôi muốn tiếp tục làm những gì tôi đã làm trong X năm rồi!
• Tôi không muốn mất năng lượng (kỹ thuật) mà tôi có và hoàn thành tất cả các quy trình xử lý công việc, để có một bản sửa lỗi ngớ ngẩn trong sản xuất, tôi sẽ mất 5 phút thay vì 5 giờ (hoặc vài ngày ...).
• ... (Tôi có thể thêm một tá đạn nữa ở đây ...).

Bất cứ khi nào những thách thức đó xuất hiện, tất cả một kỹ sư DevOps nên nói là như sau:

Tôi xin lỗi, tôi chỉ đang làm công việc của mình ... dựa trên hướng dẫn của quản lý cấp trên.

Nhận ngân sách cần thiết

Một cách hiệu quả để có được Ngân sách cần thiết, là tạo / gửi trường hợp kinh doanh phù hợp giải thích các lợi ích hữu hình và vô hình của các thực tiễn DevOps khác nhau bằng cách áp dụng chúng cho một số trường hợp thực tế áp dụng cho chính công ty.

Dưới đây là một số trường hợp thực tế mà tôi tự trải nghiệm, như một chuyên gia tư vấn SCM được thuê bởi một số công ty nơi những điều này đã xảy ra. Tôi biết, SCM chỉ là một phần của DevOps, nhưng đó là lĩnh vực mà tôi có một số kinh nghiệm ...

1. Lợi ích của tự động hóa

Do một số cuộc đình công chỉ từ 2 nhà khai thác máy tính (không gõ lệnh điều khiển nữa mà họ dự kiến ​​sẽ nhập), các đoàn tàu đã phải dừng lại ở đâu đó giữa hai nhà máy (vì hệ thống tại nhà máy nơi tàu đang đi xuống, dữ liệu quan trọng về việc xử lý tàu không có sẵn).

Bằng cách thực hiện một hệ thống SCM, nhiều lệnh toán tử đã được tự động hóa.

2. Giảm chi phí bản quyền phần mềm

Một số nhà cung cấp phần mềm đã quyết định tăng một số phí hàng năm cho phần mềm SCM (lỗi thời) mà ban quản lý không đồng ý. Do đó, họ đã tạo ra một dự án đặc biệt để thay thế nó bằng một số phần mềm SCM thay thế.

Ngân sách của dự án bằng với phí hàng năm mà họ không muốn tiếp tục trả. Điều đó bao gồm bay trong các kỹ sư từ các châu lục khác (như tôi) để làm cho dự án thành công.

3. Giảm chi phí vận hành

Một số công ty bảo hiểm lớn đã sử dụng một số phần mềm FTP để chuyển các bản sửa lỗi phần mềm cho khoảng 13.000 máy tính tầm trung (AS / 400) trên toàn quốc và điều này bất cứ khi nào có "sửa". Chi phí cho 1 lần chuyển như vậy là khoảng 4 USD (13.000 x 4 = 52.000 USD cho một lần chuyển ...). Phần mềm bao gồm 120.000 thành phần, được phát triển / duy trì bởi khoảng 150 nhà phát triển. Làm toán về xác suất mà 1 nhà phát triển đã mắc 1 (nhỏ) trong bất kỳ 120.000 thành phần nào trong số này, khiến nó được sản xuất và yêu cầu sửa chữa khẩn cấp, sẽ tốn thêm 52.000 USD (chỉ cho việc chuyển nhượng!).

Bằng cách thực hiện một hệ thống SCM đầy đủ (với các môi trường kiểm tra được phê duyệt, phê duyệt, v.v.), công ty này đã đạt được mức giảm chi phí lớn. Hãy suy nghĩ về điều này, nếu hệ thống SCM có thể ngăn chặn chỉ cần 20 lần chuyển các bản sửa lỗi khẩn cấp, thì nó đã giúp giảm chi phí 52.000 x 20 = 1.040.000 USD (khá ngân sách để thực hiện hệ thống SCM, họ chỉ cần một phần nhỏ số tiền đó để hoàn thành công việc).

4. Giảm chi phí không có sẵn

Nếu các trường hợp trên không đủ sức thuyết phục, thì hãy nghĩ đến (các) hệ thống của một công ty thẻ tín dụng lớn không có sẵn trên toàn thế giới. Tôi đã được thông báo rằng 1 giây không có sẵn có giá 1.000.000 USD.

Đó có lẽ cũng là lý do tại sao, trong một thời gian rất dài, các công ty như vậy đã có các công cụ DevOps tinh vi, trong nhiều thập kỷ. Bởi vì mỗi giây họ không kinh doanh đều khiến họ phải trả giá.

TL; DR: Vì quản lý cấp trên thường hay thay đổi và dễ nổi giận, tôi khuyên bạn nên cố gắng uốn cong đầu óc một chút để có một quan điểm khác, đồng thời thay đổi mọi thứ tốt hơn, dần dần.

(Tôi cho rằng rắc rối của anh ấy chủ yếu là với các nhà phát triển bất đắc dĩ , chứ không phải các đồng nghiệp op khác của anh ấy dường như thực hiện các hoạt động cổ điển là chủ yếu.)

IMO, ngay cả khi bạn có DevOps, điều đó không nhất thiết có nghĩa là mọi nhà phát triển cần phải là một bậc thầy DevOps chính thức. Tôi thấy khá bình thường rằng sẽ có một hoặc hai chuyên gia thực sự trong một nhóm người nhất định và phần còn lại ít nhiều gắn thẻ. Miễn là khối lượng công việc không quá lớn đối với anh chàng đó, và miễn là anh ta xoay sở để gói gọn kiến ​​thức của mình trong các kịch bản, v.v. thay vì xây dựng silo của riêng mình, điều đó cũng ổn với tôi.

Một điều không nên xảy ra là anh chàng DevOps tự động hóa và mọi người khác cố gắng hết sức để tránh tự động hóa (ví dụ, đi qua đường ống CI / CD và làm thủ công trong một trong các môi trường). Điều này, IMO là điều chính phải dừng lại. Một giải pháp cho điều đó là thúc đẩy mạnh mẽ phương pháp tiếp cận không phải là vật nuôi của gia súc, tức là không ngừng xé nát máy ảo hoặc thùng chứa bên trái và bên phải ngay khi bạn có thể, và liên tục quay những cái mới.

Thứ hai, tất nhiên mọi người cần phải nhận thức được những gì tự động hóa đang làm, và ít nhất là về mặt lý thuyết, với một số hoạt động có thể, có thể khởi động máy móc tự động hóa (nghĩa là, nếu mọi thứ chạy từ một cam kết / đẩy, thì các nhà phát triển cần phải nhận thức và cập nhật rất nhiều với thực tế là sẽ có những thứ xảy ra trong nền khi họ cam kết). Đường ống CI (/ CD) cần phải được nhìn thấy rõ và phải là điều mọi người thường xuyên nhận thức được (tức là khi một nhà phát triển phá vỡ nó).

Thứ ba, "một chàng trai" tất nhiên phải coi chừng rằng anh ta không thực hiện các nhiệm vụ hàng ngày, nguy hiểm cho đồng nghiệp của mình (ví dụ: tạo Dockerfile sau Dockerfile cho các tạo tác của họ ...).

Thứ tư, các giải pháp mà anh chàng DevOps tạo ra tất nhiên phải thực sự vượt trội so với các phương pháp thủ công trong quá khứ theo một cách có thể đo lường được. Trong trường hợp đó, anh ta có thể chứng minh những cải tiến của mình; tức là, chứng minh làm thế nào mọi thứ trở nên dễ dàng hơn với mọi người, hoặc dường như không thể giới thiệu các lỗi trong giai đoạn sau của đường ống, v.v ... Nếu điều này dường như không thể, thì anh chàng DevOps cần phải xem xét kỹ những gì anh ấy đang làm Nếu có thể, điều đó kêu gọi các phiên brownbag và rất nhiều việc truyền giáo trong đội của anh ấy.

Rõ ràng, trong một môi trường miễn cưỡng như vậy, có thể bạn sẽ không đến với một giải pháp CD hoàn toàn tự động, hoặc phát triển dựa trên thân cây bất cứ lúc nào sớm. Nhưng tôi sẽ không lo lắng quá nhiều về việc bị độc thân. Anh ấy là chuyên gia, và nếu anh ấy làm tốt công việc của mình, toàn đội sẽ dần dần cải thiện.

Và cuối cùng, nếu sau nhiều năm và nhiều năm không có sự cải thiện rõ rệt với các đồng nghiệp của mình, bạn luôn có thể tìm kiếm các con đường khác (có thể là trong hoặc ngoài công ty). Có tất cả những gì DevOps trải nghiệm dưới vành đai của anh ấy là cơ sở tuyệt vời để tìm kiếm một công việc, những ngày này ...

Tôi thấy rất nhiều câu trả lời tuyệt vời ở đây khi nói về DevOps như một văn hóa, những gợi ý về cách làm việc với quản lý và giúp xác định những việc cần làm của một nhóm hoặc kỹ sư DevOps. Tôi nghĩ rằng mỗi câu hỏi đều tuyệt vời và thực sự minh họa cho nhiều câu trả lời có thể đúng 100%, và vẫn rất khác nhau, hoặc thậm chí hoàn toàn mơ hồ, với nhau ... Đó là DevOps!

Câu trả lời này chỉ là quan điểm độc đáo của tôi từ kinh nghiệm, và có thể không phải là biểu hiện của các tiêu chuẩn hoặc thực tiễn tốt nhất ...

Nhưng điều mà đồng nghiệp DevOps của bạn phàn nàn là chính bản chất của điều khiến DevOps gặp nhiều thách thức và khó khăn , đặc biệt là khi được bổ nhiệm vai trò kỹ sư DevOps, và không chỉ đơn giản là một tư duy văn hóa.

Cá nhân, tôi thích trở thành một con sói đơn độc, bởi vì tôi vẫn có những đóng góp có giá trị, nhưng cũng có thể đặt ra giới hạn của riêng mình, trong khi thuyết phục người khác tự giúp mình, từ đó giúp tôi phá vỡ các silo CNTT.

Một số silo vẫn còn nguyên vẹn và không sao, đó là nhiệm vụ của DevOps để giải quyết vấn đề đó và cố gắng làm cho các silo đó trở nên vô nghĩa hoặc vô hình nhất có thể.

Có thể đồng nghiệp của bạn có thể nhận ra hoặc chưa nhận ra rằng họ không thích trở thành kỹ sư của DevOps .

Nói một cách tương đối, khái niệm của các tín đồ là mới và vẫn tự xác định theo ý kiến ​​của tôi. Tôi hiện đang hoàn thành một vai trò kỹ sư devops. Đối với tôi, điều này có nghĩa là tôi tạo điều kiện và phát triển các công cụ và quy trình được sử dụng bởi cả nhóm phát triển và nhóm của chúng tôi để họ tập trung vào sản phẩm tạo ra doanh thu cho công ty. Các nhóm op và dev quay lên các máy chủ của riêng họ và như vậy là cần thiết. Tôi chỉ kết nối CI cho các sản phẩm của chúng tôi, đảm bảo các quy trình của chúng tôi có ý nghĩa và tìm kiếm quy trình nào có thể được cải thiện / tự động. Tôi gặp tất cả các bộ phận của chúng tôi, từ bán hàng, kho, đến nhà phát triển và vận hành (QA và quản lý phát hành) để xem họ đang làm gì và làm thế nào tôi có thể cải thiện quy trình của họ.

Đối với tôi, DevOps có nghĩa là việc phát triển và vận hành một hệ thống phần mềm trở thành trách nhiệm của một nhóm, thay vì các nhóm phát triển và op riêng biệt. Đây là một con đường hai chiều. Các đội giỏi nhất được tạo thành từ những người " hình chữ T ", những người là chuyên gia trong một lĩnh vực và quen thuộc với một số lĩnh vực liên quan.

• Các thành viên trong nhóm có kinh nghiệm Ops được mong đợi sẽ làm những gì họ làm tốt nhất (ví dụ như Ops), để dạy các nguyên tắc cơ bản về những gì họ làm tốt nhất (ví dụ như Ops) cho những người khác và học và làm các công việc trong các lĩnh vực liên quan (ví dụ: nhiệm vụ Dev).
• Các thành viên trong nhóm có kinh nghiệm Dev dự kiến ​​sẽ làm những gì họ làm tốt nhất (ví dụ như Dev), để dạy các nguyên tắc cơ bản về những gì họ làm tốt nhất (ví dụ như Dev) cho những người khác và học và làm các công việc trong các lĩnh vực liên quan (ví dụ: nhiệm vụ Ops).

Vì vậy, để làm cho kỹ sư DevOps cảm thấy không giống một con sói đơn độc, hãy mời anh ta dạy cho các nhà phát triển cách vận hành các hệ thống, đồng thời thừa nhận rằng anh ta là chuyên gia về cách thiết kế cơ sở hạ tầng.

Khiến anh ta tham gia vào kiến ​​trúc cấp cao ngay từ đầu, để anh ta có thể giới thiệu những mối quan tâm về chuyên môn của mình. (Trước khi chúng tôi có DevOps, các bản vẽ kiến ​​trúc của chúng tôi luôn che đậy "những điều nhỏ nhặt" như bộ cân bằng tải và máy chủ dự phòng. Bây giờ những thứ như vậy là một phần của bản phác thảo đầu tiên.)

Hy vọng các Dev sẽ thực hiện một số nhiệm vụ Ops hàng ngày, cả hai để xây dựng dự phòng vào nhóm và truyền bá công việc "vét" một cách công bằng.

Hy vọng anh ta sẽ đóng góp cho nỗ lực Dev nếu không có nhiệm vụ nào giống Ops được thực hiện. Một số DevOps tôi biết dường như tìm thấy cơ sở dữ liệu hoạt động mở rộng tự nhiên trong lĩnh vực chuyên môn của họ, không chắc điều đó có thể được khái quát hóa hay không.

Những gì có thể được thực hiện để giúp các Kỹ sư DevOps cảm thấy không giống như một con sói đơn độc?

Để diễn giải - những gì một kỹ sư DevOps có thể làm mình / mình cảm thấy ít giống như một con sói đơn độc?

Thiếu văn hóa và hỗ trợ quản lý chỉ là một phần của phương trình. Phần khác theo ý kiến ​​của tôi là kiến ​​thức chi tiết DevOps thường đề cập đến bối cảnh phức tạp và điều quan trọng là phải có lời khuyên và tham khảo các ví dụ làm việc.

Do đó - đừng cảm thấy như một con sói đơn độc; tham gia vào các cộng đồng DevOps như thế này tại đây hoặc các nhóm dành riêng cho công cụ và GitHub - cảm giác ít nhất là bạn không phải là con sói đơn độc duy nhất ;-)