DevOps có nghĩa là các nhà phát triển hiện chịu trách nhiệm về cơ sở hạ tầng và phát hành - nhưng các trình điều khiển đằng sau sự thay đổi này là gì?

DevOps có nghĩa là các nhà phát triển hiện chịu trách nhiệm về cơ sở hạ tầng và phát hành - nhưng các trình điều khiển đằng sau sự thay đổi này là gì?

Tôi sẽ đặt các thẻ của mình lên bàn: Tôi là một nhà phát triển và đã làm việc trong cả "DevOps" và không có văn hóa. Phải lo lắng về cơ sở hạ tầng và phát hành và QA và buổi lễ liên quan là một sự phân tâm lớn từ việc viết mã tốt.

Nhưng ngành công nghiệp đang đi theo hướng này, vậy những lý do cho việc này là gì? Những vấn đề nào đã làm cho mô hình "cũ" của chuyên gia về vai trò?

Lý do chính là đám mây.

Trước đây, mã của bạn đã được chuyển trên đĩa mềm, rồi CD, và sau đó nó được triển khai đến một máy chủ, và sau đó nó được triển khai đến hai máy chủ (để phục hồi) ... Và tất cả việc triển khai đó có thể được thực hiện thủ công bởi một con người, vì vậy con người đã được đào tạo để làm điều đó.

Ngày nay, mã của bạn thường sẽ có hàng chục hoặc hàng trăm máy chủ. Việc cung cấp, định cấu hình và triển khai cho các máy chủ đó không thể được thực hiện thủ công bởi con người. Bạn cần quản trị viên hệ thống của bạn biết đủ kịch bản để tự động hóa quy trình đó, vì bạn hiện đang sử dụng Chef hoặc người thân của nó. Nhưng thành thật mà nói, không có đủ quản trị viên có thể làm điều đó. Vì vậy, các dev đã được kéo vào để lấy chùng.

Và vâng, việc thêm nhiều kỹ năng hơn vào các yêu cầu ngày càng tăng của các nhà phát triển đương nhiên sẽ làm giảm năng lực của họ ở nơi khác. Các ý tưởng là cho phép cái nhìn sâu sắc dev vào quá trình xây dựng / phát hành, họ có thể dự đoán các vấn đề tốt hơn, hoặc có quyền tự chủ nhằm cải thiện nó. Ý tưởng là chất lượng của tất cả mọi thứ tăng lên kể từ khi phát hành chiến thắng vượt qua các tổn thất viết mã.

Tôi hoài nghi rằng sự đánh đổi là đáng giá thường xuyên như mọi người đưa ra.

Có rất nhiều lý do khác nhau để các tổ chức khác nhau chuyển sang DevOps.
Tôi sẽ cố gắng liệt kê những thứ xuất hiện thường xuyên.

Giảm thời gian thay đổi chu kỳ
Thường có một khoảng thời gian dài giữa việc đưa ra yêu cầu thay đổi và nó thực sự được triển khai và sử dụng trong tổ chức. Đầu tiên, nó được lên kế hoạch theo một trong các chu kỳ phát triển của các nhà phát triển và sau khi được phân phối, nó được lên kế hoạch theo một trong các chu kỳ phát hành của các hoạt động. Cả hai chu trình bao gồm kiểm tra và trong trường hợp có vấn đề được tìm thấy, cả hai chu kỳ đều được đặt lại. Bằng cách tích hợp các bộ phận phát triển và hoạt động, chúng tôi có thể hợp lý hóa cả hai quy trình.

Các vấn đề về phần mềm và phần cứng
Hãy nhớ phim hoạt hình Bugs Bunny trong đó Bugs và Daffy đang tranh cãi liệu đó là mùa vịt hay mùa thỏ? Bây giờ hãy tưởng tượng chúng ta thay vì làm cho nó với các nhà phát triển và hoạt động trong đó các nhà phát triển cho rằng đó là vấn đề phần cứng và hoạt động cho rằng đó là vấn đề phần mềm. Đối với người dùng cuối, đây là một sự khác biệt không có sự khác biệt. Họ chỉ muốn nó cố định.
Bằng cách mang các nhà phát triển và hoạt động lại với nhau, họ sẽ phải khắc phục các sự cố. Và nó có thể chỉ ra đó là một vấn đề phần mềm và phần cứng.

Chúng tôi so với họ
Trong rất nhiều công ty, khoảng cách giữa người thử nghiệm và nhà phát triển ngày càng tăng bởi vì họ là các phòng ban riêng biệt và chu kỳ phát triển ngày càng được chính thức hóa và tiêu chuẩn hóa.
Với sự xuất hiện của Agile, các nhà phát triển và người thử nghiệm đã làm việc gần nhau hơn và chúng tôi đã bắt đầu thấy quan điểm của nhau về chu kỳ phát triển và thậm chí có thể tôn trọng nó.
Một cái gì đó tương tự cần phải xảy ra giữa các nhà phát triển và hoạt động, bởi vì khi cả hai lĩnh vực trưởng thành và các quy trình tiếp tục chính thức hóa và tiêu chuẩn hóa, khoảng cách giữa các bộ phận này đang gia tăng. Vì vậy, một trong những vấn đề với mô hình truyền thống là có vẻ như "chúng tôi" so với "họ" đối với các nhà phát triển và hoạt động như nhau. Cả hai không hoàn toàn hiểu được khó khăn của trách nhiệm của người khác.

