2.20 خرابی سے نمٹنا اور لچک کے نمونے

جائزہ اور محرکات

آپ کا لکھا ہر پروگرام ناکام ہوگا۔ ڈسک بھر جاتی ہے، نیٹ ورک گر جاتا ہے، سروس ٹائم آؤٹ ہوتی ہے، کال کرنے والا کچرا بھیجتا ہے، انحصار ایسی چیز لوٹاتا ہے جس کا دستاویزات میں ذکر نہ تھا۔ سوال کبھی یہ نہیں کہ ناکامی ہوتی ہے یا نہیں؛ سوال یہ ہے کہ آپ کا کوڈ اس ناکامی کا سامنا منصوبے سے کرتا ہے یا حیرت سے۔ خرابی سے نمٹنا اس کا فن ہے کہ آپ لائن بہ لائن اور فنکشن بہ فنکشن طے کریں کہ جب دنیا تعاون نہ کرے تو آپ کا کوڈ کیا کرتا ہے۔ یہ تعمیر کا سب سے کم چمکدار حصہ ہے اور وہی حصہ جو، کسی بھی فیچر سے زیادہ، طے کرتا ہے کہ لوگ آپ کے نظام پر بھروسہ کرتے ہیں یا نہیں۔

یہ باب کوڈ اور جزو کی سطح پر لچک کے بارے میں ہے: فنکشن، ماڈیول، یا API کے اندر کے انتخاب۔ یہ باب 3.5 کی تکمیل کرتا ہے، جو نظام کی سطح پر لچک (لوڈ بیلنسنگ، نقل، سروسز کے پار فیل اوور) کا احاطہ کرتا ہے۔ باب 3.5 پورے پلیٹ فارم کو کھڑا رکھتا ہے جب پورا خطہ اندھیرے میں چلا جائے؛ یہ باب ایک درخواست کو آپ کے ڈیٹا بگاڑنے یا بغیر نشان کے غائب ہونے سے روکتا ہے۔ دونوں ایک دوسرے کو مضبوط کرتے ہیں۔ آپ کے فن تعمیر میں سرکٹ بریکر کا کوئی مطلب نہیں اگر اس کے پیچھے کا کوڈ استثنا نگل لے، اور اگر گرد کا نظام فالتو پن سے خالی ہو تو دفاعی فنکشن آپ کو نہیں بچا سکتا۔ یہ باب باب 2.9 (سافٹ ویئر تعمیر) پر بھی بنتا ہے، جہاں خرابیاں سنبھالنا بہت سے نظم و ضبط میں سے ایک تھا؛ یہاں یہ پورا موضوع بن جاتا ہے۔

بڑی ٹیموں کے لیے انعام یکسانیت ہے۔ جب سینکڑوں انجینئر سینکڑوں طریقوں سے خرابیاں سنبھالیں تو ہر سروس پہیلی بن جاتی ہے اور ہر واقعہ کھدائی۔ انٹرپرائز ترتیبوں میں یہ بے ترتیبی ہر آڈٹ اور ہر انضمام کی لاگت بڑھاتی ہے۔ حکومت اور دیگر اعلیٰ داؤ کے نظاموں میں داؤ تیز تر ہیں: درستگی، محفوظ ناکامی، اور واضح آڈٹ کا نشان ایسے فیچرز نہیں جو آپ بعد میں جوڑیں بلکہ ایسی خصوصیات ہیں جو نظام میں پہلے کمٹ سے ہونی چاہییں۔ فوائد کا نظام جو خاموشی سے غلط حساب لگائے، یا ریکارڈز کا نظام جو ناکامی بغیر لاگ کیے کھو دے، محض بگ والا نہیں۔ وہ ناقابل اعتماد ہے ایسے طریقے سے جو اس کے پیچھے ادارے کو کھوکھلا کرتا ہے۔

بنیادی اصول

خرابیوں، نقائص، اور ناکامیوں کو الگ پہچانیں، اور ہر ایک کو درست تہہ پر سنبھالیں۔
فوری ناکامی یا محفوظ ناکامی سوچ سمجھ کر، ہر سیاق میں، اتفاقاً کبھی نہیں چنیں۔
ہر فنکشن اور API کا خرابی سنبھالنے کا معاہدہ واضح اور ایماندار بنائیں۔
حدود پر توثیق کریں؛ ان کے اندر بھروسہ کریں؛ وسوسے کے بغیر دفاع کریں۔
کبھی خاموشی سے خرابی نہ نگلیں؛ اسے سامنے لائیں، لپیٹیں، یا جان بوجھ کر سنبھالیں۔
دوبارہ کوششوں کو یکسانی، ٹائم آؤٹ، بیک آف، اور جٹر سے محفوظ بنائیں۔
خرابی کے راستے کو خوش گوار راستے جتنی ہی ڈیزائن کی توجہ دیں۔

سفارشات

خرابیوں، نقائص، اور ناکامیوں میں فرق کریں

ڈھیلی لغت ڈھیلی ہینڈلنگ پیدا کرتی ہے، اس لیے واضح اصطلاحات سے شروع کریں۔ نقص نظام میں خامی ہے: بگ، بری ترتیب، بند انحصار۔ خرابی وہ غلط اندرونی حالت ہے جو نقص پیدا کرتا ہے: وہاں null جہاں قدر ہونی تھی، وہ بیلنس جو اب مصالحت نہیں کرتا۔ ناکامی وہ ہے جو بیرونی مشاہدہ کار دیکھتا ہے: درخواست غلط جواب لوٹاتی ہے، یا کوئی جواب نہیں۔ ایک نقص بہت سی خرابیاں پیدا کر سکتا ہے، اور بہت سی خرابیاں کسی کے نظر آنے والی ناکامی بننے سے پہلے پکڑی جا سکتی ہیں۔ خرابی سے نمٹنے کا پورا مقصد اس زنجیر کو توڑنا ہے، خرابی کو اس ناکامی بننے سے پہلے پکڑنا جو صارف یا آڈیٹر تجربہ کرتا ہے۔

یہ لغت یہ بھی بتاتی ہے کہ کہاں عمل کرنا ہے۔ نقائص کو ریویو، ٹیسٹنگ، اور ترتیب میں سنبھالا جاتا ہے۔ خرابیوں کو رن ٹائم پر اس باب کے نمونوں سے۔ ناکامیوں کو مشاہدہ پذیری (باب 9.2) اور باب 3.5 کی نظام کی سطح کی لچک سے۔ جب آپ کی ٹیم یہ الفاظ بانٹتی ہے تو واقعے کے جائزے تیز ہو جاتے ہیں: آپ ٹھیک کہہ سکتے ہیں کہ زنجیر کہاں ٹوٹنی چاہیے تھی اور نہیں ٹوٹی، بجائے اس بحث کے کہ “بگ” کیا تھا۔

فوری ناکامی یا محفوظ ناکامی ہر سیاق میں چنیں

