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