Làm thế nào tôi có thể thuyết phục các nhà phát triển trong nhóm của mình nắm lấy phần mềm Bạn xây dựng nó, bạn điều hành nó?

Làm cách nào tôi có thể thuyết phục các nhà phát triển trong nhóm của mình nắm lấy "Bạn xây dựng nó, bạn chạy nó"? Do đó, tôi có ý kiến trích dẫn này từ Werner Vogels :

Trao cho các nhà phát triển trách nhiệm hoạt động đã nâng cao đáng kể chất lượng dịch vụ, cả từ quan điểm của khách hàng và quan điểm công nghệ. Mô hình truyền thống là bạn đưa phần mềm của bạn vào bức tường ngăn cách sự phát triển và hoạt động, và ném nó đi và sau đó quên nó đi. Không phải ở Amazon. Bạn xây dựng nó, bạn chạy nó. Điều này đưa các nhà phát triển tiếp xúc với hoạt động hàng ngày của phần mềm của họ. Nó cũng đưa họ tiếp xúc hàng ngày với khách hàng. Vòng phản hồi khách hàng này là điều cần thiết để cải thiện chất lượng dịch vụ.

Tôi đặc biệt nghĩ về một nhóm các nhà phát triển:

• Đã được thuê vào một vai trò nhà phát triển, với rất ít / không đề cập đến các nhiệm vụ liên quan đến ops.
• Theo truyền thống đã "ném mã trên tường" cho một nhóm ops.
• Theo truyền thống, có một lịch trình làm việc 9-5 và rất tích cực thù địch với ý tưởng "nhiệm vụ máy nhắn tin", tham gia khắc phục thảm họa, viết thư sau khi chết, v.v., đặc biệt là ngoài giờ làm việc bình thường. (Lưu ý: Tôi chỉ có những lần mất điện không thường xuyên trong vấn đề này; tôi không đề xuất rằng chúng tôi sẽ thêm hỗ trợ khách hàng sau giờ làm việc cho khối lượng công việc của nhóm này.)
• Hiện tại không chịu trách nhiệm viết / hỗ trợ giám sát hoặc cảnh báo về các ứng dụng của họ.

Giả sử có một nhóm đang phát triển nhanh chóng các dịch vụ vi mô đám mây mới với một hồ sơ sắp trở thành việc cung cấp các dịch vụ này cho nhóm ops là tối ưu vì họ không thể theo kịp để có được kiến ​​thức sâu về các dịch vụ được yêu cầu để quản lý và giám sát chúng một cách hiệu quả. "Bạn xây dựng nó, bạn chạy nó" sẽ hoạt động tốt hơn cho nhóm này vì các nhiệm vụ có thể được ủy quyền cho từng thành viên trong nhóm chịu trách nhiệm. Vì vậy, nhóm này sẽ bắt đầu tham gia thiết kế cơ sở hạ tầng, các công cụ giám sát / cảnh báo cho các dịch vụ và (rất không thường xuyên) phản ứng với các sự kiện ngừng hoạt động.

Tôi đặc biệt quan tâm đến các phương pháp, được hỗ trợ bởi các ví dụ trong thế giới thực. Làm thế nào điều này đã được thực hiện thành công ở nơi làm việc khác, và nếu có bất kỳ bước chính tắc nào để làm theo trong khi thực hiện điều này? Bất kỳ liên kết đến bài viết có thể hỗ trợ câu trả lời sẽ rất hữu ích.

Tôi nghĩ cách dễ nhất là thay đổi mục tiêu hiệu suất của họ để họ dựa trên độ tin cậy cũng như phân phối mã. Bán nó vì công ty không thể thành công mà không có cả hai, vậy tại sao các nhà phát triển chỉ nên được đo trên một? Cách tốt nhất để họ đạt được mục tiêu hiệu suất của họ là tham gia vào các hoạt động.

Cuối cùng, bạn cần thuyết phục họ đây là cách tốt nhất để công ty thành công và do đó để họ thành công. Điều đó thật khó khăn và bạn không thể mong đợi họ sẽ ở trên tàu ngay từ đầu. Họ cần phải được bán trên giá trị quá.

Khi nói đến ảnh hưởng đến văn hóa kinh doanh, cách tốt nhất có lẽ là thông qua phương pháp "luộc ếch" nổi tiếng. Bạn phải giới thiệu các nhiệm vụ này cho các nhà phát triển một cách từ từ, bởi vì tôi biết bản thân tôi (với tư cách là một nhà phát triển) sẽ chùn bước khi có tất cả trách nhiệm mới này cùng một lúc.

