آؤٹ سورسنگ سے ترقی تک (حصہ 1)

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

پس منظر

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

ہمارے پاس نگرانی تھی، لیکن خالصتاً علمی دلچسپی کے باعث میں اپنا سب سے آسان تحریر لکھنے کی کوشش کرنا چاہتا تھا۔ خیال یہ تھا: میں چاہتا تھا کہ یہ ویب پر ہو، تاکہ میں آسانی سے کسی بھی کلائنٹ کو انسٹال کیے بغیر اندر جا سکوں اور دیکھ سکوں کہ کسی بھی ڈیوائس سے نیٹ ورک کے ساتھ کیا ہو رہا ہے، بشمول وائی فائی کے ذریعے ایک موبائل ڈیوائس، اور میں بھی واقعی جلدی سے سمجھنا چاہتا تھا کہ کمرے میں کون سا سامان ہے جو "موپی" بن گیا ہے کیونکہ... اس طرح کے مسائل کے جوابی وقت کے لیے بہت سخت تقاضے تھے۔ نتیجے کے طور پر، میرے ذہن میں ایک سادہ ویب صفحہ لکھنے کا منصوبہ پیدا ہوا جس پر نیٹ ورک ڈایاگرام کے ساتھ ایک jpeg پس منظر تھا، اس تصویر میں ان کے آئی پی ایڈریس کے ساتھ ڈیوائسز کو خود کاٹ دوں، اور اس تصویر کے اوپر متحرک مواد دکھائیں۔ ایک سبز یا چمکتے سرخ IP ایڈریس کی شکل میں مطلوبہ نقاط میں تصویر۔ کام طے ہو چکا ہے، آئیے شروع کرتے ہیں۔

پہلے، میں ڈیلفی، پی ایچ پی، جے ایس اور انتہائی سطحی طور پر C++ میں پروگرامنگ کر رہا تھا۔ میں اچھی طرح جانتا ہوں کہ نیٹ ورک کیسے کام کرتے ہیں۔ VLAN، روٹنگ (OSPF، EIGRP، BGP)، NAT۔ یہ میرے لیے خود ایک قدیم نگرانی کا پروٹو ٹائپ لکھنے کے لیے کافی تھا۔

میں نے وہی لکھا جو میں نے پی ایچ پی میں پلان کیا تھا۔ اپاچی اور پی ایچ پی سرور ونڈوز پر تھا کیونکہ... اس وقت میرے لیے لینکس ایک ناقابل فہم اور بہت پیچیدہ چیز تھی، جیسا کہ بعد میں پتہ چلا، میں بہت غلط تھا اور بہت سی جگہوں پر لینکس ونڈوز کے مقابلے میں بہت آسان ہے، لیکن یہ ایک الگ موضوع ہے اور ہم سب جانتے ہیں کہ اس پر کتنے ہولیور ہیں۔ یہ موضوع. ونڈوز ٹاسک شیڈیولر نے ایک چھوٹے وقفے پر کھینچا (مجھے بالکل یاد نہیں ہے، لیکن ہر تین سیکنڈ میں ایک بار کی طرح) ایک پی ایچ پی اسکرپٹ جس نے تمام اشیاء کو ایک عام پنگ کے ساتھ پول کیا اور ریاست کو فائل میں محفوظ کیا۔

system(“ping -n 3 -w 100 {$ip_address}“); 

ہاں، ہاں، اس وقت ڈیٹا بیس کے ساتھ کام کرنا بھی میرے لیے مہارت نہیں تھا۔ میں نہیں جانتا تھا کہ عمل کو متوازی بنانا ممکن ہے، اور تمام نیٹ ورک نوڈس سے گزرنے میں کافی وقت لگا، کیونکہ... یہ ایک دھاگے میں ہوا. مسائل خاص طور پر اس وقت پیدا ہوئے جب کئی نوڈس دستیاب نہ ہوں، کیونکہ ان میں سے ہر ایک نے اسکرپٹ کو 300 ms تک موخر کیا۔ کلائنٹ کی طرف ایک سادہ لوپنگ فنکشن تھا جس نے چند سیکنڈ کے وقفوں پر، Ajax کی درخواست کے ساتھ سرور سے تازہ ترین معلومات کو ڈاؤن لوڈ کیا اور انٹرفیس کو اپ ڈیٹ کیا۔ ٹھیک ہے، پھر، لگاتار 3 ناکام پنگوں کے بعد، اگر کمپیوٹر پر مانیٹرنگ والا ویب صفحہ کھلا، تو ایک خوش کن کمپوزیشن بجا۔

جب سب کچھ ہو گیا تو میں نتیجہ سے بہت متاثر ہوا اور سوچا کہ میں اس میں مزید اضافہ کر سکتا ہوں (اپنے علم اور صلاحیتوں کی وجہ سے)۔ لیکن مجھے ہمیشہ ایک ملین چارٹس والے سسٹم پسند نہیں تھے، جو میں نے تب سوچا تھا، اور آج تک سوچتا ہوں، زیادہ تر معاملات میں غیر ضروری ہیں۔ میں وہاں صرف وہی ڈالنا چاہتا تھا جو واقعی میرے کام میں میری مدد کرے گی۔ یہ اصول آج تک ولیم کی ترقی کے لیے بنیادی ہے۔ مزید، میں نے محسوس کیا کہ یہ بہت اچھا ہوگا اگر مجھے نگرانی کو کھلا رکھنے اور مسائل کے بارے میں جاننے کی ضرورت نہیں ہے، اور جب ایسا ہوا، تو صفحہ کھولیں اور دیکھیں کہ یہ مسئلہ نیٹ ورک نوڈ کہاں واقع ہے اور اس کے ساتھ آگے کیا کرنا ہے۔ . کسی طرح میں نے اس وقت ای میل نہیں پڑھا تھا، میں نے اسے استعمال نہیں کیا۔ مجھے انٹرنیٹ پر معلوم ہوا کہ ایس ایم ایس گیٹ وے ہیں جن پر آپ GET یا POST کی درخواست بھیج سکتے ہیں، اور وہ میرے موبائل فون پر اس متن کے ساتھ ایک SMS بھیجیں گے جو میں لکھوں گا۔ مجھے فوراً احساس ہوا کہ میں واقعی یہ چاہتا تھا۔ اور میں نے دستاویزات کا مطالعہ شروع کیا۔ کچھ عرصے کے بعد میں کامیاب ہو گیا، اور اب مجھے اپنے موبائل فون پر نیٹ ورک پر مسائل کے بارے میں ایک "گری ہوئی چیز" کے نام سے ایک SMS موصول ہوا۔ اگرچہ یہ نظام قدیم تھا، لیکن یہ میں نے خود لکھا تھا، اور سب سے اہم چیز جس نے مجھے اسے تیار کرنے کی ترغیب دی وہ یہ تھی کہ یہ ایک ایپلیکیشن پروگرام تھا جس نے واقعی میرے کام میں میری مدد کی۔

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

