KHỐI 0 - Nền tảng bắt buộc (Ngày 1–5)

Ngày 1: Linux fundamentals cho cloud engineer

• Mục tiêu: Debug được một VM/container "bằng tay" khi mọi dashboard đều im lặng.

• Lý thuyết: Process lifecycle, filesystem hierarchy, iptables cơ bản, systemd unit/service management.

• Thực hành: SSH vào 1 Compute Engine VM, dùng ps, top, journalctl, iptables -L để kiểm tra 1 service đang chạy và log của nó.

Ngày 2: Networking fundamentals

• Mục tiêu: Hiểu request đi từ browser đến server qua những bước nào.

• Lý thuyết: TCP/IP stack, DNS resolution, TLS/SSL handshake cơ bản, L4 vs L7 load balancing, CDN caching.

• Thực hành: Dùng dig, curl -v, openssl s_client để trace 1 request HTTPS thật từ DNS lookup đến TLS handshake.

Ngày 3: Container & Kubernetes cơ bản

• Mục tiêu: Nắm vững building block trước khi học sâu K8s ở khối sau.

• Lý thuyết: Image layer & registry, container runtime (containerd), pod/deployment/service/ingress object model.

• Thực hành: Build 1 Docker image, push lên Artifact Registry, deploy lên GKE bằng kubectl apply thủ công (chưa dùng CI/CD).

Ngày 4: Git nâng cao

• Mục tiêu: Thao tác Git thành thạo để làm việc nhóm mà không phá lịch sử code.

• Lý thuyết: Rebase vs merge, git bisect để tìm commit gây bug, worktree, trunk-based development vs gitflow.

• Thực hành: Tự tạo 1 bug giả trong repo, dùng git bisect tìm ra commit gây lỗi; thực hành rebase interactive để dọn 5 commit thành 1.

Ngày 5: Đọc một hệ thống distributed đơn giản

• Mục tiêu: Có trực giác về consensus/replication trước khi học lý thuyết chính thức ở khối sau.

• Lý thuyết: Tổng quan kiến trúc Redis (single-thread, replication) hoặc etcd (Raft-based).

• Thực hành: Đọc phần "Replication" trong docs Redis, tự dựng 1 master-replica Redis local và quan sát dữ liệu đồng bộ.

KHỐI 1 - Thiết kế ứng dụng cloud-native (Ngày 6–12)

Ngày 6: Chọn platform đúng bài toán

• Mục tiêu: Quyết định Compute Engine vs GKE vs Cloud Run dựa trên dữ liệu, không theo cảm tính.

• Lý thuyết: Cold start, cost model, control-plane overhead của từng platform; khi nào cần full control (Compute Engine) vs khi nào cần tốc độ ship (Cloud Run).

• Thực hành: Deploy cùng 1 app lên cả Cloud Run và GKE, so sánh cold start time và cost ước tính cho cùng traffic pattern.

Ngày 7: API design

• Mục tiêu: Thiết kế API bền vững, không phải sửa breaking change liên tục.

• Lý thuyết: REST vs gRPC tradeoff, versioning strategy (URL/header), Apigee/Cloud API Gateway cho rate limiting & auth.

• Thực hành: Thiết kế 1 API versioned (/v1/...), cấu hình Cloud API Gateway giới hạn rate limit theo API key.

Ngày 8: Kiến trúc event-driven

• Mục tiêu: Biết khi nào nên và không nên dùng async.

• Lý thuyết: Pub/Sub, Eventarc, Workflows, Cloud Tasks, Cloud Scheduler - và rủi ro khi dùng async cho path cần latency thấp.

• Thực hành: Dựng 1 luồng: Cloud Run nhận request → publish Pub/Sub → Eventarc trigger 1 Cloud Function xử lý background.

Ngày 9: Data layer selection

• Mục tiêu: Chọn đúng database ngay từ đầu, tránh migrate đau đớn sau này.

• Lý thuyết: AlloyDB/Spanner (structured, strong consistency) vs Bigtable/Firestore (unstructured, tunable consistency) - CAP tradeoff thực tế.

• Thực hành: Viết 1 bảng so sánh cho chính app của bạn: loại dữ liệu, tần suất đọc/ghi, yêu cầu consistency → chọn database phù hợp và giải thích lý do.

Ngày 10: Failover, session affinity, caching

• Mục tiêu: Thiết kế cho failure ngay từ đầu, không đợi sự cố mới vá.

• Lý thuyết: Zonal vs regional failover, session affinity cho content delivery, caching layer với Memorystore.

• Thực hành: Bật session affinity trên Cloud Run/GKE service, đo hiệu quả caching bằng Memorystore trước/sau cho 1 endpoint đọc nhiều.

Ngày 11: Capacity modeling & load test

• Mục tiêu: Biết giới hạn hệ thống trước khi user báo lỗi.

• Lý thuyết: Ước lượng QPS, P99 latency budget, cách đọc kết quả load test để suy ra bottleneck.

• Thực hành: Viết script k6/Locust load test cho app của bạn, tìm điểm gãy (breaking point) về throughput.

Ngày 12: Multi-region design

• Mục tiêu: Quyết định đúng mức độ multi-region cần thiết, tránh over-engineering.

• Lý thuyết: Active-active vs active-passive, chi phí/độ phức tạp tăng theo cấp số nhân khi thêm region.

• Thực hành: Vẽ kiến trúc active-passive cho app của bạn (region chính + region backup), liệt kê rõ điều kiện nào mới cần active-active thật.

KHỐI 2 - Bảo mật ứng dụng (Ngày 13–17)

Ngày 13: Vulnerability detection & protection

• Mục tiêu: Có lớp phòng vệ tự động phát hiện lỗ hổng trước khi bị khai thác.

• Lý thuyết: Identity-Aware Proxy (IAP), Web Security Scanner, Artifact Analysis, Security Command Center tổng quan.

• Thực hành: Bật Web Security Scanner cho 1 app test, đọc kết quả finding và fix ít nhất 1 lỗ hổng được phát hiện.

