Nguyen Nhat Minh

Pod Lifecycle & Scheduling

Luồng schedule một Pod

• API Server: nhận request, validate theo schema + admission controllers (ResourceQuota, MutatingWebhook, PodSecurity).
• etcd: persist Pod object với nodeName="" (chưa được schedule).
• Scheduler: watch các Pod chưa có nodeName, chạy 2 pha — Filter (loại node không đủ resource, không match taint/affinity/nodeSelector) và Score (chấm điểm node còn lại: least-allocated, image-locality), rồi Bind node điểm cao nhất.
• Kubelet: trên node đích, gọi CRI pull image, tạo container, attach volume, setup network qua CNI plugin.
• Probe: startup → liveness → readiness pass → endpoint controller add Pod IP vào Service.

Điểm cộng khi nói: nhắc topologySpreadConstraints cho HA và preemption theo priority khi node full.

AKS Networking — CNI Modes

Talking point thực tế: nhiều cluster trong cùng VNet thì Azure CNI truyền thống cạn IP rất nhanh — chọn Overlay để giữ pod IP space riêng, chỉ node mới consume IP VNet.

Autoscaling — HPA / VPA / Cluster Autoscaler / KEDA

• HPA: scale số replica theo CPU/memory hoặc custom metric (qua Prometheus Adapter). Cốt lõi cho web e-commerce co giãn theo tải.
• VPA: đề xuất/điều chỉnh request & limit. Không combine HPA + VPA trên cùng metric — sẽ conflict.
• Cluster Autoscaler: add/remove node khi pod pending. Trên AKS dùng built-in (không phải Karpenter — đó là AWS). Tune scale-down-unneeded-time, scale-down-delay-after-add.
• KEDA: event-driven autoscaling — scale theo độ dài queue (Service Bus, Storage Queue), Kafka lag, hay custom metric. Cực hợp với e-commerce: scale worker theo số order tồn trong queue, scale-to-zero khi rảnh để tiết kiệm chi phí.

Pattern spike e-commerce (flash sale)

• Pre-scale theo lịch (cron HPA / scheduled scaling) trước giờ sale, không đợi metric mới phản ứng.
• Overprovision pod "pause" priority thấp để giữ node ấm → pod thật schedule tức thì, không chờ node mới boot.
• Tách node pool theo workload (system / app / batch) để autoscale độc lập.

Security & Identity — chuẩn banking/finance

• Workload Identity (federated, prefer): pod lấy Azure AD token qua OIDC, không cần secret trong cluster. Thay thế Pod Identity (legacy) — không cần NMI/MIC, scale tốt hơn.
• Secrets: Azure Key Vault + Secrets Store CSI Driver mount secret vào pod; bật auto-rotation. Không để secret plaintext trong manifest/Git.
• RBAC + AAD integration: AKS-managed Azure AD, gán quyền theo AAD group; least-privilege namespace-scoped Role thay vì cluster-admin.
• Private cluster: API server private endpoint, không expose ra internet — bắt buộc với banking. Truy cập qua jumpbox/VPN/Bastion.
• Azure Policy for AKS (Gatekeeper/OPA): enforce không cho privileged container, bắt buộc resource limits, chỉ pull image từ ACR tin cậy, deny hostPath.
• Defender for Containers: runtime threat detection, scan image vulnerability trong ACR.

AKS Upgrade & Day-2 Operations

• Control plane vs node pool: upgrade control plane trước, node pool sau; giữ skew ≤ 2 minor version.
• Surge upgrade: max-surge để tạo node mới trước khi cordon/drain node cũ → zero-downtime. Cặp với PDB hợp lý.
• Blue-green node pool: tạo node pool mới version mới, cordon pool cũ, drain dần, quan sát rồi xóa pool cũ — an toàn cho Prod banking.
• Compatibility audit: quét deprecated API trước upgrade (kubent / kubectl deprecations), check Helm chart không dùng API sắp bỏ.
• Maintenance window & auto-upgrade channel: đặt window, dùng channel (patch/stable) để tự vá security, nhưng Prod thì controlled.

Multi-tenancy & Isolation

