Ngân hàng đề — Google Cloud Digital Leader

Đáp án

B — Đội thứ nhất: Cloud Run; đội thứ hai: App Engine Standard.

Vì sao đúng

Hai đội có hai điểm xuất phát khác nhau, và đó chính là thứ quyết định.

⚠ Đội 1 — đã có container:

"Sản phẩm triển khai là một IMAGE
 DOCKER dựng sẵn, không trạng thái"
"nền tảng có quản lý, CO VỀ 0"
        ↓
    ⚠ CLOUD RUN
    → chạy bất kỳ container nào
    → co về 0
    → trả theo request

⚠ Đội 2 — muốn triển khai từ MÃ NGUỒN:

"ứng dụng viết bằng Go"
"⚠ triển khai TRỰC TIẾP TỪ MÃ NGUỒN,
  KHÔNG tự dựng container"
        ↓
    ⚠ APP ENGINE STANDARD
    → `gcloud app deploy`
    → Google tự dựng và chạy
    → Go là runtime được hỗ trợ
    → co về 0

⚠ Cả hai đều serverless, khác ở đầu vào:

CLOUD RUN
    đầu vào: ⚠ IMAGE CONTAINER
    (cũng nhận mã nguồn qua
     `gcloud run deploy --source`,
     nhưng bản chất vẫn dựng
     container bằng Buildpacks)

APP ENGINE STANDARD
    đầu vào: ⚠ MÃ NGUỒN + app.yaml
    (runtime giới hạn: Python, Java,
     Go, Node.js, PHP, Ruby)

⚠ Vì sao ba phương án kia sai:

A. GKE + Compute Engine
    → ⚠ CẢ HAI đều KHÔNG co về 0
    → cụm và VM luôn tính tiền

C. Cloud Run Functions + Cloud Run
    → ⚠ Functions dành cho HÀM nhỏ
      theo sự kiện, không phải
      dịch vụ web đóng gói container

D. App Engine Standard + Cloud Run
    → ⚠ ĐẢO NGƯỢC hai đội

Vì sao các phương án khác sai

• D (App Engine Standard rồi Cloud Run) — phương án gần nhất: đúng hai sản phẩm nhưng đảo thứ tự. Đội có sẵn container nên đi Cloud Run; đội muốn đẩy mã nguồn nên đi App Engine.

• A (GKE và Compute Engine) — cả hai đều không co về 0, trái yêu cầu.

• C (Cloud Run Functions và Cloud Run) — Functions dành cho hàm đơn nhiệm theo sự kiện, không phải nơi triển khai một image container có sẵn.

Ghi nhớ

⚠ Bốn lựa chọn serverless — bảng phải thuộc: | Sản phẩm | Đầu vào | Co về 0? | |---|---|---| | Cloud Run | ⚠ container image | CÓ | | App Engine Standard | ⚠ mã nguồn + app.yaml | CÓ | | Cloud Run Functions | mã của một hàm | CÓ | | App Engine Flexible | container | ⚠ KHÔNG | | GKE | container | ⚠ KHÔNG (cụm luôn chạy) |

Từ khoá nhận diện:

"đã có image container" → Cloud Run "triển khai thẳng từ mã nguồn" → App Engine Standard "phản ứng khi có sự kiện" → Cloud Run Functions "nhiều dịch vụ phụ thuộc nhau" → GKE

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí lúc rảnh có bằng 0 không | billing report theo ngày | | Cold start bao lâu | đo p99 sau khoảng nghỉ | | Có bị mở rộng vô hạn không | ⚠ kiểm max-instances |

Và một cách đọc đề rất hữu ích cho những câu ghép nhiều đội như thế này: tìm chữ mô tả ĐẦU VÀO của mỗi đội. "Image dựng sẵn", "mã nguồn", "một hàm nhỏ", "nhiều dịch vụ" — mỗi cụm từ đó gần như chỉ thẳng vào đúng một sản phẩm, và không cần cân nhắc gì thêm.

Đáp án

A — Cloud Run Functions.

Vì sao đúng

Đề dùng đúng ba chữ mô tả Cloud Run Functions: một đoạn mã nhỏ, phản ứng theo sự kiện nền, đơn nhiệm.

⚠ Ba đặc điểm ↔ Cloud Run Functions:

1. "MỘT ĐOẠN MÃ NHỎ"
     → viết một hàm, không phải
       cả một dịch vụ web

2. ⚠ "PHẢN ỨNG THEO SỰ KIỆN NỀN"
     → mỗi khi có TỆP MỚI được
       tải lên bucket
     → không có ai gọi HTTP cả

3. "ĐƠN NHIỆM" (single-purpose)
     → hàm chỉ làm đúng một việc:
       quét tệp

⚠ Luồng sự kiện:

Người dùng tải tệp lên bucket
        ↓
Cloud Storage phát sự kiện
`google.cloud.storage.object.v1.finalized`
        ↓
    ⚠ Eventarc định tuyến sự kiện
        ↓
Cloud Run Function được kích hoạt
        ↓
    Hàm nhận metadata: tên bucket,
    tên đối tượng, kích thước
        ↓
    Quét tệp → ghi kết quả
        ↓
    ⚠ Hàm kết thúc, tài nguyên
      được thu hồi
    ⚠ Không có tệp mới → không tốn tiền

