LAYER 6 - PLATFORM ENGINEERING

Tài nguyên: Team Topologies (Skelton & Pais), Accelerate (Forsgren/Humble/Kim), DevEx framework (Forsgren et al.), Backstage docs, CNCF Platform Engineering white paper/maturity model, Argo Rollouts/Flagger docs, OpenFeature, DORA reports, Docs for Developers.

KHỐI A - Platform-as-Product & Product Thinking (Ngày 1-24)

Ngày 1: Khởi động Layer 6

• Mục tiêu: Hiểu platform engineering giải quyết bài toán gì.

• Lý thuyết: vì sao platform team ra đời, giảm ma sát & cognitive load ở quy mô.

• Thực hành: Repo platform-eng/; viết một trang "vì sao cần platform".

Ngày 2: Team Topologies

• Mục tiêu: Mô hình tổ chức nền tảng.

• Lý thuyết: platform team, stream-aligned, enabling, complicated-subsystem; interaction modes.

• Thực hành: Vẽ topology cho một tổ chức giả định.

Ngày 3: Platform-as-Product

• Mục tiêu: Tư duy sản phẩm nội bộ.

• Lý thuyết: internal customer, adoption-not-mandate, thin platform.

• Thực hành: Xác định "khách hàng" và giá trị platform.

Ngày 4: Cognitive load & flow

• Mục tiêu: Nền của DevEx.

• Lý thuyết: intrinsic/extraneous load, flow state, vì sao giảm tải là mục tiêu.

• Thực hành: Liệt kê nguồn cognitive load của dev hiện tại.

Ngày 5: Personas

• Mục tiêu: Biết ai dùng.

• Lý thuyết: app dev, SRE, security, data, PM - nhu cầu khác nhau.

• Thực hành: Viết 3 persona chính.

Ngày 6: Stakeholder mapping

• Mục tiêu: Căn chỉnh kỳ vọng.

• Lý thuyết: stakeholder, quyền/lợi ích, alignment (nối Leadership cross-cutting).

• Thực hành: Bản đồ stakeholder + chiến lược giao tiếp.

Ngày 7: Discovery

• Mục tiêu: Hiểu pain thật.

• Lý thuyết: interview dev, jobs-to-be-done, pain point.

• Thực hành: Kịch bản phỏng vấn dev + tổng hợp pain.

Ngày 8: Value proposition

• Mục tiêu: Platform đáng dùng.

• Lý thuyết: value prop, thin viable platform, tránh over-build.

• Thực hành: Viết value proposition canvas.

Ngày 9: Roadmap

• Mục tiêu: Định hướng nhiều quý.

• Lý thuyết: outcome-based roadmap, now/next/later.

• Thực hành: Draft roadmap platform 3 quý.

Ngày 10: Prioritization

• Mục tiêu: Làm đúng thứ.

• Lý thuyết: impact vs effort, RICE, opportunity cost.

• Thực hành: Xếp hạng backlog platform.

Ngày 11: Build vs buy vs adopt

• Mục tiêu: Không tự làm mọi thứ.

• Lý thuyết: khi nào dùng OSS/SaaS, khi nào tự xây.

• Thực hành: Quyết định build/buy cho 3 capability.

Ngày 12: Golden path vs guardrail

• Mục tiêu: Ba khái niệm nền.

• Lý thuyết: golden path (paved road) vs guardrail (ràng buộc) vs escape hatch.

• Thực hành: Phân biệt bằng ví dụ cụ thể.

Ngày 13: Adoption strategy

• Mục tiêu: Được dùng, không bị ép.

• Lý thuyết: voluntary adoption, internal marketing (nối Layer 11), champion.

• Thực hành: Kế hoạch adoption cho một capability.

Ngày 14: Anti-patterns

• Mục tiêu: Tránh sai lầm kinh điển.

• Lý thuyết: platform-as-gatekeeper, ivory tower, ticket-ops.

• Thực hành: Checklist anti-pattern để tự soi.

Ngày 15: Operating model

• Mục tiêu: Vận hành platform team.

• Lý thuyết: on-call cho platform, support model, SLA nội bộ.

• Thực hành: Thiết kế support/on-call model.

Ngày 16: Success metrics (preview)

• Mục tiêu: Bắc cầu Khối E.

• Lý thuyết: DORA/DevEx/adoption sẽ đo thế nào.

• Thực hành: Chọn North Star metric cho platform.

Ngày 17: Platform API thinking

• Mục tiêu: Mọi thứ là self-service API.

• Lý thuyết: capability → API/CRD, không qua ticket.

• Thực hành: Liệt kê capability nên thành API.

Ngày 18: Thinnest viable platform

• Mục tiêu: Tiến hoá, không big-bang.

• Lý thuyết: TVP, bắt đầu nhỏ, mở rộng theo nhu cầu.

• Thực hành: Định nghĩa TVP đầu tiên.

Ngày 19: Developer sentiment

• Mục tiêu: Lắng nghe định lượng.

• Lý thuyết: survey design, cadence, hành động theo kết quả.

• Thực hành: Draft khảo sát DevEx.

Ngày 20: Case studies

• Mục tiêu: Học từ thực tế.

• Lý thuyết: Spotify (golden path/Backstage), Netflix, Google.

• Thực hành: Rút bài học áp dụng được.

Ngày 21: Maturity model

• Mục tiêu: Biết mình ở đâu.

• Lý thuyết: CNCF platform engineering maturity model.

• Thực hành: Tự chấm maturity một tổ chức giả định.

Ngày 22: Capabilities map

• Mục tiêu: Platform cung cấp gì.

• Lý thuyết: bản đồ capability (build/deploy/observe/secure/provision).

• Thực hành: Vẽ capability map mục tiêu.

Ngày 23: Ôn Khối A

• Mục tiêu: Chốt tư duy sản phẩm.

• Lý thuyết: rà persona → pain → value → roadmap.

• Thực hành: Chuẩn bị vision doc.

Ngày 24: Platform Vision & Strategy doc

• Mục tiêu: Kim chỉ nam.

• Lý thuyết: vision, principles, roadmap, metrics gói vào một doc.

• Thực hành: Viết "Platform Vision & Strategy" (dùng xuyên layer).

KHỐI B - Developer Experience & Golden Paths (Ngày 25-54) → P1

Ngày 25: DevEx framework

• Mục tiêu: Ba trục DevEx.

• Lý thuyết: feedback loops, cognitive load, flow state (Forsgren et al.).

• Thực hành: Map pain đã thu về 3 trục.

Ngày 26: Feedback loops

• Mục tiêu: Rút ngắn vòng phản hồi.

• Lý thuyết: local dev, CI speed, deploy time, review latency.

• Thực hành: Đo feedback loop hiện tại; tìm điểm chậm.

Ngày 27: Giảm cognitive load

• Mục tiêu: Dev tập trung việc chính.

• Lý thuyết: abstraction, sensible defaults, ẩn phức tạp không cần thiết.

• Thực hành: Chọn một quy trình rườm rà → đơn giản hoá.

Ngày 28: Inner vs outer loop

• Mục tiêu: Tối ưu đúng vòng.

• Lý thuyết: inner (code-build-test local) vs outer (CI-deploy-release).

• Thực hành: Vẽ hai vòng cho một service.

Ngày 29: Local dev experience

• Mục tiêu: Inner loop mượt.

• Lý thuyết: devcontainers, Tilt/Skaffold, hot reload, telepresence.

• Thực hành: Dựng local dev nhanh cho một service k8s.

Ngày 30: CỘT MỐC 30

• Mục tiêu: Chốt tư duy sản phẩm + DevEx.

• Lý thuyết: Ôn A + đầu B; kiểm kê: vision doc + hiểu DevEx.

• Thực hành: Đề thi #1 (platform-as-product/DevEx) + tự chấm; blog #60 ("Platform-as-Product: coi hạ tầng như một sản phẩm cho developer"); tag layer6-day030; nghỉ nửa ngày. Đã đi 30/180 (17%).

Ngày 31: Golden path - định nghĩa

• Mục tiêu: Con đường mặc định tốt.

• Lý thuyết: "new service to prod in minutes", opinionated.

• Thực hành: Đặc tả golden path mục tiêu.

Ngày 32: Paved road & escape hatch

• Mục tiêu: Mặc định tốt nhưng không cưỡng ép.

• Lý thuyết: paved road, escape hatch khi cần khác biệt.

• Thực hành: Xác định điểm cho phép "đi ra khỏi đường".

Ngày 33: Scaffolding concept

• Mục tiêu: Sinh dự án chuẩn.

• Lý thuyết: software template, scaffolder, cookiecutter-style.

• Thực hành: Sinh một service từ template thủ công.

Ngày 34: Repo templates

• Mục tiêu: Cấu trúc chuẩn.

• Lý thuyết: layout, CI wired-in, deploy config sẵn.

• Thực hành: Repo template có sẵn CI + deploy.

Ngày 35: Standardized CI

• Mục tiêu: CI tái dùng.

• Lý thuyết: reusable workflow/pipeline, DRY.

• Thực hành: Reusable CI pipeline dùng chung nhiều repo.

Ngày 36: Standardized build

• Mục tiêu: Build không cần Dockerfile thủ công.

• Lý thuyết: Cloud Native Buildpacks, ko, BuildKit (nối Layer 4).

• Thực hành: Build image bằng buildpacks không viết Dockerfile.

Ngày 37: Standardized deploy

• Mục tiêu: Deploy nhất quán.

• Lý thuyết: helm/kustomize generation, GitOps (nối Layer 4).

• Thực hành: Sinh manifest deploy từ metadata.

Ngày 38: Service catalog thinking

• Mục tiêu: Bắc cầu Backstage.

• Lý thuyết: vì sao cần catalog service/ownership.

• Thực hành: Phác mô hình catalog.

Ngày 39: Golden path - web service

• Mục tiêu: Đường cho stateless web.

• Lý thuyết: template + CI + deploy + observ + docs.

• Thực hành: Thiết kế golden path web service.

Ngày 40: Golden path - worker/batch

• Mục tiêu: Đường cho job.

• Lý thuyết: queue consumer, cronjob (nối Layer 4).

• Thực hành: Thiết kế golden path worker.

Ngày 41: Golden path - data pipeline

• Mục tiêu: Đường cho data (preview Layer 9).

• Lý thuyết: ingest → transform → store, orchestration.

• Thực hành: Phác golden path data (khái niệm).

Ngày 42: Docs baked in

• Mục tiêu: Tài liệu đi kèm mặc định.

• Lý thuyết: docs-as-code trong template (TechDocs preview).

• Thực hành: Template có sẵn khung docs.

Ngày 43: Observability baked in

• Mục tiêu: Quan sát tự động (nối Layer 7).

• Lý thuyết: auto metrics/logs/traces, dashboard mặc định.

