Infrastructure & Networking

Module 11 — Kiến trúc thực tế: các hệ thống lớn được xây thế nào và vì sao Mỗi mục dưới đây là một bài tập tổng hợp của 10 module trước. Cấu trúc chung: đặc trưng workload → nó ép ra kiến trúc gì → trade-off và failure case đã trả giá. Điều đáng học không phải sơ đồ — mà là chuỗi suy luận từ workload ra kiến trúc. ...

Module 10 — Security cho Backend Systems Nguyên tắc chi phối toàn module: defense in depth (nhiều lớp — vì mỗi lớp SẼ có lỗ) và least privilege (mọi thứ chỉ được quyền tối thiểu — để khi bị xuyên, blast radius nhỏ nhất). Security không phải tính năng thêm sau; nó là thuộc tính kiến trúc như latency. 1. Authentication & Authorization: TLS/mTLS, JWT, OAuth2 mTLS — máy xác thực máy TLS thường: client xác thực server (module 01). mTLS: cả hai chiều — client cũng trình certificate. Đây là nền của zero-trust nội bộ: không tin “vì cùng mạng nội bộ” (perimeter model chết khi một máy bên trong bị chiếm — kẻ tấn công di chuyển ngang tự do). Vấn đề thật của mTLS không phải crypto mà là vận hành vòng đời cert: cấp phát, xoay ngắn hạn, thu hồi cho hàng nghìn service. Làm tay = bất khả thi; đây chính là lý do dùng service mesh (Istio/Linkerd tự động toàn bộ: SPIFFE identity, cert 24h, xoay tự động) hoặc SPIRE. Nếu không có nhu cầu compliance/zero-trust thật, cân nhắc kỹ trước khi trả chi phí vận hành mesh. ...

Module 09 — Reliability Engineering Tiên đề: mọi thứ đều hỏng. Disk hỏng, mạng phân mảnh, process bị OOM, con người gõ nhầm lệnh, và một ngày nào đó cả region sập. Reliability engineering không phải ngăn hỏng hóc — đó là thiết kế để hệ thống vẫn phục vụ được user khi từng phần của nó đang hỏng. 1. High Availability và Fault Tolerance Toán học nền tảng Availability chuỗi nối tiếp NHÂN với nhau: 5 service 99.9% nối tiếp = 99.5% (43 phút → 3.6 giờ downtime/tháng). Hệ quả khắc nghiệt: chuỗi phụ thuộc càng dài, availability càng tệ hơn mắt xích tệ nhất, và mọi dependency đồng bộ trong critical path đều phải “trả thuế” này. Ngược lại, redundancy song song: 2 bản 99% độc lập = 99.99% — nếu thật sự độc lập. ...

Module 08 — Observability Monitoring trả lời “hệ thống có đang hỏng theo cách tôi đã đoán trước không?”. Observability trả lời “hệ thống đang làm cái quái gì vậy?” — kể cả với lỗi chưa ai từng đoán. Trong hệ phân tán, lỗi thú vị luôn là lỗi chưa ai đoán trước. 1. Problem Statement Một request đi qua 15 service. User báo “chậm”. Không có observability: 15 team nhìn 15 dashboard riêng, ai cũng “service tôi bình thường”, 4 tiếng meeting để tìm ra một connection pool cạn ở service thứ 9. Chi phí thật của thiếu observability đo bằng MTTR (giờ thay vì phút) và bằng những sự cố âm ỉ không ai biết (lỗi 0.5% user suốt 3 tuần). ...

Module 07 — Cloud Infrastructure Cloud không phải “máy tính của người khác cho thuê”. Nó là một mô hình kinh tế + vận hành khác: đổi CAPEX thành OPEX, đổi “quản lý phần cứng” thành “quản lý cấu hình và chi phí”. Module này lấy AWS làm hệ quy chiếu; khái niệm ánh xạ 1-1 sang GCP/Azure. 1. VPC — mạng riêng ảo, nền của mọi thứ Problem Statement Trong datacenter chung của cloud, khách hàng cần một mạng cách ly logic hoàn toàn: tự chọn dải IP, tự quyết định gì nói chuyện với gì, gì thấy Internet. VPC = software-defined network cung cấp đúng điều đó — mọi tài nguyên bạn tạo đều sống trong một VPC, mọi quyết định security/network đầu tiên là quyết định topology VPC. ...

