9.7 صلاحیت کی منصوبہ بندی اور طلب کی پیش گوئی

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

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

یہ باب دو پڑوسیوں کے درمیان بیٹھتا اور دونوں کا تکمیلی رہتا ہے۔ باب 3.5 پیمائش پذیری کو فن تعمیر کی خاصیت کے طور پر ڈھانپتا ہے: نظام کیسے بنایا جاتا ہے کہ وہ بڑھ سکے، statelessness، sharding، اور افقی پیمائش سے۔ باب 9.1 سائٹ ریلائیبلٹی انجینئرنگ (SRE) ڈھانپتا ہے، جو قابل اعتمادی کے اہداف طے کرتی ہے جن کا صلاحیت کو دفاع کرنا ہے۔ یہاں آپ فن تعمیر کو دیا ہوا اور اہداف کو مقرر مان کر مقداری سوال کا جواب دیتے ہیں: ہر چیز میں سے کتنا خریدنا، reserve کرنا، اور ریزرو میں رکھنا ہے تاکہ نظام اپنے service level objectives (SLOs، باب 9.1 کے قابل اعتمادی کے اہداف) پیش گوئی شدہ طلب اور ان اچھالوں میں پورے کرے جن کی آپ نے پیش گوئی نہیں کی۔ Autoscaling اور کارکردگی کی انجینئرنگ (باب 2.16) وہ ٹولز ہیں جو آپ یہاں استعمال کرتے ہیں، لیکن وہ منصوبہ بندی کے متبادل نہیں، اور انہیں منصوبہ بندی سمجھنا عام اور مہنگی غلطی ہے۔

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

بنیادی اصول

پیش گوئی شدہ طلب جمع دانستہ گنجائش کے لیے صلاحیت کی منصوبہ بندی کریں؛ saturation کے قریب نہ چلائیں۔
صلاحیت کی منصوبہ بندی، autoscaling، اور کارکردگی کی انجینئرنگ کو الگ رکھیں؛ ہر ایک مختلف مسئلہ حل کرتا ہے۔
رجحان، موسمی پن، معلوم واقعات، اور کاروباری نمو سے پیش گوئی کریں، صرف پچھلے ہفتے سے نہیں۔
اپنی حقیقی حدیں load testing اور benchmarking سے ڈھونڈیں، اندازے سے یا پروڈکشن کے انہیں ڈھونڈنے کا انتظار کر کے نہیں۔
saturation کے قریب تاخیر کو ڈھلوان نہیں، کھائی سمجھیں؛ استعمال کے اہداف queueing theory کی وجہ سے ہیں۔
اپنی سخت رکاوٹیں جانیں: connection pools، کوٹے، اور واحد نقطے autoscale نہیں ہوتے۔
لاگت کو قابل اعتمادی کے مقابل دانستہ متوازن کریں، اور صلاحیت کا ریویو واقعے کے بعد کی بجائے باقاعدہ تال پر کریں۔

سفارشات

صلاحیت کی منصوبہ بندی، autoscaling، اور کارکردگی کی انجینئرنگ کو الگ کریں

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

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

رجحان، موسمی پن، واقعات، اور کاروباری نمو سے طلب کی پیش گوئی کریں

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

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

استعمال کے اہداف طے کریں اور queueing-theory کی کھائی کا احترام کریں

پیسہ بچانے کو انفراسٹرکچر 90 فیصد استعمال پر “گرم” چلانے کی جبلت جال ہے، اور وجہ queueing theory ہے، جو باب 11.3 میں گہرائی سے ڈھکی ہے۔ جب وسیلہ مکمل استعمال کے قریب پہنچتا ہے تو انتظار کا وقت نرمی اور خطی طور پر نہیں بڑھتا؛ یہ پھٹ پڑتا ہے۔ 50 فیصد استعمال پر سرور کے پاس آرام دہ گنجائش ہے؛ وہی سرور 90 فیصد پر کئی گنا بدتر تاخیر دیکھ سکتا ہے، اور 95 فیصد پر قطار پوری طرح بھاگ سکتی ہے۔ Saturation کے قریب تاخیر کھائی ہے، ڈھلوان نہیں، اور آپ کے صارفین وسیلے کے تکنیکی طور پر “بھرنے” سے بہت پہلے اس کھائی کو timeouts، retries، اور غلطیوں کے طور پر محسوس کرتے ہیں۔

