# Syllabus học automation (3)

# PHASE 8 - Platform Engineering (Ngày 226–265)

## TUẦN 46 - DOCKER FUNDAMENTALS

**Ngày 226: Image & Container**

*   Mục tiêu: Hiểu khác biệt giữa image (bản thiết kế) và container (bản chạy).
    
*   Lý thuyết: Layer trong Docker image, image cache.
    
*   Thực hành: Build image cho API Task (Phase 2), chạy container, vào shell container để kiểm tra.
    

**Ngày 227: Dockerfile Best Practice**

*   Mục tiêu: Viết Dockerfile nhỏ gọn, build nhanh.
    
*   Lý thuyết: Order layer theo tần suất thay đổi, `.dockerignore`.
    
*   Thực hành: Tối ưu lại Dockerfile Ngày 226, đo dung lượng và thời gian build trước/sau.
    

**Ngày 228: Multi-stage Build**

*   Mục tiêu: Giảm dung lượng image production.
    
*   Lý thuyết: Build stage vs runtime stage.
    
*   Thực hành: Chuyển Dockerfile sang multi-stage cho ứng dụng TypeScript (build ở stage 1, chạy JS đã compile ở stage 2).
    

**Ngày 229: Docker Networking**

*   Mục tiêu: Cho nhiều container giao tiếp với nhau đúng cách.
    
*   Lý thuyết: Bridge network, DNS nội bộ giữa container.
    
*   Thực hành: Chạy API Task + Postgres trong 2 container riêng, kết nối qua network tên miền nội bộ.
    

**Ngày 230: Volume & Persistence**

*   Mục tiêu: Không mất dữ liệu khi container bị xóa.
    
*   Lý thuyết: Named volume vs bind mount.
    
*   Thực hành: Cấu hình volume cho Postgres container, xóa container và tạo lại, xác nhận dữ liệu còn nguyên.
    

## TUẦN 47 - DOCKER PRODUCTION

**Ngày 231: Docker Compose**

*   Mục tiêu: Quản lý nhiều service liên quan bằng 1 file khai báo.
    
*   Lý thuyết: `docker-compose.yml` structure, service dependency (`depends_on`).
    
*   Thực hành: Viết Compose file chạy toàn bộ stack: API Task + Postgres + Redis + RabbitMQ.
    

**Ngày 232: Environment & Secret trong Docker**

*   Mục tiêu: Không hard-code thông tin nhạy cảm vào image.
    
*   Lý thuyết: `.env` file, build-time vs runtime variable.
    
*   Thực hành: Tách toàn bộ config (DB password, API key) ra `.env`, verify image không chứa secret bằng `docker history`.
    

**Ngày 233: Health Check**

*   Mục tiêu: Biết container có thực sự "sống" hay chỉ đang chạy nhưng lỗi.
    
*   Lý thuyết: `HEALTHCHECK` instruction, liveness vs readiness (chuẩn bị cho Kubernetes).
    
*   Thực hành: Thêm healthcheck cho API Task container, giả lập lỗi để container báo unhealthy.
    

**Ngày 234: Image Security Scanning**

*   Mục tiêu: Phát hiện lỗ hổng bảo mật trong image trước khi deploy.
    
*   Lý thuyết: Vulnerability scanning (Trivy), base image tối giản (distroless/alpine).
    
*   Thực hành: Chạy Trivy scan image API Task, sửa base image để giảm số lỗ hổng.
    

**Ngày 235: Container Registry**

*   Mục tiêu: Lưu trữ và phân phối image cho team/CI.
    
*   Lý thuyết: Docker Hub, GitHub Container Registry (GHCR), tagging strategy.
    
*   Thực hành: Push image API Task lên GHCR, cấu hình tag theo git commit SHA.
    

## TUẦN 48 - KUBERNETES BASICS

**Ngày 236: Pod & Deployment**

*   Mục tiêu: Chạy container trên Kubernetes theo đúng mô hình quản lý.
    
*   Lý thuyết: Pod là gì, Deployment quản lý ReplicaSet ra sao.
    
*   Thực hành: Cài Minikube/kind, viết Deployment YAML chạy API Task, apply và kiểm tra pod.
    

**Ngày 237: Service**

*   Mục tiêu: Truy cập được vào pod dù pod bị thay thế liên tục.
    
*   Lý thuyết: ClusterIP, NodePort, LoadBalancer.
    
*   Thực hành: Tạo Service cho Deployment Ngày 236, test gọi API từ trong cluster.
    

**Ngày 238: Rolling Update**

*   Mục tiêu: Deploy phiên bản mới mà không downtime.
    
*   Lý thuyết: Rolling update strategy, `maxSurge`/`maxUnavailable`.
    
*   Thực hành: Đổi image tag sang version mới, quan sát Kubernetes tự động rolling update từng pod.
    

**Ngày 239: Kubectl Debugging**

*   Mục tiêu: Tự tìm ra nguyên nhân khi pod không chạy được.
    
*   Lý thuyết: `kubectl describe`, `kubectl logs`, `kubectl exec`.
    
*   Thực hành: Cố tình gây lỗi (sai image tag, thiếu env), dùng kubectl để tìm và sửa lỗi.
    

**Ngày 240: Practice - Deploy Full Stack cơ bản**

*   Mục tiêu: Deploy nhiều service liên quan lên Kubernetes.
    
*   Lý thuyết: Ôn tập Deployment/Service.
    
*   Thực hành: Deploy API Task + Postgres (dùng tạm PVC đơn giản) lên Minikube, xác nhận API hoạt động qua Service.
    

## TUẦN 49 - KUBERNETES INTERMEDIATE

**Ngày 241: StatefulSet**

*   Mục tiêu: Chạy đúng cách các service có trạng thái (như DB).
    
*   Lý thuyết: StatefulSet vs Deployment, stable network identity, ordered deployment.
    
*   Thực hành: Chuyển Postgres từ Deployment sang StatefulSet, quan sát tên pod cố định (`postgres-0`).
    

**Ngày 242: PersistentVolume & PersistentVolumeClaim**

