اوپر fakapov سیان

سب کے لئے اچھا ہے! 

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

پریامبل

بہت عرصہ پہلے، جب سیان یک سنگی پر مشتمل تھا، اور ابھی تک مائیکرو سروسز کے کوئی اشارے نہیں ملے تھے، ہم نے 3-5 صفحات کی جانچ کرکے وسائل کی دستیابی کی پیمائش کی۔ 

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

سائٹ کے مرکزی صفحات یا ہم کیسے سمجھتے ہیں کہ ہم نے نیچے مارا ہے۔

 
غلطی کی ترجیح کو سمجھنے کے لیے، ہم نے کاروباری فعالیت کے لیے انتہائی اہم سائٹ کے صفحات کی نشاندہی کی ہے۔ ان کا استعمال کرتے ہوئے، ہم کامیاب/ناکام درخواستوں اور ٹائم آؤٹ کی تعداد گنتے ہیں۔ اس طرح ہم اپ ٹائم کی پیمائش کرتے ہیں۔ 

ہم کہتے ہیں کہ ہمیں پتہ چلا کہ سائٹ کے بہت سے انتہائی اہم حصے ہیں جو مرکزی خدمت کے ذمہ دار ہیں - اشتہارات تلاش کرنا اور جمع کرنا۔ اگر ناکام ہونے والی درخواستوں کی تعداد 1% سے زیادہ ہے، تو یہ ایک اہم واقعہ ہے۔ اگر پرائم ٹائم کے دوران 15 منٹ کے اندر غلطی کی شرح 0,1% سے تجاوز کر جائے تو اسے بھی ایک نازک واقعہ سمجھا جاتا ہے۔ یہ معیار زیادہ تر واقعات کا احاطہ کرتے ہیں؛ باقی اس مضمون کے دائرہ کار سے باہر ہیں۔

سب سے اوپر بہترین واقعات سیان

لہذا، ہم نے یقینی طور پر اس حقیقت کا تعین کرنا سیکھا ہے کہ ایک واقعہ پیش آیا۔ 

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

اگر آپ گزشتہ چند سالوں کی تمام ناکامیوں کو جمع کرتے ہیں، تو رہنما یہ ہیں: 

• mssql سے متعلق واقعات؛
• بیرونی عوامل کی وجہ سے واقعات؛
• منتظم کی غلطیاں

آئیے منتظمین کی غلطیوں کے ساتھ ساتھ کچھ دوسری دلچسپ ناکامیوں کو مزید تفصیل سے دیکھتے ہیں۔

پانچویں جگہ - "DNS میں چیزوں کو ترتیب دینا"

یہ ایک طوفانی منگل تھا۔ ہم نے DNS کلسٹر میں آرڈر بحال کرنے کا فیصلہ کیا۔ 

میں اندرونی ڈی این ایس سرورز کو بائنڈ سے پاور ڈی این ایس میں منتقل کرنا چاہتا تھا، اس کے لیے مکمل طور پر الگ سرور مختص کرتے ہوئے، جہاں ڈی این ایس کے علاوہ کچھ نہیں ہے۔ 

ہم نے اپنے DCs کے ہر مقام پر ایک DNS سرور رکھا، اور وہ لمحہ آیا کہ زونز کو بائنڈ سے پاور ڈی این ایس میں منتقل کیا جائے اور انفراسٹرکچر کو نئے سرورز میں تبدیل کیا جائے۔ 

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

نتیجہ:

اگر پہلے ہم کام کی تیاری کے دوران بیرونی عوامل کو نظر انداز کرتے تھے تو اب وہ بھی اس فہرست میں شامل ہیں جن کی ہم تیاری کر رہے ہیں۔ اور اب ہم اس بات کو یقینی بنانے کی کوشش کرتے ہیں کہ تمام اجزاء n-2 محفوظ ہیں، اور کام کے دوران ہم اس سطح کو n-1 تک کم کر سکتے ہیں۔

• ایکشن پلان تیار کرتے وقت، ان پوائنٹس کو نشان زد کریں جہاں سروس ناکام ہو سکتی ہے، اور ایک ایسے منظر نامے کے بارے میں سوچیں جہاں سب کچھ پہلے سے "خراب سے بدتر" ہو گیا ہو۔
• اندرونی DNS سرورز کو مختلف جغرافیائی مقامات/ڈیٹا سینٹرز/ریک/سوئچز/ان پٹ پر تقسیم کریں۔
• ہر سرور پر، ایک مقامی کیشنگ DNS سرور انسٹال کریں، جو درخواستوں کو مرکزی DNS سرورز کو بھیجتا ہے، اور اگر یہ دستیاب نہیں ہے، تو یہ کیش سے جواب دے گا۔ 

