Lộ trình
Microsoft AzureCơ bảnTuần 4: Tối ưu & vận hànhBài 25 / 30

Ngày 25: Support Plans

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
az-900ngày 25
hoàn thành25 / 30 bài
Bối cảnh bài học

Chọn support plan Azure theo severity, scope, response expectation, technical depth và business impact; phân biệt support với Status/Service Health.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Chọn support plan Azure theo severity, scope, response expectation, technical depth và business impact; phân biệt support với Status/Service Health.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • So sánh các gói hỗ trợ Basic, Developer, Standard, Professional Direct
  • Tìm hiểu Azure Status page
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Một outage production bị gửi sai kênh billing, team chờ support plan trả lời như SLA và không biết Azure Status khác Service Health. Bài học tạo support decision tree và incident handoff có evidence.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • Support plan tiers/features/pricing có thể thay đổi; phải kiểm tra trang chính thức hiện hành trước purchase.
  • Basic/Developer/Standard/Professional Direct (theo roadmap) khác target, response/technical support và business guidance; không học bằng một bảng giá bất biến.
  • Azure Status là public status view; Service Health cá nhân hóa theo subscription/resource; support ticket là channel cho case cần provider assistance.
  • Severity phải phản ánh business impact, affected resource, region, symptoms, timeline và mitigation, không chỉ cảm xúc.

Support là một phần operating model

Khi có incident, trước hết xác định đây là public Azure incident, subscription-specific health issue, resource/configuration fault, quota/access hay billing question. Dùng Status/Service Health để tìm provider signal; dùng logs/metrics/runbook để triage; mở support case với evidence đủ.

Support plan tiers và response/features có thể thay đổi. Đọc trang chính thức hiện hành, ghi date/assumption và chọn theo business impact, technical depth, response expectation và budget. Không mua plan để thay architecture hoặc on-call.

Case template

impact → affected scope/resource/region → UTC timeline → symptoms/error/correlation → recent change → mitigation → evidence → question. Redact credentials/PII. Severity phải dựa impact và urgency.

Bài tập

Viết decision tree và hai mock support cases: production API outage, billing discrepancy. Chọn kênh, severity, evidence và expected next action.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
az account show --output table
az account list --output table
az group list --output table
Hands-on lab

Thực hành theo scenario

  1. Tạo decision tree: public incident → Status/Service Health; resource-specific issue → diagnostics/support ticket; billing/quota/access → đúng support channel.
  2. Lập support case template: subscription/resource ID (redacted), region, start time UTC, impact, error, correlation ID, changes, mitigation và desired outcome.
  3. So sánh support plan theo use case startup/sandbox/production/regulatory, ghi current-source check/date và assumption.
  4. Không tạo ticket thật hoặc đưa subscription/PII vào repo; dùng incident giả lập và status page public.
Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Phân biệt Status/Service Health/support ticket.
  • Support plan decision có business impact/severity.
  • Case template đủ evidence nhưng không lộ secret.
  • Không coi support response là SLA availability.
  • Kiểm tra feature/price từ nguồn hiện hành.
Transfer to exam / production

Bẫy thường gặp và trade-off

Azure Status là public; Service Health gắn subscription/resource; support plan cung cấp kênh/technical assistance. Những thứ này không thay resilience hay monitoring.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Team muốn biết một Azure incident có ảnh hưởng đến subscription/resource cụ thể của mình hay không. Kênh nào phù hợp nhất?

Kết thúc bài

Checklist trước khi sang Ngày 2