فوری ناکامی کا مطلب ہے جس لمحے کچھ غلط ہو رک جانا، خراب حالت پر آگے بڑھنے سے انکار کرنا تاکہ مسئلہ بلند آواز سے اور اپنی وجہ کے قریب سامنے آئے۔ محفوظ ناکامی کا مطلب ہے معلوم، بے ضرر حالت میں گھٹ جانا اور وہ پیش کرتے رہنا جو آپ محفوظ طریقے سے کر سکتے ہیں۔ کوئی بھی عالمگیر طور پر درست نہیں، اور ہنر سیاق کے مطابق چننا ہے۔ ڈیولپمنٹ کے دوران اور اندرونی حدود پر فوری ناکامی آپ کی دوست ہے: جو پروگرام توڑے گئے عدم تغیر پر رک جائے وہ آپ کو لمبے اسرار کی جگہ چھوٹا اسٹیک ٹریس دیتا ہے۔ پروڈکشن میں، صارف کی طرف والے نظام کے کناروں پر، محفوظ ناکامی اکثر جیتتی ہے: سفارشات کا پینل جو کچھ نہ لوٹائے اس چیک آؤٹ صفحے سے بہتر ہے جو لوڈ ہی نہ ہو۔

یہ فیصلہ ہر حد کے لیے سوچ سمجھ کر کریں اور لکھ لیں۔ پرواز کنٹرول یا طبی آلے کا جزو متعین حالت میں محفوظ طور پر ناکام ہوتا ہے کیونکہ خراب ڈیٹا پر جاری رہنا کسی کو نقصان پہنچا سکتا ہے۔ کھاتے کی اندراج فوری ناکام ہوتی ہے کیونکہ غلط اندراج پوسٹ کرنا کوئی نہ کرنے سے برا ہے۔ غلط جوڑی دونوں سمتوں میں خطرناک ہے: جہاں فوری ناکامی چاہیے تھی وہاں محفوظ ناکامی بگاڑ چھپاتی ہے، اور جہاں محفوظ ناکامی چاہیے تھی وہاں فوری ناکامی ظاہری رکاوٹ کو بندش بنا دیتی ہے۔

خرابی کا اشارہ دینے کا طریقہ چنیں اور مستقل استعمال کریں

زبانیں آپ کو اشارہ دینے کے دو وسیع طریقے دیتی ہیں کہ کچھ غلط ہوا۔ استثنا کی ہینڈلنگ کال اسٹیک پر اوپر شے پھینکتی ہے جب تک کوئی ہینڈلر اسے پکڑ نہ لے، خرابی کے راستے کو مرکزی منطق سے الگ کرتے ہوئے۔ متبادل واضح خرابی کی قدریں ہیں: فنکشن نتیجہ اور خرابی دونوں لوٹاتا ہے، اور کال کرنے والے کو دونوں جانچنے ہوتے ہیں۔ بہت سی جدید زبانیں مؤخر الذکر کو Result قسم سے رسمی بناتی ہیں، جسے اکثر Result یا Either کہا جاتا ہے، جو کال کرنے والے کو قدر استعمال کرنے سے پہلے کامیابی یا ناکامی کھولنے پر مجبور کرتی ہے۔ ہر طریقے کی قیمت ہے۔ استثنا خوش گوار راستہ صاف رکھتے ہیں مگر کنٹرول کا بہاؤ چھپا سکتے ہیں اور ڈویلپرز کو ہر چیز پکڑنے والے بلاکس کی طرف راغب کرتے ہیں جو معلومات مٹا دیتے ہیں۔ واضح نتائج ہر ناکامی کو قسم کے دستخط میں نظر آنے والا بناتے ہیں مگر رسم بڑھاتے ہیں اور اگر زبان جانچ پر مجبور نہ کرے تو نظر انداز ہو سکتے ہیں۔

صحیح جواب اس بارے میں کم ہے کہ کون سا طریقہ، اور یکسانیت اور ایمانداری کے بارے میں زیادہ۔ وہ اسلوب چنیں جسے آپ کی زبان اور ماحولیاتی نظام ترجیح دیتے ہیں، اور اسے اپنی سروسز میں یکساں لاگو کریں تاکہ قاری ہمیشہ جانے کہ ناکامی کیسے سفر کرتی ہے۔ استثنا واقعی غیر معمولی حالتوں کے لیے رکھیں، عام کنٹرول کے بہاؤ کے لیے نہیں جیسے “صارف نہیں ملا”، جسے عام نتیجے کے طور پر ماڈل کرنا بہتر ہے۔ جو بھی چنیں، ناکامی کو کبھی غیر مرئی نہ ہونے دیں: بغیر جانچی خرابی کی قدر اتنی ہی خطرناک ہے جتنا خالی catch بلاک۔ بڑے کوڈ بیس میں تحریری اصول جمع وہ لنٹر جو نظر انداز خرابیاں نشان زد کرے کسی بھی فرد کی ترجیح سے بہتر ہے۔

خرابی سنبھالنے کا معاہدہ واضح بنائیں

ہر فنکشن اور ہر API کا خرابی سنبھالنے کا معاہدہ ہوتا ہے، چاہے کسی نے لکھا ہو یا نہیں۔ یہ جواب دیتا ہے: یہاں کیا غلط ہو سکتا ہے، آپ کو کیسے پتا چلے گا، اور جب ہو تو حالت کے بارے میں کیا ضمانت ہے؟ اس معاہدے کو واضح بنائیں۔ دستاویزی کریں کہ فنکشن کون سی خرابیاں لوٹا یا پھینک سکتا ہے، قابل بحالی خرابیوں (کال کرنے والا معقول طور پر دوبارہ کوشش کر سکتا ہے یا متبادل لے سکتا ہے) کو ناقابل بحالی سے الگ کریں (کال کرنے والا اسے ٹھیک نہیں کر سکتا اور اسے آگے بڑھانا یا ختم کرنا چاہیے)، اور بتائیں کہ آیا فنکشن ناکامی پر حالت کو بغیر تبدیل چھوڑتا ہے۔ یہ آخری خاصیت، جسے کبھی مضبوط استثنا کی ضمانت کہتے ہیں، کا مطلب ہے کہ ناکام کال ایسی ہے جیسے ہوئی ہی نہ ہو، جو ٹھیک وہی ہے جو کال کرنے والے کو محفوظ طور پر دوبارہ کوشش کرنے دیتی ہے۔

عوامی یا ٹیموں کے پار API کے لیے یہ معاہدہ انٹرفیس کا حصہ ہے، اتنا ہی حقیقی جتنی پیرامیٹر کی اقسام۔ چھوٹی، مستحکم خرابی کی درجہ بندی ڈیزائن کریں: زمروں کا محدود سیٹ جیسے توثیق کی خرابی، نہیں ملا، تنازع، غیر مجاز، انحصار دستیاب نہیں، اور اندرونی خرابی۔ کال کرنے والے پھر تاروں کو پارس کیے بغیر زمرے پر شاخ لے سکتے ہیں۔ واضح درجہ بندی خرابی سے نمٹنے کو بہت سی سروسز کے پار ترتیب پذیر بناتی ہے، اور ناکامیوں کو قابل آڈٹ بناتی ہے، کیونکہ ہر ناکامی معلوم، نام زد قسم سے ملتی ہے۔