• Thực hành: Template tự nối observability.

Ngày 44: Security baked in

• Mục tiêu: An toàn mặc định (nối Layer 8).

• Lý thuyết: secure defaults, scan trong CI, secret injection (nối Layer 5).

• Thực hành: Template có scan + secure defaults.

Ngày 45: Cost visibility baked in

• Mục tiêu: Thấy chi phí (nối Layer 11).

• Lý thuyết: tagging tự động, cost estimate.

• Thực hành: Template gắn tag cost chuẩn.

Ngày 46: P1 - thiết kế golden path

• Mục tiêu: Đóng khung P1.

• Lý thuyết: end-to-end: create → build → deploy → observe.

• Thực hách: golden-path-design.md.

Ngày 47: P1 - template + scaffolding

• Mục tiêu: Sinh service chuẩn.

• Lý thuyết: parameterized template.

• Thực hành: Scaffolder sinh repo service đầy đủ.

Ngày 48: P1 - CI pipeline

• Mục tiêu: Build/test/scan tự động.

• Lý thuyết: reusable CI + quality gate.

• Thực hành: CI hoạt động ngay khi sinh service.

Ngày 49: P1 - deploy (GitOps)

• Mục tiêu: Ra prod an toàn.

• Lý thuyết: GitOps (nối Layer 4), env promotion.

• Thực hành: Deploy tự động qua GitOps.

Ngày 50: P1 - observability + docs

• Mục tiêu: Vận hành được ngay.

• Lý thuyết: metrics/logs/traces + docs auto.

• Thực hành: Service mới có sẵn dashboard + docs.

Ngày 51: P1 - đo time-to-first-deploy

• Mục tiêu: Chứng minh giá trị.

• Lý thuyết: đo từ "tạo" tới "chạy prod".

• Thực hành: Đo thời gian; đặt mục tiêu (ví dụ < 30 phút).

Ngày 52: P1 - đo ma sát & lặp

• Mục tiêu: Cải thiện liên tục.

• Lý thuyết: friction log, dev feedback.

• Thực hành: Sửa 3 điểm ma sát lớn nhất.

Ngày 53: P1 - docs & examples

• Mục tiêu: Dev tự dùng được.

• Lý thuyết: getting-started, ví dụ.

• Thực hành: Viết docs golden path.

Ngày 54: P1 - Golden Path template

• Mục tiêu: Release P1.

• Lý thuyết: rà "done": create→prod tự động, có observ/docs/security.

• Thực hành: Đóng gói + blog #61 ("Golden path: đưa một service ra prod trong vài phút"). P1 done.

KHỐI C - Internal Developer Platform (Ngày 55-108) → P2

Ngày 55: IDP - khái niệm

• Mục tiêu: Bức tranh IDP.

• Lý thuyết: portal + orchestrator + platform API, một cửa cho dev.

• Thực hành: Vẽ kiến trúc IDP mục tiêu.

Ngày 56: IDP building blocks

• Mục tiêu: Thành phần cốt lõi.

• Lý thuyết: software catalog, scaffolder, TechDocs, scorecards.

• Thực hành: Map building blocks vào nhu cầu.

Ngày 57: Backstage - kiến trúc

• Mục tiêu: Portal phổ biến nhất.

• Lý thuyết: plugin architecture, frontend/backend, catalog.

• Thực hành: Đọc kiến trúc Backstage.

Ngày 58: Backstage - setup

• Mục tiêu: Dựng portal.

• Lý thuyết: app structure, config, DB.

• Thực hành: Chạy Backstage local.

Ngày 59: Software Catalog

• Mục tiêu: Bản đồ hệ thống.

• Lý thuyết: entity model (Component/System/API/Resource/Group).

• Thực hành: Thêm entity đầu tiên vào catalog.

Ngày 60: CỘT MỐC 60

• Mục tiêu: Chốt golden path + vào IDP.

• Lý thuyết: Ôn B + đầu C; kiểm kê: golden path (P1) + Backstage chạy.

• Thực hành: Đề thi #2 (golden path/DevEx/catalog) + tự chấm; blog #62 ("Từ golden path tới một Internal Developer Platform"); tag layer6-day060; nghỉ nửa ngày. Đã đi 60/180 (33%).

Ngày 61: Catalog - ownership & relations

• Mục tiêu: Ai sở hữu gì.

• Lý thuyết: catalog-info.yaml, owner, dependsOn/partOf relations.

• Thực hành: Mô hình hoá quan hệ giữa services.

Ngày 62: Catalog - discovery

• Mục tiêu: Tự động cập nhật.

• Lý thuyết: auto-ingest từ repo/annotation, providers.

• Thực hành: Auto-discover services từ nhiều repo.

Ngày 63: TechDocs

• Mục tiêu: Docs-as-code trong portal.

• Lý thuyết: TechDocs, mkdocs, docs cạnh code.

• Thực hành: Publish docs một service lên portal.

Ngày 64: Scaffolder

• Mục tiêu: Golden path trong portal.

• Lý thuyết: software templates, form → action.

• Thực hành: Tạo template Backstage sinh service.

Ngày 65: Scaffolder - actions

• Mục tiêu: Tùy biến sinh dự án.

• Lý thuyết: built-in actions, custom action.

• Thực hành: Viết custom action (ví dụ tạo repo + register catalog).

Ngày 66: Scaffolder - wire golden path

• Mục tiêu: Ghép P1 vào IDP.

• Lý thuyết: template gọi golden path template (P1).

• Thực hành: Dev bấm nút → sinh service golden path.

Ngày 67: Plugin ecosystem

• Mục tiêu: Không làm lại từ đầu.

• Lý thuyết: plugin có sẵn (CI/CD, k8s, cost, incident).

• Thực hành: Cài + cấu hình 2 plugin hữu ích.

Ngày 68: Custom plugin - frontend

• Mục tiêu: Mở rộng portal.

• Lý thuyết: frontend plugin, card, page.

• Thực hành: Viết plugin hiển thị deploy status.

Ngày 69: Custom plugin - backend

• Mục tiêu: Tích hợp hệ ngoài.

• Lý thuyết: backend plugin, gọi API ngoài.

• Thực hành: Backend plugin lấy dữ liệu từ một hệ nội bộ.

Ngày 70: Permissions

• Mục tiêu: Kiểm soát trong portal.

• Lý thuyết: permission framework, policy.

• Thực hành: Giới hạn ai được dùng scaffolder nào.

Ngày 71: Auth & identity

• Mục tiêu: Đăng nhập (nối Layer 5).

• Lý thuyết: OIDC/SSO integration, user→group.

• Thực hành: SSO + map group vào ownership.

Ngày 72: CI/CD view

• Mục tiêu: Thấy pipeline trong portal.

• Lý thuyết: integrate CI status vào catalog entity.

• Thực hành: Hiển thị CI/CD của service trong portal.

Ngày 73: k8s plugin

• Mục tiêu: Thấy workload (nối Layer 4).

• Lý thuyết: Backstage k8s plugin, map entity → workload.

• Thực hành: Xem pod/deploy của service trong portal.

Ngày 74: Cost & observability view

• Mục tiêu: Một cửa vận hành.

• Lý thuyết: nhúng dashboard/cost (nối Layer 7/11).

• Thực hành: Nhúng metrics + cost vào trang service.

Ngày 75: Platform API

• Mục tiêu: Capability là API.

• Lý thuyết: expose capability qua API/CRD (nối Layer 4 operator).

• Thực hành: Thiết kế một platform API (ví dụ "provision database").

Ngày 76: Platform orchestrator

• Mục tiêu: Điều phối provisioning.

• Lý thuyết: Score/Kratix/Humanitec - tách workload khỏi platform.

• Thực hành: Đọc mô hình orchestrator; chọn hướng.

Ngày 77: Score

• Mục tiêu: Workload spec trung lập.

• Lý thuyết: Score spec, abstract khỏi platform cụ thể.

• Thực hành: Viết một Score file cho service.

Ngày 78: Kratix

• Mục tiêu: Platform theo "promise".

• Lý thuyết: Kratix promise, pipeline (nối Layer 4 operators).

• Thực hành: Đọc promise-based platform; ý tưởng áp dụng.

Ngày 79: Crossplane làm backend

• Mục tiêu: Provisioning thật (nối Layer 4/5).

• Lý thuyết: IDP request → Crossplane XR → tài nguyên cloud.

• Thực hành: Nối một self-service request tới Crossplane.

Ngày 80: Self-service - flow

• Mục tiêu: Request → provisioned tự động.

• Lý thuyết: portal form → orchestrator → provision, không ticket.

• Thực hành: Thiết kế một self-service flow đầu-cuối.

Ngày 81: Self-service - environment

• Mục tiêu: Env theo yêu cầu.

• Lý thuyết: ephemeral/preview environments, TTL.

• Thực hành: Self-service tạo preview env cho PR.

Ngày 82: Self-service - resource

• Mục tiêu: DB/bucket theo yêu cầu.

• Lý thuyết: golden defaults (encryption/backup), Crossplane.

• Thực hành: Self-service provision một database an toàn.

Ngày 83: Self-service + guardrails

• Mục tiêu: Tự do trong khuôn khổ (nối Layer 5).

• Lý thuyết: policy auto-áp (OPA/Kyverno), quota.

• Thực hành: Guardrail tự động áp khi provision.

Ngày 84: Multi-tenancy trong IDP

• Mục tiêu: Nhiều team dùng chung (nối Layer 4).

• Lý thuyết: tenant model, isolation, ownership.

• Thực hành: Thiết kế tenancy cho portal.

Ngày 85: RBAC & ownership

• Mục tiêu: Đúng người đúng quyền.

• Lý thuyết: ownership → quyền, team scoping.

• Thực hành: Gắn quyền theo ownership catalog.

Ngày 86: Scorecards - khái niệm

• Mục tiêu: Đo sức khoẻ kỹ thuật.

• Lý thuyết: tech health, standards, maturity check.

• Thực hành: Chọn bộ tiêu chí scorecard.

Ngày 87: Scorecards - định nghĩa chuẩn

• Mục tiêu: Chuẩn hoá kỳ vọng.

• Lý thuyết: has-docs/has-oncall/has-tests/has-slo (nối Layer 11).

• Thực hành: Viết bộ standard cho service.

Ngày 88: Scorecards - tự động & gamify

• Mục tiêu: Cải thiện tự nguyện.

• Lý thuyết: automated check, leaderboard, nudge.

• Thực hành: Chấm điểm tự động cho các service.

Ngày 89: Golden path adoption qua portal

• Mục tiêu: Đẩy adoption.

• Lý thuyết: làm golden path là đường dễ nhất.

• Thực hành: Đo tỉ lệ service dùng golden path.

Ngày 90: CỘT MỐC 90