Kỳ vọng / Upsides
Với DevOps cả hai chuyên ngành sẽ học một số kỹ năng truyền thống được thực hiện bởi người kia. Không ai sẽ mong muốn một quản trị viên hệ thống trở thành kỹ sư phần mềm hoặc nhà phát triển để trở thành kỹ sư mạng, nhưng cả hai đều được dự kiến ​​sẽ đảm nhận một số trách nhiệm của người khác. Điều này có nghĩa là khi bạn thực sự cần một số bàn tay phụ, chúng ở đó.

Và có một số ưu điểm nhất định cho các nhà phát triển: giờ đây bạn có nhiều quyền kiểm soát hơn đối với môi trường thử nghiệm của mình, bạn sẽ thấy việc triển khai phần mềm cho người dùng dễ dàng hơn và có nhiều người trong tổ chức của bạn chia sẻ tình yêu của bạn với nghề.

Viết mã chất lượng là không đủ. Bạn là một phần của vấn đề hoặc là một phần của giải pháp.

Đối với nhiều lập trình viên, bạn đang viết phần mềm đang được trả tiền bởi một số người dùng cuối. Viết mã chất lượng là một điều tốt, nhưng đó cũng là điều mà khách hàng / người quản lý cho rằng bạn nên luôn luôn làm và làm nhanh. Nó giống như nói một thợ mộc cắt ván chính xác, nhưng bạn có thực sự xây dựng một cái gì đó mà ai đó muốn trả tiền không?

DevOps cung cấp cho các nhà phát triển quyền kiểm soát nhiều hơn và hy vọng buộc mã của họ phù hợp với kết quả cuối cùng. Ai phù hợp nhất để tự động hóa quá trình hoạt động? Sự hài lòng của người dùng cuối là thanh đo chính. Bạn không chỉ phải viết mã chất lượng mà còn phải làm hài lòng khách hàng. Xin lỗi, nhưng không ai quay lại sử dụng các dòng mã. Họ không quan tâm nếu bạn xây dựng khung ORM của riêng bạn từ đầu giống như người mua nhà bình thường không quan tâm nếu bạn chặt cây và làm bảng của riêng bạn. Có ai muốn làm lại tất cả các tập tin cấu hình của họ vì "nâng cấp" của bạn đặt chúng trở lại mặc định không?

Bạn muốn thể hiện các chương trình phát triển của mình? Xây dựng một cái gì đó mọi người muốn mua và bao gồm toàn bộ trải nghiệm người dùng. Thật tuyệt khi bạn đang viết mã chất lượng, nhưng thật không may, bạn có thể không nhận được tiền thưởng nếu nó không được phát hành cho sự hài lòng của khách hàng trả tiền. Vui lòng đổ lỗi cho QA, nhưng công ty của bạn vẫn không có đủ tiền để trả cho bạn nhiều hơn.

Nó là thứ đã đi đôi với Agile & Scrum. Không còn vai trò công việc được xác định rõ ràng - mọi người đều là "nhà phát triển".

Và nó không chỉ là ops. Các nhà phát triển thường phải đảm nhận vai trò phân tích kinh doanh, thử nghiệm, quản trị cơ sở dữ liệu & quản lý xây dựng - danh sách này tiếp tục.

Trọng tâm của vấn đề là những gì bạn có thể gọi là churn . Khi số lượng vai trò khác nhau liên quan đến một dự án tăng lên, càng có nhiều cuộc họp, hiểu lầm và xung đột tài nguyên. Có được phần mềm trước mặt người dùng một cách nhanh chóng là trò chơi kết thúc và bất cứ điều gì có thể tưởng tượng được theo cách đó đã đi đôi chút.

Đây không hoàn toàn là một điều xấu. Nhà phát triển trung bình của bạn mở rộng các kỹ năng của họ mặc dù hiện tại tình trạng kẹt đang rất mỏng. Nó cũng đứng đầu các cuộc tranh luận giữa các lập trình viên và quản trị viên máy chủ về vấn đề nằm ở đâu khi triển khai theo cách của quả lê. Các nhà phát triển thường muốn đưa ra các giải pháp với công nghệ tiên tiến và quản trị viên máy chủ thường không biết điều này có nghĩa là gì từ một quản trị viên POV cho đến khi họ được trình bày với bộ cài đặt.

Các công ty có tư duy sáng sủa và tiến bộ hơn cuối cùng đã bắt đầu nhận ra rằng những người có hình chữ T là một điều tốt. Tuy nhiên, có một sự khác biệt giữa việc nghĩ rằng chúng là một điều tốt và hy vọng điều này sẽ xảy ra một cách kỳ diệu khi một nền văn hóa truyền thống đã được chấp nhận trước đây.

