Chắc lâu lắm mới viết bài chia sẻ mindset như thế này, xin phép được ngồi ghế chia sẻ của người đi phỏng vấn nhé, trải nghiệm cá nhân các bác cứ góp ý.

Hôm trước, tôi có phỏng vấn một bạn apply vị trí Senior DevOps. Nhìn cái CV rất wow: K8s, Istio, Linkerd, HashiCorp Vault, ArgoCD, Prometheus, Grafana, Jaeger, Kiali… gần như cái CNCF Landscape có gì là thấy hết trong project.

Nghĩ bụng bảo quả này mà trình độ ở mức năm exp thì nhận ngay vào luôn đi chứ còn gì nữa để mình có thêm thời gian đi uống trà đá :))

Trong buổi phỏng vấn, anh em đều biết rồi hỏi dựa trên CV thôi, tôi hỏi một câu tình huống:

Nếu hệ thống chỉ có 5 microservices, traffic chưa tới 100 req/s, thì em đưa Istio với Jaeger vào để giải quyết bài toán gì?

Thì bạn bắt đầu lúng túng (trong CV ghi giải quyết được issue đó nên tôi hỏi thử use case nhưng chưa trả lời được).

Và có thể là cái bẫy mà anh em làm DevOps, kể cả những người làm có kinh nghiệm mắc phải: Nghiện tool.

1. Nghệ thuật của Senior là Lấy ra, không phải Thêm vào

Đức Phật có câu rất hay, đại khái là: “Đường đạo càng đi càng bớt, không phải càng thêm“.

Hồi mới làm, nếu chưa từng trải nghiệm thì sẽ thường khoác vác đủ thứ xịn xò về cài để chứng tỏ bản thân. May mắn, tôi không có tư tưởng này nên khi ngồi thiết kế hạ tầng, tôi luôn tự hỏi: “Cái này có thực sự cần thiết không? Nếu bỏ nó đi, hệ thống có chết không?”

• Nếu CloudWatch hay Loki đơn giản đã đủ để debug, thì đừng dựng cả một cụm ELK khổng lồ chỉ để tốn tiền storage và công maintain.
• Nếu Docker Compose hoặc Systemd là đủ để quản lý mấy con worker nhẹ nhàng, thì đừng cố nhét nó vào Kubernetes cho bằng bạn bằng bè.

Senior DevOps giỏi (với tôi) là người hiểu rõ Trade-off (sự đánh đổi). Họ sẵn sàng dùng một cái script Bash 50 dòng thay vì cài một cái tool nặng nề, miễn là nó giải quyết đúng việc và ai trong team cũng hiểu được.

2. Càng nhiều tool, diện tích tiếp xúc với outage càng rộng

Anh em cứ tưởng tượng hệ thống như một con tàu. Càng nhiều linh kiện phức tạp thì tỉ lệ có thứ gì đó hỏng càng cao.

• Cài Istio để làm Service Mesh? Ok, nhưng anh em có đủ người để vận hành nó khi Envoy sidecar nó ngốn RAM hay làm tăng latency bất thường không?
• Dùng Vault để quản lý secret? Tốt thôi, nhưng nếu Vault cluster nó lăn đùng ra chết thì toàn bộ app của anh em có lấy được secret để chạy tiếp không?

Cá nhân tôi thấy bất an không phải là thiếu tool, mà là Complexity (sự phức tạp) và tư duy của người dựng/quản trị tool. Càng nhiều tool, cognitive load (áp lực nhận thức) lên team càng lớn. Đến lúc production sập lúc 2-3 giờ sáng, anh em phải lội qua 7-8 lớp tool chỉ để tìm xem lỗi ở đâu thì đó là bi kịch chứ không phải thành tựu.

Dĩ nhiên, hầu hết đều do con người thôi chứ cái tool nó chẳng có tội tình gì cả, biết dùng thì nhẹ người, đẹp profile thì có thể… nhẹ người khiêng…

3. Đừng để tool làm lu mờ bản chất hệ thống

Nhiều bạn bây giờ học DevOps theo kiểu học vẹt menu của tool. Biết click Jenkins, biết viết YAML cho ArgoCD nhưng không hiểu gói tin nó chạy thế nào qua Ingress, không hiểu tại sao DB lại bị lock.

Tool chỉ là cái cờ-lê, mỏ-lết. Người thợ giỏi là người biết khi nào dùng lực, khi nào dùng mẹo, chứ không phải người có cái hộp đồ nghề to nhất.

Dù sao, nếu có những nguồn học tốt thì đi từng bước, mới thì học gõ lệnh, dùng tool vẫn được vì cũng cần phải qua vòng gửi xe có vị trí rồi đi lên mà, ý tôi chia sẻ ở đây là tư tưởng, không lên đến senior vẫn tập trung vào tool thì cá nhân tôi thấy khá khó lên vị trí cao hơn…

4. Case study thực tế: Bye bye Istio

Đang tiện nói về buổi phỏng vấn chủ đề Istio thì cũng chia sẻ luôn tới mọi người, có thể hữu ích.

Tôi từng tư vấn cho một bên Startup (tư vấn nghe hơi to vì ông bạn nhờ nhưng tư vấn cho CTO công ty họ cũng áp dụng nên tạm gọi vậy các bác nhé), hệ thống họ chậm một cách vô lý. Khi vào check, tôi thấy họ cài Istio cho một dàn microservices bé tẹo, trong khi team chỉ có 2 ông DevOps.

Riêng việc cấu hình mTLS, mần mò các loại VirtualService, DestinationRule đã ngốn hết thời gian của họ. Latency thì tăng vọt vì cái overhead của sidecar.

Tôi bảo: Gỡ hết Istio ra, quay về load balancer cơ bản của Cloud.

Kết quả? Hệ thống chạy mượt hơn, latency giảm hơn 30%, và quan trọng nhất là 2 ông DevOps kia thoát khỏi cảnh suốt ngày đi cứu con Envoy proxy. Đó chính là giá trị của việc dám lược bỏ.

Chốt lại thôi

Đến một lúc nào đấy (có thể) anh em sẽ không tự hào vì CV có nhiều tên tool. Mà sẽ tự hào vì hệ thống build Lean (tinh gọn) nhất có thể.

Suy ra từ câu của Đức Phật thì có thể nói như này không anh em nhỉ: Hạ tầng hoàn hảo không phải là khi không còn gì để thêm vào, mà là khi không còn gì để bớt ra. 😀

Anh em có ai từng dũng cảm vứt rác ra khỏi hệ thống của mình chưa? Hay vẫn đang gồng mình maintain một đống tool ngầu nhưng có vẻ ném đi cũng được…

Tranh thủ

Anh em tranh thủ sự kiện góp ý duy nhất trong năm nhé State of DevOps VietNam 2026. Và rất mong các bác có chuyên môn có thể ra mặt, để lại thông tin để góp mặt vào số “chuyên gia chia sẻ” giúp cộng đồng DevOps của chúng ta, có thể tôi cũng đã có 1 slot 😀