حدود پر توثیق کریں اور وسوسے کے بغیر دفاع کریں

اعتماد کی حد پار کرنے والے ڈیٹا (نیٹ ورک کی درخواست، فائل، صارف کا ان پٹ، دوسری سروس کا پیغام) کو توثیق ہونے تک دشمن سمجھیں، اور اس کی توثیق حد پر ایک بار، مکمل طور پر کریں۔ یہ دفاعی پروگرامنگ ہے جو سمجھ بوجھ سے لاگو ہو۔ ایسے ماڈیول کے اندر جس کے ان پٹس آپ پہلے توثیق کر چکے ہوں، ہر لائن پر فالتو جانچیں منطق چھپاتی ہیں اور وہی ناکامیاں دباتی ہیں جو آپ دیکھنا چاہیں گے۔ نظم و ضبط یہ ہے: کناروں پر سخت دفاع کریں، ان کے اندر بھروسہ کریں۔ جہاں ڈیٹا داخل ہو وہاں ساخت، حدود، اور عدم تغیرات کی توثیق کریں، اسے ان اقسام میں بدلیں جو غیر قانونی حالتوں کو ناقابل اظہار بناتی ہیں، اور اندرونی کوڈ کو فرض کرنے دیں کہ وہ صاف ڈیٹا کے ساتھ کام کر رہا ہے۔

وسوسے کی حقیقی قیمت ہے۔ null کی جانچوں اور دفاعی شاخوں میں دبا ہوا کوڈ پڑھنا مشکل ہے، اور بدتر، یہ اکثر واضح ناکامی کو خاموش کندھے اچکانے میں بدل دیتا ہے، جہاں انتباہ اٹھانا تھا وہاں ڈیفالٹ لوٹاتا ہے۔ وہ دفاعی پن جو بگز چھپائے حفاظت نہیں؛ یہ ٹالنا ہے۔

دوبارہ کوششوں کو محفوظ، محدود، اور مہذب بنائیں

بہت سے نقائص عارضی ہوتے ہیں: لمحاتی نیٹ ورک کی ہچکی، سروس کا ری اسٹارٹ، مختصر لاک تنازع۔ کسی بھی تقسیم شدہ نظام (باب 3.3) میں یہ جزوی ناکامیاں استثنا کے بجائے معمول کی حالت ہیں۔ دوبارہ کوشش قدرتی جواب ہے، مگر سادہ دوبارہ کوشش کا لوپ بھرا ہوا ہتھیار ہے۔ پہلے، جس عمل کو آپ دوبارہ کوشش کریں اسے یکساں اثر والا بنائیں، یعنی اسے دو بار کرنے کا وہی اثر ہو جو ایک بار کرنے کا۔ یکسانی کے بغیر ٹائم آؤٹ کے بعد دوبارہ کوشش کارڈ پر دو بار چارج کر سکتی ہے یا دو ریکارڈ بنا سکتی ہے، کیونکہ آپ نہیں بتا سکتے کہ پہلی کوشش ناکام ہوئی یا صرف اس کی رسید کھو گئی۔ لکھنے کے لیے یکسانی کی کلیدیں استعمال کریں تاکہ وصول کنندہ دہراؤ کو پہچان کر ڈی ڈپ کر سکے۔

دوسرے، ہر دور دراز کال پر ٹائم آؤٹ لگائیں تاکہ لٹکی ہوئی انحصار آپ کو نہ لٹکا دے۔ تیسرے، دوبارہ کوششوں کو تیز رفتاری سے بڑھتے بیک آف سے فاصلہ دیں، ہر کوشش کے بعد انتظار دگنا کرتے ہوئے، اور جٹر (چھوٹی بے ترتیب تاخیر) جوڑیں تاکہ ایک ساتھ بحال ہوتے ہزار کلائنٹ ہم وقت ہو کر ایسی بھگدڑ نہ بنائیں جو بحال ہوتی سروس کو دوبارہ گرا دے۔ چوتھے، دوبارہ کوششوں کی تعداد اور کل وقت محدود کریں، پھر شائستگی سے ہار مانیں۔ حدود، بیک آف، جٹر، اور یکسانی کے بغیر دوبارہ کوششیں ان عام ترین طریقوں میں سے ہیں جن سے چھوٹی ہچکی خود پر ڈھائی گئی بندش بن جاتی ہے۔

کوڈ میں سرکٹ بریکرز، بلک ہیڈز، اور شائستہ گھٹاؤ جوڑیں

جب انحصار واقعی بند ہو تو اسے دوبارہ آزمانا محض محنت ضائع کرتا اور گڑھا گہرا کرتا ہے۔ سرکٹ بریکر انحصار کی کالز کی ناکامی کی شرح دیکھتا ہے اور، جب ناکامیاں حد پار کریں، ٹھنڈا ہونے کی مدت کے لیے “کھل” جاتا ہے تاکہ ڈوبی کالز کا انتظار کرنے کے بجائے فوراً ناکام ہو۔ ٹھنڈا ہونے کے بعد وہ آزمائشی کال گزرنے دیتا ہے اور اگر انحصار بحال ہو گیا ہو تو دوبارہ بند ہو جاتا ہے۔ یہ آپ کے کال کرنے والوں (ڈھیر ہوتے ٹائم آؤٹ کے بجائے تیز، قابل پیش گوئی ناکامیاں) اور جدوجہد کرتی انحصار (بحال ہونے کے لیے سانس لینے کی گنجائش) دونوں کو بچاتا ہے۔ بلک ہیڈ کا نمونہ، جہاز کے پانی بند خانوں کے نام پر، وسائل الگ کرتا ہے تاکہ ایک سیر شدہ انحصار ہر تھریڈ یا کنکشن کھا کر پورے عمل کو ڈبو نہ دے؛ آپ ہر انحصار کو اپنا محدود پول دیتے ہیں۔

یہ نمونے کوڈ کی سطح پر شائستہ گھٹاؤ کے ساتھ جوڑ بناتے ہیں: جب غیر ضروری انحصار دستیاب نہ ہو تو خرابی کے بجائے کم مگر مفید نتیجہ لوٹائیں۔ باسی ہونے کے نوٹ کے ساتھ کیش شدہ ڈیٹا دکھائیں، ذاتی بنانے کا پینل چھپائیں، لکھائی کو بعد کے لیے قطار میں ڈالیں۔ یہ باب 3.5 کی نظام کی سطح کی لچک کا مقامی تکملہ ہے: فن تعمیر مشینوں کے پار فالتو پن دیتا ہے، اور آپ کا کوڈ تب معقول رویہ دیتا ہے جب کوئی ٹکڑا غائب ہو۔

خرابیوں کو سیاق کے ساتھ لپیٹیں اور کبھی نہ نگلیں