⚠ Cloud Run Functions và Cloud Run — khác ở đâu:

CLOUD RUN FUNCTIONS
    → ⚠ viết MỘT HÀM
    → nền tảng lo phần còn lại
    → gắn sẵn với hàng chục
      nguồn sự kiện
    → ⚠ "idiomatic" cho việc này

CLOUD RUN
    → ⚠ viết cả một DỊCH VỤ WEB
      trong container
    → cũng nhận được sự kiện
      qua Eventarc
    → nhưng phải tự dựng container
      và tự xử lý HTTP
        ↓
    Đề hỏi cái "ĐÚNG CHẤT" nhất
    cho một tác vụ nhỏ
        ↓
    → Cloud Run Functions

Vì sao các phương án khác sai

• D (Cloud Run) — phương án gần nhất và hoàn toàn làm được (Cloud Run Functions thực chất chạy trên nền Cloud Run). Nhưng với một đoạn mã nhỏ đơn nhiệm, việc đóng gói cả một container và một máy chủ HTTP là thừa — đề hỏi lựa chọn đúng chất nhất.

• C (App Engine) — nền tảng cho ứng dụng web, không phải mô hình hàm theo sự kiện.

• B (Compute Engine) — máy ảo chạy suốt ngày chờ sự kiện; tốn tiền liên tục và phải tự viết vòng lặp theo dõi.

Ghi nhớ

⚠ Bốn lựa chọn tính toán serverless — bảng phải thuộc: | Sản phẩm | Dùng khi | |---|---| | Cloud Run Functions | ⚠ hàm nhỏ, theo SỰ KIỆN, đơn nhiệm | | Cloud Run | dịch vụ web trong container | | App Engine | ứng dụng web từ mã nguồn | | Cloud Run jobs | tác vụ chạy tới khi xong, không phục vụ HTTP |

Từ khoá nhận diện:

"mỗi khi có tệp mới, khi có bản ghi mới, theo sự kiện" → Cloud Run Functions "dịch vụ web, API, container" → Cloud Run "định tuyến sự kiện tới dịch vụ" → Eventarc "theo lịch" → Cloud Scheduler

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có bị gọi hai lần không | ⚠ kiểm tính idempotent bằng cách gửi lại sự kiện | | Có vòng lặp không | xem số lần kích hoạt trong Cloud Monitoring | | Timeout có đủ không | thử với tệp lớn nhất có thể gặp |

Và một tai nạn kinh điển đáng ghi nhớ với hàm theo sự kiện: hàm ghi kết quả ngược vào chính bucket đã kích hoạt nó. Nó tạo ra một vòng lặp tự nuôi, chạy hàng nghìn lần trước khi ai kịp nhận ra — và đó là lý do max-instances nên được đặt ngay từ lần triển khai đầu tiên.

Đáp án

B — Cloud Run.

Vì sao đúng

Đề nêu bốn đặc điểm, và chúng gộp lại chỉ về đúng một sản phẩm:

⚠ Bốn đặc điểm ↔ Cloud Run:

1. "DỊCH VỤ WEB đóng gói thành MỘT
    CONTAINER IMAGE, KHÔNG TRẠNG THÁI"
     → ⚠ Cloud Run chạy container
       bất kỳ

2. "NỀN TẢNG SERVERLESS"
     → không quản máy chủ

3. "TỰ MỞ RỘNG theo REQUEST HTTP"
     → mở rộng theo số request đồng thời

4. ⚠ "CO VỀ 0 khi không có lưu lượng
    để giảm chi phí"
     → ⚠ điều kiện loại trừ then chốt

⚠ Vì sao ba phương án kia trượt:

COMPUTE ENGINE
    → ⚠ máy ảo chạy là tính tiền
    → không co về 0
    → phải tự quản OS

GKE
    → ⚠ CỤM luôn chạy, node luôn tính tiền
    → quá nặng cho MỘT dịch vụ

APP ENGINE STANDARD
    → ⚠ CÓ co về 0
    → nhưng nhận MÃ NGUỒN với
      runtime giới hạn
    → đề nói rõ đã có
      CONTAINER IMAGE
        ↓
    → Cloud Run là lựa chọn đúng chất

⚠ Gần trùng với #13281 (cùng lô này) — đề đó cũng mô tả dịch vụ web không trạng thái trong container, lưu lượng thất thường, cần co về 0, và cùng khoá Cloud Run. Cũng liên quan #13314 (đội có container → Cloud Run). Cả ba nhất quán. Mẫu đề lặp: container + không trạng thái + co về 0 → luôn là Cloud Run.

Vì sao các phương án khác sai

• D (App Engine Standard) — phương án gần nhất và cũng co về 0. Nhưng nó nhận mã nguồn với runtime được hỗ trợ, còn đề nói rõ sản phẩm triển khai đã là một container image.

• C (GKE) — mạnh cho hệ nhiều dịch vụ, nhưng cụm luôn tính tiền và cần vận hành Kubernetes. Quá nặng cho một dịch vụ đơn lẻ.

• A (Compute Engine) — máy ảo, không serverless, không co về 0, phải tự quản hệ điều hành.