Ngày 14: Secret & key lifecycle

• Mục tiêu: Không bao giờ để secret nằm trong code hoặc env var lộ thiên.

• Lý thuyết: Secret Manager, Cloud KMS, Workload Identity Federation thay cho service account key file.

• Thực hành: Chuyển 1 app đang hardcode secret sang dùng Secret Manager + Workload Identity Federation, xoá hết credential file khỏi repo.

Ngày 15: Authentication mechanisms

• Mục tiêu: Chọn đúng cơ chế auth cho từng loại service (user-facing vs service-to-service).

• Lý thuyết: Application Default Credentials, JWT, OAuth 2.0, Cloud SQL/AlloyDB Auth Proxy, Identity Platform.

• Thực hành: Cấu hình app kết nối Cloud SQL qua Auth Proxy thay vì IP + password, verify kết nối chỉ hoạt động qua IAM identity.

Ngày 16: Service-to-service security & supply chain

• Mục tiêu: Đảm bảo service chỉ giao tiếp với service được phép, và chỉ chạy image đáng tin.

• Lý thuyết: Cloud Service Mesh, Kubernetes NetworkPolicy, least privilege IAM, Binary Authorization.

• Thực hành: Viết 1 NetworkPolicy chặn pod A giao tiếp trực tiếp với pod C (chỉ được qua B), test bằng kubectl exec + curl.

Ngày 17: Threat modeling thực chiến

• Mục tiêu: Chủ động tìm điểm yếu bảo mật thay vì đợi bị hack mới biết.

• Lý thuyết: STRIDE framework (Spoofing, Tampering, Repudiation, Info disclosure, DoS, Elevation of privilege).

• Thực hành: Áp STRIDE lên chính app của bạn, liệt kê ít nhất 5 threat cụ thể và mitigation tương ứng; làm thêm 1 lab giả lập leaked service account key.

KHỐI 3 - Lưu trữ & truy cập dữ liệu (Ngày 18–21)

Ngày 18: Schema design

• Mục tiêu: Thiết kế schema đúng ngay từ đầu cho từng loại database.

• Lý thuyết: Structured schema (AlloyDB, Spanner) vs unstructured/denormalized (Bigtable, Firestore).

• Thực hành: Thiết kế schema Firestore cho 1 use case đọc nhiều-ghi ít (denormalize hợp lý) và schema Spanner cho use case cần transaction.

Ngày 19: Consistency implications

• Mục tiêu: Không bị bất ngờ khi dữ liệu "chưa kịp đồng bộ" trong production.

• Lý thuyết: Eventual vs strongly consistent replication trên AlloyDB, Bigtable, Cloud SQL, Spanner, Cloud Storage.

• Thực hành: Viết 1 kịch bản test: ghi dữ liệu rồi đọc lại ngay lập tức từ Firestore, quan sát trường hợp có thể đọc thấy dữ liệu cũ.

Ngày 20: Signed URL & BigQuery integration

• Mục tiêu: Cấp quyền truy cập tạm thời an toàn và đẩy dữ liệu vào pipeline phân tích.

• Lý thuyết: Cơ chế signed URL cho Cloud Storage, pattern ghi dữ liệu sang BigQuery cho analytics/AI/ML.

• Thực hành: Tạo signed URL có thời hạn 15 phút cho 1 object private, viết 1 job đẩy dữ liệu batch từ app sang BigQuery.

Ngày 21: Migration & backup/restore drill

• Mục tiêu: Đảm bảo bạn có thể thay đổi schema hoặc phục hồi dữ liệu mà không gây downtime/mất dữ liệu.

• Lý thuyết: Dual-write pattern, backfill, cutover cho migration không downtime; PITR concept cho backup.

• Thực hành: Tự tay restore 1 database từ backup sang instance mới, đo RTO/RPO thực tế đạt được.

KHỐI 4 - Build & Test (Ngày 22–25)

Ngày 22: Development environment setup

• Mục tiêu: Dev local giống production nhất có thể, giảm bug "chạy máy tôi thì được".

• Lý thuyết: Emulate Google Cloud service bằng gcloud CLI cho local testing, Cloud Code, Cloud Workstations.

• Thực hành: Cấu hình local emulator cho Pub/Sub hoặc Firestore, viết 1 unit test chạy hoàn toàn offline dựa trên emulator.

Ngày 23: Cloud Build & Artifact Registry

• Mục tiêu: Có pipeline build container tự động, có provenance để truy vết.

• Lý thuyết: Cloud Build config, Artifact Registry lưu container, provenance cho Binary Authorization.

• Thực hành: Viết cloudbuild.yaml build image từ source, push vào Artifact Registry, bật provenance.

Ngày 24: Unit test & integration test tự động

• Mục tiêu: Có safety net để refactor không sợ vỡ.

• Lý thuyết: Viết unit test có hỗ trợ AI coding assistant, chạy integration test tự động trong Cloud Build.

• Thực hành: Viết 5 unit test cho 1 module nghiệp vụ (dùng AI assistant gợi ý case biên), thêm bước integration test vào cloudbuild.yaml.

Ngày 25: Testing pyramid & flaky test

• Mục tiêu: Cân bằng đúng tỷ lệ test, không lãng phí thời gian debug test tự dưng fail.

• Lý thuyết: Testing pyramid (unit nhiều, integration vừa, e2e ít), contract testing (Pact) giữa các service, nguyên nhân phổ biến gây flaky test.

• Thực hành: Audit bộ test hiện có của bạn theo tỷ lệ pyramid, tìm và fix 1 flaky test thật (thường do race condition hoặc phụ thuộc thời gian).

KHỐI 5 - Deploy ứng dụng (Ngày 26–29)

Ngày 26: Deploy Cloud Run

• Mục tiêu: Nắm vững cách trigger và invoke Cloud Run service đúng cách.

• Lý thuyết: Deploy từ source, invoke qua Eventarc/Pub/Sub trigger, configure event receiver.

