ہماری ٹیم تجربات سے محبت کرتی ہے۔ ہر سلرم پچھلے لوگوں کی ایک مستحکم تکرار نہیں ہے، بلکہ تجربے کی عکاسی اور اچھے سے بہتر کی طرف منتقلی ہے۔ لیکن ساتھ ہم نے ایک بالکل نیا فارمیٹ لاگو کرنے کا فیصلہ کیا - تاکہ شرکاء کو "مقابلہ" کے لیے ممکنہ حد تک قریب کی شرائط فراہم کی جاسکیں۔
اگر ہم مختصر طور پر اس بات کا خاکہ پیش کرتے ہیں کہ ہم نے گہرے کورس کے دوران کیا کیا: "ہم بناتے ہیں، ہم توڑتے ہیں، ہم مرمت کرتے ہیں،
ہم پڑھ رہے ہیں." SRE محض تھیوری میں بہت کم ہے - صرف مشق، حقیقی حل، حقیقی مسائل۔
شرکاء کو ٹیموں میں تقسیم کیا گیا تھا تاکہ ایک زبردست مسابقتی جذبہ کسی کو سونے یا آئی فون پر "اینگری برڈز" لانچ کرنے کی اجازت نہ دے، دیمتری اناتولیوچ کی مثال کے مطابق۔
چار سرپرستوں کے ذریعے شرکاء کو مسائل، خرابیاں، کیڑے اور کام فراہم کیے گئے۔ Ivan Kruglov، Booking.com (نیدرلینڈز) کے پرنسپل ڈویلپر۔ بین ٹائلر، Booking.com (USA) میں پرنسپل ڈویلپر۔ ایڈورڈ میدویدیف، ٹنگسٹن لیبز (جرمنی) میں سی ٹی او۔ Evgeniy Varavva، Google (San Francisco) کے جنرل ڈویلپر۔
اس کے علاوہ، شرکاء ٹیموں میں تقسیم ہوتے ہیں اور ایک دوسرے کے ساتھ مقابلہ کرتے ہیں. دلچسپ؟
Ivan, Ben, Eduard اور Evgeniy مقابلہ شروع ہونے سے پہلے Slurm SRE کے غریب شرکا کو نرم لیننسٹ اسکوئنٹس کے ساتھ دیکھتے ہیں۔
تو کام:
ہم اپنے ہیں نئی دنیا بنائیں گے...
ایک مووی ٹکٹ ایگریگیٹر ویب سائٹ ہے۔ واقعات پہلے سے کام کرنے والے منظر نامے میں سرپرستوں کے ذریعہ ایجاد کیے جاتے ہیں (اگرچہ کوئی بھی خاص طور پر نفیس اور کپٹی اصلاح کو خارج نہیں کرتا ہے)، سائٹ کی کارکردگی کو مختلف میٹرکس کے ذریعہ بیان کیا جاتا ہے۔ مسائل بہت مختلف ہو سکتے ہیں: Moulin Rouge تھیٹر کے ٹکٹ ڈیٹا بیس میں لوڈ نہیں ہوتے ہیں۔ فلموں اور پرفارمنس کے پوسٹرز ڈیٹا بیس میں 10 سیکنڈ سے زیادہ میں لوڈ ہو جاتے ہیں۔ ایک انفرادی فلم کی تفصیل جم جاتی ہے۔ 0,1% آرڈرز پہلے ہی محفوظ ہیں۔ وقتاً فوقتاً ادائیگی کی کارروائی کا نظام ایک یا دو منٹ کے لیے کریش ہو جاتا ہے۔ اور بہت سی، بہت سی، بہت سی ناخوشگوار چیزیں جو Slurm SRE کے شریک کو اس کے حقیقی کام پر پڑ سکتی ہیں۔
ہم کسی بھی چیز کو سنبھالنے کے لیے تیار ہیں۔
ہماری دیرینہ ویب سائٹ کئی مائیکرو سروسز پر مشتمل ہے۔ اس کا کام تمام سینما گھروں سے شوز، قیمتوں اور دستیاب سیٹوں کے ڈیٹا کو جمع کرنا ہے؛ یہ فلم کے اعلانات دکھاتا ہے، آپ کو سینما، شو، ہال اور جگہ کا انتخاب کرنے، ٹکٹ بک کرنے اور ادائیگی کرنے کی اجازت دیتا ہے۔ عام طور پر، ہر وہ چیز جس کا دیکھنے والا صرف خواب دیکھ سکتا ہے۔ لیکن صارف کو اس بات پر بھی شبہ نہیں ہوتا کہ سائٹ کے استحکام اور رسائی کے لیے کیا ٹائٹینک جدوجہد اندر سے جاری ہے۔
گہری سائٹ کے لیے، ہم نے ایس ایل او، ایس ایل آئی، ایس ایل اے اشارے تیار کیے، فن تعمیر اور بنیادی ڈھانچہ تیار کیا، سائٹ کو متعین کیا، نگرانی اور انتباہ قائم کیا۔ اور ہم چلے جاتے ہیں۔
ایس ایل او، ایس ایل آئی، ایس ایل اے
SLI - خدمت کی سطح کے اشارے۔ SLOs خدمت کی سطح کے اہداف ہیں۔ SLA - سروس کی سطح کے معاہدے۔
SLA ایک ITIL طریقہ کار کی اصطلاح ہے جو کسی سروس کے صارف اور اس کے فراہم کنندہ کے درمیان ایک رسمی معاہدے کی نشاندہی کرتی ہے، جس میں سروس کی تفصیل، فریقین کے حقوق اور ذمہ داریاں اور سب سے اہم بات یہ ہے کہ اس کی فراہمی کے لیے معیار کی متفقہ سطح ہوتی ہے۔ سروس
ایس ایل او سروس لیول کا مقصد ہے: سروس لیول کے لیے ٹارگٹ ویلیو یا اقدار کی رینج جس کی پیمائش SLI کے ذریعے کی جاتی ہے۔ SLO کے لیے ایک عام قدر "SLI ≤ ہدف" یا "نچلی حد ≤ SLI ≤ اوپری حد" ہے۔
SLI ایک سروس لیول انڈیکیٹر ہے — فراہم کردہ سروس کی سطح کے ایک پہلو کا احتیاط سے بیان کردہ مقداری پیمانہ۔ زیادہ تر خدمات کے لیے، کلیدی SLI کو درخواست میں تاخیر سمجھا جاتا ہے - درخواست کا جواب واپس کرنے میں کتنا وقت لگتا ہے۔ دیگر عام SLIs میں غلطی کی شرح، اکثر موصول ہونے والی تمام درخواستوں کے ایک حصے کے طور پر ظاہر کی جاتی ہے، اور سسٹم تھرو پٹ، عام طور پر فی سیکنڈ درخواستوں میں ماپا جاتا ہے۔
سب سے پہلے، ہم طیاروں کو توڑ دیں گے، پھر لڑکیاں، اور پھر لڑکیاں...
اندرونی اور بیرونی عوامل نے پہلے ہی منٹوں سے SLO کو "خراب" کرنا شروع کر دیا۔ سب کچھ منتظمین کے سروں پر پڑا — ڈویلپر کی غلطیاں، بنیادی ڈھانچے کی ناکامیاں، زائرین کی آمد، اور DDoS حملے۔ ہر وہ چیز جو SLO کو خراب کرتی ہے۔
"- پیارے شرکاء، میں آپ کو خوش کرنے میں جلدی کرتا ہوں، پہلی چیز جس میں آپ ناکام ہوتے ہیں وہ ہے... سب کچھ!"
راستے میں، مقررین نے استحکام، خرابی کے بجٹ، ٹیسٹنگ پریکٹس، رکاوٹوں کے انتظام اور آپریشنل بوجھ پر تبادلہ خیال کیا۔
ہم ٹھیلے والے نہیں، بڑھئی نہیں...
پھر شرکاء نے چیزوں کو ٹھیک کرنا شروع کر دیا - اہم بات یہ سمجھنا ہے کہ پہلے کیا پکڑنا ہے۔
"- خداوند، میں نے اسے کبھی اس طرح، اس شکل میں اور ایسی حالت میں ٹوٹتے نہیں دیکھا!"
چنانچہ ایک حادثہ پیش آیا۔ ادائیگی کی پروسیسنگ سروس بند ہے۔ کم سے کم وقت میں فعالیت کو بحال کرنے کے لیے کیسے عمل کیا جائے؟
ماہرین، شرکاء کو پیار سے دیکھتے ہوئے، ایک اور چال تیار کر رہے ہیں۔
ہر ٹیم حادثے کو ختم کرنے کے لیے گروپ کے کام کو منظم کرتی ہے - اس میں ساتھی شامل ہوتے ہیں، دلچسپی رکھنے والی جماعتوں (اسٹیک ہولڈرز) کو مطلع کرتے ہیں۔ اس کے ساتھ ساتھ ترجیحات کا تعین کیا جاتا ہے۔ اس طرح، شرکاء نے انتہائی محدود وقت کے حالات میں دباؤ میں کام کرنے کی تربیت دی۔
"کیسی وحشت نکلی ہے؟!"
سانس چھوڑیں... اور ورزش ختم کریں۔
مقررین کے ساتھ مل کر، ہر مسئلہ کے حل ہونے اور سائٹ کو عارضی طور پر مستحکم کرنے کے بعد، ٹیم نے واقعات کا SRE نقطہ نظر سے مطالعہ کیا۔ ہم نے تفصیل سے مسائل کا تجزیہ کیا - وقوع پذیر ہونے کی وجوہات، خاتمے کی پیش رفت۔ اس کے بعد، ٹیم بہ ٹیم اور اجتماعی طور پر، ہم نے فیصلے کیے کہ انہیں مزید کیسے روکا جائے: نگرانی کو کیسے بہتر بنایا جائے، فن تعمیر کو دانشمندی سے کیسے بدلا جائے، ترقی اور آپریشن کے طریقہ کار کو کیسے ایڈجسٹ کیا جائے، ضابطوں کو کیسے درست کیا جائے۔ مقررین نے پوسٹ مارٹم کرانے کی مشق کا مظاہرہ کیا۔
"اور کون عذاب چاہتا ہے! - میں!"
ٹیموں کی کامیابیوں کو الیکٹرانک سکور بورڈ پر سختی سے اور واضح طور پر درج کیا گیا تھا۔
پہلی جگہوں کے لیے - اسٹیک ہولڈرز سے بونس۔
ماخذ: www.habr.com