HighLoad++، Evgeniy Kuzovlev (EcommPay IT): جب ڈاؤن ٹائم کے ایک منٹ کی لاگت $100000 ہو تو کیا کریں

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

اگلی HighLoad++ کانفرنس 6 اور 7 اپریل 2020 کو سینٹ پیٹرزبرگ میں منعقد ہوگی۔ کے لیے تفصیلات اور ٹکٹ لنک. 9 نومبر، 18:00۔ ہائی لوڈ++ ماسکو 2018، دہلی + کولکتہ ہال۔ مقالہ جات اور پریزنٹیشن.

Evgeniy Kuzovlev (اس کے بعد - EC): - دوستو، ہیلو! میرا نام Kuzovlev Evgeniy ہے۔ میں EcommPay کمپنی سے ہوں، ایک مخصوص ڈویژن EcommPay IT ہے، کمپنیوں کے گروپ کا IT ڈویژن۔ اور آج ہم ڈاون ٹائمز کے بارے میں بات کریں گے - ان سے کیسے بچنا ہے، اس بارے میں کہ اگر ان سے بچا نہیں جا سکتا تو ان کے نتائج کو کیسے کم کیا جائے۔ موضوع اس طرح بیان کیا گیا ہے: "جب ڈاؤن ٹائم کے ایک منٹ کی قیمت $100 ہو تو کیا کریں"؟ آگے دیکھتے ہوئے، ہماری تعداد موازنہ ہے۔

EcommPay IT کیا کرتا ہے؟

ہم کون ہیں؟ میں یہاں تمہارے سامنے کیوں کھڑا ہوں؟ مجھے یہاں آپ کو کچھ بتانے کا حق کیوں ہے؟ اور ہم یہاں مزید تفصیل سے کیا بات کریں گے؟

کمپنیوں کا EcommPay گروپ ایک بین الاقوامی حاصل کنندہ ہے۔ ہم پوری دنیا میں ادائیگیوں پر کارروائی کرتے ہیں - روس، یورپ، جنوب مشرقی ایشیاء (دنیا بھر میں)۔ ہمارے پاس 9 دفاتر ہیں، کل 500 ملازمین، اور ان میں سے تقریباً نصف سے بھی کم IT ماہرین ہیں۔ ہم جو کچھ بھی کرتے ہیں، ہر وہ چیز جس سے ہم پیسہ کماتے ہیں، ہم نے خود کیا۔

ہم نے اپنی تمام پروڈکٹس لکھی ہیں (اور ہمارے پاس ان میں سے کافی تعداد ہے - ہماری بڑی IT مصنوعات کی لائن میں ہمارے پاس تقریباً 16 مختلف اجزاء ہیں)؛ ہم خود لکھتے ہیں، ہم خود کو ترقی دیتے ہیں۔ اور اس وقت ہم روزانہ تقریباً ایک ملین لین دین کرتے ہیں (لاکھوں شاید یہ کہنے کا صحیح طریقہ ہے)۔ ہم کافی نوجوان کمپنی ہیں - ہماری عمر صرف چھ سال ہے۔

6 سال پہلے یہ ایک ایسا اسٹارٹ اپ تھا جب لوگ کاروبار کے ساتھ آئے تھے۔ وہ ایک خیال سے متحد ہو گئے تھے (ایک خیال کے سوا کچھ نہیں تھا) اور ہم بھاگے۔ کسی بھی سٹارٹ اپ کی طرح، ہم تیزی سے بھاگے... ہمارے لیے رفتار معیار سے زیادہ اہم تھی۔

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

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

ڈاؤن ٹائمز آپریشن کے احکام۔

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

جب ہم نے اپنے نقطہ نظر کو تبدیل کرنا شروع کیا تو ہم نے 4 احکام بنائے۔ میں نے انہیں سلائیڈز پر پیش کیا ہے:

یہ احکام بہت آسان ہیں:

• جلدی سے مسئلہ کی نشاندہی کریں۔
• اس سے بھی تیزی سے چھٹکارا حاصل کریں۔
• وجہ سمجھنے میں مدد کریں (بعد میں، ڈویلپرز کے لیے)۔
• اور طریقوں کو معیاری بنائیں۔

میں آپ کی توجہ پوائنٹ نمبر 2 کی طرف مبذول کرانا چاہتا ہوں۔ ہم مسئلے سے چھٹکارا پا رہے ہیں، اسے حل نہیں کر رہے ہیں۔ فیصلہ کرنا ثانوی ہے۔ ہمارے لیے بنیادی بات یہ ہے کہ صارف اس مسئلے سے محفوظ ہے۔ یہ کسی الگ تھلگ ماحول میں موجود ہوگا، لیکن اس ماحول کا اس سے کوئی رابطہ نہیں ہوگا۔ درحقیقت، ہم مسائل کے ان چار گروہوں سے گزریں گے (کچھ زیادہ تفصیل سے، کچھ کم تفصیل میں)، میں آپ کو بتاؤں گا کہ ہم کیا استعمال کرتے ہیں، حل کرنے میں ہمارے پاس کیا متعلقہ تجربہ ہے۔

خرابیوں کا سراغ لگانا: وہ کب ہوتے ہیں اور ان کے بارے میں کیا کرنا ہے؟

لیکن ہم ترتیب سے باہر شروع کریں گے، ہم پوائنٹ نمبر 2 سے شروع کریں گے - مسئلہ سے جلدی کیسے چھٹکارا حاصل کیا جائے؟ ایک مسئلہ ہے - ہمیں اسے ٹھیک کرنے کی ضرورت ہے۔ "ہمیں اس بارے میں کیا کرنا چاہیے؟" - اہم سوال. اور جب ہم نے اس مسئلے کو حل کرنے کے بارے میں سوچنا شروع کیا، تو ہم نے اپنے لیے کچھ تقاضے تیار کیے جن پر عمل کرنا ضروری ہے۔

ان تقاضوں کو وضع کرنے کے لیے، ہم نے اپنے آپ سے یہ سوال پوچھنے کا فیصلہ کیا: "ہمیں کب مسائل درپیش ہیں"؟ اور مسائل، جیسا کہ یہ نکلا، چار صورتوں میں ہوتا ہے:

• ہارڈ ویئر کی ناکامی۔
• بیرونی خدمات ناکام ہوگئیں۔
• سافٹ ویئر ورژن کو تبدیل کرنا (وہی تعیناتی)۔
• دھماکہ خیز بوجھ میں اضافہ۔

ہم پہلے دو کے بارے میں بات نہیں کریں گے۔ ہارڈ ویئر کی خرابی کو کافی آسانی سے حل کیا جاسکتا ہے: آپ کے پاس ہر چیز کی نقل ہونی چاہئے۔ اگر یہ ڈسکیں ہیں، تو ڈسکوں کو RAID میں جمع ہونا چاہیے؛ اگر یہ سرور ہے، تو سرور کو ڈپلیکیٹ ہونا چاہیے؛ اگر آپ کے پاس نیٹ ورک انفراسٹرکچر ہے، تو آپ کو نیٹ ورک انفراسٹرکچر کی دوسری کاپی فراہم کرنی چاہیے، یعنی آپ اسے لے لیں اور اسے نقل کریں. اور اگر کچھ ناکام ہوجاتا ہے، تو آپ ریزرو پاور پر سوئچ کرتے ہیں۔ یہاں مزید کچھ کہنا مشکل ہے۔

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

پھر کیا کیا جائے؟ یہاں دو آپشنز ہیں۔ سب سے پہلے، اگر آپ کر سکتے ہیں، تو آپ کو اس سروس کو کسی طرح سے نقل کرنا چاہیے۔ مثال کے طور پر، اگر ہم کر سکتے ہیں، تو ہم ٹریفک کو ایک سروس سے دوسری سروس میں منتقل کرتے ہیں: مثال کے طور پر، Sberbank کے ذریعے کارڈز پر کارروائی کی گئی تھی، Sberbank کو مسائل درپیش ہیں - ہم ٹریفک کو [مشروط طور پر] Raiffeisen میں منتقل کرتے ہیں۔ دوسری چیز جو ہم کر سکتے ہیں وہ یہ ہے کہ بیرونی خدمات کی ناکامی کو بہت جلد محسوس کریں، اور اس لیے ہم رپورٹ کے اگلے حصے میں ردعمل کی رفتار کے بارے میں بات کریں گے۔

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