یہی وجہ ہے کہ صلاحیت کے منصوبہ ساز استعمال کے اہداف 100 فیصد سے بہت نیچے رکھتے ہیں، تاخیر کے حساس سروسز کے لیے عموماً 50 فیصد سے 70 فیصد کی رینج میں، اور throughput پر مبنی batch کام کے لیے اونچے جو قطار برداشت کرتا ہے۔ ہدف ضیاع نہیں؛ یہ قابل پیش گوئی تاخیر کی قیمت ہے۔ ہدف SLO سے چنیں: اگر آپ کا تاخیر کا مقصد سخت ہے تو آپ کی استعمال کی چھت نیچی ہے، کیونکہ queueing کی پیدا کردہ دم کی تاخیر ٹھیک وہ ہے جو SLO اڑا دیتی ہے۔ گنجائش اور حفاظتی حاشیہ دو سمتوں سے ایک ہی خیال ہیں۔ گنجائش عام لوڈ اور صلاحیت کے درمیان خلا ہے؛ حفاظتی حاشیہ وہی خلا ہے جو بیمے کے طور پر ظاہر ہو اس پیش گوئی کے خلاف جو اونچی نکلے، failover جو لوڈ مرتکز کرے، یا اچھال جو آپ نے نہ دیکھا۔

load testing اور benchmarking سے حقیقی حدیں ڈھونڈیں

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

کئی الگ ٹیسٹ چلائیں۔ Load test متوقع چوٹی تک چڑھتا اور تصدیق کرتا ہے کہ SLO گنجائش کے ساتھ قائم ہے۔ Stress test ٹوٹنے کے نقطے سے آگے دھکیلتا ہے یہ دیکھنے کو کہ نظام کیسے ناکام ہوتا ہے، کیونکہ نرمی سے گھٹنے والا نظام ڈھے جانے والے سے بہت مختلف ہے۔ Soak test گھنٹوں یا دنوں معتدل لوڈ تھامتا ہے تاکہ میموری leaks، connection کی تھکن، اور ڈسک بھرنے کے مسائل سامنے آئیں جو صرف وقت کے ساتھ ظاہر ہوتے ہیں۔ Spike test اچانک لوڈ دے مارتا ہے یہ جانچنے کو کہ آیا autoscaling اور buffers صارفین کے نوٹس سے پہلے اسے جذب کرتے ہیں۔ پروڈکشن جیسے ڈیٹا اور ٹوپولوجی کے مقابل ٹیسٹ کریں، کیونکہ کھلونا ڈیٹا سیٹ پر ناپی حد جھوٹ بولتی ہے۔ نظام بدلنے پر یہ ٹیسٹ دوبارہ چلائیں، تاکہ آپ کے اعداد اس نظام کو بیان کریں جو آپ کے پاس ہے اس کو نہیں جو سال پہلے تھا۔

فراہمی کی حکمت عملیاں دانستہ چنیں

کلاؤڈ فراہم کنندگان آپ کو وہی صلاحیت ایسے طریقوں سے خریدنے دیتے ہیں جو قیمت کو لچک کے مقابل بدلتے ہیں، اور انہیں اچھی طرح ملانا وہ جگہ ہے جہاں حقیقی پیسہ بچتا ہے۔ On-demand صلاحیت لچکدار اور مہنگی ہے: آپ کسی بھی وقت شروع اور بند کرنے کی صلاحیت کے لیے پورا ریٹ دیتے ہیں، جو غیر متوقع اور مختصر عمر کے لوڈ کو موزوں ہے۔ Reserved صلاحیت (ایک یا تین سال کے commitments، یا savings plans) فی اکائی سستی ہے اسے استعمال کرتے رہنے کے وعدے کے بدلے، جو آپ کے مستحکم بنیادی خط کو موزوں ہے۔ Spot instances فاضل صلاحیت گہری رعایت پر بیچتے ہیں مگر تھوڑی وارننگ پر واپس لیے جا سکتے ہیں، جو fault-tolerant، مداخلت پذیر کام جیسے batch processing اور stateless workers کو موزوں ہے۔

جو نمونہ کام کرتا ہے وہ تہہ دار ہے۔ اپنے مستحکم بنیادی خط کو سب سے کم اکائی لاگت کے لیے reserved صلاحیت سے ڈھانپیں، روزانہ اور ہفتہ وار تغیر کو on-demand autoscaling سے جذب کریں، اور مداخلت پذیر batch کام رعایت کاٹنے کو spot پر ڈالیں۔ ان سروسز کے لیے پہلے سے فراہم شدہ صلاحیت کا گرم buffer pool رکھیں جو صفر سے scale کی cold-start تاخیر برداشت نہیں کر سکتیں، تاکہ اچانک اچھال نئے instances کے boot ہونے کے دوران قطار کی بجائے تیار صلاحیت سے ملے۔ درست امتزاج پورٹ فولیو کا فیصلہ ہے، اور آپ کی طلب کی شکل اور فراہم کنندہ کی قیمتیں بدلنے پر یہ بدلتا ہے، اس لیے اس پر نظر ثانی کریں۔

سخت رکاوٹوں کا نقشہ بنائیں جو autoscale نہیں ہوں گی