Banking/finance thường cần tách biệt mạnh giữa team/môi trường/khách hàng:

Quota + LimitRange chống một tenant ăn hết resource; PriorityClass bảo vệ workload critical (payment) khi node pressure.

Chọn đúng controller cho từng loại workload

Talking points hay bị hỏi

• Vì sao DB dùng StatefulSet chứ không Deployment? StatefulSet cho stable identity (pod-0, pod-1) + PVC gắn cố định từng pod — quan trọng cho replication/clustering. Deployment thì pod và volume đều vô danh.
• headless Service (clusterIP: None) đi kèm StatefulSet để mỗi pod có DNS riêng.
• concurrencyPolicy của CronJob: Forbid tránh job chồng nhau khi job trước chưa xong.
• init container cho setup trước khi app start (wait-for-db, migration nhẹ).

Mô hình PV / PVC / StorageClass

• PersistentVolume (PV): tài nguyên storage thực (Azure Disk/File/Blob), do admin hoặc dynamic provisioner tạo.
• PersistentVolumeClaim (PVC): yêu cầu storage của app (dung lượng + accessMode). Pod mount PVC, không mount PV trực tiếp.
• StorageClass: định nghĩa cách dynamic provision (loại disk, SKU, reclaimPolicy, binding mode).

Access Modes

Vì sao GitOps?

Ở project Automobile (NTT DATA) em chuyển continuous delivery sang mô hình GitOps với Argo CD. Git là single source of truth: state mong muốn của cluster nằm hết trong repo, Argo CD reconcile liên tục để cluster khớp với Git.

Lợi ích thực tế

• Auditability: mọi thay đổi đi qua PR → có review, có history, rollback = git revert.
• Drift detection: ai đó sửa tay trên cluster (kubectl edit) → Argo CD báo OutOfSync và tự heal về state trong Git.
• Tách deploy khỏi CI: pipeline chỉ build image + push, không cần quyền write thẳng vào cluster → giảm blast radius về security.

Pattern hay dùng

• App of Apps: một root Application quản nhiều child Application → onboard env/team mới chỉ bằng cách thêm manifest.
• Sync waves & hooks: điều khiển thứ tự apply (CRD trước, workload sau; migration job chạy như PreSync hook).
• Progressive delivery: kết hợp Argo Rollouts cho canary/blue-green theo % traffic, quan sát metric rồi promote/rollback.

Cilium (eBPF) — vì sao team modern chọn

• Network policy ở kernel level (eBPF) thay vì iptables → latency thấp hơn đáng kể, scale tốt khi số pod/rule lớn.
• Identity-based policy: match theo pod label/identity thay vì IP → policy ổn định khi pod restart đổi IP.
• Hubble: observability L3/L4/L7 không cần sidecar — thấy được flow giữa service, drop do policy, DNS, HTTP.
• Default deny: bắt đầu bằng deny-all rồi whitelist explicit, đúng tinh thần zero-trust trong cluster.

Gateway API — thế hệ sau Ingress

Ở project Automobile em dùng Gateway API cho traffic routing thay cho Ingress truyền thống. Lý do:

Điểm hay khi vận hành: infra team own Gateway (TLS, listener, IP), app team chỉ tự quản HTTPRoute của mình → giảm va chạm quyền, đúng mô hình multi-team trên cùng cluster.

Cách em tổ chức Terraform

• Remote state: Azure Storage backend + state locking (blob lease) để tránh 2 người apply đè nhau.
• Module hóa: tách module tái dùng (network, aks, keyvault) → env Dev/UAT/Prod chỉ khác file tfvars, không copy-paste code.
• Workspace/folder per env: mỗi env một state riêng → nổ Dev không đụng Prod.
• Plan trong CI: terraform plan chạy tự động trên PR, output plan để review trước khi apply sau merge.

Ví dụ provision AKS (rút gọn)

module "aks" {
  source              = "../../modules/aks"
  cluster_name        = var.cluster_name
  kubernetes_version  = "1.30"
  network_plugin      = "azure"
  network_plugin_mode = "overlay"   # CNI Overlay tiết kiệm IP
  default_node_pool   = {
    name       = "system"
    vm_size    = "Standard_D4s_v5"
    min_count  = 3
    max_count  = 10
    enable_auto_scaling = true
  }
}