system(“tracert -d -w 500 8.8.8.8”);

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

مزید، روزمرہ کے کام میں مجھے کراس کراسنگ کرنا پڑتی تھی۔ اور میں ہر بار سسکو سوئچز پر جا کر یہ دیکھنے کے لیے تھک جاتا ہوں کہ کون سا انٹرفیس استعمال کرنا ہے۔ نگرانی میں کسی شے پر کلک کرنا اور تفصیل کے ساتھ اس کے انٹرفیس کی فہرست دیکھنا کتنا اچھا ہوگا۔ اس سے میرا وقت بچ جائے گا۔ مزید یہ کہ اس اسکیم میں اکاؤنٹس اور کمانڈز داخل کرنے کے لیے پٹی یا سیکیور سی آر ٹی چلانے کی ضرورت نہیں ہوگی۔ میں نے صرف مانیٹرنگ پر کلک کیا، دیکھا کہ کیا ضرورت ہے اور اپنا کام کرنے چلا گیا۔ میں نے سوئچ کے ساتھ بات چیت کرنے کے طریقے تلاش کرنا شروع کر دیے۔ مجھے فوری طور پر 2 اختیارات ملے: SNMP یا SSH کے ذریعے سوئچ میں لاگ ان کرنا، مجھے مطلوبہ کمانڈز داخل کرنا اور نتیجہ کو پارس کرنا۔ میں نے SNMP کو اس کے نفاذ کی پیچیدگی کی وجہ سے مسترد کر دیا؛ میں نتیجہ حاصل کرنے کے لیے بے چین تھا۔ SNMP کے ساتھ، آپ کو طویل عرصے تک MIB میں کھودنا پڑے گا اور، اس ڈیٹا کی بنیاد پر، انٹرفیس کے بارے میں ڈیٹا تیار کرنا پڑے گا۔ CISCO میں ایک شاندار ٹیم ہے۔

show interface status

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

ٹریس پر مبنی چینل کی نگرانی بہترین آئیڈیا نہیں رہی، کیونکہ... کبھی کبھی نیٹ ورک پر کام کیا جاتا تھا، اور ٹریسنگ بدل سکتی تھی اور مانیٹرنگ نے مجھ پر چیخنا شروع کر دیا کہ چینل کے ساتھ مسائل ہیں۔ لیکن تجزیہ پر کافی وقت گزارنے کے بعد، میں نے محسوس کیا کہ تمام چینلز کام کر رہے تھے، اور میری نگرانی مجھے دھوکہ دے رہی تھی۔ نتیجے کے طور پر، میں نے اپنے ساتھیوں سے کہا جنہوں نے چینل بنانے والے سوئچز کا انتظام کیا تھا کہ پڑوسیوں کی مرئیت کی حیثیت تبدیل ہونے پر مجھے صرف syslog بھیجیں۔ اس کے مطابق، یہ ٹریسنگ سے کہیں زیادہ آسان، تیز اور زیادہ درست تھا۔ پڑوسی گمشدہ جیسا واقعہ آچکا ہے اور میں فوراً چینل ڈاؤن کے بارے میں نوٹیفکیشن جاری کرتا ہوں۔

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

کمپنی آڈٹ ٹیلی کام کی تشکیل

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

میرے دوست پاول (آئی ٹی کے ماہر بھی) نے مسلسل مجھے اپنا کاروبار شروع کرنے کی ترغیب دینے کی کوشش کی۔ وہ جو کچھ کر رہے تھے اس کے مختلف تغیرات کے ساتھ بے شمار خیالات تھے۔ یہ برسوں سے زیر بحث ہے۔ اور آخر میں، یہ کچھ بھی نہیں ہونا چاہئے تھا کیونکہ میں ایک شکی ہوں، اور پاول ایک خواب دیکھنے والا ہے۔ جب بھی اس نے کوئی خیال پیش کیا، میں نے ہمیشہ اس پر یقین نہیں کیا اور شرکت کرنے سے انکار کردیا۔ لیکن ہم واقعی اپنا کاروبار کھولنا چاہتے تھے۔

آخر کار، ہم ایک ایسا آپشن ڈھونڈنے میں کامیاب ہو گئے جو ہم دونوں کے لیے موزوں ہو اور وہ کریں جو ہم جانتے ہیں کہ کیسے کرنا ہے۔ 2016 میں، ہم نے ایک IT کمپنی بنانے کا فیصلہ کیا جو کاروباروں کو IT کے مسائل حل کرنے میں مدد کرے گی۔ یہ آئی ٹی سسٹمز (1C، ٹرمینل سرور، میل سرور، وغیرہ)، ان کی دیکھ بھال، صارفین کے لیے کلاسک ہیلپ ڈیسک اور نیٹ ورک انتظامیہ کی تعیناتی ہے۔