• Mục tiêu: Chốt nửa IDP.

• Lý thuyết: Ôn C tới giờ; kiểm kê: catalog + scaffolder + plugin + self-service khởi đầu.

• Thực hành: Đề thi #3 (Backstage/catalog/scaffolder/self-service) + tự chấm; blog #63 ("Backstage: catalog, scaffolder và self-service cho developer"); tag layer6-day090; nghỉ nửa ngày. Đã đi 90/180 (50%).

Ngày 91: Onboarding experience

• Mục tiêu: Dev mới productive nhanh.

• Lý thuyết: onboarding path, "day-1 to first commit".

• Thực hành: Thiết kế onboarding flow trong portal.

Ngày 92: Day-2 self-service

• Mục tiêu: Vận hành cũng self-service.

• Lý thuyết: scale/rotate secret/rollback qua portal (nối Layer 5/11).

• Thực hành: Thêm day-2 action vào portal.

Ngày 93: P2 - thiết kế IDP

• Mục tiêu: Đóng khung P2.

• Lý thuyết: catalog + scaffolder + self-service + scorecards + auth.

• Thực hách: idp-design.md.

Ngày 94: P2 - catalog & ownership

• Mục tiêu: Nền IDP.

• Lý thuyết: auto-discovery + ownership.

• Thực hành: Catalog đầy đủ service + owner.

Ngày 95: P2 - scaffolder + golden path

• Mục tiêu: Self-service tạo service.

• Lý thuyết: wire P1 golden path.

• Thực hành: Bấm nút → service golden path chạy prod.

Ngày 96: P2 - TechDocs

• Mục tiêu: Docs tập trung.

• Lý thuyết: docs-as-code cho mọi service.

• Thực hành: TechDocs cho các service.

Ngày 97: P2 - custom plugin

• Mục tiêu: Giá trị riêng.

• Lý thuyết: plugin phù hợp nhu cầu (deploy/incident).

• Thực hành: Viết một custom plugin hữu ích.

Ngày 98: P2 - self-service provisioning

• Mục tiêu: Provision qua portal.

• Lý thuyết: Crossplane backend (nối Layer 4/5).

• Thực hành: Self-service provision resource với guardrail.

Ngày 99: P2 - scorecards

• Mục tiêu: Đo chuẩn kỹ thuật.

• Lý thuyết: automated scorecard.

• Thực hành: Scorecard chạy cho toàn catalog.

Ngày 100:

• Mục tiêu: Kiểm kê lớn giữa Layer 6.

• Lý thuyết: Ôn A→C; kiểm kê lớn: vision + golden path (P1) + IDP đang thành hình; đối chiếu "Sâu".

• Thực hành: Đề thi #4 tích lũy (product/DevEx/golden path/IDP) + tự chấm theo rubric; blog #64 ("100 ngày platform engineering: từ tư duy sản phẩm tới một IDP self-service"); tag layer6-day100; nghỉ nửa ngày. Đã đi 100/180 (56%).

Ngày 101: P2 - auth & permissions

• Mục tiêu: An toàn portal.

• Lý thuyết: SSO + permission theo ownership.

• Thực hành: Áp auth + permission.

Ngày 102: P2 - multi-tenancy

• Mục tiêu: Nhiều team.

• Lý thuyết: tenant isolation trong portal.

• Thực hành: Cấu hình tenancy.

Ngày 103: P2 - observability/cost views

• Mục tiêu: Một cửa vận hành.

• Lý thuyết: nhúng metrics/cost (nối Layer 7/11).

• Thực hành: Trang service có metrics + cost.

Ngày 104: P2 - self-service guardrails

• Mục tiêu: An toàn tự động.

• Lý thuyết: policy áp khi self-service (nối Layer 5).

• Thực hành: Guardrail hoạt động trên mọi request.

Ngày 105: P2 - onboarding flow

• Mục tiêu: Trải nghiệm dev mới.

• Lý thuyết: getting-started tích hợp.

• Thực hành: Test onboarding với "dev mới".

Ngày 106: P2 - đo self-service success

• Mục tiêu: Chứng minh giá trị.

• Lý thuyết: lead time provisioning, ticket giảm.

• Thực hành: Đo trước/sau self-service.

Ngày 107: P2 - docs & demo

• Mục tiêu: Sẵn sàng release.

• Lý thuyết: docs portal + demo.

• Thực hành: Viết docs + demo E2E.

Ngày 108: P2 - Backstage IDP

• Mục tiêu: Release P2.

• Lý thuyết: rà "done": catalog + scaffolder + self-service + scorecards + auth.

• Thực hành: Đóng gói + blog #65 ("Một IDP hoàn chỉnh trên Backstage"). P2 done.

KHỐI D - Release Engineering / Progressive Delivery (Ngày 109-144) → P3

Ngày 109: Release engineering

• Mục tiêu: Release an toàn, lặp lại.

• Lý thuyết: reproducible build, versioning, artifact promotion.

• Thực hành: Định nghĩa quy trình release chuẩn.

Ngày 110: Deployment strategies

• Mục tiêu: Bản đồ chiến lược.

• Lý thuyết: recreate, rolling, blue-green, canary - đánh đổi.

• Thực hành: Bảng chọn strategy theo bối cảnh.

Ngày 111: Rolling update

• Mục tiêu: Chiến lược mặc định k8s (nối Layer 4).

• Lý thuyết: maxSurge/maxUnavailable, readiness gate.

• Thực hách: Rolling update không downtime.

Ngày 112: Blue-green

• Mục tiêu: Chuyển đổi tức thì.

• Lý thuyết: hai môi trường, switch, rollback nhanh.

• Thực hành: Blue-green cho một service.

Ngày 113: Canary

• Mục tiêu: Rủi ro thấp.

• Lý thuyết: dịch traffic dần, quan sát, promote.

• Thực hành: Canary thủ công theo % traffic.

Ngày 114: Traffic shifting

• Mục tiêu: Cơ chế điều hướng.

• Lý thuyết: mesh (nối Layer 4), ingress/Gateway API, LB weight.

• Thực hành: Dịch traffic qua mesh/gateway.

Ngày 115: Progressive delivery

• Mục tiêu: Tự động hoá canary.

• Lý thuyết: deploy tách release, analysis-driven promotion, auto-rollback.

• Thực hành: Vẽ vòng progressive delivery.

Ngày 116: Argo Rollouts - nền

• Mục tiêu: Công cụ progressive delivery.

• Lý thuyết: Rollout CRD, replaces Deployment.

• Thực hành: Chuyển một Deployment sang Rollout.

Ngày 117: Argo Rollouts - canary steps

• Mục tiêu: Điều khiển từng bước.

• Lý thuyết: steps, setWeight, pause, promote.

• Thực hành: Canary nhiều bước có pause.

Ngày 118: Argo Rollouts - analysis

• Mục tiêu: Promote theo số liệu.

• Lý thuyết: AnalysisTemplate, metric provider (Prometheus, nối Layer 7).

• Thực hành: Analysis dựa trên error rate/latency.

Ngày 119: Argo Rollouts - auto-rollback

• Mục tiêu: Tự lùi khi xấu.

• Lý thuyết: abort khi metric vi phạm, rollback.

• Thực hành: Deploy tệ → tự rollback.

Ngày 120: CỘT MỐC 120

• Mục tiêu: Chốt canary tự động.

• Lý thuyết: Ôn D tới giờ; kiểm kê: Argo Rollouts canary + analysis + rollback.

• Thực hành: Đề thi #5 (deployment strategies/progressive delivery) + tự chấm; blog #66 ("Progressive delivery: canary tự động với promote/rollback theo số liệu"); tag layer6-day120; nghỉ nửa ngày. Đã đi 120/180 (67%).

Ngày 121: Flagger

• Mục tiêu: Lựa chọn khác.

• Lý thuyết: Flagger, mesh/ingress integration, canary analysis.

• Thực hành: Canary bằng Flagger.

Ngày 122: Flagger - webhooks & analysis

• Mục tiêu: Kiểm thử trong canary.

• Lý thuyết: pre/post-rollout webhook, load test, metric check.

• Thực hành: Thêm smoke test vào canary.

Ngày 123: Argo Rollouts vs Flagger

• Mục tiêu: Chọn công cụ.

• Lý thuyết: so sánh mô hình, integration.

• Thực hành: Bảng đánh đổi.

Ngày 124: SLO-based promotion

• Mục tiêu: Gắn với độ tin cậy (nối Layer 7/11).

• Lý thuyết: promote theo SLO/error budget, không chỉ metric thô.

• Thực hành: Analysis theo SLO.

Ngày 125: Feature flags - nền

• Mục tiêu: Tách deploy khỏi release.

• Lý thuyết: flag, dark launch, kill switch.

• Thực hành: Bọc một tính năng sau flag.

Ngày 126: OpenFeature

• Mục tiêu: Chuẩn trung lập.

• Lý thuyết: OpenFeature API, provider, evaluation.

• Thực hành: Tích hợp OpenFeature SDK.

Ngày 127: Flag providers

• Mục tiêu: Backend flag.

• Lý thuyết: Unleash/Flagsmith/LaunchDarkly.

• Thực hành: Dựng Unleash; đánh giá flag.

Ngày 128: Flags - targeting & rollout

• Mục tiêu: Bật dần có kiểm soát.

• Lý thuyết: percentage rollout, targeting rules, kill switch.

• Thực hành: Rollout tính năng 1%→100% theo segment.

Ngày 129: Flags - lifecycle & debt

• Mục tiêu: Tránh nợ flag.

• Lý thuyết: flag lifecycle, cleanup, ownership.

• Thực hành: Quy trình dọn flag chết.

Ngày 130: Experimentation

• Mục tiêu: Quyết định bằng dữ liệu.

• Lý thuyết: A/B test trên flag, metric quyết định.

• Thực hành: Thiết kế một A/B experiment.

Ngày 131: Release orchestration

• Mục tiêu: Nhiều service cùng release.

• Lý thuyết: coordination, dependency ordering.

• Thực hành: Phối hợp release 2 service phụ thuộc.

Ngày 132: Rollback & DB migration

• Mục tiêu: Lùi an toàn (nối Layer 3).

• Lý thuyết: backward-compatible migration, expand-contract.

• Thực hành: Migration an toàn cho rollback.

Ngày 133: Deployment safety

• Mục tiêu: Chặn deploy tệ sớm.

• Lý thuyết: pre/post check, smoke test, health gate.

• Thực hành: Thêm safety gate vào pipeline.

Ngày 134: GitOps + progressive delivery

• Mục tiêu: Ghép với GitOps (nối Layer 4).

• Lý thuyết: Rollout qua GitOps, drift.

• Thực hành: Progressive delivery điều khiển bằng Git.

Ngày 135: Release governance

• Mục tiêu: Kiểm soát mà không cản.