*   Mục tiêu: Hiểu cách Kubernetes quản lý lưu trữ bền vững.
    
*   Lý thuyết: PV, PVC, StorageClass.
    
*   Thực hành: Viết PVC cho StatefulSet Postgres Ngày 241, xác nhận dữ liệu còn khi pod restart.
    

**Ngày 243: Ingress**

*   Mục tiêu: Expose nhiều service ra ngoài qua 1 điểm vào duy nhất.
    
*   Lý thuyết: Ingress Controller (nginx), Ingress rule theo host/path.
    
*   Thực hành: Cài Ingress Controller, cấu hình route `api.local/tasks` trỏ tới Service API Task.
    

**Ngày 244: ConfigMap & Secret**

*   Mục tiêu: Tách cấu hình khỏi image, quản lý secret an toàn hơn Docker Compose.
    
*   Lý thuyết: ConfigMap cho config thường, Secret cho dữ liệu nhạy cảm (base64, chưa mã hóa thật).
    
*   Thực hành: Chuyển toàn bộ `.env` của API Task sang ConfigMap + Secret, mount vào pod.
    

**Ngày 245: Practice - Kubernetes Intermediate**

*   Mục tiêu: Củng cố kỹ năng qua bài tổng hợp.
    
*   Lý thuyết: Ôn tập StatefulSet, PVC, Ingress, ConfigMap/Secret.
    
*   Thực hành: Deploy lại toàn bộ stack Ngày 240 nhưng dùng đầy đủ StatefulSet + PVC + Ingress + Secret.
    

## TUẦN 50 - KUBERNETES ADVANCED

**Ngày 246: Resource Requests & Limits**

*   Mục tiêu: Tránh 1 pod chiếm hết tài nguyên node.
    
*   Lý thuyết: `requests` vs `limits` (CPU/Memory), OOMKilled.
    
*   Thực hành: Đặt resource limit thấp cố ý cho API Task, quan sát pod bị OOMKilled, sửa lại đúng mức.
    

**Ngày 247: Horizontal Pod Autoscaler (HPA)**

*   Mục tiêu: Tự động scale pod theo tải.
    
*   Lý thuyết: HPA dựa trên CPU/metric custom, Metrics Server.
    
*   Thực hành: Cấu hình HPA cho API Task, tạo tải giả (load test) để quan sát pod tự động tăng.
    

**Ngày 248: Liveness & Readiness Probe**

*   Mục tiêu: Kubernetes tự phát hiện và xử lý pod bị treo.
    
*   Lý thuyết: Liveness probe (restart nếu fail) vs Readiness probe (ngừng route traffic nếu fail).
    
*   Thực hành: Thêm cả 2 probe cho API Task, giả lập pod bị treo để quan sát Kubernetes tự restart.
    

**Ngày 249: Troubleshooting nâng cao**

*   Mục tiêu: Debug các lỗi phức tạp hơn (network, DNS trong cluster).
    
*   Lý thuyết: `kubectl exec` vào pod để test DNS/network nội bộ, CrashLoopBackOff nguyên nhân phổ biến.
    
*   Thực hành: Giả lập 1 pod không kết nối được DB do sai Service name, debug từng bước tới khi tìm ra nguyên nhân.
    

**Ngày 250: Practice - Production Readiness Review**

*   Mục tiêu: Tự đánh giá 1 deployment Kubernetes có sẵn sàng production chưa.
    
*   Lý thuyết: Checklist: probe, resource limit, HPA, secret management.
    
*   Thực hành: Viết checklist review cho stack đã deploy, đánh dấu phần còn thiếu.
    

## TUẦN 51 - TERRAFORM

**Ngày 251: Terraform Fundamentals**

*   Mục tiêu: Định nghĩa hạ tầng bằng code thay vì click tay.
    
*   Lý thuyết: Provider, Resource, `terraform plan`/`apply`.
    
*   Thực hành: Viết Terraform tạo thử 1 resource đơn giản (ví dụ 1 Docker container hoặc 1 file local) để làm quen cú pháp.
    

**Ngày 252: State Management**

*   Mục tiêu: Hiểu vì sao Terraform cần "nhớ" trạng thái hạ tầng.
    
*   Lý thuyết: `terraform.tfstate`, remote state (S3/Terraform Cloud), state locking.
    
*   Thực hành: Cấu hình remote state, thử 2 người (giả lập) apply cùng lúc để thấy tác dụng của state lock.
    

**Ngày 253: Variables & Outputs**

*   Mục tiêu: Viết Terraform module tái sử dụng được.
    
*   Lý thuyết: `variable`, `output`, `.tfvars`.
    
*   Thực hành: Tham số hóa cấu hình đã viết (region, instance size) qua variable.
    

**Ngày 254: Modules**

*   Mục tiêu: Đóng gói hạ tầng lặp lại thành module dùng chung.
    
*   Lý thuyết: Module structure, module registry.
    
*   Thực hành: Tách phần tạo network/VPC thành 1 module riêng, gọi lại từ 2 môi trường (staging/production).
    

**Ngày 255: Practice - IaC Project**

*   Mục tiêu: Dựng hạ tầng cho Kubernetes cluster bằng Terraform.
    
*   Lý thuyết: Provider cho cloud (AWS/GCP) hoặc local (kind) tùy điều kiện thực hành.
    
*   Thực hành: Viết Terraform tạo 1 Kubernetes cluster (managed hoặc local), verify bằng `kubectl get nodes`.
    

## TUẦN 52 - VAULT & EXTERNAL SECRETS

**Ngày 256: Vault Fundamentals**

*   Mục tiêu: Quản lý secret tập trung, có audit, thay vì rải rác trong K8s Secret/`.env`.
    
*   Lý thuyết: Secret Engine, Vault Server, unseal/seal.
    
*   Thực hành: Cài Vault (dev mode), lưu thử 1 secret (DB password) và đọc lại bằng CLI.
    

**Ngày 257: Dynamic Secrets**

