DevOps Engineer

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ộ.

Máy hỏi resolver; resolver hỏi lần lượt root, máy chủ TLD (.com, .vn), rồi máy chủ authoritative của tên miền, sau đó cache kết quả theo TTL.

Record hay dùng:

• A/AAAA: tên sang IPv4/IPv6.
• CNAME: bí danh trỏ sang tên khác.
• MX: máy chủ nhận mail; TXT: SPF, DKIM, xác minh tên miền.
• PTR: tra ngược IP sang tên.

Lỗi hay gặp:

• Đổi record nhưng cache cũ còn hiệu lực do TTL dài; nên hạ TTL trước khi chuyển đổi.
• Đặt CNAME ở tên miền gốc (apex), không hợp lệ theo chuẩn.

Kiểm tra bằng dig hoặc nslookup.

Active Directory là dịch vụ thư mục của Windows Server, quản lý tập trung người dùng, máy tính, nhóm và xác thực (Kerberos) trong một domain.

• Tổ chức đối tượng theo OU (phòng ban, chi nhánh) để áp chính sách riêng.
• Cấp quyền qua group, không cấp trực tiếp cho từng user.
• Group Policy (GPO): chính sách mật khẩu, khoá màn hình, map ổ mạng, cài phần mềm.
• Có ít nhất 2 domain controller để dự phòng; AD phụ thuộc DNS nên DNS phải đúng.
• Tài khoản admin domain tách riêng khỏi tài khoản dùng hằng ngày.

Hay sai: đồng hồ lệch giữa máy và domain controller khiến Kerberos xác thực lỗi; cần đồng bộ NTP.

Cả ba đều giảm rủi ro khi deploy nhưng khác ở chi phí và tốc độ phát hiện lỗi.

• Rolling: thay dần từng Pod, rẻ, mặc định của Deployment; hai phiên bản chạy song song một lúc.
• Blue-green: dựng nguyên bộ mới, chuyển traffic một lần, rollback tức thì; tốn gấp đôi tài nguyên.
• Canary: đưa một phần nhỏ traffic sang bản mới, theo dõi metric rồi tăng dần; cần công cụ (service mesh, Argo Rollouts) và metric tốt.

Với thanh toán, canary kèm tự động rollback theo tỷ lệ lỗi và độ trễ là lựa chọn hợp lý.

Hay sai: quên migration DB. Schema phải tương thích cả bản cũ lẫn mới (expand rồi mới contract).

Ưu tiên khôi phục dịch vụ trước, tìm nguyên nhân gốc sau.

1. Xác nhận phạm vi qua dashboard: endpoint nào, từ lúc nào, có trùng thời điểm deploy không.
2. Nếu nghi deploy: rollback ngay (kubectl rollout undo, hoặc revert trong GitOps) thay vì sửa nóng.
3. Thông báo kênh sự cố, chỉ định người điều phối, ghi lại mốc thời gian.
4. Sau khi ổn định: so sánh log, trace, diff cấu hình giữa hai phiên bản.
5. Viết postmortem không đổ lỗi, có hành động phòng ngừa (thêm test, canary, alert).

Người phỏng vấn muốn nghe: bình tĩnh, có thứ tự, biết giảm thiệt hại trước, và rút kinh nghiệm thành thay đổi quy trình.

SLI là chỉ số đo trải nghiệm người dùng (tỷ lệ request thành công, độ trễ p99); SLO là mục tiêu cho SLI đó trong một khoảng thời gian; error budget là phần được phép hỏng còn lại.

• Ví dụ: SLO 99.9% request thành công trong 30 ngày, nghĩa là budget 0.1% request lỗi.
• Alert theo burn rate: budget đang bị tiêu nhanh bất thường (đo trên cửa sổ ngắn và dài) thì báo, thay vì báo mỗi khi CPU cao.
• Hết budget: ưu tiên việc ổn định, chậm lại tính năng mới.

Hay sai: đặt alert trên nguyên nhân (CPU, RAM) thay vì triệu chứng người dùng thấy, dẫn đến báo động giả và mệt mỏi vì alert.

Trình bày theo lớp và nhấn vào phân vùng, dự phòng, quản lý.

• Phân VLAN: nhân viên, server, quản trị thiết bị, camera/IoT, Wi-Fi khách.
• Firewall ở biên và giữa các VLAN; Wi-Fi khách chỉ ra Internet, không vào mạng nội bộ.
• Core/access: switch L3 ở lõi, switch access có PoE cho AP và điện thoại IP; cân nhắc dự phòng đường lên.
• Internet: hai đường truyền từ hai nhà mạng, failover hoặc cân bằng tải.
• Dịch vụ: DHCP, DNS nội bộ, NTP, VPN cho làm việc từ xa.
• Vận hành: giám sát (SNMP, syslog), backup cấu hình thiết bị, sơ đồ mạng và tài liệu IP.

Người phỏng vấn muốn nghe: hỏi lại nhu cầu và ngân sách trước khi chốt thiết bị.

Chọn một hai điểm mạnh liên quan tới vị trí, và chứng minh bằng ví dụ thật, không liệt kê tính từ.

Cấu trúc: điểm mạnh, ví dụ ngắn, kết quả, liên hệ với công việc mới.

Câu mẫu: "Điểm mạnh của em là chủ động tìm nguyên nhân gốc. Ở dự án trước, hệ thống thỉnh thoảng bị timeout mà không ai tái hiện được. Em tự đọc log, thêm theo dõi ở các điểm nghi ngờ và tìm ra một truy vấn bị khoá bảng vào giờ cao điểm. Sau khi sửa, lỗi đó không còn xuất hiện. Em nghĩ điều này hữu ích với vị trí bên mình vì hệ thống có lượng truy cập lớn."

Hay sai: "Em chăm chỉ, ham học hỏi, chịu được áp lực" mà không có ví dụ. Ai cũng nói vậy nên không đọng lại gì.