• Lý thuyết: approval, change window, freeze, audit.

• Thực hành: Thiết kế governance nhẹ.

Ngày 136: Incident-driven rollback

• Mục tiêu: Nối vận hành (nối Layer 11).

• Lý thuyết: rollback trong incident, runbook.

• Thực hành: Runbook rollback nhanh.

Ngày 137: P3 - thiết kế pipeline

• Mục tiêu: Đóng khung P3.

• Lý thuyết: canary + analysis + flags + auto-rollback + GitOps.

• Thực hách: progressive-delivery-design.md.

Ngày 138: P3 - Argo Rollouts + mesh

• Mục tiêu: Canary thật.

• Lý thuyết: Rollout + traffic qua mesh (nối Layer 4).

• Thực hành: Canary theo % traffic.

Ngày 139: P3 - SLO analysis + rollback

• Mục tiêu: An toàn tự động.

• Lý thuyết: promote/abort theo SLO.

• Thực hành: Auto-rollback khi SLO vi phạm.

Ngày 140: P3 - feature flags

• Mục tiêu: Tách release.

• Lý thuyết: OpenFeature + provider.

• Thực hành: Kết hợp canary + flag targeting.

Ngày 141: P3 - wire vào golden path/IDP

• Mục tiêu: Mọi service được progressive delivery mặc định.

• Lý thuyết: tích hợp P1/P2.

• Thực hành: Golden path tự có canary + flags.

Ngày 142: P3 - game-day

• Mục tiêu: Chứng minh an toàn (nối Layer 11).

• Lý thuyết: deploy lỗi cố ý → tự rollback.

• Thực hành: Game-day; xác nhận auto-rollback.

Ngày 143: P3 - docs & runbook

• Mục tiêu: Vận hành được.

• Lý thuyết: runbook release/rollback.

• Thực hành: Viết runbook.

Ngày 144: P3 - Progressive delivery pipeline

• Mục tiêu: Release P3.

• Lý thuyết: rà "done": canary + analysis + flags + auto-rollback + docs.

• Thực hành: Đóng gói + blog #67 ("Deploy an toàn: canary theo SLO + feature flags + tự rollback"). P3 done.

KHỐI E - Metrics (Ngày 145-162) → P4

Ngày 145: Vì sao đo

• Mục tiêu: Outcome không phải output.

• Lý thuyết: đo để cải thiện, tránh vanity metric.

• Thực hành: Phân biệt outcome vs output cho platform.

Ngày 146: DORA - 4 metric

• Mục tiêu: Chuẩn công nghiệp.

• Lý thuyết: deploy frequency, lead time for changes, change failure rate, time-to-restore.

• Thực hành: Định nghĩa 4 metric cho tổ chức giả định.

Ngày 147: DORA - nghiên cứu & reliability

• Mục tiêu: Hiểu khoa học phía sau.

• Lý thuyết: Accelerate, elite vs low performer, metric thứ 5 (reliability).

• Thực hành: Đọc DORA report; rút insight.

Ngày 148: Đo DORA

• Mục tiêu: Lấy số thật.

• Lý thuyết: instrument pipeline, nguồn dữ liệu (CI/CD, incident).

• Thực hành: Thiết kế cách thu 4 metric.

Ngày 149: Lead time for changes

• Mục tiêu: Commit → prod.

• Lý thuyết: đo lead time, batch size ảnh hưởng.

• Thực hành: Đo lead time cho một service.

Ngày 150: CỘT MỐC 150

• Mục tiêu: Chốt release engineering + vào metrics.

• Lý thuyết: Ôn D + đầu E; kiểm kê: progressive delivery (P3) + hiểu DORA.

• Thực hành: Đề thi #6 (progressive delivery/DORA) + tự chấm; blog #68 ("Đo platform bằng DORA: deploy frequency, lead time, CFR, MTTR"); tag layer6-day150; nghỉ nửa ngày. Đã đi 150/180 (83%).

Ngày 151: Deploy frequency & batch size

• Mục tiêu: Ship nhỏ, thường xuyên.

• Lý thuyết: small batch, giảm rủi ro.

• Thực hành: Đo tần suất deploy; đề xuất giảm batch.

Ngày 152: CFR & MTTR

• Mục tiêu: Chất lượng & phục hồi (nối Layer 11).

• Lý thuyết: change failure rate, time-to-restore, quan hệ với progressive delivery.

• Thực hành: Đo CFR/MTTR; nối vào incident.

Ngày 153: SPACE framework

• Mục tiêu: Vượt DORA.

• Lý thuyết: Satisfaction/Performance/Activity/Communication/Efficiency.

• Thực hành: Chọn metric SPACE bổ sung.

Ngày 154: DevEx metrics

• Mục tiêu: Đo trải nghiệm.

• Lý thuyết: feedback loop/cognitive load/flow - đo thế nào.

• Thực hành: Bộ metric DevEx.

Ngày 155: Developer surveys

• Mục tiêu: Định tính đi kèm định lượng.

• Lý thuyết: thiết kế survey, cadence, hành động.

• Thực hành: Chạy + phân tích một survey (mô phỏng).

Ngày 156: Scorecards ở quy mô

• Mục tiêu: Sức khoẻ toàn hệ.

• Lý thuyết: tech health scorecard aggregate.

• Thực hành: Dashboard scorecard toàn catalog.

Ngày 157: Tránh gaming metric

• Mục tiêu: Đo lành mạnh.

• Lý thuyết: Goodhart's law, balance metric, không xếp hạng cá nhân.

• Thực hành: Rà bộ metric tránh bị "lách".

Ngày 158: Adoption metrics

• Mục tiêu: Đo giá trị platform.

• Lý thuyết: usage, NPS nội bộ, time-to-value, ticket giảm.

• Thực hành: Định nghĩa adoption metric.

Ngày 159: P4 - thiết kế dashboard

• Mục tiêu: Đóng khung P4.

• Lý thuyết: DORA + DevEx + adoption trên một dashboard.

• Thực hách: metrics-dashboard-design.md.

Ngày 160: P4 - instrument DORA

• Mục tiêu: Số tự động.

• Lý thuyết: thu từ pipeline/incident (nối Layer 7).

• Thực hành: Pipeline emit 4 DORA metric.

Ngày 161: P4 - dashboard + surveys

• Mục tiêu: Nhìn được toàn cảnh.

• Lý thuyết: dashboard (nối Layer 7) + kết quả survey.

• Thực hành: Dashboard DORA/DevEx/adoption sống.

Ngày 162: P4 - Metrics dashboard

• Mục tiêu: Release P4.

• Lý thuyết: rà "done": DORA tự động + DevEx + adoption.

• Thực hành: Đóng gói + blog #69 ("Dashboard đo sức khoẻ platform: DORA, DevEx, adoption"). P4 done.

KHỐI F - Documentation & Technical Communication (Ngày 163-174)

Ngày 163: Docs-as-code

• Mục tiêu: Docs versioned, review được.

• Lý thuyết: docs cạnh code, review, publish (TechDocs, nối Khối C).

• Thực hành: Quy trình docs-as-code.

Ngày 164: Diataxis

• Mục tiêu: Cấu trúc docs đúng.

• Lý thuyết: tutorial/how-to/reference/explanation.

• Thực hành: Phân loại docs hiện có theo Diataxis.

Ngày 165: RFC process

• Mục tiêu: Đề xuất & đồng thuận.

• Lý thuyết: RFC lifecycle, review culture (nối Leadership).

• Thực hành: Viết một RFC platform.

Ngày 166: ADR

• Mục tiêu: Ghi lại quyết định.

• Lý thuyết: Architecture Decision Record, context/decision/consequence.

• Thực hành: Viết 2 ADR cho platform.

Ngày 167: Runbook

• Mục tiêu: Vận hành khi có sự cố (nối Layer 11).

• Lý thuyết: runbook chuẩn, actionable step.

• Thực hành: Viết runbook cho một failure mode.

Ngày 168: API documentation

• Mục tiêu: Platform tự tài liệu.

• Lý thuyết: OpenAPI, self-documenting, ví dụ sống.

• Thực hành: Docs cho một platform API.

Ngày 169: Onboarding docs

• Mục tiêu: Dev mới tự đi.

• Lý thuyết: getting-started, "golden path in docs".

• Thực hành: Viết onboarding guide.

Ngày 170: Viết cho developer

• Mục tiêu: Rõ ràng, dùng được.

• Lý thuyết: clarity, ví dụ, ngắn gọn.

• Thực hành: Rewrite một trang docs rối.

Ngày 171: Discoverability

• Mục tiêu: Tìm được docs.

• Lý thuyết: search, navigation, single source.

• Thực hành: Cải thiện tìm kiếm docs portal.

Ngày 172: Giữ docs sống

• Mục tiêu: Chống docs cũ.

• Lý thuyết: ownership, staleness check (scorecard).

• Thực hành: Scorecard "docs freshness".

Ngày 173: Internal comms

• Mục tiêu: Cập nhật cho dev.

• Lý thuyết: changelog, platform update, viral internal doc (nối Leadership).

• Thực hành: Viết một changelog/update mẫu.

Ngày 174: Ôn Khối F

• Mục tiêu: Chốt communication.

• Lý thuyết: rà RFC/ADR/runbook/docs-as-code.

• Thực hành: Chuẩn bị capstone.

KHỐI G - Platform Product capstone (Ngày 175-180) → P5 flagship

Ngày 175: P5 - tích hợp

• Mục tiêu: Ghép mọi mảnh thành sản phẩm.

• Lý thuyết: IDP (P2) + golden path (P1) + progressive delivery (P3) + metrics (P4).

• Thực hành: Nối tất cả vào một platform.

Ngày 176: P5 - hành trình self-service E2E

• Mục tiêu: Trải nghiệm đầu-cuối.

• Lý thuyết: từ "tạo service" → build → canary → prod → observ, tất cả self-service.

• Thực hành: Chạy trọn hành trình cho một service mới.

Ngày 177: P5 - đo golden path bằng DORA

• Mục tiêu: Chứng minh tác động.

• Lý thuyết: DORA cho service qua golden path vs không.

• Thực hành: Đo & so sánh DORA.

Ngày 178: P5 - platform như sản phẩm thật

• Mục tiêu: Vận hành chuyên nghiệp.

• Lý thuyết: docs/RFC/ADR/roadmap/runbook như OSS (nối Khối F).

• Thực hành: Bộ tài liệu platform hoàn chỉnh.

Ngày 179: P5 - adoption & feedback; ôn Layer 6

• Mục tiêu: Vòng cải thiện.

• Lý thuyết: adoption metric, feedback loop, iterate.

• Thực hành: Thiết lập feedback loop; rà toàn layer.

Ngày 180: HOÀN THÀNH LAYER 6