• Thực hành: Deploy 1 service Cloud Run trực tiếp từ source code (gcloud run deploy --source), gắn Eventarc trigger từ Cloud Storage event.

Ngày 27: Deploy GKE

• Mục tiêu: Đảm bảo pod tự phục hồi và scale đúng theo tải.

• Lý thuyết: Kubernetes health checks (readiness/liveness), Horizontal Pod Autoscaler dựa trên metric.

• Thực hành: Cấu hình readiness/liveness probe đúng cách cho 1 deployment, cấu hình HPA scale theo CPU và test bằng load generator.

Ngày 28: Progressive delivery

• Mục tiêu: Giảm rủi ro khi release tính năng mới.

• Lý thuyết: Feature flag service, kill switch, dark launch - tách việc "deploy code" khỏi "bật tính năng".

• Thực hành: Tích hợp 1 feature flag đơn giản (tự viết hoặc dùng thư viện open-source) để bật/tắt 1 tính năng không cần deploy lại.

Ngày 29: Zero-downtime deploy

• Mục tiêu: Deploy giữa giờ cao điểm mà user không nhận ra gì đã xảy ra.

• Lý thuyết: Connection draining, graceful shutdown (xử lý SIGTERM đúng cách), traffic splitting khi rollout.

• Thực hành: Thêm SIGTERM handler vào app (đóng connection đang xử lý trước khi thoát), test bằng cách deploy trong lúc có traffic liên tục và đo request lỗi (phải bằng 0).

KHỐI 6 - Tích hợp Google Cloud services (Ngày 30–33)

Ngày 30: Kết nối datastore

• Mục tiêu: Quản lý connection tới nhiều loại datastore một cách nhất quán.

• Lý thuyết: Managing connections tới Cloud SQL, Firestore, Cloud Storage; connection pooling ở tầng application.

• Thực hành: Viết 1 module kết nối dùng chung (connection pool) cho Cloud SQL, test dưới tải đồng thời.

Ngày 31: Messaging integration

• Mục tiêu: Publish/consume message đúng pattern, không mất message.

• Lý thuyết: Publish/subscribe pattern với Pub/Sub, acknowledge deadline, dead-letter topic.

• Thực hành: Viết 1 publisher và 1 consumer, cấu hình dead-letter topic cho message xử lý fail quá 5 lần.

Ngày 32: Gọi Cloud API đúng cách

• Mục tiêu: Gọi API hiệu quả, không tốn quota/cost oan.

• Lý thuyết: Batching request, restricting return field, pagination, caching kết quả, exponential backoff khi lỗi, dùng service account cho API call.

• Thực hành: Viết 1 client gọi Cloud API có exponential backoff + retry, restrict field trả về để giảm payload.

Ngày 33: Troubleshooting & idempotency

• Mục tiêu: Debug nhanh khi có lỗi, và thiết kế chịu được duplicate message.

• Lý thuyết: Dùng metrics/logs/traces trong Google Cloud Observability, Error Reporting, trace ID correlation; idempotency design cho consumer chịu retry/duplicate.

• Thực hành: Thêm idempotency key vào 1 API xử lý thanh toán/đơn hàng giả lập, test gửi trùng request và verify không bị xử lý 2 lần.

KHỐI 7 - Bootstrapping tổ chức GCP (Ngày 34–40)

Ngày 34: Resource hierarchy design

• Mục tiêu: Tổ chức project/folder đúng ngay từ đầu, tránh phải tái cấu trúc sau này.

• Lý thuyết: Org → folder → project hierarchy, application-centric vs project-centric organizing.

• Thực hành: Vẽ resource hierarchy cho 1 công ty giả định 3 team (platform, product A, product B) với folder/project rõ ràng.

Ngày 35: Shared networking

• Mục tiêu: Kết nối network giữa các project mà không bị đụng độ IP hay lộ traffic không cần thiết.

• Lý thuyết: Shared VPC, VPC Network Peering, Private Service Connect - khi nào dùng cái nào.

• Thực hành: Dựng Shared VPC với 1 host project và 2 service project, verify 2 service project giao tiếp được qua internal IP.

Ngày 36: IAM & governance

• Mục tiêu: Cấp quyền đúng người đúng việc, có policy chặn hành vi nguy hiểm ở cấp tổ chức.

• Lý thuyết: IAM roles, org-level policy, service account management, data residency requirement.

• Thực hành: Viết 1 Org Policy Constraint chặn tạo external IP cho VM, tạo custom IAM role giới hạn quyền tối thiểu cho 1 service account.

Ngày 37: IaC tooling overview

• Mục tiêu: Biết chọn công cụ IaC đúng theo use case (không phải lúc nào cũng Terraform).

• Lý thuyết: Infrastructure Manager, Cloud Foundation Toolkit, Config Connector, GitOps, Terraform, Helm - điểm mạnh/yếu từng loại.

• Thực hành: Viết cùng 1 hạ tầng đơn giản (1 GCS bucket + 1 service account) bằng cả Terraform và Config Connector, so sánh trải nghiệm.

Ngày 38: Quản lý multi-environment

• Mục tiêu: Có môi trường dev/staging/prod tách biệt an toàn, không lẫn dữ liệu.

• Lý thuyết: Ephemeral environment cho PR review, config/policy management theo môi trường, GKE fleet management, patching an toàn.

• Thực hành: Cấu hình 1 ephemeral environment tự tạo khi mở PR và tự xoá khi merge (dùng Cloud Build trigger + Terraform workspace).

Ngày 39: Terraform ở quy mô team

• Mục tiêu: Terraform không vỡ khi nhiều người cùng làm việc trên 1 hạ tầng.

• Lý thuyết: Module design, remote state + state locking, drift detection, review terraform plan trong PR.

• Thực hành: Refactor 1 file Terraform monolith thành module tái sử dụng, cấu hình remote state trên GCS với locking.

Ngày 40: Landing zone & policy-as-code

• Mục tiêu: Có nền tảng chuẩn để mọi project mới đều tuân thủ security/compliance ngay từ lúc tạo.