Ghi nhớ

⚠ Chọn nền tảng tính toán — bảng phải thuộc: | Sản phẩm | Co về 0? | Dùng khi | |---|---|---| | Cloud Run | ⚠ CÓ | container không trạng thái, HTTP | | Cloud Run Functions | CÓ | hàm nhỏ theo sự kiện | | App Engine Standard | CÓ | mã nguồn, runtime hỗ trợ | | GKE | ⚠ KHÔNG | nhiều dịch vụ phụ thuộc nhau | | Compute Engine | KHÔNG | cần kiểm soát hệ điều hành |

Từ khoá nhận diện:

"container + không trạng thái + co về 0" → Cloud Run "mã nguồn, không tự dựng container" → App Engine Standard "theo sự kiện" → Cloud Run Functions "hàng chục container phụ thuộc nhau" → GKE "phần mềm cũ, kiểm soát OS" → Compute Engine

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí lúc rảnh có bằng 0 không | billing report theo ngày | | Cold start ảnh hưởng bao nhiêu | độ trễ p99 sau khoảng nghỉ | | Có mở rộng vô hạn không | ⚠ kiểm max-instances |

Và một điều kiện tiên quyết đáng nhắc lại với mọi nền tảng serverless: ứng dụng phải thật sự không trạng thái. Cloud Run có thể huỷ và tạo lại instance bất cứ lúc nào, nên bất kỳ dữ liệu nào được giữ trong bộ nhớ hay ghi xuống đĩa cục bộ đều sẽ biến mất — và lỗi đó thường chỉ lộ ra khi lưu lượng tăng đủ để nền tảng bắt đầu mở rộng.

Đáp án

B — Data democratization (dân chủ hoá dữ liệu).

Vì sao đúng

Đề mô tả đúng khái niệm này: trao cho người dùng nghiệp vụ khả năng TỰ truy cập và phân tích dữ liệu, thay vì phải xếp hàng chờ đội CNTT trung tâm làm báo cáo hộ.

⚠ Vấn đề mà nó giải quyết:

MÔ HÌNH CŨ — nút thắt cổ chai
  Người kinh doanh có câu hỏi
        ↓
    Gửi yêu cầu cho đội dữ liệu
        ↓
    ⚠ Xếp hàng chờ vài ngày
      tới vài tuần
        ↓
    Nhận báo cáo
        ↓
    ⚠ "À, nhưng tôi còn muốn hỏi thêm..."
        ↓
    Quay lại xếp hàng

DÂN CHỦ HOÁ DỮ LIỆU
  Người kinh doanh tự vào Looker
        ↓
    ⚠ Kéo thả, tự trả lời
    ⚠ Hỏi tiếp ngay lập tức
        ↓
    → quyết định nhanh hơn nhiều

⚠ Ba điều kiện để làm được:

1. CÔNG CỤ dễ dùng
     → Looker, Looker Studio,
       Connected Sheets

2. ⚠ MÔ HÌNH DỮ LIỆU ĐÁNG TIN
     → LookML định nghĩa "doanh thu"
       một lần, ai cũng dùng chung
     → ⚠ không có mô hình chung thì
       dân chủ hoá = hỗn loạn

3. QUẢN TRỊ và ĐÀO TẠO
     → ai được xem gì
     → người dùng hiểu dữ liệu nghĩa gì

⚠ Vì sao "quản trị" là điều kiện, không phải rào cản:

Mở dữ liệu cho mọi người
mà KHÔNG có quản trị
        ↓
    ⚠ Ba đội tính doanh thu ba kiểu
    ⚠ Dữ liệu nhạy cảm lọt ra
    ⚠ Không ai biết bảng nào đúng
        ↓
    → mất niềm tin vào dữ liệu
        ↓
    ⚠ Dân chủ hoá KHÔNG phải
      "bỏ hết kiểm soát"

Vì sao các phương án khác sai

• D (data sovereignty — chủ quyền dữ liệu) — phương án gần nhất về mặt "cũng là khái niệm dữ liệu cấp chiến lược", nhưng nó nói về dữ liệu chịu luật của nước nào và lưu ở đâu, không liên quan tới việc ai được dùng công cụ phân tích.

• A (mã hoá dữ liệu) — biện pháp bảo mật kỹ thuật.

• C (di chuyển dữ liệu) — chuyển dữ liệu từ nơi này sang nơi khác.

Ghi nhớ

⚠ Các khái niệm dữ liệu cấp chiến lược — bảng nên thuộc: | Khái niệm | Nghĩa | |---|---| | Data democratization | ⚠ mọi người tự truy cập và phân tích được | | Data governance | chính sách quản lý dữ liệu như tài sản | | Data sovereignty | dữ liệu chịu luật nước nào | | Data literacy | ⚠ năng lực ĐỌC HIỂU dữ liệu của nhân viên | | Data-driven culture | ra quyết định dựa trên dữ liệu | | Data monetization | biến dữ liệu thành doanh thu |

Từ khoá nhận diện:

"người dùng tự phân tích, không phụ thuộc đội CNTT" → data democratization "ai được xem gì, chất lượng, tuân thủ" → data governance "dữ liệu phải ở trong lãnh thổ" → data residency / sovereignty "đào tạo nhân viên đọc số liệu" → data literacy

