पथ 06पाठ 4 / 6

Service पर निर्भर होने से पहले उससे बाहर निकलने का तरीका जाँचें

Source-code ownership और संचालन की portability अलग समझें। Exports, स्वतंत्र builds, infrastructure access और transition के लिए जरूरी प्रमाण जाँचें।

व्यावहारिक10 minसमीक्षा की गई 5 अक्टू॰ 2026

प्रकाशक Taigaहम कैसे लिखते हैं

अपनी समझ जाँचेंआपका संगठन source code का मालिक है। संचालन की portability के लिए कौन-सा अतिरिक्त प्रमाण उपयोगी है?अभ्यास करें

उत्तर दिखाएँ

अभ्यास missing packages, configuration, credentials, infrastructure या संचालन ज्ञान सामने ला सकता है।

आप क्या सीखेंगे

Supplier के बिना संचालन के लिए जरूरी assets और अधिकार पहचानें।
महत्वपूर्ण dependency बनने से पहले छोटा exit अभ्यास design करें।
Export, transition और deletion के निर्णय अलग रखें।

तय करें कि क्या उपयोग योग्य रहना चाहिए

Source code का मालिक होना उपयोगी है। यह exit plan का केवल एक हिस्सा है।

काल्पनिक application लें जिसका source कंपनी की repository में है। Build supplier से private package download करता है। Production supplier के cloud account में है। Database restore की प्रक्रिया किसी ने दर्ज नहीं की।

कंपनी के पास code है, लेकिन वह service स्वतंत्र रूप से नहीं चला सकती। Exit plan में अधिकार, assets, access और ज्ञान साथ cover होने चाहिए।

Dependencies की inventory बनाएँ

Asset या जिम्मेदारी	Exit का प्रश्न
Code और history	क्या अगली team पूरी repository access कर सकती है?
Packages और licenses	क्या हर जरूरी dependency प्राप्त और इस्तेमाल कर सकती है?
Data और schemas	क्या संबंध सुरक्षित रखते हुए उपयोग योग्य records restore कर सकती है?
Infrastructure और configuration	क्या environment और जरूरी settings दोबारा बना सकती है?
Identities और secrets	Replacement credentials कौन बनाता है और access कौन नियंत्रित करता है?
DNS और certificates	Public endpoint कौन स्थानांतरित कर सकता है?
प्रमाण और संचालन	कौन-से decisions, runbooks, tests और incident records उपलब्ध रहते हैं?

Export formats और दायरा जाँचें। पढ़ने योग्य document export हर relationship, attachment या execution record जरूरी नहीं बचाए। Sample माँगें और इस्तेमाल करने वाले लोगों के साथ उसका निरीक्षण करें।

स्वतंत्र rebuild करें

सुरक्षित test environment और स्वीकृत example data इस्तेमाल करें। अधिकृत engineer को proposed handover package दें। Application build करने, configuration लागू करने, डेटा restore करने और पूरा business operation जाँचने को कहें।

हर missing item और उसे पाने का समय दर्ज करें। अभ्यास के दौरान चुपचाप undocumented ज्ञान न दें। उद्देश्य यह ढूँढ़ना है कि अगली team के पास क्या नहीं होगा।

फिर transition की सीमाएँ देखें: overlapping subscriptions, data transfer का समय, package access, identity changes और support की उपलब्धता। ये लागतें build-versus-buy तुलना में शामिल करें।

Export और deletion अलग रखें

Export copy बनाता है। Transition बदलता है कि service कौन चलाता है। Deletion सहमत प्रक्रिया से तय records हटाता है। ये अलग निर्णय हैं जिनके प्रमाण भी अलग हैं।

संबंधित जिम्मेदार लोगों के साथ जरूरी retention और deletion का दायरा तय करें। Supplier की वर्तमान terms और procedures की पुष्टि करें। Receiving system जाँचने से पहले एकमात्र उपयोग योग्य recovery copy न हटाएँ।

Taiga administrative export और अलग erasure प्रक्रिया का documentation देता है। Export में secret values शामिल नहीं होतीं। इसलिए handover में जरूरी secrets दोबारा बनाने का अधिकृत तरीका चाहिए। वर्तमान export की सामग्री को transition की जरूरतों से मिलाएँ; इसे पूरी application का backup न मानें।

तय करें कि कौन-सी dependencies स्वीकार्य हैं

Portability के लिए हर managed service हटाना जरूरी नहीं। Dependency उचित विकल्प हो सकती है जब उसका मूल्य, सीमाएँ और transition path समझे गए हों।

स्वीकार की dependencies, जिम्मेदार व्यक्ति और review की शर्त दर्ज करें। महत्वपूर्ण architecture या contract change के बाद exit अभ्यास दोहराएँ। आगे अपनाने की योजना पढ़ें, जिसमें शुरुआत से ये जिम्मेदारियाँ हों।

अभ्यास करें

काल्पनिक supplier Git repository और database export देता है। Application स्वतंत्र रूप से चलाने के लिए जरूरी पाँच दूसरी चीजें लिखें। एक चुनें और missing dependency दिखाने वाला test बताएँ।

Worksheet डाउनलोड करें (Markdown)

अपनी समझ जाँचें ↑