Chuyên viên Vận hành giám sát hệ thống và trực COB

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.

GitOps coi Git là nguồn sự thật cho trạng thái hệ thống; một agent trong cluster (Argo CD, Flux) liên tục kéo và đồng bộ, thay vì CI đẩy thẳng bằng kubectl.

• Tách repo code ứng dụng và repo cấu hình deploy; CI build image rồi mở PR cập nhật tag.
• Cấu hình dùng chung bằng Helm chart hoặc Kustomize, overlay riêng cho dev/staging/prod.
• Lên prod qua PR có review; rollback bằng git revert.
• Bật phát hiện drift và tự sửa lệch cấu hình.
• CI không cần giữ credential admin của cluster.

Người phỏng vấn muốn nghe: cân nhắc được đánh đổi, ví dụ secret vẫn cần giải pháp riêng và số lượng PR cập nhật tag có thể nhiều.

Container dùng chung kernel của máy chủ và cô lập bằng namespace + cgroup, nên khởi động nhanh và nhẹ; VM ảo hoá cả phần cứng và chạy một hệ điều hành riêng.

• Container: nhẹ, đóng gói ứng dụng cùng thư viện, hợp microservice và CI/CD.
• VM: cô lập mạnh hơn, chạy được kernel/OS khác (Windows trên host Linux), hợp workload cần ranh giới bảo mật rõ hoặc phần mềm cũ.
• Thực tế hai thứ thường đi cùng nhau: node Kubernetes chính là các VM trên cloud.

Hay sai: nói container "an toàn như VM". Container thoát ra host được nếu chạy --privileged hoặc kernel có lỗ hổng.

Ư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ớ.

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.

== so sánh tham chiếu (hai biến có trỏ cùng một object không), còn equals() so sánh nội dung theo logic bạn định nghĩa.

• Hợp đồng: hai object equals nhau thì bắt buộc có cùng hashCode.
• HashMap/HashSet dùng hashCode để chọn bucket trước, rồi mới dùng equals để so trong bucket. Nếu chỉ override equals, hai object "bằng nhau" có thể rơi vào hai bucket khác nhau, nên set.contains(x) trả về false dù đã add.
• Với Java 16+, record tự sinh equals/hashCode/toString theo các field.

Hay sai: so sánh String hoặc Integer bằng ==. Nó có thể chạy đúng nhờ string pool hoặc cache Integer từ -128 đến 127, rồi sai với giá trị khác.

Ý chính: dùng multi-stage build, sắp xếp layer để tận dụng cache, và không chạy bằng root.

FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-alpine
USER node
COPY --from=build /app/dist /app

• Copy file khai báo dependency trước, code sau, để đổi code không phải cài lại package.
• Dùng .dockerignore loại node_modules, .git, file .env.
• Không nhét secret vào image (kể cả ở layer đã xoá); dùng build secret hoặc biến môi trường lúc chạy.
• Ghim phiên bản base image, quét lỗ hổng trong pipeline.

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.

Trả lời thẳng thắn và cân bằng: sẵn sàng khi thật sự cần, nhưng không coi OT kéo dài là bình thường.

Câu mẫu: "Em sẵn sàng làm thêm khi có việc gấp như sự cố production hay trước một đợt release quan trọng. Nhưng nếu OT diễn ra thường xuyên, em nghĩ cần xem lại cách estimate hoặc phạm vi, và em sẽ chủ động nêu điều đó với team. Em cũng muốn hỏi thêm: ở team mình OT thường xảy ra trong trường hợp nào và được tính như thế nào ạ?"

Đây cũng là lúc bạn tìm hiểu ngược: OT có được trả lương hoặc nghỉ bù theo quy định không, tần suất ra sao. Câu trả lời của họ cho bạn biết nhiều về văn hoá công ty.

Hay sai: hứa "OT thoải mái" để lấy điểm, rồi vào làm mới thấy không chịu nổi.