• Lý thuyết: Landing zone/blueprint pattern cho doanh nghiệp, OPA/Gatekeeper hoặc Org Policy Constraints để enforce tự động.

• Thực hành: Viết 1 policy chặn project mới không được tạo bucket public, test bằng cách cố tình tạo bucket vi phạm.

KHỐI 8 - CI/CD (Ngày 41–45)

Ngày 41: Cloud Build CI sâu

• Mục tiêu: Pipeline CI nhanh, đáng tin cậy, không phải "chạy lại vì flaky".

• Lý thuyết: Cloud Build trigger types, build step caching, parallel step execution.

• Thực hành: Tối ưu 1 cloudbuild.yaml hiện có bằng caching layer, đo thời gian build trước/sau.

Ngày 42: Cloud Deploy CD

• Mục tiêu: Deploy có kiểm soát qua nhiều môi trường với approval flow.

• Lý thuyết: Cloud Deploy pipeline, Kustomize và Skaffold cho templating manifest.

• Thực hành: Dựng Cloud Deploy pipeline dev → staging → prod với approval gate thủ công trước khi lên prod.

Ngày 43: Deployment strategies

• Mục tiêu: Chọn đúng chiến lược release theo mức độ rủi ro của thay đổi.

• Lý thuyết: Canary, blue/green, rolling, traffic splitting, feature flags - và cách định nghĩa success metric từ telemetry.

• Thực hành: Thực hiện 1 canary release thật (10% traffic) cho 1 thay đổi, định nghĩa metric quyết định rollback tự động (vd: error rate > 1%).

Ngày 44: Secret management & supply chain security

• Mục tiêu: Secret không lộ trong pipeline, artifact deploy production đáng tin cậy.

• Lý thuyết: Build-time vs runtime secret injection, Artifact Analysis vulnerability scanning, SLSA framework, Binary Authorization.

• Thực hành: Cấu hình Binary Authorization chỉ cho phép deploy image đã pass vulnerability scan, test bằng image cố tình có lỗ hổng.

Ngày 45: Pipeline as reliability boundary

• Mục tiêu: Pipeline tự bảo vệ production, không phụ thuộc con người phản ứng kịp thời.

• Lý thuyết: Rollback tự động dựa trên SLO burn rate, multi-cluster/multi-cloud CD (Argo CD ApplicationSet, GKE fleet).

• Thực hành: Cấu hình 1 alert policy trigger rollback tự động khi error rate vượt ngưỡng trong 5 phút liên tiếp.

KHỐI 9 - SRE thực hành (Ngày 46–51)

Ngày 46: SLI/SLO/SLA & error budget

• Mục tiêu: Có ngôn ngữ chung để cân bằng giữa tốc độ release và độ ổn định.

• Lý thuyết: Định nghĩa SLI (availability, latency), SLO, SLA; error budget và "số 9" gắn với opportunity cost thật.

• Thực hành: Định nghĩa 1 SLO cụ thể cho app của bạn (vd: 99.5% request < 300ms), tính error budget còn lại trong tháng dựa trên data thật.

Ngày 47: Service lifecycle management

• Mục tiêu: Quản lý service từ lúc sinh ra đến lúc "nghỉ hưu" có kiểm soát.

• Lý thuyết: Planning, deployment, maintenance, retirement - mỗi giai đoạn cần gì (docs, ownership, deprecation notice).

• Thực hành: Viết checklist "retirement" cho 1 service giả định, gồm cả thông báo consumer và xoá tài nguyên an toàn.

Ngày 48: Capacity planning & autoscaling

• Mục tiêu: Đủ tài nguyên khi cần, không lãng phí khi không cần.

• Lý thuyết: Quota, limit, reservation, Dynamic Workload Scheduler; autoscaling trên MIG, Cloud Run, GKE.

• Thực hành: Cấu hình autoscaling cho 1 service dựa trên custom metric (không chỉ CPU), test bằng traffic tăng đột biến giả lập.

Ngày 49: Mitigating incident impact

• Mục tiêu: Giảm thiệt hại ngay lập tức khi sự cố xảy ra, trước khi tìm root cause.

• Lý thuyết: Draining/redirecting traffic, adding capacity, rollback strategies.

• Thực hành: Giả lập 1 version lỗi đang serve traffic, thực hành rollback về version trước trong < 5 phút.

Ngày 50: Incident command & postmortem

• Mục tiêu: Có quy trình phản ứng sự cố rõ ràng, học được từ mỗi lần fail.

• Lý thuyết: Vai trò Incident Commander/comms lead/ops lead, severity classification, blameless postmortem culture.

• Thực hành: Chạy 1 kịch bản incident giả lập, phân vai, và viết 1 bản postmortem đầy đủ (timeline, root cause, action item).

Ngày 51: Chaos engineering & on-call

• Mục tiêu: Biết hệ thống có tự phục hồi thật không, thay vì chỉ tin vào thiết kế trên giấy.

• Lý thuyết: GameDay concept (kill pod, cắt network, đầy disk), escalation policy, alert fatigue tuning.

• Thực hành: Chạy 1 GameDay thật bằng Chaos Mesh (hoặc thủ công) trên GKE - kill pod ngẫu nhiên và quan sát hệ thống tự phục hồi.

KHỐI 10 - Observability (Ngày 52–57)

Ngày 52: Telemetry collection

• Mục tiêu: Thu thập đủ dữ liệu để debug mà không tốn quá nhiều chi phí lưu trữ.

• Lý thuyết: Ops Agent, OpenTelemetry, Cloud Audit Logs, VPC Flow Logs, log optimization (filter/sampling/exclusion).

• Thực hành: Cấu hình log exclusion filter loại bỏ log health-check ồn ào, đo lượng log giảm được (và cost tiết kiệm).

Ngày 53: Metrics collection

• Mục tiêu: Có metric đúng để trả lời câu hỏi "hệ thống có khoẻ không" trong 5 giây.