*   Mục tiêu: Giảm rủi ro khi secret bị lộ (secret có thời hạn ngắn).
    
*   Lý thuyết: Dynamic Secret Engine cho DB (Vault tự tạo user DB tạm thời).
    
*   Thực hành: Cấu hình Vault Database Secret Engine cho Postgres, lấy 1 credential tạm thời và test kết nối.
    

**Ngày 258: Vault Policy**

*   Mục tiêu: Giới hạn ai/service nào được đọc secret nào.
    
*   Lý thuyết: Policy syntax (HCL), path-based access control.
    
*   Thực hành: Viết policy chỉ cho phép service API Task đọc secret DB, không đọc được secret khác.
    

**Ngày 259: External Secrets Operator**

*   Mục tiêu: Đồng bộ secret từ Vault vào Kubernetes tự động.
    
*   Lý thuyết: External Secrets Operator (ESO) kiến trúc, SecretStore/ExternalSecret CRD.
    
*   Thực hành: Cài ESO, cấu hình đồng bộ secret DB từ Vault vào K8s Secret tự động.
    

**Ngày 260: Practice - Secret Management End-to-End**

*   Mục tiêu: Đảm bảo không secret nào còn hard-code trong toàn bộ hệ thống.
    
*   Lý thuyết: Ôn tập Vault + ESO.
    
*   Thực hành: Audit lại toàn bộ Deployment đã có, thay hết Secret thủ công bằng ExternalSecret trỏ tới Vault.
    

## TUẦN 53 - GITOPS & CAPSTONE

**Ngày 261: GitOps Fundamentals**

*   Mục tiêu: Hiểu triết lý "Git là nguồn sự thật duy nhất" cho hạ tầng.
    
*   Lý thuyết: GitOps vs CI/CD truyền thống, pull-based deployment.
    
*   Thực hành: Cài ArgoCD, kết nối tới 1 Git repo chứa YAML Deployment API Task.
    

**Ngày 262: Sync Policy**

*   Mục tiêu: Kiểm soát cách ArgoCD đồng bộ trạng thái cluster theo Git.
    
*   Lý thuyết: Manual vs Automated sync, self-heal, prune.
    
*   Thực hành: Bật Automated Sync, thử sửa trực tiếp trên cluster (kubectl edit) để quan sát ArgoCD tự động sync lại theo Git.
    

**Ngày 263: App of Apps Pattern**

*   Mục tiêu: Quản lý nhiều app/service bằng 1 cấu trúc Git thống nhất.
    
*   Lý thuyết: App of Apps, ApplicationSet.
    
*   Thực hành: Tổ chức lại repo GitOps quản lý cả API Task, n8n, RabbitMQ theo pattern App of Apps.
    

**Ngày 264: Rollback**

*   Mục tiêu: Quay lại phiên bản ổn định nhanh khi deploy lỗi.
    
*   Lý thuyết: ArgoCD history & rollback, liên hệ với Git revert.
    
*   Thực hành: Giả lập 1 lần deploy lỗi (sai image tag), thực hiện rollback qua ArgoCD UI/CLI.
    

**Ngày 265: Capstone Phase 8**

*   Mục tiêu: Tổng kết toàn bộ Platform Engineering.
    
*   Lý thuyết: Ôn tập Docker, Kubernetes, Terraform, Vault, GitOps.
    
*   Thực hành: Demo toàn bộ stack (API Task, Postgres, Redis, RabbitMQ, n8n) chạy trên Kubernetes, hạ tầng tạo bằng Terraform, secret quản lý qua Vault, deploy qua ArgoCD GitOps.
    

# PHASE 9 - Reliability Engineering (Ngày 266–285)

## TUẦN 54 - RETRY & BACKOFF

**Ngày 266: Retry Pattern**

*   Mục tiêu: Xử lý lỗi tạm thời (transient error) mà không cần can thiệp thủ công.
    
*   Lý thuyết: Transient vs permanent error, khi nào nên/không nên retry.
    
*   Thực hành: Viết wrapper retry đơn giản cho hàm gọi API Task, giả lập lỗi 2 lần đầu rồi thành công ở lần 3.
    

**Ngày 267: Exponential Backoff**

*   Mục tiêu: Tránh "dội bom" hệ thống đang gặp sự cố bằng cách retry dồn dập.
    
*   Lý thuyết: Exponential backoff formula, max retry, max delay.
    
*   Thực hành: Nâng cấp wrapper Ngày 266 dùng exponential backoff (1s → 2s → 4s...).
    

**Ngày 268: Jitter**

*   Mục tiêu: Tránh nhiều client cùng retry tại đúng 1 thời điểm (thundering herd).
    
*   Lý thuyết: Full jitter, equal jitter.
    
*   Thực hành: Thêm jitter ngẫu nhiên vào backoff, viết test mô phỏng 100 client retry cùng lúc để so sánh có/không jitter.
    

**Ngày 269: Retry ở các tầng đã học**

*   Mục tiêu: Nhận diện retry đã áp dụng ở đâu trong hệ thống từ đầu khóa tới giờ.
    
*   Lý thuyết: Ôn lại retry trong Webhook (Phase 2), n8n Error Workflow (Phase 4), RabbitMQ DLQ (Phase 7).
    
*   Thực hành: Viết bảng liệt kê toàn bộ điểm có retry trong hệ thống đã xây, đánh giá điểm nào còn thiếu.
    

**Ngày 270: Practice - Retry Library**

*   Mục tiêu: Có 1 thư viện retry dùng chung cho mọi automation script.
    
*   Lý thuyết: Ôn tập backoff + jitter.
    
*   Thực hành: Đóng gói logic retry thành 1 npm module nội bộ `@internal/retry`, viết unit test.
    

## TUẦN 55 - CIRCUIT BREAKER & RATE LIMIT

**Ngày 271: Circuit Breaker Pattern**

*   Mục tiêu: Ngừng gọi 1 service đang "chết" thay vì tiếp tục retry vô ích.
    
*   Lý thuyết: Closed/Open/Half-Open state, threshold.
    
