ہم ہاتھی کو حصوں میں کھاتے ہیں۔ صحت کی نگرانی کی حکمت عملی مثالوں کے ساتھ

ہر کسی کو خوش!

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

مثال کے طور پر، اگر خدمات میں سے کوئی ایک کریش ہو گیا ہے، تو آپ کو خود بخود اس مسئلے کو ریکارڈ کرنے اور اسے حل کرنا شروع کرنے کی ضرورت ہے، اور غیر مطمئن صارفین کے تکنیکی مدد سے رابطہ کرنے کا انتظار نہیں کرنا چاہیے۔

ہماری ایک چھوٹی کمپنی ہے، ہمارے پاس مانیٹرنگ ایپلی کیشنز کے لیے کسی پیچیدہ حل کا مطالعہ کرنے اور اسے برقرار رکھنے کے لیے وسائل نہیں ہیں، ہمیں ایک آسان اور موثر حل تلاش کرنے کی ضرورت ہے۔

نگرانی کی حکمت عملی

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

آپ ہاتھی کو کیسے کھا سکتے ہیں؟ صرف حصوں میں! ہم ایپلیکیشنز کی نگرانی کے لیے یہ طریقہ استعمال کرتے ہیں۔

ہماری نگرانی کی حکمت عملی کا نچوڑ:

اپنی درخواست کو اجزاء میں تقسیم کریں۔
ہر جزو کے لیے کنٹرول چیک بنائیں۔

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

اس طرح، کسی بھی نظام کو اجزاء کے درخت کے طور پر پیش کیا جا سکتا ہے۔ پیچیدہ اجزاء کو آسان حصوں میں تقسیم کیا گیا ہے۔ سادہ اجزاء میں چیک ہوتے ہیں۔

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

کوئی معجزہ نہیں ہے؛ زیادہ تر چیکوں کو آزادانہ طور پر تیار کرنے کی ضرورت ہوگی۔ لیکن گھبرائیں نہیں، کیونکہ زیادہ تر معاملات میں ایک چیک میں 5-10 لائنوں کا کوڈ لگتا ہے، لیکن آپ کسی بھی منطق کو لاگو کر سکتے ہیں اور آپ واضح طور پر سمجھ جائیں گے کہ چیک کیسے کام کرتا ہے۔

نگرانی کا نظام

ہم کہتے ہیں کہ ہم نے ایپلیکیشن کو اجزاء میں تقسیم کیا، ہر ایک جزو کے لیے چیک سامنے لائے اور لاگو کیے، لیکن ان چیکوں کے نتائج کا کیا کریں؟ ہم کیسے جانتے ہیں کہ کچھ چیک ناکام ہو گئے؟

ہمیں نگرانی کے نظام کی ضرورت ہوگی۔ وہ مندرجہ ذیل کام انجام دے گی:

• ٹیسٹ کے نتائج حاصل کریں اور اجزاء کی حیثیت کا تعین کرنے کے لیے ان کا استعمال کریں۔
  بصری طور پر، یہ جزو کے درخت کو نمایاں کرنے کی طرح لگتا ہے۔ فنکشنل اجزاء سبز ہو جاتے ہیں، پریشانی والے اجزاء سرخ ہو جاتے ہیں۔
• باکس سے باہر عمومی چیکس انجام دیں۔
  نگرانی کا نظام خود کچھ چیک کر سکتا ہے۔ پہیے کو دوبارہ کیوں ایجاد کریں، آئیے ان کا استعمال کریں۔ مثال کے طور پر، آپ چیک کر سکتے ہیں کہ ویب سائٹ کا صفحہ کھل رہا ہے یا سرور پنگ کر رہا ہے۔
• دلچسپی رکھنے والی جماعتوں کو مسائل کی اطلاع بھیجیں۔
• نگرانی کے اعداد و شمار کا تصور، رپورٹس، گراف اور اعدادوشمار کی فراہمی۔

ASMO نظام کی مختصر تفصیل

مثال کے ساتھ سمجھانا بہتر ہے۔ آئیے دیکھتے ہیں کہ ASMO سسٹم کی کارکردگی کی نگرانی کیسے منظم کی جاتی ہے۔

