🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🏅 धडा 10 — Scorecards आणि maturity: प्रत्येक वर्गखोलीसाठी तयारीची तपासणी-यादी

📍 तुम्ही इथे आहात: 12 पैकी धडा 10 · मागील: lesson-09-policy-guardrails · पुढील: lesson-11-measuring

📦 या ब्रँचमध्ये काय आहे

धडे 01–09, आणि scorecards: प्रत्येक service वर चालवली जाणारी production-readiness तपासण्यांची weighted यादी, जिचे रूपांतर टक्केवारी आणि level मध्ये होते (gold, silver, bronze, not ready), आणि — सर्वात उपयोगी — पुढे काय दुरुस्त करायचे ते. CHECKS आणि score() idp/guard.py मध्ये, scorecards() idp/demo.py मध्ये.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

Policies (धडा 09) हे असलेच पाहिजे असे नियम आहेत: fire exit अडवलेली असेल तर कोणतीही खोली उघडत नाही. पण असायला हवे अशा अनेक गोष्टीही आहेत: कार्यालयात एक जादा किल्ली, दारावर कोणाला बोलवायचे ते सांगणारी चिठ्ठी, heating बंद पडले तर काय करायचे याचा आराखडा.

म्हणून सुविधा कार्यालय प्रत्येक वर्गखोलीसाठी एक तयारी-card ठेवते. 🏅 आठ तपासण्या. महत्त्वाच्या तपासण्या दुप्पट मोजल्या जातात: owner, on call असलेली व्यक्ती, चालणारे alarms, कोणतेही माहीत असलेले धोकादायक दोष नाहीत. प्रत्येक खोलीला गुण आणि एक बिल्ला मिळतो.

परीक्षा-खोली: 92% — gold. पुढे: पालकांना दिलेले वचन लिहून ठेवा (एक SLO).
फी-खोली: 50% — bronze. पुढे: तिला owner शोधा.
कॅन्टीन-खोली: 33% — not ready. पुढे: तिला owner शोधा.

कोणालाही लाजवण्यासाठी दीपिका हे गुण staff-room च्या भिंतीवर लावत नाही. प्रत्येक शिक्षिकेला तिचे स्वतःचे card आणि एक पुढची पायरी दिसते. Fees ने तीन गोष्टी दुरुस्त केल्या आणि ती bronze वरून silver आणि मग gold वर गेली.

🗺️ आकृती

