3.5 وسعت پذیری، کارکردگی، اور لچک

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

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

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

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

مزید دیکھیں: باب 3.3 (تقسیم شدہ نظام)، باب 9.1 (سائٹ ریلائیبلٹی انجینئرنگ)، اور باب 9.2 (مشاہدہ پذیری اور نگرانی)۔

بنیادی اصول

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

سفارشات

افقی پیمائش کو ترجیح دیں اور بے حالت سروسز ڈیزائن کریں

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

لوڈ بیلنس، خودکار پیمائش، اور صلاحیت کی منصوبہ بندی کریں

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

واضح بجٹوں کے مقابل کارکردگی کی انجینئرنگ کریں

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

لچک کے نمونے بنائیں اور افراتفری انجینئرنگ سے توثیق کریں

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

کثیر خطہ، آفت سے بحالی، اور کاروباری تسلسل کی منصوبہ بندی کریں

بحالی کے مقاصد واضح طور پر طے کریں: RTO (Recovery Time Objective، آپ کتنی دیر بند رہ سکتے ہیں) اور RPO (Recovery Point Objective، آپ کتنا ڈیٹا کھونا برداشت کر سکتے ہیں)۔ یہ براہ راست لاگت کے مضمرات والے کاروباری فیصلے ہیں، اور یہ فن تعمیر کو چلاتے ہیں۔ اختیارات لاگت اور رفتار میں مختلف ہیں: بیک اپ-اور-بحالی (سستا ترین، سست ترین)، پائلٹ لائٹ، گرم اسٹینڈ بائی، اور فعال-فعال کثیر خطہ (مہنگا ترین، تقریباً صفر RTO/RPO)۔ وہ درجہ چنیں جس کا ہر نظام کی اہمیت جواز دے۔ ہر چیز کو فعال-فعال نہیں چاہیے۔ منتخب RPO کے مطابق خطوں کے پار ڈیٹا کی نقل کریں، فیل اوور خودکار بنائیں، اور سب سے بڑھ کر فیل اوور باقاعدگی سے ٹیسٹ کریں۔ غیر ٹیسٹ شدہ آفت سے بحالی قابل اعتماد طور پر ناکام ہوتی ہے جب آخرکار اس کی ضرورت پڑتی ہے۔ یہ سب کاروباری تسلسل کے منصوبے میں لپیٹیں جو لوگوں، رابطوں، اور دستی متبادلوں کا احاطہ کرے، صرف ٹیکنالوجی نہیں۔

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

انتخاب	فوائد	نقصانات
عمودی پیمائش	سادہ، کوڈ کی تبدیلی نہیں، کم ابتدائی محنت	سخت حد، اوپر مہنگی، ناکامی کا واحد نقطہ
افقی پیمائش	تقریباً لامحدود پیمانہ، دستیابی بہتر کرتی ہے	بے حالتی، لوڈ بیلنسنگ، زیادہ آپریشنز چاہیے
خودکار پیمائش	لاگت کو طلب سے ملاتی ہے، بدلتے بوجھ سنبھالتی ہے	تاخیر سے ردعمل؛ کولڈ اسٹارٹ؛ غلط ٹیون ہو تو ڈگمگا سکتی ہے
فعال-فعال کثیر خطہ	تقریباً صفر RTO/RPO، خطے کے نقصان سے بچتی ہے	سب سے زیادہ لاگت اور پیچیدگی، ڈیٹا کی مطابقت مشکل
بیک اپ-اور-بحالی DR	سستا ترین، سادہ ترین	لمبا RTO، ڈیٹا کھونے کی بڑی کھڑکی

مرکزی سمجھوتا لاگت بمقابلہ یقین دہانی ہے۔ پیمانے کی گنجائش، کارکردگی، اور بحالی کی صلاحیت کا ہر اضافہ پیسے اور پیچیدگی لاگت کرتا ہے، اور واپسی غیر خطی ہے۔ 99.9% سے 99.99% دستیابی، یا ایک گھنٹے کے RTO سے سیکنڈوں تک جانا لاگت کو کئی گنا کر سکتا ہے۔ نظم و ضبط یہ ہے کہ ہر سرمایہ کاری کو نظام کی حقیقی اہمیت اور بندش اور ڈیٹا کھونے کے لیے کاروبار کی برداشت کے مطابق سائز دیں، بجائے اس کے کہ اضطراری طور پر سب کو اعلیٰ ترین درجے کے لیے انجینئر کریں۔ شہری کی طرف والا ادائیگی کا نظام فعال-فعال فالتو پن کا مستحق ہے؛ اندرونی رپورٹنگ کا ٹول نہیں۔

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

