کیپٹن اوبیوئس ہمیں بتاتے ہیں کہ گرمیوں میں، خریداری کی سرگرمی اور ویب پروجیکٹس کے بنیادی ڈھانچے میں تبدیلیوں کی شدت دونوں روایتی طور پر کم ہو جاتی ہیں۔ صرف اس لیے کہ یہاں تک کہ آئی ٹی ماہرین بھی کبھی کبھی چھٹیوں پر جاتے ہیں۔ اور CTO بھی۔ یہ ان لوگوں کے لیے زیادہ مشکل ہے جو عہدے پر رہتے ہیں، لیکن اب یہ بات نہیں ہے: شاید اسی لیے موسم گرما میں موجودہ ریزرویشن اسکیم کے بارے میں آہستہ آہستہ سوچنے اور اسے بہتر بنانے کے لیے منصوبہ تیار کرنے کا بہترین وقت ہے۔ اور سے Yegor Andreev کا تجربہ جس کے بارے میں انہوں نے کانفرنس میں بات کی۔ .
بیک اپ سائٹس بناتے وقت آپ کو کئی خرابیاں پڑ سکتی ہیں۔ اور ان میں پھنسنا بالکل ناممکن ہے۔ اور جو چیز ہمیں اس سب میں برباد کرتی ہے، جیسا کہ بہت سی دوسری چیزوں میں، کمال پرستی اور... کاہلی ہے۔ ہم سب کچھ، سب کچھ، سب کچھ بالکل ٹھیک کرنے کی کوشش کر رہے ہیں، لیکن ہمیں اسے مکمل طور پر کرنے کی ضرورت نہیں ہے! آپ کو صرف کچھ چیزیں کرنے کی ضرورت ہے، لیکن انہیں صحیح طریقے سے کریں، انہیں مکمل کریں تاکہ وہ صحیح طریقے سے کام کریں۔
فیل اوور کسی قسم کی پرلطف تفریحی چیز نہیں ہے "ایسا ہو جائے"۔ یہ ایک ایسی چیز ہے جسے بالکل ایک کام کرنا چاہئے - ڈاؤن ٹائم کو کم کریں تاکہ سروس، کمپنی، کم پیسے کھوئے۔ اور ریزرویشن کے تمام طریقوں میں، میں مندرجہ ذیل تناظر میں سوچنے کا مشورہ دیتا ہوں: پیسہ کہاں ہے؟
پہلا جال: جب ہم بڑے، قابل اعتماد نظام بناتے ہیں اور فالتو پن میں مشغول ہوتے ہیں، تو ہم حادثات کی تعداد کو کم کرتے ہیں۔ یہ ایک خوفناک غلط فہمی ہے۔ جب ہم فالتو کام میں مشغول ہوتے ہیں، تو ہم حادثات کی تعداد میں اضافے کا امکان رکھتے ہیں۔ اور اگر ہم سب کچھ ٹھیک کرتے ہیں، تو اجتماعی طور پر ہم ڈاؤن ٹائم کو کم کر دیں گے۔ زیادہ حادثات ہوں گے، لیکن وہ کم لاگت پر ہوں گے۔ ریزرویشن کیا ہے؟ - یہ نظام کی ایک پیچیدگی ہے۔ کوئی بھی پیچیدگی خراب ہے: ہمارے پاس زیادہ کوگ، زیادہ گیئرز، ایک لفظ میں، زیادہ عناصر ہیں - اور اس وجہ سے، خرابی کا زیادہ امکان ہے۔ اور وہ واقعی ٹوٹ جائیں گے۔ اور وہ زیادہ کثرت سے ٹوٹ جائیں گے۔ ایک سادہ مثال: ہم کہتے ہیں کہ ہمارے پاس PHP اور MySQL والی ویب سائٹ ہے۔ اور اسے فوری طور پر محفوظ کرنے کی ضرورت ہے۔
شتوش (c) ہم دوسری سائٹ لیتے ہیں، ایک جیسا نظام بناتے ہیں... پیچیدگی دگنی ہو جاتی ہے - ہمارے پاس دو ادارے ہیں۔ ہم ڈیٹا کو ایک سائٹ سے دوسری سائٹ میں منتقل کرنے کے لیے ایک مخصوص منطق بھی تیار کرتے ہیں - یعنی ڈیٹا کی نقل، جامد ڈیٹا کاپی کرنا، وغیرہ۔ لہذا، نقل کی منطق عام طور پر بہت پیچیدہ ہوتی ہے، اور اس وجہ سے، نظام کی کل پیچیدگی 2 نہیں، بلکہ 3، 5، 10 گنا زیادہ ہوسکتی ہے۔
دوسرا جال: جب ہم واقعی بڑے پیچیدہ نظام بناتے ہیں، تو ہم تصور کرتے ہیں کہ ہم آخر میں کیا حاصل کرنا چاہتے ہیں۔ Voila: ہم ایک انتہائی قابل اعتماد نظام حاصل کرنا چاہتے ہیں جو بغیر کسی وقت کے کام کرے، آدھے سیکنڈ میں (یا اس سے بہتر، فوری طور پر) بدل جائے، اور ہم خوابوں کو سچ کرنا شروع کر دیں۔ لیکن یہاں ایک اہمیت بھی ہے: مطلوبہ سوئچنگ کا وقت جتنا کم ہوگا، سسٹم کی منطق اتنی ہی پیچیدہ ہوتی جائے گی۔ ہمیں اس منطق کو جتنا پیچیدہ بنانا پڑے گا، نظام اتنا ہی زیادہ ٹوٹ جائے گا۔ اور آپ ایک بہت ہی ناخوشگوار صورتحال میں ختم ہو سکتے ہیں: ہم اپنی پوری طاقت سے ڈاؤن ٹائم کو کم کرنے کی کوشش کر رہے ہیں، لیکن درحقیقت ہم ہر چیز کو مزید پیچیدہ بنا رہے ہیں، اور جب کچھ غلط ہو جاتا ہے، تو ڈاؤن ٹائم طویل ہو جائے گا۔ یہاں آپ اکثر اپنے آپ کو یہ سوچتے رہتے ہیں: اچھا... بکنگ نہ کرنا ہی بہتر ہوگا۔ یہ بہتر ہوگا اگر یہ اکیلے اور قابل فہم ڈاون ٹائم کے ساتھ کام کرے۔
آپ اس سے کیسے لڑ سکتے ہیں؟ ہمیں اپنے آپ سے جھوٹ بولنا بند کرنے کی ضرورت ہے، اپنی چاپلوسی کرنا چھوڑ دیں کہ اب ہم یہاں ایک اسپیس شپ بنانے جا رہے ہیں، لیکن یہ سمجھنا چاہیے کہ یہ منصوبہ کب تک جھوٹ بول سکتا ہے۔ اور اس زیادہ سے زیادہ وقت کے لیے، ہم انتخاب کریں گے کہ ہم اصل میں اپنے نظام کی وشوسنییتا کو بڑھانے کے لیے کون سے طریقے استعمال کریں گے۔
یہ وقت ہے "کہانیوں سے"... زندگی سے یقیناً۔
مثال نمبر ایک
N شہر میں پائپ رولنگ پلانٹ نمبر 1 کے لیے بزنس کارڈ کی ویب سائٹ کا تصور کریں۔ اس میں بڑے حروف میں لکھا ہے - PIPE ROLLING PLANT نمبر 1۔ بالکل نیچے نعرہ ہے: "ہمارے پائپ N میں سب سے گول پائپ ہیں۔" اور نیچے سی ای او کا فون نمبر اور اس کا نام ہے۔ ہم سمجھتے ہیں کہ آپ کو بکنگ کروانے کی ضرورت ہے - یہ ایک بہت اہم چیز ہے! آئیے یہ جاننا شروع کرتے ہیں کہ یہ کس چیز پر مشتمل ہے۔ ایچ ٹی ایم ایل سٹیٹکس - یعنی چند تصاویر جہاں جنرل مینیجر درحقیقت اپنے ساتھی کے ساتھ باتھ ہاؤس میں میز پر کسی قسم کے اگلے معاہدے پر بات کر رہے ہیں۔ ہم ڈاؤن ٹائم کے بارے میں سوچنا شروع کر دیتے ہیں۔ یہ ذہن میں آتا ہے: آپ کو وہاں پانچ منٹ تک لیٹنے کی ضرورت ہے، مزید نہیں۔ اور پھر سوال یہ پیدا ہوتا ہے کہ عام طور پر ہماری اس سائٹ سے کتنی فروخت ہوئی؟ کتنا-کتنا؟ "صفر" کا کیا مطلب ہے؟ اور اس کا مطلب ہے: کیونکہ جنرل نے پچھلے سال چاروں لین دین ایک ہی میز پر کیے، انہی لوگوں کے ساتھ جن کے ساتھ وہ غسل خانے جاتے ہیں اور میز پر بیٹھتے ہیں۔ اور ہم سمجھتے ہیں کہ یہاں تک کہ اگر سائٹ ایک دن کے لیے بیٹھ جائے تو کچھ بھی خوفناک نہیں ہوگا۔
تعارفی معلومات کی بنیاد پر، اس کہانی کو بڑھانے کا ایک دن ہے۔ آئیے ایک بے کار اسکیم کے بارے میں سوچنا شروع کریں۔ اور ہم اس مثال کے لیے فالتو پن کی سب سے مثالی اسکیم کا انتخاب کرتے ہیں: ہم فالتو پن کا استعمال نہیں کرتے ہیں۔ یہ سارا معاملہ کوئی بھی ایڈمن آدھے گھنٹے میں سموگ بریک کے ساتھ اٹھا سکتا ہے۔ ایک ویب سرور انسٹال کریں، فائلیں شامل کریں - بس۔ یہ کام کرے گا. آپ کو کسی چیز پر نظر رکھنے کی ضرورت نہیں ہے، آپ کو کسی چیز پر خاص توجہ دینے کی ضرورت نہیں ہے۔ یعنی مثال نمبر ایک سے نتیجہ بالکل واضح ہے: جن خدمات کو محفوظ کرنے کی ضرورت نہیں ہے انہیں محفوظ کرنے کی ضرورت نہیں ہے۔
مثال نمبر دو
کمپنی بلاگ: خصوصی تربیت یافتہ لوگ وہاں خبریں لکھتے ہیں، ہم نے فلاں فلاں نمائش میں حصہ لیا، لیکن ہم نے ایک اور نئی پروڈکٹ جاری کی، وغیرہ۔ ہم کہتے ہیں کہ یہ ورڈپریس کے ساتھ معیاری پی ایچ پی ہے، ایک چھوٹا ڈیٹا بیس اور تھوڑا سا جامد۔ یقینا، یہ بات پھر ذہن میں آتی ہے کہ آپ کو کسی بھی حالت میں لیٹنا نہیں چاہیے - "پانچ منٹ سے زیادہ نہیں!" بس۔ لیکن آئیے مزید سوچتے ہیں۔ یہ بلاگ کیا کرتا ہے؟ لوگ وہاں Yandex سے، Google سے کچھ سوالات کی بنیاد پر، نامیاتی طور پر آتے ہیں۔ زبردست. کیا فروخت کا اس سے کوئی تعلق ہے؟ ایپی فینی: واقعی نہیں۔ ایڈورٹائزنگ ٹریفک مرکزی سائٹ پر جاتی ہے، جو کہ ایک مختلف مشین پر ہوتی ہے۔ آئیے ایک بکنگ اسکیم کے بارے میں سوچنا شروع کریں۔ اچھے طریقے سے، اسے چند گھنٹوں میں اٹھانے کی ضرورت ہے، اور اس کے لیے تیاری کرنا اچھا ہوگا۔ یہ مناسب ہوگا کہ کسی دوسرے ڈیٹا سینٹر سے مشین لیں، اس پر ماحول کو رول کریں، یعنی ایک ویب سرور، پی ایچ پی، ورڈپریس، مائی ایس کیو ایل، اور اسے وہیں چھوڑ دیں۔ اس وقت جب ہم سمجھتے ہیں کہ سب کچھ ٹوٹ گیا ہے، ہمیں دو کام کرنے کی ضرورت ہے - mysql ڈمپ کو 50 میٹر رول آؤٹ کریں، یہ وہاں ایک منٹ میں اڑ جائے گا، اور وہاں کے بیک اپ سے مخصوص تعداد میں تصاویر کو رول آؤٹ کریں گے۔ یہ بھی نہیں خدا جانے کب تک۔ اس طرح آدھے گھنٹے میں سارا معاملہ اٹھ جاتا ہے۔ کوئی نقل نہیں، یا خدا مجھے معاف کردے، خودکار فیل اوور۔ نتیجہ: ہم بیک اپ سے جو کچھ جلدی سے باہر کر سکتے ہیں اسے بیک اپ کرنے کی ضرورت نہیں ہے۔
مثال نمبر تین، زیادہ پیچیدہ
آن لائن سٹور. کھلے دل کے ساتھ پی ایچ پی کو تھوڑا سا ٹویک کیا گیا ہے، ٹھوس بنیاد کے ساتھ mysql۔ کافی جامد (آخر کار، آن لائن سٹور میں خوبصورت HD تصاویر اور وہ تمام چیزیں ہیں)، سیشن کے لیے Redis اور تلاش کے لیے Elasticsearch۔ ہم ڈاؤن ٹائم کے بارے میں سوچنا شروع کر دیتے ہیں۔ اور یہاں، یقیناً، یہ ظاہر ہے کہ ایک آن لائن اسٹور ایک دن کے لیے بھی بغیر درد کے جھوٹ نہیں بول سکتا۔ سب کے بعد، یہ لمبا جھوٹ ہے، زیادہ پیسہ ہم کھو دیتے ہیں. یہ تیز کرنے کے قابل ہے۔ کتنا؟ میرا خیال ہے کہ اگر ہم ایک گھنٹہ لیٹ جائیں تو کوئی پاگل نہیں ہو گا۔ جی ہاں، ہم کچھ کھو دیں گے، لیکن اگر ہم محنت کرنا شروع کر دیں گے، تو یہ اور بھی خراب ہو جائے گا۔ ہم فی گھنٹہ کی اجازت شدہ ڈاؤن ٹائم کی اسکیم کی وضاحت کرتے ہیں۔
یہ سب کیسے محفوظ کیا جا سکتا ہے؟ آپ کو کسی بھی صورت میں ایک کار کی ضرورت ہے: وقت کا ایک گھنٹہ بہت کم ہے۔ Mysql: یہاں ہمیں پہلے سے ہی نقل، براہ راست نقل کی ضرورت ہے، کیونکہ ایک گھنٹے میں 100 GB زیادہ تر ممکنہ طور پر ڈمپ میں شامل نہیں کیا جائے گا۔ اعدادوشمار، تصاویر: دوبارہ، ایک گھنٹے میں 500 جی بی کو شامل کرنے کا وقت نہیں ہو سکتا۔ اس لیے بہتر ہے کہ تصویریں فوراً کاپی کر لیں۔ ریڈیس: یہ وہ جگہ ہے جہاں چیزیں دلچسپ ہوجاتی ہیں۔ Redis میں، سیشنز محفوظ کیے جاتے ہیں - ہم اسے لے کر دفن نہیں کر سکتے۔ کیونکہ یہ بہت اچھا نہیں ہوگا: تمام صارفین لاگ آؤٹ ہو جائیں گے، ان کی ٹوکریاں خالی کر دی جائیں گی، وغیرہ۔ لوگوں کو اپنا صارف نام اور پاس ورڈ دوبارہ درج کرنے پر مجبور کیا جائے گا، اور بہت سے لوگ الگ ہو سکتے ہیں اور خریداری مکمل نہیں کر سکتے۔ ایک بار پھر، تبادلوں میں کمی آئے گی۔ دوسری طرف، Redis براہ راست اپ ٹو ڈیٹ ہے، آخری لاگ ان ہونے والے صارفین کو بھی شاید ضرورت نہیں ہے۔ اور ایک اچھا سمجھوتہ یہ ہے کہ Redis لیں اور اسے کل سے بیک اپ سے بحال کریں، یا، اگر آپ اسے ہر گھنٹے، ایک گھنٹہ پہلے سے کرتے ہیں۔ خوش قسمتی سے، اسے بیک اپ سے بحال کرنے کا مطلب ہے ایک فائل کاپی کرنا۔ اور سب سے دلچسپ کہانی Elasticsearch ہے۔ کس نے کبھی MySQL نقل اٹھایا ہے؟ کس نے کبھی Elasticsearch نقل کو اٹھایا ہے؟ اور اس کے بعد عام طور پر کس کے لیے کام ہوا؟ میرا مطلب یہ ہے کہ ہم اپنے نظام میں ایک خاص ہستی دیکھتے ہیں۔ یہ مفید معلوم ہوتا ہے - لیکن یہ پیچیدہ ہے۔
پیچیدہ اس لحاظ سے کہ ہمارے ساتھی انجینئرز کو اس کے ساتھ کام کرنے کا کوئی تجربہ نہیں ہے۔ یا کوئی منفی تجربہ ہے۔ یا ہم سمجھتے ہیں کہ یہ ابھی بھی کافی نئی ٹیکنالوجی ہے جس میں باریکیاں یا خامیاں ہیں۔ ہم سوچتے ہیں... لات، لچکدار بھی صحت مند ہے، اسے بیک اپ سے بحال کرنے میں بھی کافی وقت لگتا ہے، میں کیا کروں؟ ہم سمجھتے ہیں کہ ہمارے معاملے میں لچکدار تلاش کے لیے استعمال ہوتا ہے۔ ہمارا آن لائن اسٹور کیسے فروخت ہوتا ہے؟ ہم مارکیٹرز کے پاس جاتے ہیں اور پوچھتے ہیں کہ لوگ کہاں سے آتے ہیں۔ وہ جواب دیتے ہیں: "Yandex Market سے 90% براہ راست پروڈکٹ کارڈ پر آتے ہیں۔" اور یا تو وہ خریدتے ہیں یا نہیں کرتے۔ لہذا، 10% صارفین کو تلاش کی ضرورت ہے۔ اور لچکدار نقل کو برقرار رکھنا، خاص طور پر مختلف زونز میں مختلف ڈیٹا سینٹرز کے درمیان، واقعی میں بہت سی باریکیاں ہیں۔ کون سا باہر نکلنا؟ ہم ایک مخصوص سائٹ سے لچکدار لیتے ہیں اور اس کے ساتھ کچھ نہیں کرتے ہیں۔ اگر معاملہ آگے بڑھتا ہے تو ہم شاید کسی دن اسے اٹھائیں گے، لیکن یہ یقینی نہیں ہے۔ اصل میں، نتیجہ ایک ہی ہے، جمع یا مائنس: ہم، دوبارہ، ایسی خدمات محفوظ نہیں کرتے ہیں جو پیسے کو متاثر نہیں کرتی ہیں۔ خاکہ کو آسان رکھنے کے لیے۔
مثال نمبر چار، اور بھی مشکل
انٹیگریٹر: پھول بیچنا، ٹیکسی بلانا، سامان بیچنا، عام طور پر، کچھ بھی۔ ایک سنجیدہ چیز جو صارفین کی ایک بڑی تعداد کے لیے 24/7 کام کرتی ہے۔ ایک مکمل دلچسپ اسٹیک کے ساتھ، جہاں دلچسپ اڈے، حل، زیادہ بوجھ، اور سب سے اہم بات یہ ہے کہ 5 منٹ سے زیادہ لیٹنے میں تکلیف ہوتی ہے۔ نہ صرف اور اتنا ہی نہیں کہ لوگ نہیں خریدیں گے، بلکہ چونکہ لوگ دیکھیں گے کہ یہ چیز کام نہیں کرتی، وہ پریشان ہو جائیں گے اور ہو سکتا ہے واپس نہ آئیں۔
ٹھیک ہے. پانچ منٹ. ہم اس کے بارے میں کیا کرنے جا رہے ہیں؟ اس صورت میں، ہم، بالغوں کی طرح، تمام رقم کو ایک حقیقی بیک اپ سائٹ بنانے کے لیے استعمال کرتے ہیں، ہر چیز کی نقل کے ساتھ، اور حتیٰ کہ اس سائٹ پر خودکار سوئچنگ بھی ممکن حد تک ممکن ہے۔ اور اس کے علاوہ، آپ کو ایک اہم کام کرنا یاد رکھنا ہوگا: دراصل، سوئچنگ کے ضوابط لکھیں۔ ضابطے، چاہے آپ کے پاس سب کچھ خودکار ہو، بہت آسان ہو سکتا ہے۔ سیریز سے "فلاں فلاں اسکرپٹ چلائیں"، "روٹ 53 میں فلاں فلاں چیک باکس پر کلک کریں" اور اسی طرح - لیکن یہ کسی نہ کسی طرح کے اعمال کی قطعی فہرست ہونی چاہیے۔
اور سب کچھ واضح نظر آتا ہے۔ نقل کو تبدیل کرنا ایک معمولی کام ہے، یا یہ خود ہی بدل جائے گا۔ DNS میں ڈومین نام کو دوبارہ لکھنا اسی سیریز سے ہے۔ مصیبت یہ ہے کہ جب ایسا منصوبہ ناکام ہو جاتا ہے تو گھبراہٹ شروع ہو جاتی ہے اور مضبوط ترین داڑھی والے ایڈمن بھی اس کا شکار ہو سکتے ہیں۔ واضح ہدایات کے بغیر "ٹرمینل کھولیں، یہاں آئیں، ہمارے سرور کا پتہ اب بھی ایسا ہی ہے"، بحالی کے لیے مختص 5 منٹ کی وقت کی حد کو پورا کرنا مشکل ہے۔ ٹھیک ہے، اس کے علاوہ، جب ہم ان ضوابط کو استعمال کرتے ہیں، تو انفراسٹرکچر میں کچھ تبدیلیاں ریکارڈ کرنا آسان ہوتا ہے، مثال کے طور پر، اور اس کے مطابق ضوابط کو تبدیل کرنا۔
ٹھیک ہے، اگر ریزرویشن کا نظام بہت پیچیدہ ہے اور کسی موقع پر ہم سے غلطی ہوئی ہے، تو ہم اپنی بیک اپ سائٹ کو تباہ کر سکتے ہیں، اور اس کے علاوہ دونوں سائٹوں پر ڈیٹا کو کدو میں تبدیل کر سکتے ہیں - یہ مکمل طور پر افسوسناک ہوگا۔
مثال نمبر پانچ، مکمل کٹر
دنیا بھر میں کروڑوں صارفین کے ساتھ ایک بین الاقوامی سروس۔ تمام ٹائم زونز ہیں، زیادہ سے زیادہ رفتار سے زیادہ بوجھ، آپ بالکل لیٹ نہیں سکتے۔ ایک منٹ - اور یہ اداس ہو جائے گا. کیا کرنا ہے؟ ریزرو، دوبارہ، مکمل پروگرام کے مطابق. ہم نے وہ سب کچھ کیا جس کے بارے میں میں نے پچھلی مثال میں بات کی تھی، اور کچھ اور۔ ایک مثالی دنیا، اور ہمارا بنیادی ڈھانچہ IaaC devops کے تمام تصورات کے مطابق ہے۔ یعنی، سب کچھ گٹ میں ہے، اور آپ صرف بٹن دبائیں.
کیا غائب ہے؟ ایک - مشقیں. ان کے بغیر یہ ناممکن ہے۔ ایسا لگتا ہے کہ ہمارے ساتھ سب کچھ کامل ہے، ہمارے پاس عام طور پر ہر چیز کنٹرول میں ہے۔ ہم بٹن دباتے ہیں، سب کچھ ہوتا ہے۔ یہاں تک کہ اگر ایسا ہے - اور ہم سمجھتے ہیں کہ ایسا اس طرح نہیں ہوتا ہے - ہمارا نظام کچھ دوسرے نظاموں کے ساتھ تعامل کرتا ہے۔ مثال کے طور پر، یہ روٹ 53، ایس 3 اسٹوریج، کچھ اے پی آئی کے ساتھ انضمام سے ڈی این ایس ہے۔ ہم اس قیاس آرائی کے تجربے میں ہر چیز کا اندازہ نہیں لگا سکیں گے۔ اور جب تک ہم اصل میں سوئچ نہیں کھینچیں گے، ہم نہیں جان پائیں گے کہ یہ کام کرے گا یا نہیں۔
شاید بس اتنا ہی ہے۔ سستی نہ کرو اور نہ ہی اس سے زیادہ کام کرو۔ اور اپ ٹائم آپ کے ساتھ ہو سکتا ہے!
ماخذ: www.habr.com