• Mục tiêu: Chốt Platform Engineering ở mức Sâu.

• Lý thuyết: Ôn toàn layer; kiểm kê tổng: P1 golden path + P2 IDP + P3 progressive delivery + P4 metrics + P5 Platform Product tích hợp đo bằng DORA.

• Thực hành: P5 done; đề thi #7 tích lũy (toàn layer) + tự chấm theo rubric; blog #70 ("Nhìn lại 180 ngày platform engineering: một Platform Product self-service đo bằng DORA"); tag layer6-complete; nghỉ nửa ngày.

LAYER 7 - OBSERVABILITY ENGINEERING

Tài nguyên: Observability Engineering (Majors/Fong-Jones/Miranda), Google SRE Book/Workbook (SLO/alerting), OpenTelemetry docs, Prometheus docs, Grafana docs (Loki/Tempo/Mimir/Pyroscope), Brendan Gregg (profiling), Distributed Tracing in Practice.

KHỐI A - Fundamentals & Instrumentation (OpenTelemetry) (Ngày 1-30) → P1

Ngày 1: Khởi động Layer 7

• Mục tiêu: Phân biệt monitoring vs observability + dựng lab.

• Lý thuyết: monitoring (known-unknowns) vs observability (unknown-unknowns).

• Thực hành: Repo observability/; dựng lab (app mẫu multi-service + Grafana stack).

Ngày 2: Ba trụ → bốn tín hiệu

• Mục tiêu: Bản đồ tín hiệu.

• Lý thuyết: metrics/logs/traces + profiles (trụ thứ tư), điểm mạnh/yếu từng loại.

• Thực hành: Bảng: câu hỏi nào tín hiệu nào trả lời.

Ngày 3: Vì sao observability

• Mục tiêu: Giá trị thật.

• Lý thuyết: high-cardinality, debug hệ phân tán, hỏi câu chưa lường trước.

• Thực hành: Liệt kê 5 câu hỏi "unknown-unknown".

Ngày 4: REDUSEGolden Signals

• Mục tiêu: Khung tín hiệu chuẩn.

• Lý thuyết: RED (Rate/Errors/Duration) cho service, USE (Utilization/Saturation/Errors) cho tài nguyên, Four Golden Signals.

• Thực hành: Áp RED + USE cho một service.

Ngày 5: SLI/SLO/error budget

• Mục tiêu: Đo độ tin cậy (sâu ở Layer 11).

• Lý thuyết: SLI (chỉ số), SLO (mục tiêu), error budget.

• Thực hành: Phác SLI/SLO cho một service.

Ngày 6: Cardinality

• Mục tiêu: Bài toán trung tâm của observability.

• Lý thuyết: dimensionality, cardinality explosion, chi phí.

• Thực hành: Ước lượng cardinality một tập label.

Ngày 7: Sampling vs full-fidelity

• Mục tiêu: Đánh đổi cốt lõi.

• Lý thuyết: khi nào sample, mất gì, giữ gì.

• Thực hành: Kịch bản chọn sampling.

Ngày 8: Chi phí observability

• Mục tiêu: Không phá ngân sách (nối Layer 11).

• Lý thuyết: ingest/storage/query cost, cost per signal.

• Thực hành: Ước tính chi phí một stack.

Ngày 9: OpenTelemetry - vì sao

• Mục tiêu: Chuẩn hoá instrumentation.

• Lý thuyết: vendor-neutral, tránh lock-in, hợp nhất tín hiệu.

• Thực hành: Đọc kiến trúc OTel.

Ngày 10: OTel - API/SDK/Collector

• Mục tiêu: Ba lớp.

• Lý thuyết: API (instrument), SDK (xử lý), Collector (thu/biến đổi/xuất).

• Thực hành: Vẽ luồng dữ liệu OTel.

Ngày 11: OTel signals

• Mục tiêu: Bốn tín hiệu trong OTel.

• Lý thuyết: traces/metrics/logs/profiles trong một mô hình.

• Thực hành: Map tín hiệu → tài nguyên chung.

Ngày 12: OTLP

• Mục tiêu: Giao thức truyền.

• Lý thuyết: OTLP gRPC/HTTP, resource/scope/data.

• Thực hành: Bắt một payload OTLP; đọc cấu trúc.

Ngày 13: Semantic conventions

• Mục tiêu: Nhất quán tên/attribute.

• Lý thuyết: semantic conventions (http/db/messaging), keo dán correlation.

• Thực hành: Áp semantic conventions cho một service.

Ngày 14: Context propagation

• Mục tiêu: Nối tín hiệu qua service.

• Lý thuyết: W3C Trace Context (traceparent), baggage.

• Thực hành: Propagate context qua 2 service.

Ngày 15: Auto-instrumentation

• Mục tiêu: Nhanh, ít công.

• Lý thuyết: agent/auto-instrument theo ngôn ngữ.

• Thực hành: Auto-instrument app; xem tín hiệu ra.

Ngày 16: Manual instrumentation

• Mục tiêu: Kiểm soát sâu.

• Lý thuyết: span/metric thủ công, khi nào cần.

• Thực hành: Thêm span + metric custom cho logic quan trọng.

Ngày 17: OTel Collector

• Mục tiêu: Trung tâm xử lý.

• Lý thuyết: receivers/processors/exporters, pipeline.

• Thực hành: Dựng collector nhận OTLP → xuất backend.

Ngày 18: Collector - pipeline

• Mục tiêu: Xử lý tin cậy.

• Lý thuyết: batching, retry, queue, memory limiter.

• Thực hành: Cấu hình batching + retry.

Ngày 19: Collector - deployment

• Mục tiêu: Mô hình triển khai.

• Lý thuyết: agent (per-node) vs gateway (tập trung).

• Thực hành: Dựng agent + gateway (nối Layer 4).

Ngày 20: Collector - transform/redact

• Mục tiêu: Sạch & an toàn (nối Layer 8).

• Lý thuyết: filter/transform, redact PII, drop noise.

• Thực hành: Loại PII + giảm cardinality tại collector.

Ngày 21: Instrument app mẫu

• Mục tiêu: Có hệ để quan sát.

• Lý thuyết: app multi-service (web + worker + db).

• Thực hành: Dựng app mẫu sinh traffic.

Ngày 22: Instrument - metrics

• Mục tiêu: Số đo.

• Lý thuyết: counter/histogram cho RED.

• Thực hành: Metric RED cho app mẫu.

Ngày 23: Instrument - traces

• Mục tiêu: Dấu vết request.

• Lý thuyết: span xuyên service.

• Thực hành: Trace một request end-to-end.

Ngày 24: Instrument - logs

• Mục tiêu: Log có correlation.

• Lý thuyết: structured log + trace_id.

• Thực hành: Log JSON gắn trace_id.

Ngày 25: Resource attributes

• Mục tiêu: Ngữ cảnh chung.

• Lý thuyết: service.name/version/namespace, k8s attributes.

• Thực hành: Chuẩn hoá resource attributes.

Ngày 26: P1 - thiết kế

• Mục tiêu: Đóng khung P1.

• Lý thuyết: instrumentation + collector pipeline cho mọi tín hiệu.

• Thực hách: instrumentation-design.md.

Ngày 27: P1 - instrument

• Mục tiêu: App phát đủ tín hiệu.

• Lý thuyết: auto + manual kết hợp.

• Thực hành: App mẫu phát metrics/logs/traces.

Ngày 28: P1 - collector pipeline

• Mục tiêu: Thu & định tuyến.

• Lý thuyết: pipeline → backend từng tín hiệu.

• Thực hành: Collector xuất về các backend (tạm).

Ngày 29: P1 - verify

• Mục tiêu: Đảm bảo đúng.

• Lý thuyết: kiểm resource attribute + correlation cơ bản.

• Thực hành: Xác nhận trace_id nhất quán across signals.

Ngày 30: CỘT MỐC 30

• Mục tiêu: Chốt instrumentation; release P1.

• Lý thuyết: Ôn A; kiểm kê: OTel instrument + collector đủ 3 tín hiệu.

• Thực hành: P1 done; đề thi #1 (OTel/signals/RED-USE) + tự chấm; blog #71 ("OpenTelemetry: một lớp instrumentation cho mọi tín hiệu"); tag layer7-day030; nghỉ nửa ngày. Đã đi 30/180 (17%).

KHỐI B - Metrics (Ngày 31-72) → P2

Ngày 31: Loại metric

• Mục tiêu: Chọn đúng kiểu.

• Lý thuyết: counter/gauge/histogram/summary, ý nghĩa.

• Thực hành: Chọn kiểu cho các chỉ số RED/USE.

Ngày 32: Prometheus - kiến trúc

• Mục tiêu: Hệ metric chủ đạo.

• Lý thuyết: pull model, scrape, service discovery, TSDB.

• Thực hành: Dựng Prometheus scrape app mẫu.

Ngày 33: Prometheus TSDB

• Mục tiêu: Bên trong store (nối Layer 3).

• Lý thuyết: head/block, WAL, compaction, chunk.

• Thực hành: Quan sát block/WAL trên đĩa.

Ngày 34: Labels & cardinality

• Mục tiêu: Kiểm soát nổ metric.

• Lý thuyết: label = dimension, cardinality control.

• Thực hành: Tìm + giảm metric cardinality cao.

Ngày 35: PromQL - selector

• Mục tiêu: Truy vấn cơ bản.

• Lý thuyết: instant/range vector, matcher.

• Thực hành: Query cơ bản trên app mẫu.

Ngày 36: PromQL - rate

• Mục tiêu: Tốc độ thay đổi.

• Lý thuyết: rate/irate/increase, counter reset.

• Thực hành: Tính request rate + error rate.

Ngày 37: PromQL - aggregation

• Mục tiêu: Gộp theo chiều.

• Lý thuyết: sum/avg/max by/without.

• Thực hành: Aggregate theo service/endpoint.

Ngày 38: PromQL - histogram

• Mục tiêu: Latency percentile.

• Lý thuyết: histogram_quantile, bucket, native histogram.

• Thực hành: Tính p50/p95/p99 latency.

Ngày 39: PromQL - nâng cao

• Mục tiêu: Truy vấn phức tạp.

• Lý thuyết: subquery, offset, functions.

• Thực hành: Query so sánh tuần này vs tuần trước.

Ngày 40: Recording rules

• Mục tiêu: Tăng tốc & tái dùng.

• Lý thuyết: precompute, đặt tên rule.

• Thực hành: Recording rule cho RED metrics.

Ngày 41: Exporters

• Mục tiêu: Lấy metric từ hệ có sẵn.

• Lý thuyết: node_exporter/blackbox/custom exporter.

• Thực hành: node_exporter + một exporter custom.

Ngày 42: App metrics

• Mục tiêu: Metric từ code.

• Lý thuyết: client lib vs OTel metrics.