• Lý thuyết: Google Cloud Managed Service for Prometheus, custom metrics, log-based metrics, synthetic monitor.

• Thực hành: Tạo 1 synthetic monitor probe endpoint quan trọng mỗi phút, tạo 1 custom log-based metric đếm số lỗi 5xx.

Ngày 54: Log analysis & management

• Mục tiêu: Tìm ra nguyên nhân sự cố từ hàng triệu dòng log trong vài phút.

• Lý thuyết: Logs Explorer, Logging query language, export sang BigQuery/Pub/Sub/Cloud Storage, redact PII/PHI.

• Thực hành: Viết 1 query Logging language phức tạp (filter theo nhiều điều kiện + aggregate), cấu hình log processor redact số điện thoại/email.

Ngày 55: Dashboard & alerting

• Mục tiêu: Alert đúng người, đúng lúc, không spam gây "alert fatigue".

• Lý thuyết: Metrics Explorer, PromQL, alerting policy dựa trên SLO, tích hợp PagerDuty/Rootly.

• Thực hành: Dựng 1 dashboard tổng quan sức khoẻ service (RED method), cấu hình alert chỉ bắn khi vi phạm SLO thật (không phải mọi spike nhỏ).

Ngày 56: Distributed tracing

• Mục tiêu: Biết chính xác request chậm ở đâu trong chuỗi microservice.

• Lý thuyết: OpenTelemetry tracing, trace waterfall/span, correlate trace ID với structured log.

• Thực hành: Instrument 1 service với OpenTelemetry, trace 1 request đi qua 2-3 service và xác định span nào chiếm thời gian nhiều nhất.

Ngày 57: Observability-as-code & method luận

• Mục tiêu: Dashboard/alert được review như code, và biết nhìn đúng chỉ số trước khi có alert.

• Lý thuyết: Định nghĩa dashboard/alert bằng Terraform; USE method (Utilization/Saturation/Errors) cho resource, RED method (Rate/Errors/Duration) cho request.

• Thực hành: Chuyển 1 dashboard đang tạo tay trên UI sang định nghĩa bằng Terraform, đưa vào PR review.

KHỐI 11 - Performance & FinOps (Ngày 58–61)

Ngày 58: Application performance monitoring

• Mục tiêu: Phát hiện performance regression trước khi user phàn nàn.

• Lý thuyết: APM tổng quan, Active Assist insights & recommendations.

• Thực hành: Xem Active Assist recommendation cho project của bạn, áp dụng ít nhất 1 gợi ý (vd: rightsizing VM).

Ngày 59: FinOps fundamentals

• Mục tiêu: Hiểu cấu trúc chi phí GCP đủ sâu để tối ưu có chủ đích.

• Lý thuyết: Spot VM, committed-use discount, sustained-use discount, network tier (Premium vs Standard).

• Thực hành: Tính toán tiết kiệm nếu chuyển 1 workload batch sang Spot VM, so sánh network tier cho 1 use case cụ thể.

Ngày 60: Cost optimization theo workload

• Mục tiêu: Biết đòn bẩy tối ưu chi phí riêng cho từng loại compute.

• Lý thuyết: Tối ưu chi phí cho GKE (bin-packing, node pool riêng), Cloud Run (concurrency, min instance), Compute Engine (machine type, committed use).

• Thực hành: Audit 1 GKE cluster hoặc Cloud Run service hiện có, đề xuất 2-3 thay đổi cụ thể để giảm cost mà không giảm performance.

Ngày 61: FinOps vận hành thật

• Mục tiêu: Biến FinOps thành quy trình định kỳ, không phải việc làm 1 lần.

• Lý thuyết: Showback/chargeback theo team, budget alert kèm auto action, billing export ra BigQuery.

• Thực hành: Export billing data ra BigQuery, viết 1 query phân tích cost theo label/project trong 30 ngày gần nhất.

KHỐI 12 - Production extras (Ngày 62–66)

Ngày 62: Disaster Recovery

• Mục tiêu: Có kế hoạch DR đã được test thật, không chỉ nằm trên giấy.

• Lý thuyết: DR plan structure, RTO/RPO definition, failover testing cadence.

• Thực hành: Viết 1 DR plan cho service quan trọng nhất của bạn, lên lịch test failover định kỳ (vd: mỗi quý).

Ngày 63: Compliance & audit

• Mục tiêu: Hiểu đủ để làm việc được với đội compliance/audit, không cần là chuyên gia.

• Lý thuyết: Khái niệm SOC2/ISO27001 ở mức quy trình, log retention theo yêu cầu pháp lý, data residency thực tế.

• Thực hành: Đọc 1 audit checklist mẫu (tìm online), map từng mục vào control bạn đã có/chưa có trong hệ thống.

Ngày 64: Team & process

• Mục tiêu: Quy trình làm việc nhóm không phụ thuộc vào trí nhớ của 1 người.

• Lý thuyết: Change management, code review culture, documentation-as-code (runbook sống trong repo).

• Thực hành: Viết 1 runbook thật cho 1 tác vụ vận hành thường làm (vd: restart service, rotate credential), lưu trong repo cạnh code.

Ngày 65: Cấu trúc tổ chức DevOps & cost of downtime

• Mục tiêu: Hiểu mô hình tổ chức ảnh hưởng thế nào đến tốc độ và chất lượng vận hành.

• Lý thuyết: Platform team vs embedded SRE, "you build it you run it", cách tính business impact của downtime.

• Thực hành: Ước tính cost of downtime cho service của bạn (revenue/phút hoặc user impact), dùng con số đó để justify 1 khoản đầu tư reliability.

Ngày 66: Đọc nền tảng & đo DORA metrics

• Mục tiêu: Có framework đo lường mức độ trưởng thành DevOps thật sự, không chỉ dựa cảm tính.

• Lý thuyết: Tóm tắt các chương quan trọng của Site Reliability Engineering (Google) và Accelerate; 4 chỉ số DORA (deployment frequency, lead time, MTTR, change failure rate).

