اڄ، Bitrix24 سروس ۾ سوين گيگابٽ ٽرئفڪ نه آهي، ۽ نه ئي ان ۾ سرورز جو هڪ وڏو جهاز آهي (جيتوڻيڪ، يقينا، ڪافي موجود آهن). پر ڪيترن ئي گراهڪن لاء اهو ڪمپني ۾ ڪم ڪرڻ لاء مکيه اوزار آهي؛ اهو هڪ حقيقي ڪاروباري-نازڪ ايپليڪيشن آهي. تنهن ڪري، گرڻ جو ڪو طريقو ناهي. ڇا ٿيندو جيڪڏهن حادثو ٿئي ها، پر خدمت "بحال" ايترو جلدي آهي ته ڪو به ڪجهه به محسوس نه ڪيو؟ ۽ ڪم جي معيار ۽ گراهڪن جي تعداد کي وڃائڻ کان سواء ناڪامي کي لاڳو ڪرڻ ڪيئن ممڪن آهي؟ اليگزينڊر ديميدوف، ڊائريڪٽر ڪلائوڊ سروسز تي Bitrix24، اسان جي بلاگ لاءِ ڳالهايو ته ڪيئن رزرويشن سسٽم پيداوار جي وجود جي 7 سالن ۾ ترقي ڪئي آهي.
"اسان شروع ڪيو Bitrix24 هڪ SaaS طور 7 سال اڳ. مکيه مشڪل شايد هيٺ ڏنل هئي: ان کان اڳ عام طور تي SaaS طور تي شروع ڪيو ويو، هي پراڊڪٽ صرف هڪ باڪس ٿيل حل جي شڪل ۾ موجود هو. گراهڪن ان کي اسان کان خريد ڪيو، ان کي انهن جي سرور تي ميزباني ڪيو، هڪ ڪارپوريٽ پورٽل قائم ڪيو - ملازم ڪميونيڪيشن، فائل اسٽوريج، ٽاسڪ مينيجمينٽ، CRM، اهو سڀ ڪجهه لاءِ عام حل. ۽ 2012 تائين، اسان فيصلو ڪيو ته اسان ان کي SaaS طور لانچ ڪرڻ چاهيون ٿا، ان کي پاڻ سنڀالي، غلطي رواداري ۽ اعتبار کي يقيني بڻائي. اسان رستي ۾ تجربو حاصل ڪيو، ڇاڪاڻ ته ان وقت تائين اسان وٽ اهو نه هو - اسان صرف سافٽ ويئر ٺاهيندڙ هئاسين، سروس فراهم ڪندڙ نه.
خدمت شروع ڪرڻ وقت، اسان سمجھيو ته سڀ کان اهم شيء غلطي رواداري، اعتماد ۽ خدمت جي مسلسل دستيابي کي يقيني بڻائڻ آهي، ڇاڪاڻ ته جيڪڏهن توهان وٽ هڪ سادي عام ويب سائيٽ آهي، هڪ اسٽور، مثال طور، ۽ اهو توهان تي پوي ٿو ۽ اتي ويٺي آهي. هڪ ڪلاڪ، صرف توهان کي تڪليف ٿيندي، توهان آرڊر وڃائي ڇڏيو، توهان گراهڪ وڃائي ڇڏيو، پر توهان جي ڪلائنٽ پاڻ لاء، اهو هن لاء تمام نازڪ ناهي. هو پريشان هو، يقينا، پر هو ويو ۽ ان کي ڪنهن ٻئي سائيٽ تي خريد ڪيو. ۽ جيڪڏھن اھو ھڪڙو ايپليڪيشن آھي جنھن تي ڪمپني جي اندر سڀ ڪم، ڪميونيڪيشن، فيصلا ڳنڍيل آھن، پوء سڀ کان وڌيڪ ضروري آھي صارفين جو اعتماد حاصل ڪرڻ، اھو آھي، انھن کي ھيٺ ڪرڻ ۽ گرڻ نه ڏيڻ. ڇاڪاڻ ته سڀ ڪم بند ٿي سگهن ٿا جيڪڏهن اندر جي ڪا شيءِ ڪم نه ڪري.
Bitrix.24 SaaS طور
اسان 2011 ۾ عوامي لانچ کان هڪ سال اڳ پهريون پروٽوٽائپ گڏ ڪيو. اسان ان کي اٽڪل هڪ هفتي ۾ گڏ ڪيو، ان کي ڏٺو، ان کي ڦيرايو - اهو ڪم ڪري رهيو هو. اهو آهي، توهان فارم ۾ وڃي سگهو ٿا، اتي پورٽ جو نالو داخل ڪريو، هڪ نئون پورٽل کلي ويندو، ۽ هڪ صارف جو بنياد ٺاهيو ويندو. اسان ان کي ڏٺو، پراڊڪٽ جو اصولي جائزو ورتو، ان کي ختم ڪيو، ۽ ان کي مڪمل سال تائين سڌارڻ جاري رکيو. ڇاڪاڻ ته اسان وٽ هڪ وڏو ڪم هو: اسان ٻه مختلف ڪوڊ بيسز ٺاهڻ نٿا چاهيون، اسان هڪ الڳ پيڪيج ٿيل پراڊڪٽ کي سپورٽ ڪرڻ نٿا چاهيون، الڳ ڪلائوڊ حل - اسان اهو سڀ ڪجهه هڪ ڪوڊ اندر ڪرڻ چاهيون ٿا.
ان وقت هڪ عام ويب ايپليڪيشن هڪ سرور هوندو هو جنهن تي ڪجهه پي ايڇ پي ڪوڊ هلندو هو، هڪ mysql ڊيٽابيس، فائلون اپلوڊ ڪيون وينديون آهن، دستاويز، تصويرون اپلوڊ فولڊر ۾ رکيل هونديون آهن - خير، اهو سڀ ڪم ڪري ٿو. افسوس، ان کي استعمال ڪندي هڪ نازڪ مستحڪم ويب سروس شروع ڪرڻ ناممڪن آهي. اتي، ورهايل ڪيش سپورٽ نه آهي، ڊيٽابيس جي نقل ڪرڻ جي حمايت نه ڪئي وئي آهي.
اسان گهرجون ترتيب ڏنيون آهن: هي مختلف هنڌن تي واقع هجڻ جي صلاحيت آهي، نقل جي حمايت، ۽ مثالي طور تي مختلف جغرافيائي طور تي ورهايل ڊيٽا سينٽرن ۾ واقع آهي. پيداوار جي منطق کي الڳ ڪريو ۽ حقيقت ۾، ڊيٽا اسٽوريج. متحرڪ طور تي لوڊ جي مطابق ماپ ڪرڻ جي قابل ٿي، ۽ مجموعي طور تي statics برداشت. انهن خيالن مان، حقيقت ۾، پيداوار جي گهرج پيدا ٿي، جنهن کي اسان سال جي دوران بهتر ڪيو. هن عرصي دوران، پليٽ فارم ۾، جيڪو متحد ٿي ويو - باڪس ٿيل حل لاء، اسان جي پنهنجي خدمت لاء - اسان انهن شين جي حمايت ڪئي جيڪا اسان کي گهربل هئي. خود پيداوار جي سطح تي mysql نقل لاءِ سپورٽ: يعني، ڊولپر جيڪو ڪوڊ لکي ٿو اهو نه ٿو سوچي ته هن جون درخواستون ڪيئن ورهايون وينديون، هو اسان جي اي پي آئي استعمال ڪري ٿو، ۽ اسان ڄاڻون ٿا ته ڪيئن صحيح طريقي سان ورهائجي لکڻ ۽ پڙهڻ جي درخواستن کي ماسٽرز جي وچ ۾. ۽ غلام.
اسان مختلف ڪلائوڊ آبجیکٹ اسٽوريج لاءِ پراڊڪٽ ليول تي سپورٽ ڪئي آهي: گوگل اسٽوريج، ايمازون ايس3، پلس سپورٽ اوپن اسٽيڪ سوفٽ لاءِ. تنهن ڪري، اهو اسان لاءِ هڪ خدمت جي طور تي ۽ ڊولپرز لاءِ ٻنهي لاءِ آسان هو جيڪي پيڪيج ٿيل حل سان ڪم ڪن ٿا: جيڪڏهن اهي صرف ڪم لاءِ اسان جو API استعمال ڪن ٿا، اهي اهو نه سوچيندا آهن ته فائل آخرڪار ڪٿي محفوظ ٿيندي، مقامي طور تي فائل سسٽم تي يا. اعتراض فائل اسٽوريج ۾.
نتيجي طور، اسان فوري طور تي فيصلو ڪيو ته اسان سڄي ڊيٽا سينٽر جي سطح تي محفوظ ڪنداسين. 2012 ۾، اسان مڪمل طور تي Amazon AWS تي شروع ڪيو ڇاڪاڻ ته اسان کي اڳ ۾ ئي هن پليٽ فارم سان تجربو هو - اسان جي پنهنجي ويب سائيٽ اتي ميزباني ڪئي وئي هئي. اسان انهي حقيقت ڏانهن متوجه ٿي ويا آهيون ته هر علائقي ۾ Amazon وٽ ڪيترائي دستياب علائقا آهن - حقيقت ۾، (انهن جي اصطلاحن ۾) ڪيترائي ڊيٽا مرڪز جيڪي هڪ ٻئي کان گهٽ يا وڌيڪ آزاد آهن ۽ اسان کي اجازت ڏين ٿا ته هڪ مڪمل ڊيٽا سينٽر جي سطح تي محفوظ رکون: جيڪڏهن اهو اوچتو ناڪام ٿئي ٿو، ڊيٽابيس کي نقل ڪيو ويو آهي ماسٽر-ماسٽر، ويب ايپليڪيشن سرورز کي بيڪ اپ ڪيو ويو آهي، ۽ جامد ڊيٽا کي s3 اعتراض اسٽوريج ڏانهن منتقل ڪيو ويو آهي. لوڊ متوازن آهي - انهي وقت Amazon ايلب طرفان، پر ٿوري دير کان پوء اسان پنهنجي پنهنجي لوڊ بيلنسرز ڏانهن آيا، ڇو ته اسان کي وڌيڪ پيچيده منطق جي ضرورت آهي.
جيڪي چاهيندا هئا، سو ئي حاصل ڪندا هئا...
سڀ بنيادي شيون جيڪي اسان کي يقيني بڻائڻ چاهيون ٿا - خود سرورز جي غلطي رواداري، ويب ايپليڪيشنون، ڊيٽابيس - سڀ ڪجهه سٺو ڪم ڪيو. آسان ترين منظر: جيڪڏهن اسان جي ويب ايپليڪيشنن مان هڪ ناڪام ٿئي ٿي، ته پوء سڀ ڪجهه سادو آهي - اهي توازن کان بند ٿي ويا آهن.
بيلنسر (ان وقت اها ايمازون ايلب هئي) نشان لڳل مشينون جيڪي غير صحت مند طور تي ترتيب کان ٻاهر هيون ۽ انهن تي لوڊ ورهائڻ کي بند ڪري ڇڏيو. Amazon آٽو اسڪيلنگ ڪم ڪيو: جڏهن لوڊ وڌي ويو، نئين مشينون شامل ڪيون ويون آٽو اسڪيلنگ گروپ ۾، لوڊ ورهايو ويو نئين مشينن ۾ - سڀ ڪجهه ٺيڪ هو. اسان جي بيلنسرز سان، منطق تقريبن ساڳيو آهي: جيڪڏهن ايپليڪيشن سرور سان ڪجهه ٿئي ٿي، اسان ان کان درخواستون هٽائي ڇڏيو، انهن مشينن کي اڇلائي، نئين شروع ڪريو ۽ ڪم جاري رکو. اسڪيم سالن کان ٿورو تبديل ٿي چڪو آهي، پر ڪم ڪرڻ جاري آهي: اهو سادو، سمجھڻ وارو آهي، ۽ ان سان ڪو به مشڪلات نه آهي.
اسان سڄي دنيا ۾ ڪم ڪريون ٿا، گراهڪ جي لوڊ چوٽيون مڪمل طور تي مختلف آهن، ۽، هڪ دوستانه انداز ۾، اسان کي ڪنهن به وقت اسان جي سسٽم جي ڪنهن به اجزاء تي ڪجهه خدمت ڪم ڪرڻ جي قابل هوندو - گراهڪن طرفان اڻڄاتل. تنهن ڪري، اسان وٽ اهو موقعو آهي ته ڊيٽابيس کي آپريشن کان بند ڪري، لوڊ کي ٻيهر ورهائي ٻئي ڊيٽا سينٽر ڏانهن.
اهو سڀ ڪيئن ڪم ڪندو آهي؟ - اسان ٽريفڪ کي ڪم ڪندڙ ڊيٽا سينٽر ڏانهن تبديل ڪريون ٿا - جيڪڏهن ڊيٽا سينٽر تي ڪو حادثو ٿئي ٿو، پوء مڪمل طور تي، جيڪڏهن اهو اسان جو منصوبابندي ڪيل ڪم هڪ ڊيٽابيس سان آهي، ته پوء اسان انهن ڪلائنٽ جي خدمت ڪندڙ ٽرئفڪ جو حصو ٻئي ڊيٽا سينٽر ڏانهن تبديل ڪريون ٿا، معطل ڪندي. ان جي نقل. جيڪڏهن ويب ايپليڪيشنن لاءِ نئين مشينن جي ضرورت آهي ڇو ته ٻئي ڊيٽا سينٽر تي لوڊ وڌي ويو آهي، اهي خودڪار طريقي سان شروع ٿينديون. اسان ڪم کي ختم ڪريون ٿا، نقل بحال ڪيو ويو آهي، ۽ اسان سڄو لوڊ واپس آڻينداسين. جيڪڏهن اسان کي سيڪنڊ ڊي سي ۾ ڪجهه ڪم کي آئيني ڪرڻ جي ضرورت آهي، مثال طور، سسٽم اپڊيٽ کي انسٽال ڪريو يا ٻئي ڊيٽابيس ۾ سيٽنگون تبديل ڪريو، پوء، عام طور تي، اسان ساڳئي شيء کي ٻيهر ورجائيندا آهيون، صرف ٻئي طرف. ۽ جيڪڏهن اهو هڪ حادثو آهي، ته پوءِ اسان سڀ ڪجهه ٿورڙي طريقي سان ڪندا آهيون: اسان مانيٽرنگ سسٽم ۾ ايونٽ هينڊلر ميڪانيزم استعمال ڪندا آهيون. جيڪڏهن ڪيترائي چيڪ شروع ڪيا وڃن ۽ صورتحال نازڪ ٿي وڃي ٿي، ته پوءِ اسين هن هينڊلر کي هلائيندا آهيون، هڪ هينڊلر جيڪو هن يا انهي منطق تي عمل ڪري سگهي ٿو. هر ڊيٽابيس لاءِ، اسان بيان ڪريون ٿا ته ڪهڙو سرور ان لاءِ ناڪامي آهي، ۽ ڪٿي ٽريفڪ کي تبديل ڪرڻ جي ضرورت آهي جيڪڏهن اهو دستياب ناهي. تاريخي طور تي، اسان ناگيوس يا ان جي ڪجهه ڪانٽن کي هڪ يا ٻئي شڪل ۾ استعمال ڪندا آهيون. اصولي طور تي، ساڳيو ميڪانيزم تقريبن ڪنهن به نگراني سسٽم ۾ موجود آهي؛ اسان اڃا تائين وڌيڪ پيچيده ڪجھ به استعمال نٿا ڪريون، پر شايد ڪنهن ڏينهن اسان ڪنداسين. ھاڻي مانيٽرنگ غير موجودگي جي ڪري شروع ڪئي وئي آھي ۽ ڪجھھ کي تبديل ڪرڻ جي صلاحيت آھي.
ڇا اسان سڀ ڪجهه محفوظ ڪيو آهي؟
اسان وٽ آمريڪا جا ڪيترائي گراهڪ آهن، ڪيترائي گراهڪ يورپ کان، ڪيترائي گراهڪ جيڪي اوڀر جي ويجهو آهن - جاپان، سنگاپور وغيره. يقينا، گراهڪن جو هڪ وڏو حصو روس ۾ آهي. اهو آهي، ڪم هڪ علائقي ۾ نه آهي. صارفين کي تڪڙو جواب ڏيڻ جي ضرورت آهي، مختلف مقامي قانونن جي تعميل لاء گهرجون آهن، ۽ هر علائقي ۾ اسان ٻه ڊيٽا سينٽر محفوظ ڪريون ٿا، ان سان گڏ ڪجهه اضافي خدمتون آهن، جيڪي ٻيهر، هڪ علائقي جي اندر رکڻ لاء آسان آهن - گراهڪن لاء جيڪي هن علائقي ۾ ڪم ڪري رهيا آهن. REST هينڊلر، اختيار ڏيڻ وارا سرور، اهي مجموعي طور تي ڪلائنٽ جي آپريشن لاءِ گهٽ نازڪ هوندا آهن، توهان انهن کي ٿورڙي قابل قبول دير سان مٽائي سگهو ٿا، پر توهان نه ٿا چاهيو ته ان ويل کي ٻيهر نئين سر ترتيب ڏيو ته انهن جي نگراني ڪيئن ڪجي ۽ ڇا ڪجي. انهن سان. تنهن ڪري، اسان ڪوشش ڪري رهيا آهيون ته موجوده حلن کي وڌ ۾ وڌ استعمال ڪرڻ جي بدران، اضافي شين ۾ ڪجهه قسم جي صلاحيت کي ترقي ڪرڻ جي بدران. ۽ ڪٿي ڪٿي اسان ڊي اين ايس جي سطح تي سوئچنگ کي معمولي طور تي استعمال ڪندا آهيون، ۽ اسان ساڳئي ڊي اين ايس ذريعي سروس جي جانداريء جو اندازو لڳايو. Amazon وٽ هڪ روٽ 53 سروس آهي، پر اهو صرف هڪ DNS ناهي جنهن ۾ توهان داخل ڪري سگهو ٿا ۽ اهو ئي آهي- اهو تمام گهڻو لچڪدار ۽ آسان آهي. ان جي ذريعي توهان جيو ڊسٽريبيوٽڊ سروسز ٺاهي سگهو ٿا جغرافيائي هنڌن سان، جڏهن توهان ان کي استعمال ڪريو ٿا اهو طئي ڪرڻ لاءِ ته ڪلائنٽ ڪٿان آيو آهي ۽ هن کي ڪجهه رڪارڊ ڏيو - ان جي مدد سان توهان ناڪامي تعمير ڪري سگهو ٿا. ساڳيا صحت جا چيڪ روٽ 53 ۾ ترتيب ڏنل آهن، توهان آخري پوائنٽس مقرر ڪريو جيڪي مانيٽر ڪيا وڃن، ميٽرڪ سيٽ ڪريو، سيٽ ڪريو جيڪي پروٽوڪول سروس جي "زندگي" کي طئي ڪرڻ لاء - tcp، http، https؛ چيڪن جي تعدد کي مقرر ڪريو جيڪي اهو طئي ڪن ٿا ته خدمت زنده آهي يا نه. ۽ ڊي اين ايس ۾ ئي توھان بيان ڪندا آھيو ته ڇا پرائمري ھوندو، ثانوي ڪھڙو ھوندو، جيڪڏھن روٽ 53 جي اندر صحت جي چڪاس شروع ٿئي ٿي ته ڪٿي سوئچ ڪجي. اھو سڀ ڪجھ ٻين اوزارن سان ٿي سگھي ٿو، پر اھو ڇو آسان آھي - اسان ان کي سيٽ ڪيو. هڪ ڀيرو مٿي ۽ پوءِ ان بابت نه سوچيو ته اسان ڪيئن چيڪ ڪريون ٿا، اسان ڪيئن سوئچ ڪريون ٿا: هر شيءِ پنهنجو ڪم ڪري ٿي.
پهريون "پر"روٽ 53 پاڻ ڪيئن ۽ ڪهڙي طريقي سان محفوظ ڪجي؟ ڪنهن کي خبر آهي، جيڪڏهن هن کي ڪجهه ٿئي ها؟ خوشقسمتيءَ سان، اسان ڪڏهن به هن ريڪ تي قدم نه رکيو، پر ٻيهر، مون وٽ هڪ ڪهاڻي اڳيان هوندي ته اسان ڇو سوچيو ته اسان کي اڃا به رزرويشن ڪرڻ جي ضرورت آهي. هتي اسان اڳ ۾ ئي پنهنجي لاءِ پٿر رکيا هئا. ڏينهن ۾ ڪيترائي ڀيرا اسان انهن سڀني زونن جو مڪمل اپ لوڊ ڪندا آهيون جيڪي اسان وٽ روٽ 53 ۾ آهن. Amazon's API توهان کي انهن کي آساني سان JSON ۾ موڪلڻ جي اجازت ڏئي ٿو، ۽ اسان وٽ ڪيترائي بيڪ اپ سرور آهن جتي اسان ان کي تبديل ڪريون ٿا، ان کي ترتيبن جي صورت ۾ اپلوڊ ڪريون ٿا، ۽ تقريباً ڳالهائڻ، هڪ بيڪ اپ ترتيب ڏنل آهي. جيڪڏهن ڪجهه ٿئي ٿو، اسان جلدي ڊي اين ايس سيٽنگون ڊيٽا کي وڃائڻ کان سواء دستي طور تي ترتيب ڏئي سگهون ٿا.
ٻيو "پر": هن تصوير ۾ ڇا اڃا تائين محفوظ نه ڪيو ويو آهي؟ پاڻ کي بيلنس ڪندڙ! اسان جي ڪلائنٽ جي ورڇ علائقي جي لحاظ کان تمام سادي ڪئي وئي آهي. اسان وٽ ڊومينز bitrix24.ru, bitrix24.com, .de - ھاڻي 13 مختلف آھن، جيڪي مختلف علائقن ۾ ڪم ڪن ٿا. اسان هيٺ آياسين: هر علائقي جا پنهنجا بيلنس آهن. اهو ان کي وڌيڪ آسان بڻائي ٿو سڀني علائقن ۾ ورهائڻ، ان تي منحصر آهي جتي نيٽ ورڪ تي چوٽي لوڊ آهي. جيڪڏهن اهو هڪ واحد بيلنس جي سطح تي ناڪامي آهي، پوء اهو صرف خدمت مان ڪڍيو ويو آهي ۽ ڊي اين ايس تان هٽايو ويو آهي. جيڪڏهن بيلنسرز جي هڪ گروپ سان ڪجهه مسئلو آهي، ته پوء انهن کي ٻين سائيٽن تي بيڪ اپ ڪيو ويندو آهي، ۽ انهن جي وچ ۾ سوئچنگ ساڳئي رستي 53 استعمال ڪندي ڪيو ويندو آهي، ڇاڪاڻ ته مختصر TTL جي ڪري، سوئچنگ وڌ ۾ وڌ 2، 3، 5 منٽن اندر ٿيندي آهي. .
ٽيون "پر": ڇا اڃا تائين محفوظ نه آهي؟ S3، صحيح. جڏهن اسان اهي فائلون رکيا آهن جيڪي اسان استعمال ڪندڙن لاءِ s3 ۾ محفوظ ڪيون ٿا، اسان خلوص سان يقين ڪيو ته اهو هٿيارن جي ڇنڊڇاڻ آهي ۽ اتي ڪجهه به محفوظ ڪرڻ جي ضرورت ناهي. پر تاريخ ڏيکاري ٿي ته شيون مختلف طرح سان ٿينديون آهن. عام طور تي، Amazon S3 کي هڪ بنيادي خدمت جي طور تي بيان ڪري ٿو، ڇاڪاڻ ته Amazon پاڻ S3 استعمال ڪري ٿو مشين تصويرون، ترتيب، AMI تصويرون، سنيپ شاٽ محفوظ ڪرڻ لاءِ... ۽ جيڪڏهن s3 حادثو ٿئي ٿو، جيئن انهن 7 سالن دوران هڪ ڀيرو ٿيو، جيستائين اسان استعمال ڪري رهيا آهيون. bitrix24، اهو ان جي پيروي ڪري ٿو هڪ پرستار وانگر هتي شين جو هڪ سڄو گروپ آهي جيڪو اچي ٿو - مجازي مشين کي شروع ڪرڻ جي ناڪامي، اي پي آئي ناڪامي، وغيره.
۽ S3 گر ٿي سگهي ٿو - اهو هڪ ڀيرو ٿيو. تنهن ڪري، اسان هيٺ ڏنل اسڪيم تي آيا آهيون: ڪجهه سال اڳ روس ۾ ڪو به سنجيده عوامي شيون اسٽوريج سهولتون نه هيون، ۽ اسان پنهنجو پاڻ کي ڪجهه ڪرڻ جي اختيار تي غور ڪيو ... خوش قسمت، اسان اهو ڪرڻ شروع نه ڪيو، ڇاڪاڻ ته اسان ماهرن ۾ کوٽائي ڪئي آهي جيڪا اسان وٽ ناهي، ۽ شايد خراب ٿي ويندي. ھاڻي Mail.ru وٽ s3-مطابقت رکندڙ اسٽوريج آھي، Yandex وٽ آھي، ۽ ٻيا ڪيترائي مهيا ڪندڙ آھن. اسان آخرڪار اهو خيال آيو ته اسان چاهيون ٿا، پهريون، بيڪ اپ، ۽ ٻيو، مقامي ڪاپي سان ڪم ڪرڻ جي صلاحيت. روسي علائقي لاءِ خاص طور تي، اسان استعمال ڪندا آهيون Mail.ru Hotbox سروس، جيڪا API s3 سان مطابقت رکي ٿي. اسان کي ايپليڪيشن جي اندر ڪوڊ ۾ ڪا وڏي تبديلي جي ضرورت نه هئي، ۽ اسان هيٺ ڏنل ميکانيزم ٺاهيو: s3 ۾ اهڙا محرڪ آهن جيڪي شيون ٺاهڻ / حذف ڪرڻ کي متحرڪ ڪن ٿا، Amazon وٽ Lambda نالي هڪ سروس آهي - هي ڪوڊ جو هڪ سرور کان سواءِ لانچ آهي. اهو صرف تڏهن عمل ڪيو ويندو جڏهن ڪجهه محرڪ شروع ڪيا ويندا.
اسان اهو بلڪل سادو ڪيو: جيڪڏهن اسان جو ٽريگر فائر ٿئي ٿو، اسان ڪوڊ تي عمل ڪريون ٿا جيڪو اعتراض کي نقل ڪندو Mail.ru اسٽوريج ۾. ڊيٽا جي مقامي نقلن سان مڪمل طور تي ڪم شروع ڪرڻ لاءِ، اسان کي ريورس هم وقت سازي جي به ضرورت آهي ته جيئن ڪلائنٽ جيڪي روسي ڀاڱي ۾ آهن اهي اسٽوريج سان ڪم ڪري سگهن جيڪي انهن جي ويجهو آهن. ميل پنهنجي اسٽوريج ۾ ٽريگرز کي مڪمل ڪرڻ وارو آهي - اهو ممڪن ٿيندو ته انفراسٽرڪچر جي سطح تي ريورس هم وقت سازي ڪرڻ، پر هن وقت لاءِ اسان اهو ڪري رهيا آهيون پنهنجي ڪوڊ جي سطح تي. جيڪڏهن اسان ڏسون ٿا ته هڪ ڪلائنٽ هڪ فائل پوسٽ ڪئي آهي، پوء ڪوڊ جي سطح تي اسان واقعي کي قطار ۾ رکون ٿا، ان کي پروسيس ڪريو ۽ ريورس نقل ڪريو. اهو ڇو خراب آهي: جيڪڏهن اسان پنهنجي شين سان ڪنهن قسم جو ڪم اسان جي پيداوار کان ٻاهر ڪريون ٿا، اهو آهي، ڪجهه ٻاهرين ذريعن سان، اسان ان کي حساب ۾ نه وٺنداسين. تنهن ڪري، اسان آخر تائين انتظار ڪندا آهيون، جڏهن ٽرگرز اسٽوريج جي سطح تي ظاهر ٿيندا آهن، تنهنڪري ڪو به فرق ناهي ته اسان ڪوڊ کي ڪٿي به عمل ڪريون، اعتراض جيڪو اسان وٽ آيو آهي، ٻئي طرف نقل ڪيو ويو آهي.
ڪوڊ جي سطح تي، اسان هر ڪلائنٽ لاء ٻنهي اسٽوريج رجسٽرڊ ڪريون ٿا: هڪ کي مکيه سمجهيو ويندو آهي، ٻيو هڪ بيڪ اپ سمجهيو ويندو آهي. جيڪڏهن سڀ ڪجهه ٺيڪ آهي، اسان اسٽوريج سان ڪم ڪندا آهيون جيڪو اسان جي ويجهو آهي: اهو آهي، اسان جا گراهڪ جيڪي Amazon ۾ آهن، اهي S3 سان ڪم ڪن ٿا، ۽ جيڪي روس ۾ ڪم ڪن ٿا، اهي Hotbox سان ڪم ڪن ٿا. جيڪڏھن جھنڊو ھلايو ويندو آھي، ته پوءِ ناڪاميءَ کي ڳنڍيو وڃي، ۽ اسان ڪلائنٽ کي ٻئي اسٽوريج ڏانھن تبديل ڪريون ٿا. اسان هن باڪس کي علائقي جي لحاظ کان آزاد طور تي چيڪ ڪري سگهون ٿا ۽ انهن کي اڳتي ۽ پوئتي تبديل ڪري سگهون ٿا. اسان اڃا تائين عملي طور تي استعمال نه ڪيو آهي، پر اسان هن ميکانيزم لاء مهيا ڪيو آهي ۽ اسان سوچيو ٿا ته ڪنهن ڏينهن اسان کي هن سوئچ جي ضرورت پوندي ۽ ڪم ۾ اچي. اهو اڳ ۾ ئي هڪ ڀيرو ٿي چڪو آهي.
او، ۽ Amazon ڀڄي ويو ...
هي اپريل روس ۾ ٽيليگرام بلاڪنگ جي شروعات جي سالگره جي نشاندهي ڪري ٿو. سڀ کان وڌيڪ متاثر ڪندڙ فراهم ڪندڙ جيڪو هن هيٺ اچي ويو آهي Amazon. ۽، بدقسمتي سان، روسي ڪمپنيون جيڪي سڄي دنيا لاء ڪم ڪيو، وڌيڪ متاثر ٿيا.
جيڪڏهن ڪمپني گلوبل آهي ۽ روس ان لاء هڪ ننڍڙو حصو آهي، 3-5٪ - خير، هڪ طريقو يا ٻيو، توهان انهن کي قربان ڪري سگهو ٿا.
جيڪڏهن هي هڪ خالص روسي ڪمپني آهي - مون کي پڪ آهي ته اهو مقامي طور تي واقع ٿيڻ جي ضرورت آهي - خير، اهو آسان هوندو، صارفين لاء آسان، آرام سان، ۽ گهٽ خطرات هوندا.
ڇا جيڪڏهن اها هڪ ڪمپني آهي جيڪا عالمي سطح تي هلندي آهي ۽ روس ۽ دنيا جي ڪنهن به هنڌ کان تقريبن برابر تعداد ۾ ڪلائنٽ آهن؟ حصن جي رابطي اهم آهي، ۽ انهن کي هڪ ٻئي سان هڪ طريقو يا ٻيو ڪم ڪرڻ گهرجي.
مارچ 2018 جي آخر ۾، Roskomnadzor سڀ کان وڏي آپريٽرز ڏانهن هڪ خط موڪليو جنهن ۾ چيو ويو آهي ته انهن ڪيترن ئي ملين Amazon IPs کي بلاڪ ڪرڻ جي منصوبابندي ڪئي ... Zello ميسينجر کي بلاڪ ڪرڻ لاءِ. انهن ساڳين مهيا ڪندڙن جي مهرباني - انهن ڪاميابي سان هر ڪنهن کي خط لڪي ڇڏيو، ۽ اتي هڪ سمجھ هئي ته ايمازون سان رابطو ڌار ٿي سگهي ٿو. اهو جمعو هو، اسان سرورز.ru کان اسان جي ساٿين ڏانهن گھٻرائجي ويا، چيو: "دوستو، اسان کي ڪيترن ئي سرورن جي ضرورت آهي جيڪي نه روس ۾ واقع هوندا، نه Amazon ۾، پر، مثال طور، ايمسٽرڊيم ۾،" ترتيب ۾. انهي لاءِ ته گهٽ ۾ گهٽ ڪنهن نه ڪنهن طرح اسان جي پنهنجي VPN ۽ پراکسي کي انسٽال ڪرڻ جي قابل ٿي وڃو اتي ڪجهه آخري پوائنٽن لاءِ جن تي اسان ڪنهن به طرح اثرانداز نه ٿي سگهون، مثال طور ساڳي s3 جا آخري پوائنٽس - اسان ڪوشش نٿا ڪري سگهون هڪ نئين سروس کي وڌائڻ ۽ هڪ مختلف ip حاصل ڪرڻ جي، اسان کي اڃا تائين اتي وڃڻو پوندو. صرف چند ڏينهن ۾، اسان انهن سرورن کي سيٽ ڪيو، انهن کي مٿي ڪيو ۽ هلائڻ، ۽، عام طور تي، انهي لمحي لاء تيار ڪيو جڏهن بلاڪنگ شروع ٿي. اهو دلچسپ آهي ته آر ڪي اين، ڪاوڙ ۽ خوفناڪ ڏسندي چيو: "نه، اسان هاڻي ڪجهه به بلاڪ نه ڪنداسين." (پر اهو ان وقت تائين آهي جڏهن ٽيليگرام بلاڪ ٿيڻ شروع ٿيو.) بائي پاس جي صلاحيتون قائم ڪرڻ ۽ اهو محسوس ڪرڻ ته بلاڪنگ متعارف نه ڪئي وئي هئي، تنهن هوندي به، اسان سڄي معاملي کي ترتيب ڏيڻ شروع نه ڪيو. ها، صرف صورت ۾.
۽ 2019 ۾، اسان اڃا تائين بلاڪ جي حالتن ۾ رهندا آهيون. مون گذريل رات ڏٺو: اٽڪل هڪ ملين IPs بلاڪ ٿيڻ جاري آهن. سچ پچ، Amazon تقريبن مڪمل طور تي بلاڪ ڪيو ويو، ان جي چوٽي تي اهو 20 ملين پتي تي پهچي ويو ... عام طور تي، حقيقت اها آهي ته اتي شايد مطابقت، سٺي هم آهنگ نه هجي. اوچتو. اهو فني سببن لاء موجود نه ٿي سگھي ٿو - باهه، کوٽائي ڪندڙ، اهو سڀ ڪجهه. يا، جيئن اسان ڏٺو آهي، مڪمل طور تي ٽيڪنيڪل ناهي. تنهن ڪري، ڪو وڏو ۽ وڏو، انهن جي پنهنجي AS سان، شايد هن کي ٻين طريقن سان منظم ڪري سگهي ٿو - سڌو ڳنڍڻ ۽ ٻيون شيون اڳ ۾ ئي l2 سطح تي آهن. پر هڪ سادي ورزن ۾، اسان وانگر يا ان کان به ننڍو، توهان ڪري سگهو ٿا، صرف ان صورت ۾، سرورز جي سطح تي بيڪارگي ڪنهن ٻئي هنڌ اٿلائي وئي آهي، اڳواٽ ۾ ترتيب ڏنل وي پي اين، پراڪس، انهن حصن ۾ انهن کي ترتيب ڏيڻ کي جلدي تبديل ڪرڻ جي صلاحيت سان. جيڪي توهان جي رابطي لاءِ اهم آهن. اهو اسان لاءِ هڪ کان وڌيڪ ڀيرا ڪم آيو، جڏهن Amazon جي بلاڪنگ شروع ٿي؛ بدترين حالتن ۾، اسان صرف انهن ذريعي S3 ٽرئفڪ جي اجازت ڏني، پر آهستي آهستي اهو سڀ ڪجهه حل ٿي ويو.
ڪيئن محفوظ ڪجي... هڪ مڪمل فراهم ڪندڙ؟
في الحال، اسان وٽ منظر نه آهي ته صورت ۾ سڄي Amazon هيٺ ٿي وڃي. اسان وٽ روس لاءِ به ساڳيو منظر آهي. روس ۾، اسان هڪ مهيا ڪندڙ طرفان ميزباني ڪئي هئي، جنهن مان اسان ڪيترن ئي سائيٽن کي چونڊيو آهي. ۽ هڪ سال اڳ اسان هڪ مسئلي کي منهن ڏنو: جيتوڻيڪ اهي ٻه ڊيٽا مرڪز آهن، شايد اڳ ۾ ئي مسئلا مهيا ڪندڙ جي نيٽ ورڪ ترتيب جي سطح تي هوندا جيڪي اڃا تائين ٻنهي ڊيٽا سينٽرن کي متاثر ڪندا. ۽ اسان ٻنهي سائيٽن تي دستياب نه ٿي سگهون ٿا. يقيناً ائين ئي ٿيو. اسان اندر جي فن تعمير تي ٻيهر غور ڪيو. اهو تمام گهڻو تبديل نه ٿيو آهي، پر روس لاء اسان وٽ هاڻي ٻه سائيٽون آهن، جيڪي هڪ ئي فراهم ڪندڙ کان نه آهن، پر ٻه مختلف آهن. جيڪڏهن هڪ ناڪام ٿيو، اسان ٻئي ڏانهن تبديل ڪري سگهون ٿا.
فرضي طور تي، Amazon لاءِ اسان ٻئي فراهم ڪندڙ جي سطح تي رزرويشن جي امڪان تي غور ڪري رهيا آهيون؛ ٿي سگهي ٿو گوگل، ٿي سگهي ٿو ڪو ٻيو... پر هينئر تائين اسان عملي طور ڏٺو آهي ته جڏهن Amazon تي حادثا ٿين ٿا هڪ دستيابي زون جي سطح تي، حادثا پوري علائقي جي سطح تي تمام گهٽ آهن. تنهن ڪري، اسان وٽ نظرياتي طور تي اهو خيال آهي ته اسان هڪ ٺاهي سگهون ٿا "Amazon نه آهي Amazon" رزرويشن، پر عملي طور تي اهو اڃا تائين نه آهي.
خودڪار جي باري ۾ چند لفظ
ڇا خودڪار هميشه ضروري آهي؟ هتي اهو مناسب آهي ته Dunning-Kruger اثر کي ياد ڪرڻ لاء. "x" محور تي اسان جي ڄاڻ ۽ تجربو آهي جيڪو اسان حاصل ڪندا آهيون، ۽ "y" محور تي اسان جي عملن ۾ اعتماد آهي. پهرين ته اسان کي ڪا به خبر ناهي ۽ نه ئي پڪ آهي. پوءِ اسان ٿورڙي ڄاڻون ٿا ۽ ميگا-اعتماد ٿي وڃون ٿا - هي نام نهاد ”بيوقوفيءَ جي چوٽي“ آهي، جنهن کي تصوير ”ڊيمنشيا ۽ جرئت“ مان چڱيءَ طرح بيان ڪيو آهي. پوءِ اسان ٿورو سکيو آهي ۽ جنگ ۾ وڃڻ لاءِ تيار آهيون. پوءِ اسان ڪجهه ميگا-سنگين غلطين تي قدم رکون ٿا ۽ پاڻ کي نااميدي جي وادي ۾ ڳوليون ٿا، جڏهن اسان کي ڪجهه معلوم ٿئي ٿو، پر حقيقت ۾ اسان گهڻو ڪجهه نٿا ڄاڻون. پوء، جيئن اسان تجربو حاصل ڪندا آهيون، اسان وڌيڪ اعتماد بڻجي ويندا آهيون.
ڪجھ حادثن ۾ مختلف خودڪار سوئچز جي باري ۾ اسان جو منطق تمام سٺو بيان ڪيو ويو آھي ھن گراف ذريعي. اسان شروع ڪيو - اسان کي خبر نه هئي ته ڪجهه ڪيئن ڪجي، تقريبن سڄو ڪم هٿ سان ڪيو ويو. پوءِ اسان محسوس ڪيو ته اسان آٽوميشن کي ھر شيءِ سان ڳنڍي سگھون ٿا ۽، جھڙوڪ، آرام سان ننڊ ڪريو. ۽ اوچتو اسان هڪ ميگا ريڪ تي قدم رکون ٿا: هڪ غلط مثبت حرڪت ڪئي وئي آهي، ۽ اسان ٽرئفڪ کي اڳتي ۽ پوئتي تبديل ڪندا آهيون جڏهن، سٺي طريقي سان، اسان کي اهو نه ڪرڻ گهرجي ها. نتيجتاً، نقل ٽٽي پوي يا ٻيو ڪجهه، اها نااميدي جي وادي آهي. ۽ پوءِ اسان سمجهون ٿا ته اسان کي هر شي کي عقلمندي سان ڏسڻ گهرجي. اهو آهي، اهو خودڪار تي ڀروسو ڪرڻ جو احساس آهي، غلط الارم جي امڪان کي فراهم ڪرڻ. پر! جيڪڏهن نتيجا تباهه ڪندڙ ٿي سگهن ٿا، ته پوء بهتر آهي ته ان کي ڊيوٽي شفٽ تي ڇڏي ڏيو، ڊيوٽي تي انجنيئرن تي، جيڪي يقيني بڻائيندا ۽ مانيٽرنگ ڪندا ته واقعي ڪو حادثو آهي، ۽ ضروري عملن کي هٿي وٺندي ...
ٿڪل
7 سالن جي عرصي دوران، اسان ان حقيقت کان اڳتي نڪري ويا آهيون ته جڏهن ڪجهه ٿي ويو آهي، خوفناڪ خوف هو، اهو سمجهڻ ته مسئلا موجود نه آهن، صرف ڪم آهن، انهن کي حل ڪرڻ گهرجي - ۽ ٿي سگهي ٿو. جڏهن توهان هڪ خدمت ٺاهي رهيا آهيو، ان کي مٿي کان ڏسو، سڀني خطرن جو اندازو لڳايو جيڪو ٿي سگهي ٿو. جيڪڏهن توهان انهن کي فوري طور تي ڏسندا، ته پوءِ اڳواٽ ئي بيڪارگي لاءِ مهيا ڪريو ۽ غلطي برداشت ڪندڙ انفراسٽرڪچر جي تعمير جو امڪان، ڇاڪاڻ ته ڪو به نقطو جيڪو ناڪام ٿي سگهي ٿو ۽ خدمت جي غير فعال ٿيڻ جو سبب بڻجندو، اهو ضرور ڪندو. ۽ جيتوڻيڪ اهو توهان کي لڳي ٿو ته انفراسٹرڪچر جا ڪجهه عناصر ضرور ناڪام نه ٿيندا - ساڳيا S3 وانگر، اڃا به ذهن ۾ رکون ٿا ته اهي ڪري سگهن ٿا. ۽ گهٽ ۾ گهٽ نظريي ۾، هڪ خيال آهي ته توهان انهن سان ڇا ڪندا جيڪڏهن ڪجهه ٿئي. خطري جي انتظام جو منصوبو ٺاهيو. جڏهن توهان سڀ ڪجهه پاڻمرادو يا دستي طور تي ڪرڻ بابت سوچي رهيا آهيو، خطرن جو اندازو لڳايو: ڇا ٿيندو جيڪڏهن آٽوميشن هر شيءِ کي تبديل ڪرڻ شروع ڪري ٿي - ڇا اهو حادثي جي مقابلي ۾ اڃا به وڌيڪ خراب صورتحال ڏانهن نه وٺي ويندو؟ شايد ڪنهن جاءِ تي اهو ضروري آهي ته آٽوميشن جي استعمال ۽ ڊيوٽي تي انجنيئر جي ردعمل جي وچ ۾ هڪ مناسب سمجھوتو استعمال ڪيو وڃي، جيڪو حقيقي تصوير جو جائزو وٺندو ۽ سمجهي سگهندو ته ڇا ڪنهن شيء کي جڳهه تي تبديل ڪرڻ جي ضرورت آهي يا "ها، پر هاڻي نه."
تڪميل ۽ حقيقي ڪوشش جي وچ ۾ هڪ مناسب سمجھوتو، وقت، پئسا جيڪو توهان خرچ ڪري سگهو ٿا ان اسڪيم تي جيڪو توهان وٽ هوندو.
هي متن ڪانفرنس ۾ اليگزينڊر ديميدوف جي رپورٽ جو هڪ تازو ۽ وڌايو ويو نسخو آهي .
جو ذريعو: www.habr.com