وہ خرابی جو جہاں ہوئی اس سے دس تہیں اوپر “connection refused” پڑھتی ہو تقریباً بے کار ہے۔ جیسے خرابی آگے بڑھے، اسے سیاق کے ساتھ لپیٹیں: آپ کیا کرنے کی کوشش کر رہے تھے، کون سی ہستی یا درخواست، کون سی انحصار، جبکہ اصل وجہ محفوظ رکھیں تاکہ جڑ کھو نہ جائے۔ اچھی زبانیں اور لائبریریاں خرابی کی زنجیر بندی کو براہ راست سپورٹ کرتی ہیں۔ ہدف یہ ہے کہ ایک لاگ لائن ڈیوٹی پر موجود انجینئر کو بتائے کہ کیا ناکام ہوا، کس عمل کے دوران، کس ان پٹ کے لیے۔ یہ باب 9.2 کی مشاہدہ پذیری اور باب 2.15 کی ڈی بگنگ کا خام مال ہے۔

بنیادی گناہ خرابی نگلنا ہے: خالی catch بلاک، نظر انداز لوٹائی قدر، ایسا catch جو debug سطح پر لاگ کرے اور یوں آگے بڑھے جیسے کچھ نہ ہوا۔ نگلی ہوئی خرابی غائب نہیں ہوتی؛ وہ بعد میں بگڑے ڈیٹا یا ناقابل وضاحت نقص کے طور پر دوبارہ ابھرتی ہے، اب اپنی وجہ سے کٹی ہوئی۔ ہر خرابی کو تین انجاموں میں سے ایک ملنا چاہیے: اسے سنبھالیں (بحال کریں یا گھٹائیں)، لپیٹ کر آگے بڑھائیں، یا اسٹیک کے اوپر پورے سیاق کے ساتھ لاگ کر کے ناکام ہوں۔ اگر آپ خرابی پکڑیں اور ان میں سے کچھ نہ کریں تو آپ نے آئندہ واقعہ اپنے مستقبل کے آپ سے چھپانا چنا ہے۔

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
استثنا	صاف خوش گوار راستہ؛ بغیر جانچے نظر انداز کرنا مشکل	چھپا کنٹرول کا بہاؤ؛ ہر چیز پکڑ کر مٹانے کی ترغیب
واضح خرابی کی قدریں / Result اقسام	دستخط میں ناکامی نظر آتی ہے؛ ہینڈلنگ پر مجبور	زیادہ رسم؛ نفاذ کے بغیر نظر انداز ہو سکتی ہے
فوری ناکامی	بگز بلند آواز سے اور وجہ کے قریب سامنے آتے ہیں	کنارے پر استعمال ہو تو صارف کا ناقص تجربہ
محفوظ ناکامی	پیش کرتا رہتا ہے؛ صارفین اور ڈیٹا کو بچاتا ہے	جہاں فوری ناکامی چاہیے تھی وہاں بگاڑ چھپا سکتی ہے
بیک آف کے ساتھ دوبارہ کوششیں	عارضی نقائص خود بخود جھیل لیتی ہیں	یکسانی کے بغیر بوجھ بڑھاتی اور دوہری لکھائیاں کرتی ہیں
سرکٹ بریکر	تیز ناکامیاں؛ انحصار کو بحال ہونے دیتا ہے	اضافی حالت اور ٹیوننگ؛ مستقل مسئلہ چھپا سکتا ہے
حدود پر دفاعی توثیق	خراب ڈیٹا جلد، ایک بار، بلند آواز سے پکڑتی ہے	حد سے زیادہ ہو تو منطق بھر دیتی اور حقیقی ناکامیاں چھپاتی ہے

مرکزی کھنچاؤ مرئیت اور شور کے درمیان ہے۔ خرابیاں بہت خاموشی سے سنبھالیں تو آپ مسائل کو مہنگا ہونے تک چھپاتے ہیں؛ انہیں ہر جگہ بہت بلند آواز سے سنبھالیں تو آپ اشارے کو رسم میں ڈبو دیتے اور اہم ناکامیاں ڈھانپ دیتے ہیں۔ مقام اور نیت سے حل کریں۔ حدود پر بلند اور سخت رہیں، جہاں خراب ڈیٹا اور انحصار کی ناکامیاں داخل ہوتی ہیں۔ اندرونی حصے میں خاموش اور بھروسہ مند رہیں، جہاں ان پٹس پہلے سے صاف ہیں۔ فوری ناکامی بمقابلہ محفوظ ناکامی ہر حد کے لیے طے کریں اور لکھ لیں۔ مقصد ایسا کوڈ ہے جہاں ہر ناکامی کا ایک واضح مالک اور ایک واضح انجام ہو، اور کچھ خاموشی سے دراڑوں میں نہ گرے۔

اپنی ٹیم کے ساتھ بحث کے سوالات

