آپ کو کیسا لگے گا اگر گرمیوں کے ایک اچھے دن آپ کے آلات کے ساتھ ڈیٹا سینٹر ایسا نظر آئے؟
سب کو سلام! میرا نام دمتری سامسونوف ہے، میں ایک سرکردہ سسٹم ایڈمنسٹریٹر کے طور پر کام کرتا ہوں "" تصویر ان چار ڈیٹا سینٹرز میں سے ایک کو دکھاتی ہے جہاں ہمارے پروجیکٹ کو پیش کرنے والے آلات نصب ہیں۔ ان دیواروں کے پیچھے سامان کے تقریباً 4 ہزار ٹکڑے ہیں: سرورز، ڈیٹا اسٹوریج سسٹم، نیٹ ورک کا سامان وغیرہ۔ - ہمارے تمام آلات کا تقریباً ⅓۔
زیادہ تر سرور لینکس ہیں۔ ونڈوز (MS SQL) پر کئی درجن سرورز بھی ہیں - ہمارا ورثہ، جسے ہم کئی سالوں سے منظم طریقے سے ترک کر رہے ہیں۔
لہذا، 5 جون 2019 کو 14:35 پر، ہمارے ایک ڈیٹا سینٹر کے انجینئرز نے فائر الارم کی اطلاع دی۔
بات چیت
14:45۔ ڈیٹا سینٹرز میں دھوئیں کے معمولی واقعات آپ کے خیال سے زیادہ عام ہیں۔ ہالوں کے اندر اشارے نارمل تھے، اس لیے ہمارا پہلا ردعمل نسبتاً پرسکون تھا: انھوں نے پروڈکشن کے ساتھ کام کرنے پر پابندی متعارف کرائی، یعنی کسی بھی ترتیب میں تبدیلی، نئے ورژن وغیرہ کو رول آؤٹ کرنے پر، سوائے کسی چیز کو ٹھیک کرنے سے متعلق کام کے۔
غصہ
کیا آپ نے کبھی فائر فائٹرز سے یہ معلوم کرنے کی کوشش کی ہے کہ چھت پر آگ کہاں لگی ہے، یا صورتحال کا اندازہ لگانے کے لیے خود جلتی ہوئی چھت پر جا کر دیکھا ہے؟ پانچ لوگوں کے ذریعے موصول ہونے والی معلومات پر اعتماد کا درجہ کیا ہوگا؟
14: 50. اطلاع ملی ہے کہ آگ کولنگ سسٹم کے قریب پہنچ رہی ہے۔. لیکن کیا یہ آئے گا؟ ڈیوٹی پر موجود سسٹم ایڈمنسٹریٹر اس ڈیٹا سینٹر کے محاذوں سے بیرونی ٹریفک کو ہٹاتا ہے۔
اس وقت، ہماری تمام سروسز کے فرنٹ تین ڈیٹا سینٹرز میں ڈپلیکیٹ کیے گئے ہیں، ڈی این ایس لیول پر بیلنسنگ کا استعمال کیا جاتا ہے، جو ہمیں ڈی این ایس سے ایک ڈیٹا سینٹر کے پتے کو ہٹانے کی اجازت دیتا ہے، اس طرح صارفین کو خدمات تک رسائی کے ممکنہ مسائل سے محفوظ رکھا جاتا ہے۔ . اگر ڈیٹا سینٹر میں پہلے ہی مسائل پیدا ہو چکے ہیں، تو یہ خود بخود گردش کو چھوڑ دیتا ہے۔ آپ یہاں مزید پڑھ سکتے ہیں:
آگ نے ابھی تک ہمیں کسی بھی طرح سے متاثر نہیں کیا ہے - نہ ہی صارفین اور نہ ہی سامان کو نقصان پہنچا ہے۔ کیا یہ حادثہ ہے؟ دستاویز کا پہلا حصہ "حادثہ ایکشن پلان" "حادثہ" کے تصور کی وضاحت کرتا ہے، اور سیکشن اس طرح ختم ہوتا ہے:
«اگر کوئی شک ہو کہ حادثہ ہوا ہے یا نہیں تو وہ حادثہ ہے!»
14:53. ایک ایمرجنسی کوآرڈینیٹر مقرر کیا گیا ہے۔
کوآرڈینیٹر وہ شخص ہوتا ہے جو تمام شرکاء کے درمیان رابطے کو کنٹرول کرتا ہے، حادثے کے پیمانے کا اندازہ لگاتا ہے، ایمرجنسی ایکشن پلان کا استعمال کرتا ہے، ضروری اہلکاروں کو متوجہ کرتا ہے، مرمت کی تکمیل کی نگرانی کرتا ہے، اور سب سے اہم بات یہ ہے کہ کسی بھی کام کو تفویض کرتا ہے۔ دوسرے الفاظ میں، یہ وہ شخص ہے جو ہنگامی ردعمل کے پورے عمل کا انتظام کرتا ہے۔
سودے بازی
15:01۔ ہم ان سرورز کو غیر فعال کرنا شروع کر دیتے ہیں جو پیداوار سے متعلق نہیں ہیں۔
15:03۔ ہم تمام محفوظ خدمات کو صحیح طریقے سے بند کر دیتے ہیں۔
اس میں نہ صرف محاذ (جن تک اس وقت تک صارفین رسائی نہیں رکھتے) اور ان کی معاون خدمات (کاروباری منطق، کیشز وغیرہ) شامل ہیں، بلکہ نقل کے عنصر 2 یا اس سے زیادہ کے ساتھ مختلف ڈیٹا بیس بھی شامل ہیں۔, , , وغیرہ)۔
15: 06. اطلاعات موصول ہوئی ہیں کہ ڈیٹا سینٹر کے ایک ہال میں آگ لگنے کا خطرہ ہے۔ ہمارے پاس اس کمرے میں سامان نہیں ہے، لیکن حقیقت یہ ہے کہ آگ چھت سے ہالوں تک پھیل سکتی ہے جو کچھ ہو رہا ہے اس کی تصویر بہت بدل جاتی ہے۔
(بعد میں پتہ چلا کہ ہال کو کوئی جسمانی خطرہ نہیں تھا، کیونکہ اسے چھت سے ہرمیٹک طور پر سیل کیا گیا تھا۔ خطرہ صرف اس ہال کے کولنگ سسٹم کو تھا۔)
15:07 ہم سرورز پر بغیر کسی اضافی چیک کے تیز رفتار موڈ میں کمانڈ پر عمل درآمد کی اجازت دیتے ہیں ().
15:08۔ ہالوں میں درجہ حرارت معمول کی حد کے اندر ہے۔
15: 12. ہالوں میں درجہ حرارت میں اضافہ ریکارڈ کیا گیا۔
15:13. ڈیٹا سینٹر میں آدھے سے زیادہ سرورز بند ہیں۔ آئیے جاری رکھیں۔
15:16. تمام آلات بند کرنے کا فیصلہ کیا گیا۔
15:21۔ ہم ایپلیکیشن اور آپریٹنگ سسٹم کو صحیح طریقے سے بند کیے بغیر اسٹیٹ لیس سرورز کی بجلی بند کرنا شروع کر دیتے ہیں۔
15:23۔ ایم ایس ایس کیو ایل کے ذمہ دار لوگوں کا ایک گروپ مختص کیا گیا ہے (ان میں سے بہت کم ہیں، ان پر خدمات کا انحصار بہت زیادہ نہیں ہے، لیکن فعالیت کو بحال کرنے کے طریقہ کار میں زیادہ وقت لگتا ہے اور مثال کے طور پر کیسنڈرا سے زیادہ پیچیدہ ہے)۔
ڈپریشن
15: 25. 16 میں سے چار ہالز (نمبر 6، 7، 8، 9) میں بجلی بند ہونے کی اطلاع موصول ہوئی۔ ہمارا سامان ہال 7 اور 8 میں واقع ہے۔ ہمارے دو ہالوں (نمبر 1 اور 3) کے بارے میں کوئی معلومات نہیں ہیں۔
عام طور پر، آگ لگنے کے دوران، بجلی کی فراہمی فوری طور پر بند کردی جاتی ہے، لیکن اس معاملے میں، فائر فائٹرز اور ڈیٹا سینٹر کے تکنیکی عملے کے مربوط کام کی بدولت، اسے ہر جگہ بند نہیں کیا گیا اور فوری طور پر نہیں، بلکہ ضرورت کے مطابق۔
(بعد میں پتہ چلا کہ ہال 8 اور 9 میں بجلی بند نہیں کی گئی تھی۔)
15:28۔ ہم MS SQL ڈیٹا بیس کو دوسرے ڈیٹا سینٹرز میں بیک اپ سے تعینات کرنا شروع کر رہے ہیں۔
یہ کتنی دیر تک لے جائے گا؟ کیا پورے راستے کے لیے نیٹ ورک کی کافی گنجائش ہے؟
15: 37. نیٹ ورک کے کچھ حصوں کی بندش ریکارڈ کی گئی۔
مینجمنٹ اور پروڈکشن نیٹ ورک جسمانی طور پر ایک دوسرے سے الگ تھلگ ہیں۔ اگر پروڈکشن نیٹ ورک دستیاب ہے، تو آپ سرور پر جا سکتے ہیں، ایپلیکیشن کو روک سکتے ہیں اور OS کو آف کر سکتے ہیں۔ اگر یہ دستیاب نہیں ہے، تو آپ IPMI کے ذریعے لاگ ان کر سکتے ہیں، ایپلیکیشن کو روک سکتے ہیں اور OS کو بند کر سکتے ہیں۔ اگر نیٹ ورکس میں سے کوئی نہیں ہے، تو آپ کچھ نہیں کر سکتے۔ "شکریہ، کیپ!"، آپ سوچیں گے.
"اور عام طور پر، بہت زیادہ ہنگامہ آرائی ہے،" آپ بھی سوچ سکتے ہیں۔
بات یہ ہے کہ سرورز، آگ کے بغیر بھی، بہت زیادہ گرمی پیدا کرتے ہیں۔ زیادہ واضح طور پر، جب ٹھنڈک ہوتی ہے، تو وہ گرمی پیدا کرتے ہیں، اور جب ٹھنڈک نہیں ہوتی ہے، تو وہ ایک جہنمی آگ پیدا کرتے ہیں، جو بہترین طور پر، سامان کا کچھ حصہ پگھلا کر دوسرا حصہ بند کر دیتا ہے، اور بدترین طور پر... ہال کے اندر آگ، جو تقریباً ہر چیز کو تباہ کرنے کی ضمانت ہے۔
15:39. ہم conf ڈیٹا بیس کے ساتھ مسائل حل کرتے ہیں۔
conf ڈیٹا بیس اسی نام کی سروس کے لیے بیک اینڈ ہے، جسے تمام پروڈکشن ایپلی کیشنز تیزی سے سیٹنگز کو تبدیل کرنے کے لیے استعمال کرتی ہیں۔ اس بنیاد کے بغیر، ہم پورٹل کے آپریشن کو کنٹرول نہیں کر سکتے، لیکن پورٹل خود کام کر سکتا ہے۔
15:41۔ کور نیٹ ورک کے آلات پر درجہ حرارت کے سینسر زیادہ سے زیادہ قابل اجازت کے قریب ریڈنگ ریکارڈ کرتے ہیں۔ یہ ایک ایسا باکس ہے جو پورے ریک پر قابض ہے اور ڈیٹا سینٹر کے اندر موجود تمام نیٹ ورکس کے آپریشن کو یقینی بناتا ہے۔
15:42۔ ایشو ٹریکر اور ویکی دستیاب نہیں ہیں، اسٹینڈ بائی پر سوئچ کریں۔
یہ پیداوار نہیں ہے، لیکن حادثے کی صورت میں، کسی بھی علم کی بنیاد کی دستیابی اہم ہوسکتی ہے.
15:50۔ مانیٹرنگ سسٹم میں سے ایک بند ہو گیا ہے۔
ان میں سے کئی ہیں، اور وہ خدمات کے مختلف پہلوؤں کے ذمہ دار ہیں۔ ان میں سے کچھ کو ہر ڈیٹا سینٹر کے اندر خود مختار طور پر کام کرنے کے لیے ترتیب دیا گیا ہے (یعنی وہ صرف اپنے ڈیٹا سینٹر کی نگرانی کرتے ہیں)، دیگر تقسیم شدہ اجزاء پر مشتمل ہوتے ہیں جو کسی بھی ڈیٹا سینٹر کے نقصان سے شفاف طریقے سے بچ جاتے ہیں۔
اس صورت میں اس نے کام کرنا چھوڑ دیا۔ ، جو ماسٹر اسٹینڈ بائی موڈ میں کام کرتا ہے۔ اسٹینڈ بائی پر سوئچ کر دیا گیا۔
قبولیت
15:51۔ MS SQL کے علاوہ تمام سرورز کو صحیح طریقے سے بند کیے بغیر IPMI کے ذریعے آف کر دیا گیا تھا۔
اگر ضروری ہو تو کیا آپ IPMI کے ذریعے بڑے پیمانے پر سرور مینجمنٹ کے لیے تیار ہیں؟
وہ لمحہ جب ڈیٹا سینٹر میں آلات کی بچاؤ اس مرحلے پر مکمل ہو جاتی ہے۔ جو کچھ کیا جا سکتا تھا وہ ہو چکا ہے۔ کچھ ساتھی آرام کر سکتے ہیں۔
16: 13. اطلاعات موصول ہوئی ہیں کہ ایئر کنڈیشنرز کے فریون پائپ چھت پر پھٹ گئے - اس سے آگ بجھانے کے بعد ڈیٹا سینٹر کے آغاز میں تاخیر ہوگی۔
16:19. ڈیٹا سینٹر کے تکنیکی عملے سے موصول ہونے والے اعداد و شمار کے مطابق ہالز میں درجہ حرارت میں اضافہ رک گیا ہے۔
17:10۔ conf ڈیٹا بیس کو بحال کر دیا گیا ہے۔ اب ہم ایپلیکیشن کی ترتیبات کو تبدیل کر سکتے ہیں۔
یہ اتنا اہم کیوں ہے اگر سب کچھ غلطی سے روادار ہے اور ایک ڈیٹا سینٹر کے بغیر بھی کام کرتا ہے؟
سب سے پہلے، ہر چیز غلطی برداشت نہیں ہے. مختلف ثانوی خدمات ہیں جو ابھی تک ڈیٹا سینٹر کی ناکامی سے اچھی طرح سے نہیں بچ پائی ہیں، اور ماسٹر اسٹینڈ بائی موڈ میں ڈیٹا بیس موجود ہیں۔ ترتیبات کو منظم کرنے کی صلاحیت آپ کو مشکل حالات میں بھی صارفین پر کسی حادثے کے نتائج کے اثرات کو کم کرنے کے لیے ہر ضروری کام کرنے کی اجازت دیتی ہے۔
دوم، یہ واضح ہو گیا کہ ڈیٹا سینٹر کا آپریشن آنے والے گھنٹوں میں مکمل طور پر بحال نہیں ہو گا، اس لیے اس بات کو یقینی بنانے کے لیے اقدامات کرنے کی ضرورت تھی کہ نقل کی طویل مدتی عدم دستیابی اضافی پریشانیوں کا باعث نہ بنے جیسے مکمل ڈسک باقی ڈیٹا سینٹرز۔
17:29۔ پیزا کا وقت! ہم لوگوں کو ملازمت دیتے ہیں، روبوٹ نہیں۔
بحالی۔
18:02۔ ہال نمبر 8 (ہمارے)، 9، 10 اور 11 میں درجہ حرارت مستحکم ہو گیا ہے۔ ان میں سے ایک جو آف لائن رہتا ہے (نمبر 7) ہمارے سامان رکھتا ہے، اور وہاں درجہ حرارت مسلسل بڑھتا رہتا ہے۔
18:31۔ انہوں نے ہال نمبر 1 اور 3 میں سامان شروع کرنے کی اجازت دے دی - یہ ہال آگ سے متاثر نہیں ہوئے۔
فی الحال، سرورز ہال نمبر 1، 3، 8 میں شروع کیے جا رہے ہیں، جن کی شروعات انتہائی نازک سے ہوتی ہے۔ تمام چلنے والی خدمات کے درست آپریشن کی جانچ پڑتال کی جاتی ہے۔ ہال نمبر 7 کے مسائل ابھی باقی ہیں۔
18:44. ڈیٹا سینٹر کے تکنیکی عملے نے دریافت کیا کہ کمرہ نمبر 7 میں (جہاں صرف ہمارا سامان موجود ہے) بہت سے سرورز بند نہیں ہیں۔ ہمارے اعداد و شمار کے مطابق، وہاں 26 سرورز آن لائن رہتے ہیں۔ دوسری جانچ کے بعد، ہمیں 58 سرور ملتے ہیں۔
20:18. ڈیٹا سینٹر کے تکنیکی ماہرین دالانوں میں چلنے والی موبائل ڈکٹوں کے ذریعے غیر ایئر کنڈیشنڈ کمرے میں ہوا اڑاتے ہیں۔
23:08۔ پہلے ایڈمن کو گھر بھیج دیا گیا۔ کل کام جاری رکھنے کے لیے کسی کو رات کو سونے کی ضرورت ہے۔ اگلا، ہم کچھ اور ایڈمنز اور ڈویلپرز کو جاری کریں گے۔
02:56. ہم نے ہر وہ چیز لانچ کی جسے لانچ کیا جا سکتا تھا۔ ہم خودکار ٹیسٹوں کا استعمال کرتے ہوئے تمام خدمات کی بہت زیادہ جانچ کرتے ہیں۔
03:02. آخری، 7ویں ہال میں ایئر کنڈیشنگ بحال کر دی گئی ہے۔
03:36. ہم ڈیٹا سینٹر کے محاذوں کو DNS میں گردش میں لائے۔ اس لمحے سے صارف کا ٹریفک آنا شروع ہو جاتا ہے۔
ہم زیادہ تر انتظامی ٹیم کو گھر بھیج رہے ہیں۔ لیکن ہم چند لوگوں کو پیچھے چھوڑتے ہیں۔
چھوٹے سوالات:
سوال: 18:31 سے 02:56 تک کیا ہوا؟
A: "ڈیزاسٹر ایکشن پلان" کے بعد، ہم سب سے اہم خدمات سے شروع کرتے ہوئے، تمام خدمات شروع کرتے ہیں۔ اس صورت میں، چیٹ میں کوآرڈینیٹر ایک مفت ایڈمنسٹریٹر کو سروس جاری کرتا ہے، جو چیک کرتا ہے کہ آیا OS اور ایپلیکیشن شروع ہو گئی ہے، آیا کوئی خرابیاں ہیں، اور آیا اشارے نارمل ہیں۔ لانچ مکمل ہونے کے بعد، وہ چیٹ کو اطلاع دیتا ہے کہ وہ مفت ہے اور اسے کوآرڈینیٹر سے ایک نئی سروس موصول ہوتی ہے۔
ناکام ہارڈ ویئر کی وجہ سے یہ عمل مزید سست ہو جاتا ہے۔ یہاں تک کہ اگر OS کو روکنا اور سرورز کو بند کرنا صحیح طریقے سے چلا گیا ہے، کچھ سرورز ڈسک، میموری، اور چیسس کی اچانک ناکامی کی وجہ سے واپس نہیں آتے ہیں۔ جب بجلی ختم ہوجاتی ہے تو ناکامی کی شرح بڑھ جاتی ہے۔
سوال: آپ سب کچھ ایک ساتھ کیوں نہیں چلا سکتے، اور پھر نگرانی میں جو کچھ سامنے آتا ہے اسے ٹھیک کیوں نہیں کر سکتے؟
ج: سب کچھ آہستہ آہستہ کیا جانا چاہیے، کیونکہ خدمات کے درمیان انحصار ہوتا ہے۔ اور آپ کو نگرانی کا انتظار کیے بغیر، ہر چیز کو فوراً چیک کرنا چاہیے - کیونکہ مسائل کے بگڑنے کا انتظار کیے بغیر، ان سے فوراً نمٹنا بہتر ہے۔
7:40۔ آخری ایڈمن (کوآرڈینیٹر) بستر پر چلا گیا۔ پہلے دن کا کام مکمل ہو چکا ہے۔
8:09. پہلے ڈویلپرز، ڈیٹا سینٹر انجینئرز اور ایڈمنسٹریٹرز (بشمول نئے کوآرڈینیٹر) نے بحالی کا کام شروع کیا۔
09:37. ہم نے ہال نمبر 7 (آخری والا) بلند کرنا شروع کیا۔
اس کے ساتھ ساتھ، ہم اسے بحال کرنا جاری رکھتے ہیں جو دوسرے کمروں میں طے نہیں کیا گیا تھا: ڈسک/میموری/سرور کو تبدیل کرنا، نگرانی میں "جلنے والی" ہر چیز کو ٹھیک کرنا، ماسٹر اسٹینڈ بائی اسکیموں میں کرداروں کو واپس تبدیل کرنا اور دیگر چھوٹی چیزیں، جن میں سے کچھ موجود ہیں۔ اس کے باوجود بہت زیادہ.
17:08۔ ہم پیداوار کے ساتھ تمام باقاعدہ کام کی اجازت دیتے ہیں۔
21:45۔ دوسرے دن کا کام مکمل ہو گیا۔
09:45. آج جمعہ ہے. نگرانی میں ابھی بھی کچھ چھوٹے مسائل ہیں۔ ویک اینڈ آگے ہے، ہر کوئی آرام کرنا چاہتا ہے۔ ہم ہر چیز کی بڑے پیمانے پر مرمت کرتے رہتے ہیں۔ باقاعدہ ایڈمن کے کام جو ملتوی ہو سکتے تھے ملتوی کر دیے گئے۔ کوآرڈینیٹر نیا ہے۔
15:40۔ اچانک ایک اور ڈیٹا سینٹر میں کور نیٹ ورک کا نصف سامان دوبارہ شروع ہو گیا۔ خطرات کو کم کرنے کے لیے محاذوں کو گردش سے باہر لے جایا گیا۔ صارفین پر کوئی اثر نہیں ہے۔ بعد میں پتہ چلا کہ یہ ایک ناقص چیسس تھا۔ کوآرڈینیٹر ایک ساتھ دو حادثات کی مرمت پر کام کر رہا ہے۔
17:17. دوسرے ڈیٹا سینٹر میں نیٹ ورک آپریشن بحال کر دیا گیا ہے، سب کچھ چیک کر لیا گیا ہے۔ ڈیٹا سینٹر کو گردش میں رکھا جاتا ہے۔
18:29۔ تیسرے دن کا کام اور مجموعی طور پر حادثے کے بعد بحالی کا کام مکمل ہو چکا ہے۔
بعد میں
04.04.2013 ، , "ہم جماعتی" -تین دنوں تک پورٹل مکمل یا جزوی طور پر دستیاب نہیں تھا۔ اس پورے وقت کے دوران، مختلف شہروں کے 100 سے زیادہ لوگوں نے، مختلف کمپنیوں سے (بہت شکریہ!)، دور سے اور براہ راست ڈیٹا سینٹرز میں، دستی طور پر اور خودکار طور پر، ہزاروں سرورز کی مرمت کی۔
ہم نے نتیجہ اخذ کیا ہے۔ اسے دوبارہ ہونے سے روکنے کے لیے، ہم نے آج تک وسیع پیمانے پر کام کیا ہے اور جاری رکھے ہوئے ہیں۔
موجودہ حادثے اور 404 کے درمیان بنیادی فرق کیا ہیں؟
- ہمارے پاس "حادثہ ایکشن پلان" ہے۔ ایک سہ ماہی میں، ہم مشقیں کرتے ہیں - ہم ایک ہنگامی صورتحال کا کردار ادا کرتے ہیں، جسے منتظمین کے ایک گروپ کو "ایمرجنسی ایکشن پلان" کا استعمال کرتے ہوئے ختم کرنا چاہیے۔ سرکردہ نظام کے منتظمین باری باری کوآرڈینیٹر کا کردار ادا کرتے ہیں۔
- سہ ماہی، ٹیسٹ موڈ میں، ہم LAN اور WAN نیٹ ورکس کے ذریعے ڈیٹا سینٹرز کو الگ تھلگ کرتے ہیں، جو ہمیں رکاوٹوں کی فوری شناخت کرنے کی اجازت دیتا ہے۔
- کم ٹوٹی ہوئی ڈسکیں، کیونکہ ہم نے معیارات کو سخت کر دیا ہے: کم کام کے اوقات، SMART کے لیے سخت حدیں،
- ہم نے برکلے ڈی بی کو مکمل طور پر ترک کر دیا، ایک پرانا اور غیر مستحکم ڈیٹا بیس جسے سرور کے دوبارہ شروع ہونے کے بعد بحال ہونے میں کافی وقت درکار ہوتا ہے۔
- ہم نے MS SQL والے سرورز کی تعداد کو کم کیا اور باقی پر انحصار کم کیا۔
- ہمارا اپنا ہے۔ جہاں ہم دو سالوں سے تمام خدمات کو فعال طور پر منتقل کر رہے ہیں۔ کلاؤڈ ایپلی کیشن کے ساتھ کام کرنے کے پورے دور کو بہت آسان بنا دیتا ہے، اور کسی حادثے کی صورت میں یہ ایسے منفرد ٹولز فراہم کرتا ہے جیسے:
- ایک کلک میں تمام ایپلی کیشنز کا درست سٹاپ؛
- ناکام سرورز سے ایپلی کیشنز کی آسانی سے منتقلی؛
- خودکار درجہ بندی (سروسز کی ترجیح کے لحاظ سے) پورے ڈیٹا سینٹر کا آغاز۔
اس مضمون میں بیان کردہ حادثہ 404ویں دن کے بعد سب سے بڑا حادثہ تھا۔ یقینا، سب کچھ آسانی سے نہیں چلا گیا. مثال کے طور پر، دوسرے ڈیٹا سینٹر میں آگ سے تباہ شدہ ڈیٹا سینٹر کی عدم دستیابی کے دوران، سرورز میں سے ایک پر ایک ڈسک فیل ہوگئی، یعنی کیسنڈرا کلسٹر میں موجود تین نقلوں میں سے صرف ایک تک رسائی ممکن رہی، یہی وجہ ہے کہ 4,2% موبائل ایپلیکیشن استعمال کرنے والے لاگ ان نہیں ہو سکے۔ ایک ہی وقت میں، پہلے سے منسلک صارفین نے کام کرنا جاری رکھا۔ مجموعی طور پر، حادثے کے نتیجے میں، 30 سے زائد مسائل کی نشاندہی کی گئی تھی - عام کیڑے سے سروس کے فن تعمیر میں کوتاہیوں تک.
لیکن موجودہ حادثے اور 404ویں کے درمیان سب سے اہم فرق یہ ہے کہ جب ہم آگ کے نتائج کو ختم کر رہے تھے، تب بھی صارفین ٹیکسٹ کر رہے تھے اور ویڈیو کالز کر رہے تھے۔ گیمز کھیلے، موسیقی سنی، ایک دوسرے کو تحائف دیے، ویڈیوز دیکھے، ٹی وی سیریز اور ٹی وی چینلز ، اور اس میں بھی سلسلہ بندی کی گئی۔ .
آپ کے حادثات کیسے ہوتے ہیں؟
ماخذ: www.habr.com