Ưu / nhược điểm của việc ngừng quy trình làm việc DevOps?

Tôi đang cố gắng đánh giá xem có nên chuyển từ quy trình làm việc theo kiểu sùng đạo sang dev-then-op truyền thống hay không (không chắc bạn gọi đó là gì).

Chúng tôi là một bộ phận nhỏ gồm 5 người nằm trong một công ty truyền thông truyền thống 4000 nhân viên (ví dụ như không phải phần mềm). Hai năm trước, chúng tôi đã bắt đầu xây dựng phần mềm để cho phép bộ phận của chúng tôi tăng quy mô sản xuất đáng kể. Chúng tôi đã khá thành công và công ty lớn hơn đang bắt đầu chú ý. Cho đến nay, chúng tôi chỉ chịu trách nhiệm thiết kế, phát triển và triển khai những gì đã trở thành một nền tảng dịch vụ AWS ~ 10 dịch vụ. Nhóm của chúng tôi không xác định là DevOps, nhưng không nghi ngờ gì, chúng tôi đang sống cuộc sống DevOps, với mỗi nhà phát triển quen thuộc với cả mã và hệ thống mà nó chạy.

Một trong những câu hỏi chúng tôi sẽ phải đối mặt sớm là "hiệu quả" được chia sẻ giữa chúng tôi và bộ phận CNTT cho công ty mẹ của chúng tôi. Chủ dự án của chúng tôi thường thích thuê ngoài hơn học tập trong nhà, vì vậy trong trường hợp của chúng tôi, những hiệu quả này có thể có nghĩa là nhận được càng nhiều công việc CNTT "ra khỏi đĩa" càng tốt. Hiện tại, tôi muốn nói rằng nhóm của chúng tôi có sự phân chia 70/30% giữa kinh nghiệm về mã hóa và cơ sở hạ tầng. Bộ phận CNTT vững chắc trong lĩnh vực CNTT, không có sự giao thoa rõ ràng trong phát triển phần mềm.

Chủ dự án của chúng tôi (một cá nhân phi kỹ thuật) hy vọng rằng bằng cách bàn giao càng nhiều công việc càng tốt cho nhóm CNTT, chúng tôi sẽ thấy năng suất tăng 1: 1 cho mỗi giờ hoạt động mà chúng tôi làm việc. Tôi nghi ngờ về điều này mặc dù. Sản phẩm của chúng tôi vẫn là bản beta (mặc dù đã là một tài sản kinh doanh quan trọng) và theo kinh nghiệm hạn chế của chúng tôi với bộ phận CNTT, thường có sự chậm trễ đáng kể cho những việc đơn giản như thay đổi quyền hệ thống tệp.

Ngay bây giờ, giải pháp lý tưởng của tôi sẽ là cho bộ phận CNTT "thông qua" chúng tôi và cho phép chúng tôi tiếp tục triển khai công việc của mình, đồng thời đảm bảo rằng chúng tôi đáp ứng các tiêu chuẩn và yêu cầu của văn phòng CNTT. Tôi không chắc nó thực tế như thế nào. Thêm vào đó, nó gần như là cách tiếp cận ngược lại, chủ dự án của chúng tôi đang ủng hộ vì nó sẽ bổ sung thêm các hoạt động bổ sung trong thời gian ngắn.

Trong tình huống của chúng tôi, những ưu / nhược điểm có thể có của phương pháp DevOps so với việc đưa ra CNTT là gì?

Nó không phải là một ý tưởng tốt.

Theo kinh nghiệm của tôi, bạn sẽ đạt được những nhược điểm của cả hai trong khi bất kỳ lợi thế dự kiến ​​nào bằng cách nào đó sẽ không thành hiện thực.

Phân loại

1. Bạn sẽ mất tốc độ.
   CNTT sẽ tuân thủ tiêu chuẩn riêng của họ. Nhiệm vụ mới (đối với họ) sẽ tuân theo cùng một mẫu 'chậm chạp' mà tất cả công việc của họ hiện có. Hãy chuẩn bị sẵn sàng họ sẽ thấy nó đầy thách thức - vì vậy tốc độ thậm chí còn thấp hơn các hành động đơn giản tiêu chuẩn.
2. Bạn sẽ không giảm tải.
   CNTT sẽ dựa vào các bạn cho mọi dị thường. Bạn sẽ nỗ lực để tăng tốc một chàng trai - và điều tiếp theo bây giờ bạn sẽ lặp lại vì nhiệm vụ / vấn đề / ngày sau đây sẽ lại có một chàng trai mới.
3. Tài liệu sẽ được yêu cầu, nhưng nó sẽ không giúp đỡ.
   Một lần nữa hành vi mẫu sẽ là các hướng dẫn ngắn sẽ không bắt được mọi sự bất thường và các văn bản kỹ lưỡng sẽ không được đọc vì quá dài. Vì vậy, bất kỳ khoản đầu tư nào ở đây sẽ là một mất mát, tương tự như vậy, nỗ lực to lớn cần thiết để thực hiện các cải tiến để đưa các công cụ của bạn trở nên hoàn hảo hơn.