ASMO ایک خودکار موسمیاتی سپورٹ سسٹم ہے۔ یہ نظام روڈ سروس کے ماہرین کو یہ سمجھنے میں مدد کرتا ہے کہ سڑک کو ڈی آئسنگ میٹریل سے کہاں اور کب علاج کرنا ضروری ہے۔ سسٹم روڈ کنٹرول پوائنٹس سے ڈیٹا اکٹھا کرتا ہے۔ روڈ کنٹرول پوائنٹ سڑک پر ایک جگہ ہے جہاں آلات نصب ہیں: ایک ویدر اسٹیشن، ویڈیو کیمرہ وغیرہ۔ خطرناک حالات کی پیشن گوئی کرنے کے لیے، نظام بیرونی ذرائع سے موسم کی پیشن گوئی حاصل کرتا ہے۔

لہذا، نظام کی ساخت کافی عام ہے: ویب سائٹ، ایجنٹ، سامان. آئیے نگرانی شروع کریں۔

نظام کو اجزاء میں توڑنا

ASMO سسٹم میں درج ذیل اجزاء کو پہچانا جا سکتا ہے۔

1. ذاتی اکاؤنٹ
یہ ایک ویب ایپلیکیشن ہے۔ کم از کم، آپ کو یہ چیک کرنے کی ضرورت ہے کہ ایپلیکیشن انٹرنیٹ پر دستیاب ہے۔

2. ڈیٹا بیس
ڈیٹا بیس ڈیٹا کو ذخیرہ کرتا ہے جو رپورٹنگ کے لیے اہم ہے، اور آپ کو یقینی بنانا چاہیے کہ ڈیٹا بیس کے بیک اپ کامیابی کے ساتھ بنائے گئے ہیں۔

3. سرور
سرور سے ہمارا مطلب ہارڈ ویئر ہے جس پر ایپلی کیشنز چلتی ہیں۔ ایچ ڈی ڈی، ریم، سی پی یو کی حیثیت کو چیک کرنا ضروری ہے۔

4. ایجنٹ
یہ ایک ونڈوز سروس ہے جو ایک شیڈول پر بہت سے مختلف کام انجام دیتی ہے۔ کم از کم، آپ کو یہ چیک کرنے کی ضرورت ہے کہ سروس چل رہی ہے۔

5. ایجنٹ کا کام
صرف یہ جاننا کافی نہیں ہے کہ کوئی ایجنٹ کام کر رہا ہے۔ ایک ایجنٹ کام کر سکتا ہے، لیکن اپنے تفویض کردہ کام انجام نہیں دے سکتا۔ آئیے ایجنٹ کے اجزاء کو کاموں میں تقسیم کریں اور چیک کریں کہ آیا ہر ایجنٹ کا کام کامیابی سے کام کرتا ہے۔

6. روڈ کنٹرول پوائنٹس (تمام MPCs کا کنٹینر)
بہت سے روڈ کنٹرول پوائنٹس ہیں، لہذا آئیے تمام MPCs کو ایک جزو میں جوڑ دیں۔ اس سے مانیٹرنگ ڈیٹا کو پڑھنا زیادہ آسان ہو جائے گا۔ "ASMO سسٹم" کے جزو کی حیثیت کو دیکھتے وقت، یہ فوری طور پر واضح ہو جائے گا کہ مسائل کہاں ہیں: ایپلی کیشنز، ہارڈ ویئر یا زیادہ سے زیادہ کنٹرول سسٹم میں۔

7. روڈ کنٹرول پوائنٹ (ایک زیادہ سے زیادہ حد)
ہم اس جزو کو قابل استعمال سمجھیں گے اگر اس MPC پر موجود تمام آلات قابل خدمت ہیں۔

8. ڈیوائس
یہ ایک ویڈیو کیمرہ یا ویدر اسٹیشن ہے جو زیادہ سے زیادہ حراستی کی حد پر نصب ہے۔ یہ چیک کرنا ضروری ہے کہ ڈیوائس ٹھیک سے کام کر رہی ہے۔

نگرانی کے نظام میں، جزو کا درخت اس طرح نظر آئے گا:

ویب ایپلیکیشن مانیٹرنگ