اگر آپ کے پاس بادل ہے تو ان چار مسائل میں سے کئی فوری طور پر حل ہو جاتے ہیں۔ اگر آپ Microsoft Azhur، Ozone کلاؤڈز میں ہیں، یا Yandex یا Mail سے ہمارے کلاؤڈز استعمال کر رہے ہیں، تو کم از کم ہارڈ ویئر کی خرابی ان کا مسئلہ بن جاتی ہے اور ہارڈ ویئر کی خرابی کے تناظر میں آپ کے لیے فوری طور پر سب کچھ ٹھیک ہو جاتا ہے۔

ہم قدرے غیر روایتی کمپنی ہیں۔ یہاں ہر کوئی "Kubernets" کے بارے میں بات کر رہا ہے، بادلوں کے بارے میں - ہمارے پاس نہ تو "Kubernets" ہیں اور نہ ہی بادل۔ لیکن ہمارے پاس بہت سے ڈیٹا سینٹرز میں ہارڈ ویئر کے ریک ہیں، اور ہم اس ہارڈ ویئر پر زندگی گزارنے پر مجبور ہیں، ہم اس سب کے ذمہ دار ہونے پر مجبور ہیں۔ اس لیے ہم اس تناظر میں بات کریں گے۔ تو، مسائل کے بارے میں. پہلے دو کو بریکٹ سے نکالا گیا۔

سافٹ ویئر ورژن تبدیل کرنا۔ اڈے

ہمارے ڈویلپرز کو پیداوار تک رسائی نہیں ہے۔ ایسا کیوں ہے؟ یہ صرف اتنا ہے کہ ہم PCI DSS مصدقہ ہیں، اور ہمارے ڈویلپرز کو صرف "پروڈکٹ" میں جانے کا حق نہیں ہے۔ یہ ہے، مدت. بالکل. لہذا، ترقی کی ذمہ داری بالکل اسی وقت ختم ہو جاتی ہے جب ترقی ریلیز کے لیے بل جمع کراتی ہے۔

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

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

سافٹ ویئر ورژن کو تبدیل کرنے کے تقاضے

تین تقاضے ہیں:

• ہمیں فوری طور پر تعیناتی کو واپس لینا چاہیے۔
• ہمیں ناکام تعیناتی کے اثرات کو کم کرنا چاہیے۔
• اور ہمیں فوری طور پر متوازی طور پر تعینات کرنے کے قابل ہونا چاہئے۔
  بالکل اسی ترتیب میں! کیوں؟ کیونکہ، سب سے پہلے، نیا ورژن لگاتے وقت، رفتار اہم نہیں ہے، لیکن یہ آپ کے لیے اہم ہے، اگر کچھ غلط ہو جائے، تو فوری طور پر واپس ہو جائیں اور کم سے کم اثر پڑے۔ لیکن اگر آپ کے پاس پروڈکشن میں ورژن کا ایک سیٹ ہے، جس کے لیے یہ پتہ چلتا ہے کہ ایک خرابی ہے (نیلی سے باہر، کوئی تعیناتی نہیں تھی، لیکن ایک خرابی ہے) - بعد میں تعیناتی کی رفتار آپ کے لیے اہم ہے۔ ہم نے ان مطالبات کو پورا کرنے کے لیے کیا کیا؟ ہم نے مندرجہ ذیل طریقہ کار کا سہارا لیا:

  
  
  یہ کافی مشہور ہے، ہم نے اسے کبھی ایجاد نہیں کیا - یہ بلیو/گرین ڈیپلائی ہے۔ یہ کیا ہے؟ آپ کے پاس سرورز کے ہر گروپ کے لیے ایک کاپی ہونی چاہیے جس پر آپ کی ایپلیکیشنز انسٹال ہیں۔ کاپی "گرم" ہے: اس پر کوئی ٹریفک نہیں ہے، لیکن کسی بھی وقت یہ ٹریفک اس کاپی پر بھیجی جا سکتی ہے۔ یہ کاپی پچھلے ورژن پر مشتمل ہے۔ اور تعیناتی کے وقت، آپ کوڈ کو ایک غیر فعال کاپی میں رول آؤٹ کرتے ہیں۔ پھر آپ ٹریفک کے کچھ حصے (یا تمام) کو نئے ورژن میں تبدیل کرتے ہیں۔ اس طرح، ٹریفک کے بہاؤ کو پرانے ورژن سے نئے ورژن میں تبدیل کرنے کے لیے، آپ کو صرف ایک کارروائی کرنے کی ضرورت ہے: آپ کو اپ اسٹریم میں بیلنسر کو تبدیل کرنے، سمت کو تبدیل کرنے کی ضرورت ہے - ایک اپ اسٹریم سے دوسرے میں۔ یہ بہت آسان ہے اور فوری سوئچنگ اور فوری رول بیک کا مسئلہ حل کرتا ہے۔

  یہاں دوسرے سوال کا حل مائنسائزیشن ہے: آپ اپنی ٹریفک کا صرف ایک حصہ نئی لائن پر، نئے کوڈ والی لائن پر بھیج سکتے ہیں (مثال کے طور پر، 2%)۔ اور یہ 2% 100% نہیں ہیں! اگر آپ ناکام تعیناتی کی وجہ سے اپنی ٹریفک کا 100% کھو دیتے ہیں، تو یہ خوفناک ہے؛ اگر آپ اپنی ٹریفک کا 2% کھو دیتے ہیں، تو یہ ناخوشگوار ہے، لیکن یہ خوفناک نہیں ہے۔ مزید برآں، صارفین غالباً اس کا نوٹس بھی نہیں لیں گے، کیونکہ بعض صورتوں میں (بالکل نہیں) ایک ہی صارف، F5 کو دبانے سے، دوسرے، ورکنگ ورژن پر لے جایا جائے گا۔

  بلیو/سبز تعینات۔ روٹنگ

  تاہم، ہر چیز اتنی آسان نہیں ہے "بلیو/گرین ڈیپلائی"... ہمارے تمام اجزاء کو تین گروپوں میں تقسیم کیا جا سکتا ہے:

  • یہ فرنٹ اینڈ ہے (ادائیگی کے صفحات جو ہمارے کلائنٹ دیکھتے ہیں)؛
  • پروسیسنگ کور؛
  • ادائیگی کے نظام کے ساتھ کام کرنے کے لیے اڈاپٹر (بینک، ماسٹر کارڈ، ویزا...)۔

  اور یہاں ایک نزاکت ہے - nuance لائنوں کے درمیان روٹنگ میں ہے۔ اگر آپ صرف 100% ٹریفک کو تبدیل کرتے ہیں، تو آپ کو یہ مسائل نہیں ہیں۔ لیکن اگر آپ 2٪ کو تبدیل کرنا چاہتے ہیں، تو آپ سوالات پوچھنا شروع کر دیتے ہیں: "یہ کیسے کریں؟" سب سے آسان چیز سیدھی آگے ہے: آپ بے ترتیب انتخاب کے ذریعے nginx میں راؤنڈ رابن سیٹ کر سکتے ہیں، اور آپ کے پاس 2% بائیں، 98% دائیں طرف ہے۔ لیکن یہ ہمیشہ مناسب نہیں ہوتا ہے۔

  مثال کے طور پر، ہمارے معاملے میں، صارف ایک سے زیادہ درخواستوں کے ساتھ سسٹم کے ساتھ تعامل کرتا ہے۔ یہ عام ہے: 2، 3، 4، 5 درخواستیں - آپ کے سسٹم ایک جیسے ہوسکتے ہیں۔ اور اگر آپ کے لیے یہ ضروری ہے کہ صارف کی تمام درخواستیں اسی لائن پر آئیں جس پر پہلی درخواست آئی تھی، یا (دوسرا نقطہ) صارف کی تمام درخواستیں سوئچ کے بعد نئی لائن پر آتی ہیں (وہ پہلے سے کام کرنا شروع کر سکتا تھا۔ نظام، سوئچ سے پہلے)، - پھر یہ بے ترتیب تقسیم آپ کے لیے موزوں نہیں ہے۔ پھر مندرجہ ذیل اختیارات ہیں:

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

  اگر کسی وجہ سے یہ آپ کے مطابق نہیں ہے اور آپ کو اس لائن پر درخواستیں بھیجنی ہوں گی جہاں صارف کی ابتدائی، ابتدائی درخواست آئی تھی، تو آپ کے پاس دو اختیارات ہیں...
  پہلا آپشن: آپ ادا شدہ nginx+ خرید سکتے ہیں۔ ایک سٹکی سیشن میکانزم ہے، جو صارف کی ابتدائی درخواست پر، صارف کو ایک سیشن تفویض کرتا ہے اور اسے ایک یا دوسرے اپ اسٹریم سے جوڑتا ہے۔ سیشن لائف ٹائم کے اندر تمام بعد میں آنے والی صارف کی درخواستیں اسی اپ اسٹریم پر بھیجی جائیں گی جہاں سیشن پوسٹ کیا گیا تھا۔

  یہ ہمارے لئے مناسب نہیں تھا کیونکہ ہمارے پاس پہلے سے ہی باقاعدہ nginx تھا۔ nginx+ پر سوئچ کرنا یہ نہیں ہے کہ یہ مہنگا ہے، یہ صرف یہ ہے کہ یہ ہمارے لیے کچھ تکلیف دہ تھا اور بہت درست نہیں۔ مثال کے طور پر، "اسٹکس سیشنز" نے ہمارے لیے اس سادہ وجہ سے کام نہیں کیا کہ "اسٹکس سیشنز" "Either-or" کی بنیاد پر روٹنگ کی اجازت نہیں دیتے ہیں۔ وہاں آپ اس بات کی وضاحت کر سکتے ہیں کہ ہم "اسٹک سیشنز" کیا کرتے ہیں، مثال کے طور پر، IP ایڈریس یا IP ایڈریس اور کوکیز یا پوسٹ پیرامیٹر کے ذریعے، لیکن "یا تو یا" وہاں زیادہ پیچیدہ ہے۔

  لہذا، ہم چوتھے آپشن پر آئے۔ ہم نے سٹیرائڈز پر nginx لیا (یہ اوپنریسٹی ہے) - یہ وہی nginx ہے، جو آخری اسکرپٹ کو شامل کرنے کی بھی حمایت کرتا ہے۔ آپ آخری اسکرپٹ لکھ سکتے ہیں، اسے "اوپن ریسٹ" دے سکتے ہیں، اور یہ آخری اسکرپٹ صارف کی درخواست آنے پر عمل میں لایا جائے گا۔

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

  بلیو/سبز تعینات۔ فائدے اور نقصانات

  یقیناً، اسے تھوڑا سا آسان بنانا ممکن تھا (وہی "اسٹکی سیشنز" کا استعمال کریں)، لیکن ہمارے پاس ایک ایسی نزاکت بھی ہے کہ نہ صرف صارف ایک لین دین کی ایک پروسیسنگ کے فریم ورک کے اندر ہمارے ساتھ بات چیت کرتا ہے... لیکن ادائیگی کے نظام بھی ہمارے ساتھ تعامل کرتے ہیں: لین دین پر کارروائی کرنے کے بعد (پیمنٹ سسٹم کو درخواست بھیج کر)، ہمیں کول بیک موصول ہوتا ہے۔
  اور چلیں کہ اگر ہم اپنے سرکٹ کے اندر تمام درخواستوں میں صارف کا IP ایڈریس فارورڈ کر سکتے ہیں اور IP ایڈریس کی بنیاد پر صارفین کو تقسیم کر سکتے ہیں، تو ہم وہی “ویزا” نہیں بتائیں گے: “یار، ہم ایک ایسی ریٹرو کمپنی ہیں، ہمیں لگتا ہے۔ بین الاقوامی ہونے کے لیے (ویب سائٹ اور روس میں)... براہ کرم ہمیں ایک اضافی فیلڈ میں صارف کا IP ایڈریس فراہم کریں، آپ کا پروٹوکول معیاری ہے"! یہ واضح ہے کہ وہ متفق نہیں ہوں گے۔

  
  
  لہذا، یہ ہمارے لئے کام نہیں کیا - ہم نے کھلے عام کیا. اس کے مطابق، روٹنگ کے ساتھ ہمیں کچھ اس طرح ملا:

  بلیو/گرین تعیناتی کے، اس کے مطابق، وہ فوائد ہیں جن کا میں نے ذکر کیا اور نقصانات۔

  دو نقصانات:

  • آپ کو روٹنگ کے ساتھ پریشان ہونے کی ضرورت ہے؛
  • دوسرا اہم نقصان خرچ ہے.

  آپ کو دو گنا زیادہ سرورز کی ضرورت ہے، آپ کو دو گنا زیادہ آپریشنل وسائل کی ضرورت ہے، آپ کو اس پورے چڑیا گھر کو برقرار رکھنے کے لیے دو گنا زیادہ محنت کرنے کی ضرورت ہے۔

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

  فوری تعیناتی کیسے کی جائے؟

  ہم نے کم سے کم اور فوری رول بیک کے مسئلے کو حل کرنے کے بارے میں بات کی، لیکن سوال باقی ہے: "جلد کیسے تعینات کیا جائے؟"

  
  
  یہ یہاں مختصر اور سادہ ہے۔

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

    آرٹفیکٹ کیا ہے؟ ایک نمونہ ایک جمع شدہ تعمیر ہے جس میں اسمبلی کے تمام حصے پہلے ہی مکمل ہو چکے ہیں۔ ہم اس نمونے کو آرٹفیکٹ اسٹوریج میں محفوظ کرتے ہیں۔ ایک وقت میں ہم نے اس طرح کے دو سٹوریج استعمال کیے تھے - یہ Nexus تھا اور اب jFrog Artifactory)۔ ہم نے ابتدا میں "Nexus" کا استعمال کیا کیونکہ ہم نے جاوا ایپلی کیشنز میں اس طریقہ کار پر عمل کرنا شروع کیا تھا (یہ اس کے مطابق تھا)۔ پھر انہوں نے پی ایچ پی میں لکھی ہوئی کچھ ایپلی کیشنز کو وہاں ڈال دیا۔ اور "گٹھ جوڑ" اب موزوں نہیں تھا، اور اس لیے ہم نے jFrog Artefactory کا انتخاب کیا، جو تقریباً ہر چیز کو فنی شکل دے سکتا ہے۔ ہم یہاں تک پہنچ چکے ہیں کہ اس نمونے کے ذخیرے میں ہم اپنے بائنری پیکجز کو ذخیرہ کرتے ہیں جو ہم سرورز کے لیے جمع کرتے ہیں۔

  دھماکہ خیز بوجھ میں اضافہ

  ہم نے سافٹ ویئر ورژن کو تبدیل کرنے کے بارے میں بات کی۔ ہمارے پاس اگلی چیز بوجھ میں دھماکہ خیز اضافہ ہے۔ یہاں، میرا مطلب شاید بوجھ کی دھماکہ خیز نمو سے ہے جو بالکل صحیح چیز نہیں ہے...

  ہم نے ایک نیا نظام لکھا - یہ خدمت پر مبنی، فیشن ایبل، خوبصورت، ہر جگہ کارکن، ہر جگہ قطاریں، ہر جگہ غیر مطابقت پذیر ہے۔ اور اس طرح کے نظاموں میں، ڈیٹا مختلف بہاؤ سے گزر سکتا ہے۔ پہلی ٹرانزیکشن کے لیے، 1st، 3rd، 10th کارکن کو استعمال کیا جا سکتا ہے، دوسری ٹرانزیکشن کے لیے - 2nd, 4th, 5th. اور آج، ہم کہتے ہیں، صبح کے وقت آپ کے پاس ڈیٹا کا بہاؤ ہوتا ہے جو پہلے تین کارکنوں کو استعمال کرتا ہے، اور شام کو یہ ڈرامائی طور پر بدل جاتا ہے، اور ہر چیز باقی تین کارکنوں کو استعمال کرتی ہے۔

  اور یہاں یہ پتہ چلتا ہے کہ آپ کو کسی نہ کسی طرح کارکنوں کو پیمانہ کرنے کی ضرورت ہے، آپ کو کسی نہ کسی طرح اپنی خدمات کو پیمانہ کرنے کی ضرورت ہے، لیکن ایک ہی وقت میں وسائل کو پھولنے سے روکنا ہے۔

  
  
  ہم نے اپنی ضروریات کی وضاحت کی ہے۔ یہ تقاضے کافی آسان ہیں: کہ سروس کی دریافت ہو، پیرامیٹرائزیشن - اس طرح کے توسیع پذیر نظاموں کی تعمیر کے لیے سب کچھ معیاری ہے، سوائے ایک نقطہ کے - وسائل کی قدر میں کمی۔ ہم نے کہا کہ ہم وسائل کو کم کرنے کے لیے تیار نہیں ہیں تاکہ سرور ہوا کو گرم کریں۔ ہم نے "قونصل" لیا، ہم نے "Nomad" لیا، جو ہمارے کارکنوں کا انتظام کرتا ہے۔

  ہمارے لیے یہ مسئلہ کیوں ہے؟ آئیے تھوڑا پیچھے ہٹتے ہیں۔ اب ہمارے پاس تقریباً 70 ادائیگی کے نظام ہیں۔ صبح کے وقت، ٹریفک Sberbank سے گزرتا ہے، پھر Sberbank گر گیا، مثال کے طور پر، اور ہم اسے دوسرے ادائیگی کے نظام پر سوئچ کر دیتے ہیں۔ Sberbank سے پہلے ہمارے پاس 100 کارکن تھے، اور اس کے بعد ہمیں ادائیگی کے دوسرے نظام کے لیے 100 کارکنوں کو تیزی سے بڑھانے کی ضرورت ہے۔ اور یہ سب کچھ انسانی شرکت کے بغیر ہونا ضروری ہے۔ کیونکہ اگر انسانوں کی شرکت ہو تو وہاں ایک انجینئر 24/7 بیٹھنا چاہیے، جو صرف یہ کام کر رہا ہو، کیونکہ ایسی ناکامیاں، جب 70 سسٹم آپ کے پیچھے ہوتے ہیں، باقاعدگی سے ہوتے ہیں۔

  لہذا، ہم نے Nomad کو دیکھا، جس کا ایک کھلا IP ہے، اور اس نے اپنی چیز لکھی، Scale-Nomad - ScaleNo، جو تقریباً درج ذیل کام کرتا ہے: یہ قطار کی نمو پر نظر رکھتا ہے اور حرکیات کے لحاظ سے کارکنوں کی تعداد کو کم یا بڑھاتا ہے۔ قطار کے جب ہم نے یہ کیا، تو ہم نے سوچا: "شاید ہم اسے کھول سکتے ہیں؟" پھر انہوں نے اس کی طرف دیکھا - وہ دو کوپیکس کی طرح سادہ تھی۔

  ابھی تک ہم نے اسے اوپن سورس نہیں کیا ہے، لیکن اگر رپورٹ کے بعد اچانک احساس ہوا کہ آپ کو فلاں چیز کی ضرورت ہے، آپ کو اس کی ضرورت ہے، میرے رابطے آخری سلائیڈ میں ہیں- براہ کرم مجھے لکھیں۔ اگر کم از کم 3-5 لوگ ہوں تو ہم اسے اسپانسر کریں گے۔

  
  
  یہ کیسے کام کرتا ہے؟ آئیے ایک نظر ڈالیں! آگے دیکھ رہے ہیں: بائیں طرف ہماری نگرانی کا ایک ٹکڑا ہے: یہ ایک لائن ہے، سب سے اوپر واقعہ کی کارروائی کا وقت ہے، درمیان میں لین دین کی تعداد ہے، نیچے کارکنوں کی تعداد ہے۔

  اگر آپ دیکھیں تو اس تصویر میں ایک خرابی ہے۔ اوپر والے چارٹ پر، چارٹ میں سے ایک 45 سیکنڈ میں کریش ہو گیا - ادائیگی کا ایک نظام نیچے چلا گیا۔ فوری طور پر، 2 منٹ میں ٹریفک لایا گیا اور ایک اور ادائیگی کے نظام پر قطار بڑھنے لگی، جہاں کوئی کارکن نہیں تھے (ہم نے وسائل کا استعمال نہیں کیا - اس کے برعکس، ہم نے وسائل کو صحیح طریقے سے ٹھکانے لگایا)۔ ہم گرم نہیں کرنا چاہتے تھے - ایک کم سے کم تعداد تھی، تقریبا 5-10 کارکن، لیکن وہ مقابلہ نہیں کر سکے.

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

  نگرانی۔ فوری طور پر مسئلہ کی شناخت کیسے کریں؟

  اب پہلا نکتہ یہ ہے کہ "مسائل کی فوری شناخت کیسے کی جائے؟" نگرانی! ہمیں کچھ چیزوں کو جلدی سمجھ لینا چاہیے۔ ہمیں کن چیزوں کو جلدی سمجھ لینا چاہیے؟

  
  
  تین چیزیں!

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

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

  
  
  ہم ہارڈ ویئر کی نگرانی کے لیے، سرورز کے اہم اشاریوں کی نگرانی کے لیے Zabbix کا استعمال کرتے ہیں۔ ہم ڈیٹا بیس کے لیے Okmeter استعمال کرتے ہیں۔ ہم دوسرے تمام اشاریوں کے لیے "Grafana" اور "Prometheus" استعمال کرتے ہیں جو پہلے دو میں فٹ نہیں ہوتے، کچھ "Grafana" اور "Prometheus" کے ساتھ، اور کچھ "Grafana" کے ساتھ "Influx" اور Telegraf کے ساتھ۔

  ایک سال پہلے ہم نیو ریلک استعمال کرنا چاہتے تھے۔ ٹھنڈی چیز، یہ سب کچھ کر سکتی ہے۔ لیکن جتنا وہ سب کچھ کر سکتی ہے، اتنی مہنگی ہے۔ جب ہم 1,5 ہزار سرورز کے حجم تک پہنچ گئے تو ایک وینڈر ہمارے پاس آیا اور کہا: "آئیے اگلے سال کے لیے ایک معاہدہ کرتے ہیں۔" ہم نے قیمت کو دیکھا اور کہا نہیں، ہم ایسا نہیں کریں گے۔ اب ہم نیو ریلیک کو چھوڑ رہے ہیں، ہمارے پاس نیو ریلیک کی نگرانی میں تقریباً 15 سرور باقی ہیں۔ قیمت بالکل جنگلی نکلی۔

  اور ایک ٹول ہے جسے ہم نے خود لاگو کیا ہے - یہ ڈیبگر ہے۔ پہلے تو ہم نے اسے "بیگر" کہا، لیکن پھر ایک انگلش ٹیچر وہاں سے گزرا، بے دردی سے ہنسا، اور اس کا نام بدل کر "ڈیباگر" رکھ دیا۔ یہ کیا ہے؟ یہ ایک ایسا ٹول ہے جو درحقیقت ہر جزو پر 15-30 سیکنڈز میں، سسٹم کے "بلیک باکس" کی طرح، جزو کی مجموعی کارکردگی پر ٹیسٹ چلاتا ہے۔

  مثال کے طور پر، اگر کوئی بیرونی صفحہ (ادائیگی کا صفحہ) ہے، تو وہ اسے کھولتا ہے اور دیکھتا ہے کہ اسے کیسا دکھنا چاہیے۔ اگر اس پر کارروائی ہو رہی ہے، تو وہ ایک ٹیسٹ "لین دین" بھیجتا ہے اور اس بات کو یقینی بناتا ہے کہ یہ "لین دین" پہنچ جائے۔ اگر یہ ادائیگی کے نظام سے تعلق ہے، تو ہم اس کے مطابق ایک ٹیسٹ کی درخواست کو فائر کرتے ہیں، جہاں ہم کر سکتے ہیں، اور دیکھتے ہیں کہ ہمارے ساتھ سب کچھ ٹھیک ہے۔

  نگرانی کے لیے کون سے اشارے اہم ہیں؟

  ہم بنیادی طور پر کیا مانیٹر کرتے ہیں؟ ہمارے لیے کون سے اشارے اہم ہیں؟

  
  

  • محاذوں پر رسپانس ٹائم / آر پی ایس ایک بہت اہم اشارے ہے۔ وہ فوراً جواب دیتا ہے کہ آپ کے ساتھ کچھ غلط ہے۔
  • تمام قطاروں میں پروسیس شدہ پیغامات کی تعداد۔
  • کارکنوں کی تعداد۔
  • بنیادی درستگی میٹرکس۔

  آخری نقطہ "کاروبار"، "کاروبار" میٹرک ہے۔ اگر آپ ایک ہی چیز کی نگرانی کرنا چاہتے ہیں، تو آپ کو ایک یا دو میٹرکس کی وضاحت کرنے کی ضرورت ہے جو آپ کے لیے اہم اشارے ہیں۔ ہمارا میٹرک تھرو پٹ ہے (یہ کامیاب ٹرانزیکشنز کی تعداد کا مجموعی لین دین کے بہاؤ کا تناسب ہے)۔ اگر اس میں 5-10-15 منٹ کے وقفے سے کوئی چیز تبدیل ہوتی ہے، تو اس کا مطلب ہے کہ ہمیں مسائل ہیں (اگر یہ یکسر بدل جائے)۔

  یہ ہمارے لیے کیسا لگتا ہے ہمارے بورڈز میں سے ایک کی مثال ہے:

  
  
  بائیں جانب 6 گراف ہیں، یہ لائنوں کے مطابق ہے - کارکنوں کی تعداد اور قطاروں میں موجود پیغامات کی تعداد۔ دائیں طرف - آر پی ایس، آر ٹی ایس۔ ذیل میں وہی "بزنس" میٹرک ہے۔ اور "بزنس" میٹرک میں ہم فوری طور پر دیکھ سکتے ہیں کہ دو درمیانی گراف میں کچھ غلط ہو گیا ہے... یہ صرف ایک اور نظام ہے جو ہمارے پیچھے کھڑا ہے جو گر گیا ہے۔

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

  
  
  گراف ہمیں دکھاتا ہے کہ ادائیگی کے نظام میں سے ایک نے 3 سیکنڈ میں جواب دینا شروع کر دیا ہے - ہمیں مسائل ہیں۔ مزید یہ کہ جب مسائل شروع ہوں گے تو یہ چیز 20-30 سیکنڈ کے وقفے سے رد عمل ظاہر کرے گی۔

  اور مانیٹرنگ کی غلطیوں کا تیسرا طبقہ جو موجود ہے وہ منطقی نگرانی ہے۔

  سچ پوچھیں تو، میں نہیں جانتا تھا کہ اس سلائیڈ پر کیا کھینچنا ہے، کیونکہ ہم کافی عرصے سے مارکیٹ میں کسی ایسی چیز کی تلاش کر رہے تھے جو ہمارے لیے مناسب ہو۔ ہمیں کچھ نہیں ملا، اس لیے ہمیں خود ہی کرنا پڑا۔

  
  
  منطقی نگرانی سے میرا کیا مطلب ہے؟ ٹھیک ہے، تصور کریں: آپ اپنے آپ کو ایک نظام بناتے ہیں (مثال کے طور پر، ٹنڈر کلون)؛ آپ نے اسے بنایا، اسے لانچ کیا۔ کامیاب مینیجر واسیا پپکن نے اسے اپنے فون پر رکھا، وہاں ایک لڑکی کو دیکھا، اسے پسند کرتا ہے... اور اس طرح لڑکی کے پاس نہیں جاتا - اسی طرح اسی کاروباری مرکز سے سیکیورٹی گارڈ میخائلچ کے پاس جاتا ہے۔ مینیجر نیچے جاتا ہے، اور پھر حیرت سے پوچھتا ہے: "یہ سیکورٹی گارڈ میخائلچ اس کی طرف دیکھ کر اس قدر خوشگوار کیوں مسکراتا ہے؟"

  ایسے حالات میں... ہمارے لیے یہ صورت حال کچھ مختلف لگتی ہے، کیونکہ (میں نے لکھا) یہ شہرت کا نقصان ہے جو بالواسطہ مالی نقصان کا باعث بنتا ہے۔ ہماری صورت حال اس کے برعکس ہے: ہمیں براہ راست مالی نقصانات کا سامنا کرنا پڑ سکتا ہے - مثال کے طور پر، اگر ہم نے ایک ٹرانزیکشن کو کامیاب قرار دیا، لیکن وہ ناکام رہا (یا اس کے برعکس)۔ مجھے اپنا ٹول لکھنا پڑا جو کاروباری اشارے کا استعمال کرتے ہوئے وقت کے ساتھ ساتھ کامیاب ٹرانزیکشنز کی تعداد کو ٹریک کرتا ہے۔ بازار میں کچھ نہیں ملا! یہ بالکل وہی خیال ہے جو میں دینا چاہتا تھا۔ اس قسم کے مسئلے کو حل کرنے کے لیے مارکیٹ میں کچھ نہیں ہے۔

  یہ اس مسئلے کی فوری شناخت کرنے کے بارے میں تھا۔

  تعیناتی کی وجوہات کا تعین کیسے کریں۔

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

  
  
  اگر ہم لاگز کے بارے میں بات کر رہے ہیں (بنیادی وجہ لاگز ہے)، تو ہمارے لاگز کا بڑا حصہ ELK Stack میں ہے - تقریباً ہر ایک کے پاس ایک جیسا ہے۔ کچھ لوگوں کے لئے، یہ ELK میں نہیں ہوسکتا ہے، لیکن اگر آپ گیگا بائٹس میں لاگ لکھتے ہیں، تو جلد یا بدیر آپ ELK پر آجائیں گے۔ ہم انہیں ٹیرا بائٹس میں لکھتے ہیں۔

  
  
  یہاں ایک مسئلہ ہے۔ ہم نے اسے ٹھیک کیا، صارف کے لیے غلطی کو درست کیا، وہاں کیا تھا کھودنا شروع کیا، کبانہ میں چڑھے، وہاں ٹرانزیکشن آئی ڈی درج کی اور اس طرح ایک فٹ کلاتھ ملا (بہت کچھ دکھاتا ہے)۔ اور اس فٹ کلاتھ میں بالکل کچھ بھی واضح نہیں ہے۔ کیوں؟ ہاں، کیونکہ یہ واضح نہیں ہے کہ کون سا حصہ کس کارکن کا ہے، کون سا حصہ کس جز کا ہے۔ اور اس وقت ہم نے محسوس کیا کہ ہمیں ٹریسنگ کی ضرورت ہے - وہی OpenTracing جس کے بارے میں میں نے بات کی تھی۔

  ہم نے ایک سال پہلے یہ سوچا، اپنی توجہ مارکیٹ کی طرف مبذول کرائی، اور وہاں دو ٹولز تھے - "زپکن" اور "جیگر"۔ "جاگر" درحقیقت ایسا ہی ایک نظریاتی وارث ہے، جو "زپکن" کا نظریاتی جانشین ہے۔ زپکن میں سب کچھ اچھا ہے، سوائے اس کے کہ یہ نہیں جانتا کہ کیسے جمع کرنا ہے، یہ نہیں جانتا کہ ٹریس میں لاگز کیسے شامل کیے جائیں، صرف ٹائم ٹریس۔ اور "جیجر" نے اس کی تائید کی۔

  ہم نے "جیجر" کو دیکھا: آپ ایپلی کیشنز کو آلہ بنا سکتے ہیں، آپ Api میں لکھ سکتے ہیں (اس وقت پی ایچ پی کے لیے Api معیار، تاہم، منظور نہیں کیا گیا تھا - یہ ایک سال پہلے کی بات ہے، لیکن اب اس کی منظوری ہو چکی ہے)، لیکن وہاں بالکل کوئی کلائنٹ نہیں تھا. "ٹھیک ہے،" ہم نے سوچا، اور اپنے کلائنٹ کو لکھا۔ ہمیں کیا ملا؟ یہ تقریباً ایسا ہی لگتا ہے:

  
  
  Jaeger میں، ہر پیغام کے لیے اسپین بنائے جاتے ہیں۔ یعنی، جب صارف سسٹم کھولتا ہے، تو اسے ہر آنے والی درخواست کے لیے ایک یا دو بلاکس نظر آتے ہیں (1-2-3 - صارف کی جانب سے آنے والی درخواستوں کی تعداد، بلاکس کی تعداد)۔ صارفین کے لیے آسان بنانے کے لیے، ہم نے لاگز اور ٹائم ٹریس میں ٹیگ شامل کیے ہیں۔ اس کے مطابق، غلطی کی صورت میں، ہماری درخواست لاگ کو مناسب ایرر ٹیگ کے ساتھ نشان زد کرے گی۔ آپ ایرر ٹیگ کے ذریعہ فلٹر کرسکتے ہیں اور صرف اسپین کو دکھایا جائے گا جس میں یہ بلاک خرابی کے ساتھ موجود ہے۔ اگر ہم دورانیہ کو بڑھاتے ہیں تو ایسا لگتا ہے:

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

  اس کے مطابق، چیزیں ہمارے لئے اچھی ہوئی. ہم نے اپنا ایکسٹینشن لکھا اور ہم نے اسے اوپن سورس کیا۔ اگر آپ ٹریسنگ کے ساتھ کام کرنا چاہتے ہیں، اگر آپ پی ایچ پی میں "جیجر" کے ساتھ کام کرنا چاہتے ہیں، تو ہماری توسیع ہے، استعمال میں خوش آمدید، جیسا کہ وہ کہتے ہیں:

  
  
  ہمارے پاس یہ ایکسٹینشن ہے - یہ OpenTracing Api کا کلائنٹ ہے، اسے php-extention کے طور پر بنایا گیا ہے، یعنی آپ کو اسے اسمبل کرکے سسٹم پر انسٹال کرنے کی ضرورت ہوگی۔ ایک سال پہلے کچھ مختلف نہیں تھا۔ اب دوسرے کلائنٹ ہیں جو اجزاء کی طرح ہیں۔ یہاں یہ آپ پر منحصر ہے: یا تو آپ کمپوزر کے ساتھ اجزاء کو پمپ کرتے ہیں، یا آپ ایکسٹینشن کا استعمال کرتے ہیں۔

  کارپوریٹ معیارات

  ہم نے تین احکام کے بارے میں بات کی۔ چوتھا حکم نقطہ نظر کو معیاری بنانا ہے۔ یہ کس بارے میں ہے؟ یہ اس کے بارے میں ہے:

  
  
  یہاں لفظ "کارپوریٹ" کیوں ہے؟ اس لیے نہیں کہ ہم کوئی بڑی یا بیوروکریٹک کمپنی ہیں، نہیں! میں یہاں "کارپوریٹ" کا لفظ اس تناظر میں استعمال کرنا چاہتا تھا کہ ہر کمپنی، ہر پروڈکٹ کے اپنے معیارات ہونے چاہئیں، بشمول آپ۔ ہمارے پاس کیا معیار ہے؟

  
  

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

  ڈاؤن ٹائم کیا سمجھا جاتا ہے؟

  
  
  اس سب کا نتیجہ کیا نکلا؟

  اس سے یہ حقیقت سامنے آئی کہ (ہمیں استحکام کے ساتھ کچھ مسائل درپیش تھے، یہ کلائنٹس یا ہمارے لیے مناسب نہیں تھا) پچھلے 6 مہینوں میں ہمارا استحکام کا انڈیکیٹر 99,97 تھا۔ ہم کہہ سکتے ہیں کہ یہ بہت زیادہ نہیں ہے۔ ہاں، ہمارے پاس کوشش کرنے کے لیے کچھ ہے۔ اس اشارے میں سے، تقریباً نصف استحکام ہے، جیسا کہ یہ ہمارا نہیں، بلکہ ہماری ویب ایپلیکیشن فائر وال کا ہے، جو ہمارے سامنے کھڑا ہے اور بطور سروس استعمال ہوتا ہے، لیکن کلائنٹس کو اس کی کوئی پرواہ نہیں ہے۔

  ہم نے رات کو سونا سیکھا۔ آخرکار! چھ مہینے پہلے ہم نہیں کر سکے۔ اور نتائج کے ساتھ اس نوٹ پر، میں ایک نوٹ بنانا چاہوں گا۔ کل رات ایٹمی ری ایکٹر کے کنٹرول سسٹم کے بارے میں ایک شاندار رپورٹ سامنے آئی۔ اگر اس نظام کو لکھنے والے لوگ مجھے سن سکتے ہیں، تو براہ کرم اس بات کو بھول جائیں کہ میں نے "2% ڈاؤن ٹائم نہیں ہے۔" آپ کے لیے، 2% ڈاؤن ٹائم ہے، چاہے دو منٹ کے لیے!

  بس! آپ کے سوالات۔

  
  

  بیلنسرز اور ڈیٹا بیس کی منتقلی کے بارے میں

  سامعین سے سوال (اس کے بعد - B): - شب بخیر۔ ایسی ایڈمن رپورٹ کے لیے آپ کا بہت شکریہ! آپ کے بیلنسرز کے بارے میں ایک مختصر سوال۔ آپ نے بتایا کہ آپ کے پاس WAF ہے، یعنی جیسا کہ میں سمجھتا ہوں، آپ کسی قسم کا بیرونی بیلنس استعمال کرتے ہیں...

  EK: - نہیں، ہم اپنی خدمات کو بطور بیلنس استعمال کرتے ہیں۔ اس صورت میں، WAF ہمارے لیے خصوصی طور پر ایک DDoS تحفظ کا آلہ ہے۔

  پر: - کیا آپ بیلنسرز کے بارے میں کچھ الفاظ کہہ سکتے ہیں؟

  EK: - جیسا کہ میں پہلے ہی کہہ چکا ہوں، یہ اوپنریسٹی میں سرورز کا ایک گروپ ہے۔ اب ہمارے پاس 5 ریزرو گروپس ہیں جو خصوصی طور پر جواب دیتے ہیں... یعنی، ایک سرور جو خصوصی طور پر کھلے عام چلتا ہے، یہ صرف ٹریفک کو پراکسی کرتا ہے۔ اس کے مطابق، یہ سمجھنے کے لیے کہ ہمارے پاس کتنا ذخیرہ ہے: اب ہمارے پاس کئی سو میگا بٹس کا ٹریفک کا باقاعدہ بہاؤ ہے۔ وہ مقابلہ کرتے ہیں، وہ اچھا محسوس کرتے ہیں، وہ خود کو تنگ بھی نہیں کرتے ہیں۔

  پر: - ایک سادہ سا سوال بھی۔ یہاں بلیو/گرین تعیناتی ہے۔ آپ کیا کرتے ہیں، مثال کے طور پر، ڈیٹا بیس کی منتقلی کے ساتھ؟

  EK: - اچھا سوال! دیکھو، بلیو/گرین تعیناتی میں ہمارے پاس ہر لائن کے لیے الگ الگ قطاریں ہیں۔ یعنی، اگر ہم ایونٹ کی قطاروں کے بارے میں بات کر رہے ہیں جو کارکن سے کارکن تک منتقل ہوتی ہیں، تو بلیو لائن اور گرین لائن کے لیے الگ الگ قطاریں ہیں۔ اگر ہم خود ڈیٹا بیس کے بارے میں بات کر رہے ہیں، تو ہم نے جان بوجھ کر اسے اتنا ہی کم کر دیا جتنا ہم کر سکتے تھے، ہر چیز کو عملی طور پر قطاروں میں منتقل کر دیا؛ ڈیٹا بیس میں ہم صرف لین دین کا ایک اسٹیک رکھتے ہیں۔ اور ہمارا ٹرانزیکشن اسٹیک تمام لائنوں کے لیے یکساں ہے۔ اس تناظر میں ڈیٹا بیس کے ساتھ: ہم اسے نیلے اور سبز میں تقسیم نہیں کرتے ہیں، کیونکہ کوڈ کے دونوں ورژن کو یہ معلوم ہونا چاہیے کہ لین دین کے ساتھ کیا ہو رہا ہے۔

  دوستو، میرے پاس آپ کی حوصلہ افزائی کے لیے ایک چھوٹا سا انعام بھی ہے - ایک کتاب۔ اور مجھے بہترین سوال کے لیے اس سے نوازا جانا چاہیے۔

  پر: - ہیلو. رپورٹ کے لیے شکریہ۔ سوال یہ ہے۔ آپ ادائیگیوں کی نگرانی کرتے ہیں، آپ ان خدمات کی نگرانی کرتے ہیں جن کے ساتھ آپ بات چیت کرتے ہیں... لیکن آپ کیسے نگرانی کرتے ہیں کہ کوئی شخص کسی طرح آپ کے ادائیگی کے صفحے پر آئے، ادائیگی کی، اور پروجیکٹ نے اسے رقم دے دی؟ یعنی، آپ کیسے مانیٹر کرتے ہیں کہ مارچنٹ دستیاب ہے اور اس نے آپ کا کال بیک قبول کر لیا ہے؟

  EK: - اس معاملے میں ہمارے لیے "مرچنٹ" بالکل وہی بیرونی سروس ہے جو ادائیگی کے نظام کی ہے۔ ہم مرچنٹ کے ردعمل کی رفتار کی نگرانی کرتے ہیں۔

  ڈیٹا بیس کی خفیہ کاری کے بارے میں

  پر: - ہیلو. میرے پاس تھوڑا سا متعلقہ سوال ہے۔ آپ کے پاس PCI DSS حساس ڈیٹا ہے۔ میں جاننا چاہتا تھا کہ آپ PAN کو قطاروں میں کیسے محفوظ کرتے ہیں جس میں آپ کو منتقل کرنے کی ضرورت ہے؟ کیا آپ کوئی خفیہ کاری استعمال کرتے ہیں؟ اور اس سے دوسرا سوال پیدا ہوتا ہے: PCI DSS کے مطابق، تبدیلیوں (منتظمین کی برطرفی وغیرہ) کی صورت میں وقتاً فوقتاً ڈیٹا بیس کو دوبارہ انکرپٹ کرنا ضروری ہوتا ہے - اس معاملے میں رسائی کا کیا ہوتا ہے؟

  
  
  EK: - حیرت انگیز سوال! سب سے پہلے، ہم PAN کو قطار میں نہیں رکھتے۔ ہمارے پاس اصولی طور پر PAN کو کہیں بھی واضح شکل میں ذخیرہ کرنے کا حق نہیں ہے، اس لیے ہم ایک خاص سروس استعمال کرتے ہیں (ہم اسے "کیڈیمون" کہتے ہیں) - یہ ایک ایسی سروس ہے جو صرف ایک کام کرتی ہے: یہ ایک پیغام وصول کرتی ہے اور بھیجتی ہے۔ ایک مرموز پیغام باہر. اور ہم اس انکرپٹڈ پیغام کے ساتھ ہر چیز کو اسٹور کرتے ہیں۔ اس کے مطابق، ہماری کلید کی لمبائی ایک کلو بائٹ سے کم ہے، تاکہ یہ سنجیدہ اور قابل اعتماد ہو۔

  پر: - کیا آپ کو اب 2 کلو بائٹس کی ضرورت ہے؟

  EK: - ایسا لگتا ہے جیسے کل ہی 256 تھا... ٹھیک ہے، اور کہاں؟!

  اس کے مطابق، یہ پہلا ہے. اور دوسرا، جو حل موجود ہے، وہ دوبارہ انکرپشن کے طریقہ کار کی حمایت کرتا ہے - "keks" (کیز) کے دو جوڑے ہوتے ہیں، جو "decks" دیتے ہیں جو انکرپٹ ہوتے ہیں (کلید کلیدیں ہیں، ڈیک ان چابیاں کے مشتق ہیں جو خفیہ کرتی ہیں) . اور اگر طریقہ کار شروع کیا جاتا ہے (یہ باقاعدگی سے ہوتا ہے، 3 ماہ سے ± کچھ تک)، ہم "کیک" کا ایک نیا جوڑا ڈاؤن لوڈ کرتے ہیں، اور ہم ڈیٹا کو دوبارہ انکرپٹ کرتے ہیں۔ ہمارے پاس علیحدہ خدمات ہیں جو تمام ڈیٹا کو چیرتی ہیں اور اسے ایک نئے طریقے سے خفیہ کرتی ہیں۔ ڈیٹا کو اس کلید کے شناخت کنندہ کے پاس محفوظ کیا جاتا ہے جس کے ساتھ اسے خفیہ کیا جاتا ہے۔ اس کے مطابق، جیسے ہی ہم ڈیٹا کو نئی کیز کے ساتھ انکرپٹ کرتے ہیں، ہم پرانی کلید کو حذف کر دیتے ہیں۔

  بعض اوقات ادائیگیاں دستی طور پر کرنی پڑتی ہیں...

  پر: – یعنی، اگر کسی آپریشن کے لیے رقم کی واپسی آ گئی ہے، تو کیا آپ اسے اب بھی پرانی کلید سے ڈیکرپٹ کریں گے؟

  EK: - جی ہاں.

  پر: - پھر ایک اور چھوٹا سا سوال۔ جب کسی قسم کی ناکامی، زوال، یا واقعہ پیش آتا ہے، تو ضروری ہے کہ لین دین کو دستی طور پر آگے بڑھایا جائے۔ ایسی صورت حال ہے۔

  EK: - ہاں کبھی کبھی.

  پر: - آپ کو یہ ڈیٹا کہاں سے ملتا ہے؟ یا آپ خود اس اسٹوریج کی سہولت پر جاتے ہیں؟

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

  
  
  پر: - میرے پاس ایک دو سوالات ہیں۔ ان میں سے ایک PCI DSS زون کا تسلسل ہے: آپ ان کے سرکٹ کو کیسے لاگ کرتے ہیں؟ یہ سوال اس لیے ہے کیونکہ ڈویلپر لاگز میں کچھ بھی رکھ سکتا تھا! دوسرا سوال: آپ ہاٹ فکس کو کیسے رول آؤٹ کرتے ہیں؟ ڈیٹا بیس میں ہینڈلز کا استعمال ایک آپشن ہے، لیکن وہاں مفت ہاٹ فکس ہو سکتے ہیں - وہاں کیا طریقہ کار ہے؟ اور تیسرا سوال شاید آر ٹی او، آر پی او سے متعلق ہے۔ آپ کی دستیابی 99,97 تھی، تقریباً چار نائنز، لیکن جیسا کہ میں سمجھتا ہوں، آپ کے پاس دوسرا ڈیٹا سینٹر، تیسرا ڈیٹا سینٹر، اور پانچواں ڈیٹا سینٹر ہے... آپ انہیں کیسے ہم آہنگ کرتے ہیں، ان کی نقل تیار کرتے ہیں، اور باقی سب کچھ؟

  EK: - آئیے پہلے سے شروع کرتے ہیں۔ کیا نوشتہ جات کے بارے میں پہلا سوال تھا؟ جب ہم لاگ لکھتے ہیں، تو ہمارے پاس ایک پرت ہوتی ہے جو تمام حساس ڈیٹا کو ماسک کرتی ہے۔ وہ ماسک اور اضافی فیلڈز کو دیکھتی ہے۔ اس کے مطابق، ہمارے لاگز پہلے سے ماسک شدہ ڈیٹا اور ایک PCI DSS سرکٹ کے ساتھ سامنے آتے ہیں۔ یہ ٹیسٹنگ ڈیپارٹمنٹ کو تفویض کردہ باقاعدہ کاموں میں سے ایک ہے۔ انہیں ہر کام کو چیک کرنے کی ضرورت ہوتی ہے، بشمول وہ لاگز جو وہ لکھتے ہیں، اور یہ کوڈ کے جائزوں کے دوران باقاعدہ کاموں میں سے ایک ہے، تاکہ یہ کنٹرول کیا جا سکے کہ ڈویلپر نے کچھ نہیں لکھا۔ اس کے بعد کے چیک انفارمیشن سیکیورٹی ڈیپارٹمنٹ کے ذریعے ہفتے میں ایک بار باقاعدگی سے کیے جاتے ہیں: آخری دن کے لاگز کو منتخب طور پر لیا جاتا ہے اور ہر چیز کو چیک کرنے کے لیے انہیں ٹیسٹ سرورز سے ایک خصوصی سکینر تجزیہ کار کے ذریعے چلایا جاتا ہے۔
  گرم اصلاحات کے بارے میں۔ یہ ہمارے تعیناتی کے ضوابط میں شامل ہے۔ ہمارے پاس ہاٹ فکس کے بارے میں ایک الگ شق ہے۔ ہمیں یقین ہے کہ جب ہمیں ضرورت ہو ہم چوبیس گھنٹے ہاٹ فکس لگاتے ہیں۔ جیسے ہی ورژن اسمبل ہوتا ہے، جیسے ہی اسے چلایا جاتا ہے، جیسے ہی ہمارے پاس کوئی نمونہ ہوتا ہے، ہمارے پاس سپورٹ کی کال پر ڈیوٹی پر ایک سسٹم ایڈمنسٹریٹر ہوتا ہے، اور وہ اس وقت اسے تعینات کرتا ہے جب یہ ضروری ہوتا ہے۔

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

  پر: - اگر آپ کو دوسرا مل گیا تو آپ کو تیسرا کیوں نہیں ملا؟ کیونکہ ابھی تک کسی کا دماغ تقسیم نہیں ہوا ہے...

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

  پر: - شام بخیر. رپورٹ کے لیے شکریہ۔ آپ نے اپنے ڈیبگر کے بارے میں بات کی، جو پیداوار میں کچھ ٹیسٹ لین دین چلاتا ہے۔ لیکن ہمیں ٹیسٹ لین دین کے بارے میں بتائیں! یہ کتنی گہرائی میں جاتا ہے؟

  EK: - یہ پورے جزو کے پورے چکر سے گزرتا ہے۔ ایک جزو کے لیے، ٹیسٹ ٹرانزیکشن اور پروڈکشن کے درمیان کوئی فرق نہیں ہے۔ لیکن منطقی نقطہ نظر سے، یہ نظام میں صرف ایک الگ پروجیکٹ ہے، جس پر صرف ٹیسٹ ٹرانزیکشنز چلائے جاتے ہیں۔

  پر: - آپ اسے کہاں کاٹتے ہیں؟ یہاں کور بھیجا گیا...

  EK: - ہم ٹیسٹ ٹرانزیکشن کے معاملے میں اس معاملے میں "Kor" کے پیچھے ہیں... ہمارے پاس روٹنگ جیسی چیز ہے: "Kor" جانتا ہے کہ کس ادائیگی کے نظام کو بھیجنا ہے - ہم ایک جعلی ادائیگی کے نظام کو بھیجتے ہیں، جو صرف HTTP سگنل دیتا ہے اور بس اتنا ہی

  پر: - مجھے بتائیں، براہ کرم، کیا آپ کی درخواست ایک بڑی یک سنگی میں لکھی گئی تھی، یا آپ نے اسے کچھ خدمات یا حتیٰ کہ مائیکرو سروسز میں بھی کاٹ دیا تھا؟

  EK: - ہمارے پاس یک سنگی نہیں ہے، یقیناً، ہمارے پاس خدمت پر مبنی درخواست ہے۔ ہم مذاق کرتے ہیں کہ ہماری خدمت یک سنگی سے بنی ہے - وہ واقعی کافی بڑے ہیں۔ اسے مائیکرو سروسز کہنا مشکل ہے، لیکن یہ وہ خدمات ہیں جن میں تقسیم شدہ مشینوں کے کارکن کام کرتے ہیں۔

  اگر سرور پر سروس سے سمجھوتہ کیا گیا ہے...

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

  
  
  EK: - جی ہاں، ضرور. سیکورٹی کے تقاضے کافی سنگین ہیں۔ سب سے پہلے، ہمارے پاس ڈیٹا کی نقل و حرکت کھلی ہے، اور بندرگاہیں صرف وہی ہیں جن کے ذریعے ہم ٹریفک کی نقل و حرکت کا پیشگی اندازہ لگاتے ہیں۔ اگر کوئی جزو ڈیٹابیس کے ساتھ 5-4-3-2 کے ذریعے بات چیت کرتا ہے (کہیں کہ مسکول کے ساتھ)، صرف 5-4-3-2 اس کے لیے کھلا رہے گا، اور دیگر بندرگاہیں اور ٹریفک کی دوسری سمتیں دستیاب نہیں ہوں گی۔ اس کے علاوہ، آپ کو یہ سمجھنے کی ضرورت ہے کہ ہماری پروڈکشن میں تقریباً 10 مختلف سیکیورٹی لوپس ہیں۔ اور یہاں تک کہ اگر ایپلیکیشن میں کسی طرح سمجھوتہ کیا گیا تھا، خدا نہ کرے، حملہ آور سرور مینجمنٹ کنسول تک رسائی حاصل نہیں کر سکے گا، کیونکہ یہ ایک مختلف نیٹ ورک سیکیورٹی زون ہے۔

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

  EK: - میں سمجھتا ہوں. اگر عام صورت حال میں دوسرے سرور کے ساتھ مواصلت کی بالکل اجازت تھی، تو ہاں۔ SLA معاہدے کے مطابق، ہم اس بات کی نگرانی نہیں کرتے ہیں کہ آپ کو صرف پہلے 3 "کارروائیوں" کی اجازت ہے، اور آپ کو 4 "کارروائیوں" کی اجازت نہیں ہے۔ یہ شاید ہمارے لیے بے کار ہے، کیونکہ ہمارے پاس پہلے سے ہی ایک 4 سطحی تحفظ کا نظام ہے، اصولی طور پر، سرکٹس کے لیے۔ ہم اندرونی سطح کی بجائے شکلوں سے اپنا دفاع کرنے کو ترجیح دیتے ہیں۔

  ویزا، ماسٹر کارڈ اور سبر بینک کیسے کام کرتے ہیں۔

  پر: - میں صارف کو ایک ڈیٹا سینٹر سے دوسرے ڈیٹا سینٹر میں تبدیل کرنے کے بارے میں ایک نکتہ واضح کرنا چاہتا ہوں۔ جہاں تک میں جانتا ہوں، ویزا اور ماسٹر کارڈ 8583 بائنری سنکرونس پروٹوکول کا استعمال کرتے ہوئے کام کرتے ہیں، اور وہاں مرکبات موجود ہیں۔ اور میں جاننا چاہتا تھا، اب ہمارا مطلب سوئچنگ ہے - کیا یہ براہ راست "ویزا" اور "ماسٹر کارڈ" ہے یا ادائیگی کے نظام سے پہلے، پروسیسنگ سے پہلے؟

  EK: - یہ اختلاط سے پہلے ہے۔ ہمارے مکس ایک ہی ڈیٹا سینٹر میں واقع ہیں۔

  پر: - موٹے الفاظ میں، کیا آپ کے پاس ایک کنکشن پوائنٹ ہے؟

  EK: - "ویزا" اور "ماسٹر کارڈ" - ہاں۔ محض اس لیے کہ Visa اور MasterCard کو بنیادی ڈھانچے میں کافی سنجیدہ سرمایہ کاری کی ضرورت ہوتی ہے تاکہ مرکب کا دوسرا جوڑا حاصل کیا جا سکے۔ وہ ایک ڈیٹا سینٹر کے اندر محفوظ ہیں، لیکن اگر، خدا نہ کرے، ہمارا ڈیٹا سینٹر، جہاں ویزا اور ماسٹر کارڈ سے جڑنے کے لیے مکس موجود ہیں، مر جائے، تو ہمارا ویزا اور ماسٹر کارڈ سے رابطہ ختم ہو جائے گا...

  پر: - انہیں کیسے محفوظ کیا جا سکتا ہے؟ میں جانتا ہوں کہ ویزا اصولی طور پر صرف ایک کنکشن کی اجازت دیتا ہے!

  EK: - وہ خود سامان فراہم کرتے ہیں۔ کسی بھی صورت میں، ہمیں ایسا سامان ملا ہے جو اندر سے مکمل طور پر بے کار ہے۔

  پر: - تو اسٹینڈ ان کے کنیکٹس اورنج سے ہے؟

  EK: - جی ہاں.

  پر: - لیکن اس معاملے کا کیا ہوگا: اگر آپ کا ڈیٹا سینٹر غائب ہو جاتا ہے، تو آپ اسے کیسے استعمال کرنا جاری رکھ سکتے ہیں؟ یا ٹریفک صرف رک جاتی ہے؟

  EK: - نہیں. اس صورت میں، ہم آسانی سے ٹریفک کو کسی دوسرے چینل پر تبدیل کر دیں گے، جو قدرتی طور پر ہمارے لیے زیادہ مہنگا اور ہمارے کلائنٹس کے لیے زیادہ مہنگا ہو گا۔ لیکن ٹریفک ہمارے براہ راست ویزا، ماسٹر کارڈ سے نہیں بلکہ مشروط Sberbank (بہت مبالغہ آمیز) کے ذریعے نہیں جائے گی۔

  اگر میں نے Sberbank کے ملازمین کو ناراض کیا ہے تو میں بے حد معذرت خواہ ہوں۔ لیکن ہمارے اعداد و شمار کے مطابق، روسی بینکوں میں، Sberbank اکثر گرتا ہے. Sberbank میں کچھ گرے بغیر ایک مہینہ بھی نہیں گزرتا۔

  
  
  

  کچھ اشتہارات 🙂

  ہمارے ساتھ رہنے کے لیے آپ کا شکریہ۔ کیا آپ کو ہمارے مضامین پسند ہیں؟ مزید دلچسپ مواد دیکھنا چاہتے ہیں؟ آرڈر دے کر یا دوستوں کو مشورہ دے کر ہمارا ساتھ دیں، کلاؤڈ VPS برائے ڈویلپرز $4.99 سے, انٹری لیول سرورز کا ایک انوکھا اینالاگ، جو ہم نے آپ کے لیے ایجاد کیا تھا: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps کے بارے میں پوری حقیقت $19 سے یا سرور کا اشتراک کیسے کریں؟ (RAID1 اور RAID10 کے ساتھ دستیاب، 24 کور تک اور 40GB DDR4 تک)۔

  ایمسٹرڈیم میں Equinix Tier IV ڈیٹا سینٹر میں Dell R730xd 2 گنا سستا؟ صرف یہاں 2x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 سے نیدرلینڈ میں! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 سے! کے بارے میں پڑھا انفراسٹرکچر کارپوریشن کو کیسے بنایا جائے۔ ڈیل R730xd E5-2650 v4 سرورز کے استعمال کے ساتھ کلاس جس کی مالیت 9000 یورو ہے؟

ماخذ: www.habr.com