Autoscaling خطرناک اعتماد پیدا کرتی ہے، کیونکہ بہت سی حدیں اس چیز کے نیچے بیٹھی ہیں جو scale ہوتی ہے اور اس کے ساتھ نہیں ہلتیں۔ ڈیٹا بیس connection pools کلاسیکی مثال ہیں: اپنی stateless تہہ کو 10 سے 100 instances تک scale کریں اور ہر ایک اسی ڈیٹا بیس سے connections کھولتا ہے، جس کی ایک ساتھ connections پر سخت حد ہے اور وہ نئے مسترد کرنے لگے گا۔ کلاؤڈ اکاؤنٹس تقریباً ہر چیز پر کوٹے رکھتے ہیں: فی علاقہ instances، IP پتے، فی سیکنڈ API کالز، function کی concurrency۔ فن تعمیر کا کوئی بھی واحد نقطہ، بنیادی ڈیٹا بیس، leader node، مشترک cache، لائسنس شدہ appliance، چھت ہے جسے کہیں اور افقی پیمائش بلند نہیں کر سکتی۔

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

صرف اوسط نہیں، چوٹی کے واقعات کے لیے فراہمی کریں

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

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

صلاحیت کو instrument کریں اور تال پر اس کا ریویو کریں

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

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

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

طریقہ	فوائد	نقصانات
اونچا استعمال کا ہدف	فی اکائی کم لاگت؛ کم بیکار صلاحیت	saturation کے قریب تاخیر پھٹتی ہے؛ اچھال یا failover کی گنجائش نہیں
فراخ گنجائش	قابل پیش گوئی تاخیر؛ اچھال اور failover جذب کرتی ہے	زیادہ مستحکم لاگت؛ ناکارکردگی چھپا سکتی ہے
Reserved صلاحیت	مستحکم بنیادی خط کے لیے سب سے کم اکائی قیمت	طلب گرے یا بدلے تو commitment کا خطرہ
On-demand صلاحیت	لچکدار؛ متغیر لوڈ سے منٹ بہ منٹ ملتی ہے	سب سے زیادہ اکائی قیمت؛ بجٹ کو حیران کر سکتی ہے
Spot instances	مداخلت پذیر کام پر گہری رعایت	بغیر نوٹس واپس لیے جاتے ہیں؛ stateful یا تاخیر کے نازک کام کو ناموزوں
Autoscaling	دائرے کے اندر لوڈ خودکار ٹریک کرتی ہے	reserved کوٹے سے آگے نہیں جا سکتی؛ cold starts؛ نیچے کی حدیں چھپاتی ہے
Buffer pool (گرم صلاحیت)	اچانک اچھال فوراً جذب کرتا ہے	اچھالوں کے درمیان بیکار صلاحیت کی ادائیگی

مرکزی کھنچاؤ لاگت بمقابلہ قابل اعتمادی ہے، اور کوئی ترتیب دونوں کو بہتر نہیں کرتی۔ دبلے چلیں تو آپ پیسہ بچاتے ہیں اس دن تک جب اچھال saturated وسیلے سے ٹکرائے اور تاخیر queueing کی کھائی سے گر جائے۔ فراخ چلیں تو آپ آرام سے سوتے ہیں جبکہ اس گنجائش کی ادائیگی کرتے ہیں جو زیادہ تر وقت بیکار رہتی ہے۔ کھنچاؤ کو خوف یا کفایت شعاری کی بجائے SLO سے حل کریں۔ پیش گوئی شدہ چوٹیوں جمع حاشیے میں قابل اعتمادی کا ہدف پورا کرنے کو کافی گنجائش فراہم کریں، اس سے زیادہ نہیں، پھر FinOps (کلاؤڈ خرچ کے لیے مالی آپریشنز، باب 9.4) کو وہ ضیاع شکار کرنے دیں جو SLO کا دفاع نہیں کرتا۔ ہدف دانستہ توازن ہے: گنجائش کا ہر ڈالر دانستہ خریدا گیا تاکہ قابل اعتمادی کی معلوم مقدار خریدے، اور ضیاع کا ہر ڈالر دانستہ ہٹایا گیا کیونکہ وہ کچھ نہیں خریدتا۔

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