• Thực hành: Tự đo 4 chỉ số DORA cho project/team thật của bạn trong 2 tuần gần nhất, ghi lại baseline để so sánh sau này.

KHỐI NÂNG CAO (Ngày 67–102)

MODULE A - Kubernetes (Ngày 67–73)

Ngày 67: API Server & etcd internals

• Mục tiêu: Hiểu vì sao API Server chậm/lỗi khi cluster lớn, biết cách debug.

• Lý thuyết: API Server là stateless gateway, mọi thứ đi qua watch mechanism trên etcd; etcd dùng Raft, giới hạn 8GB mặc định, latency etcd ảnh hưởng toàn cluster.

• Thực hành: Bật etcdctl trên GKE (hoặc kind local), quan sát etcd_request_duration_seconds, thử tạo 5000 object rồi đo độ trễ list request.

Ngày 68: Scheduler & Controller Manager

• Mục tiêu: Biết vì sao pod bị Pending, tự viết được scheduling constraint đúng.

• Lý thuyết: Predicate/priority trong scheduling, node affinity/anti-affinity, taint-toleration, custom scheduler qua scheduler extender.

• Thực hành: Viết PodAntiAffinity để spread pod theo zone, giả lập node pressure và quan sát scheduler quyết định evict pod nào.

Ngày 69: CNI & kube-proxy internals

• Mục tiêu: Debug được vấn đề network trong cluster thay vì đoán mò.

• Lý thuyết: CNI plugin (Calico/Cilium) gắn IP cho pod thế nào, kube-proxy mode iptables vs IPVS, vì sao Cilium (eBPF) nhanh hơn iptables ở scale lớn.

• Thực hành: Cài Cilium trên GKE (Dataplane V2), dùng cilium monitor để trace 1 request giữa 2 pod khác node.

Ngày 70: Service Mesh internals

• Mục tiêu: Hiểu chi phí thật của mesh trước khi quyết định dùng.

• Lý thuyết: Sidecar proxy (Envoy) chặn traffic qua iptables redirect, mTLS handshake overhead, traffic shifting qua VirtualService/DestinationRule.

• Thực hành: Deploy Cloud Service Mesh (Istio) cho 2 service, đo thêm latency P99 do sidecar gây ra, thử canary 10% traffic bằng mesh thay vì Cloud Deploy.

Ngày 71: Pod Security & Policy enforcement

• Mục tiêu: Enforce được security baseline tự động, không phụ thuộc review thủ công.

• Lý thuyết: Pod Security Standards (restricted/baseline/privileged), OPA Gatekeeper (ConstraintTemplate) vs Kyverno (YAML-native, dễ viết hơn).

• Thực hành: Viết 1 Kyverno policy chặn container chạy root hoặc thiếu resources.limits, test bằng pod cố tình vi phạm.

Ngày 72: Runtime security

• Mục tiêu: Phát hiện hành vi bất thường trong container đang chạy (không chỉ chặn lúc deploy).

• Lý thuyết: Falco dùng eBPF/kernel module để detect syscall bất thường, seccomp profile giới hạn syscall, AppArmor giới hạn file access.

• Thực hành: Cài Falco trên GKE, giả lập 1 container bị exec vào (kubectl exec) và xem Falco alert thế nào; viết seccomp profile custom cho 1 workload.

Ngày 73: Autoscaling & node lifecycle

• Mục tiêu: Hiểu rõ đánh đổi giữa Cluster Autoscaler và bin-packing kiểu Karpenter.

• Lý thuyết: Cluster Autoscaler dựa trên pending pod + node group, Karpenter provision node theo yêu cầu thực tế (just-in-time), disruption budget khi scale-down.

• Thực hành: Cấu hình GKE Autopilot vs Standard với Cluster Autoscaler, giả lập spike traffic và đo thời gian từ Pending → node sẵn sàng.

MODULE B - Networking (Ngày 74–78)

Ngày 74: TCP internals cho production

• Mục tiêu: Đọc hiểu vì sao service bị timeout dù CPU/RAM bình thường.

• Lý thuyết: TCP congestion control (Cubic/BBR), connection pooling, keepalive timeout mismatch giữa client-LB-backend là nguyên nhân phổ biến gây lỗi 502.

• Thực hành: Dùng tcpdump/ss -tan trên 1 VM, tái hiện lỗi do keepalive timeout backend ngắn hơn LB rồi fix.

Ngày 75: TLS, HTTP/2, HTTP/3/QUIC

• Mục tiêu: Biết chọn giao thức đúng và debug TLS handshake chậm.

• Lý thuyết: TLS 1.3 handshake rút gọn, HTTP/2 multiplexing và vấn đề head-of-line blocking, QUIC chạy trên UDP giải quyết vấn đề đó.

• Thực hành: Bật HTTP/3 trên Cloud Load Balancing, so sánh thời gian tải trang qua HTTP/2 vs HTTP/3 bằng Chrome DevTools.

Ngày 76: Cloud NAT & Cloud Armor

• Mục tiêu: Kiểm soát outbound traffic và chặn tấn công ở layer 7.

• Lý thuyết: Cloud NAT port allocation & SNAT exhaustion (lỗi hay gặp khi scale), Cloud Armor rule (rate-based, geo-block, OWASP preconfigured rule).

• Thực hành: Cấu hình Cloud NAT với static port allocation, viết Cloud Armor rule chặn brute-force login (rate limit theo IP).

Ngày 77: Load Balancing chuyên sâu & Hybrid Connectivity

• Mục tiêu: Chọn đúng loại LB, thiết kế hybrid connectivity cho enterprise.

• Lý thuyết: Internal LB vs External, Regional vs Global LB (Anycast), VPN (site-to-site, HA VPN) vs Dedicated/Partner Interconnect - tradeoff bandwidth/latency/cost.

• Thực hành: Dựng Internal HTTP(S) LB cho service nội bộ, vẽ sơ đồ hybrid connectivity giả định on-prem ↔ GCP cho 1 công ty 500 nhân sự.