*   Thực hành: Implement circuit breaker đơn giản quanh 1 API call, giả lập service down liên tục để quan sát state chuyển Open.
    

**Ngày 272: Circuit Breaker Recovery**

*   Mục tiêu: Tự động thử lại dịch vụ đã "chết" mà không gây quá tải.
    
*   Lý thuyết: Half-Open state, cách xác định service đã hồi phục.
    
*   Thực hành: Cho service "hồi phục" lại, quan sát circuit breaker chuyển Half-Open rồi Closed đúng logic.
    

**Ngày 273: Rate Limiting Algorithm**

*   Mục tiêu: Hiểu sâu hơn các thuật toán rate limit (ôn lại Ngày 198 ở tầng khái niệm).
    
*   Lý thuyết: Token bucket vs Leaky bucket, so sánh burst handling.
    
*   Thực hành: Implement thử Token Bucket bằng code (không dùng Redis) để hiểu rõ cơ chế nạp/tiêu token.
    

**Ngày 274: Client-side Rate Limiting**

*   Mục tiêu: Tự giới hạn tốc độ gọi ra ngoài để không bị SaaS chặn (quan trọng khi tích hợp nhiều API ở Phase 2).
    
*   Lý thuyết: Respect `Retry-After` header, quota theo third-party API.
    
*   Thực hành: Thêm client-side rate limiter cho module gọi GitHub API (Phase 2), tôn trọng header rate limit trả về.
    

**Ngày 275: Practice - Resilience Wrapper**

*   Mục tiêu: Kết hợp retry + circuit breaker + rate limit thành 1 lớp bảo vệ chuẩn.
    
*   Lý thuyết: Ôn tập toàn bộ tuần.
    
*   Thực hành: Xây 1 module `resilientFetch()` gộp cả 3 kỹ thuật, áp dụng cho toàn bộ HTTP call trong hệ thống.
    

## TUẦN 56 - IDEMPOTENCY, DLQ & DISTRIBUTED LOCK

**Ngày 276: Idempotency**

*   Mục tiêu: Xử lý an toàn khi 1 request/message bị gửi trùng (do retry).
    
*   Lý thuyết: Idempotency key, idempotent operation design.
    
*   Thực hành: Thêm `Idempotency-Key` header cho API tạo Task, đảm bảo gửi trùng request không tạo trùng dữ liệu.
    

**Ngày 277: Idempotency ở tầng Message**

*   Mục tiêu: Áp dụng idempotency cho consumer Kafka/RabbitMQ (Phase 7).
    
*   Lý thuyết: Deduplication bằng message ID + bảng "processed\_messages".
    
*   Thực hành: Thêm bảng `processed_messages` (Postgres), consumer kiểm tra trước khi xử lý để tránh xử lý trùng.
    

**Ngày 278: Dead Letter Queue - Vận hành**

*   Mục tiêu: Có quy trình xử lý message trong DLQ thay vì để đó mãi.
    
*   Lý thuyết: DLQ reprocessing strategy, alerting khi DLQ có message mới.
    
*   Thực hành: Viết script/n8n workflow định kỳ kiểm tra DLQ (Phase 7), gửi cảnh báo nếu có message tồn đọng.
    

**Ngày 279: Distributed Lock**

*   Mục tiêu: Đảm bảo chỉ 1 instance xử lý 1 tác vụ khi có nhiều worker chạy song song.
    
*   Lý thuyết: Redlock (Redis-based lock), lock timeout, tránh deadlock.
    
*   Thực hành: Implement distributed lock bằng Redis cho job "đồng bộ dữ liệu" (Phase 4), test chạy 2 worker cùng lúc.
    

**Ngày 280: Practice - Reliability Audit**

*   Mục tiêu: Tự đánh giá độ tin cậy của 1 hệ thống có sẵn.
    
*   Lý thuyết: Ôn tập idempotency, DLQ, distributed lock.
    
*   Thực hành: Audit lại pipeline Task → Kafka → Redis/RabbitMQ (Phase 7), bổ sung idempotency và lock còn thiếu.
    

## TUẦN 57 - SRE PRACTICES

**Ngày 281: On-call Basics**

*   Mục tiêu: Hiểu quy trình vận hành khi có sự cố xảy ra ngoài giờ.
    
*   Lý thuyết: On-call rotation, escalation policy, severity level.
    
*   Thực hành: Viết 1 tài liệu On-call Runbook mẫu cho hệ thống API Task (các bước xử lý khi API down).
    

**Ngày 282: Postmortem**

*   Mục tiêu: Học được gì sau mỗi sự cố thay vì chỉ "chữa cháy".
    
*   Lý thuyết: Blameless postmortem, cấu trúc: timeline, root cause, action item.
    
*   Thực hành: Viết 1 postmortem giả lập cho sự cố "API Task down 30 phút do hết connection pool".
    

**Ngày 283: SLO/SLA/Error Budget**

*   Mục tiêu: Định lượng được "đủ tốt" nghĩa là gì cho một hệ thống.
    
*   Lý thuyết: SLI, SLO, SLA khác nhau thế nào, error budget dùng để ra quyết định release.
    
*   Thực hành: Định nghĩa SLO cho API Task (ví dụ 99.5% request < 500ms), tính thử error budget theo tháng.
    

**Ngày 284: Alerting Strategy**

*   Mục tiêu: Alert đúng người, đúng lúc, không gây "alert fatigue".
    
*   Lý thuyết: Alert theo symptom (user-facing) thay vì cause, alert threshold hợp lý.
    
*   Thực hành: Thiết kế 3 alert rule cho API Task (error rate, latency, DLQ tồn đọng) kèm mức độ nghiêm trọng.
    

**Ngày 285: Capstone Phase 9**

*   Mục tiêu: Tổng kết toàn bộ Reliability Engineering.
    
*   Lý thuyết: Ôn tập retry, circuit breaker, idempotency, SRE practice.
    
*   Thực hành: Viết "Reliability Playbook" hoàn chỉnh cho hệ thống đã xây xuyên suốt khóa học: resilience wrapper, idempotency, DLQ handling, on-call runbook, SLO.
    