کیا ہم واقعی جانتے ہیں کہ ہماری ہر سخت رکاوٹ کس لوڈ پر باندھتی ہے، یا ہم فرض کر رہے ہیں کہ autoscaling ہمیں بچا لے گی؟ زیادہ تر ٹیمیں بتا سکتی ہیں کہ ان کے instances autoscale ہوتے ہیں، اور زیادہ تر نہیں بتا سکتیں کہ ان کے بنیادی ڈیٹا بیس پر ایک ساتھ connections کی حد کیا ہے، ان کی سب سے اہم تیسری پارٹی کی API rate کی حد، یا وہ اکاؤنٹ کوٹہ جو ان کی function کی concurrency کو محدود کرتا ہے۔ یہی حدیں آغاز ختم کرتی ہیں، اور stateless تہہ کے scale ہونے پر نہیں ہلتیں۔ اگر آپ کے پاس سخت حدوں کی لکھی فہرست ہے تو لائیں، اور اگر نہیں تو وہ غیر موجودگی ہی نتیجہ ہے۔ ہر حد کے لیے آپ کو تین عدد چاہییں: چھت، آج کا استعمال، اور وہ طلب کی سطح جہاں وہ ملتے ہیں۔ جہاں آپ تینوں پیش نہ کر سکیں آپ کے پاس ایسی رکاوٹ ہے جسے آپ امید سے سنبھال رہے ہیں۔
ہم نے آخری بار اپنی آنے والی بدترین چوٹی کی سطح تک پروڈکشن جیسے ڈیٹا پر load test کب کیا، اور کیا SLO گنجائش کے ساتھ قائم رہا؟ صلاحیت کا منصوبہ اس بارے میں دعووں کا مجموعہ ہے کہ نظام لوڈ کے تحت کیسے برتاؤ کرتا ہے، اور غیر آزمودہ دعویٰ سوٹ پہنا اندازہ ہے۔ جو چوٹی اہم ہے وہ پچھلے مہینے کی اوسط نہیں بلکہ اگلا آغاز، تعطیل، یا آخری تاریخ ہے، اور ٹیسٹ تبھی کچھ معنی رکھتا ہے جب ڈیٹا اور ٹوپولوجی پروڈکشن جیسے ہوں، کیونکہ کھلونا ڈیٹا سیٹ پر ناپی حد جھوٹ بولتی ہے۔ اپنے حالیہ ترین stress اور soak ٹیسٹوں کے نتائج لائیں، بشمول نظام کہاں ٹوٹا اور ٹوٹنے پر کیسے ناکام ہوا۔ اگر ایماندار جواب یہ ہے کہ آپ نے نظام کو دانستہ اس کے ٹوٹنے کے نقطے تک کبھی نہیں دھکیلا تو آپ وہ نقطہ پروڈکشن میں، بدترین ممکنہ وقت پر، صارفین کے دیکھتے ہوئے دریافت کریں گے۔
پروڈکٹ، مارکیٹنگ، اور آپریشنز اچھال کے ہونے سے پہلے انجینئرنگ کو کیسے بتاتے ہیں، اور کتنی پہلے؟ سب سے مہنگی صلاحیت کی ناکامیاں ماڈلنگ کی غلطیاں نہیں؛ وہ واقعات ہیں جن کی انجینئرنگ نے ٹریفک آنے تک سنا ہی نہیں۔ پیش گوئی تاریخ سے رجحان اور موسمی پن extrapolate کر سکتی ہے، لیکن واقعے کی کوئی تاریخ نہیں، اس لیے وہ صرف انہی لوگوں سے آ سکتا ہے جو اس کی منصوبہ بندی کر رہے ہیں۔ پچھلے تین طلب کے اچھال لائیں اور ہر ایک کے لیے پوچھیں کہ انجینئرنگ کو کتنے دن کی وارننگ ملی اور آیا وہ صلاحیت reserve کرنے اور load test کرنے کو کافی تھی۔ جو شہادت آپ چاہتے ہیں وہ ایسا مستقل چینل ہے جس کا lead time فراہمی کو کافی لمبا ہو، کیونکہ اکیلے کلاؤڈ کوٹہ بڑھانے میں دن لگ سکتے ہیں۔ اگر چینل موجود نہیں تو آپ کا صلاحیت کا منصوبہ ٹھیک ان لمحوں سے اندھا ہے جن کی حفاظت کے لیے وہ موجود ہے۔
ہر تاخیر کے حساس سروس اصل میں کس استعمال کے ہدف پر چلتی ہے، اور کیا ہم اس عدد کو لاگت کے ہدف کی بجائے اس کے SLO تک سراغ لگا سکتے ہیں؟ یہ اس لیے اہم ہے کہ انفراسٹرکچر کو گرم چلانے کا دباؤ مسلسل ہے اور ادارے کے اس حصے سے آتا ہے جو بل دیکھتا ہے مگر queueing کی کھائی نہیں، اس لیے جب تک ہدف لکھا اور تاخیر کے مقصد سے جائز نہ ہو وہ اوپر بہتا ہے یہاں تک کہ اچھال کنارہ پا لے۔ متصادم غور ایک طرف حقیقی پیسہ اور دوسری طرف دم کی تاخیر ہے، اور ایماندار موقف یہ ہے کہ 100 فیصد سے نیچے کی گنجائش قابل پیش گوئی تاخیر کی قیمت ہے، ضیاع نہیں جسے چھانٹا جائے۔ اپنی اعلیٰ چند سروسز کا موجودہ استعمال، ہر ایک جس SLO کا دفاع کرتی ہے، اور اس استعمال پر لوڈ کے تحت ناپی تاخیر لائیں، تاکہ بحث جبلت کی بجائے شہادت سے ہو۔ انٹرپرائز یا سرکاری پلیٹ فارم میں جہاں ایک مشترک تالاب بہت سی سروسز کو سہارا دیتا ہے، ہدف مرکزی طور پر طے کریں اور ریکارڈ کریں کہ اسے بدلنے کا مجاز کون ہے، کیونکہ ایک ٹیم کا خاموشی سے اپنی چھت بڑھانا ایسے وسیلے کو کھائی کے پار دھکیل سکتا ہے جس پر دوسرے سب کے لیے منحصر ہیں۔
ہمارا reserved، on-demand، اور spot صلاحیت کا امتزاج کیا ہے، ہم نے آخری بار اس پر نظر ثانی کب کی، اور کیا یہ اب بھی ہماری طلب کی شکل سے ملتا ہے؟ امتزاج وہ جگہ ہے جہاں سب سے بڑی مسلسل بچت اور سب سے بڑا مسلسل ضیاع دونوں چھپے ہیں، کیونکہ on-demand ریٹ پر ادا ہونے والا مستحکم بنیادی خط ہر گھنٹے پیسہ جلاتا ہے جبکہ ضرورت سے زیادہ commit کی ہوئی reserved پوزیشن اس صلاحیت کی ادائیگی کرتی ہے جسے طلب نے بعد میں پیچھے چھوڑ دیا یا جس سے نیچے گر گئی۔ کھنچاؤ لاگت بمقابلہ لچک اور commitment کا خطرہ ہے: reserved صلاحیت فی اکائی سب سے سستی ہے مگر آپ کو باندھتی ہے، spot اس سے بھی سستا ہے مگر بغیر نوٹس واپس لیا جا سکتا ہے، اور on-demand ایک premium پر آزادی خریدتا ہے۔ لاگت کے حساب سے موجودہ تقسیم، وہ طلب کا منحنی جسے اسے ڈھانپنا ہے، اور کسی بھی spot ورک لوڈ کی واپس لیے جانے کی شرح اور دھماکے کا دائرہ لائیں، تاکہ کمرہ دیکھ سکے کہ مداخلت پذیر کام واقعی مداخلت پذیر ہے یا نہیں۔ انٹرپرائز اور سرکاری ترتیبوں میں reserved commitments کو خریداری اور بجٹ کے چکر سے جوڑیں، کیونکہ کئی سالہ commitments اور savings plans مالی ذمہ داریاں ہیں جنہیں مالیات اور آڈٹ پچھلی سہ ماہی کی سہولت کے مقابل نہیں بلکہ پیش گوئی شدہ طلب کے مقابل جائز دیکھنا چاہیں گے۔
جب نام زد چوٹی کا واقعہ آ رہا ہو تو pre-warming، کوٹے بڑھانے، ڈیپلائمنٹ کے انجماد، اور go/no-go کے فیصلے کا مالک کون ہے، اور کیا یہ runbook کے طور پر لکھا ہے جس کی ہم نے مشق کی؟ چوٹی کے واقعات وہ لمحے ہیں جن کی حفاظت کے لیے صلاحیت کی منصوبہ بندی ہے، اور وہ اکثر اس لیے ناکام نہیں ہوتے کہ منصوبہ غلط تھا بلکہ اس لیے کہ دن کے دباؤ میں اس پر عمل کا کوئی جوابدہ نہ تھا۔ یہاں متصادم غور رفتار اور خودمختاری بمقابلہ ہم آہنگی ہیں: ٹیمیں بھیجتے رہنا چاہتی ہیں، پھر بھی ابھار کی کھڑکی کے دوران خطرناک ڈیپلائمنٹ مہینوں کی فراہمی اڑا سکتی ہے، اس لیے کسی کے پاس منجمد کرنے اور آغاز روکنے کا اختیار ہونا چاہیے۔ اپنے اگلے بڑے واقعے کا runbook، کوٹہ بڑھانے اور buffer-pool کے گرم ہونے کے lead times، اور پچھلی بار ہر کردار کس نے سنبھالا اور کیا ہینڈ آف ٹکے کا ریکارڈ لائیں۔ حکومتی آخری تاریخ کے لیے جو خود مسلط، عوامی طور پر معلوم، اور ناقابل حرکت ہے، جوابدہ مالک اور escalation کا راستہ واضح نام لیں، کیونکہ لوڈ گرانے یا شہریوں سے بعد میں آنے کو کہنے کا کوئی اختیار نہیں، اور وہ چوٹی جس کا کوئی مالک نہیں اس کا دفاع کوئی نہیں کرے گا جب وہ آئے گی۔

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

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

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