Ngày 78: Private Service Connect & multi-VPC design

• Mục tiêu: Thiết kế network topology an toàn cho tổ chức nhiều team/project.

• Lý thuyết: PSC endpoint/service attachment, khi nào dùng PSC thay vì VPC Peering (tránh transitive peering limitation), Shared VPC ownership model.

• Thực hành: Publish 1 service qua PSC service attachment, consume từ project khác không cần VPC peering.

MODULE C - Database Reliability Engineering (Ngày 79–83)

Ngày 79: Connection management & query plan

• Mục tiêu: Tự chẩn đoán được query chậm và connection exhaustion.

• Lý thuyết: Connection pooling (PgBouncer transaction mode vs session mode), EXPLAIN ANALYZE đọc query plan, sequential scan vs index scan.

• Thực hành: Deploy PgBouncer trước AlloyDB, giả lập 200 connection đồng thời, so sánh có/không pooling; tối ưu 1 query chậm bằng EXPLAIN ANALYZE.

Ngày 80: Index strategy & vacuum

• Mục tiêu: Tránh bloat và table lock khi vận hành Postgres/AlloyDB lâu dài.

• Lý thuyết: B-tree vs GIN/GiST index, autovacuum tuning, hậu quả của vacuum bị trễ (table bloat, transaction ID wraparound).

• Thực hành: Tạo bảng lớn giả lập update liên tục, quan sát bloat qua pg_stat_user_tables, tune autovacuum threshold.

Ngày 81: Replication & read replica strategy

• Mục tiêu: Thiết kế đúng khi nào đọc từ replica, chấp nhận độ trễ nào.

• Lý thuyết: Streaming replication, replication lag nguyên nhân (long transaction, network, disk I/O), read-after-write consistency pattern.

• Thực hành: Tạo read replica cho Cloud SQL, giả lập lag bằng cách chạy transaction dài, đo lag qua pg_stat_replication.

Ngày 82: Spanner internals

• Mục tiêu: Hiểu vì sao Spanner strongly consistent toàn cầu và cách tránh hotspot.

• Lý thuyết: TrueTime (GPS + atomic clock để đồng bộ thời gian), Paxos-based leader election theo split, hotspot do primary key tuần tự (timestamp làm khoá).

• Thực hành: Thiết kế schema Spanner tránh hotspot (dùng UUID/hash prefix thay vì auto-increment), test insert throughput trước/sau khi đổi khoá.

Ngày 83: Backup strategy & restore drill

• Mục tiêu: Đảm bảo backup thực sự dùng được khi cần, không chỉ "có backup".

• Lý thuyết: Point-in-Time Recovery (PITR), snapshot lifecycle policy, sự khác biệt giữa backup có thể restore và backup chỉ "tồn tại".

• Thực hành: Tự tay restore 1 database từ backup sang instance mới, đo thời gian thực tế (RTO) và dữ liệu mất bao nhiêu (RPO).

MODULE D - Platform Engineering (Ngày 84–87)

Ngày 84: IDP concepts & Golden Path

• Mục tiêu: Hiểu triết lý platform engineering khác DevOps truyền thống thế nào.

• Lý thuyết: Internal Developer Platform giảm cognitive load cho dev, Golden Path = con đường mặc định "đủ tốt" thay vì để mỗi team tự quyết mọi thứ.

• Thực hành: Vẽ Golden Path cho 1 luồng "tạo service mới" trong tổ chức giả định (từ scaffold code → CI/CD → deploy → observability có sẵn).

Ngày 85: Backstage - software catalog & template

• Mục tiêu: Dựng được self-service portal thật cho developer.

• Lý thuyết: Backstage software catalog (đăng ký service, ownership), Scaffolder template để tạo service mới theo chuẩn.

• Thực hành: Cài Backstage local, đăng ký 1 service demo vào catalog, viết 1 Scaffolder template tạo repo + CI pipeline tự động.

Ngày 86: Self-service infra

• Mục tiêu: Cho phép dev tự cấp phát infra mà không cần platform team làm tay.

• Lý thuyết: Terraform module hoá theo "product" (database-as-a-service nội bộ), Crossplane cho phép định nghĩa infra như Kubernetes CRD.

• Thực hành: Viết 1 Terraform module chuẩn hoá "tạo Cloud SQL instance" với input tối thiểu, hoặc thử Crossplane composition tương tự.

Ngày 87: Developer Experience metrics

• Mục tiêu: Đo được platform có đang giúp ích thật hay không.

• Lý thuyết: DORA metrics mở rộng (deployment frequency, lead time, MTTR, change failure rate) + DX survey định tính.

• Thực hành: Tự đo 4 chỉ số DORA cho 1 project cá nhân trong 2 tuần gần nhất, thiết kế 1 dashboard theo dõi chúng.

MODULE E - Security Operations (Ngày 88–92)

Ngày 88: SIEM & Chronicle overview

• Mục tiêu: Hiểu luồng dữ liệu security từ log đến detection.

• Lý thuyết: SIEM tổng hợp log nhiều nguồn để correlate, Chronicle (Google SecOps) dùng UDM (Unified Data Model) để normalize log.

• Thực hành: Đẩy Cloud Audit Log vào Chronicle (hoặc BigQuery giả lập UDM), viết 1 detection rule đơn giản (nhiều lần login fail).

Ngày 89: Security Command Center nâng cao

• Mục tiêu: Dùng SCC để phát hiện misconfiguration và threat chủ động thay vì bị động.

• Lý thuyết: SCC Premium threat detection (Event Threat Detection, Container Threat Detection), Security Health Analytics finding severity.

• Thực hành: Bật SCC Premium trên project test, cố tình tạo 1 misconfig (bucket public) và xem finding xuất hiện thế nào, viết remediation.

Ngày 90: Incident Response cơ bản

• Mục tiêu: Có quy trình phản ứng khi nghi ngờ bị xâm nhập, không hoảng loạn xử lý ngẫu hứng.