کیا ہماری سروسز میں مشترک خرابی کی درجہ بندی اور خرابی سنبھالنے کا اصول ہے، یا ہر ٹیم فی البدیہہ کرتی ہے؟ بڑی ٹیم پر یہ ان ناکامیوں کے درمیان فرق ہے جو ترتیب پاتی ہیں اور جو الجھاتی ہیں۔ جب ایک سروس توثیق کے مسئلے پر HTTP 500 لوٹائے، دوسری ٹائپ شدہ استثنا پھینکے، اور تیسری null لوٹائے تو ہر انضمام مذاکرات اور ہر واقعہ ترجمے کی مشق بن جاتا ہے۔ ایک ہی منطقی ناکامی کی مثالیں لائیں، مثلاً “ریکارڈ نہیں ملا”، اپنی تین سروسز میں، اور دیکھیں کہ وہ اس کا اشارہ کتنے مختلف طریقوں سے دیتی ہیں۔ جواب تحریری معیار بننا چاہیے: خرابی کے زمروں کا محدود سیٹ، انہیں اشارہ دینے کا مستقل طریقہ، اور لنٹر یا ریویو کی چیک لسٹ جو اسے نافذ کرے۔ یہاں یکسانیت ہر آئندہ انضمام، آڈٹ، اور آن کال شفٹ میں ثمر دیتی ہے۔
کیا ہر نازک حد کے لیے ہم نے جان بوجھ کر فوری ناکامی یا محفوظ ناکامی چنی ہے، اور کیا کوڈ اس انتخاب سے میل کھاتا ہے؟ زیادہ تر ٹیموں نے یہ فیصلہ کبھی واضح طور پر نہیں کیا، جس کا مطلب ہے کہ یہ ان کے لیے اس نے کیا جس نے پہلے کوڈ لکھا، اور غیر مستقل طور پر۔ متصادم غور حقیقی ہیں: محفوظ ناکامی صارفین کو خدمت دیتی رہتی ہے مگر بگاڑ پھیلنے دے سکتی ہے، جبکہ فوری ناکامی ڈیٹا بچاتی ہے مگر معمولی انحصار کی بندش کو نظر آنے والی ناکامی بنا سکتی ہے۔ اپنی واقعات کی تاریخ لائیں اور بدترین چند کے لیے پوچھیں کہ کیا کوڈ اس طرح ناکام ہوا جیسے آپ پہلے پوچھے جانے پر چنتے۔ آپ کو جو شہادت چاہیے وہ آپ کی حدود کا نقشہ ہے جس پر ہر ایک پر سوچا سمجھا لیبل ہو، خاص طور پر جہاں پیسہ، حفاظت، یا شہری ریکارڈ شامل ہوں۔ جہاں لیبل اور کوڈ اختلاف کریں، آپ کی اگلی اصلاح مل گئی۔
ہم نے آخری بار خرابی کا راستہ جان بوجھ کر کب آزمایا، اور کیا وہ ڈیزائن کے مطابق چلا؟ خرابی کا راستہ عموماً آپ کا سب سے کم ٹیسٹ شدہ کوڈ ہے، پھر بھی وہیں اعتماد جیتا یا ہارا جاتا ہے، اور “ہم محفوظ طریقے سے ناکام ہوتے ہیں” ایسا دعویٰ ہے جس کی آپ تائید نہیں کر سکتے اگر آپ نے اسے ہوتے کبھی نہیں دیکھا۔ یکسانی کے بغیر دوبارہ کوشش کا لوپ، غلط حد والا سرکٹ بریکر، شاذ ہی پہنچی جانے والی شاخ میں نگلا ہوا استثنا: یہ تب تک چھپے رہتے ہیں جب تک حقیقی واقعہ انہیں آپ کے لیے نہ ڈھونڈ لے۔ حقیقت پسندانہ ماحول میں جان بوجھ کر ناکامی ڈالنے (مارا گیا انحصار، پیدا کردہ ٹائم آؤٹ، خراب پے لوڈ) کے نتائج لائیں۔ اس کے بعد کا عمل ناکامی ڈالنے کو معمول بنانا ہے، تاکہ بحالی، گھٹاؤ، اور محفوظ ناکامی کے رویے کی مسلسل توثیق ہو، امید نہ کی جائے۔ ہر خرابی کا راستہ جو آپ نے کبھی نہیں چلایا وہ وعدہ ہے جو آپ نے ٹیسٹ نہیں کیا۔
ہمارے کون سے لکھنے کے عمل یکساں اثر والے ہیں، اور کہاں گمشدہ رسید کے بعد دوبارہ کوشش حقیقی دنیا کا اثر جیسے ادائیگی یا ریکارڈ دہرا دے گی؟ دوبارہ کوشش سب سے عام لچک کا اضطراری عمل ہے اور، بے احتیاطی سے کی جائے تو، عارضی ہچکی کو دہرائے پیسے یا ڈیٹا میں بدلنے کا سب سے عام طریقہ۔ بڑی ٹیم میں دوبارہ کوشش کی منطق اکثر مشترک کلائنٹس، مڈل ویئر، اور انفرادی سروسز میں ایک ساتھ رہتی ہے، اس لیے ایک لکھائی کئی تہوں پر دہرائی جا سکتی ہے اور کسی کی کل رویے کی ملکیت نہیں۔ متصادم کھنچاؤ یہ ہے کہ یکسانی کی کلیدیں، ڈی ڈپلیکیشن، اور محفوظ درخواست کے نتائج اسٹوریج اور کوڈ جوڑتے ہیں، اور ترسیل کے دباؤ تلے ٹیمیں انہیں ان لکھائیوں کے لیے چھوڑ دیتی ہیں جنہیں وہ غلطی سے محفوظ سمجھتی ہیں۔ اپنے بیرونی طور پر نظر آنے والے لکھنے کے عملوں کی فہرست لائیں، ہر ایک پر نشان کہ آیا اس میں یکسانی کی کلید ہے اور وصول کنندہ دہراؤ کیسے پہچانتا اور ڈی ڈپ کرتا ہے۔ انٹرپرائز اور سرکاری ترتیبوں میں پہلے وہ نشان زد کریں جو پیسہ منتقل کرتے ہیں یا شہری کا ریکارڈ بدلتے ہیں، کیونکہ دوہری ادائیگی یا دہرایا فائدہ آڈٹ کا نتیجہ اور کبھی قانونی خطرہ ہے، محض نقص نہیں۔
کیا ہمارے ٹائم آؤٹ، سرکٹ بریکرز، اور بلک ہیڈز ایک مشترک، ٹیسٹ شدہ لائبریری سے آتے ہیں، یا ہر ٹیم انہیں ہاتھ سے بناتی ہے؟ یہ نمونے بیان کرنے میں آسان اور باریک طور پر غلط کرنے میں آسان ہیں: غائب ٹائم آؤٹ، بریکر کی حد جو کبھی نہیں ٹرپ ہوتی، کنکشن پول کا سائز ایسا کہ ایک سست انحصار پورے عمل کو بھوکا مار دے۔ جب ہر ٹیم انہیں دوبارہ نافذ کرتی ہے تو آپ بہت سی ذرا ٹوٹی نقلیں جمع کرتے ہیں اور نقص ملنے پر اسے ایک بار ٹھیک کرنے کی کوئی ایک جگہ نہیں۔ متصادم غور یہ ہے کہ مشترک لائبریری مشترک انٹرفیس اور اپ گریڈ کی تال مسلط کرتی ہے، اور غیر معمولی رن ٹائمز یا لیٹنسی کی ضروریات والی ٹیمیں تنگ ہو سکتی ہیں یا اس سے بچ نکل سکتی ہیں۔ سروے لائیں کہ پروڈکشن میں دراصل کتنے الگ دوبارہ کوشش-اور-بریکر نفاذ چلتے ہیں، اور کن سروسز کی بیرونی کالز پر اب بھی کوئی ٹائم آؤٹ بالکل نہیں۔ بڑے انٹرپرائز یا ایجنسی کے لیے جانچی ہوئی مشترک لائبریری سلامتی کے ریویورز اور آڈیٹرز کو درجنوں کی بجائے ایک جزو بھی دیتی ہے جس کی تصدیق کی جائے، جو ہر ریویو کی لاگت گھٹاتا ہے۔
اگر کل رات واقعہ ہوا ہو تو کیا کوئی بھی آن کال انجینئر اسے ایک لاگ لائن سے سراغ لگا سکتا تھا، اور کیا آڈیٹر بعد میں نظام کی ریکارڈ کی ہر ناکامی دیکھ سکتا ہے؟ لپیٹی ہوئی، درجہ بند، اچھی طرح لاگ شدہ خرابی دس منٹ کی تشخیص اور آدھی رات کی کھدائی کا فرق ہے، اور نگلی ہوئی آئندہ واقعہ ہے جو آپ نے خود سے چھپایا۔ بڑی ٹیم پر ناکامیاں کئی سروس ہاپس سے گزرتی ہیں، اس لیے قدر مستقل سیاق اور ہم آہنگی کے شناخت کنندگان سے آتی ہے جو ان ہاپس سے بچ جائیں، کسی ایک ٹیم کی محنت سے نہیں۔ متصادم کھنچاؤ لاگت اور شور ہے: سب کچھ لاگ کریں تو اشارہ ڈوبتا اور اسٹوریج کی قیمت دینی پڑتی ہے؛ بہت کم لاگ کریں تو آپ بحال نہیں کر سکتے کہ کیا ہوا۔ حالیہ حقیقی ناکامی لائیں اور اس کا نشان شروع سے آخر تک چلیں، ہر اس ہاپ پر نوٹ کرتے ہوئے جہاں سیاق گرا یا خرابی پکڑ کر پھینک دی گئی۔ ضابطے کے پابند اور سرکاری نظاموں میں اسے تعمیل کی خاصیت سمجھیں، کیونکہ ناقابل آڈٹ ناکامی، یا ایسا فیصلہ جو برسوں بعد آپ بیان نہ کر سکیں، قانونی خطرہ ہے اور محض آپریشنل خلا نہیں۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ مٹھی بھر انجینئروں اور فالتو رن وے کے بغیر اپنا خرابی سنبھالنے کا بجٹ وہاں خرچ کریں جہاں ناکامی کی قیمت گاہک یا ڈیٹا ہو: ہر بیرونی کال پر ٹائم آؤٹ لگائیں، پیسہ منتقل کرنے والی لکھائیاں یکساں اثر والی بنائیں، اور نظر انداز خرابیوں کے خلاف لنٹ کا اصول جوڑیں۔ مفصل فریم ورک چھوڑیں؛ بنیادی فنکشنز کے لیے Result قسم اور غیر نازک انحصارات پر شائستہ گھٹاؤ چند دن کے کام میں زیادہ تر حفاظت خرید لیتے ہیں۔ ڈیولپمنٹ میں فوری ناکام ہوں تاکہ بگز بلند آواز سے سامنے آئیں، اور سرکٹ بریکر ہاتھ سے بنانے کی مزاحمت کریں جب تک آپ کے پاس ایسی انحصار نہ ہو جو اس کا جواز دے۔