سچ کہوں تو، کمپنی بنانے کے وقت، میں اس پر 99,9٪ کے بارے میں یقین نہیں کرتا تھا۔ لیکن کسی نہ کسی طرح پاول مجھے آزمانے میں کامیاب ہو گیا، اور آگے دیکھتے ہوئے وہ صحیح نکلا۔ Pavel اور میں نے ہر ایک نے 300 rubles میں چِپ کیا، ایک نیا LLC "Audit-Telecom" رجسٹر کیا، ایک چھوٹا سا دفتر کرائے پر لیا، عمدہ بزنس کارڈز بنائے، عام طور پر، جیسے کہ شاید سب سے زیادہ ناتجربہ کار، نوسکھئیے تاجروں، اور گاہکوں کی تلاش شروع کی۔ گاہکوں کو تلاش کرنا ایک بالکل مختلف کہانی ہے۔ اگر کسی کو دلچسپی ہو تو شاید ہم کارپوریٹ بلاگ کے حصے کے طور پر ایک الگ مضمون لکھیں گے۔ کولڈ کالز، فلائیرز وغیرہ۔ اس سے کوئی نتیجہ نہیں نکلا۔ جیسا کہ میں اب کاروبار کے بارے میں بہت سی کہانیوں سے پڑھتا ہوں، کسی نہ کسی طرح، بہت کچھ قسمت پر منحصر ہے۔ ہم خوش قسمت تھے۔ اور کمپنی کی تخلیق کے چند ہفتوں بعد، میرے بھائی ولادیمیر نے ہم سے رابطہ کیا، جو ہمارے لیے ہمارا پہلا کلائنٹ لے کر آیا۔ میں آپ کو کلائنٹس کے ساتھ کام کرنے کی تفصیلات سے تنگ نہیں کروں گا، یہ مضمون اس کے بارے میں نہیں ہے، میں صرف اتنا کہوں گا کہ ہم آڈٹ کے لیے گئے تھے، اہم علاقوں کی نشاندہی کی گئی تھی اور یہ علاقے ٹوٹ گئے تھے جب کہ فیصلہ کیا گیا تھا کہ آیا آؤٹ سورسرز کے طور پر ہمارے ساتھ مستقل بنیادوں پر تعاون کریں۔ اس کے بعد فوری طور پر ایک مثبت فیصلہ کیا گیا۔

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

اپنے مانیٹرنگ سسٹم پر کام جاری رکھیں

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

تو، کام:

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

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

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

$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);

نتائج اکثر غلط ہوتے تھے اور اسکینوں کو مکمل ہونے میں کافی وقت لگتا تھا۔ میں پنگ کے بارے میں مکمل طور پر بھول گیا تھا، یہ fping کے ذریعے کیا گیا تھا:

system("fping -r 3 -t 100 {$this->ip}");

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

ایک اور عام معمول کا کام WEB کے ذریعے کچھ خدمات ترتیب دینا تھا۔ ٹھیک ہے، مثال کے طور پر، ایم ایس ایکسچینج سے ای سی پی۔ بنیادی طور پر یہ صرف ایک لنک ہے۔ اور ہم نے فیصلہ کیا کہ ہمیں اس طرح کے لنکس کو براہ راست سسٹم میں شامل کرنے کے قابل ہونے کی ضرورت ہے، تاکہ کسی مخصوص کلائنٹ کے ECP تک کیسے رسائی حاصل کرنے کے لیے دستاویزات یا بُک مارکس میں کہیں اور دیکھنے کی ضرورت نہ پڑے۔ اس طرح سسٹم کے وسائل کے لنکس کا تصور ظاہر ہوا، ان کی فعالیت آج تک دستیاب ہے اور تقریباً تبدیل نہیں ہوئی ہے۔

ویلیم میں ریسورس لنکس کیسے کام کرتے ہیں۔

ریموٹ کنکشن

یہ وہی ہے جو ویلیم کے موجودہ ورژن میں ایکشن میں نظر آتا ہے۔

کاموں میں سے ایک کام سرورز سے جلدی اور آسانی کے ساتھ جڑنا تھا، جن میں سے پہلے ہی بہت سارے (ایک سو سے زیادہ) تھے اور لاکھوں پہلے سے محفوظ کردہ RDP شارٹ کٹس کو چھانٹنا انتہائی تکلیف دہ تھا۔ ایک آلے کی ضرورت تھی۔ انٹرنیٹ پر ایسا سافٹ ویئر موجود ہے جو اس طرح کے RDP کنکشنز کے لیے ایڈریس بک جیسا ہے، لیکن وہ مانیٹرنگ سسٹم کے ساتھ مربوط نہیں ہیں، اور اکاؤنٹس کو محفوظ نہیں کیا جا سکتا۔ جب آپ دن میں درجنوں بار مختلف سرورز سے جڑتے ہیں تو ہر بار مختلف کلائنٹس کے اکاؤنٹس میں داخل ہونا خالص جہنم ہے۔ SSH کے ساتھ، چیزیں تھوڑی بہتر ہیں؛ بہت سارے اچھے سافٹ ویئر ہیں جو آپ کو اس طرح کے کنکشن کو فولڈرز میں منظم کرنے اور ان سے اکاؤنٹس کو یاد رکھنے کی اجازت دیتا ہے۔ لیکن 2 مسائل ہیں۔ پہلا یہ کہ ہمیں RDP اور SSH کنکشن کے لیے ایک بھی پروگرام نہیں ملا۔ دوسرا یہ ہے کہ اگر کسی وقت میں اپنے کمپیوٹر پر نہیں ہوں اور مجھے جلدی سے جڑنے کی ضرورت ہے، یا میں نے ابھی سسٹم کو دوبارہ انسٹال کیا ہے، تو مجھے اس کلائنٹ کے اکاؤنٹ کو دیکھنے کے لیے دستاویزات میں جانا پڑے گا۔ یہ تکلیف دہ اور وقت کا ضیاع ہے۔

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