• Lý thuyết: IOC (Indicator of Compromise), quy trình Identify → Contain → Eradicate → Recover → Lessons Learned.

• Thực hành: Viết 1 runbook IR cho kịch bản "service account key bị leak lên GitHub public", thực hành revoke + rotate.

Ngày 91: Threat hunting & forensics cơ bản

• Mục tiêu: Chủ động tìm dấu hiệu tấn công trong log thay vì chỉ chờ alert.

• Lý thuyết: Threat hunting hypothesis-driven, forensics cơ bản trên cloud (timeline reconstruction từ Cloud Audit Log).

• Thực hành: Từ 1 tập Cloud Audit Log giả lập, tự truy vết chuỗi hành động của 1 "kẻ tấn công" (privilege escalation qua IAM).

Ngày 92: Supply chain security sâu

• Mục tiêu: Đảm bảo artifact deploy production đúng là thứ đã được build/test, không bị chèn mã độc giữa chừng.

• Lý thuyết: SLSA level 1-4, Sigstore/Cosign ký và verify container image, SBOM (Software Bill of Materials) để biết dependency nào đang chạy.

• Thực hành: Ký 1 container image bằng Cosign, cấu hình Binary Authorization chỉ cho phép deploy image đã ký; generate SBOM bằng syft.

MODULE F - Distributed Systems (Ngày 93–97)

Ngày 93: CAP theorem thực chiến

• Mục tiêu: Áp CAP vào quyết định kiến trúc thật, không chỉ thuộc định nghĩa.

• Lý thuyết: CAP không phải "chọn 2 trong 3" tĩnh - mà là tradeoff động theo từng thời điểm network partition; PACELC mở rộng thêm tradeoff latency/consistency lúc bình thường.

• Thực hành: Phân loại 5 service thật bạn đang dùng (Spanner, Firestore, Redis, Kafka, Cloud Storage) theo CAP/PACELC và giải thích vì sao.

Ngày 94: Consensus - Raft

• Mục tiêu: Hiểu cơ chế bên trong etcd/Spanner vận hành để không sợ "hộp đen".

• Lý thuyết: Raft: leader election, log replication, term/commit index; split-brain được ngăn bằng majority quorum.

• Thực hành: Chạy Raft visualization (raft.github.io) từng bước, giả lập leader chết và quan sát election lại.

Ngày 95: Paxos vs Raft

• Mục tiêu: Biết khi nào hệ thống dùng Paxos (Spanner) khác Raft (etcd) ảnh hưởng gì đến vận hành.

• Lý thuyết: Paxos phức tạp hơn để hiểu nhưng cho phép nhiều biến thể tối ưu (Multi-Paxos), Raft ưu tiên dễ hiểu/implement.

• Thực hành: Đọc paper gốc Raft (phần Abstract + Design) và tóm tắt lại bằng 1 trang note của riêng bạn.

Ngày 96: Replication strategies

• Mục tiêu: Chọn đúng mô hình replication theo yêu cầu consistency/latency.

• Lý thuyết: Sync vs async replication, quorum-based (W+R>N), vấn đề split-brain khi network partition.

• Thực hành: Cấu hình 1 Postgres synchronous replication, đo latency write tăng lên bao nhiêu so với async.

Ngày 97: Sharding & partitioning

• Mục tiêu: Thiết kế schema chịu được scale ngang mà không tạo hotspot.

• Lý thuyết: Hash-based vs range-based sharding, rebalancing khi thêm shard, hotspot mitigation (salting key).

• Thực hành: Thiết kế sharding key cho 1 bảng "orders" giả lập 10 triệu bản ghi/ngày, giải thích cách tránh hotspot theo thời gian (timestamp).

MODULE G - AI/LLMOps trên GCP (Ngày 98–102)

Ngày 98: Vertex AI Model Registry & lifecycle

• Mục tiêu: Quản lý vòng đời model như quản lý artifact CI/CD, không phải file rời rạc.

• Lý thuyết: Model versioning, staging → production alias, model lineage (biết model train từ dataset/code nào).

• Thực hành: Đăng ký 1 model đơn giản vào Vertex AI Model Registry, gắn version và promote lên "production" alias.

Ngày 99: Feature Store

• Mục tiêu: Tránh training-serving skew - lỗi phổ biến nhất trong ML production.

• Lý thuyết: Feature Store lưu feature dùng chung cho training và serving, online vs offline store.

• Thực hành: Định nghĩa 1 feature (vd: "số đơn hàng 7 ngày gần nhất") trong Vertex AI Feature Store, dùng lại cho cả batch training và real-time serving.

Ngày 100: Model evaluation & monitoring

• Mục tiêu: Phát hiện model xuống cấp (drift) trước khi ảnh hưởng business.

• Lý thuyết: Data drift vs concept drift, evaluation metric theo bài toán (precision/recall cho classification, RMSE cho regression), continuous evaluation.

• Thực hành: Bật Vertex AI Model Monitoring cho 1 endpoint, giả lập input distribution thay đổi và xem alert drift.

Ngày 101: RAG & Vector Database

• Mục tiêu: Dựng được hệ thống RAG production-grade, không chỉ demo notebook.

• Lý thuyết: Kiến trúc RAG (retrieve → augment → generate), Vertex AI Vector Search (ANN search), chunking strategy ảnh hưởng chất lượng retrieval.

• Thực hành: Dựng RAG pipeline đơn giản: embed 1 tập tài liệu, lưu vào Vertex AI Vector Search, query và feed context vào Gemini.

Ngày 102: LLMOps - prompt, guardrail, cost

• Mục tiêu: Vận hành LLM trong production như vận hành 1 service bình thường: versioned, monitored, cost-controlled.

• Lý thuyết: Prompt versioning (coi prompt như code), guardrail (input/output filtering, jailbreak detection), cost monitoring theo token usage.

• Thực hành: Viết 1 prompt template có version, thêm guardrail chặn output chứa PII, dựng dashboard theo dõi chi phí token theo ngày.