Đầu tiên, bắt đầu bằng cách giới thiệu một hoặc hai nhiệm vụ mới chỉ được thực hiện trong giờ làm việc bình thường. Họ cần học cách làm các devops, đó có thể là quá trình học tập cho một dev (đến thời điểm này) chỉ dành cho dev và có thể cần một số giám sát. Họ cũng có thể sẽ thù địch với ý tưởng thay đổi cân bằng cuộc sống công việc của họ kể từ khi bạn đề cập đến việc họ đã sử dụng đến 9-5. Tại thời điểm này, ghi lại dữ liệu về các quy trình mới để sử dụng sau này (yêu cầu họ viết mã này, dữ liệu luôn hữu ích).

Sau này khi bạn sắp hết nhiệm vụ devops-y mới để giới thiệu (vì vậy, các gạch đầu tiên thứ nhất, thứ hai và thứ tư gần như đã hoàn thành), hãy mang các nhiệm vụ đầu tiên bạn giới thiệu là ứng viên được thực hiện ngoài giờ làm việc tiêu chuẩn . Bạn có thể thấy một số phản ứng dữ dội về điều này và thậm chí bạn có thể thấy một số sự tiêu hao tùy thuộc vào mức độ bạn thúc đẩy mạnh mẽ như thế nào và văn hóa kết thúc công việc đã ăn sâu đến mức nào. Để chống lại điều này, hy vọng dữ liệu của bạn hỗ trợ ý tưởng rằng công việc ngoài giờ tiêu chuẩn sẽ rất hiếm, chỉ xảy ra trong các tình huống cực đoan và sẽ giúp ích rất nhiều cho cả doanh nghiệp và khách hàng. Nếu dữ liệu của bạn không hỗ trợ điều này, thì tốt hơn hết bạn nên sẵn sàng giải quyết hậu quả của lựa chọn này.

Ngay cả với dữ liệu, nó vẫn có thể được dễ dàng hơn để có các nhà phát triển viết các giám sát / cảnh báo mã (để họ trở nên dev ops nhưng vẫn chủ yếu là dev) và giữ đội ops thay thế như hỗ trợ ở tuyến đầu (như một vài người khác đã gợi ý). Như tôi đã nói, những thay đổi nhỏ rất quan trọng để tránh phản ứng dữ dội. Việc tích hợp công việc cho các nhà phát triển ngoài giờ tiêu chuẩn sẽ rất khó khăn, vì họ có thể biết rằng họ có thể tìm kiếm việc làm ở nơi khác nếu họ không thích vì thị trường dành cho nhà phát triển rất mạnh ngay bây giờ, đặc biệt là nếu họ đã có kỹ năng phát triển. Emptor caveat!

Nhìn bên ngoài DevOps cụ thể, nếu bạn đang nói về môi trường doanh nghiệp (ish) lớn thì phương pháp SAFe có một cách khá tốt để khuyến khích loại hành vi này.

Về cơ bản, nó sôi sục đến một vài giai đoạn chính:

• các dự án bắt đầu như các chuyến tàu phát hành. Mục đích (và kỳ vọng của bất cứ ai tài trợ cho nó) là nó sẽ được hoạt động lâu dài. Tôi đang nói chuyện nhiều năm, không ai trong số này "đứng lên một đội trong 3 tháng rồi đứng xuống" doanh nghiệp.

• trong quá trình thực hiện dự án, đoàn tàu phát hành chắc chắn sẽ thu hút được nhiều người hơn vì cả hai yêu cầu dự án mới dựa trên các cơ hội kinh doanh mới được thực hiện cũng như thuế liên tục của công việc theo phong cách bảo trì.

• Tôi hầu như luôn thấy các đoàn tàu chạy mức tăng đầu tiên của họ là 100% nhóm dự án / thay đổi, lần tăng thứ 2 họ phân bổ phần trăm thời gian để Chạy công việc. Quản lý gia tăng thứ 3 nhận ra rằng họ sắp gặp sự cố và bắt đầu thêm các nhóm để thử và xử lý tràn Run để cho các nhà phát triển và kỹ sư dày dạn kinh nghiệm của họ có thời gian tiếp tục làm việc theo yêu cầu mới.

• nếu sự cân bằng phù hợp xảy ra với các nhóm dự án có thể tiếp tục cung cấp kết quả dự án mà không bị sa lầy vào công việc bảo trì và các nhóm mới tham gia tàu không ngay lập tức sẽ chỉ là nhóm hỗ trợ 100%, nhưng thay vào đó hãy tham gia một phần công bằng của công việc thay đổi sẽ được xử lý sau đó bạn kết thúc với các nhóm giao hàng đang sở hữu các sản phẩm họ đang xây dựng theo mặc định, không cần phải đến với họ ngay bây giờ mà bây giờ họ là nhóm Run, thay vào đó nó chỉ từ từ tích hợp vào các hoạt động hàng ngày của họ.

