Chuyên Viên Cao cấp/Chuyên Gia Vận Hành Ứng dụng (OPN)

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

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.

Mục tiêu là thu nhỏ bề mặt tấn công và có khả năng phát hiện bất thường.

• Cập nhật hệ thống, bật cập nhật bảo mật tự động; gỡ dịch vụ không dùng.
• SSH: chỉ đăng nhập bằng key, tắt đăng nhập root và mật khẩu, giới hạn IP nguồn hoặc đi qua VPN/bastion.
• Firewall (nftables, ufw, security group) chỉ mở port cần thiết.
• Tài khoản riêng cho từng người, dùng sudo, không chia sẻ tài khoản.
• Chống dò mật khẩu (fail2ban), bật SELinux/AppArmor nếu ứng dụng hỗ trợ.
• Đẩy log sang hệ thống tập trung, giám sát đăng nhập và thay đổi file quan trọng.

Người phỏng vấn muốn nghe: làm bằng script hoặc Ansible để mọi server giống nhau, không làm tay từng máy.

Ưu tiên khôi phục, giao tiếp rõ ràng, rồi mới tìm nguyên nhân và khắc phục tận gốc.

1. Báo cho người dùng và quản lý biết đang xử lý, ước lượng thời gian.
2. Kiểm tra nhanh: nguồn điện, đèn cổng, console vào được không, log thiết bị.
3. Nghi vòng lặp L2 (broadcast storm): rút dây gần đây, kiểm tra STP.
4. Hỏng phần cứng: thay bằng thiết bị dự phòng, nạp lại cấu hình đã backup.
5. Sau sự cố: viết báo cáo, xác định điểm lỗi đơn, đề xuất dự phòng (stack/hai switch lõi, nguồn kép, UPS), quy trình thay đổi cấu hình có duyệt.

Người phỏng vấn muốn nghe: có backup cấu hình và tài liệu sẵn, không phải dựng lại từ trí nhớ.

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.

WHERE lọc từng dòng trước khi gom nhóm; HAVING lọc sau GROUP BY, nên dùng được hàm tổng hợp như COUNT, SUM.

Thứ tự logic: FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT/OFFSET.

SELECT department_id, AVG(salary) AS avg_salary
FROM employees
WHERE status = 'active'
GROUP BY department_id
HAVING AVG(salary) > 20000000;

• Vì SELECT chạy sau WHERE, bạn không dùng được alias của SELECT trong WHERE (đa số DB).
• Điều kiện không cần hàm tổng hợp thì nên để ở WHERE để giảm số dòng phải gom nhóm.

Người phỏng vấn muốn nghe: bạn hiểu thứ tự logic, từ đó giải thích được vì sao alias hoặc aggregate dùng sai chỗ bị lỗi.

Index là cấu trúc dữ liệu phụ (thường là B-Tree) giúp tìm dòng theo giá trị cột mà không phải quét cả bảng, đổi lại tốn dung lượng và làm chậm thao tác ghi.

• B-Tree hợp với so sánh =, <, >, BETWEEN, ORDER BY, LIKE 'abc%'.
• Mỗi INSERT/UPDATE/DELETE phải cập nhật thêm mọi index liên quan.
• Cột có độ chọn lọc thấp (vd. gender, is_deleted) đánh index riêng thường ít tác dụng.

Không nên đánh index tràn lan: chỉ thêm cho cột hay xuất hiện trong WHERE, JOIN, ORDER BY của các query quan trọng, rồi kiểm tra bằng EXPLAIN.

Hay sai: bọc cột trong hàm, vd. WHERE YEAR(created_at) = 2026 hoặc LOWER(email) = ..., khiến index thường trên cột đó không được dùng. Hãy viết lại thành khoảng thời gian hoặc dùng index trên biểu thức.

OSI có 7 tầng: Physical, Data Link, Network, Transport, Session, Presentation, Application. Thực tế người ta hay dùng mô hình TCP/IP 4 tầng, nhưng vẫn gọi tên theo OSI.

• Switch (L2): chuyển frame theo địa chỉ MAC; switch L3 có thêm định tuyến.
• Router (L3): định tuyến gói theo địa chỉ IP giữa các mạng.
• Firewall: lọc ở L3/L4 (IP, port); firewall thế hệ mới đọc được tới L7 (ứng dụng, URL).
• TCP/UDP ở L4; HTTP, DNS ở L7.

Người phỏng vấn muốn nghe: dùng OSI để khoanh vùng sự cố, ví dụ "ping được nhưng không mở được web" là vấn đề từ L4 trở lên.

Cho thấy bạn có cách làm cụ thể, không chỉ nói "em chịu được áp lực".

• Chia nhỏ việc, ưu tiên phần quan trọng nhất cho mục tiêu.
• Báo sớm cho lead/PM nếu thấy không kịp, đề xuất cắt phạm vi hoặc xin hỗ trợ.
• Giữ chất lượng ở phần cốt lõi; ghi lại nợ kỹ thuật để xử lý sau.
• Giữ bình tĩnh, giao tiếp ngắn gọn, rõ ràng với team.

Câu mẫu theo STAR: "Trước buổi demo cho khách, team phát hiện lỗi tích hợp chỉ còn hai ngày. Em liệt kê các phần bị ảnh hưởng, cùng PM chọn luồng nào bắt buộc phải chạy cho demo, phần còn lại hẹn bàn giao tuần sau. Demo diễn ra suôn sẻ và khách đồng ý với lịch mới."

Hay sai: khoe thức trắng nhiều đêm. Người phỏng vấn muốn thấy bạn quản lý được áp lực, không chỉ chịu đựng.