چھوٹا کاروبار۔ عملے پر لچک کے ماہر کے بغیر اور تنگ بجٹ کے ساتھ اس پر انحصار کریں جو آپ کی زبان، فریم ورک، اور کلاؤڈ فراہم کنندہ پہلے سے دیتے ہیں بجائے نمونے شروع سے بنانے کے: منظم قطاریں، فراہم کنندہ کی طرف کی دوبارہ کوششیں، اور لائبریری کے ٹائم آؤٹ زیادہ تر ٹیموں کی توقع سے زیادہ احاطہ کرتے ہیں۔ فیصلے کو خریدنے بمقابلہ بنانے کے طور پر پیش کریں، اور جہاں پختہ انحصار آپ کے لیے دوبارہ کوششیں، بیک آف، اور یکسانی سنبھالے وہاں خریدیں۔ اپنی کم یاب توجہ ایک یا دو حدود پر لگائیں جہاں غلط یا کھوئی ہوئی ٹرانزیکشن واقعی نقصان دے، اور یقینی بنائیں کہ وہ محفوظ طریقے سے ناکام ہوں اور نشان چھوڑیں۔

بڑا ادارہ۔ بہت سی ٹیموں میں انعام یکسانیت ہے: مشترک خرابی کی درجہ بندی، ٹائم آؤٹ، دوبارہ کوششوں، سرکٹ بریکرز، اور بلک ہیڈز کے لیے مشترک لائبریری، اور لنٹر اور ریویو کی چیک لسٹ جو انہیں پائپ لائن میں نافذ کریں۔ ہر خرابی کو ہم آہنگی کے شناخت کنندگان کے ساتھ متحد مشاہدہ پذیری کے پلیٹ فارم میں بھیجیں تاکہ ناکامی سروس ہاپس کے پار قابل سراغ ہو، اور فوری ناکامی بمقابلہ محفوظ ناکامی کے فیصلے ہر حد کے لیے معیاری بنائیں تاکہ آڈٹ مقامی عادات کے بکھراؤ کے بجائے دستاویزی، قابل دفاع نمونہ پائیں۔ مشترک لائبریری کو حقیقی پروڈکٹ کی طرح منظم کریں، کیونکہ وہاں ایک بار ٹھیک کیا گیا نقص ہر جگہ ٹھیک ہو جاتا ہے۔

حکومت۔ درستگی، محفوظ ناکامی، اور پائیدار آڈٹ کا نشان ذمہ داریاں ہیں، ترجیحات نہیں۔ کسی بھی ٹوٹے عدم تغیر پر جو پیسے یا اہلیت کو چھوتا ہو فوری ناکام ہوں، ہر شہری کی طرف والے ان پٹ کی حد پر توثیق کریں، اور ہر ناکامی کو ناقابل تبدیل لاگ میں اتنے سیاق کے ساتھ لکھیں کہ فیصلہ برسوں بعد بیان اور ریویو کیا جا سکے۔ خریداری اور نظاموں کی طویل عمر کا مطلب ہے کہ خرابی کے معاہدے دستاویزی ہونے چاہییں تاکہ سرکاری ملازمین اصل مصنفین کے چلے جانے کے بہت بعد کوڈ برقرار رکھ سکیں، اور کوئی بھی فروخت کنندہ جزو اپنی ناکامی کا رویہ مبہم انٹرفیس کے پیچھے چھپانے کے بجائے ظاہر کرے۔

مثالیں

اسٹارٹ اپ۔ چار افراد کا اسٹارٹ اپ ایسی ایپ ریلیز کرتا ہے جو تیسری پارٹی کے ادائیگی فراہم کنندہ اور ای میل سروس کو کال کرتی ہے۔ شروع میں وہ سادہ دوبارہ کوشش کا لوپ جوڑتے ہیں اور فوراً ایک گاہک سے دو بار چارج کر بیٹھتے ہیں جب ٹائم آؤٹ نے کامیاب چارج چھپا دیا۔ اصلاح سبق سکھاتی ہے: وہ ہر لکھائی میں یکسانی کی کلیدیں جوڑتے ہیں، ہر بیرونی کال پر ٹائم آؤٹ لگاتے ہیں، اور جٹر کے ساتھ تیز رفتاری سے بڑھتے بیک آف پر آتے ہیں۔ وہ بنیادی سروس فنکشنز کے لیے Result قسم اپناتے ہیں تاکہ ناکامی دستخط میں نظر آئے، اور لنٹ کا اصول ہر نظر انداز خرابی نشان زد کرتا ہے۔ جب ای میل بھیجنا ناکام ہو تو چیک آؤٹ فروخت روکنے کے بجائے پیغام قطار میں ڈال کر شائستگی سے گھٹتا ہے۔ نظم و ضبط چند دن لیتا ہے اور انہیں ایسے واقعات کی پوری قسم سے بچاتا ہے جس کی لاگت واپسیوں اور اعتماد میں کہیں زیادہ ہوتی۔