بڑا ادارہ۔ مسئلہ سینکڑوں سروسز کے پیچھے مشترک، محدود تالابوں کا ہے، اس لیے صلاحیت پورٹ فولیو کا نظم و نسق بن جاتی ہے: برقرار رکھی سخت حدوں کی فہرست، SLOs سے مرکزی طور پر اخذ شدہ استعمال کے اہداف، اور reserved، on-demand، اور spot صلاحیت کا دانستہ امتزاج جس پر زندہ قیمتوں کے مقابل نظر ثانی ہو۔ Load، stress، soak، اور spike ٹیسٹ معیاری کریں تاکہ ہر ٹیم پروڈکشن جیسے ڈیٹا پر ایک ہی طرح ناپے، اور صلاحیت کے ریویو اس تال پر چلائیں جو سکڑتی گنجائش کو واقعہ پکڑنے سے پہلے پکڑے۔ ہم آہنگی کا واضح بجٹ بنائیں، کیونکہ جب کوئی پورے ماڈل کا مالک نہ ہو تو ایک ٹیم کی نمو دوسری کو بھوکا رکھ سکتی ہے۔

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

مثالیں

اسٹارٹ اپ۔ دس افراد کا اسٹارٹ اپ autoscaling والے کلاؤڈ انفراسٹرکچر پر صارف کی ایپ چلاتا ہے اور محفوظ محسوس کرتا ہے کیونکہ instance کی گنتی لوڈ کے ساتھ بڑھتی ہے۔ ان کا پہلا ٹیلی ویژن فیچر ایک گھنٹے میں ٹریفک تین گنا کر دیتا ہے، stateless تہہ خوبصورتی سے scale ہوتی ہے، اور ایپ پھر بھی گر جاتی ہے: ہر نیا instance ڈیٹا بیس connections کھولتا رہا یہاں تک کہ ڈیٹا بیس اپنی connection کی حد پر پہنچا اور انہیں مسترد کرنے لگا۔ سبق ان کا عمل بدل دیتا ہے۔ وہ ڈیٹا بیس کے سامنے connection pooler جوڑتے ہیں، درخواست اور جواب کے درمیان ہر سخت حد لکھتے ہیں، اور پروڈکشن کے سائز کے ڈیٹا سیٹ پر اپنی عام چوٹی کے کئی گنا تک load test کرتے ہیں۔ وہ رعایت کے لیے اپنا مستحکم بنیادی خط reserved صلاحیت کے commitment سے ڈھانپتے ہیں اور چھوٹا گرم buffer pool رکھتے ہیں تاکہ اگلا اچھال تیار صلاحیت سے ملے۔ تبدیلیاں ایک ہفتہ لیتی ہیں اور ان کے نازک اعتماد کو ایسے منصوبے میں بدلتی ہیں جس کا وہ دفاع کر سکیں۔

