Practice Execution Playbook
Mục tiêu của thực hành không phải “chạy được lệnh”, mà là biến kiến thức thành bằng chứng: bạn dự đoán điều gì, hệ thống thực sự làm gì, bạn quan sát bằng công cụ nào và từ đó giải thích được cơ chế.
Dự đoán → Thực thi → Quan sát → Giải thích → Cố tình làm hỏng → Khôi phục. Nếu chỉ copy command rồi thấy PASS, bạn mới kiểm tra được tutorial chứ chưa kiểm tra được hiểu biết.1. Trước khi chạy: viết điều bạn dự đoán
Trước mỗi lab, ghi 2–5 dòng: điều gì sẽ xảy ra, output hoặc trạng thái nào bạn mong đợi, và vì sao. Bước này buộc bạn dùng mental model trước khi nhìn kết quả.
- Java/JVM: method nào được gọi, object/reference nằm ở đâu về mặt logic, exception hoặc bytecode nào dự đoán xuất hiện?
- Database: query plan/lock/isolation anomaly nào dự đoán xảy ra?
- Messaging: message được lưu, ack, retry, redeliver hay đưa vào DLQ ở bước nào?
- Kubernetes: object nào được tạo trước, controller nào reconcile và condition nào cho biết workload thật sự ready?
2. Thực thi: làm cho lần chạy có thể tái hiện
Một lần chạy đáng tin phải ghi rõ môi trường. Tối thiểu giữ version, command, input/config và file thay đổi. Với bài phụ thuộc timing hoặc concurrency, chạy nhiều lần và ghi điều kiện tải.
# Ví dụ evidence tối thiểu
java -version
./mvnw -version
./mvnw test
# Hoặc với hạ tầng
kubectl version
kubectl get pods -A
kubectl describe pod <name>
3. Quan sát: đừng chỉ nhìn dòng cuối
| Nhóm bài | Bằng chứng nên giữ | Câu hỏi phải trả lời |
|---|---|---|
| Java/JVM | javap, JFR, thread dump, heap/class histogram, stdout/stderr | Điều source code gợi ý có khớp bytecode/runtime evidence không? |
| Spring | startup log, bean/proxy type, Actuator, transaction log, test result | Lời gọi có đi qua container/proxy boundary không? |
| PostgreSQL/Redis | EXPLAIN (ANALYZE, BUFFERS), locks/waits, transaction timeline, persistence/restart result | Correctness và performance đang bị chi phối bởi cơ chế nào? |
| API/Network | curl -v, headers, timing, DNS/TLS evidence, trace/correlation id | Lỗi nằm ở name resolution, connection, TLS, HTTP hay application? |
| RabbitMQ/Kafka | publish/consume log, ack/offset, redelivery, DLQ, lag | Message có thể duplicate/mất/đảo thứ tự trong phạm vi nào? |
| Docker/Kubernetes | image digest, manifest, events, describe/logs, rollout status, resource usage | Desired state khác observed state ở bước nào? |
| Observability | dashboard query, log filter, trace id, profile snapshot | Signal nào xác nhận hoặc bác bỏ giả thuyết? |
4. Cố tình làm hỏng
Lab tốt luôn có failure case. Tắt dependency, đổi timeout, tạo duplicate request, dùng input sai, làm consumer crash giữa chừng hoặc thay resource limit. Sau đó quan sát hệ thống thất bại theo cách nào và có khôi phục được không.
5. Viết kết luận bằng ngôn ngữ phỏng vấn
Sau lab, viết hai phiên bản:
- 30 giây: định nghĩa + cơ chế chính + một trade-off.
- 2 phút: thêm failure case bạn vừa chạy, evidence quan sát được và cách khắc phục.
Ví dụ khung trả lời: “Cơ chế X giải quyết Y bằng cách Z. Trong lab tôi cố tình tạo lỗi A và quan sát B bằng công cụ C. Điều đó cho thấy giới hạn/trade-off D; trong production tôi sẽ theo dõi E và có phương án recovery F.”
6. Evidence Pack tối thiểu
- Version runtime/tool/library.
- Command chính xác đã chạy.
- Source/config tối thiểu để tái hiện.
- Kết quả happy path.
- Một failure case có chủ đích.
- Log/metric/trace/query plan hoặc artifact chứng minh kết luận.
- Giải thích “vì sao” bằng mental model, không chỉ mô tả output.
- Một câu “khi nào không nên dùng cách này?”.
7. Cách dùng với curriculum này
Mỗi Part có trang Thực hành và nhiều Part có Execution Labs. Dùng playbook này như quy tắc chung, sau đó thực hiện lab chuyên ngành trong Part. Khi ôn phỏng vấn, ưu tiên những lab bạn có thể tự kể lại từ dự đoán đến failure/recovery thay vì cố ghi nhớ toàn bộ command.
Nguồn chuẩn để đối chiếu cách làm evidence
JUnit User Guide · test execution và reporting.
Kubernetes · Debug Applications · workflow quan sát và chẩn đoán workload.
Google SRE Book · troubleshooting, incident response, monitoring và reliability practice.
Git Documentation · giữ thay đổi/evidence có thể review và tái hiện.