भाग 1: का आणि काय (cyan, 1–4) · भाग 2: self-service (brown, 5–8) · भाग 3: guardrails आणि मोजमाप (violet, 9–12). प्रत्येक आकृती खऱ्या, deterministic lab मधून काढली आहे — idp/demo.py जे आकडे छापते तेच — आणि प्रत्येक आकृतीखाली एक lab आहे जिथे तुम्ही स्वतः कार्यालयाचे नियम बदलता. वर्तुळातील आकडे क्रमाने पाहा 1 → 2 → 3.
1 🧭 platforms का हवेत
प्रत्येक शिक्षिका स्वतःचा वर्ग-संच बनवते — cognitive load, तिकिटांची रांग आणि 'you build it, you run it' चा थकवा.
🧒 सोप्या शब्दांत
कतरिना नवी science शिक्षिका आहे, आणि तिला एक वर्ग हवा आहे. बाकडी, कुलूप, socket आणि first-aid box तिला स्वतः शोधावे लागतात. इतर शिक्षिका दीपिकाच्या office ला अर्ज लिहितात. रोज 5 अर्ज येतात, आणि दीपिका फक्त 4 पूर्ण करू शकते. म्हणून ढीग रोज 1 ने वाढतो. मग office एका कपाटावर तयार kits ठेवते, आणि कतरिना एक kit घेते.
📖 नवे शब्दplatform team — इतर teams ना शून्यापासून सुरुवात करावी लागू नये म्हणून तयार kits बनवणारे मदतनीसcognitive load — एका व्यक्तीला एकाच वेळी डोक्यात ठेवाव्या लागणाऱ्या गोष्टी, जसे 14 कामेticket queue — कोणीतरी हाताने करायची वाट पाहणारी लेखी विनंत्यांची रांग
⏪ आधी
प्रत्येक शिक्षिका आपला classroom kit स्वतः बनवत असे, किंवा facilities office च्या ढिगात विनंती लिहून वाट पाहत असे.
💡 काय
एक service चालू करायला team ला 14 कामे एकटीने करावी लागत; office मुळे ती 4 ठेवते आणि 10 तयार kits म्हणून घेते.
⚙️ कसे
रोज 5 विनंत्या येतात आणि दीपिका 4 पूर्ण करते: 20 दिवसांनी 80 पूर्ण, 20 अजून रांगेत, सरासरी वाट 2.0 दिवस.
🎯 का
ढीग रोज 1 ने वाढतो: पहिल्या दिवशी 0 दिवस वाट, 20 व्या दिवशी 4 दिवस. नुसत्या जास्त मेहनतीने रांग कधीच संपत नाही.
🚀 पुढे
पुढच्या धड्यात शिक्षिका ग्राहक बनतात: त्यांना विचारा, त्रास क्रमाने लावा, आणि सर्वात मोठा त्रास आधी सोडवा.
🧪 इथे करून पाहा — दीपिकाचा tickets चा ढीग — किती येतात, ती किती पूर्ण करते आणि कार्यालय किती kits देते ते बदला
शिक्षिका या कार्यालयाच्या ग्राहक आहेत — मुलाखती, त्रासानुसार क्रम लावलेला roadmap, सक्तीऐवजी स्वेच्छेने स्वीकार.
🧒 सोप्या शब्दांत
दीपिका या महिन्यात एक नवा kit बनवू शकते. ती चमकदार smart board बनवू शकली असती, कारण ते मजेदार आहे. त्याऐवजी ती प्रत्येक विभागाला विचारते की त्यांचा वेळ कशात वाया जातो. Database ची वाट पाहण्यात आठवड्याला 15 तास जातात. म्हणून तो kit आधी. ती कोणालाही तो वापरायची सक्ती करत नाही. Arts विभाग नको म्हणतो, तेव्हा ती का ते विचारते.
📖 नवे शब्दplatform as a product — platform वापरणाऱ्या teams ना जिंकायचे ग्राहक मानणेroadmap — पुढे काय बनवायचे त्याची यादी, सर्वात मोठा त्रास आधीadoption — किती teams नी ते वापरायचे ठरवले, जसे सहाव्या महिन्यापर्यंत 80%
⏪ आधी
मध्यवर्ती 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 हा सोपा मार्ग आहे, एकमेव नाही.
📖 नवे शब्दgolden path — एखादी गोष्ट बनवण्याचा सोपा, आधार असलेला मार्ग, ज्यात चांगले निर्णय आधीच घेतलेले असतातtemplate — दरवेळी तशाच सुरुवातीच्या files बनवणारा तयार नमुनाscaffolder — template मध्ये तुमचे नाव आणि owner भरणारे, किंवा काय दुरुस्त करायचे ते सांगणारे tool
⏪ आधी
प्रत्येक नवी 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 ची नोंदवही बनवतो.
🧪 इथे करून पाहा — कार्यालयाकडे नवीन service मागा — चुकीची नावे, अनोळखी मालक आणि नसलेले templates वापरून पाहा
प्रत्येक वर्गखोलीची नोंदवही — मालक, dependencies, अनाथ services आणि blast radius.
🧒 सोप्या शब्दांत
Office प्रत्येक खोलीची नोंदवही ठेवते: ती कोणाची आहे आणि तिला काय लागते. एका सकाळी sign-in system, auth, बंद पडते. दीपिका बाण उलटे फिरून पाहते आणि तिला 5 खोल्या अडचणीत दिसतात. तिला कोणाच्याच मालकीच्या नसलेल्या खोल्याही सापडतात: canteen-orders आणि fees. त्या बंद पडल्या तर कोणालाच फोन जात नाही. म्हणून प्रत्येक खोलीला नाव असलेला owner हवा.
📖 नवे शब्दservice catalog — प्रत्येक service, तिचा owner आणि तिला काय लागते याची नोंदवहीorphan — अजून वापरात असलेली पण कोणतीच team न सांभाळणारी serviceblast radius — एक गोष्ट बंद पडली की बंद पडणारे सगळे, जसे auth बंद पडल्यावर 5 services
⏪ आधी
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 च्या आत.
🧪 इथे करून पाहा — नोंदवही — service बिघडवून तिचा blast radius पाहा, team विसर्जित करून अनाथ services तयार करा
कार्यालयाकडे मागा, लगेच मिळवा — प्रत्येक team च्या quota मध्ये resources चा ठरलेला मेनू.
🧒 सोप्या शब्दांत
आता office च्या भिंतीवर एक menu आहे: लहान कपाट, मोठे कपाट, एक box आणि कप्प्यांचा rack. Science ला ठरावीक मर्यादा आहे: 2 कपाटे आणि 6 फरश्या. कतरिना एक मोठे आणि एक लहान कपाट मागवते, आणि ती लगेच मिळतात. तिसऱ्या कपाटाला नकार मिळतो, आणि काय करायचे याची चिठ्ठीही. आता कोणीच ढिगात वाट पाहत नाही.
📖 नवे शब्दself-service — एखाद्या व्यक्तीची वाट न पाहता menu मधून स्वतः हवे ते घेणेquota — एका team ला जास्तीत जास्त किती मिळू शकते ती मर्यादा, जसे 2 databases आणि 6 CPUtag — resource वरचे लेबल, ते कोणाचे आहे आणि कोण सांभाळते ते सांगणारे
⏪ आधी
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 ने साफ होणारा.
🧪 इथे करून पाहा — विज्ञानाचा वाटा — quota बदला, मग मेनूमधून मागवा
प्रत्येक बदलासाठी एक चाचणी वर्गखोली — प्रत्येक pull request साठी preview environments, time-to-live नंतर साफ केली जातात.
🧒 सोप्या शब्दांत
कतरिना खरी lab बदलण्याआधी नवी मांडणी करून पाहू इच्छिते. Office तिला pr-101 नावाची trial खोली देते. तिने 'झाले' म्हटले की खोली रिकामी केली जाते. 48 तास कोणीच हात लावला नाही तरीही ती रिकामी केली जाते. फक्त 3 trial खोल्या आहेत. एका आठवड्यात 674 ऐवजी फक्त 223 तास दिवे लागले.
📖 नवे शब्दpreview environment — एका pull request साठी बनवलेली app ची थोड्या काळाची copyTTL — time to live: न वापरता किती वेळ राहू शकते ते, नंतर साफ केले जाते, जसे 48 hpull request — merge होण्याआधी इतर जण पाहतात असा सुचवलेला बदल
⏪ आधी
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.
🧪 इथे करून पाहा — प्रत्येक pull request साठी एक प्रयोग-वर्ग — time-to-live आणि मर्यादा बदला
production कडे जाणारा एकच सामायिक रस्ता — पुन्हा वापरता येणारे, versioned pipeline templates आणि pinning म्हणजे काय.
🧒 सोप्या शब्दांत
प्रत्येक वर्गाला सकाळी तेच काम करावे लागते: कुलूप उघडणे, fire exit तपासणे, दिवे लावणे. Office एक routine card लिहिते आणि त्याला version 2 म्हणते. त्यात smoke-alarm ची पायरी जोडली की कतरिनाला ती दुसऱ्या सकाळी मिळते, कारण तिने 'नवीनतम version 2' म्हटले होते. ऐश्वर्याने 'नेमके 2.0' म्हटले, म्हणून ती वाट पाहते. Fees office ने वर्षांपूर्वी card 1 ची photocopy केली, आणि तिच्यापर्यंत काहीच पोहोचत नाही.
📖 नवे शब्दpipeline template — अनेक services follow करतात अशी build आणि deploy पायऱ्यांची एक सामायिक यादीmoving tag — @v2 सारखे नाव जे नेहमी नवीनतम v2.x कडे निर्देश करतेpin — एक नेमके version निवडणे, जसे @v2.0.0, म्हणजे तुम्ही ठरवेपर्यंत काहीच बदलत नाही
⏪ आधी
प्रत्येक 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.
🧪 इथे करून पाहा — प्रत्येक service खरंच काय चालवते — तिचा reference बदला, किंवा नवीन template release करा
किल्ल्यांचे कपाट — प्रत्येक team ची secrets, versions आणि rotation सह; config स्पष्ट केलेल्या थरांमध्ये.
🧒 सोप्या शब्दांत
Office कडे प्रत्येक विभागासाठी एक खुंटी असलेले किल्ल्यांचे कपाट आहे. कतरिना science ची किल्ली घेते, पण maths ची किल्ली तिची नाही. मग दीपिका कुलूप बदलते आणि किल्ली version 2 टांगते. exam-results ची लिपिक आपली किल्ली बदलते, पण lab worker अजून परत आलेली नाही. म्हणून सगळ्यांकडे नवी किल्ली येईपर्यंत दीपिका जुने कुलूप चालू ठेवते.
📖 नवे शब्दsecret — program ला लागणारा password किंवा key, नजरेआड ठेवलेलाrotation — secret च्या जागी नवे version आणणे, जसे v1 वरून v2config layers — क्रमाने रचलेल्या settings, ज्यात नंतरचा layer जिंकतो, जसे production मधून replicas 3
⏪ आधी
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.
🧪 इथे करून पहा — किल्ल्यांचे कपाट — team म्हणून paths वाचा, password बदला (rotate), consumers reload करा, v1 रद्द करून पहा
फक्त 'नाही' न म्हणता दुरुस्ती कशी करायची ते सांगणारे सुरक्षा नियम — audit आणि enforce modes मधले policy as code.
🧒 सोप्या शब्दांत
शाळेचे खोल्यांसाठी सुरक्षेचे नियम आहेत: नाव असलेला owner, पुरेसे दरवाजे, कुलूपबंद कपाटे. आधीचा तपासणीस फक्त FAILED म्हणून निघून जात असे. आता checklist लिहिलेली आहे आणि प्रत्येक बदलावर चालते. प्रत्येक अडचणीसाठी ती काय चुकले आणि कसे दुरुस्त करायचे ते सांगते. सुरुवातीला ती फक्त इशारा देते. कतरिनाच्या खोलीत 4 अडचणी होत्या, तिने चारही दुरुस्त केल्या, आणि खोली उघडली.
📖 नवे शब्दpolicy as code — प्रत्येक बदल आपोआप तपासणारे program म्हणून लिहिलेले नियमguardrail — तुम्हाला सुरक्षित ठेवणारा आणि अडचण कशी सोडवायची ते सांगणारा नियमaudit mode — नियम फक्त इशारा देतात, अजून काहीच अडवले जात नाहीenforce mode — दुरुस्त होईपर्यंत नियम बदल अडवतात
⏪ आधी
एक व्यक्ती लिहिलेल्या यादीशी बदल तपासत असे आणि कारण न सांगता 'failed' म्हणत असे, किंवा कोणी तपासतच नसे.
💡 काय
Policy as code: प्रत्येक बदलावर 5 नियम चालतात, प्रत्येकात message आणि दुरुस्ती, audit किंवा enforce mode मध्ये.
⚙️ कसे
exam-results 4 नियमांत नापास: audit warnings सह परवानगी देतो, enforce नकार देतो; चार दुरुस्त्यांनंतर परवानगी मिळते.
🎯 का
'नाही' आणि 'असे करा' सांगणारा guardrail शिकवतो; फक्त 'नाही' म्हणणारा लोकांना त्याला वळसा घालायला लावतो.
🚀 पुढे
पुढचा धडा 'करायला हवे' ची यादी जोडतो: प्रत्येक service चे weighted checks आणि एक पुढची पायरी असलेले readiness scorecard.
🧪 इथे करून पहा — exam-results चे manifest checklist विरुद्ध — गोष्टी दुरुस्त करा, audit ↔ enforce बदला
प्रत्येक वर्गखोलीसाठी तयारीची तपासणी-यादी — वजन असलेल्या तपासण्या, स्तर, आणि पुढे काय दुरुस्त करायचे.
🧒 सोप्या शब्दांत
Office प्रत्येक वर्गासाठी 8 तपासण्या असलेले readiness card ठेवते. महत्त्वाच्या तपासण्या दुप्पट मोजल्या जातात, जसे owner असणे. Exam खोलीला 92% मिळतात आणि gold मिळते. Canteen खोलीला 33% मिळतात आणि ती अजून तयार नाही. कोणालाही लाजवण्यासाठी गुण भिंतीवर लावले जात नाहीत. प्रत्येक शिक्षिका फक्त आपले card आणि पुढची एक पायरी पाहते.
📖 नवे शब्दscorecard — एका service साठी तपासण्यांचे card, गुण आणि level सहweighted check — जास्त महत्त्वाची म्हणून जास्त मोजली जाणारी तपासणी, जसे owner ×2maturity level — गुणांसाठी बिल्ला: gold 90, silver 70, bronze 50
⏪ आधी
Production readiness कोणाच्या तरी डोक्यात किंवा लांबलचक wiki checklist मध्ये असे, जी कोणी पूर्ण किंवा अद्ययावत करत नसे.
💡 काय
Scorecard: 8 weighted checks, एकूण weight 12, आणि levels gold 90, silver 70, bronze 50.
कार्यालयाचा उपयोग होतोय का? DORA च्या चार keys, पहिल्या deploy पर्यंतचा वेळ, SPACE, आणि आकड्यांचा शस्त्र म्हणून वापर न करणे.
🧒 सोप्या शब्दांत
मुख्याध्यापिका दीपिकाला विचारतात: office ची मदत झाली का? दीपिका science चे बदल तपासते. Kits आधी: आठवड्याला 1 बदल, कल्पनेपासून चालू होईपर्यंत 150 तास. नंतर: आठवड्याला 3, फक्त 5 तास. मग कोणीतरी आठवड्याला 9 बदलांचा आदेश देते, आणि एक विभाग तोच बदल तीनदा मोजतो. आकडा वाढला, पण काहीच सुधारले नाही. म्हणून दीपिका शिक्षिकांनाही विचारते.
📖 नवे शब्दDORA metrics — चार आकडे: किती वेळा, किती लवकर, किती वेळा बिघडते, किती लवकर दुरुस्त होतेlead time — बदल लिहिल्यापासून तो चालू होईपर्यंतचे तास, जसे 5 hGoodhart's law — आकडा ध्येय बनला की लोक काम सुधारण्याऐवजी आकडा वाकवतातSPACE — productivity पाहण्याचे पाच मार्ग, आकडे आणि लोकांना विचारणे एकत्र
⏪ आधी
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.
🧪 इथे करून पाहा — खऱ्या deployments मधून चार keys — आणि एखादा आकडा लक्ष्य बनला की काय होते
स्वागत कक्ष — प्रत्येक service साठी Backstage-पद्धतीचे portal पान, आणि कार्यालयाचा संपूर्ण नकाशा.
🧒 सोप्या शब्दांत
Office मोठे झाले आहे: kits, नोंदवही, menu, trial खोल्या, किल्ल्यांचे कपाट आणि checklist. नव्या शिक्षिकेला नकाशा लागेल. म्हणून दीपिका एक front desk उघडते. कतरिना exam-results म्हणते, आणि तिला एक पान मिळते: owner, gold गुण, एक इशारा आणि आठवड्याला 3 बदल. Desk स्वतः काम करत नाही. ते सगळे सहज सापडेल असे करते.
📖 नवे शब्दdeveloper portal — एक website जिथे team ला आपल्या services बद्दल सगळे सापडतेBackstage — developer portal आणि catalog बनवण्यासाठी लोकप्रिय open-source toolinternal developer platform — platform team देत असलेले kits, menus आणि नियमांचा संपूर्ण संच
⏪ आधी
नव्या शिक्षिकेला 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 आणि प्रामाणिक मोजमाप.
🧪 इथे करून पाहा — exam-results चे स्वागत कक्ष page — भाग बदला, आणि page ते कसे एकत्र करते ते पाहा