بڑا ادارہ۔ عالمی خوردہ فروش اپنے سب سے بڑے فروخت کے دن کو سال کا صلاحیت کا واقعہ سمجھتا ہے۔ مہینوں پہلے کثیر شعبہ جاتی ٹیم پچھلے برسوں کے رجحان اور موسمی پن جمع merchandising کے منصوبے سے طلب کی پیش گوئی بناتی ہے، پیش گوئی کو صلاحیت کے ماڈل کے ذریعے وسائل کی ضروریات میں بدلتی ہے، اور فراخ گنجائش کے ساتھ متوقع چوٹی کے لیے فراہمی کرتی ہے۔ وہ پروڈکشن جیسے ڈیٹا پر پورے راستے کا load، stress، soak، اور spike ٹیسٹ کرتے ہیں، ہفتوں پہلے ہر متعلقہ کلاؤڈ کوٹہ بلند کرتے ہیں، caches اور buffer pools پہلے سے گرم کرتے ہیں، اور گرد کی کھڑکی کے لیے خطرناک ڈیپلائمنٹس منجمد کرتے ہیں۔ Reserved صلاحیت لاگت کے لیے مستحکم بنیادی خط ڈھانپتی ہے، on-demand autoscaling روزانہ منحنی جذب کرتی ہے، اور مداخلت پذیر batch کام spot پر چلتا ہے۔ مشاہدہ پذیری واقعے کے دوران ہر محدود وسیلے کو اس کی حد کے مقابل حقیقی وقت میں ٹریک کرتی ہے، موجودہ قدر کی بجائے تخمینہ شدہ saturation پر الرٹس کے ساتھ۔ دن بغیر ڈرامے کے گزرتا ہے، جو ٹھیک وہ نتیجہ ہے جو منصوبہ بندی نے خریدا۔

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

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

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

اپنانے کی لاگت زیادہ تر ٹولنگ کی بجائے نظم و ضبط ہے۔ آپ طلب کی پیش گوئی بناتے ہیں، اپنی سخت حدیں لکھتے ہیں، تال پر load tests چلاتے ہیں، اپنی فراہمی کی حکمت عملیاں ملاتے ہیں، اور باقاعدہ صلاحیت کے ریویو کرتے ہیں۔ ملکیت کی کل لاگت (TCO) دونوں طرف سے ایک ساتھ بہتر ہوتی ہے: کم صلاحیت سے چلنے والے واقعات بندش اور ہنگامی ردعمل کی لاگت گھٹاتے ہیں، اور مسلسل درست سائز کاری جمع معقول reserved-اور-spot امتزاج مستحکم انفراسٹرکچر کا بل گھٹاتے ہیں۔ قیادت کے سامنے دلیل رکھنے کو صلاحیت کو ان اعداد سے جوڑیں جو وہ پہلے سے دیکھتے ہیں۔ کم فراہمی کو چوٹی کی بندش کے فی گھنٹہ کھوئی آمدنی اور معاہداتی جرمانوں والے SLO کی خلاف ورزیوں سے جوڑیں، اور زیادہ فراہمی کو باب 9.4 کی FinOps کے ضیاع کی رپورٹ سے۔ دلیل تجریدی احتیاط نہیں؛ یہ اس ڈائل کے دونوں طرف پیسہ ہے جسے آپ دانستہ طے کر سکتے ہیں۔

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