# PHASE 10 - Observability (Ngày 286–305)

## TUẦN 58 - LOGGING

**Ngày 286: Structured Logging**

*   Mục tiêu: Log có thể tìm kiếm/lọc được thay vì chỉ là text.
    
*   Lý thuyết: Structured log (JSON), log level (debug/info/warn/error), correlation ID.
    
*   Thực hành: Thêm structured logging (`pino`/`winston`) cho API Task, gắn correlation ID xuyên suốt 1 request.
    

**Ngày 287: ELK Stack Overview**

*   Mục tiêu: Hiểu kiến trúc thu thập-lưu trữ-tìm kiếm log phổ biến.
    
*   Lý thuyết: Elasticsearch (lưu trữ/tìm kiếm), Logstash/Filebeat (thu thập), Kibana (hiển thị).
    
*   Thực hành: Cài ELK stack bằng Docker Compose, đẩy log của API Task vào Elasticsearch qua Filebeat.
    

**Ngày 288: Truy vấn & Dashboard trong Kibana**

*   Mục tiêu: Tìm nhanh log liên quan tới 1 sự cố cụ thể.
    
*   Lý thuyết: Kibana Query Language (KQL), tạo dashboard đơn giản.
    
*   Thực hành: Tạo dashboard hiển thị số lượng lỗi theo giờ, tìm log của 1 request cụ thể bằng correlation ID.
    

**Ngày 289: Loki**

*   Mục tiêu: Biết một lựa chọn logging nhẹ hơn ELK, hợp với Kubernetes.
    
*   Lý thuyết: Loki + Promtail kiến trúc, khác biệt so với Elasticsearch (index label thay vì full-text).
    
*   Thực hành: Cài Loki + Promtail cho stack Kubernetes (Phase 8), xem log qua Grafana.
    

**Ngày 290: So sánh ELK vs Loki**

*   Mục tiêu: Chọn đúng công cụ logging theo quy mô hệ thống.
    
*   Lý thuyết: Bảng so sánh chi phí vận hành, khả năng full-text search, tích hợp Kubernetes.
    
*   Thực hành: Viết bảng so sánh ELK vs Loki dựa trên trải nghiệm thực tế 3 ngày qua.
    

## TUẦN 59 - METRICS (PROMETHEUS)

**Ngày 291: Prometheus Fundamentals**

*   Mục tiêu: Hiểu mô hình pull-based metrics của Prometheus.
    
*   Lý thuyết: Time series data, scrape interval, `/metrics` endpoint.
    
*   Thực hành: Cài Prometheus, cấu hình scrape target trỏ tới 1 exporter mẫu (node\_exporter).
    

**Ngày 292: Instrumenting Ứng dụng**

*   Mục tiêu: Tự expose metric từ chính API Task.
    
*   Lý thuyết: Client library (`prom-client` cho Node.js), Counter/Gauge/Histogram.
    
*   Thực hành: Thêm `prom-client` vào API Task, expose metric số request, latency histogram tại `/metrics`.
    

**Ngày 293: PromQL cơ bản**

*   Mục tiêu: Truy vấn được xu hướng dữ liệu, không chỉ số hiện tại.
    
*   Lý thuyết: `rate()`, `sum by()`, `histogram_quantile()`.
    
*   Thực hành: Viết PromQL tính p95 latency của API Task trong 5 phút gần nhất.
    

**Ngày 294: Exporter cho hệ thống đã xây**

*   Mục tiêu: Có metric cho toàn bộ hạ tầng, không chỉ app.
    
*   Lý thuyết: postgres\_exporter, redis\_exporter, rabbitmq exporter có sẵn.
    
*   Thực hành: Thêm exporter cho Postgres + Redis (Phase 1, 7), scrape vào Prometheus chung.
    

**Ngày 295: Practice - Metrics Coverage Review**

*   Mục tiêu: Đảm bảo mọi thành phần quan trọng đều có metric.
    
*   Lý thuyết: Ôn tập RED method (Rate, Error, Duration) và USE method (Utilization, Saturation, Errors).
    
*   Thực hành: Audit hệ thống đã xây, liệt kê metric còn thiếu theo RED/USE method.
    

## TUẦN 60 - GRAFANA & ALERTING

**Ngày 296: Grafana Data Source**

*   Mục tiêu: Kết nối Grafana với mọi nguồn dữ liệu đã có.
    
*   Lý thuyết: Data source config (Prometheus, Loki), variable trong dashboard.
    
*   Thực hành: Kết nối Grafana với Prometheus + Loki, tạo dashboard đầu tiên hiển thị request rate.
    

**Ngày 297: Panel Design**

*   Mục tiêu: Xây dashboard dễ đọc, đúng trọng tâm (không "vẽ cho đẹp").
    
*   Lý thuyết: Chọn loại panel phù hợp (time series, stat, gauge), nguyên tắc "1 dashboard = 1 câu hỏi cần trả lời".
    
*   Thực hành: Xây dashboard "API Task Health" gồm: request rate, error rate, p95 latency, DLQ length.
    

**Ngày 298: Alerting Rules trong Grafana**

*   Mục tiêu: Biến metric thành cảnh báo hành động được.
    
*   Lý thuyết: Alert rule, threshold, evaluation interval.
    
*   Thực hành: Tạo alert khi error rate > 5% trong 5 phút, test bằng cách giả lập lỗi.
    

**Ngày 299: Tích hợp PagerDuty/Opsgenie**

*   Mục tiêu: Alert tới đúng người on-call (liên kết với Phase 9).
    
*   Lý thuyết: Notification channel trong Grafana, routing theo severity.
    
*   Thực hành: Cấu hình alert Ngày 298 gửi qua Slack/webhook mô phỏng PagerDuty, gắn với on-call runbook đã viết ở Phase 9.
    

**Ngày 300: Practice - Dashboard cho toàn hệ thống**

*   Mục tiêu: Có cái nhìn tổng quan sức khỏe toàn platform trên 1 màn hình.
    