لہذا، ہم نے نظام کو اجزاء میں تقسیم کیا ہے، اب ہمیں ہر ایک جزو کے لیے چیک کرنے کی ضرورت ہے۔

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

1. مرکزی صفحہ کے کھلنے کی جانچ کرنا
یہ چیک مانیٹرنگ سسٹم کے ذریعے کیا جاتا ہے۔ اس پر عمل کرنے کے لیے، ہم صفحہ کا پتہ، متوقع جوابی ٹکڑا اور زیادہ سے زیادہ درخواست پر عمل درآمد کا وقت بتاتے ہیں۔

2. ڈومین کی ادائیگی کی آخری تاریخ کی جانچ کرنا
ایک بہت اہم چیک۔ جب کوئی ڈومین بلا معاوضہ رہتا ہے، تو صارف سائٹ نہیں کھول سکتے۔ مسئلہ حل ہونے میں کئی دن لگ سکتے ہیں، کیونکہ... DNS تبدیلیاں فوری طور پر لاگو نہیں ہوتی ہیں۔

3. SSL سرٹیفکیٹ کی جانچ کرنا
آج کل، تقریباً تمام ویب سائٹس رسائی کے لیے https پروٹوکول استعمال کرتی ہیں۔ پروٹوکول کے صحیح طریقے سے کام کرنے کے لیے، آپ کو ایک درست SSL سرٹیفکیٹ درکار ہے۔

ذیل میں نگرانی کے نظام میں "ذاتی اکاؤنٹ" کا جزو ہے:

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

آپ اور کیا چیک کر سکتے ہیں؟

اپنی ویب ایپلیکیشن کو مکمل طور پر مانیٹر کرنے کے لیے، آپ درج ذیل چیک کر سکتے ہیں:

• فی وقفہ جاوا اسکرپٹ کی غلطیوں کی تعداد
• مدت کے لیے ویب ایپلیکیشن سائیڈ (بیک اینڈ) پر غلطیوں کی تعداد
• ویب ایپلیکیشن کے ناکام جوابات کی تعداد (رسپانس کوڈ 404، 500، وغیرہ)
• استفسار پر عمل درآمد کا اوسط وقت

ونڈوز سروس کی نگرانی (ایجنٹ)

ASMO سسٹم میں، ایجنٹ ٹاسک شیڈیولر کا کردار ادا کرتا ہے، جو پس منظر میں طے شدہ کاموں کو انجام دیتا ہے۔

اگر ایجنٹ کے تمام کام کامیابی سے مکمل ہوتے ہیں، تو ایجنٹ ٹھیک سے کام کر رہا ہے۔ یہ پتہ چلتا ہے کہ ایک ایجنٹ کی نگرانی کرنے کے لئے، آپ کو اس کے کاموں کی نگرانی کرنے کی ضرورت ہے. لہذا، ہم "ایجنٹ" جزو کو کاموں میں تقسیم کرتے ہیں۔ ہر کام کے لیے، ہم نگرانی کے نظام میں ایک الگ جز بنائیں گے، جہاں "ایجنٹ" کا جزو "والدین" ہوگا۔

ہم ایجنٹ کے اجزاء کو بچوں کے اجزاء (ٹاسک) میں تقسیم کرتے ہیں:

لہذا، ہم نے ایک پیچیدہ جزو کو کئی آسان حصوں میں توڑ دیا ہے۔ اب ہمیں ہر ایک سادہ جزو کے لیے چیک کرنے کی ضرورت ہے۔ براہ کرم نوٹ کریں کہ والدین کے جزو "ایجنٹ" کی کوئی جانچ نہیں ہوگی، کیونکہ نگرانی کا نظام اس کے بچے کے اجزاء کی حیثیت کی بنیاد پر آزادانہ طور پر اس کی حیثیت کا حساب لگائے گا۔ دوسرے الفاظ میں، اگر تمام کام کامیابی کے ساتھ مکمل ہو جائیں، تو ایجنٹ کامیابی سے چل رہا ہے۔

ASMO سسٹم میں سو سے زیادہ کام ہیں، کیا واقعی ہر کام کے لیے منفرد چیکس کے ساتھ آنا ضروری ہے؟ بلاشبہ، کنٹرول بہتر ہو گا اگر ہم ہر ایجنٹ کے کام کے لیے اپنی خصوصی جانچیں لے کر آئیں اور ان پر عمل درآمد کریں، لیکن زیادہ تر معاملات میں یونیورسل چیک کا استعمال کرنا ہی کافی ہوتا ہے۔