منصوبے کے طور پر autoscaling: لچکدار instances پر بھروسہ جبکہ ڈیٹا بیس connection pool، اکاؤنٹ کوٹہ، یا واحد نقطہ خاموشی سے پورے نظام کو محدود کرتا ہے۔
پیسہ بچانے کو گرم چلانا: 90 فیصد سے اوپر استعمال کا ہدف رکھنا اور queueing کی کھائی سے ملنا، جہاں تاخیر پھٹتی اور SLO ٹوٹتا ہے۔
چوٹیوں کی بجائے اوسط: اوسط لوڈ کے لیے سائز دینا تاکہ نظام ٹھیک اس چوٹی کے واقعے پر ناکام ہو جس کے لیے بنایا گیا تھا۔
صرف تاریخ سے پیش گوئی: رجحان اور موسمی پن extrapolate کرنا جبکہ آغاز یا مہم چوک جائے جس کی انجینئرنگ کو کبھی بتایا نہیں گیا۔
غیر آزمودہ حدیں: ایسے ٹوٹنے کے نقطے کے گرد منصوبہ بنانا جو کسی نے ناپا نہیں، پھر اسے پروڈکشن میں بدترین لمحے پر دریافت کرنا۔
کھلونا ڈیٹا کے load tests: غیر حقیقت پسند ڈیٹا اور ٹوپولوجی پر صلاحیت ناپنا، ایسے اعداد پیدا کرنا جو حقیقی نظام کے بارے میں جھوٹ بولیں۔
سخت حدوں کی فہرست نہیں: کوٹوں، pools، اور واحد نقطوں کو لکھی، برقرار رکھی فہرست کی بجائے یادداشت اور امید سے سنبھالنا۔
سب reserve یا کچھ نہیں: reserved صلاحیت پر ضرورت سے زیادہ commit کرنا جسے طلب پیچھے چھوڑ دے یا جس سے نیچے گر جائے، یا مستحکم بنیادی خط کے لیے پورے on-demand ریٹ ادا کرنا۔
صلاحیت کا ریویو صرف واقعات کے بعد: منصوبہ بندی کو ضرورت سے پہلے فراہمی کرنے والی باقاعدہ تال کی بجائے ردعملی آگ بجھانا سمجھنا۔

پختگی کا ماڈل

سطح 1، آغاز: صلاحیت ردعملی اور ایڈہاک ہے۔ ٹیمیں وسائل ختم ہونے کے بعد جوڑتی ہیں، autoscaling سب کچھ سنبھالنے پر بھروسہ کرتی ہیں، اور کوئی پیش گوئی، سخت حدوں کی فہرست، یا load testing نہیں۔ چوٹی کے واقعات کا سامنا امید سے ہوتا ہے، اور آغاز اور آخری تاریخوں کے دوران بندشوں کو بدقسمتی سمجھا جاتا ہے۔
سطح 2، ترقی: بنیادی عمل ظاہر ہوتے ہیں مگر ٹیم بہ ٹیم مختلف ہیں۔ کچھ مانیٹرنگ استعمال دکھاتی ہے، بڑے واقعات سے پہلے کچھ load testing ہوتی ہے، بڑے کوٹے معلوم ہیں، اور جگہ جگہ موٹی پیش گوئی موجود ہے، لیکن ماڈل برقرار نہیں رکھا جاتا، نیچے کی رکاوٹیں اکثر چوک جاتی ہیں، اور گنجائش SLO سے اخذ ہونے کی بجائے انگوٹھے کے اصول سے طے ہوتی ہے۔
سطح 3، معیار بندی: صلاحیت کی منصوبہ بندی دستاویزی، ادارے بھر نافذ نظم و ضبط ہے۔ طلب کی پیش گوئی رجحان، موسمی پن، واقعات، اور کاروباری نمو کو ملاتی ہے؛ سخت حدوں کی لکھی فہرست برقرار رکھی جاتی ہے؛ استعمال کے اہداف SLOs سے اخذ ہوتے ہیں؛ load، stress، soak، اور spike ٹیسٹ پروڈکشن جیسے ڈیٹا کے مقابل تال پر چلتے ہیں؛ اور فراہمی reserved، on-demand، اور spot کو دانستہ ملاتی ہے۔ مستقل چینل پروڈکٹ اور مارکیٹنگ سے انجینئرنگ تک واقعات کی وارننگیں پہنچاتا ہے۔
سطح 4، انتظام: صلاحیت بنیادی خطوط کے مقابل ناپی اور کنٹرول کی جاتی ہے۔ پیش گوئی کا ہر چکر میں اصل طلب سے موازنہ ہوتا اور غلطی ٹریک ہو کر نیچے لائی جاتی ہے؛ استعمال، saturation کے اشارے، اور ہر سخت حد کے مقابل گنجائش کو رجحان میں رکھا اور موجودہ قدروں کی بجائے تخمینوں پر الرٹ کیا جاتا ہے؛ چوٹی کے واقعات کا بعد میں اصل مشاہدہ شدہ چوٹی کے مقابل ریویو ہوتا ہے؛ اور فراہمی کا امتزاج، reserved-commitment کی coverage، اور فی-SLO لاگت میٹرکس کے طور پر رپورٹ ہوتی ہیں جو go یا no-go کے فیصلوں پر دروازہ لگاتی ہیں۔ جبلت کی بجائے ڈیٹا طے کرتا ہے کہ کیا reserve، بلند، یا ریٹائر کرنا ہے۔
سطح 5، ہم آہنگی: صلاحیت کی منصوبہ بندی مسلسل بہتر اور ادارے بھر مربوط ہے۔ پیش گوئیاں خودکار طور پر توثیق اور نکھاری جاتی ہیں، saturation کا تخمینہ لگا کر اس کے آنے سے پہلے فراہمی ہوتی ہے، فراہمی کے امتزاج زندہ قیمتوں کے مقابل بہتر کیے جاتے ہیں، چوٹی کے واقعات مشق شدہ runbooks سے چلتے ہیں، اور لاگت اور قابل اعتمادی کا پورے پلیٹ فارم پر SLO کے مقابل دانستہ توازن ہے۔ صلاحیت کا ماڈل مشترک، تطبیقی اثاثہ ہے جو طلب کی شکل اور فراہم کنندہ کی قیمتوں کے بدلنے پر بیڑے کو دوبارہ متوازن کرتا ہے۔

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