اس حقیقت کو مدنظر رکھتے ہوئے کہ ہمارے سسٹم میں کلائنٹ ایک ایسا براؤزر تھا جسے کمپیوٹر کے مقامی وسائل تک رسائی حاصل نہیں ہے، اس لیے کہ ہمیں کسی کمانڈ کے ذریعے مطلوبہ ایپلی کیشن کو لانچ کرنے کے لیے، یہ سب کچھ ونڈوز کے ذریعے کرنے کی ایجاد کی گئی تھی۔ اپنی مرضی کے مطابق یو آر ایل اسکیم"۔ اس طرح ہمارے سسٹم کے لیے ایک مخصوص "پلگ ان" نمودار ہوا، جس میں بس پٹی اور ریموٹ ڈیسک ٹاپ پلس شامل تھا اور انسٹالیشن کے دوران، صرف ونڈوز میں URI اسکیم کو رجسٹرڈ کیا گیا۔ اب، جب ہم آر ڈی پی یا ایس ایس ایچ کے ذریعے کسی آبجیکٹ سے جڑنا چاہتے تھے، تو ہم نے اپنے سسٹم پر اس ایکشن پر کلک کیا اور کسٹم یو آر آئی نے کام کیا۔ معیاری mstsc.exe ونڈوز یا پٹی میں بنایا گیا تھا، جو "پلگ ان" کا حصہ تھا، شروع کیا گیا تھا۔ میں نے لفظ پلگ ان کو اقتباسات میں رکھا ہے کیونکہ یہ کلاسیکی معنوں میں براؤزر پلگ ان نہیں ہے۔

کم از کم یہ کچھ تھا۔ آسان ایڈریس بک۔ مزید برآں، پوٹی کے معاملے میں، سب کچھ عام طور پر ٹھیک تھا؛ اسے ان پٹ پیرامیٹرز کے طور پر آئی پی کنکشن، لاگ ان اور پاس ورڈ دیا جا سکتا ہے۔ وہ. ہم پہلے ہی اپنے نیٹ ورک پر لینکس سرورز سے بغیر پاس ورڈ داخل کیے ایک کلک کے ساتھ جڑ چکے ہیں۔ لیکن RDP کے ساتھ یہ اتنا آسان نہیں ہے۔ معیاری mstsc پیرامیٹرز کے طور پر اسناد فراہم نہیں کر سکتا۔ ریموٹ ڈیسک ٹاپ پلس بچاؤ میں آیا۔ اس نے ایسا ہونے دیا۔ اب ہم اس کے بغیر کر سکتے ہیں، لیکن ایک طویل وقت کے لئے یہ ہمارے نظام میں ایک وفادار اسسٹنٹ تھا. HTTP(S) سائٹس کے ساتھ سب کچھ آسان ہے، ایسی اشیاء آسانی سے براؤزر میں کھل جاتی ہیں اور بس۔ آسان اور عملی۔ لیکن یہ خوشی صرف اندرونی نیٹ ورک پر تھی۔

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

ایسا ہوا کہ تمام کلائنٹس کے پاس معروف کمپنی Mikrotik کے آلات بطور راؤٹرز تھے۔ وہ تقریبا کسی بھی کام کو انجام دینے کے لئے بہت فعال اور آسان ہیں. منفی پہلو یہ ہے کہ وہ "ہائی جیک" ہیں۔ ہم نے اس مسئلے کو صرف باہر سے تمام رسائی بند کر کے حل کیا۔ لیکن یہ ضروری تھا کہ کسی طرح کلائنٹ کی جگہ پر آئے بغیر ان تک رسائی حاصل کی جائے، کیونکہ... یہ طویل ہے. ہم نے بس ایسے ہر میکروٹک کے لیے سرنگیں بنائیں اور انہیں الگ پول میں الگ کر دیا۔ بغیر کسی روٹنگ کے، تاکہ آپ کے نیٹ ورک کا کلائنٹس کے نیٹ ورکس اور ان کے نیٹ ورکس کا ایک دوسرے سے کوئی تعلق نہ ہو۔

یہ خیال اس بات کو یقینی بنانے کے لیے پیدا ہوا تھا کہ جب میں سسٹم میں مطلوبہ شے پر کلک کرتا ہوں، تو مرکزی مانیٹرنگ سرور، تمام کلائنٹ Mikrotik کے SSH اکاؤنٹس کو جانتے ہوئے، مطلوبہ اکاؤنٹ سے جڑ جاتا ہے، مطلوبہ میزبان کو فارورڈ کرنے کا اصول بناتا ہے۔ مطلوبہ بندرگاہ. یہاں کئی نکات ہیں۔ حل آفاقی نہیں ہے - یہ صرف Mikrotik کے لیے کام کرے گا، کیونکہ کمانڈ کا نحو تمام راؤٹرز کے لیے مختلف ہے۔ نیز، اس طرح کی فارورڈنگز کو پھر کسی نہ کسی طرح حذف کرنا پڑا، اور ہمارے سسٹم کا سرور حصہ بنیادی طور پر کسی بھی طرح سے ٹریک نہیں کر سکتا تھا کہ آیا میں نے اپنا RDP سیشن مکمل کر لیا ہے۔ ٹھیک ہے، اس طرح کی فارورڈنگ کلائنٹ کے لئے ایک سوراخ ہے. لیکن ہم نے آفاقیت کی پیروی نہیں کی، کیونکہ... پروڈکٹ کو صرف ہماری کمپنی میں استعمال کیا گیا تھا اور اسے عوام کے لیے جاری کرنے کا کوئی خیال نہیں تھا۔

ہر مسئلے کو اپنے طریقے سے حل کیا گیا۔ جب یہ اصول بنایا گیا تھا، تو یہ فارورڈنگ صرف ایک مخصوص بیرونی IP ایڈریس کے لیے دستیاب تھی (جس سے کنکشن شروع کیا گیا تھا)۔ تو ایک حفاظتی سوراخ سے بچا گیا۔ لیکن اس طرح کے ہر کنکشن کے ساتھ، NAT صفحہ میں ایک Mikrotik اصول شامل کیا گیا اور اسے صاف نہیں کیا گیا۔ اور ہر کوئی جانتا ہے کہ جتنے زیادہ اصول ہیں، راؤٹر کا پروسیسر اتنا ہی زیادہ لوڈ ہوتا ہے۔ اور عام طور پر، میں یہ قبول نہیں کر سکتا تھا کہ ایک دن میں کسی میکروٹک میں جاؤں گا، اور وہاں سینکڑوں مردہ، بیکار اصول ہوں گے۔

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

