Chuyên viên Vận hành ứng dụng

Chuẩn hoá là tách dữ liệu để mỗi thông tin chỉ lưu ở một chỗ, tránh dư thừa và sai lệch khi cập nhật.

• 1NF: mỗi ô một giá trị nguyên tử, không lưu danh sách trong một cột.
• 2NF: cột không khoá phụ thuộc vào toàn bộ khoá chính, không chỉ một phần.
• 3NF: cột không khoá không phụ thuộc bắc cầu qua cột không khoá khác.

Denormalize khi đọc nhiều hơn ghi rất nhiều và JOIN trở thành điểm nghẽn: lưu sẵn comment_count trong bảng bài viết, chép customer_name vào đơn hàng để giữ đúng tên tại thời điểm đặt, hoặc dựng bảng báo cáo riêng.

Hay sai: denormalize mà không có cơ chế đồng bộ (trigger, job, event) nên số liệu lệch dần. Hãy nói rõ cái giá phải trả là logic ghi phức tạp hơn.

Deadlock là khi hai transaction giữ khoá mà bên kia cần và chờ nhau mãi. DB tự phát hiện, chọn một transaction làm nạn nhân và rollback nó.

Ví dụ: T1 khoá dòng A rồi muốn B, cùng lúc T2 khoá B rồi muốn A.

Cách giảm deadlock:

• Luôn khoá tài nguyên theo cùng một thứ tự (vd. sắp xếp theo id trước khi update nhiều dòng).
• Giữ transaction ngắn, không chờ I/O bên ngoài khi đang giữ khoá.
• Có index phù hợp để câu UPDATE/DELETE không khoá quá nhiều dòng.
• Ứng dụng bắt lỗi deadlock và retry có giới hạn.

Khi điều tra: MySQL dùng SHOW ENGINE INNODB STATUS, PostgreSQL xem log (deadlock được ghi kèm câu lệnh) và pg_locks.

Người phỏng vấn muốn nghe: bạn coi retry là bình thường nhưng vẫn tìm gốc rễ ở thứ tự khoá.

Chọn theo mô hình truy cập dữ liệu, không theo xu hướng. SQL mạnh ở quan hệ, ràng buộc và transaction; NoSQL mạnh ở schema linh hoạt, mô hình dữ liệu đặc thù hoặc scale ngang dễ hơn.

• Document (MongoDB): dữ liệu dạng cây, đọc nguyên khối theo một khoá, schema thay đổi thường xuyên.
• Key-value (Redis): cache, session, rate limit, bộ đếm, hàng đợi nhỏ; dữ liệu chủ yếu nằm trong RAM.
• Wide-column, time-series, search engine: ghi khối lượng lớn, log, tìm kiếm full-text.

Trade-off: JOIN và transaction nhiều document hạn chế hoặc đắt hơn, ràng buộc dữ liệu chuyển sang tầng ứng dụng, và phải thiết kế theo query ngay từ đầu.

Người phỏng vấn muốn nghe: nhiều hệ thống dùng kết hợp, vd. PostgreSQL làm nguồn sự thật, Redis làm cache. PostgreSQL với JSONB cũng đủ cho nhiều nhu cầu "schema linh hoạt".

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

Bắt đầu từ RPO/RTO của từng hệ thống, rồi áp quy tắc 3-2-1: 3 bản sao dữ liệu, trên 2 loại phương tiện, 1 bản ở nơi khác.

• Có ít nhất một bản bất biến hoặc tách rời (offline, immutable) để chống ransomware mã hoá luôn cả backup.
• Kết hợp full và incremental; database dùng công cụ backup riêng để dữ liệu nhất quán.
• Phân quyền: tài khoản backup không dùng chung với tài khoản quản trị domain.
• Mã hoá bản backup, giám sát job thất bại.
• Diễn tập khôi phục định kỳ và đo thời gian thực tế.

Hay sai: coi RAID hoặc snapshot là backup. RAID không chống xoá nhầm; snapshot nằm cùng hệ thống với dữ liệu gốc.

Đo trước: chi phí và độ trễ đến từ số token vào/ra, kích thước mô hình, số lần gọi trong một yêu cầu.