Ba việc kiểm chứng cho một tổ chức: | Việc | Câu hỏi | |---|---| | Người kinh doanh mất bao lâu để có câu trả lời | đo trước và sau | | Có bao nhiêu người tự chạy truy vấn | tỉ lệ người dùng chủ động | | Ba đội hỏi cùng một câu có ra cùng số không | ⚠ phép thử của mô hình chung |

Và một điều kiện tiên quyết mà các chương trình dân chủ hoá dữ liệu hay bỏ qua: phải có một định nghĩa chỉ số dùng chung trước khi mở quyền cho mọi người. Không có nó, kết quả không phải là nhiều người ra quyết định tốt hơn, mà là nhiều phiên bản của cùng một con số cùng tồn tại trong các cuộc họp.

Đáp án

A — Natural Language API.

Vì sao đúng

Trích xuất con người, tổ chức và địa điểm từ văn bản là bài toán kinh điển có tên riêng: nhận dạng thực thể (entity recognition) — và đó là một trong các tính năng chính của Natural Language API.

⚠ API trả về gì:

Đầu vào: "Sundar Pichai, CEO của Google,
          phát biểu tại Paris hôm qua."
        ↓
Natural Language API
        ↓
Thực thể:
  "Sundar Pichai"  PERSON       salience 0,62
  "Google"         ORGANIZATION salience 0,25
  "Paris"          LOCATION     salience 0,13
        ↓
    ⚠ Kèm liên kết tới Wikipedia
      và Knowledge Graph nếu có
    ⚠ Kèm SALIENCE — mức quan trọng
      của thực thể trong bài

⚠ Vì sao chọn API dựng sẵn ở đây:

Đề nói: "dịch vụ AI ĐƠN GIẢN,
         ĐÃ HUẤN LUYỆN SẴN"
        ↓
    ⚠ Nhận diện người, tổ chức, địa điểm
      là bài toán PHỔ QUÁT
    ⚠ Google đã huấn luyện trên
      lượng văn bản khổng lồ
        ↓
    → tự huấn luyện là lãng phí

⚠ Ba API kia làm việc khác hẳn:

CLOUD VISION API
    → ⚠ phân tích ẢNH, không phải văn bản
    → (có OCR đọc chữ TRONG ảnh,
       nhưng không trích xuất thực thể)

TEXT-TO-SPEECH API
    → ⚠ chữ → GIỌNG NÓI
    → ngược hướng hoàn toàn

CLOUD TRANSLATION API
    → ⚠ DỊCH giữa các ngôn ngữ
    → không phân tích nội dung

Vì sao các phương án khác sai

• B (Cloud Vision API) — phương án gần nhất nếu người đọc lướt qua chữ "phân tích", nhưng Vision làm việc với ảnh. Bài báo là văn bản.

• C (Text-to-Speech API) — chuyển văn bản thành giọng nói, không phân tích nội dung.

• D (Cloud Translation API) — dịch ngôn ngữ, không trích xuất thực thể.

Ghi nhớ

⚠ Các API AI dựng sẵn — bảng phải thuộc: | API | Việc | |---|---| | Natural Language API | ⚠ thực thể, cảm xúc, cú pháp, phân loại nội dung | | Cloud Vision | nhãn ảnh, OCR, khuôn mặt, logo, nội dung nhạy cảm | | Cloud Translation | dịch hơn 100 ngôn ngữ | | Speech-to-Text | giọng nói → chữ | | Text-to-Speech | chữ → giọng nói | | Video Intelligence | nội dung video | | Document AI | ⚠ trích xuất trường từ hoá đơn, hợp đồng, biểu mẫu |

Từ khoá nhận diện:

"tìm người, tổ chức, địa điểm trong văn bản" → Natural Language API "khách hàng khen hay chê" → phân tích cảm xúc — cùng API "trích xuất trường từ hoá đơn" → Document AI "đọc chữ trong ảnh chụp" → Vision API — OCR "nhãn riêng của ngành" → AutoML hoặc Gemini

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ chính xác trên dữ liệu thật | ⚠ lấy 50 bài, đối chiếu với người đọc | | Có thực thể chuyên ngành nào bị bỏ sót | → cân nhắc mô hình tuỳ biến | | Chi phí bao nhiêu | tính theo đơn vị 1.000 ký tự |

Và một mẹo giúp giảm chi phí đáng kể khi xử lý hàng nghìn bài báo: lọc và cắt bớt trước khi gọi API. Giá tính theo lượng ký tự gửi đi, nên bỏ phần chân trang, quảng cáo và bình luận trước khi gửi thường cắt được một phần đáng kể hoá đơn mà không mất thực thể nào quan trọng.

Đáp án

A — Triển khai nhiều instance trong một Managed Instance Group (MIG) đặt sau Load Balancer.

Vì sao đúng

Đề mô tả đúng hai cơ chế của MIG: tự chữa lành (autohealing) và cân bằng tải.

⚠ MIG hoạt động thế nào:

INSTANCE TEMPLATE
  (khuôn: loại máy, image, script khởi động)
        ↓
