ailiteracynepal 🇳🇵
पाठ आकार

अध्याय ५ · खण्ड II · 20 मिनेट

सुरक्षित rollouts र rollback

Scale मा प्रयोगकर्ताहरूलाई नबिगारेर परिवर्तनहरू ship गर्ने specific patterns: staging environments, canary deploys, staged rollouts, र instant rollbacks। Prompts, models, र infrastructure मा लागू।

हरेक परिवर्तन एक bet हो कि नयाँ संस्करण पुरानो भन्दा राम्रो छ। अधिकांश bets सही छन्; केही गलत छन्। सुरक्षित rollout त्यो bet 100% होइन 5% प्रयोगकर्ताहरूमा पहिले गर्ने discipline हो — ताकि गलत bet को blast radius सानो छ, service-wide outage होइन। यो खण्ड हरेक AI उत्पादले प्रयोग गर्नुपर्ने specific patterns हो।

Staging environment

कुनै पनि कुरा production हिट गर्नुभन्दा अघि, यो staging मा चल्दछ — production को समान प्रतिकृति जुन कुनै real प्रयोगकर्ताले देख्दैन। Staging अवस्थित छ ताकि तपाईंले real प्रयोगकर्ताहरूले देख्नुभन्दा पहिले “यो मेरो laptop मा काम गर्दछ तर deployed environment मा होइन” bugs catch गर्नुहुन्छ।

Structure:

Environments:
- dev         (your laptop)
- staging     (a full replica, deployed at staging.nepse-mitra.np)
- production  (the real thing, at nepse-mitra.np)

हरेक deploy पहिले staging मा जान्दछ। तपाईं staging मा परिवर्तन end-to-end test गर्नुहुन्छ (Chapter 4 बाट उही eval set प्रयोग गर्दै)। पास भएपछि मात्र यो production मा जान्दछ।

Cost: staging सामान्यतया production को 10-25% scale मा चल्दछ, त्यसैले infrastructure cost साधारण हुन्छ। बचत गरिएका outages ले यसलाई सजिलैसँग न्यायोचित बनाउँछन्।

Canary र staged rollout

Staging tests पछि पनि, एक परिवर्तनले real traffic मा misbehave गर्न सक्दछ। Pattern: gradual rollout।

  1. Canary deploy: नयाँ संस्करण 5% प्रयोगकर्ताहरूको लागि live हुन्छ।
  2. 30-60 मिनेटको लागि हेर्नुहोस्: error rate, latency, thumbs-down, cost जाँच गर्नुहोस्।
  3. यदि metrics स्वस्थ छन् भने, विस्तार गर्नुहोस्: घण्टौं भर 25% → 50% → 100%।
  4. यदि कुनै समयमा metrics degrade हुन्छन् भने, तुरुन्तै roll back गर्नुहोस्।

यो mechanism को मतलब सबैभन्दा नराम्रोमा, 5% प्रयोगकर्ताहरूले एक टुटेको संस्करण देखे — 30 मिनेटको लागि। 12 घण्टाको लागि 100% प्रयोगकर्ताहरू होइन।

Managed platforms (Fly.io, Kubernetes, Vercel) मा, staged rollout built-in feature हो। सरल platforms मा, application-level flag सँग यो आफै गर्नुहोस्:

NEW_PROMPT_ROLLOUT_PCT = 5  # start at 5%, raise as confidence grows

def prompt_for_user(user_id: str) -> str:
    if hash_percent(user_id) < NEW_PROMPT_ROLLOUT_PCT:
        return NEW_PROMPT
    return CURRENT_PROMPT

NEW_PROMPT_ROLLOUT_PCT लाई प्रगतिशील रूपमा समायोजन गर्नुहोस् (5 → 25 → 100)। जब तपाईं 100 पुग्नुहुन्छ र metrics 24 घण्टाको लागि स्थिर छन्, नयाँ prompt लाई CURRENT_PROMPT मा promote गर्नुहोस् र flag हटाउनुहोस्।

Instant rollback

हरेक परिवर्तनलाई 5 मिनेट भित्र यसलाई uskam गर्ने plan चाहिन्छ:

  • Prompt परिवर्तन: constant revert गर्नुहोस्, redeploy गर्नुहोस्। वा (यदि feature flags प्रयोग गर्दै हुनुहुन्छ भने) rollout प्रतिशत 0 मा drop गर्नुहोस्।
  • Model version परिवर्तन: pinned संस्करण फिर्ता परिवर्तन गर्नुहोस्, redeploy गर्नुहोस्।
  • Data / index परिवर्तन: retrieval code लाई पहिलेको index मा point गर्नुहोस् (पछिल्ला केही indexes राख्नुहोस्)।
  • Infrastructure परिवर्तन: platform-level rollback (Fly.io: flyctl deploys rollback; Kubernetes: kubectl rollout undo)।

तपाईंले यसलाई आवश्यक पर्नु अघि rollback अभ्यास गर्नुहोस्। नयाँ deployment को दिन एक मा, deliberately एकपटक roll back गर्नुहोस् — केवल mechanism काम गर्दछ verify गर्न। सिद्धान्तमा मात्र अवस्थित rollback rollback होइन।

Blue/green deploys