بڑا ادارہ۔ ایک عالمی لاجسٹکس کمپنی سینکڑوں سروسز چلاتی ہے اور ان سب میں خرابی سنبھالنا معیاری بناتی ہے۔ ہر سروس ناکامیوں کو مشترک درجہ بندی (توثیق، نہیں ملا، تنازع، انحصار دستیاب نہیں، اندرونی) سے ملاتی ہے، اس لیے کال کرنے والے پیغامات پارس کرنے کے بجائے زمرے پر شاخ لیتے ہیں۔ مشترک لائبریری سرکٹ بریکرز، بیک آف اور جٹر کے ساتھ محدود دوبارہ کوششیں، اور بلک ہیڈ والے کنکشن پول دیتی ہے، اس لیے کوئی انہیں غلط ہاتھ سے نہیں بناتا۔ ہر خرابی باب 9.2 کے مشاہدہ پذیری کے پلیٹ فارم کو کھلانے والے ہم آہنگی کے سیاق کے ساتھ لاگ ہوتی ہے، اس لیے آن کال انجینئر ایک لائن سے سروس ہاپس کے پار ناکامی کا سراغ لگا سکتا ہے۔ چونکہ معیار یکساں ہے اور پائپ لائن میں نافذ، انجینئر غیر مانوس سروسز میں اعتماد سے چلتے ہیں اور آڈیٹر دیکھ سکتے ہیں کہ ہر ناکامی ریکارڈ، درجہ بند، اور قابل سراغ ہے۔

حکومت۔ قومی فوائد کی ایجنسی اہلیت اور ادائیگی کا نظام بناتی ہے جہاں غلط جواب کسی کو کرائے کے پیسے سے محروم کر سکتا ہے یا عوامی خزانے سے زیادہ ادا کر سکتا ہے۔ درستگی اور محفوظ ناکامی غیر قابل مذاکرات ہیں، اس لیے کوڈ کسی بھی ٹوٹے مالی عدم تغیر پر فوری ناکام ہوتا ہے: حساب جو مصالحت نہ کر سکے غلط رقم پوسٹ کرنے کے بجائے پوسٹ کرنے سے انکار کرتا ہے۔ ہر شہری کی طرف والے ان پٹ کی حد پر توثیق ہوتی ہے، اور غیر قانونی حالتیں ڈومین کی اقسام میں ناقابل اظہار بنا دی جاتی ہیں۔ ہر ناکامی ناقابل تبدیل آڈٹ لاگ میں مکمل سیاق کے ساتھ لکھی جاتی ہے، جو قانونی تقاضا پورا کرتی ہے کہ فیصلے برسوں بعد بیان اور ریویو کے قابل ہوں۔ جہاں غیر نازک انحصار جیسے دستاویزی پیش نظارہ بند ہو، نظام شائستگی سے گھٹتا ہے تاکہ کیس ورکر پھر بھی دعویٰ نمٹا سکے۔ نئے سرکاری ملازمین ایسا کوڈ وراثت میں پاتے ہیں جس کے خرابی کے معاہدے دستاویزی ہیں، اس لیے وہ اسے اصل مصنفین کے آگے بڑھ جانے کے بہت بعد محفوظ طریقے سے برقرار رکھ سکتے ہیں۔

کاروباری جواز: محرکات، ROI اور TCO

نظم و ضبط والی خرابی سنبھالنے کی واپسی کم واقعات، چھوٹے واقعات، اور سستے واقعات کے طور پر ظاہر ہوتی ہے۔ زیادہ تر پروڈکشن بندشیں غیر معمولی نہیں ہوتیں؛ ان کا سراغ نگلے استثنا، غائب ٹائم آؤٹ، دوبارہ کوشش کے طوفان، یا ایسی حد تک جاتا ہے جس نے ایسے ڈیٹا پر بھروسہ کیا جس کی توثیق کرنی چاہیے تھی۔ ہر ایک یہاں کے نمونوں سے روکی جا سکتی ہے، اور ہر روکا گیا واقعہ نہ صرف بندش کی براہ راست لاگت بچاتا ہے بلکہ ہنگامی ردعمل، گاہکوں کے جانے، اور تحقیقات کی مرکب لاگتیں بھی۔ چونکہ لپیٹی ہوئی، اچھی طرح لاگ شدہ خرابی کی تشخیص گھنٹوں کے بجائے منٹوں میں ہو سکتی ہے، بحالی کا اوسط وقت گرتا ہے، اور تبدیلی کی ناکامی کی شرح اس کے ساتھ گرتی ہے جب انجینئر خرابی کے راستے سے ڈرنا چھوڑتے ہیں۔

اپنانے کی لاگت معمولی اور زیادہ تر ایک بار کی ہے۔ آپ خرابی کی درجہ بندی لکھتے ہیں، دوبارہ کوششوں اور سرکٹ بریکرز کے لیے مشترک لائبریری دیتے ہیں تاکہ ٹیمیں انہیں برے طریقے سے دوبارہ ایجاد نہ کریں، نظر انداز خرابیوں کے خلاف لنٹ کے اصول جوڑتے ہیں، اور ناکامی ڈالنے کی عادت بناتے ہیں۔ نظر انداز کرنے کی لاگت خاموشی سے مرکب ہوتی ہے: نگلی ہوئی خرابیاں بگڑے ڈیٹا میں جمع ہوتی ہیں جسے الٹنا مہنگا ہے، اور غیر مستقل ہینڈلنگ ہر انضمام اور ہر آڈٹ کی لاگت بڑھاتی ہے۔ ضابطے کے پابند اور سرکاری ترتیبوں میں ناقابل آڈٹ ناکامی تعمیل اور قانونی خطرہ ہے، محض انجینئرنگ کا مسئلہ نہیں۔ قیادت کے سامنے دلیل رکھنے کے لیے خرابی سنبھالنے کے نظم و ضبط کو ان اشاریوں سے جوڑیں جو وہ پہلے ہی دیکھتی ہے: واقعات کی تعدد، بحالی کا اوسط وقت، تبدیلی کی ناکامی کی شرح، اور آڈٹ کے نتائج۔

ضد نمونے اور خامیاں

خاموش نگلنا: خالی catch بلاکس اور نظر انداز لوٹائی قدریں جو ناکامی کو مؤخر، کٹا ہوا اسرار بنا دیتی ہیں۔
ہر چیز پکڑ کر مٹانا: وسیع catch جو عمومی پیغام لاگ کرے اور اصل خرابی اور اس کا سیاق پھینک دے۔
یکسانی کے بغیر دوبارہ کوشش: ٹائم آؤٹ کے بعد غیر یکساں لکھائیاں دوبارہ چلانا، دو بار چارج یا ریکارڈز دہرانا۔
دوبارہ کوشش کے طوفان: نہ بیک آف، نہ جٹر، نہ حد، اس لیے کلائنٹ ہم وقت ہو کر بحال ہوتی انحصار کو دوبارہ گرا دیتے ہیں۔
ٹائم آؤٹ نہیں: غیر محدود دور دراز کالز جو ایک لٹکی انحصار کو تھریڈز ختم کرنے اور پورا عمل جمانے دیتی ہیں۔
کنٹرول کے بہاؤ کے طور پر استثنا: “نہیں ملا” جیسے عام نتائج کے لیے پھینکنا اور پکڑنا، منطق چھپاتے اور کوڈ سست کرتے ہوئے۔
دفاعی وسوسہ: ہر لائن پر جانچیں جو منطق دفن کرتی اور حقیقی ناکامیوں کو خاموش ڈیفالٹس میں بدلتی ہیں۔
تار کی طرح برتی خرابیاں: کال کرنے والے خرابی کے پیغام کا متن پارس کرتے ہیں کیونکہ شاخ لینے کو مستحکم، درجہ بند درجہ بندی نہیں۔
جہاں فوری ناکامی چاہیے تھی وہاں محفوظ ناکامی: خراب حالت پر جاری رہنا ایسے نظام میں جہاں غلط جواب کوئی جواب نہ ہونے سے برا ہے۔

