Senior Backend & Platform Engineer – Fintech

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.

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.

Isolation level quyết định một transaction thấy được bao nhiêu thay đổi của transaction khác; mức càng cao càng an toàn nhưng càng dễ tranh chấp.

• Dirty read: đọc dữ liệu transaction khác chưa commit.
• Non-repeatable read: đọc lại cùng một dòng thấy giá trị đã đổi.
• Phantom read: chạy lại cùng điều kiện thấy thêm hoặc mất dòng.

Bốn mức chuẩn: Read Uncommitted, Read Committed, Repeatable Read, Serializable. Mặc định của PostgreSQL, SQL Server, Oracle là Read Committed; MySQL InnoDB là Repeatable Read.

Thực tế các DB dùng MVCC nên hành vi có khác lý thuyết: Repeatable Read của PostgreSQL dùng snapshot nên không gặp phantom, còn InnoDB dùng gap lock cho câu đọc có khoá.

Người phỏng vấn muốn nghe: bạn biết DB mình dùng mặc định ở mức nào và đã từng xử lý lost update, vd. bằng SELECT ... FOR UPDATE hoặc optimistic locking.

Đo trước rồi mới sửa: tìm đúng query chậm, đọc execution plan, rồi chỉnh index hoặc cách viết query.

1. Bật slow query log (MySQL) hoặc pg_stat_statements (PostgreSQL) để biết query nào tốn thời gian nhất.
2. Chạy EXPLAIN (PostgreSQL nên dùng EXPLAIN (ANALYZE, BUFFERS)) xem có full scan, ước lượng số dòng lệch nhiều so với thực tế, sort trên đĩa không.
3. Sửa theo nguyên nhân: thêm hoặc đổi composite index, bỏ hàm bọc cột, chỉ SELECT cột cần, phân trang bằng keyset thay cho OFFSET lớn.
4. Kiểm tra phía ứng dụng: lỗi N+1 query, thiếu connection pool, lock chờ lâu.
5. Cập nhật thống kê (ANALYZE) nếu planner ước lượng sai.

Người phỏng vấn muốn nghe: quy trình có số liệu trước/sau, không phải đoán rồi thêm index bừa.

Load balancer tầng 4 phân phối theo IP/port (TCP/UDP), không đọc nội dung; tầng 7 hiểu HTTP nên định tuyến được theo path, host, header.

• L7 (ALB, Application Gateway, HTTP(S) LB): định tuyến /api và /web tới các nhóm khác nhau, kết thúc TLS, gắn WAF, hợp web/API.
• L4 (NLB, Azure Load Balancer): độ trễ thấp, thông lượng cao, giao thức không phải HTTP (game, MQTT, DB proxy), cần IP tĩnh.
• Cả hai đều có health check để loại máy hỏng.

Hay sai: health check trỏ vào trang nặng hoặc phụ thuộc DB, khiến LB loại hết máy khi DB chậm.

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

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.

Đây là câu mở đầu gần như chắc chắn có. Dùng công thức Hiện tại – Quá khứ – Tương lai, gói trong khoảng 1–2 phút.

• Hiện tại: vị trí, số năm kinh nghiệm, mảng/công nghệ chính.
• Quá khứ: một hai dự án hoặc thành tích liên quan nhất tới vị trí đang tuyển.
• Tương lai: vì sao bạn quan tâm tới vị trí này.

Câu mẫu: "Em là backend developer, khoảng 3 năm kinh nghiệm, chủ yếu làm Java Spring cho hệ thống thanh toán. Ở dự án gần nhất em phụ trách module đối soát và tối ưu các truy vấn báo cáo chạy chậm. Em đang tìm môi trường làm sản phẩm lâu dài để đi sâu hơn về thiết kế hệ thống, nên rất quan tâm tới vị trí này."

Hay sai: kể từ quê quán, trường cấp ba, hoặc đọc lại nguyên CV.