MANAGED INSTANCE GROUP
  khai: "muốn có 5 instance"
        ↓
    ⚠ MIG liên tục so sánh
      mong muốn ↔ thực tế
        ↓
    Một VM chết hoặc health check fail
        ↓
    ⚠ MIG TỰ XOÁ và TẠO LẠI
      từ đúng template đó
        ↓
LOAD BALANCER
    ⚠ tự ngừng gửi lưu lượng vào
      instance không khoẻ
    ⚠ tự thêm instance mới vào pool

⚠ Health check — trái tim của cơ chế:

Load balancer health check
    → quyết định có gửi lưu lượng
      vào instance đó không

⚠ Autohealing health check (của MIG)
    → quyết định có TẠO LẠI
      instance đó không
        ↓
    ⚠ Hai loại khác nhau, nên đặt
      NGƯỠNG KHÁC nhau
    → autohealing nên "khoan dung" hơn
      để tránh khởi động lại vòng vo

⚠ Vì sao ba phương án kia sai:

MỘT VM RẤT LỚN
    → ⚠ vẫn là MỘT điểm hỏng duy nhất
    → máy to hơn không làm nó
      bất tử hơn

PREEMPTIBLE VM
    → ⚠ bị THU HỒI bất cứ lúc nào
    → làm GIẢM độ tin cậy,
      không tăng

TRẠNG THÁI TRONG PERSISTENT DISK
   GẮN VÀO MỘT VM
    → ⚠ vẫn một điểm hỏng
    → và đĩa zonal không dùng lại
      được ở zone khác

Vì sao các phương án khác sai

• D (lưu trạng thái trong Persistent Disk gắn vào một VM) — phương án gần nhất về mặt "nghe như bảo vệ dữ liệu", nhưng nó vẫn để một VM duy nhất phục vụ. VM chết là dịch vụ chết, dù dữ liệu còn.

• B (một VM rất lớn) — hiểu sai về độ tin cậy: dư thừa (redundancy) mới chống được lỗi, không phải kích thước.

• C (dùng preemptible VM để chúng được thay thường xuyên) — preemptible/Spot bị thu hồi bất cứ lúc nào; dùng cho tải chịu được gián đoạn, không phải để tăng độ tin cậy.

Ghi nhớ

⚠ Managed Instance Group — bảng phải thuộc: | Tính năng | Nội dung | |---|---| | Instance template | ⚠ khuôn BẤT BIẾN — đổi thì tạo template mới | | Autohealing | ⚠ tạo lại VM khi health check fail | | Autoscaling | theo CPU, tải LB, hoặc metric tuỳ chỉnh | | Rolling update | ⚠ cập nhật dần, quay lui được | | Regional MIG | ⚠ trải VM qua NHIỀU ZONE | | Zonal MIG | chỉ một zone — kém an toàn hơn |

Từ khoá nhận diện:

"VM chết thì tự tạo lại" → MIG autohealing "tự thêm bớt VM theo tải" → MIG autoscaling "chịu được mất một zone" → ⚠ regional MIG "container thay vì VM" → GKE hoặc Cloud Run

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tự chữa lành thật không | ⚠ xoá thử một VM và quan sát | | Chịu được mất zone không | kiểm MIG là regional hay zonal | | Health check có đúng không | thử làm ứng dụng lỗi mà cổng vẫn mở |

Và một điểm hay bị làm sai khi cấu hình health check: kiểm tra cổng mở không đủ. Một tiến trình treo vẫn giữ cổng 8080 mở trong khi không xử lý được request nào — endpoint kiểm tra sức khoẻ nên thật sự chạm vào các phụ thuộc chính trước khi trả về 200.

Đáp án

D — Cloud Storage.

Vì sao đúng

Đề nêu bốn yêu cầu, và tất cả đều là mô tả của lưu trữ đối tượng:

⚠ Bốn yêu cầu ↔ Cloud Storage:

1. VIDEO THÔ, FILE DỰ ÁN, ẢNH
     → ⚠ dữ liệu PHI CẤU TRÚC
     → chính là "object" trong
       object storage

2. ĐỘ BỀN CAO
     → ⚠ 11 số chín — nhân bản tự động

3. SẴN SÀNG CAO
     → cấu hình đa vùng nếu cần

4. TIẾT KIỆM CHI PHÍ
     → ⚠ chọn lớp Nearline / Coldline /
       Archive theo tần suất đọc

⚠ Vì sao ba CSDL kia sai loại:

BIGQUERY
    → kho PHÂN TÍCH cho dữ liệu
      có cấu trúc (hàng và cột)
    → ⚠ không phải nơi lưu file video

CLOUD SPANNER / CLOUD SQL
    → ⚠ CSDL QUAN HỆ
    → nhét video vào cột BLOB là
      cực kỳ đắt, chậm, và
      chạm trần dung lượng
        ↓
    ⚠ MẪU ĐÚNG:
      file → Cloud Storage
      metadata + ĐƯỜNG DẪN → CSDL

⚠ Kiến trúc chuẩn cho kho video:

Video thô  →  Cloud Storage
                (Standard 30 ngày,
                 rồi Coldline/Archive)
        ↓
Metadata (tên, dự án, thẻ, thời lượng)
        →  Cloud SQL hoặc Firestore
        ↓