Triết lý pipeline

Em xây pipeline ở Azure DevOps qua nhiều project. Mô hình em theo là tách rõ CI (build + test + push image) khỏi CD (deploy), đặc biệt khi cluster dùng GitOps.

Các stage chuẩn

• Build: multi-stage Dockerfile, layer cache, build image immutable theo commit SHA (không dùng latest).
• Test: unit + lint + scan image (Trivy) + scan IaC (tfsec/checkov) — fail sớm tại đây.
• Push: đẩy image lên ACR, sign/tag theo SHA.
• Deploy: CD không kubectl apply thẳng; thay vào đó cập nhật image tag trong config repo → Argo CD reconcile.

Observability stack

Quan điểm của em: alert phải có context, không phải alert nhiều. Mỗi alert nên trả lời được 3 câu — cái gì hỏng, ở đâu, nghi ngờ nguyên nhân gì.

Bốn golden signals

• Latency: đo theo percentile (p95/p99), không xài average vì average giấu outlier.
• Traffic: request/s, throughput.
• Errors: tỉ lệ lỗi, phân loại 4xx vs 5xx.
• Saturation: mức bão hòa resource (CPU, mem, queue depth).

Disaster Recovery (Healthcare, SLA 99.9%)

• PowerShell scripts: snapshot, replicate cross-region, failover validation, automated smoke test.
• Runbook cho từng scenario: region down, DB corruption, cert expiry, account lockout.
• Vendor escalation playbook (Microsoft Premier support flow).
• Báo cáo DR drill tự động gửi stakeholder hàng tháng.

Kết quả: 12 tháng liên tục đạt SLA 99.9%, recovery time giảm 40%, audit pass clean. Bài học: DR không phải plan trên giấy — phải drill thật, đo thật.

Cost Optimization Landing Zone

• Cost Analysis breakdown theo subscription / resource type / tag → tìm top spender: orphan disk, idle VM, oversized gateway.
• Network/firewall review: gộp rule thừa, tắt logging double-cost (FW → Storage → Log Analytics).
• Reserved Instance cho workload ổn định.
• Knowledge transfer: workshop + cost dashboard để team khách tự giữ discipline.

Kết quả: ở project Vietnam Customer, tối ưu chi phí hạ tầng 35% qua phân bổ resource hợp lý; ở engagement landing zone, monthly Azure spend giảm 15%. Bài học: dashboard + alert tự động bền hơn cleanup một lần.

BCDR là gì — và khác DR chỗ nào

BCDR ghép hai mảng: Business Continuity (BCP) — làm sao doanh nghiệp vẫn hoạt động khi có sự cố (con người, quy trình, communication), và Disaster Recovery (DR) — phần kỹ thuật khôi phục hệ thống/dữ liệu sau thảm họa.

Dễ hiểu: DR lo “làm sao bật lại server và data”, BCP lo “làm sao business vẫn phục vụ khách trong lúc đó”. Một DR plan tốt mà thiếu BCP thì kỹ thuật sống nhưng vận hành vẫn loạn.

4 chiến lược DR — từ rẻ tới đắt

Talking point: chọn tier theo RTO/RPO + ngân sách. Banking core thường Warm Standby hoặc Active-Active; hệ thống nội bộ ít quan trọng thì Backup & Restore là đủ.

Azure BCDR toolkit

• Azure Site Recovery (ASR): replicate VM/workload sang region khác, orchestrate failover có recovery plan (thứ tự boot, script trước/sau). Hỗ trợ test failover không đụng production.
• Azure Backup: backup VM, disk, SQL, File Share; giữ recovery point theo policy; bật soft delete + immutable vault chống ransomware/xóa nhầm.
• Storage redundancy: LRS (1 datacenter) → ZRS (cross-zone) → GRS/GZRS (cross-region) — chọn theo yêu cầu RPO.
• Front Door / Traffic Manager: điều hướng traffic sang region khỏe khi region chính chết — health probe + priority/weighted routing.
• DB: Azure SQL active geo-replication / failover group; Cosmos DB multi-region write cho RPO gần 0.
• AKS: cluster ở 2 region, manifest trong Git (Argo CD) để dựng lại nhanh; data layer dựa vào DB/storage replication chứ không dựa vào cluster.

