DevOps Engineer (Linux, Networking, CI/CD)

CI là tự động build và test mỗi lần merge code; Continuous Delivery là luôn có bản sẵn sàng deploy nhưng lên production cần bấm duyệt; Continuous Deployment thì tự lên production nếu mọi bước đều qua.

Pipeline cơ bản:

• Checkout, cài dependency (có cache).
• Lint, unit test, quét bảo mật (SAST, dependency, secret).
• Build artifact/image, gắn tag theo commit SHA, đẩy lên registry.
• Deploy lên staging, chạy smoke/integration test.
• Deploy production (thủ công hoặc tự động), có cách rollback.

Người phỏng vấn muốn nghe: build một lần, dùng cùng một artifact cho mọi môi trường; chỉ cấu hình là khác nhau.

Pod là đơn vị chạy nhỏ nhất (một hoặc vài container dùng chung network); Deployment quản lý số bản sao Pod và việc cập nhật; Service cho một địa chỉ ổn định để gọi tới nhóm Pod.

• Pod có thể chết và được tạo lại với IP mới, nên không gọi trực tiếp IP Pod.
• Deployment tạo ReplicaSet, hỗ trợ rolling update và rollback.
• Service chọn Pod theo label (selector), kiểu ClusterIP (nội bộ), NodePort, LoadBalancer.
• Từ ngoài vào HTTP thường dùng Ingress hoặc Gateway API phía trước Service.

Hay sai: label của Pod template không khớp selector của Service, khiến Service không có endpoint nào.

CrashLoopBackOff nghĩa là container khởi động rồi thoát liên tục; cần tìm lý do nó thoát.

kubectl describe pod <pod>      # events, exit code, OOMKilled?
kubectl logs <pod> --previous   # log của lần chạy trước khi chết
kubectl get events --sort-by=.lastTimestamp

• Exit code 137 / OOMKilled: thiếu memory limit hoặc rò rỉ bộ nhớ.
• Lỗi cấu hình: thiếu biến môi trường, Secret/ConfigMap sai, không kết nối được DB.
• Liveness probe quá gắt khiến app bị kill khi đang khởi động; cân nhắc startupProbe.
• Sai lệnh command/args, sai kiến trúc image (arm64 và amd64).

Người phỏng vấn muốn nghe: quy trình có thứ tự, dựa vào events và log trước khi đoán.

Đi từ gần ra xa và từ tầng thấp lên cao, mỗi bước loại trừ một khả năng.

ip a                 # hoặc ipconfig /all: có IP, gateway, DNS?
ping <gateway>       # mạng nội bộ ổn?
ping 1.1.1.1         # ra Internet được bằng IP?
nslookup example.com # DNS phân giải được?

• Ping IP được mà tên miền không được: lỗi DNS.
• Chỉ một người bị hay cả phòng: cả phòng thì nghi switch, DHCP, đường truyền.
• Chỉ một trang web: proxy, firewall, hoặc chính trang đó.
• Dùng tracert/traceroute để xem gói dừng ở chặng nào.

Người phỏng vấn muốn nghe: hỏi thêm thông tin trước (ai, từ khi nào, có gì thay đổi).

VLAN chia một switch vật lý thành nhiều mạng L2 logic tách biệt, giúp thu nhỏ vùng broadcast và cô lập các nhóm (kế toán, khách, camera, server).

• Access port: thuộc một VLAN, nối với máy trạm; frame không gắn tag.
• Trunk port: mang nhiều VLAN giữa switch với switch hoặc router, frame gắn tag 802.1Q.
• Các VLAN muốn nói chuyện với nhau phải qua thiết bị L3 (router, switch L3, firewall), nơi có thể đặt ACL.

Hay sai: để Wi-Fi khách chung VLAN với mạng nội bộ, hoặc cho phép mọi VLAN đi qua trunk khi không cần.