Tôi chắc chắn có nhiều hơn một vài lý do tốt để các nhà phát triển cũng quản lý các hoạt động và kiểm soát chất lượng (đôi khi). Dưới đây là ba trong số họ:

• Quan tâm
  Một số nhà phát triển thực sự muốn làm việc tất cả các khía cạnh của sản phẩm. Nếu họ giỏi về điều đó và nếu họ lấp đầy khoảng trống trong đội hoặc hỗ trợ tốt cho các thành viên nhóm hiện tại trong các vai trò khác, có thể không có bất kỳ lý do nào để ngăn chặn họ.
• Chi phí
  công ty lớn có thể đủ khả năng nhân viên chuyên ngành. Các công ty nhỏ đôi khi không thể. Một số trong những nơi này có thể thuê 1 hoặc có thể 2 hoặc 3 nhà phát triển, những người cần có khả năng đơn giản là làm việc.
• Quy mô dự án
  Không phải mọi dự án đều là dự án nhiều người. Nếu bạn đang xây dựng một ứng dụng "nhỏ", có thể đơn giản là quá mức cần thiết để có hơn 1 người hoàn thành. Hơn thế nữa, các dự án nhỏ với nhiều cá nhân làm việc cụ thể là đáng sợ . Không ai có đủ việc để làm - ngay cả khi bạn có đủ khả năng để giữ tất cả chúng xung quanh để xoay tròn ngón tay cái trong 6 tháng, những người tốt sẽ không ở lại. Nếu họ không cảm thấy buồn chán, họ sẽ cảm thấy sợ hãi hoặc bạn sẽ nhận ra rằng bạn đang trả khá nhiều tiền cho việc này. Dù bằng cách nào, nhân viên tốt của bạn sẽ rời đi và bảo mọi người tránh xa bạn.

... Và những lý do khác, tôi chắc chắn.

"Phải lo lắng về cơ sở hạ tầng và phát hành và QA và buổi lễ liên quan là một sự phân tâm lớn từ việc viết mã tốt"

Về cốt lõi, tôi nghĩ DevOps nói rằng lo lắng về cơ sở hạ tầng và phát hành và QA IS đang viết mã tốt.

Trong các vai trò trước đây hoạt động trong các nền văn hóa không phải là DevOps, tôi đã có rất nhiều vấn đề, có thể cho rằng, văn hóa DevOps có thể ngăn chặn được; các vấn đề về hiệu suất liên quan đến mã được phát triển trên các nền tảng không đại diện, các vấn đề mã hóa ký tự trong đó các nhà phát triển không biết gì về mã hóa ký tự được sử dụng bởi khách hàng, các hướng dẫn triển khai được mã hóa bằng tay và không đủ cho nhóm Ops mà không cần đoán trước -công việc.

Bây giờ bạn có thể lập luận rằng việc chuyên môn hóa tăng lên ở cả hai bên Dev và Ops cho phép chúng tôi vượt qua một số trong số này, nhưng vẫn có thể giải quyết được rất nhiều thông qua một số chia sẻ kiến ​​thức và công việc giữa các nhóm của chúng tôi.

DevOps không có nghĩa là "Dev bây giờ cũng làm Ops". Thuật ngữ ban đầu có nghĩa là "Người Dev và Ops làm việc chặt chẽ trong một nhóm". Điều đó không có nghĩa là người Ops cần trở nên giống Dev hơn, bởi vì tự động hóa mọi thứ đòi hỏi một số loại lập trình và cách thủ công cũ không cắt nó (xem các câu trả lời khác để biết chi tiết hơn về điểm này).

Từ Wikipedia :

DevOps (hợp chất phát triển và vận hành) là văn hóa, phong trào hoặc thực tiễn nhấn mạnh sự hợp tác và giao tiếp của cả nhà phát triển phần mềm và các chuyên gia công nghệ thông tin (CNTT) khác trong khi tự động hóa quá trình phân phối phần mềm và thay đổi cơ sở hạ tầng

Vì vậy, theo ý kiến ​​của tôi thực sự nếu bạn là một Dev có cùng trách nhiệm cũ và hiện tại cũng là trách nhiệm Hoạt động, điều đó có vẻ như là một tính toán sai lầm về phần quản lý. Bằng cách tự động hóa mọi thứ, hoàn toàn có thể bạn sẽ cần ít người Ops hơn và do đó thực sự có tiết kiệm chi phí. Nhưng DevOps chắc chắn không có nghĩa là "Hãy loại bỏ tất cả những người Ops và để Devs làm việc bổ sung".

Như thường lệ với Buzzwords, một sự khuếch tán ngữ nghĩa xảy ra và đột nhiên mọi người nghĩ rằng "Hãy để chúng tôi làm Dev cũng làm Ops và tôi đoán chúng ta có thể tiết kiệm tiền ..."