Có một nỗi ám ảnh mang tên DevOps?

Là một lập trình viên, bạn phải chịu trách nhiệm rất nhiều thành phần trong quá trình phát triển phần mềm. Vì thế mà việc phải lãnh những nhiệm vụ liên quan đến DevOps sẽ có thể không được hấp dẫn lắm. Với DevOps, bạn không chỉ chịu trách nhiệm sản xuất phần mềm, mà còn cần tự động hóa các giai đoạn xây dựng, thử nghiệm và triển khai của phần mềm. Đó là rất nhiều thứ để thực hiện! Tạm gác lại khối lượng công việc qua một bên, có thể bạn chỉ mệt mỏi với trào lưu DevOps, và tất cả sự cường điệu xung quanh nó.

Từng là một lập trình viên, tôi có thể hiểu rõ cảm giác mệt mỏi ấy. Có những lúc chúng ta phạm sai lầm khi phải gồng gánh tất cả mọi thứ, kể cả việc release. Đây là một điều thường thấy ở các lập trình viên theo chủ nghĩa hoàn hảo hoặc chỉ đơn giản là bạn không muốn cho ra một sản phẩm đầy bug.

Mặc dù bây giờ tôi làm nhiều nhiều với công việc vận hành các server và giúp nhiều công ty triển khai DevOps – hãy để tôi chia sẻ một số suy nghĩ với bạn về lý do tại sao tôi nghĩ rằng các kỹ sư đang bị mệt mỏi với DevOps.

Làm nhiều hơn nhưng lương không đổi

DevOps đã không còn bị xem chỉ dành cho lập trình viên và operator. Nhưng một số công ty vẫn bắt các nhà phát triển phải lo cả DevOps function. Vì vậy, các lập trình viên bây giờ có thể cảm thấy họ đang bị buộc phải làm thêm task của các vị trí khác. Nó đã đủ khó để tạo ra phần mềm mà không có lỗi! Do đó, các nhà phát triển sẽ cảm thấy thất vọng bởi vì họ đang làm nhiều việc hơn, với mức lương không đổi.

Như tôi đã nói, có những lúc các nhà phát triển cảm thấy cần phải làm nhiều hơn mức cần thiết. Ví dụ, nếu các operationer mất quá nhiều thời gian để trả lời các câu hỏi và yêu cầu  họ, những lập trình viên sẽ luôn tìm cách tự giải quyết vấn đề. Họ thậm chí còn sẵn sàng học những công nghệ mới như Cloud và các cơ sở hạ tầng khác. Rất nhiều điều xảy ra khi một nhà phát triển hoàn thành code và sẵn sàng để được chuyển đến khâu production. Tại thời điểm đó, nó không chỉ đơn giản là build và sau đó copy/paste, việc triển khai và phát hành có thể phức tạp hơn mà một nhóm không thể xử lý hết mọi thứ.

Tôi không nghĩ rằng việc các developer phải làm nhiều hơn là một điều xấu. Nhưng có những lúc những trách nhiệm mới này lại bị cho là điều hiển nhiên. Và đó là điều mà các lập trình viên chúng ta cảm thấy mệt mỏi và khó chịu.

Bào mòn chuyên môn

Mặc dù các nhà phát triển vẫn tham gia code và DevOps cũng giúp nuôi dưỡng cơ sở hạ tầng như code thì giờ đây chúng ta còn cần phải tìm hiểu về cơ sở hạ tầng. Nó không phải là nhiệm vụ dễ dàng để cung cấp và tinh chỉnh một server mà không lãng phí tài nguyên. Chắc chắn, các kỹ sư phần mềm cần đảm bảo code của họ không dẫn tới rò rỉ bộ nhớ cũng như không sử dụng quá nhiều luồng hoặc mạng. Nhưng đó lại là những task của các chuyên gia về cơ sở hạ tầng chứ không là của developer.

Có rất nhiều điều mà các operationer cần phải xem xét, chẳng hạn như nếu các máy chủ đang chạy trên on-prem hoặc trong một môi trường cloud hay hybrid. Vì vậy sẽ tốt hơn nếu công ty có những bộ phận chuyên môn tối đa cơ sở hạ tầng và tối ưu hóa chi phí thay vì cứ đổ lên đầu developer.