flowchart LR
    c["📋 8 checks · total weight 12<br/>owner 2 · on-call 2 · alerts 2 · no critical CVEs 2<br/>runbook 1 · pipeline v2.x 1 · SLO 1 · deps 1"] --> s["🧮 weighted %"]
    s --> l{"🏅 level"}
    l --> g["🥇 gold ≥ 90<br/>exam-results 92%"]
    l --> sv["🥈 silver ≥ 70<br/>timetable 83%"]
    l --> b["🥉 bronze ≥ 50<br/>library-search 58% · fees 50%"]
    l --> n["⛔ not ready<br/>canteen-orders 33%"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/platform-engineering/lesson-diagrams.html#l10

❓ काय

Scorecard — प्रत्येक catalog entry (धडा 04) वर तपासल्या जाणाऱ्या checks चा संच, गुण किंवा level म्हणून दाखवलेला. Port, Cortex आणि OpsLevel सारख्या portals मध्ये scorecards आधीपासूनच असतात; Backstage मध्ये open-source Tech Insights plugin आणि Spotify चे commercial Soundcheck plugin ते पुरवतात.
Production readiness — इतर जण एखाद्या service वर अवलंबून राहू शकतील इतकी ती तयार आहे का: owner असलेली, observable, on-call ने झाकलेली, पुन्हा उभी करता येणारी, patched. Google च्या SRE पुस्तकांमध्ये Production Readiness Review चे वर्णन आहे, जे SREs एखादी service हाती घेण्याआधी हे प्रश्न विचारते.
Weight — एखादा check किती महत्त्वाचा आहे. इथे incident वर सर्वात जास्त परिणाम करणारे चार checks (owner, on-call, alerts, critical vulnerabilities) यांचे weight 2 आहे; बाकीच्यांचे 1.
Level / maturity — गुणांवरचा पट्टा (या lab मध्ये gold ≥ 90, silver ≥ 70, bronze ≥ 50). या मर्यादा प्रत्येक संस्था स्वतः ठरवते.
Next step — सर्वात जास्त weight असलेला अपूर्ण check. Scorecard to-do यादी म्हणून सर्वात उपयोगी ठरतो, एका वेळी एक गोष्ट.
Scorecard विरुद्ध policy — policy (धडा 09) कधीच घडू नये ते अडवते; scorecard जे खरे असायला हवे त्याचा मागोवा घेतो आणि त्याला प्रोत्साहन देतो. बहुतेक services एखादा check पास करू लागल्या की तो scorecard मधून policy मध्ये नेणे हे विचारपूर्वक उचललेले पाऊल असते.

🤔 का

कारण नाहीतर "ही service production ready आहे का?" याचे उत्तर अंदाजाने, एकदाच, launch च्या वेळी दिले जाते, आणि पुन्हा कधीच नाही. Scorecard प्रत्येक service ला तेच प्रश्न, सतत, platform कडे आधीच असलेल्या data वरून विचारतो (catalog, pipeline version, vulnerability scan). तो teams ना त्या कुठे आहेत ते दाखवतो आणि कार्यालयाला platform ने कुठे मदत करायला हवी ते — जर अर्ध्या services मध्ये "alerts defined" नसेल, तर तो एक गहाळ kit आहे, पन्नास आळशी teams नाहीत.

🔧 कसे (या repo मध्ये)

idp/guard.py मधील CHECKS ही (check, weight) ची यादी आहे, एकूण weight 12. score(passed) पास झालेल्या checks चे weights बेरीज करतो, 12 ने भागतो, पूर्ण टक्क्यापर्यंत round करतो, level निवडतो, आणि अपूर्ण checks सर्वात जड आधी अशा क्रमाने देतो — म्हणजे missing[0] हीच पुढची पायरी. idp/demo.py मधील scorecards() catalog मधील पाच services ना गुण देतो.

🧪 करून पाहा

python3 idp/demo.py scorecards
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from guard import CHECKS, score
everything = {c for c, _ in CHECKS}
fees = everything - {"has an owner", "on-call rota set", "no critical CVEs"}
print("fees today:", score(fees))
for fix in ("has an owner", "on-call rota set", "no critical CVEs"):
    fees = fees | {fix}; pct, level, missing = score(fees)
    print(f"+ {fix:<17} → {pct:>3}% {level}")
print("only light checks:", score({"has a runbook", "pipeline on v2.x", "SLO written", "dependencies declared"})[:2])
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

scorecards हे छापते:

── production readiness: 8 weighted checks (total weight 12) · gold ≥ 90 · silver ≥ 70 · bronze ≥ 50
   exam-results     92% gold      next: SLO written
   timetable        83% silver    next: has a runbook
   library-search   58% bronze    next: on-call rota set
   fees             50% bronze    next: has an owner
   canteen-orders   33% not ready next: has an owner

तुमचा snippet हे छापतो:

fees today: (50, 'bronze', ['has an owner', 'on-call rota set', 'no critical CVEs'])
+ has an owner      →  67% bronze
+ on-call rota set  →  83% silver
+ no critical CVEs  → 100% gold

🏁 तुम्ही आत्ताच काय सिद्ध केले

Fees तीन पायऱ्यांत 50% वरून 100% वर गेली, प्रत्येक पायरी card नेच सुचवली. चार checks — फक्त हलके — पास करणाऱ्या service ला 33% मिळतात आणि ती "not ready" ठरते: weights मुळे runbook आणि SLO गहाळ owner आणि on-call लपवू शकत नाहीत. धडा 04 मधील दोन orphans (fees, canteen-orders) तळाशी आहेत, त्याच कारणाने ज्यासाठी त्यांना तिथे खूण केली होती: owner नाही. Catalog, pipeline version (धडा 07) आणि scan चे निकाल एकाच card मध्ये येतात.

📏 शिकवण्यासाठीचा नमुना: खरे scorecards प्रत्येक check live data वरून मोजतात (catalog, CI, scanner, paging tool). इथे पास झालेले checks एक set म्हणून दिले आहेत.

⚠️ नेहमीच्या चुका

मोठ्या screen वर क्रमवारीचा तक्ता — teams checks शी खेळ करतात किंवा पाहणेच बंद करतात
ज्यावर कोणीच काही करू शकत नाही असे checks ("जास्त reliable व्हा")
एकाच वेळी खूप जास्त checks; महत्त्वाच्या पाचने सुरुवात करा आणि हळूहळू वाढवा
spreadsheet मध्ये हाताने मोजलेले गुण — आठवड्याभरात जुने होतात
अनेक teams एकाच check मध्ये का नापास होतात हे कधीच न विचारणे (सहसा कारण: गहाळ platform kit)

🏭 प्रत्यक्ष वापरात

Backstage मध्ये, open-source Tech Insights plugin प्रत्येक entity बद्दल ठरलेल्या वेळापत्रकाने facts गोळा करते (उदा. "has an owner", "has TechDocs") आणि त्या facts वर checks तपासते; तुमच्या version साठीचे configuration त्याच्या documentation मध्ये दिले आहे.

Port मध्ये, scorecard एका blueprint (entity type) चा भाग असतो आणि प्रत्येक rule ला एक level आणि entity च्या properties वर अटी असतात. Tool कोणतेही असो, scorecard त्यामागच्या data इतकाच चांगला असतो — म्हणून पहिले काम सहसा catalog पूर्ण करणे हे असते (धडा 04).

तुमच्या स्वतःच्या export मधून सगळ्या services मधली सर्वात सामान्य उणीव पटकन पाहण्याचा मार्ग:

# on a real account: scores.csv from your portal — service,check,passed
awk -F, '$3=="false"{miss[$2]++} END{for (c in miss) print miss[c], c}' scores.csv | sort -rn | head -5

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: ज्या check मध्ये बहुतेक services नापास होतात, तोच कार्यालयाचा पुढचा kit आहे. Scorecards service teams इतकेच platform team साठीही feedback आहेत.

⏭️ पुढे

Scorecards services मोजतात. पुढे: कार्यालयाचेच मोजमाप — platform मुळे delivery जलद आणि सुरक्षित होत आहे का, आणि कोणालाही हानी न पोहोचवता ते कसे मोजायचे.

git checkout lesson-11-measuring

🏅 Lesson 10 — Scorecards & maturity: a readiness checklist per classroom

📍 You are here: Lesson 10 of 12 · Previous: lesson-09-policy-guardrails · Next: lesson-11-measuring

📦 What's in this branch

Lessons 01–09, plus scorecards: a weighted checklist of production-readiness checks run against every service, turned into a percentage and a level (gold, silver, bronze, not ready), and — most useful — the next thing to fix. CHECKS and score() in idp/guard.py, scorecards() in idp/demo.py.

🧒 Explain like I'm 5

Policies (lesson 09) are the must rules: no room opens with a blocked fire exit. But there are many should things too: a spare key with the office, a note on the door saying who to call, a plan for when the heating breaks.

So the facilities office keeps a readiness card for every classroom. 🏅 Eight checks. The important ones count double: an owner, a person on call, alarms that work, no known dangerous faults. Each room gets a score and a badge.

Exam room: 92% — gold. Next: write down its promise to parents (an SLO).
Fees room: 50% — bronze. Next: find it an owner.
Canteen room: 33% — not ready. Next: find it an owner.

Dipika does not pin the scores on the staff-room wall to embarrass anyone. Each teacher sees her own card and the one next step. Fees fixed three things and went from bronze to silver to gold.

🗺️ Diagram

flowchart LR
    c["📋 8 checks · total weight 12<br/>owner 2 · on-call 2 · alerts 2 · no critical CVEs 2<br/>runbook 1 · pipeline v2.x 1 · SLO 1 · deps 1"] --> s["🧮 weighted %"]
    s --> l{"🏅 level"}
    l --> g["🥇 gold ≥ 90<br/>exam-results 92%"]
    l --> sv["🥈 silver ≥ 70<br/>timetable 83%"]
    l --> b["🥉 bronze ≥ 50<br/>library-search 58% · fees 50%"]
    l --> n["⛔ not ready<br/>canteen-orders 33%"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/platform-engineering/lesson-diagrams.html#l10

❓ What

Scorecard — a set of checks evaluated against each catalog entry (lesson 04), shown as a score or level. Portals such as Port, Cortex and OpsLevel have scorecards built in; in Backstage, the open-source Tech Insights plugin and Spotify's commercial Soundcheck plugin provide them.
Production readiness — whether a service is ready to be depended on: owned, observable, on-call covered, recoverable, patched. Google's SRE books describe a Production Readiness Review that asks these questions before SREs take on a service.
Weight — how much a check matters. Here the four checks that most affect an incident (owner, on-call, alerts, critical vulnerabilities) weigh 2; the rest weigh 1.
Level / maturity — a band over the score (gold ≥ 90, silver ≥ 70, bronze ≥ 50 in this lab). The thresholds are a choice each organisation makes.
Next step — the missing check with the highest weight. A scorecard is most useful as a to-do list, one item at a time.
Scorecard vs policy — policy (lesson 09) blocks what must never happen; a scorecard tracks what should be true and encourages it. Moving a check from scorecard to policy is a deliberate step, once most services pass it.

🤔 Why

Because "is this service production ready?" is otherwise answered by gut feeling, once, at launch, and never again. A scorecard asks the same questions of every service, all the time, from data the platform already has (the catalog, the pipeline version, the vulnerability scan). It shows teams where they stand and the office where the platform should help — if half the services miss "alerts defined", that is a missing kit, not fifty lazy teams.

🔧 How (in this repo)

CHECKS in idp/guard.py is a list of (check, weight) with total weight 12. score(passed) adds the weights of the passed checks, divides by 12, rounds to a whole percent, picks the level, and lists the missing checks heaviest first — so missing[0] is the next step. scorecards() in idp/demo.py scores five services from the catalog.

🧪 Try it

python3 idp/demo.py scorecards
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from guard import CHECKS, score
everything = {c for c, _ in CHECKS}
fees = everything - {"has an owner", "on-call rota set", "no critical CVEs"}
print("fees today:", score(fees))
for fix in ("has an owner", "on-call rota set", "no critical CVEs"):
    fees = fees | {fix}; pct, level, missing = score(fees)
    print(f"+ {fix:<17} → {pct:>3}% {level}")
print("only light checks:", score({"has a runbook", "pipeline on v2.x", "SLO written", "dependencies declared"})[:2])
EOF

✅ Verify — what you should see

scorecards prints:

── production readiness: 8 weighted checks (total weight 12) · gold ≥ 90 · silver ≥ 70 · bronze ≥ 50
   exam-results     92% gold      next: SLO written
   timetable        83% silver    next: has a runbook
   library-search   58% bronze    next: on-call rota set
   fees             50% bronze    next: has an owner
   canteen-orders   33% not ready next: has an owner

Your snippet prints:

fees today: (50, 'bronze', ['has an owner', 'on-call rota set', 'no critical CVEs'])
+ has an owner      →  67% bronze
+ on-call rota set  →  83% silver
+ no critical CVEs  → 100% gold

🏁 What you just proved

Fees went from 50% to 100% in three steps, each suggested by the card itself. A service that passes four checks — only the light ones — scores 33% and is "not ready": the weights make sure a runbook and an SLO cannot hide a missing owner and on-call. The two orphans from lesson 04 (fees, canteen-orders) are at the bottom for the same reason they were flagged there: no owner. The catalog, the pipeline version (lesson 07) and the scan results feed one card.

📏 Teaching model: real scorecards compute each check from live data (the catalog, CI, the scanner, the paging tool). Here the passed checks are given as a set.

⚠️ Common mistakes

a league table on a big screen — teams game the checks or stop looking
checks nobody can act on ("be more reliable")
too many checks at once; start with five that matter and add slowly
scores computed by hand in a spreadsheet — stale in a week
never asking why many teams fail the same check (usually: a missing platform kit)

🏭 In production

In Backstage, the open-source Tech Insights plugin collects facts about each entity on a schedule (for example, "has an owner", "has TechDocs") and evaluates checks on those facts; its documentation shows the configuration for your version.

In Port, a scorecard belongs to a blueprint (an entity type) and each rule has a level and conditions on the entity's properties. Whatever the tool, the scorecard is only as good as the data behind it — so the first work is usually making the catalog complete (lesson 04).

A quick way to see the most common gap across all services from your own export:

# on a real account: scores.csv from your portal — service,check,passed
awk -F, '$3=="false"{miss[$2]++} END{for (c in miss) print miss[c], c}' scores.csv | sort -rn | head -5

🏭 Why this matters in production: the check most services fail is the office's next kit. Scorecards are feedback for the platform team as much as for the service teams.

⏭️ Next

Scorecards measure services. Next: measuring the office itself — is the platform making delivery faster and safer, and how to measure that without harming anyone.

git checkout lesson-11-measuring

← Previouspolicy guardrails Next →measuring

This page is the lesson's README from the lesson-10-scorecards branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.