*   Lý thuyết: Ôn tập panel design.
    
*   Thực hành: Xây dashboard tổng hợp: API Task, n8n, RabbitMQ, Kafka consumer lag, Kubernetes pod status.
    

## TUẦN 61 - TRACING (OPENTELEMETRY)

**Ngày 301: Distributed Tracing Fundamentals**

*   Mục tiêu: Theo dõi 1 request đi qua nhiều service khác nhau.
    
*   Lý thuyết: Trace, Span, Span context propagation.
    
*   Thực hành: Vẽ sơ đồ 1 request thực tế (Task created → Kafka → n8n → Slack) và đánh dấu các span sẽ có.
    

**Ngày 302: Cài đặt OpenTelemetry**

*   Mục tiêu: Có trace thật cho hệ thống đã xây.
    
*   Lý thuyết: OpenTelemetry SDK, exporter (OTLP), Collector.
    
*   Thực hành: Thêm OpenTelemetry SDK vào API Task, xuất trace tới Jaeger/Tempo chạy local.
    

**Ngày 303: Instrument Service Phụ**

*   Mục tiêu: Có trace xuyên suốt nhiều service, không chỉ 1 service.
    
*   Lý thuyết: Context propagation qua HTTP header (`traceparent`), qua message queue.
    
*   Thực hành: Thêm tracing cho worker Kafka consumer (Phase 7), đảm bảo trace ID được truyền từ producer sang consumer.
    

**Ngày 304: Trace Analysis**

*   Mục tiêu: Dùng trace để tìm bottleneck thực sự trong hệ thống.
    
*   Lý thuyết: Đọc waterfall view của trace, xác định span nào chiếm nhiều thời gian nhất.
    
*   Thực hành: Phân tích 1 trace của request chậm, xác định service/bước nào là nguyên nhân.
    

**Ngày 305: Capstone Phase 10**

*   Mục tiêu: Tổng hợp toàn bộ Observability thành 1 stack hoàn chỉnh.
    
*   Lý thuyết: Ôn tập Logging, Metrics, Tracing (3 trụ cột Observability).
    
*   Thực hành: Demo full observability stack cho hệ thống automation đã xây: log tập trung (Loki), metrics + alert (Prometheus/Grafana), tracing (OpenTelemetry), tất cả liên kết qua correlation/trace ID.
    

# PHASE 11 - AI Automation (Ngày 306–335)

## TUẦN 62 - MCP (MODEL CONTEXT PROTOCOL)

**Ngày 306: MCP Fundamentals**

*   Mục tiêu: Hiểu vì sao cần 1 protocol chuẩn để AI model gọi tool bên ngoài.
    
*   Lý thuyết: MCP Server/Client, Tool, Resource trong MCP.
    
*   Thực hành: Đọc tài liệu MCP chính thức, vẽ sơ đồ luồng: Client (Claude) → MCP Server → hệ thống thật (ví dụ API Task).
    

**Ngày 307: Xây MCP Server cơ bản**

*   Mục tiêu: Expose 1 chức năng thật thành tool cho AI dùng được.
    
*   Lý thuyết: Định nghĩa Tool (schema input/output), MCP SDK.
    
*   Thực hành: Viết 1 MCP Server đơn giản expose tool "tạo Task mới" (gọi lại API Task ở Phase 2).
    

**Ngày 308: Kết nối MCP Server với Client**

*   Mục tiêu: Xác nhận AI thực sự gọi được tool đã xây.
    
*   Lý thuyết: Cấu hình MCP Server trong client (Claude Desktop/Code), authentication cho MCP.
    
*   Thực hành: Kết nối MCP Server Ngày 307 vào Claude Desktop, thử yêu cầu AI "tạo 1 task mới" bằng ngôn ngữ tự nhiên.
    

**Ngày 309: MCP Resource**

*   Mục tiêu: Cho AI đọc được dữ liệu ngữ cảnh, không chỉ gọi action.
    
*   Lý thuyết: Resource trong MCP (đọc dữ liệu tĩnh/động).
    
*   Thực hành: Thêm 1 Resource expose danh sách Task hiện có để AI đọc trước khi quyết định hành động.
    

**Ngày 310: Practice - MCP Server hoàn chỉnh**

*   Mục tiêu: Có 1 MCP Server production-ready cho hệ thống Task.
    
*   Lý thuyết: Ôn tập Tool + Resource, error handling trong MCP.
    
*   Thực hành: Hoàn thiện MCP Server với 3-4 tool (tạo/sửa/xóa/tìm Task) có validate input đầy đủ.
    

## TUẦN 63 - FLOWISE

**Ngày 311: Flowise Setup**

*   Mục tiêu: Làm quen công cụ xây AI workflow kéo-thả.
    
*   Lý thuyết: Kiến trúc Flowise (dựa trên LangChain), node types cơ bản (LLM, Prompt, Chain).
    
*   Thực hành: Cài Flowise (Docker), dựng 1 chatflow đơn giản: nhận câu hỏi → gọi LLM → trả lời.
    

**Ngày 312: Xây Chatflow có Tool**

*   Mục tiêu: Cho AI gọi được hành động thật, không chỉ trả lời text.
    
*   Lý thuyết: Tool/Function node trong Flowise, Agent node.
    
*   Thực hành: Thêm Tool gọi API Task vào chatflow, thử hỏi "tạo giúp tôi 1 task tên X" bằng ngôn ngữ tự nhiên.
    

**Ngày 313: Kết nối Flowise với Tool bên ngoài**

*   Mục tiêu: Mở rộng khả năng của chatflow bằng hệ thống đã xây từ đầu khóa.
    
*   Lý thuyết: HTTP Request Tool, Custom Tool trong Flowise.
    
*   Thực hành: Thêm Tool gọi n8n webhook (Phase 4) để trigger workflow onboarding từ chatflow.
    

**Ngày 314: Memory trong Flowise**

*   Mục tiêu: Chatbot nhớ được ngữ cảnh cuộc hội thoại.
    