Phục vụ người xem
        →  Cloud CDN
        ↓
Phân tích nội dung
        →  Video Intelligence API
        ↓
    ⚠ Mỗi loại dữ liệu ở đúng chỗ của nó

⚠ Gần trùng với #13266 (lô 138) — đề đó cũng là công ty truyền thông lưu hàng petabyte ảnh và video, hiếm khi truy cập, và cùng khoá Cloud Storage. Hoàn toàn nhất quán. Mẫu đề lặp: dữ liệu phi cấu trúc, tệp lớn, độ bền cao → luôn là Cloud Storage.

Vì sao các phương án khác sai

• A (BigQuery) — phương án gần nhất về mặt "quy mô lớn", nhưng nó là kho phân tích cho dữ liệu có cấu trúc. Nó phân tích metadata của video rất tốt, nhưng không phải nơi lưu chính các tệp.

• B (Cloud Spanner) và C (Cloud SQL) — CSDL quan hệ. Lưu tệp lớn trong đó vừa đắt vừa sai mục đích.

Ghi nhớ

⚠ Ba kiểu lưu trữ — bảng phải thuộc: | Kiểu | Sản phẩm | Dùng cho | |---|---|---| | Object | Cloud Storage | ⚠ tệp, ảnh, video, sao lưu | | Block | Persistent Disk, Hyperdisk | đĩa của máy ảo | | File | Filestore | NFS chia sẻ giữa nhiều máy |

Từ khoá nhận diện:

"video, ảnh, tệp, phi cấu trúc" → Cloud Storage "đĩa gắn vào VM" → Persistent Disk "nhiều máy cùng đọc một thư mục" → ⚠ Filestore — hay dùng cho dựng phim "phân tích dữ liệu có cấu trúc" → BigQuery

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bucket nào công khai không | ⚠ Security Command Center | | Dữ liệu đang ở lớp nào | Storage Insights | | Phí đi ra bao nhiêu | billing report — SKU egress |

Và một khoản chi phí thường gây bất ngờ nhất với kho video: tiền truyền dữ liệu ra, chứ không phải tiền lưu trữ. Hàng petabyte nằm yên trong Archive rất rẻ, nhưng mỗi lần một biên tập viên ở đầu kia thế giới kéo về một bản gốc lại là một dòng đáng kể trong hoá đơn.

Đáp án

C — DevOps.

Vì sao đúng

Đề mô tả đúng vấn đề mà DevOps sinh ra để giải: hai đội làm việc trong hai ốc đảo tách biệt (silo), ném mã "qua bức tường" cho nhau, dẫn tới chu kỳ phát hành chậm và xung đột liên tục.

⚠ Vấn đề "ném qua bức tường":

ĐỘI PHÁT TRIỂN
  được thưởng vì RA TÍNH NĂNG NHANH
        ↓
    Viết xong → ném qua tường
        ↓
    ⚠ BỨC TƯỜNG
        ↓
ĐỘI VẬN HÀNH
  được thưởng vì HỆ THỐNG ỔN ĐỊNH
        ↓
    ⚠ Hai bên có ĐỘNG CƠ NGƯỢC NHAU
    ⚠ Sự cố xảy ra → đổ lỗi cho nhau
    ⚠ Vận hành dựng thêm rào để tự vệ
    ⚠ Phát hành ngày càng chậm

⚠ DevOps phá bức tường bằng cách nào:

TRÁCH NHIỆM CHUNG
    → "you build it, you run it"
    → ⚠ đội viết mã cũng trực sự cố

TỰ ĐỘNG HOÁ
    → CI/CD, hạ tầng dưới dạng mã
    → ⚠ giảm thao tác tay, giảm sai sót

PHẢN HỒI NHANH
    → giám sát, cảnh báo, đo lường

⚠ VĂN HOÁ KHÔNG QUY TỘI
    → mổ xẻ sự cố để sửa hệ thống,
      không để phạt người

⚠ DevOps và SRE — quan hệ thế nào:

DEVOPS
    → ⚠ TRIẾT LÝ, văn hoá
    → nói CÁI GÌ cần đạt

SRE
    → ⚠ một CÁCH CÀI ĐẶT cụ thể
      của DevOps, do Google đề ra
    → nói LÀM THẾ NÀO:
      SLO, error budget, giới hạn toil
        ↓
    Câu nói quen thuộc:
    ⚠ "class SRE implements DevOps"

⚠ Đối chiếu #13264 (lô 138) — đề đó khoá SRE vì nhấn mạnh "do Google khởi xướng" và "đạt mục tiêu SLO 99,9%". Câu này khoá DevOps vì nhấn mạnh "triết lý VĂN HOÁ" và "kết hợp phát triển với vận hành". Hai câu KHÔNG mâu thuẫn — chúng hỏi hai tầng khác nhau của cùng một phong trào.

Cách phân biệt khi làm bài: thấy "văn hoá, phá bỏ silo, kết hợp dev và ops" → DevOps. Thấy "SLO, error budget, do Google khởi xướng, kỹ thuật phần mềm áp vào vận hành" → SRE.

Vì sao các phương án khác sai