جب آپ کا آخری سنگین واقعہ ہوا، تینوں میں سے (کارکردگی، وسعت پذیری، لچک) اصل میں کون ناکام ہوئی، اور کیا آپ نے درست ٹھیک کی؟ باب انہیں جان بوجھ کر الگ کرتا ہے: نظام تیز ہو کر بھی بوجھ تلے ڈھ سکتا ہے، پیمائش کر کے بھی ایک جزو مرنے پر گر سکتا ہے، یا ناکامیوں سے بچتے ہوئے سست ہو سکتا ہے۔ ٹیمیں اکثر غلط تشخیص کرتی ہیں، لچک کے مسئلے میں صلاحیت جوڑتی ہیں یا ایسے نظام کو مضبوط کرتی ہیں جو عروج کے لیے بس کم فراہم تھا۔ آخری دو سنگین واقعات سے گزریں اور نام لیں کہ کون سی خصوصیت ٹوٹی اور جواب نے دراصل کیا بہتر کیا۔ فرق اصلاح بدلتا ہے: پیمانے کے لیے بے حالتی اور شارڈنگ، لچک کے لیے فالتو پن اور سرکٹ بریکرز، کارکردگی کے لیے پروفائلنگ اور بجٹ۔ زمرہ درست کرنا علاج پر خرچ کرنے اور علامت پر خرچ کرنے کا فرق ہے۔
کیا کارکردگی کی پسپائیاں آپ کی پائپ لائن ناکام کرتی ہیں، یا کسی کے نوٹس کرنے سے پہلے صارفین تک پہنچتی ہیں؟ کارکردگی کا بجٹ (p95 لیٹنسی، صفحہ متعامل ہونے کا وقت، فی ٹرانزیکشن لاگت) صارفین کی حفاظت تبھی کرتا ہے جب وہ خودکار طور پر نافذ ہو، تاکہ جو تبدیلی اسے توڑے وہ بھیجنے کی بجائے بلڈ ناکام کرے۔ بہت سے شراکت کاروں والی بڑی ٹیم میں لیٹنسی ہزار چھوٹے کمٹس کے ذریعے رینگتی ہے، اور دروازے کے بغیر دم آہستہ آہستہ سڑتی ہے جب تک لانچ اسے بے نقاب نہ کرے۔ اپنے موجودہ بجٹ لائیں اور جانچیں کہ آیا وہ CI اور نگرانی میں جڑے ہیں، اور آیا وہ اوسط کی بجائے p95 اور p99 کو ہدف بناتے ہیں، کیونکہ پیمانے پر صارفین دم محسوس کرتے ہیں۔ جہاں کوئی بجٹ نہیں وہاں طے کرنا پہلا قدم ہے۔ نفاذ ہی اچھی نیت کو ایسی خاصیت بناتا ہے جو ٹیم کی نمو سے بچ جائے۔
دباؤ میں پہلے کیا گرایا جاتا ہے، اور کیا آپ نے وہ ترتیب ڈیزائن کی یا بندش میں دریافت کریں گے؟ شائستہ گھٹاؤ اور بوجھ گرانے کا مطلب ہے کہ نظام مرکز کی حفاظت کے لیے غیر ضروری کام چھوڑ دیتا ہے، مگر صرف تب جب آپ نے پہلے سے طے کیا ہو کہ ضروری کیا ہے۔ شہری کی طرف والی سروس کے لیے وہ درجہ بندی اکثر پالیسی کا فیصلہ ہے: ٹیکس ریٹرن جمع کرانا بچنا چاہیے چاہے حیثیت کے ڈیش بورڈ اور تاریخی تلاشیں بند ہو جائیں۔ اگر کسی نے نہیں چنا تو نظام جو بھی پہلے ناکام ہو وہ گراتا ہے، جو ٹھیک وہ ہو سکتا ہے جس کی صارفین کو سب سے زیادہ ضرورت ہے۔ اپنے فیچرز کو ترجیحی ترتیب میں فہرست کریں اور تصدیق کریں کہ فن تعمیر کم ترجیح والے (کیش شدہ جوابات، بند سفارشات، قطار میں غیر فوری کام) نازک راستے کو ساتھ لیے بغیر گرا سکتا ہے۔ پھر اسے حقیقی بوجھ تلے ٹیسٹ کریں، کیونکہ غیر ٹیسٹ شدہ گھٹاؤ محض امید ہے۔
اپنے سب سے نازک نظام کے لیے RTO اور RPO کیا ہیں، وہ اعداد دراصل کس نے چنے، اور آپ نے آخری بار کب ثابت کیا کہ آپ انہیں پورا کر سکتے ہیں؟ بحالی کے وقت کا مقصد (آپ کتنی دیر بند رہ سکتے ہیں) اور بحالی کے نقطے کا مقصد (آپ کتنا ڈیٹا کھونا برداشت کر سکتے ہیں) براہ راست لاگت کے مضمرات والے کاروباری فیصلے ہیں، پھر بھی بڑی ٹیم پر وہ اکثر اس نے ایجاد کیے ہوتے ہیں جس نے رن بک لکھی، نہ کہ ان کے مالک جو سروس کے جوابدہ ہیں۔ متصادم کھنچاؤ لاگت بمقابلہ یقین دہانی ہے: RTO کو گھنٹے سے سیکنڈ یا RPO کو منٹوں سے صفر تک گھٹانا انفراسٹرکچر کے بل کو کئی گنا کر سکتا ہے، اس لیے درست عدد وہ ہے جس کی کاروبار دراصل ادائیگی کرے گا، سب سے متاثر کن نہیں۔ دستاویزی مقاصد، آخری حقیقی فیل اوور ٹیسٹ کی تاریخ، اور اس ٹیسٹ سے ناپا گیا وقت اور ڈیٹا کھونا لائیں، کیونکہ غیر ٹیسٹ شدہ مقصد خواہش ہے۔ انٹرپرائز اور سرکاری ترتیبوں میں یہ اعداد قانون، معاہدے، یا SLA سے طے ہو سکتے ہیں، اس لیے نام لیں کہ ان پر دستخط کون کرتا ہے اور آخری مشق نے ذمہ داری پوری کی یا خاموشی سے چوک گئی۔
اپنے سب سے بڑے قابل پیش گوئی عروج کے لیے، کیا آپ خودکار پیمائش پر اس لمحے ردعمل کا بھروسہ کرتے ہیں، یا آپ نے بوجھ کی پیش گوئی کی، پہلے سے فراہم کیا، اور اس ہدف تک لوڈ ٹیسٹ کیا؟ خودکار پیمائش تاخیر سے ردعمل دیتی ہے اور کولڈ اسٹارٹ ٹھیک اس وقت لیٹنسی جوڑتے ہیں جب آپ سب سے کم برداشت کر سکتے ہیں، اس لیے معلوم قدم کی تبدیلی (فائلنگ کی آخری تاریخ، اندراج کی کھڑکی، فروخت کا واقعہ) ٹھیک وہ صورت ہے جہاں ردعملی پیمائش ناکام ہوتی اور سوچی سمجھی صلاحیت کی منصوبہ بندی جیتتی ہے۔ کھنچاؤ لاگت ہے: چوٹی کے لیے صلاحیت پہلے سے گرم کرنے کا مطلب ہے سال کے بیشتر حصے بیکار پڑی گنجائش کی ادائیگی، اور ترغیب ہے کہ امید کریں خودکار پیمائش مفت میں سنبھال لے۔ پچھلے سال کے عروج کے اعداد، اس سال کی نمو کے ساتھ پیش گوئی، اور آج کے اوسط ٹریفک کی بجائے اس پیش گوئی کے کئی گنا تک چلائے لوڈ ٹیسٹ کے نتائج لائیں۔ قانونی طور پر وقت کے پابند عروج کا سامنا کرنے والی سرکاری یا انٹرپرائز سروس کے لیے غلط کرنے کا نتیجہ شامل کریں، کیونکہ فوائد کا پورٹل یا ٹیکس کا نظام جو پہلے دن بیٹھ جائے وہ محض سست دوپہر نہیں بلکہ عوامی تحقیقات بن جاتا ہے۔
کیا آپ نے کبھی پروڈکشن میں جان بوجھ کر جزو ناکام کیا ہے، اور کیا ہر نظام کا فالتو پن کا درجہ اس کی اہمیت اور لاگت سے واقعی میل کھاتا ہے؟ جس لچک کو کبھی ٹیسٹ نہ کیا گیا وہ مفروضہ ہے، اور جو درجے آپ خرید سکتے ہیں وہ سستے بیک اپ-اور-بحالی سے گرم اسٹینڈ بائی کے ذریعے مہنگے فعال-فعال کثیر خطہ تک ہیں، اس لیے نظم و ضبط یقین دہانی وہاں خرچ کرنا ہے جہاں جائز ہو بجائے سب پر سونا چڑھانے یا کسی کی حفاظت نہ کرنے کے۔ متصادم غور دھماکے کا دائرہ اور بجٹ ہیں: افراتفری کے تجربات کو حفاظتی جنگلے اور روکنے کا سوئچ چاہیے، اور اندرونی رپورٹنگ کے ٹول کے لیے فعال-فعال ضیاع ہے جبکہ ادائیگیوں کے پلیٹ فارم کے لیے صرف بیک اپ غفلت۔ اپنے ناکامی کے واحد نقطوں کی فہرست، ہر نازک نظام کا فالتو پن کا درجہ، اور آخری کنٹرول شدہ ناکامی ڈالنے کی شہادت اور اس سے کیا ظاہر ہوا لائیں۔ انٹرپرائز اور سرکاری پورٹ فولیو میں ہر درجے کو دستاویزی اہمیت کی درجہ بندی سے ملائیں تاکہ آڈیٹر دیکھ سکے کہ پیسہ خطرے کے پیچھے چلتا ہے، اور کسی کو پہلی بار خرچ کا دفاع بندش کے دوران نہ کرنا پڑے۔

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

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

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

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

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