تاخیر کے حساس سروسز کے لیے آپ کا موجودہ استعمال کا ہدف کیا ہے، اور کیا آپ اسے پیسہ بچانے کی خواہش کی بجائے اپنے SLO اور queueing کے رویے سے جائز ٹھہرا سکتے ہیں؟
آپ کے کون سے اجزا بالکل autoscale نہیں ہو سکتے، اور جب ان میں سے کوئی saturate ہو تو باقی نظام کا کیا ہوتا ہے؟
اگر اگلی سہ ماہی میں آپ کی ٹریفک دگنی ہو تو کون سا وسیلہ پہلے اپنی چھت تک پہنچتا ہے، اور اسے بلند کرنے کو آپ کو کتنے دن کا lead time چاہیے؟
آپ reserved، on-demand، اور spot صلاحیت کا امتزاج کیسے طے کرتے ہیں، اور آخری بار اپنی اصل طلب کی شکل کے مقابل اس پر نظر ثانی کب کی؟
جب چوٹی کا واقعہ آ رہا ہو تو pre-warming، کوٹے بڑھانے، اور go/no-go کے فیصلے کا مالک کون ہے، اور کیا یہ runbook کے طور پر لکھا ہے؟
کیا آپ کے صلاحیت کے الرٹس ہفتوں پہلے تخمینہ شدہ saturation پر بجتے ہیں، یا صرف موجودہ استعمال پر جب دیوار پہلے ہی قریب ہو؟

اہم نکات

صلاحیت کی منصوبہ بندی رسد کو پیش گوئی شدہ طلب سے دانستہ گنجائش کے ساتھ ملاتی ہے؛ یہ autoscaling (قلیل مدتی، دائرے کے اندر) اور کارکردگی کی انجینئرنگ (کام کی سستی اکائیاں) سے الگ ہے۔
رجحان، موسمی پن، معلوم واقعات، اور کاروباری نمو سے پیش گوئی کریں، اور پروڈکٹ اور مارکیٹنگ سے واقعات کی وارننگیں لیں، کیونکہ واقعات کی کوئی تاریخ نہیں جس سے extrapolate ہو۔
queueing-theory کی کھائی (باب 11.3) کا احترام کریں: saturation کے قریب تاخیر پھٹتی ہے، اس لیے استعمال کے اہداف اپنے SLO سے طے کریں اور حقیقی گنجائش رکھیں۔
production جیسے ڈیٹا پر load، stress، soak، اور spike ٹیسٹنگ سے حدیں ڈھونڈیں، اور سخت رکاوٹوں کی لکھی فہرست رکھیں جو autoscale نہیں ہوں گی۔
گرم buffer pools کے ساتھ reserved، on-demand، اور spot صلاحیت کو ملائیں، نام زد چوٹی کے واقعات کی الگ منصوبہ بندی کریں، اور بندشوں کے بعد کی بجائے تال پر صلاحیت کا ریویو کریں۔

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

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
Martin L. Abbott and Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organisations for the Modern Enterprise
Brendan Gregg, Systems Performance: Enterprise and the Cloud
Leonard Kleinrock, Queueing Systems, Volume 1: Theory
J. R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management