Chắc mọi người có thể đã từng thấy mấy bài diễn thuyết bóng bẩy hay mấy bài viết cũng lung linh trên Medium vẽ ra DevOps như một thiên đường công nghệ: những pipeline tự động chạy ro ro, team Dev và team Ops làm việc hòa hợp tuyệt đối, và các bản release cứ thế trôi chảy từ lúc commit code đến khi lên production. Nhưng sau khoảng 7 năm chinh chiến trong ngành công nghệ – DevOps, tôi đã phát hiện ra có một mặt tối mà hiếm khi nào được người ta nhắc đến trong các bài diễn thuyết hoành tráng.

7 Nỗi Bực Dọc Thầm Kín Mà Mọi Kỹ Sư DevOps Đều Nếm Trải (Chắc Thế)

1. Dọn nhà: Cái việc không ai muốn làm

Một kỹ sư DevOps lão làng với hơn chục năm kinh nghiệm chia sẻ rằng nó y hệt như dọn nhà vậy. Nếu mỗi ngày bạn dọn một tí, cuối cùng công việc sẽ nhẹ hơn rất nhiều so với việc bạn trì hoãn cả mấy tháng trời rồi sau đó phải cọ rửa sạch sẽ đến từng chân tường.

Tôi đã thấm thía sự thật này một cách đau đớn khi phải thừa kế một bộ sưu tập các repo không được ai ngó ngàng tới trong nhiều năm. Công việc ban đầu tưởng chừng đơn giản là cập nhật vài cái dependency, nhưng nhanh chóng leo thang thành nhiều tuần gỡ rối mấy cái feature branch bị hardcode, sàng lọc hàng ngàn repo không được bảo trì, và đối phó với mấy ông dev đã phóng ngựa một cách tùy tiện trong version control.

Phần đau đớn nhất là chuyện này xảy ra ở khắp mọi nơi. Từ startup cho đến các tập đoàn lớn, nợ kỹ thuật cứ âm thầm tích tụ cho đến khi có ai đó, thường là team DevOps, phải đứng ra dọn dẹp bãi chiến trường.

2. Khi Làm Nhanh Hơn Đồng Nghĩa Với Mua Đau Vào Thân

Có một bình luận từ một chuyên gia dày dặn kinh nghiệm thực sự chạm vào nỗi lòng của tôi, về những người muốn đốt cháy giai đoạn để đi nhanh hơn, rồi sau đó lại đổ thừa DevOps đang làm họ chậm lại.

Tôi từng làm một dự án mà ông team lead cứ khăng khăng đòi bỏ qua pipeline CI/CD chỉ một lần release này thôi vì nó mất thời gian quá. Ba tháng sau, cả team vẫn phải gánh hậu quả: môi trường không nhất quán, file cấu hình bị thiếu, và những con bug bí ẩn chỉ xuất hiện trên production.

Cái sự trớ trêu nó rành rành ra đó: những người phá rào hiếm khi là người phải đi sửa những vấn đề mà họ gây ra.

3. Nỗi khổ phải nhắc Đọc Log Đi là có thật

Câu nói pipeline của tôi bị lỗi rồi, bạn fix giùm với, có lẽ là câu quen thuộc nhất trong cuộc đời của một kỹ sư DevOps, và thường đi kèm với nó là một đống log của pipeline đã chỉ rõ mồn một ra cần phải sửa cái gì.

Tôi từng mất cả buổi sáng để giúp một bạn dev tìm lỗi pipeline (còn gà thì ai chẳng đã từng =))))), để rồi phát hiện ra thông báo lỗi Service Account không có quyền truy cập storage bucket đã đập vào mặt họ từ đầu. Khi tôi chỉ ra điều đó, họ tỉnh bơ nói rằng, ồ, tôi tưởng đó chỉ là mấy dòng nhiễu thông tin thôi.

Sự lệch pha giữa cái mà dân DevOps thấy rõ như ban ngày và cái mà các dev thực sự nhìn thấy là một rào cản giao tiếp cơ bản vẫn tồn tại ngay cả trong những tổ chức trưởng thành nhất.

4. Khủng hoảng danh tính: DevOps hay là Ops?

Việc có quá nhiều người nhầm lẫn giữa DevOps và Ops không chỉ là chuyện câu chữ, nó gây ra hậu quả thực sự đến sự hài lòng trong công việc và con đường phát triển sự nghiệp. Tôi từng đi phỏng vấn cho các vị trí Kỹ sư DevOps nhưng hóa ra lại là quản trị hệ thống truyền thống đội lốt một cái tên khác, và những vị trí khác thì về cơ bản là vai trò của dev được cấp thêm vài quyền trên AWS.

Thực tế là DevOps muôn hình vạn trạng, có những tuần cảm giác thuần túy là Ops, và những tuần khác thì hoàn toàn tập trung vào việc phát triển. Sự cân bằng này thay đổi chóng mặt giữa các công ty, các team, và thậm chí giữa các dự án trong cùng một tổ chức.

5. Đại dịch Kỹ Sư YAML

Kỹ sư YAML là hai từ có thể gợi lên cái lắc đầu ngán ngẩm từ các chuyên gia DevOps ở khắp mọi nơi.