ویسے، یہ یہاں ہے:

global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={ 
	local dstport [/ip firewall nat get value-name="dst-port" $i]
	local dstaddress [/ip firewall nat get value-name="dst-address" $i]
	local dstaddrport "$dstaddress:$dstport"
	#log warning message=$dstaddrport
	local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
	if ($thereIsCon = "") do={
		set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
		#:log warning message=($atmonrulecounter->$dstport)
		if (($atmonrulecounter->$dstport) > 5) do={
			#log warning message="Removing nat rules added automaticaly by atmon_script"
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
			set ($atmonrulecounter->$dstport) 0
		}
	} else {
		set ($atmonrulecounter->$dstport) 0
	}
}

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

میکروٹک بیک اپ

ہم نے تمام Mikrotik کے بیک اپ کو FTP میں ترتیب دیا۔ اور مجموعی طور پر سب کچھ ٹھیک تھا۔ لیکن جب آپ کو بیک اپ لینے کی ضرورت ہوتی تھی، تو آپ کو یہ ایف ٹی پی کھول کر وہاں تلاش کرنا پڑتا تھا۔ ہمارے پاس ایک ایسا نظام ہے جہاں تمام راؤٹرز جڑے ہوئے ہیں؛ ہم SSH کے ذریعے آلات کے ساتھ بات چیت کر سکتے ہیں۔ میں نے سوچا کہ ہم اسے کیوں نہیں بناتے کہ سسٹم خود ہی تمام میکروٹک سے بیک اپ لے۔ اور اس پر عمل کرنے لگا۔ ہم نے منسلک کیا، بیک اپ بنایا اور اسے اسٹوریج میں لے گئے۔

میکروٹک سے بیک اپ لینے کے لیے پی ایچ پی میں اسکرپٹ کوڈ:

<?php

	$IP = '0.0.0.0';
	$LOGIN = 'admin';
	$PASSWORD = '';
	$BACKUP_NAME = 'test';

    $connection = ssh2_connect($IP, 22);

    if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;

    ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
    stream_get_contents($connection);
    ssh2_exec($connection, '/export file="atmon.rsc"');
    stream_get_contents($connection);
    sleep(40); // Waiting bakup makes

    $sftp = ssh2_sftp($connection);

    // Download backup file
    $size = filesize("ssh2.sftp://$sftp/atmon.backup");
    $stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
    @fclose($stream);

    sleep(3);
    // Download RSC file
    $size = filesize("ssh2.sftp://$sftp/atmon.rsc");
    $stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
    @fclose($stream);

    ssh2_exec($connection, '/file remove atmon.backup');
    ssh2_exec($connection, '/file remove atmon.rsc');

?>

بیک اپ دو شکلوں میں لیا جاتا ہے - بائنری اور ٹیکسٹ کنفیگریشن۔ بائنری مطلوبہ ترتیب کو فوری طور پر بحال کرنے میں مدد کرتی ہے، اور متن والا آپ کو یہ سمجھنے کی اجازت دیتا ہے کہ اگر سامان کی زبردستی تبدیلی ہو اور بائنری اس پر اپ لوڈ نہ ہو تو کیا کرنے کی ضرورت ہے۔ نتیجے کے طور پر، ہمیں سسٹم میں ایک اور آسان فعالیت ملی۔ مزید برآں، نئے Mikrotik کو شامل کرتے وقت، کسی بھی چیز کو ترتیب دینے کی ضرورت نہیں تھی؛ میں نے صرف اس چیز کو سسٹم میں شامل کیا اور SSH کے ذریعے اس کے لیے ایک اکاؤنٹ ترتیب دیا۔ پھر سسٹم نے خود ہی بیک اپ لینے کا خیال رکھا۔ SaaS Veliam کے موجودہ ورژن میں ابھی تک یہ فعالیت نہیں ہے، لیکن ہم اسے جلد ہی پورٹ کر دیں گے۔

اندرونی نظام میں یہ کیسا لگتا تھا اس کے اسکرین شاٹس

عام ڈیٹا بیس اسٹوریج میں منتقلی۔