• Thực hành: Expose metric app qua OTel.

Ngày 43: Service discovery

• Mục tiêu: Scrape động (nối Layer 4).

• Lý thuyết: k8s SD, relabeling.

• Thực hành: Prometheus tự phát hiện pod scrape.

Ngày 44: k8s metrics

• Mục tiêu: Đo cluster.

• Lý thuyết: kube-state-metrics, cAdvisor.

• Thực hành: Dashboard cluster + workload.

Ngày 45: Prometheus Operator

• Mục tiêu: Vận hành khai báo (nối Layer 4).

• Lý thuyết: ServiceMonitor/PodMonitor/PrometheusRule.

• Thực hành: Cấu hình scrape qua ServiceMonitor.

Ngày 46: Alerting rules

• Mục tiêu: Phát hiện vấn đề.

• Lý thuyết: alert rule, for, labels/annotations.

• Thực hành: Alert cho error rate cao.

Ngày 47: Alertmanager

• Mục tiêu: Định tuyến báo động.

• Lý thuyết: routing tree, grouping, silence, inhibition.

• Thực hành: Route theo severity + gộp alert.

Ngày 48: Triết lý alert

• Mục tiêu: Alert đáng phản hồi.

• Lý thuyết: symptom-based, actionable, chống fatigue.

• Thực hành: Rà + xoá alert nhiễu.

Ngày 49: SLO burn-rate alert

• Mục tiêu: Cảnh báo theo error budget (SRE).

• Lý thuyết: multi-window multi-burn-rate.

• Thực hành: Cài burn-rate alert cho một SLO.

Ngày 50: Grafana

• Mục tiêu: Trực quan hoá.

• Lý thuyết: panel, variable, datasource.

• Thực hành: Dashboard đầu tiên cho app mẫu.

Ngày 51: Dashboard design

• Mục tiêu: Dashboard hữu ích.

• Lý thuyết: RED/USE layout, signal not noise.

• Thực hành: Dashboard RED cho service + USE cho node.

Ngày 52: Exemplars

• Mục tiêu: Metric → trace (correlation preview).

• Lý thuyết: exemplar gắn trace_id vào histogram.

• Thực hành: Bật exemplars; nhảy từ metric sang trace.

Ngày 53: Prometheus HA

• Mục tiêu: Không mất metric.

• Lý thuyết: replica, dedup.

• Thực hành: Chạy 2 Prometheus HA.

Ngày 54: Thanos

• Mục tiêu: Lưu trữ dài hạn.

• Lý thuyết: sidecar, store, compactor, query, object storage (nối Layer 3).

• Thực hành: Dựng Thanos trên object storage.

Ngày 55: Thanos - thành phần

• Mục tiêu: Hiểu từng phần.

• Lý thuyết: global query, downsampling, dedup.

• Thực hành: Query xuyên nhiều Prometheus qua Thanos.

Ngày 56: Mimir/Cortex

• Mục tiêu: Metric multi-tenant scale.

• Lý thuyết: horizontally scalable, multi-tenant.

• Thực hành: Đọc kiến trúc; so với Thanos.

Ngày 57: VictoriaMetrics

• Mục tiêu: Lựa chọn hiệu năng.

• Lý thuyết: compression tốt, MetricsQL, single-binary.

• Thực hành: Dựng VictoriaMetrics; đo dung lượng.

Ngày 58: So sánh hệ metric

• Mục tiêu: Chọn theo bối cảnh.

• Lý thuyết: Prometheus vs Thanos/Mimir vs VictoriaMetrics.

• Thực hành: Bảng đánh đổi.

Ngày 59: Cardinality ở quy mô

• Mục tiêu: Sống với hàng triệu series.

• Lý thuyết: limit, drop, aggregation, cardinality analyzer.

• Thực hành: Phân tích + cắt cardinality.

Ngày 60: CỘT MỐC 60

• Mục tiêu: Chốt PromQL + kiến trúc metric.

• Lý thuyết: Ôn B tới giờ; kiểm kê: Prometheus/PromQL/alert/Grafana/long-term store.

• Thực hành: Đề thi #2 (PromQL/alerting/scale) + tự chấm; blog #72 ("Prometheus & PromQL: từ scrape tới alert theo error budget"); tag layer7-day060; nghỉ nửa ngày. Đã đi 60/180 (33%).

Ngày 61: Remote writeOTLP metrics

• Mục tiêu: Đẩy metric.

• Lý thuyết: remote write, OTLP metrics ingest.

• Thực hành: Push metric qua OTLP/remote write.

Ngày 62: Pushgateway

• Mục tiêu: Metric cho batch job.

• Lý thuyết: Pushgateway, cảnh báo dùng sai.

• Thực hành: Batch job đẩy metric.

Ngày 63: Metrics cho k8s

• Mục tiêu: Đo hệ container (nối Layer 4).

• Lý thuyết: cluster/workload/HPA metrics.

• Thực hành: Dashboard k8s + custom metric cho HPA.

Ngày 64: Metrics cho mesh

• Mục tiêu: Đo mạng dịch vụ (nối Layer 4).

• Lý thuyết: Envoy/Istio telemetry, RED tự động từ mesh.

• Thực hành: Dashboard RED từ mesh.

Ngày 65: Downsampling & retention

• Mục tiêu: Cân bằng lịch sử/chi phí.

• Lý thuyết: downsampling, retention tiers.

• Thực hành: Cấu hình retention + downsample.

Ngày 66: Testing metrics

• Mục tiêu: Rule đúng.

• Lý thuyết: promtool, unit test alert/recording rule.

• Thực hành: Test rule bằng promtool.

Ngày 67: P2 - thiết kế

• Mục tiêu: Đóng khung P2.

• Lý thuyết: Prometheus + long-term + alert + dashboard.

• Thực hách: metrics-platform-design.md.

Ngày 68: P2 - scrape & exporters

• Mục tiêu: Thu metric đầy đủ.

• Lý thuyết: SD + exporters + app metrics.

• Thực hành: Prometheus scrape toàn hệ.

Ngày 69: P2 - long-term + HA

• Mục tiêu: Bền & lâu.

• Lý thuyết: Thanos/Mimir + HA.

• Thực hành: Metric lưu dài hạn, query global.

Ngày 70: P2 - alerting

• Mục tiêu: Cảnh báo tốt.

• Lý thuyết: SLO burn-rate + Alertmanager routing.

• Thực hành: Bộ alert actionable + routing.

Ngày 71: P2 - dashboards + exemplars

• Mục tiêu: Nhìn + nhảy sang trace.

• Lý thuyết: RED/USE + exemplars.

• Thực hành: Dashboard + exemplar link.

Ngày 72: P2 - Metrics platform

• Mục tiêu: Release P2.

• Lý thuyết: rà "done": scrape + store + alert + dashboard + exemplar.

• Thực hành: Đóng gói + blog #73 ("Một metrics platform production: Prometheus, Thanos, alert theo SLO"). P2 done.

KHỐI C - Logs (Ngày 73-102) → P3

Ngày 73: Logging fundamentals

• Mục tiêu: Log đúng cách.

• Lý thuyết: structured vs unstructured, khi nào log.

• Thực hành: Rà log app mẫu; chuẩn hoá.

Ngày 74: Structured logging

• Mục tiêu: Log máy đọc được.

• Lý thuyết: JSON, level, field chuẩn.

• Thực hành: Chuyển app sang structured log.

Ngày 75: Correlation IDtrace_id

• Mục tiêu: Nối log với trace.

• Lý thuyết: trace_id/span_id trong mọi log line.

• Thực hành: Đảm bảo log gắn trace_id.

Ngày 76: Log pipeline

• Mục tiêu: Từ app tới store.

• Lý thuyết: collect → parse → enrich → store.

• Thực hành: Vẽ pipeline mục tiêu.

Ngày 77: Collectors

• Mục tiêu: Thu log.

• Lý thuyết: Fluent BitFluentdVector, so sánh.

• Thực hành: Dựng collector thu log app mẫu.

Ngày 78: Vector

• Mục tiêu: Collector mạnh, linh hoạt.

• Lý thuyết: source/transform/sink, VRL.

• Thực hành: Transform + route log bằng Vector.

Ngày 79: Loki - kiến trúc

• Mục tiêu: "Prometheus cho log".

• Lý thuyết: label-based index, không index full-text.

• Thực hành: Dựng Loki; đẩy log vào.

Ngày 80: LogQL

• Mục tiêu: Truy vấn log.

• Lý thuyết: stream selector, filter, metric queries từ log.

• Thực hành: Query log + sinh metric từ log bằng LogQL.

Ngày 81: Loki - storage

• Mục tiêu: Lưu rẻ.

• Lý thuyết: chunk + object storage (nối Layer 3), index.

• Thực hành: Cấu hình object storage backend.

Ngày 82: Loki vs ELK

• Mục tiêu: Hai triết lý.

• Lý thuyết: index-everything (ELK) vs label-only (Loki), chi phí/truy vấn.

• Thực hành: Bảng đánh đổi.

Ngày 83: Elasticsearch/OpenSearch

• Mục tiêu: Full-text search log.

• Lý thuyết: inverted index (nối Layer 3), analyzer.

• Thực hành: Dựng OpenSearch; index log.

Ngày 84: OpenSearch - vận hành

• Mục tiêu: Scale & tin cậy.

• Lý thuyết: mapping, sharding, ILM.

• Thực hành: Mapping + index lifecycle.

Ngày 85: Ingest pipelines

• Mục tiêu: Xử lý trước lưu.

• Lý thuyết: Logstash/ingest pipeline, enrich.

• Thực hành: Pipeline parse + enrich log.

Ngày 86: KibanaDashboards

• Mục tiêu: Khám phá log.

• Lý thuyết: discover, visualize, saved search.

• Thực hành: Dashboard log + query.

Ngày 87: Log parsing

• Mục tiêu: Bóc trường từ log thô.

• Lý thuyết: grok, regex, structured extraction.

• Thực hành: Parse một log format phức tạp.

Ngày 88: Log-based metrics

• Mục tiêu: Metric từ log.

• Lý thuyết: count/rate từ log, khi nào nên.

• Thực hành: Sinh metric từ log (LogQL/pipeline).

Ngày 89: Retention & cost

• Mục tiêu: Log không phá ngân sách (nối Layer 11).

• Lý thuyết: tiering, hot/cold, retention policy.

• Thực hành: Cấu hình retention theo tier.

Ngày 90: CỘT MỐC 90

• Mục tiêu: Chốt logs.

• Lý thuyết: Ôn C tới giờ; kiểm kê: pipeline + Loki/OpenSearch + query.

• Thực hành: Đề thi #3 (logging/LogQL/pipeline) + tự chấm; blog #74 ("Logs ở quy mô: Loki vs ELK và một pipeline collector"); tag layer7-day090; nghỉ nửa ngày. Đã đi 90/180 (50%).

