ویبینار میں خراب آڈیو ہے، اس لیے ہم نے اسے نقل کر دیا ہے۔
میرا نام Medvedev Eduard ہے۔ آج میں اس بارے میں بات کروں گا کہ SRE کیا ہے، SRE کیسے ظاہر ہوا، SRE انجینئرز کے کام کا کیا معیار ہے، تھوڑا سا قابل اعتماد معیار کے بارے میں، تھوڑا سا اس کی نگرانی کے بارے میں۔ ہم سب سے اوپر چلیں گے، کیونکہ آپ ایک گھنٹے میں زیادہ کچھ نہیں بتا سکتے، لیکن میں اضافی جائزے کے لیے مواد دوں گا، اور ہم سب آپ کا انتظار کر رہے ہیں۔ . جنوری کے آخر میں ماسکو میں۔
پہلے، آئیے اس بارے میں بات کرتے ہیں کہ SRE کیا ہے - Site Reliability Engineering۔ اور یہ ایک الگ مقام کے طور پر، ایک الگ سمت کے طور پر کیسے ظاہر ہوا۔ یہ سب اس حقیقت کے ساتھ شروع ہوا کہ روایتی ترقیاتی حلقوں میں، Dev اور Ops دو بالکل مختلف ٹیمیں ہیں، عام طور پر دو بالکل مختلف مقاصد کے ساتھ۔ ترقیاتی ٹیم کا ہدف نئی خصوصیات کو متعارف کرانا اور کاروبار کی ضروریات کو پورا کرنا ہے۔ Ops ٹیم کا مقصد یہ یقینی بنانا ہے کہ ہر چیز کام کرے اور کچھ بھی نہ ٹوٹے۔ ظاہر ہے، یہ اہداف ایک دوسرے سے براہ راست متصادم ہیں: ہر چیز کے کام کرنے کے لیے اور کچھ بھی نہیں ٹوٹنے کے لیے، نئے فیچرز کو کم سے کم رول آؤٹ کریں۔ اس کی وجہ سے، بہت سے اندرونی تنازعات ہیں جنہیں اب ڈیو اوپس کہلانے والا طریقہ کار حل کرنے کی کوشش کر رہا ہے۔
مسئلہ یہ ہے کہ ہمارے پاس DevOps کی واضح تعریف اور DevOps کا واضح نفاذ نہیں ہے۔ میں نے 2 سال قبل یکاترینبرگ میں ایک کانفرنس میں بات کی تھی، اور اب تک ڈی او اوپس سیکشن کا آغاز رپورٹ "ڈی او اوپس کیا ہے" سے ہوا تھا۔ 2017 میں، Devops تقریبا 10 سال کی عمر میں ہے، لیکن ہم اب بھی بحث کر رہے ہیں کہ یہ کیا ہے. اور یہ ایک بہت ہی عجیب صورتحال ہے جسے گوگل نے چند سال پہلے حل کرنے کی کوشش کی تھی۔
2016 میں، Google نے Site Reliability Engineering کے نام سے ایک کتاب جاری کی۔ اور درحقیقت اسی کتاب کے ساتھ ہی SRE تحریک کا آغاز ہوا۔ SRE ایک مخصوص کمپنی میں DevOps پیراڈیم کا ایک مخصوص نفاذ ہے۔ SRE انجینئر اس بات کو یقینی بنانے کے لیے پرعزم ہیں کہ سسٹم قابل اعتماد طریقے سے کام کریں۔ وہ زیادہ تر ڈویلپرز سے آتے ہیں، بعض اوقات مضبوط ترقیاتی پس منظر والے منتظمین۔ اور وہ وہی کرتے ہیں جو سسٹم کے منتظمین کیا کرتے تھے، لیکن ضابطہ کے لحاظ سے نظام کی ترقی اور علم کا ایک مضبوط پس منظر اس حقیقت کی طرف لے جاتا ہے کہ یہ لوگ معمول کے انتظامی کاموں کی طرف مائل نہیں ہیں، بلکہ آٹومیشن کی طرف مائل ہیں۔
یہ پتہ چلتا ہے کہ SRE ٹیموں میں DevOps کا نمونہ اس حقیقت سے لاگو ہوتا ہے کہ SRE انجینئرز ہیں جو ساختی مسائل کو حل کرتے ہیں۔ یہ ہے، دیو اور اوپس کے درمیان وہی تعلق جس کے بارے میں لوگ 8 سال سے بات کر رہے ہیں۔ ایس آر ای کا کردار ایک آرکیٹیکٹ کی طرح ہے جس میں نئے آنے والے ایس آر ای نہیں بنتے ہیں۔ اپنے کیریئر کے آغاز میں لوگوں کو ابھی تک کوئی تجربہ نہیں ہے، علم کی ضروری وسعت نہیں ہے. کیونکہ SRE کے لیے بالکل ٹھیک ٹھیک علم کی ضرورت ہوتی ہے کہ بالکل کیا اور کب غلط ہو سکتا ہے۔ لہذا، یہاں کچھ تجربے کی ضرورت ہے، ایک اصول کے طور پر، کمپنی کے اندر اور باہر دونوں.
وہ پوچھتے ہیں کہ کیا SRE اور devops کے درمیان فرق بیان کیا جائے گا۔ اسے ابھی بیان کیا گیا ہے۔ ہم تنظیم میں SRE کی جگہ کے بارے میں بات کر سکتے ہیں۔ اس کلاسک DevOps اپروچ کے برعکس، جہاں Ops اب بھی ایک الگ شعبہ ہے، SRE ترقیاتی ٹیم کا حصہ ہے۔ وہ مصنوعات کی ترقی میں ملوث ہیں. یہاں تک کہ ایک نقطہ نظر بھی ہے جہاں SRE ایک کردار ہے جو ایک ڈویلپر سے دوسرے کو منتقل ہوتا ہے۔ وہ کوڈ کے جائزوں میں اسی طرح حصہ لیتے ہیں جیسے، مثال کے طور پر، UX ڈیزائنرز، خود ڈویلپرز، بعض اوقات پروڈکٹ مینیجر۔ SREs ایک ہی سطح پر کام کرتے ہیں۔ ہمیں انہیں منظور کرنے کی ضرورت ہے، ہمیں ان کا جائزہ لینے کی ضرورت ہے، تاکہ ہر تعیناتی کے لیے SRE کہتا ہے: "ٹھیک ہے، یہ تعیناتی، اس پروڈکٹ سے اعتبار پر منفی اثر نہیں پڑے گا۔ اور اگر ایسا ہوتا ہے تو پھر کچھ قابل قبول حدود کے اندر۔ ہم اس پر بھی بات کریں گے۔
اس کے مطابق، SRE کے پاس کوڈ کو تبدیل کرنے کے لیے ویٹو ہے۔ اور عام طور پر، اگر SRE کو غلط طریقے سے لاگو کیا جاتا ہے تو یہ کسی قسم کے چھوٹے تنازعات کی طرف بھی جاتا ہے۔ سائٹ ریلائیبلٹی انجینئرنگ کے بارے میں اسی کتاب میں، بہت سے حصے، ایک بھی نہیں، بتائیں کہ ان تنازعات سے کیسے بچا جائے۔
وہ پوچھتے ہیں کہ SRE کا معلومات کی حفاظت سے کیا تعلق ہے۔ SRE معلومات کی حفاظت میں براہ راست ملوث نہیں ہے۔ بنیادی طور پر، بڑی کمپنیوں میں، یہ افراد، ٹیسٹرز، تجزیہ کاروں کے ذریعہ کیا جاتا ہے۔ لیکن SRE ان کے ساتھ اس لحاظ سے بھی بات چیت کرتا ہے کہ کچھ آپریشنز، کچھ کمٹ، کچھ تعیناتیاں جو سیکورٹی کو متاثر کرتی ہیں پروڈکٹ کی دستیابی کو بھی متاثر کر سکتی ہیں۔ لہذا، مجموعی طور پر SRE کا کسی بھی ٹیم کے ساتھ تعامل ہوتا ہے، بشمول سیکیورٹی ٹیمیں، بشمول تجزیہ کار۔ لہذا، SREs کی بنیادی طور پر ضرورت اس وقت ہوتی ہے جب وہ DevOps کو لاگو کرنے کی کوشش کر رہے ہوں، لیکن ساتھ ہی، ڈویلپرز پر بوجھ بہت زیادہ ہو جاتا ہے۔ یعنی ڈیولپمنٹ ٹیم خود اس حقیقت کا مقابلہ نہیں کر سکتی کہ اب انہیں بھی Ops کے لیے ذمہ دار بننے کی ضرورت ہے۔ اور الگ کردار ہے۔ بجٹ میں اس کردار کی منصوبہ بندی کی گئی ہے۔ کبھی کبھی یہ کردار ٹیم کے سائز میں طے ہوتا ہے، ایک الگ شخص ظاہر ہوتا ہے، کبھی کبھی ڈویلپرز میں سے ایک بن جاتا ہے۔ اس طرح ٹیم میں پہلا SRE ظاہر ہوتا ہے۔
نظام کی پیچیدگی جو SRE سے متاثر ہوتی ہے، وہ پیچیدگی جو آپریشن کی وشوسنییتا کو متاثر کرتی ہے، ضروری اور حادثاتی ہے۔ ضروری پیچیدگی اس وقت ہوتی ہے جب کسی پروڈکٹ کی پیچیدگی اس حد تک بڑھ جاتی ہے جس حد تک نئی مصنوعات کی خصوصیات کی ضرورت ہوتی ہے۔ بے ترتیب پیچیدگی اس وقت ہوتی ہے جب نظام کی پیچیدگی بڑھ جاتی ہے، لیکن مصنوعات کی خصوصیت اور کاروباری ضروریات اس پر براہ راست اثر نہیں ڈالتی ہیں۔ یہ پتہ چلتا ہے کہ یا تو ڈویلپر نے کہیں غلطی کی ہے، یا الگورتھم زیادہ سے زیادہ نہیں ہے، یا کچھ اضافی دلچسپیاں متعارف کرائی جاتی ہیں جو خصوصی ضرورت کے بغیر مصنوعات کی پیچیدگی کو بڑھاتے ہیں. ایک اچھے SRE کو ہمیشہ اس صورتحال کو ختم کرنا چاہئے۔ یعنی، کوئی بھی کمٹ، کوئی تعیناتی، کوئی پل کی درخواست، جہاں بے ترتیب اضافے کی وجہ سے پیچیدگی بڑھ جاتی ہے، اسے بلاک کر دینا چاہیے۔
سوال یہ ہے کہ کیوں نہ صرف ایک انجینئر، ایک سسٹم ایڈمنسٹریٹر کو ٹیم میں شامل کیا جائے جس میں بہت زیادہ علم ہو۔ ایک انجینئر کے کردار میں ایک ڈویلپر، ہمیں بتایا جاتا ہے، عملے کا بہترین حل نہیں ہے۔ انجینئر کے کردار میں ایک ڈویلپر ہمیشہ عملے کا بہترین حل نہیں ہوتا ہے، لیکن یہاں بات یہ ہے کہ ایک ڈویلپر جو Ops میں مصروف ہے، آٹومیشن کے لیے تھوڑی زیادہ خواہش رکھتا ہے، اس کے پاس کچھ زیادہ علم اور اس پر عمل درآمد کرنے کے لیے ایک مہارت ہوتی ہے۔ یہ آٹومیشن. اور اسی کے مطابق، ہم نہ صرف کچھ مخصوص آپریشنز کے لیے وقت کو کم کرتے ہیں، نہ صرف روٹین، بلکہ MTTR جیسے اہم کاروباری پیرامیٹرز (میان ٹائم ٹو ریکوری، ریکوری ٹائم)۔ اس طرح، اور ہم اس کے بارے میں تھوڑی دیر بعد بات کریں گے، ہم تنظیم کے لئے پیسہ بچاتے ہیں.
اب SRE کے آپریشن کے معیار کے بارے میں بات کرتے ہیں. اور سب سے پہلے وشوسنییتا کے بارے میں۔ چھوٹی کمپنیوں، سٹارٹ اپس میں اکثر ایسا ہوتا ہے کہ لوگ یہ فرض کر لیتے ہیں کہ اگر سروس اچھی لکھی جائے، پروڈکٹ کو ٹھیک اور درست لکھا جائے تو وہ چلے گا، ٹوٹے گا نہیں۔ بس، ہم اچھا کوڈ لکھتے ہیں، اس لیے توڑنے کے لیے کچھ نہیں ہے۔ کوڈ بہت آسان ہے، توڑنے کے لئے کچھ نہیں ہے. یہ انہی لوگوں کے بارے میں ہیں جو کہتے ہیں کہ ہمیں ٹیسٹ کی ضرورت نہیں ہے، کیونکہ دیکھو، یہ وی پی آئی کے تین طریقے ہیں، یہاں کیوں توڑتے ہیں۔
یقیناً یہ سب غلط ہے۔ اور یہ لوگ عملی طور پر اس طرح کے کوڈ سے اکثر کاٹتے ہیں، کیونکہ چیزیں ٹوٹ جاتی ہیں۔ چیزیں بعض اوقات انتہائی غیر متوقع طریقوں سے ٹوٹ جاتی ہیں۔ بعض اوقات لوگ کہتے ہیں کہ نہیں، ایسا کبھی نہیں ہوگا۔ اور یہ ہر وقت ہوتا ہے۔ اکثر کافی ہوتا ہے۔ اور اسی لیے کوئی بھی کبھی 100% دستیابی کے لیے کوشش نہیں کرتا، کیونکہ 100% دستیابی کبھی نہیں ہوتی۔ یہ معمول ہے۔ اور اس لیے، جب ہم کسی سروس کی دستیابی کے بارے میں بات کرتے ہیں، تو ہم ہمیشہ نائنز کے بارے میں بات کرتے ہیں۔ 2 نائنز، 3 نائنز، 4 نائنز، 5 نائنز۔ اگر ہم اسے ڈاؤن ٹائم میں ترجمہ کرتے ہیں، تو، مثال کے طور پر، 5 نائنز، تو یہ ہر سال 5 منٹ کے ڈاؤن ٹائم سے تھوڑا زیادہ ہے، 2 نائنز ڈاؤن ٹائم کے 3,5 دن ہیں۔
لیکن یہ ظاہر ہے کہ کسی وقت پی او آئی میں کمی واقع ہوتی ہے، سرمایہ کاری پر منافع۔ دو نائنز سے تین نائنز پر جانے کا مطلب ہے کہ 3 دن سے زیادہ کا وقت کم ہونا۔ چار نائنز سے پانچ پر جانے سے ہر سال ڈاؤن ٹائم 47 منٹ کم ہوجاتا ہے۔ اور یہ پتہ چلتا ہے کہ کاروبار کے لیے یہ اہم نہیں ہو سکتا۔ اور عام طور پر، مطلوبہ وشوسنییتا تکنیکی مسئلہ نہیں ہے، سب سے پہلے، یہ ایک کاروباری مسئلہ ہے، یہ ایک مصنوعات کا مسئلہ ہے۔ پروڈکٹ کے صارفین کے لیے کس سطح کا ڈاؤن ٹائم قابل قبول ہے، وہ کیا توقع کرتے ہیں، وہ کتنی رقم ادا کرتے ہیں، مثال کے طور پر، وہ کتنی رقم کھوتے ہیں، سسٹم کتنی رقم کھوتا ہے۔
یہاں ایک اہم سوال یہ ہے کہ باقی اجزاء کی کیا اعتبار ہے؟ کیونکہ 4 اور 5 نائنز کے درمیان فرق 2 نائنز کے قابل اعتماد اسمارٹ فون پر نظر نہیں آئے گا۔ موٹے الفاظ میں، اگر سال میں 10 بار آپ کی سروس میں کسی سمارٹ فون پر کوئی چیز ٹوٹ جاتی ہے، تو غالباً 8 بار OS کی طرف سے خرابی واقع ہوئی ہے۔ صارف اس کا عادی ہے، اور سال میں ایک بار مزید توجہ نہیں دے گا۔ بڑھتے ہوئے بھروسے اور بڑھتے ہوئے منافع کی قیمت کو آپس میں جوڑنا ضروری ہے۔
صرف SRE پر کتاب میں 4 نائنز سے 3 نائنز تک بڑھانے کی ایک اچھی مثال موجود ہے۔ یہ پتہ چلتا ہے کہ دستیابی میں اضافہ 0,1% سے تھوڑا کم ہے۔ اور اگر سروس کی آمدنی $1 ملین سالانہ ہے، تو آمدنی میں اضافہ $900 ہے۔ اگر قابل استطاعت میں اضافہ کرنے کے لیے ہمیں ایک سال میں $900 سے کم لاگت آتی ہے، تو یہ اضافہ مالی معنی رکھتا ہے۔ اگر اس کی لاگت ایک سال میں 900 ڈالر سے زیادہ ہوتی ہے، تو یہ اب کوئی معنی نہیں رکھتا، کیونکہ آمدنی میں اضافہ محض مزدوری کے اخراجات، وسائل کے اخراجات کی تلافی نہیں کرتا۔ اور 3 نائنز ہمارے لیے کافی ہوں گے۔
یہ یقیناً ایک آسان مثال ہے جہاں تمام درخواستیں برابر ہیں۔ اور 3 نائنز سے 4 نائنز کی طرف جانا کافی آسان ہے، لیکن ایک ہی وقت میں، مثال کے طور پر، 2 نائنز سے 3 تک جانا، یہ پہلے سے ہی 9 ہزار ڈالر کی بچت ہے، اس سے مالی سمجھ میں آ سکتا ہے۔ قدرتی طور پر، حقیقت میں، رجسٹریشن کی درخواست کی ناکامی صفحہ کو ظاہر کرنے میں ناکامی سے بدتر ہے، درخواستوں کا وزن مختلف ہوتا ہے۔ کاروباری نقطہ نظر سے ان کا معیار بالکل مختلف ہو سکتا ہے، لیکن بہرحال، ایک اصول کے طور پر، اگر ہم کچھ مخصوص خدمات کے بارے میں بات نہیں کر رہے ہیں، تو یہ کافی حد تک قابل اعتماد تخمینہ ہے۔
ہمیں ایک سوال موصول ہوا کہ کیا سروس کے لیے تعمیراتی حل کا انتخاب کرتے وقت SRE رابطہ کاروں میں سے ایک ہے۔ آئیے موجودہ بنیادی ڈھانچے میں انضمام کے لحاظ سے کہتے ہیں، تاکہ اس کے استحکام میں کوئی نقصان نہ ہو۔ جی ہاں، SREs، اسی طرح سے درخواستیں، کمٹ، ریلیزز فن تعمیر، نئی خدمات کا تعارف، مائیکرو سروسز، نئے حل کے نفاذ کو متاثر کرتی ہیں۔ میں نے پہلے کیوں کہا کہ تجربہ چاہیے، قابلیت چاہیے۔ درحقیقت، ایس آر ای کسی بھی آرکیٹیکچرل اور سافٹ ویئر حل میں بلاک کرنے والی آوازوں میں سے ایک ہے۔ اس کے مطابق، ایک انجینئر کے طور پر، ایک SRE کو، سب سے پہلے، نہ صرف یہ سمجھنا چاہیے، بلکہ یہ بھی سمجھنا چاہیے کہ کچھ مخصوص فیصلے کس طرح وشوسنییتا، استحکام کو متاثر کرتے ہیں، اور یہ سمجھنا چاہیے کہ اس کا کاروباری ضروریات سے کیا تعلق ہے، اور یہ کس نقطہ نظر سے قابل قبول ہو سکتا ہے۔ جو نہیں.
لہذا، اب ہم صرف وشوسنییتا کے معیار کے بارے میں بات کر سکتے ہیں، جو روایتی طور پر SRE میں SLA (سروس لیول ایگریمنٹ) کے طور پر بیان کیے گئے ہیں۔ غالباً ایک مانوس اصطلاح۔ SLI (سروس لیول انڈیکیٹر)۔ SLO (سروس لیول کا مقصد)۔ سروس لیول ایگریمنٹ شاید ایک علامتی اصطلاح ہے، خاص طور پر اگر آپ نے نیٹ ورکس کے ساتھ، فراہم کنندگان کے ساتھ، ہوسٹنگ کے ساتھ کام کیا ہے۔ یہ ایک عام معاہدہ ہے جو آپ کی پوری سروس کی کارکردگی، جرمانے، غلطیوں کے لیے کچھ جرمانے، میٹرکس، معیار کو بیان کرتا ہے۔ اور SLI خود دستیابی میٹرک ہے۔ یعنی، SLI کیا ہو سکتا ہے: سروس سے رسپانس ٹائم، فی صد کے طور پر غلطیوں کی تعداد۔ اگر یہ کسی قسم کی فائل ہوسٹنگ ہو تو یہ بینڈوتھ ہو سکتی ہے۔ جب پہچان الگورتھم کی بات آتی ہے تو، اشارے، مثال کے طور پر، جواب کی درستگی بھی ہو سکتا ہے۔ SLO (سروس لیول کا مقصد) بالترتیب SLI اشارے، اس کی قدر اور مدت کا مجموعہ ہے۔
آئیے کہتے ہیں کہ ایس ایل اے اس طرح ہوسکتا ہے۔ سروس پورے سال میں 99,95% وقت دستیاب رہتی ہے۔ یا 99 اہم سپورٹ ٹکٹ فی سہ ماہی 3 گھنٹے کے اندر بند کر دیے جائیں گے۔ یا 85% سوالات کے جوابات ہر ماہ 1,5 سیکنڈ کے اندر ملیں گے۔ یعنی دھیرے دھیرے ہم سمجھتے ہیں کہ غلطیاں اور ناکامیاں بالکل نارمل ہیں۔ یہ ایک قابل قبول صورتحال ہے، ہم اس کی منصوبہ بندی کر رہے ہیں، ہم کسی حد تک اس پر اعتماد بھی کر رہے ہیں۔ یعنی، ایس آر ای ایسے سسٹم بناتا ہے جو غلطیاں کر سکتے ہیں، جن کو عام طور پر غلطیوں کا جواب دینا چاہیے، جس میں ان کو مدنظر رکھنا چاہیے۔ اور جب بھی ممکن ہو، ان کو غلطیوں کو اس طرح سنبھالنا چاہیے کہ صارف یا تو ان پر توجہ نہ دے، یا نوٹس لے، لیکن اس کے لیے کوئی نہ کوئی حل ہے، جس کی بدولت ہر چیز مکمل طور پر گر نہ جائے۔
مثال کے طور پر، اگر آپ یوٹیوب پر کوئی ویڈیو اپ لوڈ کرتے ہیں، اور یوٹیوب اسے فوری طور پر تبدیل نہیں کرسکتا، اگر ویڈیو بہت بڑی ہے، اگر فارمیٹ بہترین نہیں ہے، تو قدرتی طور پر درخواست ٹائم آؤٹ کے ساتھ ناکام نہیں ہوگی، یوٹیوب 502 غلطی نہیں دے گا۔ ، یوٹیوب کہے گا: “ہم نے سب کچھ بنایا ہے، آپ کی ویڈیو پر کارروائی ہو رہی ہے۔ یہ تقریباً 10 منٹ میں تیار ہو جائے گا۔" یہ مکرم انحطاط کا اصول ہے، جو واقف ہے، مثال کے طور پر، سامنے کی ترقی سے، اگر آپ نے کبھی ایسا کیا ہے۔
اگلی شرائط جن کے بارے میں ہم بات کریں گے، جو کہ قابل اعتمادی کے ساتھ، غلطیوں کے ساتھ، توقعات کے ساتھ کام کرنے کے لیے بہت اہم ہیں، وہ ہیں MTBF اور MTTR۔ MTBF ناکامیوں کے درمیان درمیانی وقت ہے۔ MTTR کا مطلب وصولی کا وقت، بحالی کا اوسط وقت۔ یعنی، غلطی کا پتہ چلنے سے لے کر سروس کے مکمل نارمل آپریشن میں بحال ہونے تک کتنا وقت گزر چکا ہے۔ MTBF بنیادی طور پر کوڈ کے معیار پر کام کے ذریعے طے ہوتا ہے۔ یعنی، حقیقت یہ ہے کہ SREs "نہیں" کہہ سکتے ہیں۔ اور آپ کو پوری ٹیم کو سمجھنے کی ضرورت ہے کہ جب SRE "نہیں" کہتا ہے، تو وہ اس لیے نہیں کہتا کہ وہ نقصان دہ ہے، اس لیے نہیں کہ وہ برا ہے، بلکہ اس لیے کہ بصورت دیگر ہر کوئی نقصان اٹھائے گا۔
ایک بار پھر، بہت سارے مضامین، بہت سارے طریقے، بہت سارے طریقے ہیں یہاں تک کہ اس کتاب میں بھی جس کا میں اکثر حوالہ دیتا ہوں، یہ کیسے یقینی بنایا جائے کہ دوسرے ڈویلپرز SRE سے نفرت کرنا شروع نہ کریں۔ MTTR، دوسری طرف، آپ کے SLOs (سروس لیول مقصد) پر کام کرنے کے بارے میں ہے۔ اور یہ زیادہ تر آٹومیشن ہے۔ کیونکہ، مثال کے طور پر، ہمارا SLO 4 نائنز فی سہ ماہی کا اپ ٹائم ہے۔ اس کا مطلب ہے کہ 3 مہینوں میں ہم 13 منٹ کے ڈاؤن ٹائم کی اجازت دے سکتے ہیں۔ اور یہ پتہ چلتا ہے کہ MTTR 13 منٹ سے زیادہ نہیں ہو سکتا۔ اگر ہم 13 منٹ میں کم از کم 1 ڈاؤن ٹائم کا جواب دیتے ہیں، تو اس کا مطلب ہے کہ ہم نے سہ ماہی کا پورا بجٹ پہلے ہی ختم کر دیا ہے۔ ہم SLO کو توڑ رہے ہیں۔ 13 منٹ کا وقت ایک مشین کے لیے بہت زیادہ ہے، لیکن انسان کے لیے بہت مختصر ہے۔ کیونکہ جب تک کسی شخص کو الرٹ موصول نہیں ہوتا، جب تک وہ ردِ عمل ظاہر نہیں کرتا، جب تک کہ وہ غلطی کو نہیں سمجھتا، یہ پہلے ہی کئی منٹ ہے۔ جب تک کوئی شخص یہ نہ سمجھے کہ اسے کیسے ٹھیک کرنا ہے، کیا ٹھیک کرنا ہے، کیا کرنا ہے، تب یہ چند منٹ اور ہیں۔ اور حقیقت میں، یہاں تک کہ اگر آپ کو صرف سرور کو دوبارہ شروع کرنے کی ضرورت ہے، جیسا کہ یہ پتہ چلتا ہے، یا ایک نیا نوڈ بڑھاتا ہے، تو دستی طور پر MTTR پہلے سے ہی تقریبا 7-8 منٹ ہے. عمل کو خودکار کرتے وقت، MTTR اکثر ایک سیکنڈ، کبھی کبھی ملی سیکنڈ تک پہنچ جاتا ہے۔ گوگل عام طور پر ملی سیکنڈ کے بارے میں بات کرتا ہے، لیکن حقیقت میں، سب کچھ اتنا اچھا نہیں ہے۔
مثالی طور پر، SRE کو اپنے کام کو تقریباً مکمل طور پر خودکار کرنا چاہیے، کیونکہ یہ براہ راست MTTR، اس کے میٹرکس، پوری سروس کے SLO، اور اس کے مطابق، کاروباری منافع کو متاثر کرتا ہے۔ اگر وقت سے زیادہ ہو جائے تو ہم سے پوچھا جاتا ہے کہ کیا SRE غلطی پر ہے۔ خوش قسمتی سے، کوئی بھی قصوروار نہیں ہے۔ اور یہ ایک الگ کلچر ہے جسے balmeless postmortem کہا جاتا ہے، جس کے بارے میں ہم آج بات نہیں کریں گے، بلکہ Slurm پر اس کا تجزیہ کریں گے۔ یہ ایک بہت دلچسپ موضوع ہے جس پر بہت بات کی جا سکتی ہے۔ موٹے الفاظ میں، اگر فی سہ ماہی کے لیے مختص وقت سے زیادہ ہو جائے، تو تھوڑا تھوڑا سب کو قصور وار ٹھہرانا ہے، جس کا مطلب ہے کہ سب کو موردِ الزام ٹھہرانا نتیجہ خیز نہیں ہے، آئیے اس کے بجائے، شاید کسی پر الزام نہ لگائیں، لیکن حالات کو درست کریں اور جو کچھ ہمارے پاس ہے، اس سے کام لیں۔ میرے تجربے میں، یہ نقطہ نظر زیادہ تر ٹیموں کے لیے تھوڑا اجنبی ہے، خاص طور پر روس میں، لیکن یہ سمجھ میں آتا ہے اور بہت اچھا کام کرتا ہے۔ لہذا، میں مضمون اور ادب کے آخر میں تجویز کروں گا کہ آپ اس موضوع پر پڑھ سکتے ہیں۔ یا Slurm SRE پر آئیں۔
مجھے وضاحت کا موقع دیں. اگر SLO وقت فی سہ ماہی سے تجاوز کر گیا، اگر ڈاؤن ٹائم 13 منٹ نہیں بلکہ 15 تھا، تو اس کے لیے کون ذمہ دار ہو سکتا ہے؟ بلاشبہ، SRE کو قصوروار ٹھہرایا جا سکتا ہے، کیونکہ اس نے واضح طور پر کسی قسم کا برا عہد یا تعیناتی کیا تھا۔ ڈیٹا سینٹر کا منتظم اس کے لیے ذمہ دار ہو سکتا ہے، کیونکہ اس نے کسی قسم کی غیر طے شدہ دیکھ بھال کی ہو سکتی ہے۔ اگر ڈیٹا سینٹر کے منتظم کو اس کے لیے ذمہ دار ٹھہرایا جاتا ہے، تو اس کے لیے اوپس سے تعلق رکھنے والے شخص کو ذمہ دار ٹھہرایا جاتا ہے، جس نے SLO کو مربوط کرتے وقت دیکھ بھال کا حساب نہیں لگایا۔ مینیجر، ٹیکنیکل ڈائریکٹر یا کوئی ایسا شخص جس نے ڈیٹا سینٹر کے معاہدے پر دستخط کیے اور اس حقیقت پر توجہ نہیں دی کہ ڈیٹا سینٹر کا SLA مطلوبہ ڈاؤن ٹائم کے لیے ڈیزائن نہیں کیا گیا ہے، اس کا ذمہ دار ہے۔ اس کے مطابق، اس صورتحال میں آہستہ آہستہ سبھی قصوروار ہیں۔ اور اس کا مطلب یہ ہے کہ اس صورت حال میں کسی پر الزام لگانے کا کوئی فائدہ نہیں۔ لیکن یقیناً اسے درست کرنے کی ضرورت ہے۔ اسی لیے پوسٹ مارٹم ہوتے ہیں۔ اور اگر آپ پڑھتے ہیں، مثال کے طور پر، GitHub پوسٹ مارٹم، اور یہ ہمیشہ ہر ایک معاملے میں ایک بہت ہی دلچسپ، چھوٹی اور غیر متوقع کہانی ہوتی ہے، تو آپ اس کی جگہ لے سکتے ہیں کہ کوئی بھی یہ نہیں کہے گا کہ اس خاص شخص کا قصور تھا۔ الزام ہمیشہ مخصوص نامکمل عمل پر لگایا جاتا ہے۔
آئیے اگلے سوال کی طرف چلتے ہیں۔ آٹومیشن. جب میں دوسرے سیاق و سباق میں آٹومیشن کے بارے میں بات کرتا ہوں، تو میں اکثر ایک ٹیبل کا حوالہ دیتا ہوں جو آپ کو بتاتا ہے کہ آپ کسی کام کو خودکار کرنے میں کتنی دیر تک کام کر سکتے ہیں، اس سے زیادہ وقت نکالے بغیر اسے خودکار کرنے میں آپ کی اصل بچت ہے۔ ایک جھٹکا ہے۔ گرفت یہ ہے کہ جب SREs کسی کام کو خودکار بناتے ہیں، تو وہ نہ صرف وقت بچاتے ہیں، بلکہ پیسے بھی بچاتے ہیں، کیونکہ آٹومیشن براہ راست MTTR کو متاثر کرتی ہے۔ وہ ملازمین اور ڈویلپرز کے حوصلے کو بچاتے ہیں، جو کہ ایک مکمل وسیلہ بھی ہے۔ وہ معمول کو کم کرتے ہیں۔ اور یہ سب کام پر اور اس کے نتیجے میں کاروبار پر مثبت اثر ڈالتا ہے، یہاں تک کہ اگر ایسا لگتا ہے کہ وقت کی لاگت کے لحاظ سے آٹومیشن کا کوئی مطلب نہیں ہے۔
درحقیقت، یہ تقریباً ہمیشہ ہوتا ہے، اور بہت کم ایسے معاملات ہیں جہاں SRE کے کردار میں کسی چیز کو خودکار نہیں ہونا چاہیے۔ اگلا ہم اس کے بارے میں بات کریں گے جسے ایرر بجٹ کہا جاتا ہے، غلطیوں کا بجٹ۔ درحقیقت، یہ پتہ چلتا ہے کہ اگر سب کچھ آپ کے لیے SLO سے کہیں زیادہ بہتر ہے جو آپ نے اپنے لیے مقرر کیا ہے، تو یہ بھی بہت اچھا نہیں ہے۔ یہ بہت برا ہے، کیونکہ SLO نہ صرف نچلے حصے کے طور پر کام کرتا ہے، بلکہ تقریبا اوپری حد کے طور پر بھی کام کرتا ہے۔ جب آپ اپنے آپ کو 99% دستیابی کا SLO طے کرتے ہیں، اور درحقیقت آپ کے پاس 99,99% ہے، تو پتہ چلتا ہے کہ آپ کے پاس تجربات کے لیے کچھ جگہ ہے جس سے کاروبار کو کوئی نقصان نہیں پہنچے گا، کیونکہ آپ نے خود ہی یہ سب مل کر طے کیا ہے، اور آپ ہیں یہ جگہ استعمال نہیں کرتے. آپ کے پاس غلطیوں کا بجٹ ہے، جو آپ کے معاملے میں استعمال نہیں ہوتا ہے۔
ہم اس کے ساتھ کیا کریں. ہم اسے لفظی ہر چیز کے لیے استعمال کرتے ہیں۔ پیداواری حالات میں جانچ کے لیے، نئی خصوصیات کو رول آؤٹ کرنے کے لیے جو کارکردگی کو متاثر کر سکتی ہیں، ریلیز کے لیے، دیکھ بھال کے لیے، منصوبہ بند ڈاؤن ٹائمز کے لیے۔ الٹا اصول بھی لاگو ہوتا ہے: اگر بجٹ ختم ہو جائے تو ہم کوئی نئی چیز جاری نہیں کر سکتے، کیونکہ بصورت دیگر ہم SLO سے تجاوز کر جائیں گے۔ بجٹ پہلے ہی ختم ہو چکا ہے، ہم نے کچھ جاری کیا ہے اگر اس سے کارکردگی پر منفی اثر پڑتا ہے، یعنی اگر یہ کسی قسم کا ٹھیک نہیں ہے جو خود براہ راست SLO میں اضافہ کرتا ہے، تو ہم بجٹ سے آگے جا رہے ہیں، اور یہ ایک بری صورتحال ہے۔ ، اس کا تجزیہ کرنے، پوسٹ مارٹم، اور ممکنہ طور پر کچھ پراسیس فکس کرنے کی ضرورت ہے۔
یعنی، یہ پتہ چلتا ہے کہ اگر سروس خود اچھی طرح سے کام نہیں کرتی ہے، اور SLO خرچ کیا جاتا ہے اور بجٹ تجربات پر نہیں، کچھ ریلیز پر نہیں، بلکہ خود سے خرچ کیا جاتا ہے، تو پھر کچھ دلچسپ اصلاحات کے بجائے، دلچسپ خصوصیات کے بجائے، دلچسپ ریلیز کے بجائے۔ کسی بھی تخلیقی کام کے بجائے، آپ کو بجٹ کو دوبارہ ترتیب دینے کے لیے احمقانہ اصلاحات سے نمٹنا پڑے گا، یا SLO میں ترمیم کرنا پڑے گی، اور یہ ایک ایسا عمل بھی ہے جو اکثر نہیں ہونا چاہیے۔
لہذا، یہ پتہ چلتا ہے کہ ایسی صورت حال میں جہاں ہمارے پاس غلطیوں کے لئے زیادہ بجٹ ہے، ہر کوئی دلچسپی رکھتا ہے: SRE اور ڈویلپرز دونوں. ڈویلپرز کے لیے، کیڑے کے لیے بڑے بجٹ کا مطلب ہے کہ آپ ریلیز، ٹیسٹ، تجربات سے نمٹ سکتے ہیں۔ SREs کے لیے، غلطیوں کے لیے بجٹ اور اس بجٹ میں داخل ہونے کا مطلب ہے کہ وہ براہ راست اپنا کام اچھی طرح کر رہے ہیں۔ اور یہ کسی قسم کے مشترکہ کام کی ترغیب کو متاثر کرتا ہے۔ اگر آپ ڈویلپرز کے طور پر اپنے SREs کو سنتے ہیں، تو آپ کے پاس اچھے کام کے لیے زیادہ جگہ اور بہت کم معمولات ہوں گے۔
یہ پتہ چلتا ہے کہ پیداوار میں تجربات بڑی ٹیموں میں SRE کا کافی اہم اور تقریباً لازمی حصہ ہیں۔ اور اسے عام طور پر افراتفری انجینئرنگ کہا جاتا ہے، جو Netflix کی ٹیم سے آتا ہے جس نے Chaos Monkey نامی ایک افادیت جاری کی۔
Chaos Monkey CI/CD پائپ لائن سے جڑتا ہے اور سرور کو تصادفی طور پر پیداوار میں کریش کرتا ہے۔ ایک بار پھر، SRE ڈھانچے میں، ہم اس حقیقت کے بارے میں بات کر رہے ہیں کہ ایک ڈاؤن شدہ سرور اپنے آپ میں برا نہیں ہے، اس کی توقع کی جاتی ہے۔ اور اگر یہ بجٹ کے اندر ہے تو قابل قبول ہے اور کاروبار کو نقصان نہیں پہنچاتا۔ بلاشبہ، Netflix کے پاس کافی بے کار سرورز ہیں، کافی نقل ہے، تاکہ یہ سب ٹھیک کیا جا سکے، اور تاکہ صارف کو مجموعی طور پر نوٹس بھی نہ ہو، اور اس سے بھی بڑھ کر کوئی بھی بجٹ کے لیے ایک سرور کو نہیں چھوڑتا ہے۔
Netflix کے پاس تھوڑی دیر کے لیے اس طرح کی افادیت کا ایک پورا مجموعہ تھا، جن میں سے ایک، Chaos Gorilla، Amazon کے Availability Zone میں سے ایک کو مکمل طور پر بند کر دیتا ہے۔ اور اس طرح کی چیزیں ظاہر کرنے میں مدد کرتی ہیں، سب سے پہلے، پوشیدہ انحصار، جب یہ مکمل طور پر واضح نہیں ہے کہ کس چیز پر کیا اثر پڑتا ہے، کس چیز پر منحصر ہے۔ اور یہ، اگر آپ مائیکرو سروس کے ساتھ کام کر رہے ہیں، اور دستاویزات بالکل پرفیکٹ نہیں ہیں، تو یہ آپ کو معلوم ہو سکتا ہے۔ اور ایک بار پھر، اس سے کوڈ میں ایسی غلطیوں کو پکڑنے میں بہت مدد ملتی ہے جسے آپ سٹیجنگ پر نہیں پکڑ سکتے، کیونکہ کوئی بھی سٹیجنگ بالکل درست نقلی نہیں ہے، اس حقیقت کی وجہ سے کہ بوجھ کا پیمانہ مختلف ہے، لوڈ پیٹرن مختلف ہے، سامان ہے۔ بھی، زیادہ تر امکان، دیگر. چوٹی کا بوجھ غیر متوقع اور غیر متوقع بھی ہو سکتا ہے۔ اور اس طرح کی جانچ، جو پھر سے بجٹ سے باہر نہیں جاتی ہے، بنیادی ڈھانچے میں غلطیوں کو پکڑنے میں بہت اچھی طرح سے مدد کرتی ہے جو اسٹیجنگ، آٹو ٹیسٹ، CI/CD پائپ لائن کبھی نہیں پکڑے گی۔ اور جب تک یہ سب آپ کے بجٹ میں شامل ہے، اس سے کوئی فرق نہیں پڑتا کہ آپ کی سروس وہاں چلی گئی، حالانکہ یہ بہت خوفناک لگتا ہے، سرور ڈاون ہو گیا، یہ کتنا برا خواب ہے۔ نہیں، یہ عام بات ہے، یہ اچھی بات ہے، اس سے کیڑے پکڑنے میں مدد ملتی ہے۔ اگر آپ کے پاس بجٹ ہے، تو آپ اسے خرچ کر سکتے ہیں۔
سوال: میں کون سا ادب تجویز کر سکتا ہوں؟ فہرست آخر میں۔ بہت ادب ہے، چند رپورٹوں کا مشورہ دوں گا۔ یہ کیسے کام کرتا ہے، اور SRE کمپنیوں میں ان کے اپنے سافٹ ویئر پروڈکٹ کے بغیر یا کم سے کم ترقی کے ساتھ کام کرتا ہے۔ مثال کے طور پر، ایک انٹرپرائز میں جہاں اہم سرگرمی سافٹ ویئر نہیں ہے۔ ایک انٹرپرائز میں، جہاں اہم سرگرمی سافٹ ویئر نہیں ہے، SRE بالکل اسی طرح کام کرتا ہے جیسا کہ ہر جگہ، کیونکہ ایک انٹرپرائز میں آپ کو بھی استعمال کرنے کی ضرورت ہوتی ہے، چاہے تیار نہ ہو، سافٹ ویئر پروڈکٹس، آپ کو اپ ڈیٹس رول آؤٹ کرنے کی ضرورت ہے، آپ کو تبدیل کرنے کی ضرورت ہے۔ بنیادی ڈھانچہ، آپ کو بڑھنے کی ضرورت ہے، آپ کو پیمانے کی ضرورت ہے۔ اور SREs ان عملوں میں ممکنہ مسائل کی شناخت اور پیشین گوئی کرنے میں مدد کرتے ہیں اور کچھ ترقی شروع ہونے اور کاروبار کی ضروریات میں تبدیلی کے بعد انہیں کنٹرول کرتے ہیں۔ کیونکہ اگر آپ کے پاس کم از کم چند سرور ہیں اور آپ کو کم از کم کچھ ترقی کی توقع ہے تو SRE حاصل کرنے کے لیے سافٹ ویئر ڈویلپمنٹ میں شامل ہونا بالکل ضروری نہیں ہے۔
چھوٹے منصوبوں، چھوٹی تنظیموں کے لیے بھی ایسا ہی ہوتا ہے، کیونکہ بڑی کمپنیوں کے پاس بجٹ اور تجربہ کرنے کی جگہ ہوتی ہے۔ لیکن ساتھ ہی، تجربات کے یہ تمام ثمرات کہیں بھی استعمال کیے جاسکتے ہیں، یعنی SRE، یقیناً گوگل میں، نیٹ فلکس میں، ڈراپ باکس میں ظاہر ہوا۔ لیکن ایک ہی وقت میں، چھوٹی کمپنیاں اور اسٹارٹ اپ پہلے سے ہی گاڑھا مواد پڑھ سکتے ہیں، کتابیں پڑھ سکتے ہیں، رپورٹیں دیکھ سکتے ہیں۔ وہ اس کے بارے میں زیادہ کثرت سے سننا شروع کرتے ہیں، وہ مخصوص مثالوں کو دیکھتے ہیں، مجھے لگتا ہے کہ یہ ٹھیک ہے، یہ واقعی مفید ہو سکتا ہے، ہمیں بھی اس کی ضرورت ہے، یہ بہت اچھا ہے۔
یعنی ان عملوں کو معیاری بنانے کا تمام اہم کام آپ کے لیے پہلے ہی کیا جا چکا ہے۔ یہ آپ کے لیے باقی ہے کہ آپ اپنی کمپنی میں خاص طور پر SRE کے کردار کا تعین کریں اور ان تمام طریقوں کو عملی جامہ پہنانا شروع کریں، جن کی وضاحت پہلے ہی کی جا چکی ہے۔ یعنی چھوٹی کمپنیوں کے لیے مفید اصولوں سے، یہ ہمیشہ SLA، SLI، SLO کی تعریف ہوتی ہے۔ اگر آپ سافٹ ویئر میں شامل نہیں ہیں، تو یہ اندرونی SLAs اور اندرونی SLOs ہوں گے، غلطیوں کے لیے ایک اندرونی بجٹ۔ یہ تقریبا ہمیشہ ٹیم کے اندر اور کاروبار کے اندر کچھ دلچسپ بات چیت کا باعث بنتا ہے، کیونکہ یہ ہو سکتا ہے کہ آپ انفراسٹرکچر پر خرچ کرتے ہیں، مثالی عمل کی کسی قسم کی تنظیم پر، مثالی پائپ لائن ضرورت سے کہیں زیادہ ہے۔ اور یہ 4 نائنز جو آپ کے آئی ٹی ڈیپارٹمنٹ میں ہیں، اب آپ کو واقعی ان کی ضرورت نہیں ہے۔ لیکن ایک ہی وقت میں، آپ وقت گزار سکتے ہیں، کسی اور چیز پر غلطیوں کے لیے بجٹ خرچ کر سکتے ہیں۔
اس کے مطابق، نگرانی اور نگرانی کی تنظیم کسی بھی سائز کی کمپنی کے لئے مفید ہے. اور عمومی طور پر سوچنے کا یہ طریقہ، جہاں غلطیاں قابل قبول ہیں، جہاں بجٹ ہے، جہاں مقاصد ہیں، یہ کسی بھی سائز کی کمپنی کے لیے ایک بار پھر کارآمد ہے، 3 لوگوں کے لیے اسٹارٹ اپ سے شروع۔
بات کرنے کے لیے تکنیکی باریکیوں میں سے آخری مانیٹرنگ ہے۔ کیونکہ اگر ہم SLA، SLI، SLO کے بارے میں بات کر رہے ہیں، تو ہم اس بات کی نگرانی کیے بغیر نہیں سمجھ سکتے کہ آیا ہم بجٹ میں فٹ ہوتے ہیں، آیا ہم اپنے مقاصد کی تعمیل کرتے ہیں، اور ہم حتمی SLA کو کیسے متاثر کرتے ہیں۔ میں نے کئی بار دیکھا ہے کہ نگرانی اس طرح ہوتی ہے: کچھ قدر ہوتی ہے، مثال کے طور پر، سرور سے درخواست کا وقت، اوسط وقت، یا ڈیٹا بیس کی درخواستوں کی تعداد۔ اس کے پاس ایک انجینئر کے ذریعہ طے شدہ معیار ہے۔ اگر میٹرک معمول سے ہٹ جاتا ہے، تو ایک ای میل آتا ہے۔ یہ سب کچھ بالکل بیکار ہے، ایک اصول کے طور پر، کیونکہ اس سے انتباہات کی بہتات، نگرانی کے پیغامات کی بھرمار ہوتی ہے، جب ایک شخص کو، سب سے پہلے، ہر بار ان کی تشریح کرنی چاہیے، یعنی یہ طے کرنا چاہیے کہ میٹرک کی قدر کا مطلب ہے یا نہیں۔ کچھ کارروائی کی ضرورت ہے. اور دوسری بات، وہ صرف ان تمام انتباہات کو دیکھنا چھوڑ دیتا ہے، جب کہ بنیادی طور پر اس سے کسی کارروائی کی ضرورت نہیں ہوتی ہے۔ یہ نگرانی کا ایک اچھا اصول ہے اور جب SRE لاگو ہوتا ہے تو پہلا اصول یہ ہے کہ اطلاع صرف اس وقت آنی چاہیے جب کارروائی کی ضرورت ہو۔
معیاری صورت میں، واقعات کی 3 سطحیں ہیں۔ انتباہات ہیں، ٹکٹیں ہیں، نوشتہ جات ہیں۔ انتباہات ایسی کوئی بھی چیز ہوتی ہے جس کے لیے آپ کو فوری کارروائی کرنے کی ضرورت ہوتی ہے۔ یعنی، سب کچھ ٹوٹ گیا ہے، آپ کو اسے ابھی ٹھیک کرنے کی ضرورت ہے۔ ٹکٹ وہ ہیں جن کے لیے تاخیری کارروائی کی ضرورت ہے۔ ہاں، آپ کو کچھ کرنے کی ضرورت ہے، آپ کو دستی طور پر کچھ کرنے کی ضرورت ہے، آٹومیشن ناکام ہو گئی، لیکن آپ کو اگلے چند منٹوں تک ایسا کرنے کی ضرورت نہیں ہے۔ نوشتہ جات وہ چیز ہوتی ہے جس کے لیے کارروائی کی ضرورت نہیں ہوتی ہے، اور عام طور پر، اگر چیزیں ٹھیک چلتی ہیں، تو کوئی بھی انہیں کبھی نہیں پڑھے گا۔ آپ کو نوشتہ جات کو صرف اس وقت پڑھنے کی ضرورت ہوگی جب، ماضی میں، یہ پتہ چلا کہ کچھ وقت کے لیے کچھ ٹوٹ گیا، ہمیں اس کے بارے میں علم نہیں تھا۔ یا آپ کو کچھ تحقیق کرنے کی ضرورت ہے؟ لیکن عام طور پر، ہر وہ چیز جس کے لیے کسی کارروائی کی ضرورت نہیں ہوتی وہ نوشتہ جات میں جاتی ہے۔
اس سب کے ضمنی اثر کے طور پر، اگر ہم نے یہ بیان کیا ہے کہ کن واقعات کے لیے اعمال کی ضرورت ہوتی ہے اور یہ اچھی طرح بیان کیا ہے کہ ان اعمال کو کیا ہونا چاہیے، تو اس کا مطلب ہے کہ عمل خودکار ہو سکتا ہے۔ یعنی جو ہوتا ہے۔ ہم الرٹ سے جاتے ہیں۔ آئیے ایکشن کی طرف چلتے ہیں۔ ہم اس کارروائی کی تفصیل پر جاتے ہیں۔ اور پھر ہم آٹومیشن کی طرف بڑھتے ہیں۔ یعنی کوئی بھی آٹومیشن کسی واقعہ کے ردعمل سے شروع ہوتی ہے۔
نگرانی سے، ہم مشاہدے کی اصطلاح کی طرف بڑھتے ہیں۔ پچھلے کچھ سالوں سے اس لفظ کے ارد گرد تھوڑا سا ہائپ بھی ہے۔ اور بہت کم لوگ سمجھتے ہیں کہ سیاق و سباق سے ہٹ کر اس کا کیا مطلب ہے۔ لیکن اہم نکتہ یہ ہے کہ مشاہداتی نظام کی شفافیت کا ایک میٹرک ہے۔ اگر کچھ غلط ہو گیا ہے، تو آپ کتنی جلدی اس بات کا تعین کر سکتے ہیں کہ اصل میں کیا غلط ہوا اور اس وقت سسٹم کی حالت کیا تھی۔ کوڈ کے لحاظ سے: کون سا فنکشن ناکام ہوا، کون سی سروس ناکام ہوگئی۔ کیا حالت تھی، مثال کے طور پر، اندرونی متغیرات، ترتیب۔ انفراسٹرکچر کے لحاظ سے، یہ وہ ہے جس میں دستیابی کے زون میں ناکامی واقع ہوئی ہے، اور اگر آپ کے پاس کوئی Kubernetes انسٹال ہے، تو پھر کس پوڈ میں ناکامی ہوئی، پوڈ کی حالت کیا تھی۔ اور اس کے مطابق، مشاہدے کا MTTR کے ساتھ براہ راست تعلق ہے۔ سروس کی آبزرویبلٹی جتنی زیادہ ہوگی، غلطی کی نشاندہی کرنا اتنا ہی آسان ہوگا، غلطی کو ٹھیک کرنا اتنا ہی آسان ہوگا، غلطی کو خودکار کرنا اتنا ہی آسان ہوگا، ایم ٹی ٹی آر اتنا ہی کم ہوگا۔
دوبارہ چھوٹی کمپنیوں کی طرف بڑھتے ہوئے، یہ پوچھنا بہت عام ہے، اب بھی، ٹیم کے سائز سے کیسے نمٹا جائے، اور کیا چھوٹی ٹیم کو علیحدہ SRE کی خدمات حاصل کرنے کی ضرورت ہے۔ اس کے بارے میں کچھ دیر پہلے بات کی ہے۔ ایک سٹارٹ اپ یا مثال کے طور پر ایک ٹیم کی ترقی کے پہلے مراحل میں، یہ بالکل ضروری نہیں ہے، کیونکہ SRE کو ایک عبوری کردار بنایا جا سکتا ہے۔ اور یہ ٹیم کو تھوڑا سا زندہ کرے گا، کیونکہ کم از کم کچھ تنوع ہے۔ اور اس کے علاوہ یہ لوگوں کو اس حقیقت کے لیے تیار کرے گا کہ ترقی کے ساتھ، عمومی طور پر، SRE کی ذمہ داریاں بہت نمایاں طور پر تبدیل ہو جائیں گی۔ اگر آپ کسی شخص کی خدمات حاصل کرتے ہیں، تو یقیناً اس کی کچھ توقعات ہیں۔ اور یہ توقعات وقت کے ساتھ نہیں بدلیں گی بلکہ تقاضے بہت بدل جائیں گے۔ لہذا، ابتدائی مراحل میں SRE کی خدمات حاصل کرنے کا طریقہ کافی مشکل ہے۔ خود کو بڑھانا بہت آسان ہے۔ لیکن یہ سوچنے کے قابل ہے۔
واحد استثناء، شاید، وہ ہے جب ترقی کے بہت سخت اور اچھی طرح سے متعین تقاضے ہوں۔ یعنی، سٹارٹ اپ کی صورت میں، یہ سرمایہ کاروں کی طرف سے کسی قسم کا دباؤ، ایک ساتھ کئی بار ترقی کی کسی قسم کی پیشن گوئی ہو سکتی ہے۔ پھر ایک SRE کی خدمات حاصل کرنا بنیادی طور پر جائز ہے کیونکہ اسے جائز قرار دیا جا سکتا ہے۔ ہمارے پاس ترقی کے تقاضے ہیں، ہمیں ایک ایسے شخص کی ضرورت ہے جو اس حقیقت کا ذمہ دار ہو کہ اتنی ترقی سے کچھ نہیں ٹوٹے گا۔
ایک اور سوال. کیا کرنا ہے جب کئی بار ڈویلپرز کسی ایسی خصوصیت کو کاٹتے ہیں جو ٹیسٹ پاس کرتی ہے، لیکن پروڈکشن کو توڑ دیتی ہے، بیس کو لوڈ کرتی ہے، دیگر خصوصیات کو توڑ دیتی ہے، کس عمل کو لاگو کرنا ہے۔ اس کے مطابق، اس معاملے میں، یہ غلطیوں کے لئے بجٹ ہے جو متعارف کرایا جاتا ہے. اور کچھ خدمات، کچھ فیچرز پہلے ہی پروڈکشن میں ٹیسٹ کیے جا رہے ہیں۔ یہ کینری ہوسکتا ہے، جب صارفین کی صرف ایک چھوٹی سی تعداد، لیکن پہلے سے ہی پیداوار میں، ایک خصوصیت تعینات ہے، لیکن پہلے ہی اس توقع کے ساتھ کہ اگر کچھ ٹوٹ جاتا ہے، مثال کے طور پر، تمام صارفین کے نصف فیصد کے لیے، یہ اب بھی پورا کرے گا۔ غلطیوں کے لیے بجٹ اس کے مطابق، ہاں، ایک خرابی ہوگی، کچھ صارفین کے لیے سب کچھ ٹوٹ جائے گا، لیکن ہم پہلے ہی کہہ چکے ہیں کہ یہ معمول ہے۔
SRE ٹولز کے بارے میں ایک سوال تھا۔ یعنی، کیا خاص طور پر کوئی ایسی چیز ہے جسے SRE استعمال کریں گے جو باقی سب نہیں کریں گے۔ درحقیقت، کچھ انتہائی مخصوص یوٹیلٹیز ہیں، کچھ ایسے سافٹ ویئر ہیں جو، مثال کے طور پر، بوجھ کی نقل کرتے ہیں یا کینری A/B ٹیسٹنگ میں مصروف ہیں۔ لیکن بنیادی طور پر SRE ٹول کٹ وہی ہے جسے آپ کے ڈویلپر پہلے سے استعمال کر رہے ہیں۔ کیونکہ SRE براہ راست ترقیاتی ٹیم کے ساتھ بات چیت کرتا ہے۔ اور اگر آپ کے پاس مختلف ٹولز ہیں، تو یہ پتہ چلے گا کہ مطابقت پذیر ہونے میں وقت لگتا ہے۔ خاص طور پر اگر SREs بڑی ٹیموں میں کام کرتے ہیں، بڑی کمپنیوں میں جہاں کئی ٹیمیں ہو سکتی ہیں، یہ کمپنی کی سطح پر معیاری کاری ہے جو یہاں بہت مدد کرے گی، کیونکہ اگر 50 ٹیموں میں 50 مختلف یوٹیلٹیز استعمال کی جاتی ہیں، تو اس کا مطلب ہے کہ SRE کو ان کا علم ہونا چاہیے۔ تمام اور یقیناً ایسا کبھی نہیں ہوگا۔ اور کام کا معیار، کم از کم کچھ ٹیموں کے کنٹرول کے معیار میں نمایاں کمی آئے گی۔
ہمارا ویبنار اختتام کو پہنچ رہا ہے۔ میں کچھ بنیادی باتیں بتانے میں کامیاب ہوگیا۔ بلاشبہ، SRE کے بارے میں ایک گھنٹے میں کچھ نہیں بتایا اور سمجھا جا سکتا ہے۔ لیکن میں امید کرتا ہوں کہ میں نے سوچنے کے اس طریقے، اہم کلیدی نکات کو پہنچانے میں کامیاب ہو گیا ہوں۔ اور پھر یہ ممکن ہو گا، اگر دلچسپی ہو، تو اس موضوع کو تلاش کرنا، خود سیکھنا، یہ دیکھنا کہ اسے دوسرے لوگ، دوسری کمپنیوں میں کیسے نافذ کر رہے ہیں۔ اور اس کے مطابق، فروری کے شروع میں، Slurm SRE میں ہمارے پاس آئیں۔
Slurm SRE ایک تین روزہ گہرا کورس ہے جو اس کے بارے میں بات کرے گا جس کے بارے میں میں اب بات کر رہا ہوں، لیکن بہت زیادہ گہرائی کے ساتھ، حقیقی معاملات کے ساتھ، پریکٹس کے ساتھ، پوری شدت کا مقصد عملی کام ہے۔ لوگ ٹیموں میں تقسیم ہو جائیں گے۔ آپ سب حقیقی مقدمات پر کام کریں گے۔ اسی مناسبت سے، ہمارے پاس Booking.com کے انسٹرکٹر Ivan Kruglov اور Ben Tyler ہیں۔ ہمارے پاس سان فرانسسکو سے گوگل کی طرف سے ایک شاندار یوجین باراباس ہے۔ اور میں آپ کو بھی کچھ بتاؤں گا۔ تو ہماری وزٹ ضرور کریں۔
تو، کتابیات. SRE پر حوالہ جات موجود ہیں۔ اسی کتاب پر، یا SRE کے بارے میں 2 کتابوں پر، جو گوگل نے لکھی ہے۔ ایک دوسرا ، جہاں شرائط اور ان کا اطلاق قدرے تفصیلی ہے۔ اگلے 3 مختلف کمپنیوں میں SRE پر رپورٹس ہیں۔ پہلا - یہ گوگل کے بین ٹرینر کا کلیدی نوٹ ہے۔ دوسرا - . تیسرا پھر ہے۔ . سے چوتھی رپورٹ جس کے 5 ممالک میں صرف 190 اہم SRE ملازمین ہیں۔ اس سب کو دیکھنا بہت دلچسپ ہے، کیونکہ جس طرح DevOps کا مطلب مختلف کمپنیوں اور یہاں تک کہ مختلف ٹیموں کے لیے بہت مختلف چیزیں ہیں، اسی طرح SRE کی بہت مختلف ذمہ داریاں ہیں، یہاں تک کہ ایک جیسے سائز کی کمپنیوں میں بھی۔
افراتفری انجینئرنگ کے اصولوں پر 2 مزید لنکس: , . اور آخر میں سیریز کی 3 فہرستیں ہیں Awesome Lists کے بارے میں کے بارے میں اور کے بارے میں . SRE پر فہرست ناقابل یقین حد تک بہت بڑی ہے، یہ سب کچھ جانا ضروری نہیں ہے، تقریباً 200 مضامین ہیں۔ میں صلاحیت کی منصوبہ بندی اور بے قصور پوسٹ مارٹم کے بارے میں وہاں سے مضامین کی انتہائی سفارش کرتا ہوں۔
دلچسپ مضمون:
اس وقت میری بات سننے کے لیے آپ کا شکریہ۔ امید ہے آپ نے کچھ سیکھا ہوگا۔ امید ہے کہ آپ کے پاس مزید جاننے کے لیے کافی مواد موجود ہے۔ اور ملتے ہیں۔ امید ہے فروری میں۔
ویبینار کی میزبانی ایڈورڈ میدویدیف نے کی۔
PS: ان لوگوں کے لیے جو پڑھنا پسند کرتے ہیں، ایڈورڈ نے حوالہ جات کی ایک فہرست دی۔ جو لوگ عملی طور پر سمجھنے کو ترجیح دیتے ہیں ان کا استقبال ہے۔ .
ماخذ: www.habr.com