چوتھا مقام - "نگینکس میں چیزوں کی صفائی"

ایک اچھے دن، ہماری ٹیم نے فیصلہ کیا کہ "ہمارے پاس یہ کافی ہے" اور nginx configs کو ری فیکٹر کرنے کا عمل شروع ہوا۔ بنیادی مقصد کنفیگس کو ایک بدیہی ڈھانچے میں لانا ہے۔ پہلے، سب کچھ "تاریخی طور پر قائم" تھا اور اس میں کوئی منطق نہیں تھی۔ اب ہر سرور_نام کو اسی نام کی فائل میں منتقل کر دیا گیا ہے اور تمام کنفیگرز کو فولڈرز میں تقسیم کر دیا گیا ہے۔ ویسے، تشکیل 253949 لائنوں یا 7836520 حروف پر مشتمل ہے اور تقریباً 7 میگا بائٹس لیتی ہے۔ ساخت کی اعلی سطح: 

Nginx ڈھانچہ

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

یہ بہت بہتر ہو گیا، لیکن کنفیگرز کا نام تبدیل کرنے اور تقسیم کرنے کے عمل میں، ان میں سے کچھ کی توسیع غلط تھی اور ان کو include *.conf ہدایت میں شامل نہیں کیا گیا تھا۔ نتیجے کے طور پر، کچھ میزبان غیر دستیاب ہو گئے اور 301 واپس مرکزی صفحہ پر آ گئے۔ اس حقیقت کی وجہ سے کہ رسپانس کوڈ 5xx/4xx نہیں تھا، اس کا فوری طور پر نوٹس نہیں لیا گیا، بلکہ صرف صبح ہی دیکھا گیا۔ اس کے بعد، ہم نے بنیادی ڈھانچے کے اجزاء کو جانچنے کے لیے ٹیسٹ لکھنا شروع کیا۔

نتیجہ: 

• اپنی تشکیلات کو صحیح طریقے سے تشکیل دیں (صرف nginx نہیں) اور پروجیکٹ کے ابتدائی مرحلے میں ساخت کے بارے میں سوچیں۔ اس طرح آپ انہیں ٹیم کے لیے زیادہ قابل فہم بنائیں گے، جس کے نتیجے میں TTM کم ہو جائے گا۔
• کچھ بنیادی ڈھانچے کے اجزاء کے لیے ٹیسٹ لکھیں۔ مثال کے طور پر: یہ چیک کرنا کہ تمام کلیدی سرور_نام درست حیثیت + رسپانس باڈی دیتے ہیں۔ یہ کافی ہوگا کہ ہاتھ میں صرف چند اسکرپٹ ہوں جو جزو کے بنیادی افعال کو چیک کرتی ہیں، تاکہ صبح 3 بجے تک یہ یاد نہ رہے کہ اور کیا چیک کرنے کی ضرورت ہے۔ 

تیسرا مقام - "کیسینڈرا میں اچانک جگہ ختم ہوگئی"

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

ایک طوفانی دن جھرمٹ تقریباً کدو میں بدل گیا، یعنی:

• کلسٹر میں کل جگہ کا تقریباً 20% رہ گیا تھا۔
• نوڈس کو مکمل طور پر شامل کرنا ناممکن ہے، کیونکہ پارٹیشنز پر جگہ کی کمی کی وجہ سے نوڈ شامل کرنے کے بعد صفائی نہیں ہوتی۔
• پیداواری صلاحیت بتدریج گرتی ہے کیونکہ کمپیکشن کام نہیں کرتا ہے۔ 
• کلسٹر ہنگامی حالت میں ہے۔

باہر نکلیں - ہم نے بغیر صفائی کے مزید 5 نوڈس شامل کیے، جس کے بعد ہم نے انہیں منظم طریقے سے کلسٹر سے ہٹانا اور ان کو دوبارہ داخل کرنا شروع کیا، جیسے خالی نوڈس جن کی جگہ ختم ہو گئی تھی۔ ہماری خواہش سے کہیں زیادہ وقت صرف ہوا۔ کلسٹر کی جزوی یا مکمل عدم دستیابی کا خطرہ تھا۔ 

نتیجہ:

• تمام کیسینڈرا سرورز پر، ہر پارٹیشن پر 60% سے زیادہ جگہ پر قبضہ نہیں کیا جانا چاہیے۔ 
• انہیں 50% سی پی یو سے زیادہ نہیں لوڈ کیا جانا چاہئے۔
• آپ کو صلاحیت کی منصوبہ بندی کے بارے میں نہیں بھولنا چاہیے اور ہر ایک جز کے لیے اس کی تفصیلات کی بنیاد پر سوچنے کی ضرورت ہے۔
• کلسٹر میں جتنے زیادہ نوڈس ہوں گے، اتنا ہی بہتر ہے۔ بہت کم ڈیٹا پر مشتمل سرورز تیزی سے اوورلوڈ ہو جاتے ہیں اور ایسے کلسٹر کو بحال کرنا آسان ہوتا ہے۔ 

دوسری جگہ - "کونسل کی ویلیو اسٹوریج سے ڈیٹا غائب ہو گیا"

سروس کی دریافت کے لیے، ہم، بہت سے لوگوں کی طرح، قونصل کا استعمال کرتے ہیں۔ لیکن ہم اس کی کلیدی قدر کو یک سنگی کے نیلے سبز لے آؤٹ کے لیے بھی استعمال کرتے ہیں۔ یہ فعال اور غیر فعال upstreams کے بارے میں معلومات کو ذخیرہ کرتا ہے، جو تعیناتی کے دوران جگہوں کو تبدیل کرتے ہیں۔ اس مقصد کے لیے، ایک تعیناتی سروس لکھی گئی جس نے KV کے ساتھ بات چیت کی۔ کسی وقت، KV سے ڈیٹا غائب ہو گیا۔ میموری سے بحال کیا گیا، لیکن کئی غلطیوں کے ساتھ۔ نتیجے کے طور پر، اپ لوڈ کے دوران، اپ اسٹریمز پر لوڈ غیر مساوی طور پر تقسیم کیا گیا، اور ہمیں CPU پر بیک اینڈز کے اوور لوڈ ہونے کی وجہ سے بہت سی 502 غلطیاں موصول ہوئیں۔ نتیجے کے طور پر، ہم قونصل KV سے پوسٹگریس میں چلے گئے، جہاں سے اب انہیں ہٹانا اتنا آسان نہیں رہا۔  

نتیجہ:

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

پہلی جگہ - "کیپٹن غیر واضح" 

کسی وقت، ہم نے ایسے معاملات میں nginx upstreams پر بوجھ کی غیر مساوی تقسیم کو دیکھا جہاں بیک اینڈ میں 10+ سرورز تھے۔ اس حقیقت کی وجہ سے کہ راؤنڈ رابن نے ترتیب سے پہلی سے آخری اپ اسٹریم تک درخواستیں بھیجی تھیں، اور ہر nginx دوبارہ لوڈ شروع ہوا، پہلی اپ اسٹریم کو ہمیشہ باقی کی نسبت زیادہ درخواستیں موصول ہوئیں۔ نتیجے کے طور پر، انہوں نے سست کام کیا اور پوری سائٹ کو نقصان پہنچا۔ ٹریفک کی مقدار بڑھنے کے ساتھ یہ بات تیزی سے نمایاں ہوتی گئی۔ بے ترتیب کو فعال کرنے کے لیے بس nginx کو اپ ڈیٹ کرنے سے کام نہیں ہوا - ہمیں lua کوڈ کے ایک گروپ کو دوبارہ کرنے کی ضرورت ہے جو ورژن 1 (اس وقت) پر نہیں آیا تھا۔ ہمیں اپنے nginx 1.15 کو پیچ کرنا تھا، اس میں بے ترتیب سپورٹ متعارف کرانا تھا۔ اس سے مسئلہ حل ہوگیا۔ یہ بگ "کیپٹن غیر واضح" زمرہ جیتتا ہے۔

نتیجہ:

اس مسئلے کو دریافت کرنا بہت دلچسپ اور پرجوش تھا)۔ 

• اپنی نگرانی کو منظم کریں تاکہ اس سے آپ کو اس طرح کے اتار چڑھاو کو تیزی سے تلاش کرنے میں مدد ملے۔ مثال کے طور پر، آپ ELK کا استعمال ہر اپ اسٹریم کے ہر بیک اینڈ پر rps کی نگرانی کے لیے کر سکتے ہیں، nginx کے نقطہ نظر سے ان کے ردعمل کے وقت کی نگرانی کر سکتے ہیں۔ اس معاملے میں، اس نے ہمیں مسئلہ کی نشاندہی کرنے میں مدد کی۔ 

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

ماخذ: www.habr.com