Module 06 — CI/CD và Deployment Strategy CI/CD không phải chuyện công cụ (Jenkins vs GitHub Actions). Nó là bài toán quản lý rủi ro thay đổi: thay đổi là nguồn sự cố số 1 của mọi hệ thống production, và cũng là thứ duy nhất tạo ra giá trị. Mục tiêu: tăng tần suất thay đổi VÀ giảm blast radius của mỗi thay đổi — hai thứ tưởng mâu thuẫn nhưng thực ra cộng hưởng. ...

Module 05 — Kubernetes Kubernetes không phải “công cụ chạy container”. Nó là một hệ điều khiển hội tụ trạng thái (desired state reconciliation). Nắm được mô hình đó, mọi thứ còn lại là chi tiết. 1. Tại sao Kubernetes tồn tại và mô hình tư duy cốt lõi Problem Statement Container giải bài toán đóng gói cho MỘT máy. Ở quy mô nhiều máy, các câu hỏi mới xuất hiện: đặt container nào lên máy nào (bin packing)? Máy chết thì container đi đâu? Traffic tìm container đang di chuyển thế nào? Rollout 200 instance không downtime bằng cách nào? Trước Kubernetes, mỗi công ty tự viết script/orchestrator riêng — Google đúc kết 15 năm chạy Borg thành Kubernetes. ...

Module 04 — Container Điều kiện tiên quyết: Module 03 (namespace, cgroup, OOM). Container không phải VM nhẹ — nó là process Linux được cách ly. Toàn bộ module này triển khai từ câu đó. 1. Tại sao container tồn tại Problem Statement Trước container, deploy có 2 lựa chọn tệ: Cài trực tiếp lên máy: “works on my machine” — app phụ thuộc phiên bản libc, Python, thư viện hệ thống của máy đó. Hai app cần 2 phiên bản khác nhau của cùng thư viện = xung đột. Môi trường dev/staging/prod lệch nhau = lớp bug riêng. VM: cách ly tốt nhưng mỗi VM chở nguyên một kernel + OS: boot hàng phút, tốn GB RAM cho phần không phải app, mật độ thấp. Container giải cả hai: đóng gói app + toàn bộ userspace dependency thành một artifact bất biến (giải quyết “works on my machine”), chạy như process thường trên kernel chung (giải quyết chi phí VM — khởi động ms, overhead ~0). ...

Module 03 — Linux Internals Mọi thứ bạn deploy cuối cùng đều là process trên Linux. Container, Kubernetes, “serverless” — tất cả là abstraction trên các cơ chế trong module này. Hiểu chúng = debug được mọi tầng phía trên. 1. Process, Thread và Scheduler Problem Statement Một CPU chỉ chạy được một luồng lệnh tại một thời điểm, nhưng hệ thống cần chạy hàng nghìn việc “đồng thời”, cách ly lỗi giữa các chương trình, và phân phối CPU công bằng. Process/thread + scheduler là câu trả lời của kernel. ...

Module 02 — Backend Networking Từ “mạng hoạt động thế nào” sang “hệ thống backend nói chuyện với nhau thế nào cho đáng tin cậy ở quy mô lớn”. 1. Connection Lifecycle, Keep-Alive và Connection Pooling Problem Statement Mỗi connection mới có chi phí cố định: TCP handshake (1 RTT) + TLS handshake (1–2 RTT) + slow start (nhiều RTT để đạt throughput). Với RTT 50ms, một HTTPS connection mới tốn ~150–250ms trước khi gửi byte đầu tiên. Service gọi nhau 1000 req/s mà mỗi request mở connection mới thì: latency cộng thêm hàng trăm ms, CPU đốt vào handshake, ephemeral port cạn (TIME_WAIT), file descriptor cạn. ...