مثالیں

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

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

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

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

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

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

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

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

پختگی کا ماڈل

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

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

آپ کی کون سی سروسز اب بھی انسٹینس پر حالت رکھتی ہیں، اور انہیں بے حالت بنانے سے آپ کو کیا روکتا ہے؟
اپنے سب سے نازک نظام کے لیے RTO اور RPO کیا ہیں، انہیں کس نے طے کیا، اور آپ نے آخری بار کب ثابت کیا کہ آپ انہیں پورا کر سکتے ہیں؟
کیا خودکار پیمائش واقعی آپ کو آپ کے سب سے بڑے معلوم عروج سے بچاتی ہے، یا آپ اس سے وہ کروانے پر انحصار کر رہے ہیں جو وہ نہیں کر سکتی؟
آپ کا باقی ناکامی کا واحد نقطہ کہاں ہے، اور اسے ہٹانے کا منصوبہ کیا ہے؟
کیا آپ p99 لیٹنسی ناپ اور بجٹ کر رہے ہیں، یا اوسط کے پیچھے چھپ رہے ہیں؟
کیا آپ نے کبھی پروڈکشن میں جان بوجھ کر جزو ناکام کیا ہے؟ اگر نہیں تو آپ کو کیسے پتا کہ آپ کی لچک کام کرتی ہے؟

اہم نکات

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

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

Martin Kleppmann, Designing Data-Intensive Applications
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Betsy Beyer et al. (Google), Site Reliability Engineering and The Site Reliability Workbook
Casey Rosenthal and Nora Jones, Chaos Engineering
Brendan Gregg, Systems Performance: Enterprise and the Cloud
John Allspaw, The Art of Capacity Planning
Ilya Grigorik, High Performance Browser Networking
Nassim Nicholas Taleb, Antifragile