زیادہ تر پروڈکٹ ٹیمیں فرض کرتی ہیں کہ انفراسٹرکچر کی ملکیت صرف سافٹ ویئر کی تعمیر کا حصہ ہے۔ ہم نے بھی ایسا ہی کیا۔ یہ اس وقت تک نہیں تھا جب تک ہم نے یہ اندازہ نہیں لگایا کہ آپریشنل کاموں پر انجینئرنگ کا کتنا وقت صرف ہوا ہے کہ ہمیں احساس ہوا کہ یہ مفروضہ کتنا مہنگا ہے۔
سہ ماہی پلاننگ سیشن کے دوران، ہمارے ایک انجینئر نے ایک سوال پوچھا جو ٹیم میں سے کسی نے پہلے کبھی براہ راست نہیں پوچھا تھا۔ "ان چیزوں کو بنانے کے بجائے بنیادی ڈھانچے پر کتنا وقت صرف کیا جا رہا ہے جو لوگ استعمال کرتے ہیں؟”
یہ کوئی بیان بازی کا سوال نہیں تھا۔ ہم نے اپنے سپرنٹ لاگز، واقعے کے نوشتہ جات، اور کیلنڈرز نکالے اور ایمانداری سے جواب دینے کی کوشش کی۔
ہم ایک بڑی انٹرپرائز تنظیم کے اندر سات افراد پر مشتمل ایک اندرونی ٹولز ٹیم تھے۔ ہمارا مشن سادہ تھا۔ مقصد یہ ہے کہ ورک فلو آٹومیشن، اندرونی ڈیش بورڈز، اور اندرونی نظاموں کے درمیان انضمام کے ذریعے پوری کمپنی میں دیگر ٹیموں کو تیز تر بنایا جائے۔
ہمارا ایمیزون ویب سروسز (AWS) ماحول ٹھیک نہیں ہے۔ زیادہ تر معیارات کے مطابق، یہ ایک پختہ انفراسٹرکچر تھا۔ ECS میں کنٹینرائزڈ خدمات، GitHub ایکشنز کے ذریعے خودکار تعیناتی، CloudWatch آبزرویبلٹی، اور تمام ماحول میں IAM کے کردار کے مناسب دائرہ کار۔ فن تعمیر کے جائزے میں اس کے بارے میں کچھ بھی تشویش پیدا نہیں کرے گا۔
انوائس پر لاگت نہیں دکھائی گئی۔ ہم اسے اس فریکوئنسی میں دیکھ سکتے ہیں جس کے ساتھ کیلنڈرز، سیاق و سباق کے سوئچز، اور "انفراسٹرکچر ورک” نے خاموشی سے اس بیک لاگ کو تبدیل کر دیا جس کے ہم اصل میں ذمہ دار تھے۔
ان مکالموں نے بالآخر ہمیں جانچنے اور Sevalla کی طرف ہجرت کرنے پر مجبور کیا، جو آپریشنل سادگی کے لیے ایک پلیٹ فارم کے طور پر ایک سروس انفراسٹرکچر کنٹرول ہے۔ ہجرت میں تین ہفتے لگے۔ اثرات ایک ماہ کے اندر قابل پیمائش تھے۔
اس آرٹیکل میں، ہم اس بات پر ایک نظر ڈالیں گے کہ ہمارا AWS سیٹ اپ ہجرت سے پہلے کیسا لگتا تھا، ہجرت کا عمل اس میں اصل میں شامل تھا، مخصوص میٹرکس جو بعد میں تبدیل ہوا، اور راستے میں ہم نے جو تجارتی معاوضے قبول کیے تھے۔
ہم کیا احاطہ کریں گے:
ہجرت سے پہلے
AWS سیٹ اپ بہت اچھا تھا۔ ہم دستی طور پر کچھ نہیں کر رہے تھے، جو شرمناک تھا۔ ہم ہیں:
-
کنٹینر آرکیسٹریشن کے لیے ای سی ایس
-
ڈیٹا بیس کے لیے RDS
-
لاگز اور میٹرکس کے لیے CloudWatch
-
GitHub ایکشنز کے ساتھ CI/CD پائپ لائن
-
آئی اے ایم کے کردار متعدد ماحول میں منظم ہیں۔
-
CloudFormation ٹیمپلیٹس ایک سینئر انجینئر کے زیر انتظام
اس نے کام کیا۔ تعیناتی خودکار ہے۔ نظام مستحکم تھا۔
مسئلہ یہ نہیں ہے کہ کچھ ٹوٹ گیا ہے۔ مسئلہ ہموار آپریشنز کو برقرار رکھنے کی لاگت کا تھا۔
وہ نمبر جس نے گفتگو شروع کی۔
اپنے سہ ماہی پلاننگ سیشنز کے دوران، ہم نے ایماندار ہونے کی کوشش کی کہ ہمارا انجینئرنگ کا وقت کیسا گزر رہا ہے۔
ہم نے اندازہ لگایا کہ پوری ٹیم میں، تقریباً 12 سے 15 گھنٹے فی ہفتہ انفراسٹرکچر سے متعلق کام پر صرف کیے گئے جو کہ اندرونی صارفین کو براہ راست قدر فراہم نہیں کرتے تھے۔ ان میں شامل ہیں:
-
تعیناتی پائپ لائن کی دیکھ بھال اور ڈیبگنگ (فی ہفتہ 4 گھنٹے تک)
-
CloudWatch لاگ انویسٹی گیشن اور الرٹ ٹیوننگ (فی ہفتہ 3 گھنٹے تک)
-
IAM اجازت کا انتظام اور رسائی کا جائزہ (فی ہفتہ 2 گھنٹے تک)
-
انحصار اپ ڈیٹس، بنیادی ڈھانچے کے اجزاء کے لیے حفاظتی پیچ (فی ہفتہ 2 گھنٹے تک)
-
ایڈہاک واقعات کی تحقیقات، ماحولیاتی بڑھوتری، اور لاگت کی بے ضابطگیوں (فی ہفتہ 3-4 گھنٹے تک)
ایک مکمل طور پر پرعزم انجینئر کی قیمت پر، ہفتے میں 12 سے 15 گھنٹے اس کا تقریباً ایک تہائی حصہ ہے جو ایک کل وقتی انجینئر ہر ہفتے کسی چیز کو بنانے کے بجائے لائٹس کو روشن رکھنے میں صرف کرتا ہے۔
ایک ایسی ٹیم کے لیے جس کے پاس پہلے سے ہی لمبا بیک لاگ تھا جتنا ہم حقیقت پسندانہ طور پر سنبھال سکتے تھے، اس تعداد کا جواز پیش کرنا مشکل تھا۔
تعیناتی کا عمل: "معقول طور پر خودکار” کا واقعی کیا مطلب ہے۔
ہماری تعیناتی پائپ لائن زیادہ تر معیارات کے مطابق اچھی تھی۔ دھکا mainGitHub ایکشنز نے ایک تعمیر کو متحرک کیا، تصویر کو ECR پر دھکیل دیا، اور ECS سروس کو اپ ڈیٹ کیا۔ اچھے دن پر، تعیناتی کو انضمام سے چلنے میں تقریباً 12 منٹ لگے۔
تاہم، "معقول طور پر خودکار” ہونا ایک انتباہ کے ساتھ آتا ہے۔
صرف ایک انجینئر نے پائپ لائن کو پوری طرح سمجھا۔ جب تعیناتی کے دوران کوئی مسئلہ پیش آتا ہے، جیسا کہ ٹاسک ڈیفینیشن میں مماثلت، IAM اجازت کی خرابی، یا CloudFormation اسٹیک تنازعہ، زیادہ تر ٹیمیں یا تو مناسب انجینئر کا انتظار کرتی ہیں یا AWS دستاویزات کو پڑھنے اور خود اس کی تشخیص کرنے میں اہم وقت صرف کرتی ہیں۔
رول بیک دستی تھا۔ کوئی صاف ون کلک رول بیک نہیں تھا۔ رول بیک کا مطلب ہے پرانے امیج ٹیگز کو دوبارہ لگانا، جس کے لیے یہ جاننا ضروری ہے کہ وہ ٹیگز کیا ہیں، پائپ لائن کو دوبارہ متحرک کرنا، اور مزید 12 منٹ انتظار کرنا۔ وہ 12 منٹ کیس میں اہم تھے۔
ماحولیاتی برابری کمزور تھی۔ ہمارے پاس اسٹیجنگ اور پروڈکشن کا ماحول تھا۔ انہیں مستقل مزاجی اور متواتر مفاہمت کی ضرورت ہے۔ ہمیں اس سے زیادہ کثرت سے کنفیگریشن ڈرفٹ کا سامنا کرنا پڑا ہے جس کا ہم اعتراف کرنا چاہتے ہیں، جس کے نتیجے میں بعض اوقات ریلیزز اسٹیجنگ کے مقابلے پروڈکشن میں مختلف طریقے سے برتاؤ کرتی ہیں۔
ٹیم کے نئے ارکان اعتماد کے ساتھ تعینات کرنے سے قاصر تھے۔ نئے انجینئرز کو تعیناتی کے عمل میں شامل کرنے میں ایک دن کا بہتر حصہ لگا، اور زیادہ تر نئے ملازمین کئی ہفتوں تک آزادانہ طور پر تعیناتی شروع کرنے سے ہچکچا رہے تھے۔ پائپ لائن خودکار ہے، لیکن علم نہیں ہے۔
ہجرت دراصل کیا شامل ہے۔
ہم نے اپنی خدمات کو ایک ساتھ منتقل کرنے کی بجائے تقریباً تین ہفتوں میں بتدریج منتقل کیا۔
سب سے بڑی سرمایہ کاری انوائرمنٹ ویری ایبل کنفیگریشن اور سیکرٹ مینجمنٹ کو AWS پیرامیٹر اسٹور سے Sevalla کی انوائرمنٹ کنفیگریشن میں تبدیل کرنا تھا۔ تقریباً آدھا دن لگا۔
CI/CD منتقلی آسان تھی۔ ECS تعیناتی کے مرحلے کو Sevalla کی Git سے منسلک تعیناتی سے بدل دیا۔ GitHub انضمام براہ راست ذخیروں کا انتخاب کرتا ہے۔
ڈیٹا بیس کی منتقلی سب سے زیادہ محتاط حصہ تھا۔ ہم نے دونوں ڈیٹا بیس کو دو ہفتوں تک متوازی طور پر چلایا، ڈیٹا کی مستقل مزاجی کی تصدیق کی، اور پھر DNS کو تبدیل کیا۔ کوئی ڈیٹا ضائع نہیں ہوا تھا اور کوئی ڈاؤن ٹائم نہیں تھا۔
پوری ٹیم میں ہجرت کی کل کوشش: 3 ہفتوں میں تقریباً 40 گھنٹے، زیادہ تر 2 انجینئرز پر توجہ مرکوز کی۔
ہجرت کے بعد کیا بدلا۔
تعیناتی کا وقت ~12 منٹ سے کم کر کے ~3 منٹ کر دیا گیا ہے۔
یہ سب سے اہم تبدیلی نہیں تھی، لیکن یہ سب سے فوری طور پر قابل توجہ تھی۔ تیز تر تعیناتی کا مطلب ہے تیز فیڈ بیک لوپس۔ تعمیراتی سائیکل کا انتظار کیے بغیر اصلاحات کو پروڈکشن میں ڈالا جا سکتا ہے اور منٹوں میں تصدیق کی جا سکتی ہے۔
عام طور پر، 8 سے 10 تعیناتیوں کے ساتھ، آپ فی ہفتہ تقریباً 90 منٹ کی مجموعی تاخیر کو بحال کر لیں گے۔
ہر انجینئر پہلے دن اعتماد کے ساتھ تعینات کر سکتا ہے۔
یہ سب سے اہم آپریشنل تبدیلی تھی۔ تعیناتی کا عمل نظر آتا تھا، انٹرفیس میں ہی دستاویزی تھا، اور اسے چلانے کے لیے کسی ماہر علم کی ضرورت نہیں تھی۔ ٹیم میں شامل ہونے والے نئے انجینئرز پہلے دن سے اپنی پہلی تبدیلیاں آزادانہ طور پر تعینات کر سکتے ہیں۔
غیر رسمی "تعیناتی گیٹ کیپر” کا کردار جو خاموشی سے سب سے زیادہ تجربہ کار AWS انجینئرز کے ارد گرد تشکیل پا چکا تھا، مؤثر طریقے سے ختم کر دیا گیا۔
رول بیک 12 منٹ کے دستی عمل سے 30 سیکنڈ کے کام تک چلا گیا۔
Sevalla کی تمام تقسیمیں پچھلی تعمیرات پر ایک کلک رول بیک کو برقرار رکھتی ہیں۔ ہم نے اسے ہجرت کے بعد پہلے مہینے میں دو بار استعمال کیا۔ ایک بار جب ہم نے فوری طور پر ایک رجعت پکڑ لی، اور ایک بار جب ہمیں ڈیٹا بیس کی ناکام منتقلی کے دوران فوری طور پر واپس جانا پڑا۔
دونوں واقعات جن کے لیے پہلے گھنٹوں کی دستی مداخلت کی ضرورت تھی ایک منٹ سے بھی کم وقت میں حل ہو گئے تھے۔
انفراسٹرکچر کی دیکھ بھال کا وقت تقریباً 2-3 گھنٹے فی ہفتہ کم کر دیا گیا ہے۔
ہم اب IAM کرداروں، CloudWatch کی اطلاعات، CloudFormation ٹیمپلیٹس، یا ECS ٹاسک کی تعریفوں کو برقرار نہیں رکھتے ہیں۔ بنیادی ڈھانچے کی سطح کا رقبہ جو ہمارے پاس ہے ڈرامائی طور پر کم ہوا ہے۔
فی ہفتہ 12 سے 15 گھنٹے انفراسٹرکچر کے کام کا تخمینہ تقریباً 2 سے 3 گھنٹے فی ہفتہ کم کر دیا گیا ہے۔ اب اس میں بنیادی طور پر ایپلیکیشن کے رویے کی نگرانی اور بلڈ لاگز کا جائزہ لینا شامل ہے۔ یہ تقریباً 10 گھنٹے فی ہفتہ انجینئرنگ کے حقیقی بیک لاگ کے لیے مختص وقت کی بازیافت کرتا ہے۔
ایک چوتھائی سے زیادہ، یا تقریباً 130 گھنٹے، یا تقریباً تین ہفتے، پروڈکٹ پر کام کرنے میں صرف ہوتے ہیں۔
پیچھے مڑ کر دیکھا تو ہم خاموشی سے ایک پلیٹ فارم ٹیم بن گئے۔ اس لیے نہیں کہ ہم چاہتے تھے، بلکہ اس لیے کہ ہم نے جو بھی بنیادی ڈھانچے کا فیصلہ کیا ہے اس نے اپنی ملکیت کے لیے مزید انفراسٹرکچر بنایا ہے۔
اضافی ٹولز کے بغیر لاگ کی نمائش میں بہتری۔
ایک نتیجہ جس کی ہمیں توقع نہیں تھی وہ یہ ہے کہ کم سرمایہ کاری کے باوجود پیداوار کی نمائش میں بہتری آئی۔
AWS میں لاگ ان کے بامعنی تجزیہ کے لیے CloudWatch Insights کے سوالات، مناسب لاگ گروپس کی تشکیل، اور کہاں دیکھنا ہے۔ مفید مشاہدے کے لیے جان بوجھ کر سیٹ اپ کی کوششوں کی ضرورت ہے۔
Sevalla آپ کو بغیر کسی کنفیگریشن کے براہ راست ڈیش بورڈ سے بلڈ لاگز، رن ٹائم لاگز، اور تعیناتی کی تاریخ تک رسائی کی اجازت دیتا ہے۔ جب پروڈکشن میں کوئی مسئلہ پیش آتا ہے، تو "کچھ غلط ہو گیا” سے لے کر "کیا ہوا” تک کا وقت 10-20 منٹ سے کم کر کے ٹول کی تلاش میں زیادہ تر معاملات میں 2 منٹ سے بھی کم کر دیا گیا ہے۔
ہم نے کیا چھوڑ دیا
فکری ایمانداری کے لیے فوائد اور نقصانات کی فہرست درکار ہوتی ہے۔
سب سے پہلے، بنیادی ڈھانچے کی لچک کا فقدان ہے۔ اگر آپ کو اپنی مرضی کے مطابق نیٹ ورکنگ ٹوپولاجیز، مخصوص کمپیوٹ مثالوں، یا دانے دار اسٹوریج کنفیگریشنز کی ضرورت ہے، تو Sevalla آپ کی ضروریات کو پورا نہیں کرے گا۔ اندرونی ٹولز ٹیم کے لیے، ان میں سے کوئی بھی ضروریات پوری نہیں ہوئیں۔ لیکن وہ کر سکتے تھے۔
مزید برآں، کچھ AWS پر مبنی انضمام کے لیے دوبارہ کام کی ضرورت ہے۔ ہمارے پاس لیمبڈا کے کئی فنکشنز تھے جن کو خدمات میں ری فیکٹر کرنے کی ضرورت تھی۔ اس نے ہجرت میں مزید پیچیدگی پیدا کردی جس کا ہمیں پوری طرح سے اندازہ نہیں تھا۔
حقیقی کلاس
ہجرت نے ایسے حقائق کا انکشاف کیا جو اندرونی طور پر آسانی سے چھوٹ گئے۔ اس کا مطلب یہ ہے کہ پروڈکٹ ٹیموں کے لیے بنیادی ڈھانچے کی ملکیت کی لاگت بنیادی طور پر کلاؤڈ بل نہیں ہے۔ یہ انجینئرنگ کا مسئلہ ہے۔
ہماری سات افراد کی ٹیم کے لیے، فی ہفتہ 10 گھنٹے کے ریکوری ٹائم کا مطلب ان کاموں کے لیے دستیاب صلاحیت میں 28% اضافہ ہے جن کی ہمارے صارفین اصل میں خیال رکھتے ہیں۔ یہ معمولی بہتری نہیں ہے۔ یہ ایک معنی خیز تبدیلی ہے جو ٹیم حقیقت پسندانہ طور پر بھیج سکتی ہے۔
نتائج صرف Sevalla تک محدود نہیں ہیں۔ آپریشنل بوجھ کو صحیح معنوں میں کم کرنے کے لیے بنیادی ڈھانچے کو آسان بنانے کے اسی طرح کے نتائج برآمد ہوں گے۔
پوچھنے کے قابل سوالات ہیں: ~ کر سکتے ہیں۔ اپنے انفراسٹرکچر کا انتظام کریں۔ آیا انفراسٹرکچر مینجمنٹ آپ کی انجینئرنگ کی صلاحیتوں سے زیادہ سے زیادہ فائدہ اٹھا رہی ہے۔
داخلی ٹولز ٹیموں کے لیے جن کی قدر پوری طرح سے اس بات سے ماپا جاتا ہے کہ وہ کیا فراہم کرتے ہیں نہ کہ ان کو کیسے تعینات کیا جاتا ہے، جواب ایک زبردست نہیں تھا۔