• B (ITIL) — phương án gần nhất vì cũng là khung quản lý dịch vụ CNTT. Nhưng ITIL thiên về quy trình và thủ tục chuẩn hoá (quản lý thay đổi, quản lý sự cố), thường bị coi là làm chậm chu kỳ phát hành chứ không phải giải pháp cho vấn đề của đề.

• A (Waterfall) — mô hình phát triển tuần tự theo giai đoạn, chính là thứ tạo ra kiểu bàn giao "qua bức tường".

• D (Six Sigma) — phương pháp cải tiến chất lượng trong sản xuất, giảm sai lệch. Không phải triết lý CNTT về dev và ops.

Ghi nhớ

⚠ Bốn khái niệm dễ lẫn — bảng phải thuộc: | Khái niệm | Nội dung | |---|---| | DevOps | ⚠ TRIẾT LÝ VĂN HOÁ — kết hợp dev và ops | | SRE | ⚠ cách CÀI ĐẶT DevOps của Google — SLO, error budget | | Agile | phát triển phần mềm theo vòng lặp ngắn | | ITIL | quản lý dịch vụ CNTT theo quy trình | | Waterfall | mô hình tuần tự cũ |

Từ khoá nhận diện:

"văn hoá, phá silo, kết hợp dev và ops" → DevOps "SLO, error budget, do Google khởi xướng" → SRE "sprint, backlog, lặp ngắn" → Agile "quy trình quản lý thay đổi chuẩn hoá" → ITIL

Ba việc kiểm chứng cho một tổ chức: | Việc | Câu hỏi | |---|---| | Bao lâu triển khai một lần | ⚠ mỗi tháng một lần là dấu hiệu xấu | | Từ commit tới production mất bao lâu | | | Ai bị gọi lúc 3 giờ sáng | ⚠ nếu chỉ có đội vận hành thì bức tường vẫn còn |

Và một phép thử đơn giản cho biết một tổ chức có thật sự làm DevOps hay chỉ mua công cụ: hỏi xem ai chịu trách nhiệm khi dịch vụ sập lúc nửa đêm. Nếu câu trả lời vẫn là "đội vận hành", thì bức tường mà đề bài mô tả vẫn còn nguyên ở đó, chỉ là giờ nó có thêm một đường ống CI/CD chạy xuyên qua.

Đáp án

B — "Nó cho phép lập trình viên dùng image Docker tuỳ biến cho ứng dụng." Đây là đặc điểm KHÔNG đúng với App Engine Standard.

Vì sao đúng

⚠ Đây là câu hỏi PHỦ ĐỊNH — đề hỏi đặc điểm nào KHÔNG phải của App Engine Standard. Ba đặc điểm còn lại đều đúng.

⚠ App Engine có HAI môi trường, và đây là khác biệt lớn nhất:

APP ENGINE STANDARD
    → ⚠ chỉ chạy RUNTIME ĐƯỢC HỖ TRỢ:
      Python, Java, Go, Node.js,
      PHP, Ruby
    → ⚠ KHÔNG nhận container tuỳ biến
    → ⚠ CO VỀ 0
    → khởi động rất nhanh

APP ENGINE FLEXIBLE
    → ⚠ CHẤP NHẬN container tuỳ biến
    → chạy trên máy ảo
    → ⚠ KHÔNG co về 0
      (tối thiểu một instance)
    → khởi động chậm hơn nhiều

⚠ Ba mệnh đề kia đều ĐÚNG với Standard:

A. "triển khai trực tiếp từ MÃ NGUỒN
    với runtime của ngôn ngữ cụ thể"
     → ⚠ ĐÚNG — `gcloud app deploy`
       với `app.yaml`

C. "tự mở rộng 0 tới N, gồm cả
    CO VỀ 0 để tiết kiệm"
     → ⚠ ĐÚNG — đặc trưng của Standard

D. "PaaS serverless có quản lý hoàn toàn"
     → ⚠ ĐÚNG — đúng định nghĩa

⚠ Muốn dùng container thì đi đâu:

Có container image
        ↓
    ⚠ CLOUD RUN
      → serverless, co về 0,
        chạy container bất kỳ
        ↓
    hoặc App Engine Flexible
      → nhưng không co về 0
        ↓
    hoặc GKE
      → khi có nhiều dịch vụ

Vì sao các phương án khác sai

(Ở câu phủ định, "sai" nghĩa là mệnh đề đó đúng về App Engine Standard, nên không phải đáp án.)

• A — Standard thật sự triển khai từ mã nguồn với các runtime được hỗ trợ.
• C — Standard thật sự co về 0.
• D — Standard thật sự là PaaS serverless có quản lý.

Ghi nhớ

⚠ Hai môi trường App Engine — bảng phải thuộc: | | Standard | Flexible | |---|---|---| | Đầu vào | ⚠ mã nguồn, runtime hỗ trợ | ⚠ container tuỳ biến | | Co về 0 | ⚠ CÓ | ⚠ KHÔNG | | Khởi động | rất nhanh (ms) | chậm (phút) | | Chạy trên | sandbox riêng | máy ảo Compute Engine | | SSH vào instance | ⚠ không | có | | Chi phí lúc rảnh | gần 0 | vẫn tính tiền |

Từ khoá nhận diện:

