Lesson 2: Building the Standard Operations Profile

Why a profile comes before any product

In Level 1 you saw every Google Cloud management and monitoring service on one page. The obvious next move is to start comparing products. Don't do that yet. Experienced teams describe the estate first and pick tools second. If you skip that step, you end up choosing whatever the last conference talk showed you.

Think of the standard operations profile as the brief you give an architect before they draw a house. They need to know how many people will live there, the budget, and what the planning office won't allow. You will fill in this profile once and then reuse it in every service lesson in this course. Each later lesson will say which section of it decides the choice.

The profile has nine sections:

1. Estate size and environments
2. Telemetry volume and retention
3. SLOs and alerting
4. IaC and change control
5. Patching
6. Cost allocation
7. Guardrails
8. Team skills
9. Cost model

Rule 1: numbers, not adjectives

"Lots of logs" doesn't help you decide anything. "About 120 GB of logs a day, 90 days searchable, 400 days for audit" does. Every item gets a measurable figure plus two tags:

• type: hard (a constraint you can't break: a regulation, a contract, a board decision) or pref (a preference you can trade away)
• source: where the number came from (a measurement, a document, an interview, or an estimate)

Gotcha: if you can't name a source, the number is a guess. Tag it estimate and give it an owner who will replace it with a measurement.

Walkthrough: measure before you write

Most section 1 and 2 numbers can be pulled from the estate itself. Run these from Cloud Shell:

# Section 1: VM count across the whole organisation (Cloud Asset Inventory search)
gcloud asset search-all-resources \
  --scope=organizations/123456789012 \
  --asset-types=compute.googleapis.com/Instance \
  --format="value(name)" | wc -l
# 214   <- record as source: measured, date 2026-10-30

# Section 1: how many projects you have, a rough proxy for environments and teams
gcloud projects list --format="value(projectId)" | wc -l
# 37

# Section 2: current retention on each log bucket in one project
gcloud logging buckets list --project=shop-prod \
  --format="table(name.basename(), location, retentionDays)"
# NAME       LOCATION  RETENTION_DAYS
# _Default   global    30
# _Required  global    400

For daily log volume, open Metrics Explorer and chart logging.googleapis.com/billing/bytes_ingested summed per day over the last 30 days. Use the billed figure, not your own estimate: the billable size includes metadata on top of your message text.

Know your defaults: the _Default log bucket keeps entries for 30 days unless you change it. The _Required bucket keeps audit-type entries for 400 days, and you can't change that. Write both into section 2 so nobody plans around a retention period that doesn't exist.

The filled-in profile (sample estate)

Keep the profile as a YAML file in Git, next to your infrastructure code. Then changes to it get reviewed like any other change.

# ops-profile.yaml  (sample retailer, version 1, 2026-10-30)
estate:
  vms:            {value: 214, type: pref, source: "asset search 2026-10-30"}
  gke_clusters:   {value: 3,   type: pref, source: "asset search"}
  environments:   {value: [dev, test, prod], type: hard, source: "platform standard v2"}
  regions:        {value: [europe-west2], type: hard, source: "data residency policy"}
telemetry:
  logs_gb_per_day:     {value: 120, type: pref, source: "bytes_ingested, 30-day avg"}
  log_retention_days:  {value: 90,  type: pref, source: "SRE interview"}
  audit_retention_days:{value: 400, type: hard, source: "_Required bucket default"}
  custom_metrics:      {value: "~5k time series", type: pref, source: estimate, owner: priya}
slos_alerting:
  checkout_availability: {value: "99.9% / 30 days", type: hard, source: "customer contract"}
  paging_channel:        {value: PagerDuty, type: pref, source: "on-call runbook"}
iac_change:
  tool:      {value: Terraform, type: pref, source: "repo survey"}
  approval:  {value: "2 reviewers for prod", type: hard, source: "change policy"}
patching:
  critical_cve_days: {value: 14, type: hard, source: "security standard"}
  os_mix:            {value: "80% Debian, 20% Windows", type: pref, source: "OS inventory"}
cost_allocation:
  labels_required: {value: [team, env, cost-centre], type: hard, source: "finance"}
  showback_or_chargeback: {value: showback, type: pref, source: "CFO memo"}
guardrails:
  allowed_regions: {value: [europe-west2], type: hard, source: "org policy"}
team_skills:
  terraform: {value: strong, type: pref, source: "skills survey"}
  promql:    {value: none,   type: pref, source: "skills survey"}
cost_model:
  monthly_ops_budget_gbp: {value: 6000, type: hard, source: "FY27 budget"}
  commitment_appetite:    {value: "1-year max", type: pref, source: finance}

Trade-off: keep the profile short. If a section runs past a few lines, you are writing a design document. The profile only has to answer: how big, how much, how strict, who, and what budget.

Turning numbers into early cost signals

Some numbers start talking straight away. Take the 120 GB a day figure and the published Cloud Logging list prices at the time of writing (October 2026; always check the pricing page). Storage is $0.50 per GiB ingested, with the first 50 GiB per project per month free. Retention beyond 30 days costs $0.01 per GiB per month.

120 GB/day x 30 days       = ~3,600 GB/month ingested
(3,600 - 50 free) x $0.50  = ~$1,775/month   <- in one project, before retention

That one line says logging alone could take a large share of a £6,000 budget. Now you know which section to question first. Treat this as a rough check only. Level 4 covers how logging is really billed.

Which section decides what later

Hard constraints remove options. Preferences only add weight. Later in the course, the selection scorecard takes its weights directly from this file.

Key takeaways

• Fill in the nine-section profile before you compare any service, and reuse it in every later lesson.
• Every item needs a measurable figure, a hard/pref tag and a named source. Guesses are tagged estimate and given an owner.
• Measure where you can: Asset Inventory search for VM counts, bytes_ingested for log volume, gcloud logging buckets list for retention.
• Record the defaults: _Default keeps logs 30 days (you can change it), _Required keeps them 400 days (fixed).
• Hard constraints rule options out; preferences only weight the scorecard.
• Keep the profile in Git so changes to it are reviewed.