Trường hợp mô hình này rõ ràng có một số điểm yếu là trong việc định giá cho một doanh nghiệp. Nói chung, tôi hy vọng sẽ trả nhiều tiền hơn cho tài nguyên thay đổi so với tài nguyên đang chạy, thường chạy hợp đồng với các nhà cung cấp lớn là giá cố định và mục đích là họ kiếm tiền từ việc cải tiến liên tục và do đó tiết kiệm chi phí.

Điều đó đang được nói, không khó để xem xét các nhóm thay đổi đã đứng lên như một phần của chuyến tàu phát hành để đơn giản là cung cấp các cải tiến liên tục. Nếu có một cái gì đó họ có thể xây dựng hoặc làm để cải thiện khả năng tập trung vào việc giao dự án mới và ít quan tâm đến công việc "kinh doanh như bình thường" thì điều đó nên được đăng ký và ưu tiên dựa trên lợi ích nhận thức của bất kỳ ai giữ tiền cho phát hành tàu.

IMHO You build it, you run itkhông nên được thực hiện theo nghĩa đen. Để bắt đầu - nó gần như là một hình phạt;)

Không một người hay nhóm nhà phát triển nhỏ nào có thể hỗ trợ hợp lý một công cụ hoặc bộ công cụ được sử dụng trong quy trình phát triển phần mềm (nghĩa là trong sản xuất!) Trong thời gian dài. Đã từng trải qua rồi :)

Nhiệm vụ hỗ trợ có xu hướng mở rộng khi công cụ (bộ) cơ sở khách hàng phát triển. Nếu đảm nhận những nhiệm vụ đó, nhóm phát triển cuối cùng có thể hỗ trợ, hầu như không còn thời gian để phát triển. Thực sự là một ngõ cụt - có bao nhiêu nhà phát triển muốn gắn bó trong môi trường như vậy?

Có một đội ngũ hỗ trợ chuyên nghiệp đầu tiên là rất quan trọng để ngăn chặn sự thất vọng, căng thẳng và các tác động khác của việc tiếp xúc lâu dài với các nhiệm vụ hỗ trợ đối với các thành viên nhóm phát triển của bạn.

Tất nhiên, nhóm hỗ trợ dòng 1 sẽ dự phòng cho nhóm nhà phát triển (một lần nữa, nhóm, không phải là người độc thân!) Cho các vấn đề mà họ không thể giải quyết trực tiếp. Vâng, ban đầu có thể khó khăn, nhưng mọi thứ sẽ trở nên tốt hơn. Nó phải là một sự hợp tác - đó là một phần của những gì DevOps nói về.

Điều này cuối cùng phụ thuộc vào quy mô và cấu trúc của công ty. Có ba giai đoạn thực sự mà công ty của bạn có thể tham gia:

1. Giai đoạn khởi động (dưới 150 kỹ sư). Tất nhiên, các nhà phát triển cần phải chạy phần mềm của riêng họ. Mọi người đều làm như vậy trong một khởi nghiệp. Bạn thậm chí có thể không có nhóm vận hành để bắt đầu, nhưng ngay cả khi bạn làm, nó rất nhỏ và tốc độ tiến bộ nhanh đến mức không có cách nào truyền đạt kiến ​​thức cần thiết để chạy nó thành công cho nhóm khác đủ nhanh để họ thành công.

2. Các doanh nghiệp có quy mô trung bình (hơn 150 kỹ sư, nhưng một nhóm hoạt động duy nhất). Ở giai đoạn này, công việc trong công ty bắt đầu quá cao, các kỹ sư xây dựng phần mềm không nhất thiết phải chạy xung quanh để chạy nó. Bạn không biết tất cả mọi người nữa và thật khó để giao tiếp hiệu quả cho mọi người trong hoạt động. Nó sẽ bắt đầu biến thành hỗn loạn. Ở giai đoạn này, bạn muốn chuyển sang mô hình Google, nơi mọi nhóm phải vận hành phần mềm của họ, nhưng không nhất thiết phải vận hành nó. Họ sẽ vận hành nó khi bắt đầu, nhưng một phần lớn của việc xây dựng phần mềm là giảm chi phí vận hành đến một điểm, trong đó tải đủ nhỏ để nhóm vận hành có thể đăng nhập để chạy nó. Chỉ sau đó nó được coi là thực hiện.

3. Doanh nghiệp lớn với nhiều đơn vị kinh doanh, (mỗi đơn vị có nhóm hoạt động riêng): Ở giai đoạn này, bạn có thể quay lại mô hình Amazon, nơi mọi nhóm thiết yếu phát triển và vận hành các dịch vụ riêng của họ. Mỗi đơn vị kinh doanh phải đủ nhỏ để mọi người biết nhau, vì vậy, dưới 150 kỹ sư và bạn vận hành mỗi cơ bản như một công ty khởi nghiệp. Amazon có mỗi dịch vụ AWS hoạt động riêng biệt ít nhiều và nó hoạt động cho họ.