*   Lý thuyết: Conversation Memory, Buffer Memory vs Summary Memory.
    
*   Thực hành: Thêm Memory node, test hội thoại nhiều lượt có tham chiếu ngữ cảnh trước đó.
    

**Ngày 315: Practice - Flowise Assistant**

*   Mục tiêu: Có 1 trợ lý AI thật sự hữu ích cho công việc automation.
    
*   Lý thuyết: Ôn tập Tool, Memory, Agent.
    
*   Thực hành: Hoàn thiện 1 chatflow "Automation Assistant" có thể tạo Task, tra cứu trạng thái, trigger workflow n8n.
    

## TUẦN 64 - LANGFLOW

**Ngày 316: LangFlow Overview**

*   Mục tiêu: Biết thêm 1 lựa chọn xây AI flow trực quan.
    
*   Lý thuyết: Kiến trúc LangFlow, so sánh với Flowise (cả hai đều dựa LangChain).
    
*   Thực hành: Cài LangFlow, dựng lại chatflow cơ bản tương tự Ngày 311.
    

**Ngày 317: Component & Custom Component**

*   Mục tiêu: Mở rộng LangFlow khi component có sẵn không đủ.
    
*   Lý thuyết: Component structure trong LangFlow, viết custom component bằng Python.
    
*   Thực hành: Viết 1 custom component gọi API Task, dùng trong flow.
    

**Ngày 318: So sánh Flowise vs LangFlow**

*   Mục tiêu: Chọn đúng công cụ theo team (JS-centric vs Python-centric).
    
*   Lý thuyết: Bảng so sánh ngôn ngữ nền tảng, ecosystem, khả năng mở rộng.
    
*   Thực hành: Viết bảng so sánh Flowise vs LangFlow dựa trên trải nghiệm thực tế.
    

**Ngày 319: Xây lại Assistant trong LangFlow**

*   Mục tiêu: Củng cố kỹ năng qua việc làm lại bài quen thuộc trên công cụ mới.
    
*   Lý thuyết: Ôn tập Tool/Memory trong LangFlow.
    
*   Thực hành: Xây lại "Automation Assistant" (Ngày 315) trong LangFlow.
    

**Ngày 320: Practice - Chọn công cụ AI Flow**

*   Mục tiêu: Tổng kết và ra quyết định công cụ cho tổ chức.
    
*   Lý thuyết: Ôn tập MCP, Flowise, LangFlow.
    
*   Thực hành: Viết tài liệu khuyến nghị "khi nào dùng MCP trực tiếp, khi nào dùng Flowise/LangFlow" cho team.
    

## TUẦN 65 - RAG

**Ngày 321: RAG Fundamentals**

*   Mục tiêu: Hiểu vì sao cần RAG thay vì chỉ hỏi LLM trực tiếp.
    
*   Lý thuyết: Retrieval-Augmented Generation là gì, vấn đề hallucination LLM giải quyết được nhờ RAG.
    
*   Thực hành: Vẽ sơ đồ pipeline RAG: document → chunk → embedding → lưu trữ → truy vấn → LLM trả lời.
    

**Ngày 322: Chunking Strategy**

*   Mục tiêu: Chia tài liệu thành đoạn hợp lý để retrieval chính xác.
    
*   Lý thuyết: Fixed-size chunking, semantic chunking, overlap.
    
*   Thực hành: Viết script chunk 1 bộ tài liệu (ví dụ docs của hệ thống Task) theo 2 chiến lược, so sánh kết quả.
    

**Ngày 323: Embedding**

*   Mục tiêu: Biến văn bản thành vector để so sánh độ tương đồng.
    
*   Lý thuyết: Embedding model, cosine similarity.
    
*   Thực hành: Dùng 1 embedding API (hoặc model local) tạo vector cho các chunk Ngày 322.
    

**Ngày 324: Retrieval Strategy**

*   Mục tiêu: Lấy đúng đoạn tài liệu liên quan nhất cho câu hỏi.
    
*   Lý thuyết: Top-k retrieval, hybrid search (keyword + vector), re-ranking.
    
*   Thực hành: Viết truy vấn thử "cách reset mật khẩu tài khoản" và kiểm tra chunk nào được retrieve.
    

**Ngày 325: Đánh giá chất lượng RAG**

*   Mục tiêu: Biết đo lường RAG có "trả lời đúng" hay không.
    
*   Lý thuyết: Precision/Recall cho retrieval, đánh giá answer relevance thủ công.
    
*   Thực hành: Viết bộ 10 câu hỏi test, đánh giá thủ công chất lượng câu trả lời của pipeline RAG đã xây.
    

## TUẦN 66 - VECTOR DATABASE

**Ngày 326: pgvector**

*   Mục tiêu: Dùng lại PostgreSQL (đã học sâu ở Phase 1) để lưu vector.
    
*   Lý thuyết: Extension `pgvector`, kiểu dữ liệu `vector`, so sánh với vector DB chuyên dụng.
    
*   Thực hành: Cài `pgvector`, tạo bảng lưu embedding của các chunk Ngày 322-323, query bằng `<->` (cosine distance).
    

**Ngày 327: Qdrant**

*   Mục tiêu: Làm quen 1 vector DB chuyên dụng, hiệu năng cao hơn cho quy mô lớn.
    
*   Lý thuyết: Collection, Point, Payload trong Qdrant.
    
*   Thực hành: Cài Qdrant (Docker), import lại cùng bộ embedding, so sánh tốc độ query với pgvector.
    

**Ngày 328: Indexing Strategy cho Vector**

*   Mục tiêu: Vector search vẫn nhanh khi dữ liệu lớn.
    
*   Lý thuyết: HNSW index, trade-off giữa tốc độ và độ chính xác.
    
*   Thực hành: Thử điều chỉnh tham số HNSW trong Qdrant, quan sát ảnh hưởng tới tốc độ/độ chính xác.
    

**Ngày 329: Kết hợp Metadata Filtering**

*   Mục tiêu: Kết hợp vector search với filter thông thường (như SQL WHERE).
    