Một lần nữa, nó không phải là một điều xấu khi các nhà phát triển biết thêm về cơ sở hạ tầng và làm thế nào mà code của họ ảnh hưởng đến hệ thống sản xuất. Nhưng một số lập trình viên thì thích tạo ứng dụng, do đó họ có thể cảm thấy như DevOps khiến họ mất đi thời gian phát triển các kỹ năng chuyên môn của mình.

Áp dụng DevOps vô thưởng vô phạt

“Mọi người đều làm DevOps, và bạn cũng vậy”. Tôi nghĩ hẳn bạn đã từng nghe câu nói như vậy.

Quả thật, tôi tin rằng DevOps mang lại kết quả rất tốt, nhưng chỉ khi DevOps đang giải quyết tốt 1 vấn đề mà dự án bạn đang gặp phải. Còn nếu bạn chỉ đang triển khai DevOps vì đó là xu hướng mới, thì có thể bạn chỉ cần sử dụng đường ống phân phối hiện tại của mình là đủ rồi.

Tôi thích cách Gene Kim đã định nghĩa DevOps, ông nói rằng nếu áp dụng DevOps là để cho kết quả của bạn thay vì những gì bạn làm thì đừng nên áp dụng DevOps.

Nếu bạn mệt mỏi với tất cả các công cụ của DevOps, thì không sao. Tôi cũng cảm thấy mệt mỏi trong một thời gian. Nhưng trong trường hợp của tôi, đó là bởi vì mọi người có hiểu biết sai về DevOps, điều này khiến họ thực hiện những thứ mà vốn dĩ DevOps được tạo ra để sửa nó.

Thêm áp lực từ những kỳ vọng vô lý

Có rất nhiều kỳ vọng không thực tế với DevOps và triển khai nó mỗi ngày là một trong số đó. Báo cáo DevOps năm 2017 cho rằng những người giỏi (các công ty như Amazon, Netflix, Google, …) luôn bảo đảm thực hiện triển khai DevOps mỗi ngày.

Vì vậy tôi hiểu tại sao một số tổ chức muốn “làm” DevOps mỗi ngày. Nhưng để thành công trước tiên bạn cần phải xác định vấn đề của bạn là gì? Có rất nhiều lợi ích từ việc triển khai nó mỗi ngày, nhưng không dễ dàng để thực hiện được điều đó.

Các kỹ sư đã có đủ áp lực để đáp ứng thời hạn, và việc thêm nhiều kỳ vọng hơn không làm cho mọi thứ tốt hơn chút nào.

Kết quả mới là quan trọng nhất

Hãy để tôi nhắc lại lời trích dẫn của Gene một lần nữa. “DevOps không phải là những gì bạn làm, mà là kết quả bạn nhận được”. Khi bạn nắm lấy ý tưởng này, bạn bắt đầu nhận ra rằng nhiều điều bạn nghĩ về DevOps hoàn toàn không có ý nghĩa. Mỗi phần trong câu đố đều có mục đích của nó, và việc buộc mọi người phải làm thêm bên ngoài phạm vi nhiệm vụ của họ không bao giờ là một điều tốt.

Các lập trình viên có thể cảm thấy mệt mỏi với DevOps bởi vì họ sẽ làm nhiều việc hơn. Chắc chắn, họ đang học những điều mới, nhưng họ cũng không thể tập trung được cho chuyên môn của mình. Hoặc có thể là việc những người quản lý đang tạo thêm áp lực với những kỳ vọng không thực tế, không nhận ra rằng sự thay đổi đó không thể chỉ trong một sớm một chiều.

Nếu bạn hoặc nhóm của bạn đang gặp vấn đề với DevOps, hãy tạm gác lại chúng sang 1 bên, ngồi xuống cùng nhau bàn bạc xác định vấn đề chính đang gặp phải. Lý do khác nhau, nhưng quy trình, công cụ hoặc thậm chí con người bạn có thể là lí do cản trở quá trình phát hành phần mềm. Ý nghĩa của DevOps chưa bao giờ là xấu; vấn đề là mọi người đều có một định nghĩa về DevOps và thực hiện nó theo nhiều cách khác nhau. Chính điều đó mới thật sự khó chịu.

Techtalk via dzone