"container tuỳ biến + serverless + co về 0" → ⚠ Cloud Run, không phải App Engine "mã nguồn, runtime hỗ trợ, co về 0" → App Engine Standard "container nhưng cần môi trường VM" → App Engine Flexible "nhiều dịch vụ phụ thuộc nhau" → GKE

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Runtime có được hỗ trợ không | kiểm danh sách trong tài liệu | | Có phụ thuộc hệ thống lạ không | ⚠ nếu có → Cloud Run | | Chi phí lúc rảnh | billing report theo ngày |

Và một điều đáng lưu ý khi chọn giữa App Engine và Cloud Run cho một dự án mới: Cloud Run gần như luôn là lựa chọn mặc định hợp lý hơn. Nó cho cùng trải nghiệm serverless nhưng không ràng buộc bạn vào một danh sách runtime, và vì dựa trên Knative nên ứng dụng của bạn giữ được khả năng chuyển đi nơi khác.

Đáp án

C — Phân tích âm thanh thô để nhận ra các vấn đề khách hàng lặp lại và cảm xúc tổng thể.

Vì sao đúng

Câu hỏi là về giá trị kinh doanh mà ML mở khoá cho dữ liệu phi cấu trúc — thứ mà công cụ BI truyền thống không chạm tới được.

⚠ Vì sao BI truyền thống bó tay:

Công cụ BI làm việc với HÀNG và CỘT
        ↓
    Ghi âm cuộc gọi là MỘT TỆP ÂM THANH
        ↓
    ⚠ BI chỉ thấy: tên tệp, thời lượng,
      ngày giờ, nhân viên nào nhận
    ⚠ KHÔNG thấy được NỘI DUNG
        ↓
    → hàng nghìn giờ nội dung
      nằm im, không ai khai thác

⚠ ML biến âm thanh thành dữ liệu phân tích được:

Tệp ghi âm
        ↓
SPEECH-TO-TEXT  → bản chép lời
        ↓
NATURAL LANGUAGE API
   ├── ⚠ trích xuất THỰC THỂ
   │     → sản phẩm nào bị nhắc nhiều
   ├── ⚠ phân tích CẢM XÚC
   │     → khách hài lòng hay bực bội
   └── phân loại chủ đề
        ↓
BIGQUERY  → giờ đã là dữ liệu có cấu trúc
        ↓
LOOKER    → ⚠ "vấn đề nào tăng mạnh
             trong tháng này?"

⚠ Giá trị kinh doanh cụ thể:

⚠ Phát hiện lỗi sản phẩm SỚM
   → 200 cuộc gọi cùng nhắc một lỗi
     trước khi nó lên mạng xã hội

⚠ Biết chủ đề nào tốn thời gian nhất
   → viết tài liệu tự phục vụ cho nó

⚠ Đo cảm xúc theo thời gian
   → thay vì chỉ dựa vào khảo sát
     mà ít người trả lời

⚠ Tìm cuộc gọi mẫu để đào tạo

Vì sao các phương án khác sai

• A (đếm chính xác số cuộc gọi mỗi ngày) — phương án gần nhất về mặt "cũng là phân tích", nhưng đây là thống kê đơn giản mà BI truyền thống làm được từ metadata. Không cần ML, và không phải giá trị mà ML mở khoá.

• B (đảm bảo giảm 50% lượng cuộc gọi) — không hệ thống nào đảm bảo một con số cụ thể như vậy. ML cho hiểu biết, việc giảm cuộc gọi là kết quả của hành động sau đó.

• D (tạo schema quan hệ để lưu tệp âm thanh hiệu quả hơn) — nhầm lẫn về loại việc: đó là chuyện lưu trữ, và tệp âm thanh nên nằm ở Cloud Storage, không phải trong CSDL quan hệ.

Ghi nhớ

⚠ Ba loại dữ liệu — bảng phải thuộc: | Loại | Ví dụ | Công cụ | |---|---|---| | Có cấu trúc | bảng, hàng và cột | SQL, BI truyền thống | | Bán cấu trúc | JSON, XML, log | BigQuery, NoSQL | | Phi cấu trúc | ⚠ âm thanh, ảnh, video, văn bản tự do | ⚠ ML và AI | | Tỉ lệ thực tế | ⚠ phần lớn dữ liệu doanh nghiệp là PHI CẤU TRÚC |

Từ khoá nhận diện:

"âm thanh, ảnh, video, văn bản tự do" → cần ML để khai thác "đếm, tổng hợp bảng biểu" → BI truyền thống là đủ "chuyển giọng nói thành chữ" → Speech-to-Text "khách hài lòng hay không" → phân tích cảm xúc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản chép có đủ chính xác không | ⚠ nghe lại 20 cuộc và đối chiếu | | Chủ đề tìm ra có ý nghĩa không | đưa cho trưởng nhóm tổng đài xem | | Đã che PII chưa | quét bằng Sensitive Data Protection |

Và một lý do khiến loại dự án này thường đem lại giá trị nhanh hơn nhiều dự án ML khác: dữ liệu đã có sẵn từ lâu. Hàng nghìn giờ ghi âm đã nằm đó nhiều năm, và điều duy nhất từng thiếu là một cách biến chúng thành thứ có thể đặt câu hỏi được.