ایک رول آؤٹ کہانی جس نے ہر چیز کو متاثر کیا۔

حقیقت کے دشمن 12f-2 کے ذریعے

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

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

پس منظر + یہ کس قسم کی فعالیت ہے؟

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

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

• اوپن اسٹیک اپنے کی اسٹون کی اجازت ماڈیول کے ساتھ،
• Hotbox (S3 اسٹوریج) Mail.ru کلاؤڈ پروجیکٹ پر مبنی،

جس کے ارد گرد پھر نئی خدمات نمودار ہوئیں۔

بنیادی طور پر، یہ اجازت کی دو مختلف قسمیں تھیں۔ اس کے علاوہ، ہم نے کچھ الگ Mail.ru ترقیات کا استعمال کیا، مثال کے طور پر، ایک عام Mail.ru پاس ورڈ اسٹوریج کے ساتھ ساتھ ایک خود سے لکھا ہوا Openid کنیکٹر، جس کی بدولت Horizon پینل میں SSO (اختتام سے آخر تک اجازت) فراہم کی گئی تھی۔ ورچوئل مشینوں کا (آبائی اوپن اسٹیک UI)۔

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

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

ہم کیا رول آؤٹ کرنے جا رہے ہیں؟

تقریباً 4 ماہ میں ہم نے مندرجہ ذیل چیزیں تیار کیں:

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

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

اس طرح کی تبدیلیوں کو کیسے ختم کیا جائے اور اسے خراب نہ کیا جائے؟ پہلے ہم نے مستقبل میں تھوڑا سا دیکھنے کا فیصلہ کیا۔

رول آؤٹ حکمت عملی

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

ڈگریشن: رول آؤٹ کیا ہے؟

<احتیاط، فلسفہ>

ہر آئی ٹی ماہر آسانی سے جواب دے سکتا ہے کہ رول آؤٹ کیا ہے۔ آپ CI/CD انسٹال کرتے ہیں، اور ہر چیز خود بخود اسٹور پر پہنچ جاتی ہے۔ 🙂

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

اور پوری تصویر کچھ یوں ہے۔ رول آؤٹ چار اہم پہلوؤں پر مشتمل ہے:

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

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

ایکٹ 1..n، رہائی کی تیاری

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

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

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

اس دوران، تکنیکی مدد سے تعلق رکھنے والے لڑکوں نے کنکشن کے طریقوں پر کلائنٹس کے لیے ہدایات لکھنے کے لیے اپنے خود مختار تجربات کیے، جو کہ رول آؤٹ کے بعد تبدیل ہو جانا تھا۔ انہوں نے صارف UX پر کام کیا، ہدایات تیار کیں اور ذاتی مشاورت فراہم کی۔

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

اور تو…

رول آؤٹ سے پہلے حتمی عمل

...یہ رول آؤٹ کرنے کا وقت ہے۔

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

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

1. صارف کے بنیادی ڈھانچے کو متاثر کریں (ہمارے لیے مقدس، سب سے قیمتی)،
2. فعالیت: رول آؤٹ کے بعد ہماری سروس کا استعمال پہلے جیسا ہی ہونا چاہیے۔

رول آؤٹ کرنا

دو رول، 8 مداخلت نہیں کرتے

ہم صارفین کی تمام درخواستوں کے لیے 7 گھنٹے کے لیے ڈاؤن ٹائم لیتے ہیں۔ اس وقت، ہمارے پاس رول آؤٹ پلان اور رول بیک پلان دونوں ہیں۔

• رول آؤٹ میں ہی تقریباً 3 گھنٹے لگتے ہیں۔
• جانچ کے لیے 2 گھنٹے۔
• 2 گھنٹے - تبدیلیوں کے ممکنہ رول بیک کے لیے ریزرو۔

ہر عمل کے لیے ایک گینٹ چارٹ تیار کیا گیا ہے، اس میں کتنا وقت لگتا ہے، ترتیب وار کیا ہوتا ہے، متوازی طور پر کیا کیا جاتا ہے۔

رول آؤٹ گینٹ چارٹ کا ایک ٹکڑا، ابتدائی ورژن میں سے ایک (متوازی عمل کے بغیر)۔ ہم وقت سازی کا سب سے قیمتی ٹول