Ngày 91: PII & redaction

• Mục tiêu: Log an toàn (nối Layer 8).

• Lý thuyết: redact PII, compliance, không log secret.

• Thực hành: Redact PII ở collector.

Ngày 92: Sampling & volume control

• Mục tiêu: Giảm nhiễu/chi phí.

• Lý thuyết: log sampling, drop debug ở prod.

• Thực hành: Sample/drop log ít giá trị.

Ngày 93: Audit logs

• Mục tiêu: Log cho tuân thủ (nối Layer 4/5/8).

• Lý thuyết: audit log riêng, immutability.

• Thực hành: Tách + bảo vệ audit log.

Ngày 94: Query ở quy mô

• Mục tiêu: Debug nhanh.

• Lý thuyết: query hiệu quả, workflow từ triệu chứng.

• Thực hành: Điều tra một sự cố qua log.

Ngày 95: Alert trên log

• Mục tiêu: Phát hiện qua log.

• Lý thuyết: log-based alert, khi nào dùng thay metric.

• Thực hành: Alert khi xuất hiện pattern lỗi.

Ngày 96: k8s logging

• Mục tiêu: Log container (nối Layer 4).

• Lý thuyết: stdout, DaemonSet collector, metadata enrichment.

• Thực hành: Thu log toàn cluster + gắn metadata pod.

Ngày 97: OTel logs

• Mục tiêu: Log qua OTel.

• Lý thuyết: OTel logs pipeline, hợp nhất với trace.

• Thực hành: Đẩy log qua collector OTel.

Ngày 98: P3 - thiết kế

• Mục tiêu: Đóng khung P3.

• Lý thuyết: collector + store + query + correlation.

• Thực hách: logs-platform-design.md.

Ngày 99: P3 - collector pipeline

• Mục tiêu: Thu + xử lý log.

• Lý thuyết: Vector/Fluent Bit + parse + redact.

• Thực hành: Pipeline log hoàn chỉnh.

Ngày 100:

• Mục tiêu: Kiểm kê lớn giữa Layer 7.

• Lý thuyết: Ôn A→C; kiểm kê lớn: OTel + metrics platform (P2) + logs đang thành hình; đối chiếu "Sâu".

• Thực hành: Đề thi #4 tích lũy (instrument + metrics + logs) + tự chấm theo rubric; blog #75 ("100 ngày observability: metrics và logs hợp nhất bằng OpenTelemetry"); tag layer7-day100; nghỉ nửa ngày. Đã đi 100/180 (56%).

Ngày 101: P3 - store + query + correlation

• Mục tiêu: Log truy được & nối trace.

• Lý thuyết: Loki/OpenSearch + query + trace_id link.

• Thực hành: Từ trace nhảy sang log liên quan.

Ngày 102: P3 - Logs platform

• Mục tiêu: Release P3.

• Lý thuyết: rà "done": pipeline + store + query + redaction + correlation.

• Thực hành: Đóng gói + blog #76 ("Một logs platform với correlation tới trace"). P3 done.

KHỐI D - Tracing (Ngày 103-132) → P4

Ngày 103: Distributed tracing - nền

• Mục tiêu: Theo dấu request phân tán.

• Lý thuyết: trace = cây span, vì sao cần.

• Thực hành: Đọc một trace; nhận ra critical path.

Ngày 104: Span

• Mục tiêu: Đơn vị trace.

• Lý thuyết: attributes, events, status, links, parent/child.

• Thực hành: Thêm attribute/event vào span.

Ngày 105: Context propagation

• Mục tiêu: Nối span qua service.

• Lý thuyết: W3C Trace Context (recap), inject/extract.

• Thực hành: Propagate qua HTTP + async.

Ngày 106: OTel tracing SDK

• Mục tiêu: Sinh trace.

• Lý thuyết: tracer, span processor, exporter.

• Thực hành: Cấu hình tracer + export.

Ngày 107: Instrument traces

• Mục tiêu: Phủ trace.

• Lý thuyết: auto + manual span cho logic quan trọng.

• Thực hành: Trace đầy đủ app mẫu.

Ngày 108: Propagation across boundaries

• Mục tiêu: Không đứt trace.

• Lý thuyết: async, queue, thread pool.

• Thực hành: Giữ context qua worker/queue.

Ngày 109: Head-based sampling

• Mục tiêu: Giảm khối lượng.

• Lý thuyết: quyết định sample tại nguồn, ưu/nhược.

• Thực hành: Head sampling theo tỉ lệ.

Ngày 110: Tail-based sampling

• Mục tiêu: Giữ trace "thú vị".

• Lý thuyết: quyết định sau khi thấy cả trace (collector), giữ lỗi/latency cao.

• Thực hành: Tail sampling ở collector.

Ngày 111: Sampling strategy

• Mục tiêu: Chọn đúng.

• Lý thuyết: head vs tail, cost vs fidelity (nối Layer 11).

• Thực hành: Thiết kế chiến lược sampling.

Ngày 112: Jaeger

• Mục tiêu: Backend trace kinh điển.

• Lý thuyết: kiến trúc, storage.

• Thực hành: Dựng Jaeger; xem trace.

Ngày 113: Grafana Tempo

• Mục tiêu: Trace lưu rẻ.

• Lý thuyết: object-storage-backed, không index tốn kém.

• Thực hành: Dựng Tempo trên object storage.

Ngày 114: TraceQL

• Mục tiêu: Truy vấn trace.

• Lý thuyết: TraceQL, tìm theo attribute/latency.

• Thực hành: Tìm trace lỗi/latency cao.

Ngày 115: Span metrics

• Mục tiêu: RED từ trace.

• Lý thuyết: span metrics connector sinh RED tự động.

• Thực hành: Sinh RED từ trace.

Ngày 116: Service graph

• Mục tiêu: Bản đồ phụ thuộc.

• Lý thuyết: service graph từ trace.

• Thực hành: Vẽ service graph app mẫu.

Ngày 117: Trace analysis

• Mục tiêu: Đọc trace để tìm chậm.

• Lý thuyết: latency breakdown, critical path, N+1.

• Thực hành: Tìm nút cổ chai từ trace.

Ngày 118: Trace-based debugging

• Mục tiêu: Quy trình điều tra.

• Lý thuyết: từ trace lỗi → nguyên nhân.

• Thực hành: Debug một request chậm bằng trace.

Ngày 119: Traces cho mesh

• Mục tiêu: Trace tự động (nối Layer 4).

• Lý thuyết: Envoy/Istio tracing, propagation qua mesh.

• Thực hành: Bật tracing mesh; đọc trace.

Ngày 120: CỘT MỐC 120

• Mục tiêu: Chốt tracing nền.

• Lý thuyết: Ôn D tới giờ; kiểm kê: OTel tracing + sampling + Tempo/Jaeger + TraceQL.

• Thực hành: Đề thi #5 (tracing/sampling/TraceQL) + tự chấm; blog #77 ("Distributed tracing: từ span tới service graph, và tail sampling"); tag layer7-day120; nghỉ nửa ngày. Đã đi 120/180 (67%).

Ngày 121: Traces ↔ logs

• Mục tiêu: Correlation.

• Lý thuyết: trace_id nối log ↔ trace.

• Thực hành: Từ span nhảy sang log của span đó.

Ngày 122: Traces ↔ metrics

• Mục tiêu: Correlation.

• Lý thuyết: exemplars (metric → trace).

• Thực hành: Từ latency spike nhảy vào trace mẫu.

Ngày 123: Baggage

• Mục tiêu: Ngữ cảnh xuyên suốt.

• Lý thuyết: baggage cho cross-cutting (tenant, user).

• Thực hành: Truyền baggage; dùng để lọc.

Ngày 124: Async/messaging tracing

• Mục tiêu: Trace qua queue (nối Layer 9).

• Lý thuyết: producer/consumer span, link.

• Thực hành: Trace qua một message queue.

Ngày 125: DB/query tracing

• Mục tiêu: Thấy DB trong trace (nối Layer 3).

• Lý thuyết: span cho query, semantic conventions db.

• Thực hành: Trace một query chậm.

Ngày 126: Sampling cost vs fidelity

• Mục tiêu: Cân bằng.

• Lý thuyết: giữ đủ để debug, cắt chi phí (nối Layer 11).

• Thực hành: Tinh chỉnh tail sampling.

Ngày 127: Tail sampling config

• Mục tiêu: Cấu hình thực chiến.

• Lý thuyết: policies (latency/status/rate) trong collector.

• Thực hành: Tail sampling giữ lỗi + latency cao.

Ngày 128: P4 - thiết kế

• Mục tiêu: Đóng khung P4.

• Lý thuyết: OTel traces + collector tail sampling + Tempo.

• Thực hách: tracing-platform-design.md.

Ngày 129: P4 - traces + sampling

• Mục tiêu: Thu trace thông minh.

• Lý thuyết: instrument + tail sampling.

• Thực hành: Pipeline trace + tail sampling.

Ngày 130: P4 - store + TraceQL

• Mục tiêu: Trace truy được.

• Lý thuyết: Tempo/Jaeger + query.

• Thực hành: Lưu + query trace hiệu quả.

Ngày 131: P4 - span metrics + graph + correlation

• Mục tiêu: Trace nối tín hiệu khác.

• Lý thuyết: span metrics + service graph + trace↔log↔metric.

• Thực hành: Correlation trace↔log↔metric hoạt động.

Ngày 132: P4 - Tracing platform

• Mục tiêu: Release P4.

• Lý thuyết: rà "done": trace + sampling + store + span metrics + correlation.

• Thực hành: Đóng gói + blog #78 ("Một tracing platform với tail sampling và correlation"). P4 done.

KHỐI E - Profiling (Ngày 133-150) → P5

Ngày 133: Continuous profiling - vì sao

• Mục tiêu: Trụ thứ tư.

• Lý thuyết: profiling liên tục ở prod, tìm CPU/mem hot ở mức dòng code.

• Thực hành: So profiling vs metrics/traces trong debug hiệu năng.

Ngày 134: Profiling recap

• Mục tiêu: Nối Layer 2.

• Lý thuyết: perf, flame graph, on/off-CPU.

• Thực hành: Ôn flame graph một workload.

Ngày 135: pprof

• Mục tiêu: Profile chuẩn.

• Lý thuyết: CPU/heap/goroutine/block profile.

• Thực hành: Thu + đọc pprof một app.

Ngày 136: Flame graph & diff

• Mục tiêu: Đọc & so profile.

• Lý thuyết: flame graph, differential (trước/sau).

• Thực hành: So profile trước/sau một thay đổi.

Ngày 137: Pyroscope

• Mục tiêu: Continuous profiling backend.

• Lý thuyết: kiến trúc, storage, query.