Readiness quyết định Pod có nhận traffic không; liveness quyết định có restart container không; startup probe tạm hoãn hai probe kia cho tới khi app khởi động xong.

• Readiness fail: Pod bị gỡ khỏi endpoint của Service, không bị restart.
• Liveness fail: kubelet restart container.
• Startup probe hợp với app khởi động chậm (JVM, nạp model).

Lỗi hay gặp:

• Liveness kiểm tra cả DB bên ngoài: DB chậm là toàn bộ Pod bị restart dây chuyền.
• Không có readiness: rolling update đẩy traffic vào Pod chưa sẵn sàng, gây lỗi 5xx.

Người phỏng vấn muốn nghe: liveness chỉ nên kiểm tra chính process còn sống, phần phụ thuộc để cho readiness.

State là file Terraform ghi lại ánh xạ giữa code và tài nguyên thật; Terraform dựa vào nó để tính plan. Mất hoặc lệch state là nguy cơ tạo trùng hoặc xoá nhầm tài nguyên.

• Lưu state ở remote backend (S3, GCS, Azure Blob, Terraform Cloud), bật versioning và mã hoá.
• Bật locking để hai người không apply cùng lúc.
• Tách state theo môi trường/thành phần để giảm phạm vi ảnh hưởng.
• Không commit state lên Git: trong đó có thể chứa secret.
• Chạy plan trong CI cho mỗi PR, apply qua pipeline có duyệt.

Hay sai: sửa tay trên console rồi quên, tạo drift; nên định kỳ chạy plan để phát hiện.

Nguyên tắc: secret không nằm trong Git, không in ra log, được cấp theo quyền tối thiểu và xoay vòng được.

• Dùng secret manager (Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) làm nguồn gốc.
• Đồng bộ vào cluster bằng External Secrets Operator hoặc CSI driver; nếu phải để trong Git thì mã hoá (Sealed Secrets, SOPS).
• Kubernetes Secret mặc định chỉ base64: bật mã hoá etcd và giới hạn RBAC đọc Secret.
• CI dùng biến được che (masked), ưu tiên OIDC để lấy credential ngắn hạn thay vì key dài hạn.
• Bật quét secret khi push code.

Người phỏng vấn muốn nghe: biết base64 không phải mã hoá, và có kế hoạch xoay key khi bị lộ.

Xác định tài nguyên nào đang nghẽn: CPU, RAM, ổ đĩa hay mạng.

uptime; top          # load average, process ngốn CPU/RAM
free -h              # còn RAM không, có dùng swap nhiều?
df -h; df -i         # đầy dung lượng hoặc hết inode
iostat -x 1          # ổ đĩa có quá tải (%util, await)?
ss -tunap            # kết nối mạng
journalctl -p err -b # lỗi từ lần boot này

• Load cao nhưng CPU rảnh: thường là chờ I/O (wa cao trong top).
• dmesg có OOM killer: thiếu RAM.

Hay sai: xoá file log đang được process mở; dung lượng không giải phóng cho tới khi restart process (xem lsof +L1).

Chọn sai lầm thật, có hậu quả vừa phải, nhận trách nhiệm rõ ràng, và nhấn mạnh việc bạn đã thay đổi sau đó.

Cấu trúc: chuyện gì xảy ra, phần lỗi của bạn, bạn khắc phục ngay thế nào, bài học và thay đổi lâu dài.

Câu mẫu: "Có lần em deploy một thay đổi cấu hình lên production vào chiều thứ Sáu mà không kiểm tra kỹ trên staging, làm một tính năng lỗi khoảng một giờ. Em báo ngay cho lead, rollback và viết báo cáo sự cố. Sau đó em đề xuất checklist trước deploy và quy ước hạn chế deploy cuối tuần; team áp dụng tới giờ."

Hay sai: kể một "thất bại" thực ra là khoe, đổ lỗi cho người khác, hoặc nói mình chưa từng thất bại.