Infrastructure परिवर्तनहरूको लागि advanced pattern: एकैचोटि production को दुई पूर्ण प्रतिलिपिहरू चलाउनुहोस्। “Blue” मा सबै traffic route गर्नुहोस् जब तपाईं नयाँ संस्करण “green” मा deploy गर्नुहुन्छ। जब green स्वस्थ हुन्छ, traffic switch गर्नुहोस्। यदि green असफल हुन्छ भने, blue मा फिर्ता switch गर्नुहोस्।

एक सानो Nepal-scale उत्पादको लागि, blue/green overkill हो। हजारौं प्रयोगकर्ताहरू सर्भ गर्ने कुनै पनि कुराको लागि, वा जहाँ downtime dollars मा मापन गरिन्छ, यो worthwhile बन्दछ। Managed platforms ले यसलाई checkbox रूपमा प्रदान गर्दछन्।

Rollout checklist

हरेक गैर-तुच्छ deploy भन्दा पहिले:

  • Automated tests (unit + integration) पास हुन्छन्।
  • Staging मा eval set पास हुन्छ।
  • Change log entry लिखित।
  • Rollback plan documented (यो परिवर्तनको लागि specifically)।
  • Metrics dashboards खुला, हेर्न तयार।
  • Reasonable घण्टामा deploy गर्नुहोस् (late night होइन; बिदा भन्दा ठीक पहिले होइन)।
  • Team सदस्य ब्युँझिएको र पहिलो 30-60 मिनेट post-deploy को लागि उपलब्ध।

कुनै पनि step आफ्नो जोखिममा skip गर्नुहोस्। हरेक step सानो छ; कुनै एउटा skip गर्नु सबै combined गर्ने भन्दा बढी खर्च हुन्छ।

Change fatigue

Frequent, सुरक्षित deploys लक्ष्य हो। Trap हो कि जब साना deploys routine बन्दछन्, discipline erode हुन्छ। कसैले check बिना deploy गर्दछन्, कसैले change log skip गर्दछन्, कसैले staged rollouts लाई “बस 100% मा push गर्नुहोस्” मा घटाउँछन्।

Deploys लाई friction-कम तर ceremony-explicit राखेर discipline संरक्षण गर्नुहोस्। Slack मा हरेक deploy घोषणा:

Deploying prompt v1.5 to production.
Change: added Nepali script normalisation instruction.
Rollout: 5% canary for 30 min, then 100% if healthy.
Rollback: revert commit abc123, redeploy.
Deployer: @nishan
Metrics: dashboard.example.com/nepse-mitra

पाँच लाइनहरू। लेख्न दुई मिनेट। Team लाई signals गर्दछ कि परिवर्तन भइरहेको छ, bounded छ, र plan छ।

Rolling back असफलता होइन

सांस्कृतिक रूपमा, टिमहरूले internalise गर्न आवश्यक छ: rolling back सफलता हो, failure होइन। विकल्प — pride संरक्षण गर्न टुटेको परिवर्तन live छोड्नु — जहाँ trust नष्ट हुन्छ।

हरेक टिमले norm हुनुपर्दछ: जसले regression नोटिस गर्दछ त्यसले roll back गर्दछ, कुनै अनुमति आवश्यक छैन। Post-mortems प्रयोगकर्ताहरूलाई सुरक्षित गरेपछि हुन्छन्, अघि होइन।

Rollout maturity ladder

तपाईंको टिम आज कहाँ छ?

Level 1 — Cowboy। Production मा सिधै deploys। कुनै staging होइन। कुनै rollback plan होइन। Breakages frequent र fix गर्न गाह्रो छन्। (धेरैजसो day-1 projects।)

Level 2 — Staged। Staging environment छ। Deploys पहिले staging मा जान्दछन्, manually test हुन्छन्, त्यसपछि production मा। कम regressions। Rollback सम्भव छ तर तेज होइन।

Level 3 — Canary। हरेक real परिवर्तनको लागि Staged rollout। Fast rollback (<5 मिनेट)। हरेक deploy tracked। Rollout को समयमा metrics सक्रिय रूपमा हेरिएको।

Level 4 — Automated। Rollouts स्वचालित छन्। Metrics ले misbehave गर्ने canary लाई स्वचालित रूपमा abort गर्दछ। हरेक deploy nerve-wracking होइन, routine घटना हो।

अधिकांश Nepal-scale AI उत्पादहरूले Level 3 लक्ष्य राख्नुपर्दछ। Level 4 4+ को team र regressions real पैसा खर्च गर्ने पर्याप्त ठूलो traffic भएपछि worthwhile हुन्छ।

अब के आउँछ

तपाईंलाई थाहा छ परिवर्तनहरू सुरक्षित रूपमा कसरी roll out गर्ने। तर केही परिवर्तनहरू बाहिर तपाईंको नियन्त्रण बाट आउँछन् — Anthropic ले मोडेल update गर्दछ, OpenAI ले API deprecate गर्दछ, Nepal-specific data source ले format परिवर्तन गर्दछ। Chapter 5 को अन्तिम खण्ड त्यो specific class को परिवर्तन सम्हाल्ने बारे हो: model provider drift, र यसले आवश्यक पर्ने operational discipline।