title: "Chương 1: Phân cấp tài nguyên & tổ chức trên GCP" description: "Cẩm nang đầy đủ về quản lý tài nguyên GCP, phân cấp, chính sách và các mô hình triển khai production" date: "2026-06-01"
Chương 1: Phân cấp tài nguyên & tổ chức trên GCP
Để quản lý thành công 1000+ tài nguyên trên 100+ dự án cần hiểu sâu cấu trúc tổ chức của GCP.
Chương này bao quát nền tảng của mọi triển khai GCP: từ cách tổ chức tài nguyên, xác thực dịch vụ, phân bổ chi phí cho tới áp đặt chính sách.
Lộ trình học
Khuyến nghị theo thứ tự sau (nhưng có thể bỏ qua các chủ đề đã quen thuộc):
Nền tảng (Bắt buộc hiểu)
- Nền tảng phân cấp tài nguyên - Phân cấp 4 tầng (Org→Folder→Project→Resource), mô hình kế thừa, blast radius
- API Resource Manager - Quản lý tài nguyên qua API, tính nhất quán cuối cùng, mẫu retry
- Đặt tên & tự động hóa dự án - Ràng buộc Project ID, soft-delete, quy ước đặt tên
Truy cập & bảo mật (Bắt buộc)
- Lan truyền chính sách IAM - Lan truyền ba lớp, chiến lược kiểm thử, thời gian áp dụng
- Phạm vi service account - Khóa so với token, impersonation, workload identity
Tổ chức & siêu dữ liệu (Rất khuyến nghị)
- Labels, Tags & tổ chức - Chiến lược metadata, phân bổ chi phí, chính sách có điều kiện
- Cloud Asset Inventory - Truy vấn trạng thái tài nguyên, kiểm toán tuân thủ, phát hiện lệch cấu hình
- Organization Policies - Ép buộc ràng buộc, kế thừa, ràng buộc tùy chỉnh
Vận hành (Khuyến nghị)
- Quản lý quota - Quota theo tốc độ/phân bổ/đồng thời, xử lý khi cạn
- Bảo vệ tài nguyên - Khóa, soft-delete, ngăn xóa nhầm
- Phân cấp thanh toán - Gán chi phí, chargeback, cảnh báo ngân sách
Mạng (Cho đội ops/platform)
- Mô hình Shared VPC - Quản lý mạng tập trung, kết nối liên dự án
Theo trường hợp sử dụng
Tôi là kỹ sư backend xây dựng dịch vụ
→ Read: 01, 02, 04, 05, 06, 10
Tôi là kỹ sư platform quản lý hạ tầng
→ Read: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12
Tôi làm ops/SRE
→ Read: 01, 04, 07, 08, 09, 11
Tôi làm DevOps/tự động hóa hạ tầng
→ Read: 02, 03, 05, 06, 08, 09, 11
Tôi xây dựng giải pháp tuân thủ/bảo mật
→ Read: 04, 06, 07, 08, 12
Khái niệm chính trong chương
Phân cấp & kế thừa
Tài nguyên được tổ chức theo phân cấp 4 tầng (Org→Folder→Project→Resource). Chính sách kế thừa đi xuống (Org → Project) nhưng không đi ngược lên trên.
Quan trọng: Chính sách ở tầng thấp hơn không thể ghi đè chính sách deny ở tầng cao hơn.
Tính nhất quán cuối cùng
GCP là hệ thống phân tán. Việc tạo/cập nhật tài nguyên cần 5-60 giây để lan truyền:
- T+0: Instant (control plane)
- T+5-30s: Cập nhật lớp cache
- T+5-60s: Các dịch vụ xác nhận thay đổi
Hệ quả: Tự động hóa phải retry, không được giả định tính nhất quán tức thì.
Quản lý blast radius
Phân cấp giúp giới hạn blast radius: xóa một project không ảnh hưởng project khác. Chính sách dùng chung áp dụng trên nhiều project → cần ép buộc cẩn thận.
Chiến lược metadata
Ba hệ thống song song theo dõi tài nguyên:
- Labels (theo từng tài nguyên, có thể truy vấn, phân bổ chi phí)
- Tags (theo phân cấp, hiểu IAM, ép buộc chính sách)
- Network Tags (cũ, chỉ dùng cho firewall)
Kết hợp hiệu quả → tổ chức mạnh và tuân thủ tốt.
Gán chi phí
Labels đúng cách + xuất billing → theo dõi chi phí chính xác theo team/service/environment.
Mô hình production
Mẫu 1: Hạ tầng bất biến
Project-A:
- VM được tạo bằng Terraform
- Terraform quản lý mọi thay đổi
- Phát hiện và từ chối chỉnh sửa thủ công
Lợi ích: Lặp lại được, kiểm toán được, phát hiện drift đượcMẫu 2: Bảo mật theo tầng
Production: Chính sách nghiêm ngặt (CMEK, OS Login, không có external IP)
Staging: Chính sách vừa phải (mã hóa tùy chọn)
Dev: Chính sách tối thiểu (cho phép thử nghiệm)
Triển khai qua: Tags → Organization Policies có điều kiệnMẫu 3: Quản trị chi phí
1. Bắt buộc gắn labels khi tạo
2. Labels có cost-center
3. Báo cáo BigQuery hàng tháng
4. Chargeback cho các team
5. Cảnh báo khi vượt ngân sách
Kết quả: Các team tự chịu trách nhiệm chi phí của mìnhCác anti-pattern cần tránh
❌ Một project khổng lồ chứa mọi thứ
→ Blast radius quá lớn, khó quản lý quota
❌ Labels không nhất quán
→ Không thể truy vấn tài nguyên, theo dõi chi phí thất bại
❌ Gán role Owner cho engineer
→ Không thể ngăn các hành động phá hoại
❌ `terraform destroy` không có biện pháp bảo vệ
→ Tài nguyên production bị xóa nhầm
❌ Không có backup
→ Mất dữ liệu là vĩnh viễn
❌ Service account có khóa trên máy
→ Khóa có thể bị đánh cắp, khó xoay vòng
❌ Không có organization policies
→ Các team làm việc không an toàn (external IP, mã hóa yếu)Tiếp theo
Sau khi nắm vững Chương 1:
- Chương 2: Đi sâu vào VPC & Networking
- Chương 3: Kubernetes (GKE) ở quy mô lớn
- Chương 4: Mẫu thiết kế data engineering
- Chương 5: Khôi phục sau thảm họa & tính sẵn sàng
Tham khảo nhanh
Lệnh
# Điều hướng phân cấp
gcloud projects list
gcloud resource-manager folders list
gcloud resource-manager org-policies list
# Thao tác service account
gcloud iam service-accounts create NAME
gcloud iam service-accounts add-iam-policy-binding [email protected]
# Thanh toán
gcloud billing accounts list
gcloud billing projects link PROJECT_ID --billing-account=ID
# Kiểm kê tài nguyên
gcloud asset search-all-resources --scope=organizations/ORG_ID
# Quota
gcloud compute project-info describe --project=PROJECT_IDTerraform
# Tạo project
resource "google_project" "example" {
name = "My Project"
project_id = "my-project-123"
org_id = "123456789"
folder_id = "123456789"
}
# Service account
resource "google_service_account" "example" {
account_id = "my-sa"
project = google_project.example.project_id
}
# IAM binding
resource "google_project_iam_member" "example" {
project = google_project.example.project_id
role = "roles/compute.admin"
member = "serviceAccount:${google_service_account.example.email}"
}
# Labels on resources
resource "google_compute_instance" "example" {
labels = {
environment = "production"
team = "backend"
}
}Thông tin tài liệu
- Cập nhật lần cuối: 2026-06-01
- Phiên bản GCP Docs: Dựa trên tài liệu chính thức lấy ngày 2026-05-15
- Language: Vietnamese (Tiếng Việt)
- Đối tượng: Kỹ sư senior, team platform, chuyên gia hạ tầng
- Tổng nội dung: 12 file, ~42.000 từ, tập trung vào production