Một kỹ sư mô tả việc quản lý khoảng 30 cluster Kubernetes với vài trăm ngàn pod và vài repo gitops có lẽ chứa hơn 100 ngàn file YAML. Mặc dù định dạng YAML bản thân nó khá đơn giản, nhưng số lượng khổng lồ của nó tạo ra một loại bành trướng cấu hình đặc thù mà gần như không thể bảo trì nổi.

Thứ bắt đầu là một file cấu hình deploy đơn giản có thể nhanh chóng biến thành một mớ file rối rắm bí hiểm mà rất ít người thực sự hiểu. Sau nhiều ngày trời vật lộn với một vấn đề Kubernetes bí ẩn, tôi phát hiện ra nguyên nhân cốt lõi là một dấu cách bị lệch trong một file YAML đã được sao chép qua lại giữa nhiều repo.

6. Khi Mọi Thứ Rơi Vãi Đều Trở Thành Việc Của Bạn

Team DevOps thường trở thành cái rổ hứng hết những trách nhiệm không thuộc về bất kỳ team nào một cách rõ ràng. Vấn đề về cơ sở dữ liệu? Gọi DevOps. Vấn đề bảo mật? DevOps lo được. Giám sát, cảnh báo, tuân thủ, tối ưu chi phí? Tất cả đều là việc của DevOps.

Phạm vi công việc rộng lớn này khiến việc tập trung vào các trách nhiệm cốt lõi trở nên khó khăn và thường dẫn đến kiệt sức. Như một đồng nghiệp DevOps của tôi đã lưu ý, tất cả những gì rơi vãi giữa các kẽ hở đều là trách nhiệm của bạn.

7. Nghịch Lý Tàng Hình

Một tâm sự đã tiết lộ sự thật cơ bản về công việc DevOps là người ta chỉ nhớ đến chúng ta khi có sự cố.

Thành công thường đồng nghĩa với sự vô hình. Khi mọi thứ hoạt động trơn tru, không ai để ý đến những pipeline được chế tác cẩn thận, hệ thống giám sát chủ động, hay những giờ làm việc bỏ ra để tối ưu hóa quy trình deploy.

Nhưng khi có gì đó sập? Đột nhiên, mọi người đều biết chính xác phải gọi ai.

5 Chiến Lược DevOps Thực Sự Hiệu Quả

Sau nhiều năm đối mặt với những thách thức này, tôi đã khám phá ra một số phương pháp thực sự giúp giải quyết những nỗi bực dọc này:

1. Biến việc dọn dẹp thành một phần của quy trình. Thay vì xem nợ kỹ thuật là một hoạt động riêng biệt, hãy đưa thời gian bảo trì vào quy trình làm việc thường xuyên của bạn. Một kỹ thuật hiệu quả với tôi là dành giờ đầu tiên của mỗi sáng thứ Hai để giải quyết ít nhất một món nợ kỹ thuật.

2. Tạo ra các giải pháp tự phục vụ. Thay vì trở thành người mà ai cũng réo gọi mỗi khi pipeline lỗi, hãy đầu tư thời gian vào việc tạo ra các giải pháp tự phục vụ để trao quyền cho các dev tự giải quyết vấn đề của họ. Tôi đã xây một con bot trên Slack có thể phát hiện các lỗi pipeline phổ biến và tự động đề xuất giải pháp, giúp giảm bớt gần 40% sự gián đoạn cho team DevOps.

3. Triệt để áp dụng nguyên tắc ai làm hỏng, người đó sửa. Khi ai đó bỏ qua quy trình đã được thiết lập hoặc đưa vào một thay đổi có vấn đề, hãy để họ chịu trách nhiệm sửa chữa các sự cố phát sinh.

4. Xác định rõ ranh giới của bạn. Trình bày rõ ràng những gì thuộc và không thuộc trách nhiệm của team bạn. Điều này không có nghĩa là từ chối giúp đỡ, mà là thiết lập những kỳ vọng thực tế về những gì team bạn có thể hoàn thành.

5. Hãy để công việc của bạn được nhìn thấy. Thường xuyên truyền thông về giá trị công việc của bạn, đặc biệt là khi mọi thứ đang vận hành trơn tru. Chia sẻ các chỉ số như tần suất deploy, thời gian trung bình để phục hồi, và tỷ lệ lỗi sau thay đổi để chứng minh tác động từ những nỗ lực của bạn.

Yếu Tố Con Người Trong DevOps

Ngoài những thách thức kỹ thuật, công việc DevOps về cơ bản là về con người. Những kỹ sư DevOps thành công nhất mà tôi từng gặp không chỉ giỏi về mặt kỹ thuật, họ còn là những người giao tiếp, người thầy, và người vận động xuất sắc.

Một kỹ sư senior từng nói với tôi rằng DevOps không phải là làm cho máy móc hoạt động cùng nhau; mà là làm cho con người hoạt động được cùng nhau. Cái nhìn sâu sắc đó đã thay đổi hoàn toàn cách tiếp cận của tôi và giúp tôi vượt qua những nỗi bực dọc vốn là một phần của công việc.