Serverless Cloud Run Operations & SRE Runbook

1. Cloud-Native Serverless Operations Overview

In accordance with ADR-007, all platform backend hosts execute as stateless containers on Google Cloud Run in southamerica-east1 (São Paulo). Serverless compute eliminates manual Linux kernel updates, hardware driver checks, and operating system reboots.

Operational activities center on revisions management, traffic splitting, database migration orchestrations, and capacity governance.

flowchart TD
    subgraph DEPLOYMENT ["Cloud Run Revision Deployment"]
        IMAGE["Artifact Registry Image<br>(gercia-server:main)"] --> REV_NEW["New Revision Created<br>(gercia-server-prd-00042)"]
    end

    subgraph TRAFFIC ["Zero-Downtime Traffic Routing"]
        REV_OLD["Active Revision (00041)<br>(100% Traffic)"]
        REV_NEW -. "Canary Test (10%)" .-> SPLIT{"Traffic Split"}
        SPLIT -- "90%" --> REV_OLD
        SPLIT -- "10%" --> REV_NEW
        REV_NEW -- "Promote (100% Traffic)" --> FULL_ROLLOUT["Production Live"]
    end

2. Managing Cloud Run Service (`Gercia.Server`)

A. Deploying a New Container Revision

Deployments are executed automatically by Google Cloud Build on push to main or staging. For manual emergency deployments:

gcloud run deploy gercia-server-prd \
    --project=gercia-gcp \
    --region=southamerica-east1 \
    --image=southamerica-east1-docker.pkg.dev/gercia-gcp/gercia-platform/gercia-server:main \
    --vpc-connector=projects/gercia-gcp/locations/southamerica-east1/connectors/gercia-vpc-cx \
    --min-instances=0 \
    --max-instances=30 \
    --concurrency=80 \
    --memory=512Mi \
    --cpu=1

B. Instant Zero-Downtime Rollback

If a critical application defect escapes to production, rollback to the previous known-good revision executes in less than 2 seconds:

List Recent Revisions:

gcloud run revisions list \
    --project=gercia-gcp \
    --region=southamerica-east1 \
    --service=gercia-server-prd

Shift 100% Traffic to Previous Revision:

gcloud run services update-traffic gercia-server-prd \
    --project=gercia-gcp \
    --region=southamerica-east1 \
    --to-revisions=gercia-server-prd-00041=100

3. Database Migration Execution via Cloud Run Jobs (`gercia-migrator`)

To prevent long-running EF Core schema migrations from timing out in HTTP request contexts or blocking web container startup, database migrations execute as an ephemeral Cloud Run Job running gercia-server with --migrate:

sequenceDiagram
    autonumber
    participant CI as Cloud Build / SRE
    participant Job as Cloud Run Job (gercia-migrator)
    participant GSM as Google Secret Manager
    participant DB as Google Cloud SQL (Private IP)

    CI->>Job: Execute Job (gcloud run jobs execute gercia-migrator)
    Job->>GSM: Resolve CONNECTION_STRING_MIGRATOR_PRD
    Job->>DB: Apply Pending Linear-Tagged EF Core Migrations
    DB-->>Job: Schema DDL Applied & Committed
    Job-->>CI: Exit Code 0 (Container Terminated)

Executing Migrations in Production:

gcloud run jobs execute gercia-migrator \
    --project=gercia-gcp \
    --region=southamerica-east1 \
    --wait

The job spins up a lightweight container, connects to Google Cloud SQL over the private Serverless VPC Access Connector, applies all pending EF Core migrations (Database.Migrate()), and terminates immediately.

4. Live Log Streaming & Triage

Cloud Run streams all stdout and stderr logs in JSON format directly to Google Cloud Logging. SREs tail logs in real time via CLI:

# Tail live production API logs
gcloud run services logs tail gercia-server-prd \
    --project=gercia-gcp \
    --region=southamerica-east1

# Filter for errors and exceptions
gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=gercia-server-prd AND severity>=ERROR" \
    --project=gercia-gcp \
    --limit=20 \
    --format="json(timestamp, textPayload, jsonPayload.message)"