تمام شرکاء کا رول آؤٹ میں ان کے کردار کا تعین ہوتا ہے، وہ کون سے کام کرتے ہیں، اور وہ کس چیز کے ذمہ دار ہیں۔ ہم ہر مرحلے کو خود کار طریقے سے لانے کی کوشش کرتے ہیں، اسے رول آؤٹ کرتے ہیں، اسے واپس رول کرتے ہیں، تاثرات جمع کرتے ہیں اور اسے دوبارہ رول آؤٹ کرتے ہیں۔

واقعات کی تاریخ۔

چنانچہ 15 لوگ 29 اپریل بروز اتوار رات 10 بجے کام پر آئے۔ اہم شرکاء کے علاوہ، کچھ صرف ٹیم کو سپورٹ کرنے کے لیے آئے، جس کے لیے ان کا خصوصی شکریہ۔

یہ بات بھی قابل ذکر ہے کہ ہمارا کلیدی ٹیسٹر چھٹی پر ہے۔ بغیر جانچ کے رول آؤٹ کرنا ناممکن ہے، ہم آپشنز تلاش کر رہے ہیں۔ ایک ساتھی چھٹی سے ہمیں ٹیسٹ کرنے پر راضی ہے، جس کے لیے وہ پوری ٹیم کی جانب سے بے حد مشکور ہیں۔

00:00 رک جاؤ
ہم صارف کی درخواستوں کو روکتے ہیں، تکنیکی کام کے طور پر ایک نشان لٹکا دیتے ہیں۔ نگرانی چیخ رہی ہے، لیکن سب کچھ نارمل ہے۔ ہم چیک کرتے ہیں کہ جو گرنا چاہیے تھا اس کے علاوہ کچھ نہیں گرا۔ اور ہم ہجرت پر کام شروع کرتے ہیں۔

ہر ایک کے پاس ایک پرنٹ شدہ رول آؤٹ پلان ہوتا ہے، ہر کوئی جانتا ہے کہ کون کیا کر رہا ہے اور کس وقت۔ ہر عمل کے بعد، ہم اس بات کو یقینی بنانے کے لیے اوقات کی جانچ کرتے ہیں کہ ہم ان سے تجاوز نہیں کرتے، اور سب کچھ منصوبہ بندی کے مطابق ہوتا ہے۔ جو لوگ موجودہ مرحلے میں براہ راست رول آؤٹ میں حصہ نہیں لے رہے ہیں وہ ایک آن لائن کھلونا (Xonotic، type 3 quacks) شروع کرکے تیاری کر رہے ہیں تاکہ ان کے ساتھیوں کو پریشان نہ کریں۔ 🙂

02:00 رول آؤٹ
ایک خوشگوار حیرت - ہم اپنے ڈیٹا بیس اور ہجرت کے اسکرپٹ کی اصلاح کی وجہ سے ایک گھنٹہ پہلے رول آؤٹ ختم کرتے ہیں۔ عام رونا، "رول آؤٹ!" تمام نئے فنکشنز پروڈکشن میں ہیں، لیکن اب تک صرف ہم انہیں انٹرفیس میں دیکھ سکتے ہیں۔ ہر کوئی ٹیسٹنگ موڈ میں جاتا ہے، انہیں گروپس میں ترتیب دیتا ہے، اور یہ دیکھنا شروع کرتا ہے کہ آخر میں کیا ہوا۔

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

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

ہم ایسے سوالات لکھتے ہیں جو اسے ریکارڈ کرتے ہیں، کم از کم 4 آنکھوں سے۔ ہم پری پروڈکشن کے دوران ان کی جانچ کرتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ وہ کام کرتے ہیں اور کچھ بھی نہیں ٹوٹتے۔ آپ مزید رول کر سکتے ہیں۔ ایک ہی وقت میں، ہم اپنی باقاعدہ انضمام کی جانچ چلاتے ہیں، جو کچھ اور مسائل کو ظاہر کرتا ہے۔ وہ سب چھوٹے ہیں، لیکن ان کی مرمت کی بھی ضرورت ہے۔

03:00 -2 مسائل +2 مسائل
پچھلے دو بڑے مسائل حل ہو چکے ہیں، اور تقریباً تمام چھوٹے مسائل بھی۔ وہ تمام لوگ جو اصلاحات میں مصروف ہیں فعال طور پر اپنے اکاؤنٹس میں کام کر رہے ہیں اور جو کچھ انہیں ملتا ہے اس کی اطلاع دے رہے ہیں۔ ہم ترجیح دیتے ہیں، ٹیموں میں تقسیم کرتے ہیں، اور صبح کے لیے غیر اہم اشیاء چھوڑ دیتے ہیں۔

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