میں پہلے ہی اوپر لکھ چکا ہوں کہ نمونے ظاہر ہوئے۔ بعض اوقات سسٹم میں موجود اشیاء کی پوری فہرست ہی غائب ہوجاتی ہے، بعض اوقات کسی چیز میں ترمیم کرتے وقت معلومات محفوظ نہیں ہوتی تھیں اور آبجیکٹ کا تین بار نام تبدیل کرنا پڑتا تھا۔ اس نے سب کو بری طرح پریشان کیا۔ اشیاء کی گمشدگی شاذ و نادر ہی ہوتی ہے، اور اس فائل کو بحال کرکے آسانی سے بحال کیا جاتا تھا، لیکن اشیاء میں ترمیم کرتے وقت ناکامی اکثر ہوتی ہے۔ شاید، میں نے ابتدائی طور پر ڈیٹا بیس کے ذریعے ایسا نہیں کیا تھا کیونکہ یہ میرے ذہن میں نہیں آتا تھا کہ فلیٹ ٹیبل میں تمام کنکشن والے درخت کو کیسے رکھنا ممکن ہے۔ یہ فلیٹ ہے، لیکن درخت درجہ بندی کا ہے۔ لیکن ایک سے زیادہ رسائی کے لیے ایک اچھا حل، اور اس کے نتیجے میں (جیسا کہ نظام زیادہ پیچیدہ ہو جاتا ہے) لین دین، ایک DBMS ہے۔ میں شاید اس مسئلے کا سامنا کرنے والا پہلا شخص نہیں ہوں۔ میں نے گوگل کرنا شروع کیا۔ یہ پتہ چلا کہ سب کچھ مجھ سے پہلے ہی ایجاد کیا گیا تھا اور بہت سے الگورتھم ہیں جو ایک فلیٹ میز سے ایک درخت بناتے ہیں. ہر ایک کو دیکھنے کے بعد، میں نے ان میں سے ایک کو لاگو کیا. لیکن یہ پہلے سے ہی سسٹم کا نیا ورژن تھا، کیونکہ... درحقیقت اس کی وجہ سے مجھے بہت کچھ دوبارہ لکھنا پڑا۔ نتیجہ فطری تھا، نظام کے بے ترتیب رویے کے مسائل دور ہو گئے۔ کچھ لوگ یہ کہہ سکتے ہیں کہ سافٹ ویئر ڈویلپمنٹ کے میدان میں غلطیاں بہت شوقیہ ہیں (سنگل تھریڈڈ اسکرپٹس، ایسی معلومات کو ذخیرہ کرنا جس تک ایک فائل میں مختلف تھریڈز سے بیک وقت کئی بار رسائی کی گئی ہو، وغیرہ)۔ ہوسکتا ہے کہ یہ سچ ہو، لیکن میرا اصل کام انتظامیہ تھا، اور پروگرامنگ میری روح کے لیے ایک طرف کی ہلچل تھی، اور مجھے پروگرامرز کی ٹیم میں کام کرنے کا تجربہ نہیں تھا، جہاں ایسی بنیادی چیزیں فوری طور پر میرے سینئر نے مجھے تجویز کی ہوں گی۔ ساتھیوں لہٰذا، میں نے ان تمام ٹکڑوں کو اپنے طور پر بھر دیا، لیکن میں نے مواد کو بہت اچھی طرح سے سیکھا۔ اور اس کے علاوہ، میرے کام میں کلائنٹس کے ساتھ ملاقاتیں، کمپنی کو فروغ دینے کی کوشش کرنے والے اقدامات، کمپنی کے اندر انتظامی مسائل کا ایک گروپ، اور بہت کچھ شامل ہے۔ لیکن ایک یا دوسرے طریقے سے، جو پہلے سے موجود تھا، مطالبہ میں تھا. لڑکوں اور میں نے خود اپنے روزمرہ کے کام میں پروڈکٹ کا استعمال کیا۔ واضح طور پر ناکام خیالات اور حل تھے جن پر وقت ضائع کیا گیا تھا، لیکن آخر میں یہ واضح ہو گیا کہ یہ کام کرنے والا آلہ نہیں تھا اور کسی نے اسے استعمال نہیں کیا اور یہ ولیم میں ختم نہیں ہوا.

ہیلپ ڈیسک - ہیلپ ڈیسک

یہ بتانا بے جا نہ ہوگا کہ ہیلپ ڈیسک کی تشکیل کیسے ہوئی۔ یہ بالکل مختلف کہانی ہے، کیونکہ... ویلیم میں یہ پہلے سے ہی تیسرا مکمل طور پر نیا ورژن ہے، جو پچھلے تمام ورژن سے مختلف ہے۔ اب یہ ایک سادہ سسٹم ہے، غیر ضروری گھنٹیوں اور سیٹیوں کے بغیر بدیہی، ڈومین کے ساتھ مربوط ہونے کی صلاحیت کے ساتھ ساتھ ای میل کے لنک کا استعمال کرتے ہوئے کسی بھی جگہ سے ایک ہی صارف پروفائل تک رسائی حاصل کرنے کی صلاحیت کے ساتھ۔ اور سب سے اہم بات یہ ہے کہ درخواست دہندہ سے VNC کے ذریعے کہیں سے بھی (گھر یا دفتر میں) براہ راست VPN یا پورٹ فارورڈنگ کے بغیر رابطہ ممکن ہے۔ میں آپ کو بتاؤں گا کہ ہم یہاں تک کیسے پہنچے، پہلے کیا ہوا اور کیا خوفناک فیصلے کیے گئے۔