ASMO سسٹم کاموں کے لیے صرف یونیورسل چیک کا استعمال کرتا ہے اور یہ سسٹم کی کارکردگی کی نگرانی کے لیے کافی ہے۔

پیشرفت کی جانچ ہو رہی ہے۔
سب سے آسان اور سب سے مؤثر چیک عملدرآمد کی جانچ ہے۔ چیک اس بات کی تصدیق کرتا ہے کہ کام غلطیوں کے بغیر مکمل ہوا ہے۔ تمام کاموں میں یہ چیک ہوتا ہے۔

تصدیقی الگورتھم

ہر ٹاسک پر عمل درآمد کے بعد، آپ کو کامیابی کے چیک کا نتیجہ مانیٹرنگ سسٹم کو بھیجنے کی ضرورت ہے اگر ٹاسک کا عمل کامیاب رہا، یا اگر ایگزیکیوشن غلطی کے ساتھ مکمل ہو گیا تو ERROR۔

یہ چیک درج ذیل مسائل کا پتہ لگا سکتا ہے۔

1. کام چلتا ہے لیکن غلطی کے ساتھ ناکام ہوجاتا ہے۔
2. کام چلنا بند ہو گیا ہے، مثال کے طور پر، یہ منجمد ہو گیا ہے۔

آئیے دیکھتے ہیں کہ ان مسائل کو مزید تفصیل سے کیسے حل کیا جاتا ہے۔

مسئلہ 1 - کام چلتا ہے لیکن غلطی کے ساتھ ناکام ہوجاتا ہے۔
ذیل میں ایک ایسا معاملہ ہے جہاں ٹاسک چلتا ہے لیکن 14:00 اور 16:00 کے درمیان ناکام ہوجاتا ہے۔

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

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

مسئلہ 2 - ٹاسک نے عمل کرنا بند کر دیا (منجمد)
نگرانی کا نظام کیسے سمجھے گا کہ کوئی کام پھنس گیا ہے؟

چیک کے نتیجے میں ایک درست مدت ہے، مثال کے طور پر، 1 گھنٹہ۔ اگر ایک گھنٹہ گزر جاتا ہے اور کوئی نیا ٹیسٹ نتیجہ نہیں آتا ہے، تو نگرانی کا نظام ٹیسٹ کی حیثیت کو الارم پر سیٹ کر دے گا۔

اوپر کی تصویر میں، رات 14:00 بجے روشنیاں بند کر دی گئی تھیں۔ 15:00 بجے، نگرانی کا نظام پتہ لگائے گا کہ ٹیسٹ کا نتیجہ (14:00 سے) بوسیدہ ہے، کیونکہ متعلقہ وقت ختم ہو گیا ہے (ایک گھنٹہ)، لیکن کوئی نیا نتیجہ نہیں ہے، اور چیک کو الارم کی حالت میں تبدیل کر دے گا۔

16:00 بجے دوبارہ لائٹس آن کر دی گئیں، پروگرام ٹاسک کو مکمل کر کے عملدرآمد کا نتیجہ مانیٹرنگ سسٹم کو بھیج دے گا، ٹیسٹ سٹیٹس دوبارہ کامیاب ہو جائے گا۔

مجھے کون سا وقت چیک کرنا چاہیے؟

متعلقہ وقت کام کو انجام دینے کی مدت سے زیادہ ہونا چاہیے۔ میں ٹاسک پر عمل درآمد کی مدت سے 2-3 گنا زیادہ وقت مقرر کرنے کی تجویز کرتا ہوں۔ یہ غلط اطلاعات موصول ہونے سے بچنے کے لیے ضروری ہے جب، مثال کے طور پر، کسی کام میں معمول سے زیادہ وقت لگے یا کسی نے پروگرام کو دوبارہ لوڈ کیا۔

پیشرفت کی جانچ ہو رہی ہے۔

