internal developer platform कसा चालतो, हे शाळेच्या सुविधा कार्यालयाच्या रूपात शिकवले आहे: प्रत्येक शिक्षिकेने स्वतःचा वर्ग-संच स्वतः बनवण्याऐवजी, कार्यालय तयार संच, एक सूची आणि एक बांधलेली वाट देते — नवीन शिक्षिकेला (एका team ला) काही मिनिटांत वर्ग (एक service) मिळतो, आणि कार्यालय शिक्षिकांना आपले ग्राहक मानते. प्रत्येक धडा म्हणजे एक शाळेची गोष्ट, त्यासोबत हाताने काढलेली आकृती आणि एक lab — आणि कार्यालय repo मध्येच आहे: शुद्ध Python मधले deterministic models (idp/, शून्य dependencies), जे तुम्ही बदलू आणि मोडू शकता.
# the 60-second wow — the facilities office, in your terminal:
git clone https://github.com/BaluRaut/learn-platform-engineering-school.git && cd learn-platform-engineering-school
python3 idp/demo.py # 12 lessons: tickets, templates, quotas, previews, guardrails, DORA
python3 idp/test_idp.py # 12 checks across the lessons
तुम्हाला काय दिसायला हवे (छाटलेले — यश असे दिसते):
═══ why ═══
── to open one classroom (ship one service) a teacher's team must handle 14 concerns alone
with the facilities office: the team keeps 4 (application code, tests, alerts, on-call for the service)
the office offers 10 as ready kits (Dockerfile, CI pipeline, Terraform, IAM, DNS + TLS …) — still visible, still changeable
── the ticket queue: 5 requests a day, the office finishes 4 a day, for 20 working days
finished 80 · still waiting 20 · average wait 2.0 days
a ticket finished on day 1 waited 0 days · one finished on day 20 waited 4 days — the line grows by 1 every day
'you build it, you run it' stays — the office removes the undifferentiated work, not the ownership
═══ product ═══
── Dipika (the facilities office) interviews 5 departments: hours lost per week, per pain
1. waiting for a database 15 h/week across 3 teams
2. writing CI YAML 7 h/week across 2 teams
3. finding a service's owner 5 h/week across 4 teams
4. preview environments 5 h/week across 2 teams
5. rotating secrets 3 h/week across 2 teams
── the roadmap starts at the top: self-service databases first, not the tool the office finds most fun
month 1: 20% of departments chose the paved path
month 3: 60% of departments chose the paved path
month 6: 80% of departments chose the paved path
adoption is earned, not mandated: if a team leaves the path, ask why — it is product feedback
═══ goldenpath ═══
── create ('python-service', 'Exam Results!', 'science') → refused:
• name 'Exam Results!' — use 3–31 lowercase letters, digits or dashes, starting with a letter, e.g. 'exam-results'
── create ('python-service', 'timetable', 'sciense') → refused:
• name 'timetable' is taken — pick another, or ask its owner in the catalog
• owner 'sciense' is not a known group — choose one of: facilities-office, library, maths, science
── create ('java-service', 'exam-results', 'science') → refused:
• no template 'java-service' — choose one of: python-service, static-site
── Katrina creates 'exam-results' from python-service v3 → 8 files, ready to push:
README.md
src/app.py
tests/test_app.py
Dockerfile
catalog-info.yaml
.github/workflows/ci.yml
deploy/values.yaml
docs/index.md
catalog-info.yaml:
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: exam-results
spec:
type: service
lifecycle: experimental
owner: science
a golden path is the easy way, not the only way — teams may leave it, and then they own what they change
═══ catalog ═══
── the catalog holds 8 entries owned by groups ['science', 'maths', 'library', 'facilities-office']
science owns ['exam-results', 'results-db']
maths owns ['parent-portal', 'timetable']
facilities-office owns ['auth']
orphans (no owner, or the owner group is gone): ['canteen-orders', 'fees']
broken references: [('fees', 'payments-api'), ('library-search', 'search-index')]
── blast radius — if auth breaks, these depend on it: ['canteen-orders', 'exam-results', 'fees', 'parent-portal', 'timetable']
if results-db breaks: ['exam-results', 'parent-portal']
the catalog is only as good as its freshness: keep catalog-info.yaml in each repo, next to the code
═══ selfservice ═══
── science's quota: 2 databases, 3 buckets, 2 queues, 6 CPU — requests go to the office's catalogue, not a ticket
postgres-medium results-db → ready: science-results-db {'owner': 'science', 'managed-by': 'facilities-office'}
postgres-small lab-db → ready: science-lab-db {'owner': 'science', 'managed-by': 'facilities-office'}
postgres-small extra-db → refused: science already uses 2/2 databases — delete one or ask for a bigger quota
mongodb notes-db → refused: 'mongodb' is not in the catalogue — offered: postgres-small, postgres-medium, bucket, queue (or ask the office to add it)
bucket lab-photos → ready: science-lab-photos {'owner': 'science', 'managed-by': 'facilities-office'}
queue grade-events → ready: science-grade-events {'owner': 'science', 'managed-by': 'facilities-office'}
used now: {'databases': 2, 'buckets': 1, 'queues': 1, 'cpu': 6}
quotas + a fixed menu make self-service safe; every refusal says what to do next
═══ previews ═══
── one preview environment per pull request · TTL 48 h (restarts on push) · at most 3 live
h1 pr-101 created → pr-101.preview.school.test
h5 pr-102 created → pr-102.preview.school.test
h10 pr-103 created → pr-103.preview.school.test
h20 pr-101 deleted (PR closed)
h30 pr-104 created → pr-104.preview.school.test
h40 pr-103 updated, TTL restarts
h41 pr-105 refused — 3 previews already live; retry when one closes
h53 pr-102 expired (TTL 48 h)
h70 pr-103 deleted (PR closed)
h78 pr-104 expired (TTL 48 h)
h120 pr-106 created → pr-106.preview.school.test
h168 pr-106 expired (TTL 48 h)
── after one week (168 h): 5 previews made · 223 environment-hours with cleanup · 674 if nobody ever deleted them
still live at the end: [] · abandoned PRs cost nothing after their TTL
═══ pipelines ═══
── the office publishes pipeline templates v1.0.0, v2.0.0 (adds SBOM + image scan), v2.1.0 (adds a dependency cache)
exam-results uses @v2 → runs v2.1.0 7 steps, 15 min (scans images)
timetable uses @v2.0.0 → runs v2.0.0 6 steps, 17 min (scans images)
library-search uses @v1 → runs v1.0.0 4 steps, 14 min
fees uses @copy → runs v1.0.0 (pasted copy) 4 steps, 14 min
'@v2' picked up v2.1.0 by itself · '@v2.0.0' waits for a deliberate bump · '@v1' has no image scan · the pasted copy never changes
one fix in the template reaches every service that follows it — pin exact versions (or commit SHAs) where you need control
═══ secrets ═══
── secrets live in the office's store, by path; a team reads its own paths only
science reads teams/science/results-db-password → ok · teams/science/results-db-password v1 (22 characters, value hidden)
science reads teams/maths/timetable-api-key → denied · science may read teams/science/* only — ask the owner of teams/maths/timetable-api-key to share it
── rotation: the password is now v2; consumers still on the old version: ['exam-results', 'lab-worker']
exam-results reloads → still stale: ['lab-worker'] · keep v1 valid until nobody uses it, then revoke
── config in layers (defaults → environment → service), each value explains where it came from:
log_level = info (from defaults)
replicas = 3 (from production)
feature_new_grades = True (from exam-results)
═══ policy ═══
── audit mode: exam-results → allowed with warnings (4 findings)
── enforce mode: exam-results → denied (4 findings)
✗ owner-label no owner label → fix: add labels.owner: <your group> (the catalog uses it to page the right people)
✗ no-latest-tag image tag is 'latest' or missing → fix: pin a version such as :1.4.2 (the paved pipeline tags every build)
✗ limits-set no CPU/memory limits → fix: add limits: {cpu: 500m, memory: 256Mi} (the template's defaults)
✗ two-replicas-in-prod 1 replica in production → fix: set replicas: 2 or more so one restart is not an outage
── after the four fixes → allowed
a guardrail that says 'no' and 'here is how' teaches; one that only says 'no' sends people around it
═══ 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
a scorecard is a to-do list for a team, not a league table to shame them
═══ measure ═══
── the four DORA keys for the science department, 4 weeks each (teaching data):
before (tickets) 1.0 deploys/week · lead time 150.0 h · change failure rate 50% · recovery 23.0 h
after (paved path) 3.0 deploys/week · lead time 5.0 h · change failure rate 8% · recovery 2.0 h
── time to first deploy for a new team: 4 tickets in a row (repo, pipeline, database, DNS) × 2.0 days ≈ 8.0 days
on the golden path: scaffold + self-service database + one pipeline run of 15 min — the same day
── weaponize the metric ('deploy more!'): count every re-run of the deploy job → 9.0 deploys/week, lead time 5.0 h
the number tripled; the same 12 changes reached the students — nothing real improved (Goodhart's law)
SPACE: Satisfaction, Performance, Activity, Communication, Efficiency — mix numbers with asking people; compare a team with itself
═══ portal ═══
── the portal page for exam-results (one place, gathered from every part of the office):
owner science · lifecycle production · depends on results-db, auth
depended on by parent-portal
scorecard 92% (gold) · next: SLO written
policy: allowed with warnings · bucket is public → set public_bucket: false and serve files through the CDN kit
pipeline v2 → v2.1.0 · preview environments live: 1
DORA: 3.0 deploys/week · lead time 5.0 h · failure rate 8% · recovery 2.0 h
── the whole picture: pains → a product roadmap → golden paths → a catalog → self-service → previews → paved pipelines
→ secrets as a service → guardrails that explain → scorecards → honest measures → one portal
✅ done — every teacher has a classroom
idp/ आहे, platform/ नाही, कारण ते Python चे स्वतःचे platform module झाकून टाकेल); खरे platforms Backstage किंवा Port (portal आणि catalog), Crossplane किंवा Terraform (infrastructure), Argo CD (delivery), GitHub Actions किंवा GitLab CI (pipelines), Vault किंवा cloud secrets manager (secrets) आणि OPA Gatekeeper किंवा Kyverno (policy) यांपासून बनतात. ही शाळा कुठे बसते: CI/CD शाळा एक pipeline बांधते आणि Argo CD शाळा ती deliver करते; ही शाळा त्यांना प्रत्येक team साठी एक बांधलेला रस्ता बनवते.संपूर्ण कोर्स एका कॅनव्हासवर. 4K आवृत्तीसाठी क्लिक करा.
एक git branch = एक कल्पना; branch 04 मध्ये धडे 01–04 आहेत. idp/ प्रत्येक वेळी चालवल्यावर तेच आकडे छापते.
lesson-01-why-platformsधडा वाचा →आकृती पहा ↗lesson-02-platform-as-productधडा वाचा →आकृती पहा ↗lesson-03-golden-pathsधडा वाचा →आकृती पहा ↗lesson-04-service-catalogधडा वाचा →आकृती पहा ↗teams स्वतःची मदत स्वतः करतात: quotas मधले resources, आपोआप साफ होणारी environments, सामायिक pipelines, rotation असलेली secrets.
lesson-05-self-service-infraधडा वाचा →आकृती पहा ↗lesson-06-preview-environmentsधडा वाचा →आकृती पहा ↗lesson-07-paved-pipelinesधडा वाचा →आकृती पहा ↗lesson-08-secrets-configधडा वाचा →आकृती पहा ↗'नाही' ची भिंत न उभारता self-service सुरक्षित ठेवणे, आणि कार्यालयाचा उपयोग होतोय का हे प्रामाणिकपणे दाखवणे.
lesson-09-policy-guardrailsधडा वाचा →आकृती पहा ↗lesson-10-scorecardsधडा वाचा →आकृती पहा ↗lesson-11-measuringधडा वाचा →आकृती पहा ↗lesson-12-developer-portalधडा वाचा →आकृती पहा ↗@v2, @v2.0.0 आणि चिकटवलेली प्रत यांत फरक काय? (8) जुने secret रद्द करण्याआधी ते rotate का करावे? (9) संरक्षक नियम अडवण्याऐवजी शिकवतो तो कशामुळे? (10) DORA चे आकडे कधीही लक्ष्य का बनू नयेत?प्रत्येक धडा एका क्रमांकित बॉक्स-आणि-बाण आकृतीत — स्वतंत्र पानावरही.
प्रत्येक शिक्षिका स्वतःचा वर्ग-संच बनवते — cognitive load, तिकिटांची रांग आणि 'you build it, you run it' चा थकवा.
कतरिना नवी science शिक्षिका आहे, आणि तिला एक वर्ग हवा आहे. बाकडी, कुलूप, socket आणि first-aid box तिला स्वतः शोधावे लागतात. इतर शिक्षिका दीपिकाच्या office ला अर्ज लिहितात. रोज 5 अर्ज येतात, आणि दीपिका फक्त 4 पूर्ण करू शकते. म्हणून ढीग रोज 1 ने वाढतो. मग office एका कपाटावर तयार kits ठेवते, आणि कतरिना एक kit घेते.
प्रत्येक शिक्षिका आपला classroom kit स्वतः बनवत असे, किंवा facilities office च्या ढिगात विनंती लिहून वाट पाहत असे.
एक service चालू करायला team ला 14 कामे एकटीने करावी लागत; office मुळे ती 4 ठेवते आणि 10 तयार kits म्हणून घेते.
रोज 5 विनंत्या येतात आणि दीपिका 4 पूर्ण करते: 20 दिवसांनी 80 पूर्ण, 20 अजून रांगेत, सरासरी वाट 2.0 दिवस.
ढीग रोज 1 ने वाढतो: पहिल्या दिवशी 0 दिवस वाट, 20 व्या दिवशी 4 दिवस. नुसत्या जास्त मेहनतीने रांग कधीच संपत नाही.
पुढच्या धड्यात शिक्षिका ग्राहक बनतात: त्यांना विचारा, त्रास क्रमाने लावा, आणि सर्वात मोठा त्रास आधी सोडवा.
शिक्षिका या कार्यालयाच्या ग्राहक आहेत — मुलाखती, त्रासानुसार क्रम लावलेला roadmap, सक्तीऐवजी स्वेच्छेने स्वीकार.
दीपिका या महिन्यात एक नवा kit बनवू शकते. ती चमकदार smart board बनवू शकली असती, कारण ते मजेदार आहे. त्याऐवजी ती प्रत्येक विभागाला विचारते की त्यांचा वेळ कशात वाया जातो. Database ची वाट पाहण्यात आठवड्याला 15 तास जातात. म्हणून तो kit आधी. ती कोणालाही तो वापरायची सक्ती करत नाही. Arts विभाग नको म्हणतो, तेव्हा ती का ते विचारते.
मध्यवर्ती team ला आवडलेले tool ती निवडत असे, आणि मग ठरलेल्या तारखेपर्यंत प्रत्येक विभागाला ते वापरायला सांगत असे.
Platform as a product: दीपिका 5 विभागांशी बोलते आणि दर आठवड्याला वाया जाणाऱ्या तासांनुसार त्रास क्रमाने लावते.
Database ची वाट 3 teams मध्ये 15 h/week खाते, CI YAML 7 h, owner शोधणे 5 h: म्हणून databases पहिल्यांदा.
Adoption मिळवावा लागतो: पहिल्या महिन्यात 20%, तिसऱ्यात 60%, सहाव्यात 80%. दूर राहणारी team म्हणजे feedback.
पुढच्या धड्यात लोकांनी मागितलेला पहिला kit बनतो: मिनिटांत नवी service बनवणारा golden-path template.
तयार वर्ग-संच — versioned template मधून service चा सांगाडा बनवणारा scaffolder.
कतरिना office कडे exam-results नावाचा नवा classroom kit मागते. दीपिका कपाटातून एक box काढते: python-service, version 3. आत एकमेकांना जुळणाऱ्या 8 गोष्टी आहेत. एका मैत्रिणीने आधी 'Exam Results!' हे नाव वापरून पाहिले. दीपिकाने फक्त नाही म्हटले नाही. ती म्हणाली: लहान अक्षरे आणि dash वापरा, जसे exam-results. Kit हा सोपा मार्ग आहे, एकमेव नाही.
प्रत्येक नवी service रिकाम्या repo मधून सुरू होत असे, किंवा जवळ असलेल्या जुन्या repo ची copy करून.
Golden path म्हणजे version असलेला template: python-service v3 src/app.py पासून catalog-info.yaml पर्यंत 8 files बनवतो.
Scaffolder नावाचा नियम, मोकळे नाव, ओळखीचा owner आणि template तपासतो, आणि प्रत्येक नकारात दुरुस्ती सांगतो.
'Exam Results!' ला 'exam-results वापरा' आणि 'sciense' ला खरे 4 groups सांगितले जातात: शिकवणारा नकार, भिंत नाही.
पुढचा धडा प्रत्येक service बरोबर येणारी catalog-info.yaml वाचून शाळेची services ची नोंदवही बनवतो.
प्रत्येक वर्गखोलीची नोंदवही — मालक, dependencies, अनाथ services आणि blast radius.
Office प्रत्येक खोलीची नोंदवही ठेवते: ती कोणाची आहे आणि तिला काय लागते. एका सकाळी sign-in system, auth, बंद पडते. दीपिका बाण उलटे फिरून पाहते आणि तिला 5 खोल्या अडचणीत दिसतात. तिला कोणाच्याच मालकीच्या नसलेल्या खोल्याही सापडतात: canteen-orders आणि fees. त्या बंद पडल्या तर कोणालाच फोन जात नाही. म्हणून प्रत्येक खोलीला नाव असलेला owner हवा.
Service बंद पडेपर्यंत तिचा owner कोण हे कोणालाच माहीत नसे; लोक chat मध्ये विचारत, आणि काही उत्तरे वर्षांपूर्वीची असत.
Service catalog म्हणजे नोंदवही: 8 नोंदी, प्रत्येकीला owner, lifecycle आणि ती कशावर अवलंबून आहे याची माहिती.
बाण उलटे फिरा: auth बंद पडले तर 5 services अडतात; results-db बंद पडले तर exam-results आणि parent-portal.
ती 2 orphans (canteen-orders, fees) आणि 2 तुटलेले संदर्भ दाखवते: ते बंद पडले तर कोणालाच फोन जात नाही.
पुढच्या धड्यात teams स्वतःची मदत करतात: menu मधून database मागवा, स्वतःच्या quota च्या आत.
कार्यालयाकडे मागा, लगेच मिळवा — प्रत्येक team च्या quota मध्ये resources चा ठरलेला मेनू.
आता office च्या भिंतीवर एक menu आहे: लहान कपाट, मोठे कपाट, एक box आणि कप्प्यांचा rack. Science ला ठरावीक मर्यादा आहे: 2 कपाटे आणि 6 फरश्या. कतरिना एक मोठे आणि एक लहान कपाट मागवते, आणि ती लगेच मिळतात. तिसऱ्या कपाटाला नकार मिळतो, आणि काय करायचे याची चिठ्ठीही. आता कोणीच ढिगात वाट पाहत नाही.
Database म्हणजे ticket, office च्या रांगेत वाट, आणि दरवेळी थोडा वेगळा बनलेला निकाल.
Self-service infrastructure: ठरलेला menu (postgres-small, postgres-medium, bucket, queue) आणि प्रत्येक team ला quota.
Science ला 2 databases आणि 6 CPU मिळतात: results-db (4 CPU) आणि lab-db (2 CPU) लगेच तयार, extra-db ला नकार.
Quota मुळे एक team संपूर्ण शाळा भरू शकत नाही, आणि प्रत्येक resource ला owner=science, managed-by=facilities-office tag असतो.
पुढचा धडा मागणीनुसार संपूर्ण environments देतो: प्रत्येक pull request ला एक trial classroom, TTL ने साफ होणारा.
प्रत्येक बदलासाठी एक चाचणी वर्गखोली — प्रत्येक pull request साठी preview environments, time-to-live नंतर साफ केली जातात.
कतरिना खरी lab बदलण्याआधी नवी मांडणी करून पाहू इच्छिते. Office तिला pr-101 नावाची trial खोली देते. तिने 'झाले' म्हटले की खोली रिकामी केली जाते. 48 तास कोणीच हात लावला नाही तरीही ती रिकामी केली जाते. फक्त 3 trial खोल्या आहेत. एका आठवड्यात 674 ऐवजी फक्त 223 तास दिवे लागले.
Teams एकच staging environment वाटून घेत, ते वापरायला रांग लावत, आणि कोणालाही आठवत नसलेल्या test copies चालू ठेवत.
प्रत्येक pull request ला एक preview environment, जसे pr-101.preview.school.test: TTL 48 h, प्रत्येक push ने पुन्हा सुरू.
PR बंद झाला की room हटते, 48 h push नाही तर ती expire होते, आणि जास्तीत जास्त 3 चालू: h41 ला pr-105 ला नकार.
एका आठवड्यात 5 previews cleanup सह 223 environment-hours वापरतात, कोणीच न हटवल्यास 674 वापरले असते.
पुढचा धडा production पर्यंतचा रस्ता बांधतो: प्रत्येक service वापरू शकेल असा एक सामायिक, version असलेला pipeline template.
production कडे जाणारा एकच सामायिक रस्ता — पुन्हा वापरता येणारे, versioned pipeline templates आणि pinning म्हणजे काय.
प्रत्येक वर्गाला सकाळी तेच काम करावे लागते: कुलूप उघडणे, fire exit तपासणे, दिवे लावणे. Office एक routine card लिहिते आणि त्याला version 2 म्हणते. त्यात smoke-alarm ची पायरी जोडली की कतरिनाला ती दुसऱ्या सकाळी मिळते, कारण तिने 'नवीनतम version 2' म्हटले होते. ऐश्वर्याने 'नेमके 2.0' म्हटले, म्हणून ती वाट पाहते. Fees office ने वर्षांपूर्वी card 1 ची photocopy केली, आणि तिच्यापर्यंत काहीच पोहोचत नाही.
प्रत्येक repo ची स्वतःची pipeline file होती, एकदा copy केलेली आणि वर्षानुवर्षे हाताने बदललेली, म्हणून दोन सारख्या नव्हत्या.
Office pipeline templates प्रकाशित करते: v1.0.0, v2.0.0 (SBOM आणि image scan जोडतो) आणि v2.1.0 (cache जोडतो).
@v2 15 min मध्ये v2.1.0 चालवतो, @v2.0.0 17 min मध्ये v2.0.0, @v1 मध्ये image scan नाही, आणि pasted copy कधीच बदलत नाही.
Template मधील एक दुरुस्ती त्याला follow करणाऱ्या प्रत्येक service पर्यंत पोहोचते; नियंत्रण हवे तिथे exact version किंवा SHA pin करा.
पुढचा धडा किल्ल्यांचे कपाट उघडतो: प्रत्येक team चे secrets, versions आणि rotation सह, आणि स्पष्ट layers मधील settings.
किल्ल्यांचे कपाट — प्रत्येक team ची secrets, versions आणि rotation सह; config स्पष्ट केलेल्या थरांमध्ये.
Office कडे प्रत्येक विभागासाठी एक खुंटी असलेले किल्ल्यांचे कपाट आहे. कतरिना science ची किल्ली घेते, पण maths ची किल्ली तिची नाही. मग दीपिका कुलूप बदलते आणि किल्ली version 2 टांगते. exam-results ची लिपिक आपली किल्ली बदलते, पण lab worker अजून परत आलेली नाही. म्हणून सगळ्यांकडे नवी किल्ली येईपर्यंत दीपिका जुने कुलूप चालू ठेवते.
Passwords wiki pages आणि .env files मध्ये पडलेले असत; एक बदलला की जुने value वापरणारे सगळे बंद पडत.
Office चा secret store path नुसार चालतो: science फक्त teams/science/* वाचू शकते; teams/maths/* ला नकार.
v2 वर rotate करा: exam-results आणि lab-worker stale आहेत; exam-results reload करते, आणि फक्त lab-worker v1 वर राहते.
कोणीच वापरत नाही तोपर्यंत v1 चालू ठेवा, मग revoke करा; config layers दाखवतात की replicas = 3 production मधून आले.
पुढचा धडा सुरक्षेचे नियम code मध्ये लिहितो: काय चुकले आणि कसे दुरुस्त करायचे हे सांगणारे guardrails.
फक्त 'नाही' न म्हणता दुरुस्ती कशी करायची ते सांगणारे सुरक्षा नियम — audit आणि enforce modes मधले policy as code.
शाळेचे खोल्यांसाठी सुरक्षेचे नियम आहेत: नाव असलेला owner, पुरेसे दरवाजे, कुलूपबंद कपाटे. आधीचा तपासणीस फक्त FAILED म्हणून निघून जात असे. आता checklist लिहिलेली आहे आणि प्रत्येक बदलावर चालते. प्रत्येक अडचणीसाठी ती काय चुकले आणि कसे दुरुस्त करायचे ते सांगते. सुरुवातीला ती फक्त इशारा देते. कतरिनाच्या खोलीत 4 अडचणी होत्या, तिने चारही दुरुस्त केल्या, आणि खोली उघडली.
एक व्यक्ती लिहिलेल्या यादीशी बदल तपासत असे आणि कारण न सांगता 'failed' म्हणत असे, किंवा कोणी तपासतच नसे.
Policy as code: प्रत्येक बदलावर 5 नियम चालतात, प्रत्येकात message आणि दुरुस्ती, audit किंवा enforce mode मध्ये.
exam-results 4 नियमांत नापास: audit warnings सह परवानगी देतो, enforce नकार देतो; चार दुरुस्त्यांनंतर परवानगी मिळते.
'नाही' आणि 'असे करा' सांगणारा guardrail शिकवतो; फक्त 'नाही' म्हणणारा लोकांना त्याला वळसा घालायला लावतो.
पुढचा धडा 'करायला हवे' ची यादी जोडतो: प्रत्येक service चे weighted checks आणि एक पुढची पायरी असलेले readiness scorecard.
प्रत्येक वर्गखोलीसाठी तयारीची तपासणी-यादी — वजन असलेल्या तपासण्या, स्तर, आणि पुढे काय दुरुस्त करायचे.
Office प्रत्येक वर्गासाठी 8 तपासण्या असलेले readiness card ठेवते. महत्त्वाच्या तपासण्या दुप्पट मोजल्या जातात, जसे owner असणे. Exam खोलीला 92% मिळतात आणि gold मिळते. Canteen खोलीला 33% मिळतात आणि ती अजून तयार नाही. कोणालाही लाजवण्यासाठी गुण भिंतीवर लावले जात नाहीत. प्रत्येक शिक्षिका फक्त आपले card आणि पुढची एक पायरी पाहते.
Production readiness कोणाच्या तरी डोक्यात किंवा लांबलचक wiki checklist मध्ये असे, जी कोणी पूर्ण किंवा अद्ययावत करत नसे.
Scorecard: 8 weighted checks, एकूण weight 12, आणि levels gold 90, silver 70, bronze 50.
exam-results 92% gold, timetable 83% silver, library-search 58%, fees 50% bronze, canteen-orders 33% not ready.
प्रत्येक team ला एक पुढची पायरी दिसते: fees आधी owner, मग on-call, मग CVEs जोडते आणि 50 → 67 → 83 → 100% चढते.
पुढचा धडा कठीण प्रश्न विचारतो: office खरेच मदत करते का? DORA च्या चार keys, SPACE आणि प्रामाणिक आकडे.
कार्यालयाचा उपयोग होतोय का? DORA च्या चार keys, पहिल्या deploy पर्यंतचा वेळ, SPACE, आणि आकड्यांचा शस्त्र म्हणून वापर न करणे.
मुख्याध्यापिका दीपिकाला विचारतात: office ची मदत झाली का? दीपिका science चे बदल तपासते. Kits आधी: आठवड्याला 1 बदल, कल्पनेपासून चालू होईपर्यंत 150 तास. नंतर: आठवड्याला 3, फक्त 5 तास. मग कोणीतरी आठवड्याला 9 बदलांचा आदेश देते, आणि एक विभाग तोच बदल तीनदा मोजतो. आकडा वाढला, पण काहीच सुधारले नाही. म्हणून दीपिका शिक्षिकांनाही विचारते.
Platform ची किंमत भावनेवरून, किंवा office दर महिन्याला किती tickets बंद करते यावरून ठरवली जात असे.
DORA च्या चार keys: दर आठवड्याचे deploys, lead time, change failure rate आणि recovery time, आणि लोकांना विचारणे (SPACE).
Science 1.0 वरून 3.0 deploys/week, lead time 150 h वरून 5 h, failures 50% वरून 8%, आणि recovery 23 h वरून 2 h वर आली.
Re-runs मोजले तर त्याच 12 बदलांसाठी 9.0 deploys/week दिसतात: आकडा वाढतो पण काहीच सुधारत नाही.
पुढचा धडा सगळे एका पानावर आणतो: developer portal, office चे प्रत्येक काम एकत्र करणारा front desk.
स्वागत कक्ष — प्रत्येक service साठी Backstage-पद्धतीचे portal पान, आणि कार्यालयाचा संपूर्ण नकाशा.
Office मोठे झाले आहे: kits, नोंदवही, menu, trial खोल्या, किल्ल्यांचे कपाट आणि checklist. नव्या शिक्षिकेला नकाशा लागेल. म्हणून दीपिका एक front desk उघडते. कतरिना exam-results म्हणते, आणि तिला एक पान मिळते: owner, gold गुण, एक इशारा आणि आठवड्याला 3 बदल. Desk स्वतः काम करत नाही. ते सगळे सहज सापडेल असे करते.
नव्या शिक्षिकेला kit shelf, नोंदवही, menu, किल्ल्यांचे कपाट आणि checklist शोधायला नकाशा लागत असे.
Developer portal म्हणजे front desk: प्रत्येक service चे एक पान, catalog, scorecard आणि policy मधून गोळा केलेले.
exam-results चे पान owner science, 92% gold, एक policy warning, pipeline v2 → v2.1.0 आणि 3.0 deploys/week दाखवते.
Desk फक्त वाचते; kits, menu आणि कपाट काम करतात, आणि desk ते सगळे एका जागी सहज सापडतील असे करते.
30 teams च्या शाळेसाठी office आखा: पहिले तीन kits, quotas, पाच guardrails आणि प्रामाणिक मोजमाप.