03:20 ہنگامی مطابقت پذیری
ایک نیا مسئلہ طے ہوا۔ دوسرے کے لیے، ہم ہنگامی مطابقت پذیری کا اہتمام کر رہے ہیں۔ ہم سمجھتے ہیں کہ کیا ہو رہا ہے: پچھلی فکس نے ایک مسئلہ طے کیا، لیکن دوسرا پیدا کیا۔ ہم یہ جاننے کے لیے ایک وقفہ لیتے ہیں کہ اسے صحیح طریقے سے اور بغیر نتائج کے کیسے کرنا ہے۔

03:30 چھ آنکھیں
ہم سمجھتے ہیں کہ بنیاد کی آخری حالت کیا ہونی چاہیے تاکہ تمام شراکت داروں کے لیے سب کچھ ٹھیک رہے۔ ہم 6 آنکھوں کے ساتھ ایک درخواست لکھتے ہیں، اسے پری پروڈکشن میں رول آؤٹ کرتے ہیں، اس کی جانچ کرتے ہیں، اسے پروڈکشن کے لیے رول آؤٹ کرتے ہیں۔

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

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

06:00 UI میں سب کے لیے کھلا ہے۔
کیڑے ٹھیک ہو گئے۔ کچھ جو صارفین کو اپیل نہیں کرتے ہیں وہ بعد میں چھوڑ دیے جاتے ہیں۔ ہم ہر ایک کے لیے انٹرفیس کھولتے ہیں۔ ہم بلنگ پر کام جاری رکھتے ہیں، صارف کے تاثرات اور مانیٹرنگ کے نتائج کا انتظار کرتے ہیں۔

07:00 API لوڈ کے ساتھ مسائل
یہ واضح ہو جاتا ہے کہ ہم نے اپنے API پر بوجھ کا تھوڑا سا غلط منصوبہ بنایا اور اس بوجھ کا تجربہ کیا، جس سے مسئلہ کی نشاندہی نہیں ہو سکی۔ نتیجے کے طور پر، ≈5% درخواستیں ناکام ہو جاتی ہیں۔ آئیے متحرک ہوں اور وجہ تلاش کریں۔

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

08:00 API کو درست کریں۔
ہم نے بوجھ کے لیے ایک فکس تیار کیا، ناکامیاں دور ہو گئیں۔ ہم گھر جانے لگتے ہیں۔

10:00 تمام
سب کچھ طے شدہ ہے۔ یہ نگرانی میں خاموش ہے اور گاہکوں کی جگہ پر، ٹیم آہستہ آہستہ سو جاتی ہے۔ بلنگ باقی ہے، ہم اسے کل بحال کر دیں گے۔

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

تو، رول آؤٹ کامیاب رہا! یہ یقیناً بہتر ہو سکتا ہے، لیکن ہم نے اس بارے میں نتیجہ اخذ کیا جو ہمارے لیے کمال حاصل کرنے کے لیے کافی نہیں تھا۔

مجموعی طور پر

رول آؤٹ کے لیے 2 ماہ کی فعال تیاری کے دوران، 43 کام مکمل کیے گئے، جو چند گھنٹوں سے کئی دنوں تک جاری رہے۔

رول آؤٹ کے دوران:

• نئے اور بدلے ہوئے شیطان - 5 ٹکڑے، 2 یک سنگی کی جگہ؛
• ڈیٹا بیس کے اندر تبدیلیاں - صارف کے ڈیٹا کے ساتھ ہمارے تمام 6 ڈیٹا بیسز متاثر ہوئے ہیں، تین پرانے ڈیٹا بیس سے ایک نئے میں ڈاؤن لوڈ کیے گئے ہیں۔
• مکمل طور پر دوبارہ ڈیزائن فرنٹ اینڈ؛
• ڈاؤن لوڈ کردہ کوڈ کی مقدار - نئے کوڈ کی 33 ہزار لائنیں، ٹیسٹوں میں کوڈ کی ≈ 3 ہزار لائنیں، ≈ مائیگریشن کوڈ کی 5 ہزار لائنیں؛
• تمام ڈیٹا برقرار ہے، کسی ایک صارف کی ورچوئل مشین کو نقصان نہیں پہنچا۔ 🙂

اچھے رول آؤٹ کے لیے اچھے طریقے

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

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

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

ماخذ: www.habr.com