# Syllabus GCP DevOps

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