Incident response — cách em xử lý

Lifecycle một sự cố

Python / Bash / PowerShell — dùng đúng chỗ

• Python: automation phức tạp — data transfer sang ERP, gọi API, xử lý JSON/CSV, glue logic. Đây là ngôn ngữ chính em viết script transfer dữ liệu ở project Integration (Singapore/Malaysia/Australia).
• Bash: glue trong CI/CD, Dockerfile entrypoint, k8s init container, thao tác file/log nhanh trên Linux.
• PowerShell: automation trên Azure/Windows — DR runbook (snapshot, replicate, failover validation), quản Active Directory, smoke test sau failover.

Ví dụ — Bash an toàn cho automation

#!/usr/bin/env bash
set -euo pipefail

RESOURCE_GROUP="${1:?need resource group}"
log(){ echo "[$(date -u +%FT%TZ)] $*"; }

log "Snapshotting disks in ${RESOURCE_GROUP}..."
for disk in $(az disk list -g "$RESOURCE_GROUP" --query "[].name" -o tsv); do
  az snapshot create -g "$RESOURCE_GROUP" \
    --name "${disk}-$(date -u +%Y%m%d)" \
    --source "$disk" --only-show-errors
  log "snapshot done: $disk"
done

Thói quen: biến bắt buộc dùng ${VAR:?} để fail sớm nếu thiếu tham số, log có timestamp UTC, quản lỗi bằng set -euo pipefail.

Tell me about yourself

Dùng Self-Pitch ở trên: 8+ năm, IT support → Cloud → DevOps/Architect, mạnh AKS/GitOps/Terraform, có con số (cost -35%, breach -40%, troubleshoot -70%), làm đa vùng.

Conflict với team thì sao?

STAR ngắn: tình huống bất đồng về approach → tập trung vào data/tradeoff thay vì quan điểm cá nhân → thống nhất tiêu chí (cost, risk, time) → chọn giải pháp đo được. Kết: quyết định dựa trên bằng chứng, quan hệ vẫn tốt.

Một lần thất bại?

Chọn lỗi thật nhưng đã fix + học được (vd PDB minAvailable=100% làm drain kẹt) → nhấn mạnh bài học và guardrail thêm sau đó.

Cuối buổi, hỏi ngược để thể hiện mình quan tâm đúng chỗ:

• Team đang ở đâu trên hành trình GitOps / platform engineering? Có internal developer platform chưa?
• On-call setup thế nào — rotation, escalation, có tôn trọng error budget không?
• Quyết định kỹ thuật do team tự quyết hay top-down? Tech debt được ưu tiên ra sao?
• Thách thức lớn nhất của platform trong 6-12 tháng tới là gì?
• Thành công của vị trí này được đo bằng gì sau 3-6 tháng?

Trước phỏng vấn

• Ôn lại 5 STAR stories, nhớ con số (35% / 40% / 70% / 99.9%)
• Nắm Self-Pitch dưới 60 giây
• Ôn AKS deep-dive: pod lifecycle, CNI, storage, upgrade, autoscaling
• Ôn GitOps / Argo CD, Terraform, CI/CD flow
• Chuẩn bị 3-5 câu hỏi ngược
• Research công ty + JD, map kinh nghiệm vào requirement

Kỹ năng trả lời

• Dùng STAR cho câu behavioral
• Nói tradeoff, không nói tuyệt đối (“tùy context”)
• Thành thật khi không biết, nói cách sẽ tìm ra
• Gắn câu trả lời với impact thực tế

Khung trả lời một bài system design

Khi nào cần service mesh — và khi nào không

Mesh giải quyết 3 bài ở tầng hạ tầng (không đụng code app): traffic management (canary, retry, timeout), security (mTLS, authz service-to-service), và observability (golden metrics, distributed trace tự động).