ASMO سسٹم میں "لوڈ پیشن گوئی" کا کام ہوتا ہے، جو ایک گھنٹے میں ایک بار بیرونی ذریعہ سے نئی پیشن گوئی ڈاؤن لوڈ کرنے کی کوشش کرتا ہے۔ بیرونی نظام میں نئی ​​پیشن گوئی کے ظاہر ہونے کا صحیح وقت معلوم نہیں ہے، لیکن یہ معلوم ہے کہ یہ دن میں 2 بار ہوتا ہے۔ معلوم ہوا کہ اگر کئی گھنٹوں تک کوئی نئی پیش گوئی نہ ہو تو یہ معمول کی بات ہے لیکن اگر ایک دن سے زائد عرصے تک کوئی نئی پیش گوئی نہ ہو تو کہیں نہ کہیں کچھ ٹوٹ گیا ہے۔ مثال کے طور پر، بیرونی پیشن گوئی کے نظام میں ڈیٹا کی شکل تبدیل ہو سکتی ہے، جس کی وجہ سے ASMO نئی پیشن گوئی جاری نہیں دیکھے گا۔

تصدیقی الگورتھم

یہ کام کامیابی کے چیک کا نتیجہ مانیٹرنگ سسٹم کو بھیجتا ہے جب وہ پیش رفت حاصل کرنے میں کامیاب ہو جاتا ہے (موسم کی نئی پیشن گوئی ڈاؤن لوڈ کرنا)۔ اگر کوئی پیش رفت نہیں ہوتی ہے یا کوئی خرابی ہوتی ہے، تو نگرانی کے نظام کو کچھ نہیں بھیجا جاتا ہے۔

چیک میں ایک متعلقہ وقفہ ہونا ضروری ہے کہ اس وقت کے دوران یہ نئی پیشرفت حاصل کرنے کی ضمانت ہو۔

براہ کرم نوٹ کریں کہ ہم تاخیر کے ساتھ مسئلہ کے بارے میں جانیں گے، کیونکہ مانیٹرنگ سسٹم آخری اسکین کے نتیجے کی میعاد ختم ہونے تک انتظار کرتا ہے۔ اس لیے چیک کی میعاد کی مدت کو زیادہ طویل کرنے کی ضرورت نہیں ہے۔

ڈیٹا بیس کی نگرانی

ASMO سسٹم میں ڈیٹا بیس کو کنٹرول کرنے کے لیے، ہم درج ذیل چیک کرتے ہیں:

1. بیک اپ کی تخلیق کی تصدیق کی جا رہی ہے۔
2. مفت ڈسک کی جگہ کی جانچ کر رہا ہے۔

بیک اپ کی تخلیق کی تصدیق کی جا رہی ہے۔
زیادہ تر ایپلی کیشنز میں، اپ ٹو ڈیٹ ڈیٹا بیس کا بیک اپ ہونا ضروری ہے تاکہ اگر سرور ناکام ہو جائے، تو آپ پروگرام کو نئے سرور پر تعینات کر سکتے ہیں۔

ASMO ہفتے میں ایک بار بیک اپ کاپی بناتا ہے اور اسے اسٹوریج میں بھیجتا ہے۔ جب یہ طریقہ کار کامیابی سے مکمل ہو جاتا ہے، تو کامیابی کی جانچ کا نتیجہ مانیٹرنگ سسٹم کو بھیج دیا جاتا ہے۔ تصدیق کا نتیجہ 9 دنوں کے لیے درست ہے۔ وہ. بیک اپ کی تخلیق کو کنٹرول کرنے کے لیے، "پراگریس چیک" میکانزم، جس پر ہم نے اوپر بات کی ہے، استعمال کیا جاتا ہے۔

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

عددی پیرامیٹرز کو چیک کرنے کے لیے میٹرکس کا استعمال کرنا آسان ہے۔

میٹرکس ایک عددی متغیر ہے، جس کی قدر مانیٹرنگ سسٹم میں منتقل ہوتی ہے۔ نگرانی کا نظام حد کی اقدار کو چیک کرتا ہے اور میٹرک کی حیثیت کا حساب لگاتا ہے۔

ذیل میں ایک تصویر دی گئی ہے کہ مانیٹرنگ سسٹم میں "ڈیٹا بیس" کا جزو کیسا لگتا ہے:

سرور کی نگرانی