ہم معروف TeamViewer کے ذریعے صارفین سے جڑے ہیں۔ تمام کمپیوٹرز جن کے صارفین کو ہم پیش کرتے ہیں ان کے پاس TV انسٹال ہے۔ پہلی چیز جو ہم نے غلط کی، اور بعد میں اسے ہٹا دیا، ہر HD کلائنٹ کو ہارڈ ویئر سے جوڑنا تھا۔ درخواست چھوڑنے کے لیے صارف نے HD سسٹم میں کیسے لاگ ان کیا؟ ٹی وی کے علاوہ، ہر ایک نے اپنے کمپیوٹر پر ایک خاص یوٹیلیٹی انسٹال کی ہوئی تھی، جو لعزر میں لکھی ہوئی تھی (یہاں بہت سے لوگ اپنی آنکھیں گھماتے ہوں گے، اور شاید گوگل پر بھی جائیں کہ یہ کیا ہے، لیکن سب سے بہترین مرتب شدہ زبان جو میں جانتا تھا وہ ڈیلفی تھی، اور لازر تقریباً ایک ہی چیز، صرف مفت)۔ عام طور پر، صارف نے ایک خصوصی بیچ فائل لانچ کی جس نے اس یوٹیلیٹی کو لانچ کیا، جس کے نتیجے میں سسٹم کا HWID پڑھا اور اس کے بعد براؤزر لانچ ہوا اور اجازت ملی۔ ایسا کیوں کیا گیا؟ کچھ کمپنیوں میں، خدمت کرنے والے صارفین کی تعداد انفرادی طور پر شمار کی جاتی ہے، اور ہر مہینے کے لیے سروس کی قیمت لوگوں کی تعداد پر مبنی ہوتی ہے۔ یہ بات سمجھ میں آتی ہے، آپ کہتے ہیں، لیکن یہ ہارڈ ویئر سے کیوں منسلک ہے؟ بہت سادگی سے، کچھ لوگ گھر آئے اور اپنے گھر کے لیپ ٹاپ سے اس انداز میں درخواست کی کہ ’’یہاں میرے لیے ہر چیز کو خوبصورت بنا دو‘‘۔ سسٹم HWID کو پڑھنے کے علاوہ، یوٹیلیٹی نے موجودہ Teamviewer ID کو رجسٹری سے نکالا اور اسے ہمارے پاس بھی منتقل کیا۔ ٹیم ویور کے پاس انضمام کے لیے ایک API ہے۔ اور ہم نے یہ انضمام کیا۔ لیکن ایک کیچ تھا۔ ان APIs کے ذریعے، صارف کے کمپیوٹر سے جڑنا ناممکن ہے جب وہ واضح طور پر اس سیشن کو شروع نہیں کرتا ہے اور اس سے جڑنے کی کوشش کرنے کے بعد، اسے "تصدیق" پر بھی کلک کرنا ہوگا۔ اس وقت، یہ ہمارے لیے منطقی معلوم ہوا کہ صارف کی درخواست کے بغیر کسی کو رابطہ نہیں کرنا چاہیے، اور چونکہ وہ شخص کمپیوٹر پر ہے، اس لیے وہ سیشن شروع کرے گا اور ریموٹ کنکشن کی درخواست کا اثبات میں جواب دے گا۔ سب کچھ غلط نکلا۔ درخواست دہندگان سیشن شروع کرنے کے لیے پریس کرنا بھول گئے، اور انہیں ٹیلی فون پر بات چیت میں یہ بتانا پڑا۔ اس سے وقت ضائع ہوا اور اس عمل کے دونوں طرف مایوسی ہوئی۔ مزید برآں، ایسے لمحات کے لیے یہ بالکل بھی غیر معمولی بات نہیں ہے جب کوئی شخص درخواست چھوڑتا ہے، لیکن صرف اس وقت رابطہ قائم کرنے کی اجازت ہے جب وہ لنچ کے لیے روانہ ہو۔ کیونکہ مسئلہ نازک نہیں ہے اور وہ نہیں چاہتا کہ اس کے کام کے عمل میں خلل پڑے۔ اس کے مطابق، وہ کنکشن کی اجازت دینے کے لیے کوئی بٹن نہیں دبائے گا۔ ہیلپ ڈیسک میں لاگ ان کرتے وقت اضافی فعالیت اس طرح ظاہر ہوتی ہے - ٹیم ویور کی ID پڑھتے ہوئے۔ ہمیں وہ مستقل پاس ورڈ معلوم تھا جو ٹیم ویور کو انسٹال کرتے وقت استعمال کیا جاتا تھا۔ زیادہ واضح طور پر، صرف سسٹم ہی اسے جانتا تھا، کیونکہ یہ انسٹالر اور ہمارے سسٹم میں بنایا گیا تھا۔ اس کے مطابق ایپلی کیشن سے ایک کنکشن بٹن آیا جس پر کلک کرنے سے کسی چیز کا انتظار کرنے کی ضرورت نہیں تھی لیکن ٹیم ویور نے فوراً کھولا اور کنکشن ہو گیا۔ نتیجے کے طور پر، دو قسم کے ممکنہ کنکشن تھے. آفیشل Teamviewer API اور ہمارے خود ساختہ ایک کے ذریعے۔ میری حیرت کی بات یہ ہے کہ انہوں نے پہلے کا استعمال تقریباً فوراً ہی بند کر دیا، حالانکہ اسے صرف خاص صورتوں میں استعمال کرنے کی ہدایت تھی اور جب صارف خود اجازت دیتا ہے۔ پھر بھی، اب مجھے سیکورٹی دو۔ لیکن معلوم ہوا کہ درخواست گزاروں کو اس کی ضرورت نہیں تھی۔ تصدیقی بٹن کے بغیر ان سے منسلک ہونے کے ساتھ وہ بالکل ٹھیک ہیں۔

لینکس میں ملٹی تھریڈنگ پر سوئچ کرنا

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

پی ایچ پی بذات خود ملٹی تھریڈنگ آؤٹ آف دی باکس کو سپورٹ نہیں کرتا ہے۔ ملٹی پروسیسنگ کے قابل، آپ کانٹا کر سکتے ہیں۔ لیکن، درحقیقت، میرے پاس پہلے سے ہی ایک پولنگ میکانزم لکھا ہوا تھا اور میں اسے بنانا چاہتا تھا تاکہ میں ایک بار ڈیٹابیس سے اپنی ضرورت کے تمام نوڈس کو شمار کروں، ہر چیز کو ایک ساتھ پنگ کروں، ہر ایک کے جواب کا انتظار کروں اور اس کے فوراً بعد ہی لکھوں۔ ڈیٹا یہ پڑھنے کی درخواستوں کی تعداد کو بچاتا ہے۔ ملٹی تھریڈنگ اس خیال میں بالکل فٹ بیٹھتی ہے۔ پی ایچ پی کے لیے ایک پی ٹی تھریڈز ماڈیول ہے جو آپ کو حقیقی ملٹی تھریڈنگ کرنے کی اجازت دیتا ہے، حالانکہ اسے پی ایچ پی 7.2 پر سیٹ اپ کرنے کے لیے کافی حد تک ٹنکرنگ کی ضرورت تھی، لیکن یہ ہو گیا۔ پورٹ اسکیننگ اور پنگ اب تیز ہیں۔ اور اس کے بجائے، مثال کے طور پر، 15 سیکنڈ فی لیپ پہلے، اس عمل میں 2 سیکنڈ لگنے لگے۔ یہ ایک اچھا نتیجہ تھا.

نئی کمپنیوں کا فوری آڈٹ

