SRE (Site Reliability Engineering) ویب پروجیکٹس کی دستیابی کو یقینی بنانے کا ایک طریقہ ہے۔ اسے DevOps کے لیے ایک فریم ورک سمجھا جاتا ہے اور اس بارے میں بات کرتا ہے کہ DevOps طریقوں کو لاگو کرنے میں کامیابی کیسے حاصل کی جائے۔ اس مضمون میں ترجمہ کتابیں گوگل سے میں نے یہ ترجمہ خود تیار کیا اور نگرانی کے عمل کو سمجھنے میں اپنے تجربے پر انحصار کیا۔ ٹیلیگرام چینل میں и میں نے خدمت کی سطح کے اہداف کے بارے میں اسی کتاب کے باب 4 کے ترجمہ کا لنک بھی شائع کیا۔
بلی کا ترجمہ۔ پڑھنے سے لطف اندوز!
Google کی SRE ٹیموں کے پاس مانیٹرنگ اور نوٹیفکیشن کے کامیاب نظام بنانے کے لیے بنیادی اصول اور بہترین طریقے ہیں۔ یہ باب رہنمائی فراہم کرتا ہے کہ ویب صفحہ دیکھنے والے کو کن مسائل کا سامنا کرنا پڑ سکتا ہے اور ان مسائل کو کیسے حل کیا جائے جو ویب صفحات کو ڈسپلے کرنا مشکل بنا دیتے ہیں۔
تعریفیں
نگرانی سے متعلق موضوعات پر بات کرنے کے لیے کوئی ایک لفظ استعمال نہیں کیا گیا ہے۔ گوگل پر بھی، ذیل کی اصطلاحات عام طور پر استعمال نہیں کی جاتی ہیں، لیکن ہم سب سے عام تشریحات کی فہرست بنائیں گے۔
نگرانی
نظام کے بارے میں حقیقی وقت میں مقداری ڈیٹا کو جمع کرنا، پروسیسنگ کرنا، جمع کرنا اور ڈسپلے کرنا: درخواستوں کی تعداد اور درخواستوں کی اقسام، غلطیوں کی تعداد اور غلطیوں کی اقسام، درخواست پر کارروائی کا وقت اور سرور اپ ٹائم۔
وائٹ باکس کی نگرانی
اندرونی نظام کے اجزاء کے ذریعہ دکھائے جانے والے میٹرکس پر مبنی نگرانی، بشمول لاگز، جاوا ورچوئل مشین پروفائلنگ میٹرکس، یا HTTP ہینڈلر میٹرکس جو اندرونی اعداد و شمار تیار کرتے ہیں۔
بلیک باکس کی نگرانی
صارف کے نقطہ نظر سے درخواست کے رویے کی جانچ کرنا۔
ڈیش بورڈ
ایک انٹرفیس (عام طور پر ویب) جو خدمات کے کلیدی صحت کے اشاریوں کا جائزہ فراہم کرتا ہے۔ ڈیش بورڈ میں فلٹرز، دکھائے گئے انڈیکیٹرز کو منتخب کرنے کی صلاحیت وغیرہ ہو سکتے ہیں۔ انٹرفیس ان اشاریوں کی شناخت کے لیے ڈیزائن کیا گیا ہے جو صارفین کے لیے سب سے اہم ہیں۔ ڈیش بورڈ تکنیکی معاون عملے کے لیے معلومات بھی ظاہر کر سکتا ہے: درخواستوں کی ایک قطار، اعلی ترجیحی غلطیوں کی فہرست، اور ذمہ داری کے دیئے گئے علاقے کے لیے ایک تفویض کردہ انجینئر۔
الرٹ (اطلاع)
اطلاعات جن کا مقصد کسی شخص کو ای میل یا دیگر ذرائع سے موصول ہونا ہے، جو کہ غلطیوں یا درخواست کی قطار میں اضافے کی وجہ سے ہو سکتا ہے۔ اطلاعات کی درجہ بندی اس طرح کی گئی ہے: ٹکٹس، ای میل الرٹس اور فوری میسنجر کے پیغامات۔
بنیادی وجہ
سافٹ ویئر کی خرابی یا انسانی غلطی جو ایک بار درست ہو جانے کے بعد دوبارہ نہیں ہونی چاہیے۔ مسئلہ کی کئی اہم وجوہات ہو سکتی ہیں: ناکافی عمل آٹومیشن، سافٹ ویئر کی خرابی، ایپلی کیشن منطق کی ناکافی وضاحت۔ ان عوامل میں سے ہر ایک بنیادی وجہ ہو سکتا ہے، اور ان میں سے ہر ایک کو ختم کرنا ضروری ہے۔
نوڈ اور مشین (نوڈ اور مشین)
فزیکل سرور، ورچوئل مشین، یا کنٹینر پر چلنے والی ایپلیکیشن کی ایک مثال کا حوالہ دینے کے لیے قابل تبادلہ اصطلاحات۔ ایک مشین کئی خدمات کی میزبانی کر سکتی ہے۔ خدمات ہو سکتی ہیں:
- ایک دوسرے سے منسلک: مثال کے طور پر، ایک کیشنگ سرور اور ایک ویب سرور؛
- ہارڈ ویئر کے ایک ٹکڑے پر غیر متعلقہ خدمات: مثال کے طور پر، کوڈ ریپوزٹری اور کنفیگریشن سسٹم کے لیے وزرڈ، جیسے یا .
پش
سافٹ ویئر کنفیگریشن میں کوئی تبدیلی۔
نگرانی کی ضرورت کیوں ہے؟
کئی وجوہات ہیں جن کی وجہ سے ایپلی کیشنز کو مانیٹر کرنے کی ضرورت ہے:
طویل مدتی رجحانات کا تجزیہ
ڈیٹا بیس کتنا بڑا ہے اور کتنی تیزی سے بڑھ رہا ہے؟ یومیہ صارفین کی تعداد کیسے بدلتی ہے؟
کارکردگی کا موازنہ
کیا Ajax DB 2.72 کے مقابلے بائٹس 3.14 کی Acme بالٹی پر درخواستیں تیز ہیں؟ ایک اضافی نوڈ کی ظاہری شکل کے بعد درخواستیں کتنی بہتر ہیں؟ کیا سائٹ پچھلے ہفتے کے مقابلے سست چل رہی ہے؟
انتباہ (اطلاعات)
کچھ ٹوٹ گیا ہے اور کسی کو اسے ٹھیک کرنے کی ضرورت ہے۔ یا کچھ جلد ٹوٹ جائے گا اور کسی کو جلد ہی اسے چیک کرنے کی ضرورت ہے۔
ڈیش بورڈز بنانا
ڈیش بورڈز کو بنیادی سوالات کا جواب دینا چاہیے اور اس میں سے کچھ شامل کرنا چاہیے۔ - تاخیر (تاخیر)، ٹریفک (ٹریفک)، غلطیاں (غلطیاں) اور لوڈ سائز (سنترپتی)۔
سابقہ تجزیہ کا انعقاد (ڈیبگنگ)
درخواست پر کارروائی میں تاخیر بڑھ گئی ہے، لیکن اسی وقت اور کیا ہوا؟
نگرانی کے نظام کاروباری انٹیلی جنس سسٹمز کے لیے ڈیٹا کے ایک ذریعہ کے طور پر کارآمد ہوتے ہیں اور سیکیورٹی کے واقعات کے تجزیہ میں سہولت فراہم کرتے ہیں۔ چونکہ یہ کتاب انجینئرنگ کے شعبوں پر توجہ مرکوز کرتی ہے جس میں SREs کو مہارت حاصل ہے، ہم یہاں نگرانی کی تکنیکوں پر بات نہیں کریں گے۔
نگرانی اور انتباہات سسٹم کو آپ کو یہ بتانے کی اجازت دیتے ہیں کہ یہ کب ٹوٹ گیا ہے یا ٹوٹنے والا ہے۔ جب کوئی نظام خود بخود خود کو ٹھیک نہیں کر سکتا، تو ہم چاہتے ہیں کہ انسان الرٹ کا تجزیہ کرے، اس بات کا تعین کرے کہ آیا مسئلہ اب بھی فعال ہے، اسے حل کرے، اور بنیادی وجہ کا تعین کرے۔ اگر آپ سسٹم کے اجزاء کا آڈٹ نہیں کرتے ہیں، تو آپ کو کبھی بھی انتباہ نہیں ملے گا کیونکہ "کچھ تھوڑا سا عجیب لگتا ہے۔"
کسی شخص پر نوٹیفیکیشن کا بوجھ ڈالنا ملازم کے وقت کا کافی مہنگا استعمال ہے۔ اگر ملازم کام کر رہا ہے تو، الرٹ کام کے عمل میں خلل ڈالتا ہے۔ اگر ملازم گھر پر ہے تو، الرٹ ذاتی وقت اور ممکنہ طور پر نیند میں خلل ڈالتا ہے۔ جب انتباہات بہت کثرت سے آتے ہیں، تو ملازمین ان سے چھیڑ چھاڑ کرتے ہیں، انہیں بند کر دیتے ہیں، یا آنے والے انتباہات کو نظر انداز کر دیتے ہیں۔ وقتاً فوقتاً وہ حقیقی الرٹ کو نظر انداز کرتے ہیں، جو شور کے واقعات سے چھپا ہوا ہے۔ سروس کی رکاوٹیں طویل عرصے تک جاری رہ سکتی ہیں کیونکہ شور کے واقعات مسئلے کی فوری تشخیص اور درست ہونے سے روکتے ہیں۔ مؤثر انتباہی نظام میں ایک اچھا سگنل ٹو شور کا تناسب ہوتا ہے۔
نگرانی کے نظام کے لیے معقول توقعات کا تعین کرنا
ایک پیچیدہ ایپلیکیشن کے لیے مانیٹرنگ سیٹ کرنا اپنے آپ میں ایک پیچیدہ انجینئرنگ کام ہے۔ یہاں تک کہ جمع کرنے، ڈسپلے کرنے، اور الرٹ کرنے والے ٹولز کے ایک اہم انفراسٹرکچر کے ساتھ، 10-12 اراکین کی Google SRE ٹیم میں عام طور پر ایک یا دو افراد شامل ہوتے ہیں جن کا بنیادی مقصد نگرانی کے نظام کی تعمیر اور اسے برقرار رکھنا ہے۔ یہ تعداد وقت کے ساتھ ساتھ کم ہوئی ہے کیونکہ ہم نگرانی کے بنیادی ڈھانچے کو مضبوط اور مرکزی بناتے ہیں، لیکن ہر SRE ٹیم میں عام طور پر کم از کم ایک شخص ہوتا ہے جو مکمل طور پر نگرانی کے لیے وقف ہوتا ہے۔ ہمیں یہ کہنا ہے کہ مانیٹرنگ سسٹم کے ڈیش بورڈز کو دیکھنے کے لیے کافی دلچسپ ہیں، لیکن SRE ٹیمیں احتیاط سے ایسے حالات سے گریز کرتی ہیں جن میں کسی کو مسائل کی نگرانی کے لیے اسکرین کو دیکھنے کی ضرورت ہوتی ہے۔
مجموعی طور پر، گوگل حقیقت کے بعد تجزیہ کرنے کے بہترین ٹولز کے ساتھ سادہ اور تیز نگرانی کے نظام کی طرف چلا گیا ہے۔ ہم ایسے "جادو" نظاموں سے گریز کرتے ہیں جو حد کی پیش گوئی کرنے کی کوشش کرتے ہیں یا خود بخود بنیادی وجہ کا پتہ لگاتے ہیں۔ سینسرز جو اختتامی صارف کی درخواستوں میں غیر ارادی مواد کا پتہ لگاتے ہیں وہ واحد جوابی مثال ہیں۔ جب تک یہ سینسرز سادہ رہیں گے، یہ سنگین بے ضابطگیوں کی وجوہات کا فوری پتہ لگا سکتے ہیں۔ مانیٹرنگ ڈیٹا استعمال کرنے کے لیے دیگر فارمیٹس، جیسے کہ صلاحیت کی منصوبہ بندی یا ٹریفک کی پیشن گوئی، زیادہ پیچیدہ ہیں۔ نمونے لینے کی کم شرح (گھنٹوں یا دنوں) پر بہت طویل مدت (مہینوں یا سالوں) کا مشاہدہ ایک طویل مدتی رجحان کو ظاہر کرے گا۔
Google SRE ٹیم کو پیچیدہ انحصاری درجہ بندی کے ساتھ ملی جلی کامیابی ملی ہے۔ ہم شاذ و نادر ہی ایسے اصول استعمال کرتے ہیں جیسے "اگر مجھے پتہ چلتا ہے کہ ڈیٹا بیس سست ہے، مجھے ایک انتباہ ملتا ہے کہ ڈیٹا بیس سست ہے، ورنہ مجھے الرٹ ملتا ہے کہ سائٹ سست ہے۔" انحصار پر مبنی قواعد عام طور پر ہمارے سسٹم کے ناقابل تغیر حصوں کا حوالہ دیتے ہیں، جیسے کہ ڈیٹا سینٹر میں صارف کی ٹریفک کو فلٹر کرنے کا نظام۔ مثال کے طور پر، "اگر ڈیٹا سینٹر میں ٹریفک فلٹرنگ کو کنفیگر کیا گیا ہے، تو مجھے صارف کی درخواستوں پر کارروائی میں تاخیر کے بارے میں آگاہ نہ کریں" ڈیٹا سینٹر کی جانب سے الرٹس کے لیے ایک عمومی اصول ہے۔ Google پر کچھ ٹیمیں پیچیدہ انحصاری درجہ بندی کی حمایت کرتی ہیں کیونکہ ہمارے بنیادی ڈھانچے میں مسلسل ری فیکٹرنگ کی مستقل شرح ہے۔
اس باب میں بیان کیے گئے کچھ خیالات اب بھی متعلقہ ہیں: علامات سے جڑ تک تیزی سے جانے کا موقع ہمیشہ موجود ہوتا ہے، خاص طور پر مسلسل بدلتے ہوئے نظاموں میں۔ اس لیے، جب کہ یہ باب نگرانی کے نظام کے لیے کچھ اہداف اور ان اہداف کو حاصل کرنے کے طریقے بتاتا ہے، یہ ضروری ہے کہ نگرانی کے نظام آسان ہوں اور ٹیم کے ہر فرد کے لیے قابل فہم ہوں۔
اسی طرح، شور کی سطح کو کم رکھنے اور سگنل کی سطح کو بلند رکھنے کے لیے، الرٹ شدہ اثاثوں کی نگرانی کے طریقے بہت آسان اور قابل اعتماد ہونے چاہئیں۔ ایسے قوانین جو لوگوں کے لیے انتباہات پیدا کرتے ہیں ان کو سمجھنا اور واضح مسئلہ پیش کرنا آسان ہونا چاہیے۔
علامات بمقابلہ اسباب
آپ کے مانیٹرنگ سسٹم کو دو سوالوں کا جواب دینا چاہیے: "کیا ٹوٹا" اور "کیوں ٹوٹ گیا۔"
"کیا ٹوٹا" علامت کے بارے میں بات کرتا ہے، اور "یہ کیوں ٹوٹ گیا" وجہ کے بارے میں بات کرتا ہے۔ مندرجہ ذیل جدول اس طرح کے کنکشن کی مثالیں دکھاتا ہے۔
علامت۔
کیونکہ
HTTP ایرر 500 یا 404 حاصل کرنا
ڈیٹا بیس سرور کنکشن کو مسترد کرتے ہیں۔
سست سرور کے جوابات
زیادہ CPU استعمال یا خراب ایتھرنیٹ کیبل
انٹارکٹیکا کے صارفین بلی کے GIFs وصول نہیں کر رہے ہیں۔
آپ کا CDN سائنسدانوں اور بلیوں سے نفرت کرتا ہے، اس لیے کچھ IP پتے بلیک لسٹ ہو گئے۔
پرائیویٹ مواد ہر جگہ سے دستیاب ہو گیا ہے۔
ایک نئے سافٹ ویئر ریلیز کے رول آؤٹ نے فائر وال کو تمام ACLs کو فراموش کر دیا اور سب کو اندر آنے دیا۔
زیادہ سے زیادہ سگنل اور کم سے کم شور کے ساتھ ایک اچھا مانیٹرنگ سسٹم بنانے کے لیے "کیا" اور "کیوں" سب سے اہم بلڈنگ بلاکس ہیں۔
بلیک باکس بمقابلہ وائٹ باکس
ہم اہم میٹرکس کے لیے وسیع وائٹ باکس مانیٹرنگ کو معمولی بلیک باکس مانیٹرنگ کے ساتھ جوڑتے ہیں۔ بلیک باکس کا وائٹ باکس سے موازنہ کرنے کا سب سے آسان طریقہ یہ ہے کہ بلیک باکس علامات پر مرکوز ہے اور فعال نگرانی کے بجائے رد عمل کا حامل ہے: "اس وقت سسٹم صحیح طریقے سے کام نہیں کر رہا ہے۔" وائٹ باکس سسٹم کی اندرونی تصدیقی صلاحیتوں پر منحصر ہے: ایونٹ لاگز یا ویب سرورز۔ اس طرح، وائٹ باکس آپ کو آنے والے مسائل، ایسی خرابیوں کا پتہ لگانے کی اجازت دیتا ہے جو درخواست کی دوبارہ منتقلی کے طور پر ظاہر ہوتے ہیں، وغیرہ۔
نوٹ کریں کہ ملٹی لیئر سسٹم میں، ایک انجینئر کی ذمہ داری کے علاقے میں ایک علامت دوسرے انجینئر کی ذمہ داری کے علاقے میں ایک علامت ہوتی ہے۔ مثال کے طور پر، ڈیٹا بیس کی کارکردگی میں کمی آئی ہے۔ سست ڈیٹا بیس ریڈز ڈیٹا بیس SRE کی ایک علامت ہیں جو ان کا پتہ لگاتا ہے۔ تاہم، ایک سست ویب سائٹ کا مشاہدہ کرنے والے فرنٹ اینڈ SRE کے لیے، اسی سست ڈیٹا بیس کی وجہ ایک سست ڈیٹا بیس ہے۔ لہذا، وائٹ باکس کی نگرانی بعض اوقات علامات پر مرکوز ہوتی ہے اور بعض اوقات وجہ پر مرکوز ہوتی ہے، اس پر منحصر ہے کہ یہ کتنا وسیع ہے۔
ڈیبگنگ کے لیے ٹیلی میٹری جمع کرتے وقت، وائٹ باکس کی نگرانی کی ضرورت ہوتی ہے۔ اگر ویب سرورز ڈیٹا بیس کے سوالات کا جواب دینے میں سست ہیں، تو آپ کو یہ جاننے کی ضرورت ہے کہ ویب سرور کتنی جلدی ڈیٹا بیس کے ساتھ بات چیت کرتا ہے اور کتنی جلدی جواب دیتا ہے۔ بصورت دیگر، آپ سست ڈیٹا بیس سرور اور ویب سرور اور ڈیٹا بیس کے درمیان نیٹ ورک کے مسئلے میں فرق نہیں کر پائیں گے۔
انتباہات بھیجتے وقت بلیک باکس کی نگرانی کا ایک اہم فائدہ ہوتا ہے: آپ وصول کنندہ کو اطلاع اس وقت متحرک کرتے ہیں جب مسئلہ پہلے ہی حقیقی علامات کے نتیجے میں ہوتا ہے۔ دوسری طرف، بلیک باکس کے مسئلے کے لیے نگرانی بیکار ہے جو ابھی پیدا نہیں ہوا ہے لیکن قریب ہے۔
چار سنہری اشارے
چار سنہری نگرانی کے سگنل تاخیر، ٹریفک، غلطیاں، اور سنترپتی ہیں۔ اگر آپ صرف چار صارف سسٹم میٹرکس کی پیمائش کر سکتے ہیں، تو ان چاروں پر توجہ دیں۔
تاخیر۔
درخواست پر کارروائی کے لیے درکار وقت۔ کامیاب اور ناکام درخواستوں کی تاخیر کے درمیان فرق کرنا ضروری ہے۔ مثال کے طور پر، ڈیٹا بیس یا دوسرے بیک اینڈ سے کنکشن ختم ہونے کی وجہ سے HTTP 500 کی خرابی کی بہت جلد تشخیص کی جا سکتی ہے، تاہم، HTTP 500 کی خرابی ناکام درخواست کی نشاندہی کر سکتی ہے۔ مجموعی تاخیر پر 500 غلطی کے اثرات کا تعین غلط نتائج کی طرف لے جا سکتا ہے۔ دوسری طرف، ایک سست غلطی بھی ایک تیز غلطی ہے! لہذا، غلطیوں کو فلٹر کرنے کے بجائے غلطی کی تاخیر کی نگرانی کرنا ضروری ہے۔
ٹریفک
آپ کے سسٹم کی درخواستوں کی تعداد کو اعلی سطحی سسٹم میٹرکس میں ماپا جاتا ہے۔ ویب سروس کے لیے، یہ پیمائش عام طور پر فی سیکنڈ HTTP درخواستوں کی تعداد کی نمائندگی کرتی ہے، درخواستوں کی نوعیت (مثال کے طور پر، جامد یا متحرک مواد) سے تقسیم ہوتی ہے۔ آڈیو سٹریمنگ سسٹم کے لیے، یہ پیمائش نیٹ ورک I/O کی رفتار یا بیک وقت سیشنز کی تعداد پر مرکوز ہو سکتی ہے۔ کلیدی قدر ذخیرہ کرنے کے نظام کے لیے، یہ پیمائش لین دین یا تلاش کے نتائج فی سیکنڈ ہو سکتی ہے۔
نقائص
یہ ناکام درخواستوں کی شرح ہے جو صریح ہیں (مثلاً HTTP 500)، مضمر (مثلاً HTTP 200 لیکن غلط مواد کے ساتھ مل کر) یا پالیسی (مثلاً "اگر آپ نے ایک سیکنڈ میں جواب حاصل کیا تو کوئی ایک سیکنڈ غلطی ہے")۔ اگر HTTP رسپانس کوڈ تمام ناکامی کے حالات کو ظاہر کرنے کے لیے کافی نہیں ہیں، تو جزوی ناکامی کا پتہ لگانے کے لیے ثانوی (اندرونی) پروٹوکول کی ضرورت پڑ سکتی ہے۔ اس طرح کی تمام ناکام درخواستوں کی نگرانی کرنا معلوماتی نہیں ہو سکتا، جبکہ سسٹم کے آخر تک ٹیسٹ اس بات کا پتہ لگانے میں مدد کریں گے کہ آپ غلط مواد پر کارروائی کر رہے ہیں۔
سنترپتی
میٹرک دکھاتا ہے کہ آپ کی سروس کو کتنی شدت سے استعمال کیا جاتا ہے۔ یہ نظام کی نگرانی کا ایک پیمانہ ہے جو ان وسائل کی نشاندہی کرتا ہے جو سب سے زیادہ محدود ہیں (مثال کے طور پر، میموری سے محدود سسٹم پر، میموری کو ظاہر کرتا ہے، I/O-ممنوع نظام پر، I/Os کی تعداد دکھاتا ہے)۔ نوٹ کریں کہ بہت سے سسٹم 100% استعمال تک پہنچنے سے پہلے ہی کارکردگی کو کم کر دیتے ہیں، اس لیے استعمال کا ہدف ہونا ضروری ہے۔
پیچیدہ نظاموں میں، سنترپتی کو اعلی سطحی بوجھ کی پیمائش سے پورا کیا جا سکتا ہے: کیا آپ کی سروس صحیح طریقے سے ڈبل ٹریفک کو ہینڈل کر سکتی ہے، صرف 10% زیادہ ٹریفک کو ہینڈل کر سکتی ہے، یا اس سے بھی کم ٹریفک کو ہینڈل کر سکتی ہے جو اس وقت ہے؟ ایسی سادہ خدمات کے لیے جن میں ایسے پیرامیٹرز نہیں ہوتے جو درخواست کی پیچیدگی کو تبدیل کرتے ہیں (مثال کے طور پر، "مجھے کچھ بھی نہ دیں" یا "مجھے ایک منفرد واحد یک یک انٹیجر کی ضرورت ہے")، جو ترتیب میں شاذ و نادر ہی تبدیلی کرتی ہیں، ایک جامد لوڈ ٹیسٹ ویلیو کافی ہو سکتی ہے۔ تاہم، جیسا کہ پچھلے پیراگراف میں زیر بحث آیا ہے، زیادہ تر سروسز کو بالواسطہ سگنلز کا استعمال کرنا چاہیے جیسے کہ CPU استعمال یا نیٹ ورک بینڈوڈتھ، جن کا اوپری باؤنڈ معلوم ہوتا ہے۔ تاخیر میں اضافہ اکثر سنترپتی کا ایک اہم اشارہ ہوتا ہے۔ ایک چھوٹی سی ونڈو میں 99ویں پرسنٹائل رسپانس ٹائم کی پیمائش کرنا (مثلاً ایک منٹ) سنترپتی کا بہت ابتدائی سگنل فراہم کر سکتا ہے۔
آخر میں، سنترپتی کا تعلق آنے والی سنترپتی کے بارے میں پیشین گوئیوں سے بھی ہے، مثال کے طور پر: "ایسا لگتا ہے کہ آپ کا ڈیٹا بیس آپ کی ہارڈ ڈرائیو کو 4 گھنٹے میں بھر دے گا۔"
اگر آپ چاروں سنہری اشاروں کی پیمائش کرتے ہیں اور جب میٹرکس میں سے کسی ایک میں کوئی مسئلہ ہوتا ہے (یا، سنترپتی کی صورت میں، قریب کا مسئلہ)، تو آپ کسی شخص کو الرٹ کرتے ہیں، آپ کی سروس کم و بیش نگرانی کے ذریعے احاطہ کرے گی۔
"دم" (یا آلہ سازی اور کارکردگی) کے بارے میں تشویش
شروع سے مانیٹرنگ سسٹم بناتے وقت، اوسط قدروں پر مبنی ایک نظام تیار کرنے کا لالچ ہوتا ہے: اوسط تاخیر، نوڈس کا اوسط CPU استعمال، یا اوسط ڈیٹا بیس مکمل۔ آخری دو مثالوں کا خطرہ واضح ہے: پروسیسرز اور ڈیٹا بیس کو انتہائی غیر متوقع طریقے سے نمٹا دیا جاتا ہے۔ اسی طرح تاخیر پر لاگو ہوتا ہے۔ اگر آپ 100ms کی اوسط تاخیر کے ساتھ 1000 درخواستیں فی سیکنڈ کے ساتھ ویب سروس چلاتے ہیں، تو 1% درخواستوں میں 5 سیکنڈ لگ سکتے ہیں۔ اگر صارفین اس طرح کی متعدد ویب سروسز پر انحصار کرتے ہیں، تو ایک بیک اینڈ کا 99 واں پرسنٹائل آسانی سے فرنٹ اینڈ کا میڈین ریسپانس ٹائم بن سکتا ہے۔
درخواستوں کی سست اوسط اور انتہائی سست رفتار کے درمیان فرق کرنے کا آسان ترین طریقہ یہ ہے کہ اعدادوشمار میں بیان کردہ درخواستوں کی پیمائش کو جمع کیا جائے (دکھانے کا ایک اچھا ٹول ہسٹوگرام ہے) بجائے کہ اصل تاخیر: سروس نے کتنی درخواستیں پیش کیں جن میں 0 ایم ایس کے درمیان وقت لگا۔ اور 10 ms، 10 ms اور 30 ms کے درمیان، 30 ms اور 100 ms کے درمیان، 100 ms اور 300 ms کے درمیان، وغیرہ۔ ہسٹوگرام کی حدود کو تقریباً تیزی سے پھیلانا (3 کے تخمینے کے عنصر سے) اکثر تقسیم کو دیکھنے کا ایک آسان طریقہ ہوتا ہے۔ درخواستوں کی.
پیمائش کے لیے تفصیل کی مناسب سطح کا انتخاب کرنا
نظام کے مختلف عناصر کو تفصیل کی مختلف سطحوں پر ناپا جانا چاہیے۔ مثال کے طور پر:
- وقت کی ایک مدت میں سی پی یو کے استعمال کی نگرانی کرنا طویل مدتی اسپائکس نہیں دکھائے گا جو زیادہ تاخیر کا باعث بنتے ہیں۔
- دوسری طرف، ہر سال 9 گھنٹے سے زیادہ ڈاؤن ٹائم (99,9% سالانہ اپ ٹائم) کو نشانہ بنانے والی ویب سروس کے لیے، HTTP 200 جواب کو ایک منٹ میں ایک یا دو بار سے زیادہ چیک کرنا غیر ضروری طور پر بار بار ہونے کا امکان ہے۔
- اسی طرح، ہر 99,9-1 منٹ میں ایک سے زیادہ بار 2% دستیابی کے لیے ہارڈ ڈرائیو کی جگہ کی جانچ کرنا شاید ضروری نہیں ہے۔
اس بات کا خیال رکھیں کہ آپ کس طرح اپنی پیمائش کے گرانولریٹی کو تشکیل دیتے ہیں۔ فی سیکنڈ میں ایک بار CPU لوڈ جمع کرنا دلچسپ ڈیٹا فراہم کر سکتا ہے، لیکن اس طرح کی متواتر پیمائشیں جمع کرنے، ذخیرہ کرنے اور تجزیہ کرنے کے لیے بہت مہنگی ہو سکتی ہیں۔ اگر آپ کے مانیٹرنگ کے مقصد کے لیے اعلی گرانولریٹی کی ضرورت ہے اور اس کے لیے اعلی ردعمل کی ضرورت نہیں ہے، تو آپ سرور پر میٹرکس کلیکشن ترتیب دے کر اور پھر ان میٹرکس کو اکٹھا کرنے اور جمع کرنے کے لیے ایک بیرونی نظام ترتیب دے کر ان اخراجات کو کم کر سکتے ہیں۔ کیا تم:
- ہر سیکنڈ میں CPU لوڈ کی پیمائش کریں۔
- تفصیل کو 5% تک کم کریں۔
- ہر منٹ میں مجموعی میٹرکس۔
یہ حکمت عملی آپ کو اعلی تجزیہ اور سٹوریج اوور ہیڈ کے بغیر ڈیٹا اکٹھا کرنے کی اجازت دے گی۔
جتنا ممکن ہو آسان، لیکن آسان نہیں۔
ایک دوسرے کے اوپر مختلف تقاضوں کے اوورلے کے نتیجے میں نگرانی کا نظام بہت پیچیدہ ہو سکتا ہے۔ مثال کے طور پر، آپ کے سسٹم میں درج ذیل پیچیدہ عناصر ہوسکتے ہیں:
- تمام قسم کے مختلف اشاریوں کے لیے مختلف پرسنٹائلز میں، درخواست پر کارروائی میں تاخیر کے لیے مختلف حدوں کے مطابق الرٹس۔
- ممکنہ وجوہات کا پتہ لگانے اور شناخت کرنے کے لیے اضافی کوڈ لکھنا۔
- مسائل کی ممکنہ وجوہات میں سے ہر ایک کے لیے متعلقہ ڈیش بورڈز بنائیں۔
ممکنہ پیچیدگی کے ذرائع کبھی ختم نہیں ہوتے ہیں۔ تمام سافٹ ویئر سسٹمز کی طرح، نگرانی اتنی پیچیدہ ہو سکتی ہے کہ اسے تبدیل کرنا اور برقرار رکھنا مشکل ہو جاتا ہے۔
لہذا، اپنے نگرانی کے نظام کو زیادہ سے زیادہ آسان بنانے کے لیے ڈیزائن کریں۔ کیا ٹریک کرنا ہے اس کا انتخاب کرتے وقت، درج ذیل کو ذہن میں رکھیں:
- وہ اصول جو اکثر حقیقی واقعات کو پکڑتے ہیں، ممکن حد تک آسان، پیشین گوئی اور قابل اعتماد ہونے چاہئیں۔
- ڈیٹا اکٹھا کرنے، جمع کرنے، اور انتباہ کے لیے کنفیگریشن جو کبھی کبھار کی جاتی ہے (مثال کے طور پر، کچھ SRE ٹیموں کے لیے سہ ماہی سے بھی کم) کو ہٹا دیا جانا چاہیے۔
- وہ میٹرکس جو جمع کیے گئے ہیں لیکن کسی پیش نظارہ ڈیش بورڈ میں نہیں دکھائے گئے ہیں یا کسی الرٹ کے ذریعے استعمال کیے گئے ہیں وہ حذف کیے جانے کے امیدوار ہیں۔
گوگل میں، بنیادی میٹرکس کا مجموعہ اور جمع، انتباہات اور ڈیش بورڈز کے ساتھ مل کر، نسبتاً الگ الگ نظام کے طور پر اچھی طرح کام کرتا ہے (گوگل کا مانیٹرنگ سسٹم دراصل کئی سب سسٹمز میں ٹوٹا ہوا ہے، لیکن لوگ عام طور پر ان سب سسٹمز کے تمام پہلوؤں سے واقف ہیں)۔ پیچیدہ نظاموں کی جانچ کے لیے نگرانی کو دیگر تکنیکوں کے ساتھ جوڑنا پرکشش ہوسکتا ہے: سسٹم کی تفصیلی پروفائلنگ، پروسیس ڈیبگنگ، مستثنیات یا ناکامیوں کے بارے میں تفصیلات سے باخبر رہنا، لوڈ ٹیسٹنگ، لاگ اکٹھا کرنا اور تجزیہ کرنا، یا ٹریفک کا معائنہ۔ اگرچہ ان میں سے زیادہ تر چیزوں میں بنیادی مانیٹرنگ کے ساتھ مشترکات ہیں، لیکن ان کو ملانے سے بہت زیادہ نتائج برآمد ہوں گے اور ایک پیچیدہ اور نازک نظام بن جائے گا۔ جیسا کہ سافٹ ویئر ڈویلپمنٹ کے بہت سے دوسرے پہلوؤں کے ساتھ، واضح، سادہ، ڈھیلے جوڑے ہوئے انضمام پوائنٹس کے ساتھ مختلف سسٹمز کو سپورٹ کرنا بہترین حکمت عملی ہے (مثال کے طور پر، ایک ویب API کا استعمال کرتے ہوئے مجموعی ڈیٹا کو ایک فارمیٹ میں بازیافت کرنا جو طویل عرصے تک مستقل رہ سکتا ہے۔ )۔
اصولوں کو ایک ساتھ باندھنا
اس باب میں زیر بحث اصولوں کو ایک مانیٹرنگ اور الرٹ کرنے والے فلسفے میں ملایا جا سکتا ہے جس کی گوگل ایس آر ای ٹیمیں توثیق اور پیروی کرتی ہیں۔ نگرانی کے اس فلسفے پر عمل کرنا ضروری ہے، یہ آپ کے انتباہ کے طریقہ کار کو بنانے یا اس پر نظر ثانی کرنے کے لیے ایک اچھا نقطہ آغاز ہے، اور آپ کی تنظیم کے سائز یا سروس یا سسٹم کی پیچیدگی سے قطع نظر، آپ کے آپریشن کے فنکشن کے صحیح سوالات پوچھنے میں آپ کی مدد کر سکتا ہے۔
مانیٹرنگ اور الرٹ کرنے کے اصول بناتے وقت، درج ذیل سوالات پوچھنے سے آپ کو غلط مثبت اور غیر ضروری انتباہات سے بچنے میں مدد مل سکتی ہے:
- کیا یہ قاعدہ سسٹم کی کسی دوسری صورت میں ناقابل شناخت حالت کا پتہ لگاتا ہے جو فوری ہے، کال ٹو ایکشن، اور لامحالہ صارف کو متاثر کرتی ہے؟
- کیا میں اس انتباہ کو نظر انداز کر سکتا ہوں، یہ جانتے ہوئے کہ یہ بے نظیر ہے؟ میں اس انتباہ کو کب اور کیوں نظر انداز کر سکتا ہوں اور میں اس منظر نامے سے کیسے بچ سکتا ہوں؟
- کیا اس الرٹ کا مطلب یہ ہے کہ صارفین منفی طور پر متاثر ہو رہے ہیں؟ کیا ایسے حالات ہیں جہاں صارفین منفی طور پر متاثر نہیں ہوتے ہیں، جیسے ٹریفک فلٹرنگ کے ذریعے یا ٹیسٹ سسٹم استعمال کرتے وقت جن کے لیے الرٹس کو فلٹر کیا جانا چاہیے؟
- کیا میں اس الرٹ کے جواب میں کارروائی کر سکتا ہوں؟ کیا یہ اقدامات فوری ہیں یا وہ صبح تک انتظار کر سکتے ہیں؟ کیا کوئی عمل محفوظ طریقے سے خودکار ہو سکتا ہے؟ کیا یہ عمل طویل مدتی حل ہوگا یا قلیل مدتی حل؟
- کچھ لوگوں کو اس مسئلے کے لیے متعدد الرٹس مل رہے ہیں، تو کیا انتباہات کی تعداد کو کم کرنے کا کوئی طریقہ ہے؟
یہ سوالات الرٹس اور وارننگ سسٹم کے بنیادی فلسفے کی عکاسی کرتے ہیں:
- جب بھی کوئی انتباہ آتا ہے، مجھے فوری طور پر ردعمل ظاہر کرنا پڑتا ہے۔ میں تھک جانے سے پہلے دن میں کئی بار فوری ردعمل ظاہر کر سکتا ہوں۔
- ہر الرٹ متعلقہ ہونا چاہیے۔
- الرٹ کے ہر جواب کے لیے انسانی مداخلت کی ضرورت ہوتی ہے۔ اگر اطلاع خود بخود کارروائی کی جا سکتی ہے، تو اسے نہیں آنا چاہیے۔
- انتباہات کسی نئے مسئلے یا واقعہ کے بارے میں ہونے چاہئیں جو پہلے موجود نہیں تھے۔
یہ نقطہ نظر کچھ امتیازات کو دھندلا دیتا ہے: اگر انتباہ پچھلی چار شرائط کو پورا کرتا ہے، تو اس سے کوئی فرق نہیں پڑتا کہ الرٹ وائٹ باکس یا بلیک باکس مانیٹرنگ سسٹم سے بھیجا گیا ہے۔ یہ نقطہ نظر بعض فرقوں کو بھی تقویت دیتا ہے: اسباب کی بجائے علامات کی شناخت پر زیادہ محنت کرنا بہتر ہے۔ جب بات اسباب کی ہو، تو آپ کو صرف ناگزیر وجوہات کے بارے میں فکر کرنے کی ضرورت ہے۔
طویل مدتی نگرانی
آج کے پیداواری ماحول میں، نگرانی کے نظام بدلتے ہوئے سافٹ ویئر فن تعمیر، کام کے بوجھ کی خصوصیات، اور کارکردگی کے اہداف کے ساتھ ہمیشہ سے ابھرتے ہوئے پیداواری نظام کی نگرانی کرتے ہیں۔ انتباہات جو فی الحال خودکار کرنا مشکل ہیں عام ہو سکتے ہیں، شاید قابل توجہ بھی۔ اس مقام پر، کسی کو مسئلہ کی بنیادی وجوہات کو تلاش کرنا اور اسے ختم کرنا ہوگا۔ اگر ایسی ریزولیوشن ممکن نہ ہو تو الرٹ کے جواب کے لیے مکمل آٹومیشن کی ضرورت ہوتی ہے۔
یہ ضروری ہے کہ نگرانی کے فیصلے طویل مدتی اہداف کو ذہن میں رکھ کر کیے جائیں۔ آج چلنے والا ہر انتباہ کل نظام کو بہتر کرنے سے انسان کی توجہ ہٹاتا ہے، لہذا طویل مدت میں نگرانی کے نظام کو بہتر بنانے کے لیے درکار وقت کے لیے پیداواری نظام کی دستیابی یا کارکردگی میں اکثر کمی واقع ہوتی ہے۔ آئیے اس رجحان کو واضح کرنے کے لیے دو مثالیں دیکھتے ہیں۔
بگ ٹیبل ایس آر ای: اوور الرٹ کی کہانی
Google کا اندرونی انفراسٹرکچر عام طور پر سروس لیول (SLO) کے مطابق فراہم اور ماپا جاتا ہے۔ کئی سال پہلے، Bigtable کی سروس SLO ایک مصنوعی لین دین کی اوسط کارکردگی پر مبنی تھی جو ایک لائیو کلائنٹ کی نقل کرتی تھی۔ بگ ٹیبل میں مسائل اور سٹوریج اسٹیک کی نچلی سطحوں کی وجہ سے، اوسط کارکردگی ایک "بڑی" دم سے چلتی تھی: بدترین 5% سوالات اکثر باقی کے مقابلے میں نمایاں طور پر سست تھے۔
ایس ایل او کی حد کے قریب آتے ہی ای میل اطلاعات بھیجی گئیں، اور ایس ایل او کی حد سے تجاوز کرنے پر میسنجر الرٹس بھیجے گئے۔ دونوں قسم کے انتباہات اکثر بھیجے جاتے تھے، جس میں انجینئرنگ کے ناقابل قبول وقت کا استعمال ہوتا تھا: ٹیم نے ان چند کو تلاش کرنے کے لیے انتباہات کو ترتیب دینے میں کافی وقت صرف کیا جو حقیقت میں متعلقہ تھے۔ ہم اکثر ایک ایسا مسئلہ یاد کرتے ہیں جس نے حقیقت میں صارفین کو متاثر کیا تھا کیونکہ صرف کچھ انتباہات اس مخصوص مسئلے کے لیے تھے۔ بنیادی ڈھانچے میں قابل فہم مسائل کی وجہ سے بہت سے انتباہات فوری نہیں تھے اور ان پر معیاری طریقے سے کارروائی کی گئی تھی، یا ان پر بالکل بھی کارروائی نہیں کی گئی تھی۔
صورت حال کے تدارک کے لیے، ٹیم نے تین جہتی نقطہ نظر اختیار کیا: Bigtable کی کارکردگی کو بہتر بنانے کے لیے سخت محنت کرتے ہوئے، ہم نے عارضی طور پر اپنا SLO ہدف استفسار کے جواب میں تاخیر کا 75 واں فیصد مقرر کیا۔ ہم نے ای میل الرٹس کو بھی بند کر دیا کیونکہ ان میں سے بہت سارے تھے کہ ان کی تشخیص میں وقت گزارنا ناممکن تھا۔
اس حکمت عملی نے ہمیں طویل مدتی مسائل کو بگ ٹیبل اور اسٹوریج اسٹیک کی نچلی سطحوں میں حل کرنا شروع کرنے کی اجازت دی، بجائے اس کے کہ مسلسل حکمت عملی سے متعلق مسائل کو ٹھیک کریں۔ انجینئر درحقیقت ہر وقت الرٹس کی بمباری کیے بغیر کام کروا سکتے تھے۔ بالآخر، الرٹ پروسیسنگ کو عارضی طور پر موخر کرنے سے ہمیں اپنی سروس کے معیار کو بہتر بنانے کا موقع ملا۔
جی میل: قابل قیاس، الگورتھم انسانی ردعمل
اپنے آغاز میں، Gmail کو ایک ترمیم شدہ ورک کیو پروسیس مینجمنٹ سسٹم پر بنایا گیا تھا جسے تلاش کے انڈیکس کے عمل کے حصوں کو بیچنے کے لیے ڈیزائن کیا گیا تھا۔ ورک کیو کو دیرپا عمل کے مطابق ڈھال لیا گیا اور بعد میں جی میل پر لاگو کیا گیا، لیکن مبہم شیڈیولر کوڈ میں کچھ کیڑے ٹھیک کرنا بہت مشکل ثابت ہوئے۔
اس وقت، Gmail کی نگرانی کا ڈھانچہ بنایا گیا تھا تاکہ انتباہات کو متحرک کیا جائے جب انفرادی کاموں کو Workqueue کا استعمال کرتے ہوئے منسوخ کیا جائے گا۔ یہ نقطہ نظر مثالی نہیں تھا، کیونکہ اس وقت بھی Gmail نے ہزاروں کام انجام دیے تھے، جن میں سے ہر ایک ہمارے صارفین کے ایک فیصد کے حصے کو فراہم کیا گیا تھا۔ ہم Gmail کے صارفین کو ایک اچھا صارف تجربہ فراہم کرنے کے بارے میں بہت فکر مند تھے، لیکن بہت سارے انتباہات کو ہینڈل کرنا دسترس سے باہر تھا۔
اس مسئلے کو حل کرنے کے لیے، Gmail SRE نے ایک ٹول بنایا تاکہ شیڈیولر کو ڈیبگ کرنے میں مدد کی جائے تاکہ صارفین پر پڑنے والے اثرات کو کم سے کم کیا جا سکے۔ ٹیم نے اس بارے میں کچھ بات چیت کی کہ آیا مسئلے کی دریافت سے لے کر صرف ایک طویل مدتی حل تلاش کرنے تک پورے چکر کو خودکار بنانا ہے، لیکن کچھ کو خدشہ تھا کہ اس طرح کا حل درحقیقت مسئلے کو حل کرنے میں تاخیر کرے گا۔
یہ تناؤ ٹیم میں عام تھا اور اکثر خود نظم و ضبط پر اعتماد کی کمی کی عکاسی کرتا ہے: جب کہ ٹیم کے کچھ اراکین درست درستگی کے لیے وقت دینا چاہتے ہیں، دوسروں کو خدشہ ہے کہ حتمی فکس کو فراموش کردیا جائے گا اور عارضی فکس ہمیشہ کے لیے ختم ہوجائے گا۔ یہ مسئلہ توجہ کا مستحق ہے کیونکہ حالات کو مستقل کرنے کے بجائے عارضی طور پر مسائل کو حل کرنا بہت آسان ہے۔ مینیجرز اور تکنیکی عملہ طویل مدتی اصلاحات کو نافذ کرنے، ابتدائی "درد" کے کم ہونے کے بعد بھی ممکنہ طور پر طویل مدتی اصلاحات کی حمایت اور ترجیح دینے میں کلیدی کردار ادا کرتے ہیں۔
باقاعدہ، دہرائے جانے والے انتباہات اور الگورتھمک جوابات کو سرخ پرچم ہونا چاہیے۔ ان انتباہات کو خودکار کرنے میں آپ کی ٹیم کی ہچکچاہٹ کا مطلب ہے کہ ٹیم کے پاس اعتماد کی کمی ہے کہ وہ الگورتھم پر بھروسہ کر سکتی ہے۔ یہ ایک سنگین مسئلہ ہے جس پر توجہ دینے کی ضرورت ہے۔
طویل مدتی
ایک عام تھیم Bigtable اور Gmail کی مثالوں کو جوڑتا ہے: قلیل مدتی اور طویل مدتی دستیابی کے درمیان مقابلہ۔ اکثر، ایک مضبوط کوشش ایک کمزور نظام کو زیادہ دستیابی حاصل کرنے میں مدد کر سکتی ہے، لیکن یہ راستہ عام طور پر قلیل المدتی ہوتا ہے، جس میں ٹیم برن آؤٹ اور اسی بہادر ٹیم کے چند اراکین پر انحصار ہوتا ہے۔
کنٹرول شدہ، دستیابی میں قلیل مدتی کمی اکثر تکلیف دہ ہوتی ہے، لیکن نظام کے طویل مدتی استحکام کے لیے حکمت عملی کے لحاظ سے اہم ہے۔ یہ ضروری ہے کہ ہر الرٹ کو تنہائی میں نہ دیکھیں بلکہ اس بات پر غور کریں کہ آیا الرٹ والیوم کی مجموعی سطح ایک قابل عمل ٹیم اور ایک سازگار تشخیص کے ساتھ ایک صحت مند، مناسب طریقے سے قابل رسائی نظام کی طرف لے جاتی ہے۔ ہم انتظامیہ کو سہ ماہی رپورٹس میں الرٹ فریکوئنسی کے اعدادوشمار کا تجزیہ کرتے ہیں (عام طور پر ہر شفٹ کے واقعات کے طور پر ظاہر کیا جاتا ہے، جہاں ایک واقعہ متعدد متعلقہ واقعات پر مشتمل ہو سکتا ہے)، جس سے فیصلہ سازوں کو الرٹ سسٹم کے بوجھ اور ٹیم کی مجموعی صحت کے بارے میں مسلسل نظر رکھنے کی اجازت ملتی ہے۔
حاصل يہ ہوا
صحت مند نگرانی اور انتباہ کا راستہ آسان اور واضح ہے۔ یہ مسئلہ کی علامات پر توجہ مرکوز کرتا ہے جو الرٹس کو متحرک کرتے ہیں، اور وجہ کی نگرانی مسائل کو ٹھیک کرنے میں مدد کے طور پر کام کرتی ہے۔ علامات کی نگرانی کرنا اتنا ہی آسان ہوتا ہے جتنا آپ اپنے کنٹرول کے اسٹیک میں ہوتے ہیں، حالانکہ ڈیٹا بیس کے بوجھ اور کارکردگی کی نگرانی براہ راست ڈیٹا بیس پر ہی کی جانی چاہیے۔ ای میل اطلاعات کی افادیت بہت محدود ہے اور یہ آسانی سے شور بن جاتے ہیں۔ اس کے بجائے، آپ کو ایک ڈیش بورڈ استعمال کرنا چاہئے جو تمام موجودہ مسائل پر نظر رکھتا ہے جو ای میل الرٹس کو متحرک کرتے ہیں۔ تاریخی ارتباط کا تجزیہ کرنے کے لیے ڈیش بورڈ کو ایونٹ لاگ کے ساتھ بھی جوڑا جا سکتا ہے۔
طویل مدتی میں، علامات اور آسنن حقیقی مسائل کے بارے میں انتباہات کی کامیاب گردش حاصل کرنے کے لیے ضروری ہے، اہداف کو اپناتے ہوئے اس بات کو یقینی بنانے کے لیے کہ نگرانی تیزی سے تشخیص کی حمایت کرتی ہے۔
ترجمہ آخر تک پڑھنے کا شکریہ۔ نگرانی کے بارے میں میرے ٹیلیگرام چینل کو سبسکرائب کریں۔ и .
ماخذ: www.habr.com