Bạn phải tìm ra giai đoạn nào công ty của bạn đang ở và / hoặc chuyển sang và hành động phù hợp. Không có giải pháp "một kích thước phù hợp với tất cả".

Tôi đảm nhận việc này (nếu tôi phải đối mặt với điều răn như vậy, hoặc bất cứ điều gì bạn gọi nó), sẽ là một cái gì đó như " What else would you expect?!?!". Bởi vì, vô tình:

• Tôi thậm chí sẽ không thể sống mà không có nó, và
• Tôi thích ăn thức ăn (chó) của riêng tôi.

Hãy để tôi giải thích thêm một chút ...

Kinh doanh / sở thích / đam mê của tôi là scm , cụ thể hơn là trong môi trường máy tính lớn . Và bất cứ nơi nào tôi đi (để hoàn thiện công cụ phù hợp với nhu cầu của khách hàng), yêu cầu đầu tiên mà tôi áp đặt (trong hợp đồng của tôi), là bất kỳ điều chỉnh nào được thực hiện cho hệ thống chúng tôi thực hiện, đều thông qua hệ thống đó. Và bằng cách làm như vậy (đúng, mất khoảng vài giờ, tối đa là nửa ngày), chúng tôi nhận được những lợi ích này từ nó (danh sách không đầy đủ):

• Tôi hầu như không làm tài liệu gì tôi đã làm để hệ thống hoạt động. Nếu có bất kỳ câu hỏi nào, tôi chỉ cần truy vấn hệ thống (và hướng dẫn khách hàng cách truy vấn hệ thống mà không cần sự giúp đỡ của tôi).
• Nếu tôi được gọi trong X tháng / năm (để nâng cấp lên bản phát hành mới?), Tôi muốn biết (hãy nhớ) những gì "tôi" đã làm trước đây (và điều duy nhất tôi tin là hệ thống nói với tôi, aka nhắc tôi về).
• Tôi chỉ cần hỏi khách hàng một lần về cách thực hiện những điều cụ thể trong trang web của họ (quy ước đặt tên rất khó nhớ) hoặc thuyết phục họ cấp quyền yêu cầu cho "hệ thống" (không phải cho tôi ...).
• Bạn continuously kiểm tra QA hệ thống của riêng bạn ... trong sản xuất. Rất có thể là bạn sẽ gặp lỗi, lỗi logic hoặc thiếu tính năng (và những gì không). Và những người cực kỳ có động lực để khiến họ giải quyết càng sớm càng tốt ... ví dụ để trở nên năng suất hơn.
• ... và nếu bạn muốn tôi có thể thêm hàng tá lý do ...

Tuy nhiên, trước khi bạn tự thử điều này ở nhà, hãy lưu ý một số cạm bẫy cần tránh:

• bạn muốn mọi người tham gia bữa tiệc (sử dụng hệ thống), vì chỉ có 1 "ngoại lệ" (còn gọi là người quản lý / chủ sở hữu công ty?) có thể phá hỏng bữa tiệc (bạn nghĩ rằng bạn có thể tin tưởng vào hệ thống của mình, nhưng sau đó ai đó đã làm gì đó mà không hỏi / sử dụng hệ thống). Những trường hợp đó có thể khiến bạn mất nhiều ngày để khám phá ...
• người dùng mới có thể phàn nàn rằng bằng cách sử dụng hệ thống (mới) này, họ sẽ mất nhiều thời gian hơn để hoàn thành công việc (so với bất kỳ điều gì họ đã sử dụng trước đây). Và bất cứ nơi nào có ý nghĩa, họ sẽ sử dụng nó như một cái cớ tại sao họ đến trễ để hoàn thành công việc của họ. Tại thời điểm đó, tốt hơn hết là bạn nên quản lý cấp trên bảo vệ bạn, bởi vì nếu không thì dự án / hệ thống của bạn có thể bị đổ lỗi.
• đảm bảo bạn biết hệ thống của riêng mình và cách định cấu hình để phù hợp với nhu cầu của bạn. Như một ví dụ (trong trường hợp của tôi): bạn muốn định cấu hình hệ thống để bạn sử dụng môi trường hoạt động để phân phối đến môi trường thử nghiệm của mình và không phải là cách khác ... Tôi đã thấy điều đó xảy ra trong quá khứ ... sử dụng (lạm dụng) hệ thống kiểm tra để phân phối đến các môi trường được bảo mật cao.