سرور کی نگرانی کے لیے ہم درج ذیل چیک اور میٹرکس استعمال کرتے ہیں:

1. مفت ڈسک کی جگہ
اگر ڈسک کی جگہ ختم ہو جائے تو ایپلیکیشن کام نہیں کر سکے گی۔ ہم 2 حد کی قدریں استعمال کرتے ہیں: پہلی سطح WARNING ہے، دوسری سطح الارم ہے۔

2. فی گھنٹہ فیصد میں RAM کی اوسط قدر
ہم فی گھنٹہ اوسط استعمال کرتے ہیں کیونکہ... ہمیں نایاب نسلوں میں کوئی دلچسپی نہیں ہے۔

3. فی گھنٹہ اوسط CPU فیصد
ہم فی گھنٹہ اوسط استعمال کرتے ہیں کیونکہ... ہمیں نایاب نسلوں میں کوئی دلچسپی نہیں ہے۔

4. پنگ چیک
چیک کرتا ہے کہ سرور آن لائن ہے۔ نگرانی کا نظام یہ چیک کر سکتا ہے؛ کوڈ لکھنے کی ضرورت نہیں ہے۔

ذیل میں ایک تصویر دی گئی ہے کہ نگرانی کے نظام میں "سرور" کا جزو کیسا لگتا ہے:

آلات کی نگرانی

میں آپ کو بتاتا ہوں کہ ڈیٹا کیسے حاصل کیا جاتا ہے۔ ہر روڈ کنٹرول پوائنٹ (MPC) کے لیے ٹاسک پلانر میں ایک کام ہوتا ہے، مثال کے طور پر، "Survey MPC M2 km 200"۔ یہ کام ہر 30 منٹ میں تمام MPC آلات سے ڈیٹا وصول کرتا ہے۔

مواصلاتی چینل کا مسئلہ
زیادہ تر سامان شہر سے باہر واقع ہے؛ ڈیٹا ٹرانسمیشن کے لیے ایک GSM نیٹ ورک استعمال کیا جاتا ہے، جو مستحکم طور پر کام نہیں کرتا (وہاں ایک نیٹ ورک ہے، یا ایک نہیں ہے)۔

بار بار نیٹ ورک کی ناکامی کی وجہ سے، سب سے پہلے، نگرانی میں MPC سروے کی جانچ اس طرح نظر آئی:

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

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

ذیل میں ایک تصویر دی گئی ہے کہ مانیٹرنگ سسٹم میں آلات کیسا لگتا ہے:

اہم!
جب GSM نیٹ ورک کام کرنا بند کر دیتا ہے، تمام MDC آلات پول نہیں ہوتے ہیں۔ مانیٹرنگ سسٹم سے ای میلز کی تعداد کو کم کرنے کے لیے، ہمارے انجینئرز "ڈیوائس" کے بجائے "MPC" قسم کے اجزاء کے مسائل کے بارے میں اطلاعات کو سبسکرائب کرتے ہیں۔ یہ آپ کو ہر آلہ کے لیے علیحدہ اطلاع موصول کرنے کے بجائے ہر MPC کے لیے ایک اطلاع موصول کرنے کی اجازت دیتا ہے۔

حتمی ASMO مانیٹرنگ اسکیم

آئیے سب کچھ ایک ساتھ رکھیں اور دیکھیں کہ ہمارے پاس کس قسم کی مانیٹرنگ اسکیم ہے۔

حاصل يہ ہوا

آئیے خلاصہ کرتے ہیں۔
ASMO کی کارکردگی کی نگرانی نے ہمیں کیا دیا؟

1. خرابی کے خاتمے کا وقت کم ہو گیا ہے۔
ہم نے پہلے صارفین سے نقائص کے بارے میں سنا ہے، لیکن تمام صارفین نقائص کی اطلاع نہیں دیتے ہیں۔ ایسا ہوا کہ ہمیں سسٹم کے جزو کے ظاہر ہونے کے ایک ہفتے بعد اس کی خرابی کے بارے میں معلوم ہوا۔ اب جیسے ہی کسی مسئلے کا پتہ چلتا ہے نگرانی کا نظام ہمیں مسائل سے آگاہ کرتا ہے۔