Cuối cùng nhưng không kém phần quan trọng sẽ phản ánh về các bạn. Tar, nguyên tắc tarbrush.

Nếu những điều trên nghe có vẻ hoài nghi, thì tôi sợ rằng tôi đã ở đó. Nhiều lần.

Thay vào đó, phải làm gì?

Đi mua sắm trong bộ phận CNTT, tìm cho mình một ứng cử viên hữu ích và giữ cho anh chàng này 'cho mượn' để giảm bớt khối lượng công việc của bạn.

Bạn có thể tìm thấy nhiều câu trả lời trong kết quả khảo sát DevOps mà bạn nên yêu cầu chủ sở hữu sản phẩm đọc. Đây là một tài liệu được viết riêng cho những người kinh doanh có ít kiến ​​thức kỹ thuật nói về các thuật ngữ anh ta nên hiểu.

Trung bình bạn sẽ cần thêm 1 nhà phát triển cho mỗi 4 người để giữ mức phát triển tính năng như nhau (38% so với 49% thời gian dành cho công việc mới). Thời gian trung bình của bạn để phục hồi từ thất bại sẽ giảm xuống tới 25 lần. Công việc của bạn sẽ ít thú vị hơn 20% và bạn sẽ có 40% khả năng giới thiệu công việc của mình cho bạn bè. Chỉ cần ba sự thật là đủ.

Những gì bạn sẽ mất bằng cách phù hợp với tổ chức CNTT là phần "Dev" trong nhóm DevOps nhỏ của bạn. Khi các nhóm được phân chia thành các vai trò nhân tạo của NetOps, SysOps và Dev, bạn sẽ đưa ra các vấn đề sau:

1. Không cần thiết băng đỏ và cách ly - Để làm bất cứ điều gì, các nhà phát triển sẽ phải gửi một vé cho CNTT và chờ họ thực hiện nó. Họ sẽ không còn có thể tự thực hiện và tương tác với nó - lên đến và bao gồm cả các phiên bản Dev và QA của họ, điều này sẽ giới hạn cơ sở hạ tầng mà họ có thể mã hóa. Họ bị mắc kẹt tại hàng rào VM thay vì có thể mã hóa trên toàn bộ ngăn xếp. Nếu những gì họ gửi cho CNTT trông giống như mã DevOps, họ sẽ không được trang bị đầy đủ để xử lý nó và có thể quay lại triển khai thủ công.
2. Bỏ bê - Ngoài ra, họ có thể chỉ triển khai nó và sau đó bỏ bê con thú vì họ không biết cách tương tác với nó - và họ không phải là nhà phát triển, vì vậy mã không phải là vấn đề của họ.
3. Mất điện - Một trong những lợi ích bị bỏ qua của DevOps là bản chất lập trình. Chắc chắn, có thể mất nhiều thời gian hơn để triển khai máy chủ đó bằng cách coi nó là mã, nhưng điều này tự động hóa các lỗi của con người. Cách nó đi vào dev là cách họ sẽ đi vào QA / Test là cách nó sẽ đi vào prod, do đó giảm mất điện. Khi các nhà phát triển mất quyền truy cập vào thiết bị mạng, họ cần triển khai dịch vụ của họ hoặc cơ sở hạ tầng tính toán không chỉ mất nhiều thời gian hơn mà còn giới thiệu nhiều người dễ bị tổn thương hơn, điều này sẽ gây ra nhiều sự cố mất điện.
4. Tài liệu - Trong một số giác quan, mã DevOps là tự chứng minh. Bạn biết cách máy chủ được xây dựng và triển khai vì mã cho bạn biết. Trong 5 năm, khi đến lúc nâng cấp lên CentOS 8 hoặc bất cứ điều gì, sẽ không ai biết cách triển khai ứng dụng của bạn nữa - bao gồm tại các lớp mạng, lưu trữ, giám sát và sao lưu.

Nói tóm lại, bạn nên đề nghị chủ sở hữu dự án của bạn dành thời gian để đọc Tháng đàn ông huyền thoại để không cho anh ấy hoặc cô ấy biết rằng bạn sẽ thấy mối quan hệ 1: 1 về năng suất và Dự án Phượng hoàng là một tiểu thuyết hay (và giải trí) minh họa những gì được và mất bằng cách sử dụng DevOps trong ngôn ngữ phi kỹ thuật cho những người không có kỹ thuật. Nếu chủ dự án có bất kỳ loại hình đi lại nào thì có thể sử dụng bản audiobook của Dự án Phoenix.

Tôi sẽ đề nghị bạn áp dụng một số nhóm CNTT và đào tạo họ kỹ lưỡng trong hệ thống mới.

Một khi họ hiểu hệ thống đầy đủ thì sẽ có ý nghĩa để giảm tải cho họ.

Nếu không, bạn sẽ trở thành một Trung tâm hỗ trợ cho CNTT - và dành nhiều thời gian để chữa cháy khi họ tìm hiểu sự phức tạp của hệ thống mới.