پختگی کا ماڈل

سطح 1، آغاز: خرابی سنبھالنا فی البدیہہ اور ردعملی ہے، ہر ڈویلپر کا اپنا فیصلہ۔ خالی catch بلاکس اور نظر انداز لوٹائی قدریں عام ہیں، دوبارہ کوششیں سادہ ہیں، ٹائم آؤٹ غائب ہیں، اور ناکامیاں بگڑے ڈیٹا یا پراسرار نقائص کے طور پر سامنے آتی ہیں جن کی کوئی مستقل لاگنگ نہیں۔
سطح 2، ترقی: ٹیمیں بنیادی عمل اپناتی ہیں، مگر غیر مستقل طور پر۔ خرابیاں کچھ سیاق کے ساتھ لاگ ہوتی ہیں، واضح نگلنے کی ریویو میں حوصلہ شکنی ہوتی ہے، اور ٹائم آؤٹ اور سادہ دوبارہ کوششیں موجود ہیں، مگر سروسز کے بیچ اصول مختلف ہیں، یکسانی ہلکی پھلکی ہے، اور خرابی کا راستہ شاذ ہی ٹیسٹ ہوتا ہے۔
سطح 3، معیار بندی: مشترک خرابی کی درجہ بندی اور ہینڈلنگ کا اصول دستاویزی اور پورے ادارے میں نافذ ہے۔ حد کی توثیق، بیک آف اور جٹر کے ساتھ یکساں دوبارہ کوششیں، سرکٹ بریکرز، بلک ہیڈز، اور خرابی لپیٹنا معیاری ہیں، مشترک لائبریریوں سے فراہم، اور ہر خرابی متحد مشاہدہ پذیری کی پائپ لائن کو کھلاتی ہے۔
سطح 4، انتظام: خرابی سنبھالنے کا رویہ بنیادی خطوط کے مقابل ناپا اور ڈیٹا سے کنٹرول کیا جاتا ہے۔ ہر سروس کے لیے دوبارہ کوششوں کی شرحیں، سرکٹ بریکر کے ٹرپ، ٹائم آؤٹ کی گنتی، جامد تجزیے سے نگلی خرابیوں کے نتائج، بحالی کا اوسط وقت، اور تبدیلی کی ناکامی کی شرح ٹریک ہوتے ہیں؛ سرکٹ بریکر کی حدیں اور ٹائم آؤٹ اندازے کے بجائے مشاہدہ شدہ لیٹنسی اور ناکامی کے ڈیٹا سے ٹیون ہوتے ہیں؛ ناکامی ڈالنا شیڈول پر چلتا ہے؛ اور ٹیمیں ان اشاریوں کا جائزہ لیتی ہیں تاکہ پسپائی پکڑیں اور ہر فوری ناکامی یا محفوظ ناکامی کے انتخاب کو شواہد کا پابند رکھیں۔
سطح 5، ہم آہنگی: لچک ترسیل اور خطرے کی منصوبہ بندی سے مربوط اور مسلسل بہتر ہوتی ہے۔ درجہ بندی، مشترک لائبریریاں، اور معیارات ہر واقعے سے ارتقا کرتے ہیں، افراتفری اور ناکامی ڈالنے کے تجربات معمول ہیں، اور ادارہ ٹائم آؤٹ، بریکر کی حدیں، گھٹاؤ کی حکمت عملیاں، اور حدود کے فیصلے ٹریفک، انحصارات، اور خطرے کی تصویر بدلنے کے ساتھ ڈھالتا ہے۔

بحث کے لیے خیالات

آپ کے کوڈ بیس میں اس وقت خرابی کہاں نگلی جاتی ہے، اور اگر آپ غلط ہوں کہ نہیں نگلی جاتی تو آپ کو کیسے پتا چلے گا؟
آپ کے کون سے لکھنے کے عمل یکساں اثر والے ہیں، اور کون سے دو بار چلیں گے اگر گمشدہ رسید کے بعد دوبارہ کوشش چلے؟
کیا “صارف نہیں ملا” استثنا ہونا چاہیے، خرابی کی قدر، یا عام نتیجہ، اور کیا آپ کی ٹیم اس کا مستقل جواب دیتی ہے؟
توثیق کہاں ہوتی ہے اس کا آپ کا اصل اصول کیا ہے، اور کیا آپ ایسی حد کی طرف اشارہ کر سکتے ہیں جو ایسے ڈیٹا پر بھروسہ کرتی ہے جس پر نہیں کرنا چاہیے؟
آپ سرکٹ بریکر کی حد اور ٹھنڈا ہونے کی مدت کیسے طے کرتے ہیں، اور آپ کو کیسے پتا چلے گا کہ موجودہ ترتیبات غلط ہیں؟
اگر آڈیٹر پوچھے کہ پچھلے مہینے آپ کے نظام نے کون سی ہر ناکامی دیکھی، تو کیا آپ اسے درجہ بند اور سیاق کے ساتھ پیش کر سکتے ہیں؟

اہم نکات

نقائص، خرابیوں، اور ناکامیوں میں فرق کریں، اور اندرونی خرابی کے نظر آنے والی ناکامی بننے سے پہلے زنجیر توڑیں۔
فوری ناکامی یا محفوظ ناکامی ہر حد کے لیے سوچ سمجھ کر چنیں، اور ہر فنکشن کا خرابی سنبھالنے کا معاہدہ واضح بنائیں۔
اعتماد کی حدود پر سخت توثیق کریں اور ان کے اندر بھروسہ کریں؛ وہ دفاعی پن جو ناکامیاں چھپائے ٹالنا ہے، حفاظت نہیں۔
دوبارہ کوششوں کو یکسانی، ٹائم آؤٹ، تیز رفتاری سے بڑھتے بیک آف، اور جٹر سے محفوظ بنائیں، اور کوڈ میں سرکٹ بریکرز اور شائستہ گھٹاؤ جوڑیں۔
خرابیوں کو سیاق کے ساتھ لپیٹیں، انہیں مشاہدہ پذیری میں بھیجیں، اور کبھی نہ نگلیں؛ ہر خرابی کو سنبھالا جائے، آگے بڑھایا جائے، یا لاگ کر کے سامنے لایا جائے۔

حوالہ جات اور مزید مطالعہ

Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
Andrew Hunt and David Thomas, The Pragmatic Programmer
Steve McConnell, Code Complete: A Practical Handbook of Software Construction
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
Marc Brooker, “Timeouts, Retries, and Backoff with Jitter,” Amazon Builders’ Library
Martin Fowler, “CircuitBreaker,” martinfowler.com
Nassim Nicholas Taleb, Antifragile: Things That Gain from Disorder