Module 01 — Networking Fundamentals Đối tượng: Backend/Senior Engineer trở lên. Mục tiêu: hiểu mạng từ góc nhìn người thiết kế hệ thống — không phải người dùng công cụ. 1. OSI Model và TCP/IP — Tại sao phải chia tầng? Problem Statement Nếu mọi ứng dụng tự lo từ tín hiệu điện đến format dữ liệu, mỗi phần mềm phải viết lại toàn bộ stack mạng, và không phần mềm nào nói chuyện được với phần mềm khác. Bài toán cốt lõi: tách trách nhiệm (separation of concerns) để các hệ thống khác nhau tương tác được mà không cần biết chi tiết của nhau. ...

Infrastructure Handbook — Từ First Principles đến Production Bộ tài liệu chuyên sâu về hạ tầng cho hệ thống backend, viết cho Software/Backend/Senior Engineer, Tech Lead và Architect. Mục tiêu không phải liệt kê khái niệm — mà là giúp bạn hiểu tại sao mỗi công nghệ tồn tại, nó đánh đổi điều gì, và làm sao thiết kế/vận hành/debug hệ thống production. Cấu trúc Module Nội dung Vì sao đọc 01 — Networking Fundamentals OSI/TCP-IP, IP/CIDR/NAT, TCP, UDP, DNS, HTTP 1.1→3, QUIC, TLS Nền của mọi thứ; 80% sự cố “bí ẩn” nằm ở đây 02 — Backend Networking Connection pooling, LB, CDN, WebSocket, gRPC, service discovery, timeout/retry/circuit breaker Cách service nói chuyện với nhau cho đáng tin cậy 03 — Linux Internals Process/thread/scheduler, memory, fd, epoll, signal, cgroup/namespace, OOM Mọi thứ deploy đều là process Linux; hiểu nó = debug được mọi tầng trên 04 — Container Docker/containerd/runc, image/layer/overlayfs, networking, storage, security Container = process được cách ly, không phải VM nhẹ 05 — Kubernetes Reconciliation model, Pod/probe, controllers, Service/Ingress, scheduler, autoscaling, volume Hệ điều khiển hội tụ trạng thái — nắm mô hình, chi tiết tự sáng 06 — CI/CD Pipeline, artifact bất biến, rolling/blue-green/canary, rollback, feature flag, GitOps Quản lý rủi ro thay đổi — nguồn sự cố số 1 07 — Cloud Infrastructure VPC/subnet/routing, SG, NAT, managed services, autoscaling, multi-region, cost Topology và kinh tế học của cloud 08 — Observability Logging, metrics/Prometheus, tracing/OTel, SLI/SLO/SLA, alerting Không đo được thì không vận hành được 09 — Reliability Engineering HA, DR/RTO/RPO, bulkhead, degradation, load shedding, chaos engineering, postmortem Thiết kế để phục vụ user khi mọi thứ đang hỏng 10 — Security TLS/mTLS, JWT/OAuth2, secret management, WAF/DDoS, container & K8s security Defense in depth + least privilege như thuộc tính kiến trúc 11 — Kiến trúc thực tế E-commerce, FinTech, Social, SaaS, Video, Messaging, Blockchain, AI Platform Bài tập tổng hợp: từ workload suy ra kiến trúc Cách đọc Đọc tuần tự lần đầu: các module xây trên nhau có chủ đích (TCP slow start ở module 01 giải thích connection pooling ở module 02; cgroup ở module 03 giải thích CPU throttling ở module 05; retry ở module 02 quay lại trong FinTech ở module 11). Lộ trình theo vai trò: Backend Engineer: 01 → 02 → 03 → 08, rồi phần còn lại. Tiếp quản vận hành Kubernetes: 03 → 04 → 05 → 08 → 09. Chuẩn bị lên Architect: đọc hết, dừng lâu ở mọi bảng trade-off và module 11. Dùng làm tài liệu tra cứu sự cố: mỗi module có bảng troubleshooting/lệnh Linux; module 03 có bảng “triệu chứng → lệnh đầu tiên” đáng in ra. Triết lý của bộ tài liệu Mỗi chủ đề đi theo mạch: vấn đề gì → vì sao giải pháp cũ không đủ → công nghệ này hoạt động thế nào bên trong → đánh đổi cái gì → dùng ở production ra sao → khi nào KHÔNG dùng → hỏng thì debug thế nào. Mọi kết luận kỹ thuật đều phải trả lời được: tại sao, đánh đổi gì, và điều gì xảy ra nếu làm ngược lại. ...