Gnu Group Learning AcademyGnu Group ↗
Platform Engineering Fundamentals · Module 09 of 12

Observability, scorecards and operational readiness

Make operational readiness part of the platform product by connecting ownership, telemetry, SLOs, runbooks and scorecards to concrete remediation rather than vanity compliance percentages.

Learning objectives

By the end of this module, you should be able to:

  • Define minimum observability/readiness capabilities for a golden path.
  • Use scorecards to drive actionable improvement rather than rank teams.
  • Connect service metadata to dashboards, alerts, SLOs and runbooks.

The platform should create observability hooks by default

Generated services should have a clear path to logs, metrics, traces, dashboards and alert ownership. The platform can supply conventions and integrations; application teams still own meaningful instrumentation and service objectives.

Scorecards need actionable rules

A useful scorecard answers “what should I fix next and why?” Rules should be evidence-based, owned and linked to remediation. A single maturity score with no context is weak feedback.

Operational readiness is a release capability

Before production exposure, confirm owner, health signals, SLO/alert strategy, runbook, rollback and support path.

Worked example

Readiness evidence

owner ✓  dashboard ✓  SLO ✓  alert route ✓  runbook ✓  rollback ✓
  • Each item points to inspectable evidence.
  • The platform can automate detection, but teams still need to maintain service-specific correctness.
Core lab · account-free

Lab 09 — Generate an actionable readiness scorecard

Goal: Evaluate two services and list missing controls rather than only a numeric score.

Before you start

  • No cloud account required.
  • Core lab uses bash/Python 3 and local files only.
STEP 1

Create evidence

cat > /tmp/readiness.json <<'EOF'
[{"service":"orders","owner":true,"dashboard":true,"slo":true,"runbook":true,"rollback":true},{"service":"worker","owner":true,"dashboard":true,"slo":false,"runbook":false,"rollback":true}]
EOF
STEP 2

Report gaps

python3 - <<'PY2'
import json
for s in json.load(open('/tmp/readiness.json')):
 gaps=[k for k,v in s.items() if k!='service' and v is not True]
 print(s['service'], 'READY' if not gaps else 'FIX '+','.join(gaps))
PY2
STEP 3

Attach remediation

For each missing rule, define the documentation/template/action that helps the team fix it.

Verify

  • The incomplete service lists SLO and runbook as gaps.
  • The output is actionable rather than just a percentage.

Expected outcome

  • A readiness report with concrete remediation targets.

Diagnose / troubleshoot

  • If a rule cannot be measured reproducibly, refine the evidence source.
  • If teams game a score, focus on outcome/evidence instead of leaderboard behavior.
Real-world connection

Platform scorecards are most useful as feedback loops that connect standards to specific developer actions.

Real-tool practicum · optional but recommended

Optional tool lab — catalog scorecard concepts

Inspect how your portal/catalog could link entity ownership to dashboard, SLO and runbook metadata.

Prerequisites

  • Use a disposable local lab or organization-approved sandbox.
  • Pin tool versions in real platform automation; do not blindly depend on latest.

Cost / risk

  • Core learning is account-free. Optional external/sandbox tools may consume local CPU/RAM; do not use production credentials or billable cloud resources.

Warnings

  • Do not point training automation at production clusters, repositories or cloud accounts.
  • A successful command is not proof of a good platform interface; validate the developer outcome and guardrails.
TOOL 1
printf '%s
' 'orders-api owner=payments dashboard=/d/orders slo=99.9 runbook=/docs/orders'
Avoid these traps

Common mistakes

  • Using one opaque score as the only definition of service quality.
  • Making platform own application-specific SLOs.
  • Generating dashboards that nobody owns or understands.
Knowledge check

Can you connect the developer need to a platform contract?

Three concept checks plus one scenario check.

1What makes a scorecard rule useful?

It has reproducible evidence, a clear owner, rationale and actionable remediation.

2What observability should a golden path provide?

A supported path to telemetry, dashboards/queries, alert ownership and service objectives while leaving meaningful instrumentation to the service team.

3Why link runbooks to the catalog?

Operators can move from the service entity to current ownership and recovery guidance quickly.

4Scenario: a service scores 95/100 but has no tested rollback. What should the platform emphasize?

The concrete rollback gap and remediation, not the flattering aggregate score.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.