آپریشنل ہینڈ آف وہ لمحہ ہے جب سائٹ پر موجود سسٹم (build) محض ‘فارورڈ ڈیپلائڈ انجینئر’ (FDE) کی فطری سمجھ بوجھ یا مہارت پر چلنے والی چیز نہیں رہتا، بلکہ ایک ایسا نظام بن جاتا ہے جسے کسٹمر کی ٹیم باقاعدہ اور شعوری طور پر چلا سکتی ہے۔ آپریشنل ہینڈ آف کا مطلب ہے کہ کسٹمر روزمرہ کی بنیاد پر سسٹم کو چلا سکے، خرابی کی صورت میں اسے ٹھیک (debug) کر سکے، اور آپ کی موجودگی کے بغیر اس میں محفوظ تبدیلیاں لا سکے۔
اس صورتحال پر غور کریں۔ آپ نے ‘HarborView Insurance’ کے لیے AI کی مدد سے چلنے والی کلیمز ٹریاج (claims triage) سروس تیار کی ہے، جو Kubernetes پر چل رہی ہے اور اس میں PostgreSQL ڈیٹا بیس، Redis کیشے، اور انٹرنل گیٹ وے کے پیچھے ماڈل کالز شامل ہیں۔ پائلٹ پروجیکٹ کامیاب رہا، انتظامیہ چاہتی ہے کہ آپ اسے پروڈکشن (اصل استعمال) میں لائیں، اور پھر تین ہفتوں میں آپ کا سائٹ سے واپس جانا طے ہے۔
اس آخری مرحلے میں، اصل سوال یہ نہیں ہے کہ آیا سسٹم آج کام کر رہا ہے۔ اصل سوال یہ ہے کہ کیا ‘HarborView’ منگل کی رات پیش آنے والے کسی واقعے (incident) کے دوران اسے رواں رکھ سکے گی، اور کیا وہ اگلی سہ ماہی میں اس میں کوئی تبدیلی کر سکیں گے بغیر اس کے کہ نادانستہ طور پر سیکیورٹی میں کوئی کمزوری یا قابلِ اعتماد ہونے (reliability) کا مسئلہ پیدا ہو جائے۔
ہینڈ آف اکثر اس لیے ناکام ہو جاتا ہے کیونکہ ہر کوئی “مکمل” (done) کے لفظ سے مختلف مراد لیتا ہے۔ آپ کی مراد یہ ہو سکتی ہے کہ بیک لاگ (بقیہ کام) ختم ہو چکا ہے اور ڈیش بورڈز ‘سبز’ (درست حالت) دکھا رہے ہیں۔ کسٹمر کی مراد یہ ہو سکتی ہے کہ وہ آپ کو بلائے بغیر (بغیر paging کے) سسٹم کو ڈیپلائے کر سکتے ہیں، اور ان کی سیکیورٹی ٹیم نے رسائی اور لاگنگ (logging) کی منظوری دے دی ہے۔
“مکمل” ہونے کی تعریف کامیابی کے ان معیارات کے مجموعے کے طور پر کریں جن کا تعلق قابلِ اعتماد ہونے (reliability)، سیکیورٹی اور ڈیلیوری کی ملکیت سے ہو۔ آپ کا مقصد یہ ضمانت دینا نہیں ہے کہ کوئی واقعہ (incident) پیش ہی نہیں آئے گا۔ آپ کا مقصد یہ یقینی بنانا ہے کہ جب کوئی واقعہ پیش آئے، تو کسٹمر اسے پہچان سکے، اس کی تشخیص کر سکے، اور آپ کی نجی معلومات یا پس منظر کی سمجھ بوجھ (private context) کی مدد لیے بغیر اسے بحال کر سکے۔
آئیے ایک سادہ طریقہ دیکھتے ہیں جس سے یہ جانچا جا سکے کہ آیا ہینڈ آف واقعی مکمل ہو چکا ہے۔
آگے بڑھنے کے لیے بنیادی اصول یہ ہے کہ کامیابی کے ہر معیار (success criterion) کے لیے ایک ذمہ دار فرد اور ثبوت (proof point) کا ہونا ضروری ہے۔ ثبوت سے مراد کوئی ایسی ٹھوس چیز ہے جس کی طرف اشارہ کیا جا سکے، مثلاً رن بک (runbook) کا لنک، رسائی کی مکمل شدہ درخواست، آن کال روٹیشن میں اندراج، یا کسٹمر ٹیم کی جانب سے آپ کی موجودگی میں کیا گیا کامیاب ‘ڈیپلائے’ (deploy)۔
وعدوں سے ثبوت بہتر ہے اگر ہینڈ آف (handoff) کی کسی ضرورت کی تصدیق مختصر جائزے میں نہیں کی جا سکتی، تو وہ ابھی تک کوئی ‘ضرورت’ نہیں ہے۔
جب ہینڈ آف کا عمل کمزور ہو، تو سروس کی پہلی بندش (outage) ایک اور مسئلہ پیدا کر دیتی ہے۔ پہلی خرابی تکنیکی نوعیت کی ہوتی ہے، جبکہ دوسرا مسئلہ ذمہ داری کے تعین میں ابہام کا ہوتا ہے؛ یہ ابہام بندش کے دورانیے کو طول دیتا ہے اور ایک دوسرے پر الزام تراشی کا سلسلہ شروع کر دیتا ہے۔
فرض کریں HarborView کو ایک الرٹ موصول ہوتا ہے کہ p95 لیٹنسی (latency) دوگنی ہو گئی ہے اور درخواستیں ٹائم آؤٹ (time out) ہو رہی ہیں۔ آن کال انجینئر ڈیش بورڈ کھولتا ہے اور دیکھتا ہے کہ ایک ساتھ دس الرٹس آ رہے ہیں۔ اسے یہ معلوم نہیں ہوتا کہ کون سا الرٹ اہم ہے، اسے پروڈکشن میں Kubernetes ڈیپلائمنٹ کو دوبارہ شروع کرنے کی اجازت نہیں ہوتی، اور اسے ایسی کوئی رن بک نہیں ملتی جو یہ بتائے کہ ماڈل گیٹ وے کے لیے “نارمل” (معمول کی) صورتحال کیا ہے۔
وہ آپ سے رابطہ کرتے ہیں، آپ ‘بلڈ’ (build) کے دوران سیکھی گئی تین اہم باتیں بتاتے ہیں، اور سسٹم بحال ہو جاتا ہے۔ دو ہفتے بعد یہی واقعہ دوبارہ پیش آتا ہے، لیکن اس بار آپ پرواز (flight) پر ہوتے ہیں، اور سروس کی بندش کا دورانیہ تین گھنٹے مزید طویل ہو جاتا ہے۔ اس کی بنیادی وجہ ‘کیش سٹیمپِیڈ’ (cache stampede) یا ڈیٹا بیس کنکشن پول کا غلط سائز ہو سکتا ہے، لیکن بندش کا طویل دورانیہ آپریشنل بنیادی تقاضوں کی عدم موجودگی کی وجہ سے ہوا، نہ کہ خود اس بگ (bug) کی وجہ سے۔
دیکھیں کہ کس طرح ہینڈ آف کے عمل میں معمولی کمی یا کوتاہی طویل دورانیے کے مسائل اور ذمہ داری کے تعین میں الجھن کا باعث بنتی ہے۔