Banki.ru پورٹل کے ڈائریکٹر آپریشنز اینڈری نکولسکی نے گزشتہ سال کی کانفرنس میں بات کی۔ یتیم خدمات کے بارے میں: بنیادی ڈھانچے میں یتیم کی شناخت کیسے کی جائے، یتیم خدمات کیوں خراب ہیں، ان کے ساتھ کیا کرنا ہے، اور اگر کچھ مدد نہیں کرتا ہے تو کیا کرنا ہے۔
کٹ کے نیچے رپورٹ کا متنی ورژن ہے۔
ہیلو ساتھیوں! میرا نام اینڈری ہے، میں Banki.ru پر آپریشنز کا سربراہ ہوں۔
ہمارے پاس بڑی خدمات ہیں، یہ ایسی یک سنگی خدمات ہیں، زیادہ کلاسیکی معنوں میں خدمات ہیں، اور بہت چھوٹی ہیں۔ میری مزدور کسان کی اصطلاح میں، میں کہتا ہوں کہ اگر کوئی خدمت سادہ اور چھوٹی ہے، تو وہ مائیکرو ہے، اور اگر یہ بہت آسان اور چھوٹی نہیں ہے، تو یہ صرف ایک خدمت ہے۔
خدمات کے فوائد
میں جلدی سے خدمات کے فوائد پر غور کروں گا۔
پہلا اسکیلنگ ہے۔ آپ فوری طور پر سروس پر کچھ کر سکتے ہیں اور پیداوار شروع کر سکتے ہیں۔ آپ کو ٹریفک موصول ہوئی ہے، آپ نے سروس کو کلون کیا ہے۔ آپ کے پاس زیادہ ٹریفک ہے، آپ نے اسے کلون کیا ہے اور اس کے ساتھ رہتے ہیں۔ یہ ایک اچھا بونس ہے، اور اصولی طور پر، جب ہم نے شروع کیا تھا، تو اسے ہمارے لیے سب سے اہم سمجھا جاتا تھا کہ ہم یہ سب کیوں کر رہے ہیں۔
دوم، الگ تھلگ ترقی، جب آپ کے پاس کئی ترقیاتی ٹیمیں ہوں، ہر ٹیم میں کئی مختلف ڈویلپرز ہوں، اور ہر ٹیم اپنی سروس تیار کرتی ہے۔
ٹیموں کے ساتھ ایک nuance ہے. ڈویلپرز مختلف ہیں۔ اور وہاں ہیں، مثال کے طور پر، . میں نے اسے پہلی بار میکسم ڈوروفیف کے ساتھ دیکھا۔ بعض اوقات برفانی تودے والے لوگ کچھ ٹیموں پر ہوتے ہیں اور دوسروں پر نہیں۔ اس سے کمپنی میں استعمال ہونے والی مختلف خدمات قدرے ناہموار ہوجاتی ہیں۔
تصویر دیکھیں: یہ ایک اچھا ڈویلپر ہے، اس کے ہاتھ بڑے ہیں، وہ بہت کچھ کر سکتا ہے۔ اصل مسئلہ یہ ہے کہ یہ ہاتھ کہاں سے آتے ہیں۔
خدمات مختلف پروگرامنگ زبانوں کا استعمال ممکن بناتی ہیں جو مختلف کاموں کے لیے زیادہ موزوں ہیں۔ کچھ سروس گو میں ہے، کچھ ایرلنگ میں ہے، کچھ روبی میں ہے، کچھ پی ایچ پی میں ہے، کچھ پائتھون میں ہے۔ عام طور پر، آپ بہت وسیع پیمانے پر توسیع کر سکتے ہیں. یہاں بھی باریکیاں ہیں۔
سروس پر مبنی فن تعمیر بنیادی طور پر ڈیوپس کے بارے میں ہے۔ یعنی، اگر آپ کے پاس آٹومیشن نہیں ہے، تعیناتی کا کوئی عمل نہیں ہے، اگر آپ اسے دستی طور پر ترتیب دیتے ہیں، تو آپ کی کنفیگریشنز سروس مثال سے مثال کے طور پر بدل سکتی ہیں، اور آپ کو وہاں کچھ کرنے کے لیے جانا پڑے گا، تب آپ جہنم میں ہیں۔
مثال کے طور پر، آپ کے پاس 20 خدمات ہیں اور آپ کو ہاتھ سے تعینات کرنے کی ضرورت ہے، آپ کے پاس 20 کنسولز ہیں، اور آپ بیک وقت ننجا کی طرح "انٹر" دبائیں گے۔ یہ بہت اچھا نہیں ہے۔
اگر آپ کے پاس جانچ کے بعد کوئی سروس ہے (اگر جانچ ہو رہی ہے، یقیناً)، اور آپ کو پھر بھی اسے فائل کے ساتھ ختم کرنے کی ضرورت ہے تاکہ یہ پروڈکشن میں کام کرے، میرے پاس آپ کے لیے بھی بری خبر ہے۔
اگر آپ ایمیزون کی مخصوص خدمات پر بھروسہ کرتے ہیں اور روس میں کام کرتے ہیں، تو دو ماہ قبل آپ کے پاس بھی "ہر چیز جل رہی ہے، میں ٹھیک ہوں، سب کچھ ٹھنڈا ہے۔"
ہم تعیناتی کو خودکار کرنے کے لیے Ansible، کنورجنسی کے لیے کٹھ پتلی، خودکار تعیناتی کے لیے بانس، اور کسی نہ کسی طرح ان سب کو بیان کرنے کے لیے Confluence کا استعمال کرتے ہیں۔
میں اس پر تفصیل سے غور نہیں کروں گا، کیونکہ رپورٹ بات چیت کے طریقوں کے بارے میں زیادہ ہے، نہ کہ تکنیکی نفاذ کے بارے میں۔
مثال کے طور پر، ہمیں مسائل کا سامنا کرنا پڑا ہے جہاں سرور پر پپٹ روبی 2 کے ساتھ کام کرتا ہے، لیکن کچھ ایپلیکیشن روبی 1.8 کے لیے لکھی گئی ہے، اور وہ ایک ساتھ کام نہیں کرتے ہیں۔ وہاں کچھ غلط ہو جاتا ہے۔ اور جب آپ کو ایک مشین پر روبی کے متعدد ورژن چلانے کی ضرورت ہوتی ہے، تو آپ کو عام طور پر مسائل کا سامنا کرنا پڑتا ہے۔
مثال کے طور پر، ہم ہر ڈویلپر کو ایک پلیٹ فارم دیتے ہیں جس پر ہمارے پاس تقریباً ہر چیز موجود ہوتی ہے، وہ تمام خدمات جو تیار کی جا سکتی ہیں، تاکہ اس کے پاس الگ تھلگ ماحول ہو، وہ اسے توڑ سکتا ہے اور جیسا چاہے بنا سکتا ہے۔
ایسا ہوتا ہے کہ آپ کو وہاں کسی چیز کی حمایت کے ساتھ کچھ خاص طور پر مرتب کردہ پیکیج کی ضرورت ہوتی ہے۔ یہ کافی سخت ہے۔ میں نے ایک رپورٹ سنی جہاں ڈوکر امیج کا وزن 45 جی بی ہے۔ لینکس میں، یقینا، یہ آسان ہے، وہاں سب کچھ چھوٹا ہے، لیکن پھر بھی، کافی جگہ نہیں ہوگی۔
ٹھیک ہے، متضاد انحصار ہیں، جب پروجیکٹ کا ایک ٹکڑا ایک ورژن کی لائبریری پر منحصر ہوتا ہے، پروجیکٹ کا دوسرا ٹکڑا دوسرے ورژن پر منحصر ہوتا ہے، اور لائبریریاں ایک ساتھ انسٹال نہیں ہوتیں۔
ہمارے پاس پی ایچ پی 5.6 میں سائٹس اور سروسز ہیں، ہم ان پر شرمندہ ہیں، لیکن ہم کیا کر سکتے ہیں؟ یہ ہماری ایک سائٹ ہے۔ پی ایچ پی 7 پر سائٹس اور سروسز موجود ہیں، ان میں سے اور بھی ہیں، ہمیں ان پر شرم نہیں آتی۔ اور ہر ڈویلپر کا اپنا بیس ہوتا ہے جہاں وہ خوشی سے دیکھتا ہے۔
اگر آپ کسی کمپنی میں ایک زبان میں لکھتے ہیں، تو فی ڈویلپر تین ورچوئل مشینیں نارمل لگتی ہیں۔ اگر آپ کے پاس مختلف پروگرامنگ زبانیں ہیں، تو صورتحال مزید خراب ہو جاتی ہے۔
آپ کے پاس اس پر سائٹس اور سروسز ہیں، اس پر، پھر Go کے لیے ایک اور سائٹ، ایک سائٹ Ruby کے لیے، اور کچھ دوسری Redis اس طرف ہیں۔ نتیجے کے طور پر، یہ سب سپورٹ کے لیے ایک بڑے میدان میں بدل جاتا ہے، اور ہر وقت اس میں سے کچھ ٹوٹ سکتا ہے۔
لہذا، ہم نے پروگرامنگ لینگویج کے فوائد کو مختلف فریم ورک کے استعمال سے بدل دیا، چونکہ پی ایچ پی کے فریم ورک بالکل مختلف ہیں، ان میں مختلف صلاحیتیں، مختلف کمیونٹیز اور مختلف سپورٹ ہیں۔ اور آپ ایک خدمت لکھ سکتے ہیں تاکہ آپ کے پاس اس کے لیے کچھ تیار ہو۔
ہر سروس کی اپنی ٹیم ہوتی ہے۔
ہمارا سب سے بڑا فائدہ، جو کئی سالوں میں کرسٹلائز ہوا ہے، یہ ہے کہ ہر سروس کی اپنی ٹیم ہوتی ہے۔ یہ ایک بڑے پروجیکٹ کے لیے آسان ہے، آپ دستاویزات پر وقت بچا سکتے ہیں، مینیجر اپنے پروجیکٹ کو اچھی طرح جانتے ہیں۔
آپ آسانی سے سپورٹ سے کام جمع کروا سکتے ہیں۔ مثال کے طور پر، انشورنس سروس ٹوٹ گئی۔ اور فوری طور پر وہ ٹیم جو انشورنس سے نمٹتی ہے اسے ٹھیک کرنے جاتی ہے۔
نئی خصوصیات تیزی سے تخلیق کی جا رہی ہیں، کیونکہ جب آپ کے پاس ایک ایٹم سروس ہے، تو آپ جلدی سے اس میں کوئی چیز ڈال سکتے ہیں۔
اور جب آپ اپنی سروس کو توڑتے ہیں، اور یہ لامحالہ ہوتا ہے، تو آپ نے دوسرے لوگوں کی خدمات کو متاثر نہیں کیا، اور دوسری ٹیموں کے ڈویلپر آپ کے پاس بٹس لے کر نہیں آتے اور کہتے ہیں: "اے-اے، ایسا مت کرو۔"
ہمیشہ کی طرح، باریکیاں ہیں۔ ہمارے پاس مستحکم ٹیمیں ہیں، مینیجرز ٹیم کے ساتھ جڑے ہوئے ہیں۔ واضح دستاویزات موجود ہیں، مینیجرز ہر چیز کی کڑی نگرانی کرتے ہیں۔ مینیجر کے ساتھ ہر ٹیم کی متعدد خدمات ہیں، اور اہلیت کا ایک خاص نقطہ ہے۔
اگر ٹیمیں تیر رہی ہیں (ہم کبھی کبھی اسے استعمال بھی کرتے ہیں)، تو ایک اچھا طریقہ ہے جسے "اسٹار میپ" کہا جاتا ہے۔
آپ کے پاس خدمات اور لوگوں کی فہرست ہے۔ نجمہ کا مطلب ہے کہ وہ شخص اس خدمت میں ماہر ہے، کتاب کا مطلب ہے کہ وہ شخص اس خدمت کا مطالعہ کر رہا ہے۔ اس شخص کا کام ستارے کے لیے کتابچہ کو تبدیل کرنا ہے۔ اور اگر پیش خدمت کے سامنے کچھ نہ لکھا جائے تو مسائل شروع ہو جاتے ہیں جس پر آگے بات کروں گا۔
یتیم خدمات کیسے ظاہر ہوتی ہیں؟
پہلا مسئلہ، آپ کے بنیادی ڈھانچے میں یتیم خدمت حاصل کرنے کا پہلا طریقہ لوگوں کو برطرف کرنا ہے۔ کیا کاموں کا اندازہ لگانے سے پہلے کبھی کسی نے کاروبار کی ڈیڈ لائن کو پورا کیا ہے؟ کبھی کبھی ایسا ہوتا ہے کہ ڈیڈ لائن تنگ ہوتی ہے اور دستاویزات کے لیے کافی وقت نہیں ہوتا۔ "ہمیں خدمت کو پیداوار کے حوالے کرنے کی ضرورت ہے، پھر ہم اسے شامل کریں گے۔"
اگر ٹیم چھوٹی ہے، تو یہ ہوتا ہے کہ ایک ڈویلپر ہے جو سب کچھ لکھتا ہے، باقی پنکھوں میں ہیں. "میں نے بنیادی فن تعمیر لکھا ہے، آئیے انٹرفیس شامل کریں۔" پھر کسی وقت مینیجر، مثال کے طور پر، چھوڑ دیتا ہے۔ اور اس مدت کے دوران، جب مینیجر چلا گیا ہے اور ابھی تک ایک نیا مقرر نہیں کیا گیا ہے، ڈویلپر خود فیصلہ کرتے ہیں کہ سروس کہاں جا رہی ہے اور وہاں کیا ہو رہا ہے. اور جیسا کہ ہم جانتے ہیں (چلو کچھ سلائیڈوں پر واپس چلتے ہیں)، کچھ ٹیموں میں سنو فلیک لوگ ہوتے ہیں، بعض اوقات سنو فلیک ٹیم لیڈر ہوتے ہیں۔ پھر وہ چھوڑ دیتا ہے، اور ہمیں یتیم کی خدمت ملتی ہے۔
ایک ہی وقت میں، سپورٹ اور کاروبار سے کام ختم نہیں ہوتے؛ وہ بیک لاگ میں ختم ہو جاتے ہیں۔ اگر سروس کی ترقی کے دوران کوئی آرکیٹیکچرل خرابیاں تھیں، تو وہ بھی بیک لاگ میں ختم ہوجاتی ہیں۔ سروس آہستہ آہستہ خراب ہو رہی ہے۔
یتیم کی شناخت کیسے کی جائے؟
یہ فہرست صورتحال کو اچھی طرح بیان کرتی ہے۔ ان کے انفراسٹرکچر کے بارے میں کس نے کچھ سیکھا؟
دستاویزی کام کے بارے میں: ایک خدمت ہے اور، عام طور پر، یہ کام کرتی ہے، اس کے ساتھ کام کرنے کے طریقہ کے بارے میں دو صفحات کا دستورالعمل ہے، لیکن کوئی نہیں جانتا کہ یہ اندر کیسے کام کرتا ہے۔
یا، مثال کے طور پر، کچھ قسم کا لنک شارٹنر ہے۔ مثال کے طور پر، ہمارے پاس فی الحال مختلف خدمات میں مختلف مقاصد کے لیے تین لنک شارٹنرز استعمال میں ہیں۔ یہ صرف اس کے نتائج ہیں۔
اب میں ظاہر کا کپتان بنوں گا۔ کیا کرنا چاہیے؟ سب سے پہلے، ہمیں سروس کو دوسرے مینیجر، دوسری ٹیم کو منتقل کرنے کی ضرورت ہے۔ اگر آپ کی ٹیم کی قیادت ابھی تک نہیں چھوڑی ہے، تو اس دوسری ٹیم میں، جب آپ سمجھتے ہیں کہ خدمت یتیم کی طرح ہے، آپ کو کسی ایسے شخص کو شامل کرنے کی ضرورت ہے جو کم از کم اس کے بارے میں کچھ سمجھتا ہو۔
اہم بات: آپ کے پاس منتقلی کے طریقہ کار کو خون میں لکھا جانا چاہیے۔ ہمارے معاملے میں، میں عام طور پر اس کی نگرانی کرتا ہوں، کیونکہ مجھے یہ سب کام کرنے کی ضرورت ہے۔ مینیجرز کو اس کی جلد فراہمی کی ضرورت ہوتی ہے، اور بعد میں اس کے ساتھ کیا ہوتا ہے اب ان کے لیے اتنا اہم نہیں ہے۔
یتیم بنانے کا اگلا طریقہ یہ ہے کہ "ہم اسے آؤٹ سورس کریں گے، یہ تیز تر ہوگا، اور پھر ہم اسے ٹیم کے حوالے کر دیں گے۔" یہ واضح ہے کہ ٹیم میں ہر کسی کے پاس کوئی نہ کوئی منصوبہ ہے، ایک باری ہے۔ اکثر کاروباری گاہک سوچتا ہے کہ آؤٹ سورس وہی کام کرے گا جو کمپنی کے پاس تکنیکی شعبہ ہے۔ اگرچہ ان کے محرکات مختلف ہیں۔ آؤٹ سورسنگ میں عجیب تکنیکی حل اور عجیب الگورتھمک حل ہیں۔
مثال کے طور پر، ہمارے پاس ایک سروس تھی جس میں مختلف غیر متوقع جگہوں پر Sphinx موجود تھا۔ میں آپ کو بعد میں بتاؤں گا کہ مجھے کیا کرنا تھا۔
آؤٹ سورسرز کے پاس خود تحریری فریم ورک ہوتے ہیں۔ یہ پچھلے پروجیکٹ سے کاپی پیسٹ کے ساتھ صرف ننگی پی ایچ پی ہے، جہاں آپ کو ہر طرح کی چیزیں مل سکتی ہیں۔ جب آپ کو کسی فائل میں کئی لائنوں کو تبدیل کرنے کے لیے کچھ پیچیدہ باش اسکرپٹس استعمال کرنے کی ضرورت ہوتی ہے تو تعیناتی اسکرپٹ ایک بڑی خرابی ہوتی ہے، اور ان تعیناتی اسکرپٹس کو کسی تیسرے اسکرپٹ کے ذریعے کہا جاتا ہے۔ نتیجے کے طور پر، آپ تعیناتی کے نظام کو تبدیل کرتے ہیں، کچھ اور منتخب کرتے ہیں، ہاپ کرتے ہیں، لیکن آپ کی سروس کام نہیں کرتی ہے۔ کیونکہ وہاں مختلف فولڈرز کے درمیان مزید 8 لنک ڈالنا ضروری تھا۔ یا ایسا ہوتا ہے کہ ایک ہزار ریکارڈ کام کرتے ہیں، لیکن ایک لاکھ کام نہیں کرتے۔
میں کپتانی جاری رکھوں گا۔ آؤٹ سورس سروس کو قبول کرنا ایک لازمی طریقہ کار ہے۔ کیا کبھی کسی کے پاس آؤٹ سورس سروس آئی ہے اور اسے کہیں بھی قبول نہیں کیا گیا ہے؟ یہ اتنا مقبول نہیں ہے، یقیناً، یتیم کی خدمت کے طور پر، لیکن پھر بھی۔
سروس کو چیک کرنے کی ضرورت ہے، سروس کا جائزہ لینے کی ضرورت ہے، پاس ورڈ تبدیل کرنے کی ضرورت ہے۔ ہمارے پاس ایک معاملہ تھا جب انہوں نے ہمیں ایک سروس دی، وہاں ایک ایڈمن پینل ہے "اگر لاگ ان == 'ایڈمن' && پاس ورڈ == 'ایڈمن'..."، یہ کوڈ میں ہی لکھا ہوا ہے۔ ہم بیٹھ کر سوچتے ہیں اور لوگ یہ 2018 میں لکھتے ہیں؟
ذخیرہ کرنے کی صلاحیت کی جانچ بھی ایک ضروری چیز ہے۔ آپ کو یہ دیکھنے کی ضرورت ہے کہ ایک لاکھ ریکارڈ پر کیا ہوگا، اس سے پہلے کہ آپ اس سروس کو کہیں پروڈکشن میں ڈالیں۔
بہتری کے لیے سروس بھیجنے میں کوئی شرم نہیں ہونی چاہیے۔ جب آپ کہتے ہیں: "ہم اس سروس کو قبول نہیں کریں گے، ہمارے پاس 20 کام ہیں، انہیں کریں، پھر ہم قبول کریں گے،" یہ عام بات ہے۔ آپ کے ضمیر کو اس بات سے ٹھیس نہیں پہنچنی چاہیے کہ آپ مینیجر لگا رہے ہیں یا کاروبار پیسے کا ضیاع کر رہا ہے۔ کاروبار پھر زیادہ خرچ کرے گا۔
ہمارے پاس ایک کیس تھا جب ہم نے پائلٹ پروجیکٹ کو آؤٹ سورس کرنے کا فیصلہ کیا۔
یہ وقت پر پہنچایا گیا تھا، اور یہ معیار کا واحد معیار تھا۔ اسی لیے ہم نے ایک اور پائلٹ پروجیکٹ بنایا، جو اب واقعی پائلٹ نہیں تھا۔ ان خدمات کو قبول کیا گیا، اور انتظامی ذرائع سے انہوں نے کہا، یہ رہا آپ کا کوڈ، یہ رہا ٹیم، یہ رہا آپ کا مینیجر۔ خدمات نے اصل میں پہلے ہی منافع کمانا شروع کر دیا ہے۔ ایک ہی وقت میں، حقیقت میں، وہ اب بھی یتیم ہیں، کوئی نہیں سمجھتا کہ وہ کیسے کام کرتے ہیں، اور مینیجر اپنے کاموں سے انکار کرنے کی پوری کوشش کرتے ہیں۔
ایک اور عظیم تصور ہے - گوریلا ترقی۔ جب کچھ محکمہ، عام طور پر مارکیٹنگ کا شعبہ، کسی مفروضے کی جانچ کرنا چاہتا ہے اور پوری سروس کو آؤٹ سورس کرنے کا حکم دیتا ہے۔ اس میں ٹریفک آنے لگتا ہے، وہ دستاویزات بند کر دیتے ہیں، ٹھیکیدار سے دستاویزات پر دستخط کرتے ہیں، کام میں آتے ہیں اور کہتے ہیں: "یار، ہمارے یہاں ایک سروس ہے، اس میں پہلے سے ہی ٹریفک ہے، اس سے پیسے آتے ہیں، چلو مان لیتے ہیں۔" ہم ایسے تھے، "اوپا، یہ کیسے ہو سکتا ہے۔"
اور یتیم کی خدمت حاصل کرنے کا ایک اور طریقہ: جب کچھ ٹیم اچانک اپنے آپ کو بوجھ محسوس کرتی ہے، تو انتظامیہ کہتی ہے: "آئیے اس ٹیم کی سروس کو دوسری ٹیم کو منتقل کریں، اس کا بوجھ کم ہے۔" اور پھر ہم اسے کسی تیسری ٹیم کو منتقل کر دیں گے اور مینیجر کو تبدیل کر دیں گے۔ اور آخر کار ہمارے پاس ایک بار پھر یتیم ہے۔
یتیموں کا مسئلہ کیا ہے؟
کون نہیں جانتا، یہ جنگی جہاز واسا ہے جسے سویڈن میں اٹھایا گیا تھا، جو اس حقیقت کے لیے مشہور ہے کہ یہ لانچنگ کے 5 منٹ بعد ہی ڈوب گیا۔ اور سویڈن کے بادشاہ نے ویسے بھی اس کے لیے کسی کو پھانسی نہیں دی۔ اسے انجینئروں کی دو نسلوں نے بنایا تھا جو نہیں جانتے تھے کہ ایسے جہاز کیسے بنائے جاتے ہیں۔ قدرتی اثر۔
جہاز، ویسے، بہت زیادہ خراب طریقے سے ڈوب سکتا تھا، مثال کے طور پر، جب بادشاہ پہلے ہی طوفان میں کہیں اس پر سوار تھا۔ اور اس طرح، وہ فوراً ڈوب گیا، ایجیل کے مطابق جلد ناکام ہونا اچھا ہے۔
اگر ہم جلد ناکام ہو جاتے ہیں، تو عام طور پر کوئی مسئلہ نہیں ہوتا ہے۔ مثال کے طور پر، قبولیت کے دوران اسے نظر ثانی کے لیے بھیجا گیا تھا۔ لیکن اگر ہم پہلے ہی پیداوار میں ناکام ہو جاتے ہیں، جب پیسہ لگایا جاتا ہے، تو پھر مسائل ہو سکتے ہیں۔ نتائج، جیسا کہ انہیں کاروبار میں کہا جاتا ہے۔
یتیم خدمات کیوں خطرناک ہیں:
- سروس اچانک ٹوٹ سکتی ہے۔
- سروس کی مرمت میں کافی وقت لگتا ہے یا بالکل ٹھیک نہیں ہوتا ہے۔
- سیفٹی کے مسائل
- بہتری اور اپ ڈیٹس کے ساتھ مسائل۔
- اگر کوئی اہم سروس ٹوٹ جاتی ہے تو کمپنی کی ساکھ متاثر ہوتی ہے۔
یتیموں کی خدمات کا کیا کرنا ہے؟
میں دوبارہ دہراؤں گا کہ کیا کرنا ہے۔ سب سے پہلے، دستاویزات ہونا ضروری ہے. Banki.ru میں 7 سالوں نے مجھے سکھایا کہ ٹیسٹرز کو ڈویلپرز کی بات نہیں لینی چاہیے، اور آپریشنز کو ہر کسی کی بات نہیں لینی چاہیے۔ ہمیں چیک کرنے کی ضرورت ہے۔
دوم، بات چیت کے خاکے لکھنا ضروری ہے، کیونکہ ایسا ہوتا ہے کہ ایسی خدمات جو بہت اچھی طرح سے موصول نہیں ہوتیں ان میں انحصار ہوتا ہے جس کے بارے میں کسی نے نہیں کہا۔ مثال کے طور پر، ڈویلپرز نے کچھ Yandex.Maps یا Dadata کی اپنی کلید پر سروس انسٹال کی۔ آپ مفت کی حد سے باہر ہو گئے ہیں، سب کچھ ٹوٹ گیا ہے، اور آپ نہیں جانتے کہ کیا ہوا ہے۔ اس طرح کے تمام ریک کو بیان کرنا ضروری ہے: سروس Dadata، SMS، کچھ اور استعمال کرتی ہے۔
تیسرا، تکنیکی قرض کے ساتھ کام کرنا۔ جب آپ کسی قسم کی بیساکھی کرتے ہیں یا کوئی خدمت قبول کرتے ہیں اور کہتے ہیں کہ کچھ کرنے کی ضرورت ہے، تو آپ کو یہ یقینی بنانا ہوگا کہ یہ ہو گیا ہے۔ کیونکہ پھر یہ معلوم ہو سکتا ہے کہ چھوٹا سوراخ اتنا چھوٹا نہیں ہے، اور آپ اس میں سے گر جائیں گے۔
تعمیراتی کاموں کے ساتھ، ہمارے پاس اسفنکس کے بارے میں ایک کہانی تھی۔ خدمات میں سے ایک نے فہرستیں داخل کرنے کے لیے Sphinx کا استعمال کیا۔ صرف صفحہ بندی کی فہرست، لیکن اسے ہر رات دوبارہ ترتیب دیا جاتا تھا۔ اسے دو اشاریہ جات سے جمع کیا گیا تھا: ایک بڑا اشاریہ ہر رات ترتیب دیا جاتا تھا، اور ایک چھوٹا اشاریہ بھی تھا جو اس کے ساتھ جڑا ہوا تھا۔ ہر روز، بم دھماکے یا نہ ہونے کے 50% امکان کے ساتھ، حساب کتاب کے دوران انڈیکس کریش ہو گیا، اور ہماری خبروں نے مرکزی صفحہ پر اپ ڈیٹ ہونا بند کر دیا۔ پہلے انڈیکس کو ری انڈیکس ہونے میں 5 منٹ لگے، پھر انڈیکس بڑھتا گیا اور کسی وقت دوبارہ انڈیکس ہونے میں 40 منٹ لگنے لگے۔ جب ہم نے اسے کاٹ دیا، تو ہم نے سکون کی سانس لی، کیونکہ یہ واضح تھا کہ تھوڑا اور وقت گزر جائے گا اور ہمارا انڈیکس مکمل وقت پر دوبارہ ترتیب دیا جائے گا۔ یہ ہمارے پورٹل کی ناکامی ہوگی، آٹھ گھنٹے تک کوئی خبر نہیں ہے - بس، کاروبار ٹھپ ہو گیا ہے۔
یتیم خدمت کے ساتھ کام کرنے کا منصوبہ بنائیں
درحقیقت، یہ کرنا بہت مشکل ہے، کیونکہ ڈیوپس مواصلات کے بارے میں ہے۔ آپ اپنے ساتھیوں کے ساتھ اچھی شرائط پر رہنا چاہتے ہیں، اور جب آپ اپنے ساتھیوں اور مینیجرز کو قواعد و ضوابط سے ٹکراتے ہیں، تو وہ ان لوگوں کے بارے میں متضاد جذبات رکھتے ہیں جو ایسا کرتے ہیں۔
ان تمام نکات کے علاوہ، ایک اور اہم چیز ہے: مخصوص افراد کو ہر مخصوص سروس کے لیے، تعیناتی کے طریقہ کار کے ہر مخصوص حصے کے لیے ذمہ دار ہونا چاہیے۔ جب لوگ نہ ہوں اور آپ کو اس سارے معاملے کا مطالعہ کرنے کے لیے کچھ اور لوگوں کو راغب کرنا پڑے تو یہ مشکل ہو جاتا ہے۔
اگر یہ سب کچھ مدد نہیں کرتا ہے، اور آپ کی یتیم خدمت اب بھی یتیم ہے، کوئی بھی اسے لینا نہیں چاہتا، دستاویزات نہیں لکھی گئی ہیں، جس ٹیم کو اس خدمت میں بلایا گیا تھا وہ کچھ کرنے سے انکار کر دیتی ہے، ایک آسان طریقہ ہے - دوبارہ کرنا سب کچھ
یعنی، آپ سروس کی ضروریات کو نئے سرے سے لیتے ہیں اور ایک نئی سروس لکھتے ہیں، بہتر، ایک بہتر پلیٹ فارم پر، عجیب تکنیکی حل کے بغیر۔ اور تم جنگ میں اس کی طرف ہجرت کرو۔
ہمارے پاس ایسی صورتحال تھی جب ہم نے Yii 1 پر ایک سروس لی اور محسوس کیا کہ ہم اسے مزید ترقی نہیں دے سکتے، کیونکہ ہمارے پاس ایسے ڈویلپرز کی کمی تھی جو Yii 1 پر اچھا لکھ سکتے تھے۔ تمام ڈویلپرز Symfony XNUMX پر اچھا لکھتے ہیں۔ کیا کرنا ہے؟ ہم نے وقت مختص کیا، ایک ٹیم مختص کی، ایک مینیجر مختص کیا، پروجیکٹ کو دوبارہ لکھا اور ٹریفک کو آسانی سے اس پر منتقل کیا۔
اس کے بعد پرانی سروس کو ڈیلیٹ کیا جا سکتا ہے۔ یہ میرا پسندیدہ طریقہ کار ہے، جب آپ کو کنفیگریشن مینجمنٹ سسٹم سے کچھ سروس لینے اور صاف کرنے کی ضرورت ہوتی ہے اور پھر جا کر دیکھیں کہ پروڈکشن میں تمام کاریں غیر فعال ہو چکی ہیں، تاکہ ڈویلپرز کے پاس کوئی نشان باقی نہ رہے۔ ذخیرہ Git میں رہتا ہے۔
یہ وہی ہے جس کے بارے میں میں بات کرنا چاہتا تھا، میں بحث کرنے کے لیے تیار ہوں، موضوع ہولیور ہے، بہت سے لوگ اس میں تیر چکے ہیں۔
سلائیڈوں میں کہا گیا کہ آپ نے زبانوں کو یکجا کیا۔ ایک مثال تصویروں کا سائز تبدیل کرنا تھا۔ کیا واقعی اسے ایک زبان تک محدود رکھنا ضروری ہے؟ کیونکہ پی ایچ پی میں تصویر کا سائز تبدیل کرنا، ٹھیک ہے، دراصل گولانگ میں کیا جا سکتا ہے۔
درحقیقت، یہ تمام طریقوں کی طرح اختیاری ہے۔ شاید، بعض صورتوں میں، یہ بھی ناپسندیدہ ہے. لیکن آپ کو یہ سمجھنے کی ضرورت ہے کہ اگر آپ کے پاس 50 افراد پر مشتمل کمپنی میں تکنیکی شعبہ ہے، ان میں سے 45 پی ایچ پی کے ماہرین ہیں، باقی 3 ڈیوپس ہیں جو Python، Ansible، Puppet اور اس طرح کی کوئی چیز جانتے ہیں، اور ان میں سے صرف ایک لکھتا ہے۔ کچھ گو امیج ریسائزنگ سروس، پھر جب یہ چلی جاتی ہے، مہارت اس کے ساتھ جاتی ہے۔ اور ایک ہی وقت میں، آپ کو مارکیٹ کے لیے مخصوص ڈویلپر کو تلاش کرنے کی ضرورت ہوگی جو اس زبان کو جانتا ہو، خاص طور پر اگر یہ نایاب ہو۔ یعنی تنظیمی نقطہ نظر سے یہ مسئلہ ہے۔ ڈیوپس کے نقطہ نظر سے، آپ کو صرف کچھ تیار شدہ پلے بکس کے سیٹ کلون کرنے کی ضرورت نہیں ہوگی جو آپ خدمات کو تعینات کرنے کے لیے استعمال کرتے ہیں، بلکہ آپ کو انہیں دوبارہ لکھنا پڑے گا۔
ہم فی الحال Node.js پر ایک سروس بنا رہے ہیں، اور یہ ہر ایک ڈویلپر کے لیے ایک الگ زبان کے ساتھ قریب ہی ایک پلیٹ فارم ہوگا۔ لیکن ہم بیٹھ گئے اور سوچا کہ کھیل موم بتی کے قابل ہے۔ یعنی یہ آپ کے لیے بیٹھ کر سوچنے کا سوال ہے۔
آپ اپنی خدمات کی نگرانی کیسے کرتے ہیں؟ آپ لاگز کو کیسے جمع اور نگرانی کرتے ہیں؟
ہم Elasticsearch میں لاگز جمع کرتے ہیں اور انہیں Kibana میں ڈالتے ہیں، اور اس بات پر منحصر ہے کہ آیا یہ پروڈکشن ہے یا ٹیسٹ ماحول، وہاں مختلف جمع کرنے والے استعمال کیے جاتے ہیں۔ کہیں لمبر جیک، کہیں اور کچھ اور، مجھے یاد نہیں۔ اور کچھ سروسز میں اب بھی کچھ جگہیں ہیں جہاں ہم ٹیلی گراف انسٹال کرتے ہیں اور الگ سے کہیں اور شوٹ کرتے ہیں۔
ایک ہی ماحول میں کٹھ پتلی اور جوابدہ کے ساتھ کیسے رہنا ہے؟
درحقیقت، اب ہمارے پاس دو ماحول ہیں، ایک کٹھ پتلی، دوسرا جواب دینے والا۔ ہم ان کو ہائبرڈائز کرنے کے لیے کام کر رہے ہیں۔ Ansible ابتدائی سیٹ اپ کے لیے ایک اچھا فریم ورک ہے، Puppet ابتدائی سیٹ اپ کے لیے ایک برا فریم ورک ہے کیونکہ اس کے لیے براہ راست پلیٹ فارم پر ہینڈ آن کام کی ضرورت ہوتی ہے، اور Puppet کنفیگریشن کنورجنسی کو یقینی بناتا ہے۔ اس کا مطلب یہ ہے کہ پلیٹ فارم اپنے آپ کو تازہ ترین حالت میں برقرار رکھتا ہے، اور جوابی مشین کو اپ ٹو ڈیٹ رکھنے کے لیے، آپ کو ہر وقت کچھ فریکوئنسی کے ساتھ اس پر پلے بکس چلانے کی ضرورت ہوتی ہے۔ یہی فرق ہے۔
آپ مطابقت کیسے برقرار رکھتے ہیں؟ کیا آپ کے پاس جوابی اور کٹھ پتلی دونوں میں تشکیلات ہیں؟
یہ ہمارا بڑا درد ہے، ہم اپنے ہاتھوں سے مطابقت برقرار رکھتے ہیں اور سوچتے ہیں کہ اب اس سب سے آگے کیسے بڑھیں۔ اس سے پتہ چلتا ہے کہ پپیٹ پیکیجز کو رول آؤٹ کرتا ہے اور وہاں کچھ لنکس کو برقرار رکھتا ہے، اور جوابی، مثال کے طور پر، کوڈ کو رول آؤٹ کرتا ہے اور وہاں جدید ترین ایپلیکیشن کنفیگرز کو ایڈجسٹ کرتا ہے۔
پریزنٹیشن روبی کے مختلف ورژن کے بارے میں تھی۔ کیا حل؟
ہم نے ایک جگہ اس کا سامنا کیا، اور ہمیں اسے ہر وقت اپنے ذہن میں رکھنا پڑتا ہے۔ ہم نے صرف روبی پر چلنے والے حصے کو بند کر دیا جو ایپلی کیشنز سے مطابقت نہیں رکھتا تھا اور اسے الگ رکھا۔
اس سال کی کانفرنس 7 دسمبر کو Technopolis میں منعقد ہوگا۔ ہم 11 نومبر تک رپورٹس کے لیے درخواستیں قبول کر رہے ہیں۔ اگر آپ بات کرنا چاہتے ہیں تو ہم سے۔
شرکاء کے لئے رجسٹریشن کھلا ہے، ہمارے ساتھ شامل ہوں!
ماخذ: www.habr.com