• Thực hành: Dựng Pyroscope; profile liên tục app.

Ngày 138: Parca

• Mục tiêu: Profiling toàn hệ.

• Lý thuyết: eBPF-based, không cần instrument.

• Thực hành: Dựng Parca; profile cả node.

Ngày 139: eBPF profiling

• Mục tiêu: Chi phí thấp (nối Layer 2).

• Lý thuyết: whole-system, low overhead, no code change.

• Thực hành: Profile bằng eBPF; đo overhead.

Ngày 140: Language profilers

• Mục tiêu: Sâu theo ngôn ngữ.

• Lý thuyết: Go/Java/Python/Rust profiling đặc thù.

• Thực hành: Profile một app theo ngôn ngữ.

Ngày 141: Memory profiling

• Mục tiêu: Tìm rò rỉ.

• Lý thuyết: heap profile, leak detection.

• Thực hành: Tìm memory leak bằng profile.

Ngày 142: Off-CPU profiling

• Mục tiêu: Vì sao chờ (nối Layer 2).

• Lý thuyết: off-CPU analysis, blocking.

• Thực hành: Tìm nguyên nhân chờ.

Ngày 143: Profiling ở prod

• Mục tiêu: An toàn khi chạy thật.

• Lý thuyết: overhead budget, sampling profile.

• Thực hành: Bật continuous profiling an toàn ở prod.

Ngày 144: Profile ↔ trace

• Mục tiêu: Correlation trụ 4.

• Lý thuyết: span profiling, nối profile với span.

• Thực hành: Từ span chậm mở profile CPU của nó.

Ngày 145: Optimization workflow

• Mục tiêu: Từ profile ra cải thiện.

• Lý thuyết: profile → hotspot → tối ưu → đo lại.

• Thực hành: Một vòng tối ưu có số liệu.

Ngày 146: Profiling cho k8s

• Mục tiêu: Workload container (nối Layer 4).

• Lý thuyết: profile pod, gắn metadata.

• Thực hành: Continuous profiling toàn cluster.

Ngày 147: P5 - thiết kế

• Mục tiêu: Đóng khung P5.

• Lý thuyết: Pyroscope/Parca + eBPF + correlation.

• Thực hách: profiling-design.md.

Ngày 148: P5 - profiler

• Mục tiêu: Thu profile liên tục.

• Lý thuyết: eBPF + language profiler.

• Thực hành: Continuous profiling hoạt động.

Ngày 149: P5 - correlation + case

• Mục tiêu: Chứng minh giá trị.

• Lý thuyết: profile ↔ trace, tối ưu thật.

• Thực hành: Case tối ưu từ profile + correlation.

Ngày 150: CỘT MỐC 150

• Mục tiêu: Chốt profiling; release P5.

• Lý thuyết: Ôn E; kiểm kê: continuous profiling + eBPF + correlation profile↔trace.

• Thực hành: P5 done; đề thi #6 (profiling/eBPF/flame graph) + tự chấm; blog #79 ("Continuous profiling: trụ thứ tư và tối ưu dựa trên profile"); tag layer7-day150; nghỉ nửa ngày. Đã đi 150/180 (83%).

KHỐI F - Correlation (Ngày 151-162)

Ngày 151: Bài toán correlation

• Mục tiêu: Một sự cố, bốn tín hiệu.

• Lý thuyết: vì sao rời rạc là chậm; mục tiêu single-pane.

• Thực hành: Vẽ luồng điều tra lý tưởng.

Ngày 152: Exemplars (sâu)

• Mục tiêu: Metric → trace.

• Lý thuyết: exemplar end-to-end.

• Thực hành: Từ dashboard latency → trace cụ thể.

Ngày 153: trace_id everywhere

• Mục tiêu: Logs ↔ traces.

• Lý thuyết: trace_id trong mọi log.

• Thực hành: Nhảy hai chiều log ↔ trace.

Ngày 154: Span → profile

• Mục tiêu: Traces ↔ profiles.

• Lý thuyết: span profiling link.

• Thực hành: Từ span mở profile.

Ngày 155: Semantic conventions = keo dán

• Mục tiêu: Nhất quán mới correlate được.

• Lý thuyết: OTel semantic conventions xuyên tín hiệu.

• Thực hành: Chuẩn hoá attribute toàn hệ.

Ngày 156: Single pane

• Mục tiêu: Một nơi điều tra.

• Lý thuyết: Grafana correlations, datalinks.

• Thực hành: Cấu hình correlations nối 4 tín hiệu.

Ngày 157: Correlation-driven debugging

• Mục tiêu: Quy trình chuẩn.

• Lý thuyết: alert → metric → trace → log → profile.

• Thực hành: Đi trọn một điều tra qua 4 tín hiệu.

Ngày 158: Correlation trong incident

• Mục tiêu: Thực chiến (nối Layer 11).

• Lý thuyết: correlate nhanh dưới áp lực.

• Thực hành: Điều tra một incident mô phỏng.

Ngày 159: Data model unification

• Mục tiêu: Cùng chiều dữ liệu.

• Lý thuyết: resource attributes thống nhất mọi tín hiệu.

• Thực hành: Chuẩn resource attributes toàn stack.

Ngày 160: Sampling coherence

• Mục tiêu: Correlate được sau sampling.

• Lý thuyết: giữ nhất quán khi các tín hiệu sample khác nhau.

• Thực hành: Đảm bảo trace được sample có log/profile tương ứng.

Ngày 161: Correlation pitfalls

• Mục tiêu: Tránh sai lệch.

• Lý thuyết: clock skew, missing context, đứt propagation.

• Thực hành: Phát hiện + sửa một correlation gãy.

Ngày 162: Ôn Khối F

• Mục tiêu: Chốt correlation.

• Lý thuyết: rà exemplars/trace_id/span-profile/semantic conv.

• Thực hành: Chuẩn bị alerting & SLO.

KHỐI G - Alerting, Dashboards, SLI/SLO (Ngày 163-174)

Ngày 163: Triết lý alert (sâu)

• Mục tiêu: Alert không gây mệt.

• Lý thuyết: symptom vs cause, alert fatigue, giảm noise.

• Thực hành: Audit toàn bộ alert; cắt nhiễu.

Ngày 164: Actionable alerts

• Mục tiêu: Alert dẫn tới hành động.

• Lý thuyết: runbook link (nối Layer 6/11), severity rõ.

• Thực hành: Gắn runbook vào alert.

Ngày 165: SLI

• Mục tiêu: Chọn đúng chỉ số.

• Lý thuyết: availability/latency/quality SLI, đo từ đâu.

• Thực hành: Định nghĩa SLI cho một service.

Ngày 166: SLO

• Mục tiêu: Đặt mục tiêu.

• Lý thuyết: SLO target, window (rolling), realistic.

• Thực hành: Đặt SLO + đo tuân thủ.

Ngày 167: Error budget (giới thiệu)

• Mục tiêu: Ngân sách lỗi (policy ở Layer 11).

• Lý thuyết: error budget = 1 − SLO, ý nghĩa.

• Thực hành: Tính error budget hiện tại.

Ngày 168: Burn-rate alerting (sâu)

• Mục tiêu: Cảnh báo đúng lúc.

• Lý thuyết: multi-window multi-burn-rate (SRE workbook).

• Thực hành: Cài bộ alert burn-rate hoàn chỉnh.

Ngày 169: Dashboard principles

• Mục tiêu: Tín hiệu, không nhiễu.

• Lý thuyết: mục đích rõ, ít panel đúng chỗ.

• Thực hành: Refactor một dashboard rối.

Ngày 170: RED/USE/Golden dashboards

• Mục tiêu: Dashboard chuẩn.

• Lý thuyết: service (RED) + resource (USE) + golden signals.

• Thực hành: Bộ dashboard chuẩn cho app mẫu.

Ngày 171: Executive vs debug dashboards

• Mục tiêu: Đúng đối tượng.

• Lý thuyết: cấp cao (SLO) vs điều tra (chi tiết).

• Thực hành: Một dashboard SLO + một dashboard debug.

Ngày 172: On-call & routing

• Mục tiêu: Đúng người, đúng lúc (nối Layer 11).

• Lý thuyết: routing theo team/severity, escalation.

• Thực hành: Route alert theo ownership (nối Layer 6 catalog).

Ngày 173: Observability-driven dev

• Mục tiêu: Quan sát từ đầu.

• Lý thuyết: testing in prod, feature-flag + observ (nối Layer 6).

• Thực hành: Thêm observability vào định nghĩa "done".

Ngày 174: Ôn Khối G

• Mục tiêu: Chốt alert/SLO/dashboard.

• Lý thuyết: rà triết lý alert + SLI/SLO + dashboard.

• Thực hành: Chuẩn bị capstone.

KHỐI H - Enterprise Observability Platform capstone (Ngày 175-180) → P6 flagship

Ngày 175: P6 - tích hợp 4 tín hiệu

• Mục tiêu: Một platform, đủ tín hiệu.

• Lý thuyết: metrics (P2) + logs (P3) + traces (P4) + profiles (P5).

• Thực hành: Ghép 4 platform vào một stack.

Ngày 176: P6 - correlation

• Mục tiêu: Nối mọi thứ.

• Lý thuyết: exemplars + trace_id + span profiles + single pane.

• Thực hành: Correlation 4 tín hiệu hoạt động end-to-end.

Ngày 177: P6 - SLO + alerting + dashboards

• Mục tiêu: Vận hành được.

• Lý thuyết: SLO + burn-rate alert + bộ dashboard.

• Thực hành: SLO dashboard + alert cho app mẫu.

Ngày 178: P6 - multi-tenant + cost + retention

• Mục tiêu: Dùng chung, bền vững (nối Layer 11).

• Lý thuyết: multi-tenant, cost control, retention theo tín hiệu.

• Thực hành: Cấu hình tenancy + retention + cost guardrail.

Ngày 179: P6 - incident drill; ôn Layer 7

• Mục tiêu: Chứng minh giá trị.

• Lý thuyết: alert → correlate 4 tín hiệu → nguyên nhân gốc.

• Thực hành: Game-day: gieo lỗi → điều tra tới root cause; rà toàn layer.

Ngày 180: HOÀN THÀNH LAYER 7

• Mục tiêu: Chốt Observability Engineering ở mức Sâu.

• Lý thuyết: Ôn toàn layer; kiểm kê tổng: OTel (P1) + metrics (P2) + logs (P3) + traces (P4) + profiling (P5) + Enterprise Observability Platform tích hợp + correlation (P6).

• Thực hành: P6 done; đề thi #7 tích lũy (toàn layer) + tự chấm theo rubric; blog #80 ("Nhìn lại 180 ngày observability: bốn tín hiệu và correlation trong một platform"); tag layer7-complete; nghỉ nửa ngày.