Senior framing: mesh không miễn phí — thêm sidecar = thêm latency, RAM, và độ phức tạp vận hành. Microservice ít thì library (Resilience4j) hoặc Gateway API là đủ. Mesh đáng dùng khi có nhiều service, cần zero-trust mTLS toàn mạng, hoặc progressive delivery chuẩn hóa.

Shift-left security — bảo mật từ lúc code

• Scan image (Trivy/Grype): chạy trong CI, fail build khi có CVE HIGH/CRITICAL chưa có fix — đừng block khi chưa có patch.
• Scan IaC (Checkov/tfsec): phát hiện misconfiguration Terraform/Helm trước khi apply.
• SBOM (Software Bill of Materials): liệt kê toàn bộ dependency trong image; bắt buộc trong nhiều regulated industry.
• Image signing (Cosign/Notation): ký image sau build, Gatekeeper chỉ cho deploy image đã ký từ registry tin cậy.
• Supply chain (SLSA): provenance — biết image đến từ đâu, ai build, từ source nào — chống tampering.
• Runtime (Defender for Containers / Falco): detect anomaly trong runtime (exec ở container không được phép, privilege escalation).

Một số bài hay bị hỏi ở tầm senior

Các khái niệm nền tảng hay bị hỏi

• CAP theorem: distributed system chỉ đảm bảo được 2/3: Consistency, Availability, Partition tolerance. Khi có network partition buộc phải chọn CP (SQL) hay AP (Cassandra, Cosmos).
• Eventual consistency: replica đồng bộ theo giờ, read có thể stale — chấp nhận được cho cart, feed; không được cho balance/payment.
• Idempotency: retry an toàn vì result không thay đổi — bắt buộc cho payment API, queue consumer.
• Distributed lock: Redis SETNX + TTL hoặc Lease — cẩn thận GC pause có thể expire lock sớm.
• Saga pattern: long-running transaction qua nhiều service — choreography (event) hay orchestration (saga coordinator); rollback bằng compensating transaction.
• Outbox pattern: viết DB + publish event trong 1 transaction (to outbox table), polling relay đẩy ra queue — đảm bảo at-least-once, không mất event.

Internal Developer Platform (IDP)

Platform engineering là xây dựng “sản phẩm nội bộ” cho developer — thay vì từng team tự setup CI/CD, Terraform, observability từ đầu. Mục tiêu: giảm cognitive load cho dev, chuẩn hóa golden path.

• Self-service portal (Backstage): dev click là ra repo + pipeline + cluster namespace + monitoring, không cần đợi ops.
• Golden path template: Helm chart chuẩn, Dockerfile bảo mật, pipeline template — team follow thì tự được best practice.
• Platform team là product team: đo NPS, lead time, DORA metrics — không chỉ support ticket.

Senior không chỉ làm giỏi — phải nhân rộng được

• Technical mentoring: pair programming, code/IaC review có giải thích “vi sao” thay vì chỉ sửa; viết decision record (ADR) để team sau hiểu context.
• Runbook & documentation: kiến thức trong đầu không scale — em ưu tiên viết runbook rõ để junior on-call tự xử lý được mà không ping senior.
• Blameless culture: postmortem tập trung vào system failure, không đổ lỗi người — tạo môi trường tự báo lỗi sớm.
• Leading without authority: ở cross-functional project, em dẫn dắt bằng sự chuẩn bị kỹ, đặt câu hỏi đúng, và proposal có data — không phải bằng title.
• Delegation: biết việc nào nên giao (ownership rõ, guardrail sẵn), việc nào phải đứng ra — tránh bỏ nhiệm hoặc ôm hết.

AIOps là gì — và giải quyết bài nào

AIOps (AI for IT Operations) dùng ML + big data để xử lý khối lượng tín hiệu khổng lồ (log, metric, trace, event) mà con người không đọc xuể. Mục tiêu: giảm alert fatigue, phát hiện sớm bất thường, tăng tốc tìm root cause, và tiến tới tự động xử lý.

Quan điểm senior: AIOps không thay thế SRE — nó lọc nhiễu để con người tập trung vào việc khó. Theo hướng "AI gợi ý, người quyết định" cho tới khi đủ tin cậy mới mở auto-remediation.