مختلف میٹرکس اور ہارڈ ویئر کی خصوصیات کو جمع کرنے کی فعالیت کیسے آئی؟ یہ آسان ہے. بعض اوقات ہمیں صرف موجودہ آئی ٹی انفراسٹرکچر کا آڈٹ کرنے کا حکم دیا جاتا ہے۔ ٹھیک ہے، ایک ہی چیز نئے کلائنٹ کے آڈٹ کو تیز کرنے کے لئے ضروری ہے. ہمیں کسی ایسی چیز کی ضرورت تھی جو ہمیں درمیانی یا بڑی کمپنی میں آنے کی اجازت دے اور جلدی سے معلوم کر سکے کہ ان کے پاس کیا ہے۔ میری رائے میں، اندرونی نیٹ ورک پر پنگ صرف ان لوگوں کی طرف سے مسدود ہے جو اپنی زندگی کو پیچیدہ کرنا چاہتے ہیں، اور ہمارے تجربے میں ان میں سے بہت کم ہیں۔ لیکن ایسے لوگ بھی ہیں۔ اس کے مطابق، آپ ایک سادہ پنگ کے ساتھ آلات کی موجودگی کے لیے نیٹ ورکس کو تیزی سے اسکین کر سکتے ہیں۔ پھر ہم انہیں شامل کر سکتے ہیں اور کھلی بندرگاہوں کے لیے اسکین کر سکتے ہیں جن میں ہماری دلچسپی ہو۔ درحقیقت، یہ فعالیت پہلے سے موجود تھی؛ یہ صرف مرکزی سرور سے ایک کمانڈ کو غلام میں شامل کرنے کی ضرورت تھی تاکہ یہ مخصوص نیٹ ورکس کو اسکین کرے اور جو کچھ بھی ملا اسے فہرست میں شامل کرے۔ میں ذکر کرنا بھول گیا، یہ فرض کیا گیا تھا کہ ہمارے پاس پہلے سے ہی ایک ترتیب شدہ نظام (غلام مانیٹرنگ سرور) کے ساتھ ایک ریڈی میڈ امیج موجود ہے جسے ہم ایک آڈٹ کے دوران کلائنٹ سے آسانی سے نکال سکتے ہیں اور اسے اپنے کلاؤڈ سے جوڑ سکتے ہیں۔

لیکن آڈٹ کے نتیجے میں عام طور پر مختلف معلومات کا ایک گروپ شامل ہوتا ہے، اور ان میں سے ایک یہ ہے کہ نیٹ ورک پر کس قسم کے آلات ہیں۔ سب سے پہلے، ہمیں ڈومین کے حصے کے طور پر ونڈوز سرورز اور ونڈوز ورک سٹیشنز میں دلچسپی تھی۔ چونکہ درمیانی اور بڑی کمپنیوں میں ڈومین کی کمی شاید اس قاعدے سے مستثنیٰ ہے۔ ایک زبان بولنے کے لیے، اوسط، میری رائے میں، 100+ لوگ ہیں۔ تمام ونڈوز مشینوں اور سرورز سے ان کے آئی پی اور ڈومین ایڈمنسٹریٹر اکاؤنٹ کو جانتے ہوئے، لیکن ان میں سے ہر ایک پر کوئی سافٹ ویئر انسٹال کیے بغیر ڈیٹا اکٹھا کرنے کا ایک طریقہ تلاش کرنا ضروری تھا۔ WMI انٹرفیس بچاؤ کے لیے آتا ہے۔ ونڈوز مینجمنٹ انسٹرومینٹیشن (WMI) کا لفظی مطلب ہے ونڈوز مینجمنٹ ٹولز۔ WMI مرکزی انتظام اور ونڈوز پلیٹ فارم پر چلنے والے کمپیوٹر انفراسٹرکچر کے مختلف حصوں کے آپریشن کی نگرانی کے لیے بنیادی ٹیکنالوجیز میں سے ایک ہے۔ ویکی سے لیا گیا ہے۔ اگلا، مجھے ڈیبین کے لیے wmic (یہ ایک WMI کلائنٹ ہے) کو مرتب کرنے کے لیے دوبارہ ٹنکر کرنا پڑا۔ سب کچھ تیار ہونے کے بعد، صرف ضروری معلومات کے لیے wmic کے ذریعے ضروری نوڈس کو پول کرنا باقی رہ گیا تھا۔ WMI کے ذریعے آپ ونڈوز کمپیوٹر سے تقریباً کوئی بھی معلومات حاصل کر سکتے ہیں، اور مزید یہ کہ آپ اس کے ذریعے کمپیوٹر کو کنٹرول بھی کر سکتے ہیں، مثال کے طور پر اسے ریبوٹ پر بھیجیں۔ اس طرح ہمارے سسٹم میں ونڈوز اسٹیشنز اور سرورز کے بارے میں معلومات کا مجموعہ ظاہر ہوا۔ اس کے علاوہ موجودہ سسٹم لوڈ انڈیکیٹرز کے بارے میں موجودہ معلومات موجود تھیں۔ ہم ان سے زیادہ کثرت سے درخواست کرتے ہیں، اور ہارڈ ویئر کے بارے میں معلومات کم کثرت سے۔ اس کے بعد آڈیٹنگ کچھ زیادہ ہی خوشگوار ہو گئی۔

سافٹ ویئر کی تقسیم کا فیصلہ

ہم خود اس نظام کو ہر روز استعمال کرتے ہیں، اور یہ ہر تکنیکی ملازم کے لیے ہمیشہ کھلا رہتا ہے۔ اور ہم نے سوچا کہ جو کچھ ہمارے پاس ہے وہ ہم دوسروں کے ساتھ بانٹ سکتے ہیں۔ نظام ابھی تک تقسیم کے لیے تیار نہیں تھا۔ بہت کچھ دوبارہ کرنا پڑا تاکہ مقامی ورژن SaaS میں بدل جائے۔ ان میں سسٹم کے مختلف تکنیکی پہلوؤں میں تبدیلیاں شامل ہیں (ریموٹ کنکشن، سپورٹ سروس)، لائسنسنگ کے لیے ماڈیولز کا تجزیہ، کسٹمر ڈیٹا بیس کی شارڈنگ، ہر سروس کی اسکیلنگ، اور تمام حصوں کے لیے آٹو اپ ڈیٹ سسٹم کی ترقی۔ لیکن یہ مضمون کا دوسرا حصہ ہوگا۔

اپ ڈیٹ کریں

دوسرا حصہ

ماخذ: www.habr.com