2. سسٹم کے استحکام میں اضافہ ہوا ہے۔
چونکہ نقائص کو پہلے ہی ختم کرنا شروع ہو گیا تھا، اس لیے مجموعی طور پر نظام بہت زیادہ مستحکم کام کرنے لگا۔

3. تکنیکی مدد کے لیے کالز کی تعداد کو کم کرنا
بہت سے مسائل اب حل ہو چکے ہیں اس سے پہلے کہ صارفین ان کے بارے میں جان سکیں۔ صارفین نے تکنیکی مدد سے کم کثرت سے رابطہ کرنا شروع کیا۔ اس سب کا ہماری ساکھ پر اچھا اثر پڑتا ہے۔

4. کسٹمر اور صارف کی وفاداری میں اضافہ
گاہک نے نظام کے استحکام میں مثبت تبدیلیوں کو دیکھا۔ صارفین کو سسٹم کا استعمال کرتے ہوئے کم مسائل کا سامنا کرنا پڑتا ہے۔

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

اہم!
آپ مانیٹرنگ سسٹم کو اسی سرور پر انسٹال نہیں کر سکتے جہاں آپ کی ایپلی کیشنز چلتی ہیں۔ اگر سرور ڈاؤن ہو جاتا ہے تو ایپلیکیشنز کام کرنا بند کر دیں گی اور اس کے بارے میں مطلع کرنے والا کوئی نہیں ہو گا۔

نگرانی کے نظام کو دوسرے ڈیٹا سینٹر میں علیحدہ سرور پر چلنا چاہیے۔

اگر آپ کسی نئے ڈیٹا سینٹر میں سرشار سرور استعمال نہیں کرنا چاہتے تو آپ کلاؤڈ مانیٹرنگ سسٹم استعمال کر سکتے ہیں۔ ہماری کمپنی Zidium کلاؤڈ مانیٹرنگ سسٹم استعمال کرتی ہے، لیکن آپ کسی دوسرے مانیٹرنگ سسٹم کو استعمال کر سکتے ہیں۔ کلاؤڈ مانیٹرنگ سسٹم کی قیمت نئے سرور کو کرایہ پر لینے سے کم ہے۔

سفارشات:

1. ایپلی کیشنز اور سسٹمز کو اجزاء کے درخت کی شکل میں زیادہ سے زیادہ تفصیل سے توڑ دیں، تو یہ سمجھنا آسان ہوگا کہ کہاں اور کیا ٹوٹا ہے، اور کنٹرول زیادہ مکمل ہوگا۔
2. کسی جزو کی فعالیت کو جانچنے کے لیے، ٹیسٹ استعمال کریں۔ ایک پیچیدہ چیک کے مقابلے میں کئی سادہ چیک استعمال کرنا بہتر ہے۔
3. میٹرک تھریشولڈز کو کوڈ میں لکھنے کے بجائے مانیٹرنگ سسٹم کے اطراف میں ترتیب دیں۔ یہ آپ کو ایپلیکیشن کو دوبارہ مرتب کرنے، دوبارہ ترتیب دینے یا دوبارہ شروع کرنے سے بچائے گا۔
4. حسب ضرورت چیکس کے لیے، غلط اطلاعات موصول ہونے سے بچنے کے لیے متعلقہ وقت کا مارجن استعمال کریں کیونکہ کچھ چیک کو مکمل ہونے میں معمول سے تھوڑا زیادہ وقت لگتا ہے۔
5. کوشش کریں کہ نگرانی کے نظام کے اجزاء صرف اس وقت سرخ ہوجائیں جب یقینی طور پر کوئی مسئلہ ہو۔ اگر وہ بغیر کسی وجہ کے سرخ ہو جاتے ہیں، تو آپ نگرانی کے نظام کی اطلاعات پر توجہ دینا چھوڑ دیں گے، اس کا مطلب ختم ہو جائے گا۔

اگر آپ ابھی تک مانیٹرنگ سسٹم استعمال نہیں کر رہے ہیں تو شروع کریں! یہ اتنا مشکل نہیں جتنا لگتا ہے۔ سبز اجزاء کے درخت کو دیکھنے سے ایک کک حاصل کریں جسے آپ نے خود بڑھایا ہے۔

گڈ لک.

ماخذ: www.habr.com