Ngành công nghệ đang phải đối mặt với nhận thức ngày càng rõ ràng rằng DevOps, từng được ca ngợi như một phương pháp cách mạng trong phát triển phần mềm và vận hành, có thể đã đi lạc hướng. Điều bắt đầu như một phong trào để trao quyền cho các nhà phát triển sở hữu môi trường sản xuất của họ đã phát triển thành thứ mà nhiều người cho rằng đi ngược lại mục đích ban đầu.
Tầm Nhìn Ban Đầu so với Thực Tế Hiện Tại
DevOps bắt đầu với một ý tưởng đơn giản: các nhà phát triển nên triển khai code của chính họ và chịu trách nhiệm giữ cho nó hoạt động. Điều này có nghĩa là giám sát hệ thống, phản hồi các vấn đề, và sử dụng kỹ năng lập trình để tự động hóa việc triển khai một cách an toàn. Phương pháp này hoàn toàn hợp lý, đặc biệt khi các dịch vụ đám mây khiến việc khởi tạo máy chủ trở nên dễ dàng như gọi một API.
Tuy nhiên, ngay khi thực hành này có một cái tên chính thức, mọi thứ đã thay đổi. Các công ty bắt đầu tạo ra các nhóm DevOps chuyên biệt và tuyển dụng các kỹ sư DevOps, thực tế là kéo những nhà phát triển có tư duy sản xuất ra khỏi các nhóm sản phẩm. Điều này khiến các nhóm phát triển không có ai tập trung vào mối quan tâm sản xuất, tái tạo chính những rào cản mà DevOps được tạo ra để loại bỏ.
Vấn Đề Khoảng Cách Kỹ Năng
Một trong những vấn đề quan trọng nhất đang ảnh hưởng đến việc triển khai DevOps hiện đại là sự không phù hợp về kỹ năng cơ bản. Nhiều chuyên gia trong các vai trò DevOps đến từ nền tảng quản trị hệ thống truyền thống mà không có khả năng lập trình mạnh. Điều này tạo ra một nút thắt cổ chai nơi các nhóm gặp khó khăn với các tác vụ gỡ lỗi và tự động hóa cơ bản đòi hỏi kỹ năng phát triển thực sự.
Kỳ vọng rằng một người có thể xử lý phát triển, vận hành, khả năng quan sát và hỗ trợ đơn giản là không thể mở rộng trong thực tế. Kết quả thường là hoặc những người vận hành với các chức danh mới lạ hoặc các nhà phát triển bị đẩy vào lãnh thổ không quen thuộc, hiếm khi đạt được sự kết hợp kỹ năng thực sự mà vai trò đòi hỏi.
Các Vấn Đề Thường Gặp Trong Triển Khai DevOps
- Thiếu Phù Hợp Về Kỹ Năng: Nhiều chuyên gia DevOps thiếu khả năng lập trình mạnh mẽ, xuất thân từ nền tảng quản trị hệ thống truyền thống
- Tách Biệt Tổ Chức: Việc tạo ra các nhóm DevOps riêng biệt khiến chuyên môn sản xuất bị tách khỏi các nhóm phát triển
- Vấn Đề Tin Tưởng: Các triển khai hiện đại thường hạn chế thay vì trao quyền cho các nhà phát triển
- Gánh Nặng Tuân Thủ: Các yêu cầu bảo mật được triển khai thông qua hạn chế thay vì minh bạch
- Độ Phức Tạp Của Công Cụ: Các trừu tượng hóa nội bộ chậm hơn so với khả năng của nhà cung cấp đám mây
Vấn Đề Tin Tưởng và Kiểm Soát
Các nhóm DevOps hiện đại thường hoạt động dưới giả định rằng các nhà phát triển không thể được tin tưởng với quyền truy cập sản xuất. Tư duy này dẫn đến các lớp hạn chế và quy trình phê duyệt làm chậm việc phát triển thay vì tạo điều kiện cho nó. Các nhóm cuối cùng xây dựng các công cụ nội bộ được thiết kế nhiều hơn để hạn chế thay vì trao quyền, bao bọc các API đám mây trong những trừu tượng tự phát triển tụt hậu so với những gì các nhà cung cấp đã cung cấp.
Các kỹ sư nhóm sản phẩm ngày nay cảm thấy như những đứa trẻ được nuông chiều, họ không hiểu máy chủ chạy như thế nào, và yêu cầu những thứ không hợp lý.
Điều này tạo ra một chu kỳ luẩn quẩn nơi các nhà phát triển ngày càng trở nên tách biệt khỏi thực tế sản xuất trong khi các nhóm DevOps trở thành người gác cổng thay vì người tạo điều kiện.
Cạm Bẫy Tuân Thủ
Các yêu cầu tuân thủ thường bị đổ lỗi cho các thực hành hạn chế, nhưng vấn đề thực sự nằm ở việc triển khai. Bảo mật nên đến từ khả năng hiển thị và minh bạch, không phải cửa khóa. Khi các nhóm DevOps sở hữu danh sách kiểm tra tuân thủ, họ thường tích hợp sự không tin tưởng vào các quy tắc, giả định các nhà phát triển là những kẻ xấu tiềm năng thay vì cộng tác viên.
Điều Gì Hoạt Động Tốt Hơn
Các tổ chức thành công đang chuyển từ các nhóm DevOps riêng biệt sang các mô hình nhúng. Một số công ty có các kỹ sư có tư duy sản xuất làm việc trực tiếp với các nhóm phát triển, sử dụng các chức danh như kỹ sư hệ thống thay vì kỹ sư DevOps. Phương pháp này giữ chuyên môn vận hành gần với sản phẩm trong khi duy trì tinh thần hợp tác đã làm cho DevOps có giá trị ngay từ đầu.
Các nhóm hiệu quả nhất kết hợp các nhà phát triển tập trung vào tính năng với các thành viên nhóm am hiểu ops có thể triển khai công việc của chính họ, được hỗ trợ bởi các nhóm kỹ thuật nền tảng chuyên biệt cung cấp công cụ và cơ sở hạ tầng mà không trở thành nút thắt cổ chai.
Các Phương Pháp Thay Thế Thành Công
- Mô hình Tích hợp: Các kỹ sư có tư duy sản xuất làm việc trực tiếp với các nhóm phát triển
- Kỹ sư Hệ thống: Các vai trò kỹ thuật tập trung vào cơ sở hạ tầng mà không mang theo gánh nặng của " DevOps "
- Kỹ thuật Nền tảng: Các nhóm chuyên biệt cung cấp công cụ và cơ sở hạ tầng mà không trở thành nút thắt cổ chai
- Trách nhiệm Chia sẻ: Kết hợp các nhà phát triển tập trung vào tính năng với các thành viên nhóm am hiểu về vận hành
Nhìn Về Phía Trước
Ngành công nghiệp dường như đang học hỏi từ những sai lầm này, mặc dù chậm. Platform Engineering đang nổi lên như sự phát triển tiếp theo, mặc dù một số người lo ngại nó có thể lặp lại những mô hình tương tự. Chìa khóa dường như là duy trì tinh thần hợp tác và trách nhiệm chung đã làm cho DevOps có giá trị trong khi tránh các rào cản tổ chức đã làm suy yếu nó.
Thành công đòi hỏi lãnh đạo kỹ thuật mạnh hiểu cả phát triển và vận hành, mục tiêu rõ ràng, và một văn hóa coi trọng hợp tác hơn chính trị. Không có những nền tảng này, bất kỳ mô hình tổ chức nào sẽ gặp khó khăn bất kể nó được gọi là gì.
Tham khảo: In retrospect, DevOps was a bad idea.