*   Lý thuyết: Payload filter trong Qdrant, filter kết hợp với vector search.
    
*   Thực hành: Query "tài liệu liên quan tới X, chỉ trong phòng ban Y" kết hợp vector search + metadata filter.
    

**Ngày 330: Practice - RAG Pipeline hoàn chỉnh**

*   Mục tiêu: Có 1 pipeline RAG production-ready.
    
*   Lý thuyết: Ôn tập chunking, embedding, retrieval, vector DB.
    
*   Thực hành: Hoàn thiện pipeline RAG dùng Qdrant, tích hợp vào MCP Server (Ngày 306-310) như 1 Tool "tra cứu tài liệu nội bộ".
    

## TUẦN 67 - AGENT WORKFLOW & CAPSTONE

**Ngày 331: Multi-Agent Design**

*   Mục tiêu: Hiểu khi nào nên chia 1 AI thành nhiều agent chuyên biệt.
    
*   Lý thuyết: Orchestrator agent, specialist agent, communication giữa agent.
    
*   Thực hành: Thiết kế (trên giấy) hệ multi-agent cho "AI Helpdesk": 1 agent phân loại câu hỏi, 1 agent tra cứu RAG, 1 agent thực thi hành động (tạo ticket).
    

**Ngày 332: Human-in-the-loop Pattern**

*   Mục tiêu: Đảm bảo AI không tự ý thực hiện hành động nhạy cảm.
    
*   Lý thuyết: Approval gate cho agent (liên hệ Approval Flow Phase 4), khi nào cần con người xác nhận.
    
*   Thực hành: Thêm bước "chờ người duyệt" trước khi Agent thực thi hành động tạo/xóa dữ liệu quan trọng.
    

**Ngày 333: Xây AI Helpdesk - Phần Retrieval & Routing**

*   Mục tiêu: Hiện thực hóa phần đầu của hệ multi-agent đã thiết kế.
    
*   Lý thuyết: Ôn tập RAG (tuần 65-66), Agent trong Flowise/LangFlow.
    
*   Thực hành: Xây agent phân loại câu hỏi + agent tra cứu RAG (dùng pipeline Ngày 330).
    

**Ngày 334: Xây AI Helpdesk - Phần Action & Integration**

*   Mục tiêu: Hoàn thiện khả năng AI thực thi hành động thật qua MCP/n8n.
    
*   Lý thuyết: Kết nối Agent với MCP Server (Ngày 310) và n8n webhook (Phase 4).
    
*   Thực hành: Thêm agent thực thi: tạo Jira ticket / gửi Slack khi cần, có human-in-the-loop cho hành động nhạy cảm.
    

**Ngày 335: Capstone Phase 11 - AI Helpdesk hoàn chỉnh**

*   Mục tiêu: Tổng kết toàn bộ AI Automation.
    
*   Lý thuyết: Ôn tập MCP, RAG, Vector DB, Multi-Agent.
    
*   Thực hành: Demo end-to-end AI Helpdesk: nhận câu hỏi → tra cứu RAG (Qdrant) → nếu cần hành động thì gọi MCP/n8n có duyệt của người → trả lời qua Slack.
    

# CAPSTONE PROJECTS - Kế hoạch tích hợp cuối khóa (8 tuần, Ngày 336–375)

## Capstone 1 - Automation Platform (2 tuần, Ngày 336–345)

**Stack:** Retool + PostgreSQL + n8n **Chức năng:** Workflow Builder, Approval System, Audit Log

*   Tuần 1: Thiết kế schema (Phase 1) cho workflow definition + audit log; xây n8n workflow engine chạy được các bước cấu hình động.
    
*   Tuần 2: Xây UI Retool (Phase 3) cho phép người dùng tạo/duyệt workflow không cần code; hoàn thiện audit trail đầy đủ; demo end-to-end.
    

## Capstone 2 - Enterprise Process Platform (2 tuần, Ngày 346–355)

**Stack:** Camunda + RabbitMQ + PostgreSQL **Chức năng:** Procurement, Change Request, Incident Management

*   Tuần 1: Deploy lại 3 quy trình BPMN đã xây ở Phase 6 lên 1 Camunda cluster chung; kết nối RabbitMQ (Phase 7) làm lớp giao tiếp giữa Camunda worker và hệ thống ngoài.
    
*   Tuần 2: Thêm reliability layer (Phase 9: retry, idempotency) và observability (Phase 10: log/metrics/trace) cho toàn bộ 3 quy trình; demo.
    

## Capstone 3 - Platform Automation Hub (2 tuần, Ngày 356–365)

**Stack:** Kubernetes + Vault + Terraform + ArgoCD + n8n **Chức năng:** User Provisioning, Secret Management, Infrastructure Requests

*   Tuần 1: Dùng Terraform (Phase 8) dựng hạ tầng; deploy toàn bộ hệ thống (API Task, n8n, Camunda, RabbitMQ...) qua ArgoCD GitOps; kết nối Vault cho toàn bộ secret.
    
*   Tuần 2: Xây n8n workflow "User Provisioning" (SCIM/SSO - bổ sung ở Phase 2) gọi Terraform/Vault để tự động cấp phát tài nguyên; demo self-service "Infrastructure Request" qua Retool.
    

## Capstone 4 - AI Automation Platform (2 tuần, Ngày 366–375)

**Stack:** n8n + Flowise + Qdrant + MCP + Slack **Chức năng:** AI Helpdesk, Knowledge Retrieval, Approval Agent

*   Tuần 1: Hoàn thiện lại AI Helpdesk (Phase 11) với dữ liệu thật của toàn bộ hệ thống đã xây (docs, quy trình, FAQ nội bộ) làm nguồn RAG.
    
*   Tuần 2: Kết nối Approval Agent với Approval Flow (Phase 4) và Camunda (Phase 6) để AI có thể *đề xuất* hành động nhưng luôn cần người duyệt; demo tổng kết toàn khóa học trước "hội đồng" (bạn bè/mentor/nhà tuyển dụng giả lập).