• Chọn mô hình: định tuyến, việc dễ cho mô hình nhỏ, việc khó mới gọi mô hình lớn.
• Giảm token: prompt gọn, truy xuất ít đoạn nhưng chính xác hơn (rerank), giới hạn độ dài đầu ra.
• Prompt caching cho phần prompt cố định lặp lại; cache câu trả lời cho câu hỏi trùng.
• Streaming để người dùng thấy chữ sớm, cải thiện độ trễ cảm nhận.
• Gộp việc không gấp thành batch.
• Tự host: quantization, batching động, engine suy luận tối ưu.

Người phỏng vấn muốn nghe: mọi tối ưu đều kiểm tra lại bằng bộ eval để chắc chất lượng không giảm.

Mỗi kỹ thuật giải một vấn đề khác nhau, nên cần xác định điểm nghẽn là đọc, ghi hay kích thước dữ liệu.

• Read replica: giảm tải đọc. Phải chấp nhận replication lag; luồng vừa ghi xong đọc lại nên đọc từ primary.
• Partitioning (trong một DB): chia bảng theo khoảng thời gian hoặc theo key. Query có điều kiện trên partition key chỉ quét phần liên quan, xoá dữ liệu cũ bằng DROP PARTITION rất nhanh.
• Sharding (nhiều DB): khi một máy không chịu nổi lượng ghi hoặc dung lượng. Đổi lại phải chọn shard key cẩn thận, query xuyên shard và transaction phân tán rất khó.

Thứ tự hợp lý: tối ưu query và index, archive dữ liệu cũ, thêm replica và cache, partition, cuối cùng mới shard.

Hay sai: chọn shard key gây hot spot, vd. theo ngày tạo khiến mọi lượt ghi dồn vào một shard.

Chia thay đổi thành nhiều bước tương thích ngược để phiên bản code cũ và mới chạy song song được (expand rồi contract).

1. Expand: thêm cột mới cho phép NULL hoặc có default; tránh câu lệnh viết lại cả bảng.
2. Code mới ghi vào cả cột cũ và mới.
3. Backfill dữ liệu cũ theo từng lô nhỏ, có nghỉ giữa các lô để không gây lag replica.
4. Chuyển code sang đọc cột mới, kiểm tra kỹ.
5. Contract: bỏ cột cũ ở một lần deploy sau.

Index trên bảng lớn: PostgreSQL dùng CREATE INDEX CONCURRENTLY; MySQL dùng online DDL hoặc công cụ như gh-ost, pt-online-schema-change.

Người phỏng vấn muốn nghe: bạn biết DDL có thể giữ lock khiến mọi query xếp hàng, nên đặt lock_timeout và luôn có kế hoạch rollback.

JOIN quyết định giữ lại những dòng nào khi ghép hai bảng theo điều kiện.

• INNER JOIN: chỉ giữ dòng khớp ở cả hai bảng.
• LEFT JOIN: giữ mọi dòng bảng trái; bảng phải không khớp thì cột thành NULL.
• RIGHT JOIN: ngược lại với LEFT, ít dùng vì có thể đổi chỗ bảng.
• FULL OUTER JOIN: giữ tất cả dòng của cả hai (MySQL không hỗ trợ trực tiếp, phải UNION hai LEFT JOIN).

Ví dụ tìm khách chưa từng đặt hàng:

SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

Hay sai: đặt điều kiện lọc bảng phải trong WHERE (vd. WHERE o.status = 'paid') làm LEFT JOIN biến thành INNER JOIN; điều kiện đó phải để trong ON.

Trả lời thật nhưng hướng về phía trước: nói điều bạn đang tìm kiếm, không kể xấu nơi cũ.

Lý do chấp nhận được: muốn thử thách mới, muốn làm sản phẩm, dự án kết thúc, công ty tái cấu trúc, thu nhập chưa tương xứng (nói khéo).

Câu mẫu: "Em đã làm 2 năm ở dự án outsourcing, học được nhiều về quy trình và làm việc với khách nước ngoài. Giờ em muốn gắn bó lâu dài với một sản phẩm để thấy được tác động của những gì mình làm, và vị trí bên mình đúng hướng đó."

Hay sai: chê sếp, chê đồng nghiệp, kể chuyện drama. Người phỏng vấn sẽ nghĩ bạn cũng sẽ nói về công ty họ như vậy. Nếu nhảy việc nhiều, chuẩn bị lời giải thích cho từng lần.