یہ مضمون مضامین کی ایک سیریز میں پہلا ہے "اپنے نیٹ ورک کے انفراسٹرکچر کو کیسے کنٹرول کریں"۔ سیریز کے تمام مضامین کے مواد اور لنکس مل سکتے ہیں۔ .
میں پوری طرح تسلیم کرتا ہوں کہ کافی تعداد میں ایسی کمپنیاں ہیں جہاں ایک گھنٹے یا ایک دن کا نیٹ ورک ڈاؤن ٹائم اہم نہیں ہے۔ بدقسمتی یا خوش قسمتی سے مجھے ایسی جگہوں پر کام کرنے کا موقع نہیں ملا۔ لیکن، بلاشبہ، نیٹ ورک مختلف ہیں، ضروریات مختلف ہیں، نقطہ نظر مختلف ہیں، اور پھر بھی، کسی نہ کسی شکل میں، بہت سے معاملات میں نیچے دی گئی فہرست درحقیقت ایک "ضروری ہے۔"
لہذا، ابتدائی شرائط.
آپ ایک نئی ملازمت میں ہیں، آپ کو ترقی ملی ہے، یا آپ نے اپنی ذمہ داریوں پر ایک نیا نظر ڈالنے کا فیصلہ کیا ہے۔ کمپنی کا نیٹ ورک آپ کی ذمہ داری کا علاقہ ہے۔ آپ کے لیے، یہ بہت سے طریقوں سے ایک چیلنج اور نیا ہے، جو کسی حد تک اس مضمون کے رہنمائی کے لہجے کا جواز پیش کرتا ہے :)۔ لیکن مجھے امید ہے کہ یہ مضمون کسی بھی نیٹ ورک انجینئر کے لیے بھی کارآمد ثابت ہو سکتا ہے۔
آپ کا پہلا اسٹریٹجک مقصد اینٹروپی کے خلاف مزاحمت کرنا سیکھنا اور فراہم کردہ سروس کی سطح کو برقرار رکھنا ہے۔
ذیل میں بیان کردہ بہت سے مسائل کو مختلف طریقوں سے حل کیا جا سکتا ہے۔ میں جان بوجھ کر تکنیکی نفاذ کا موضوع نہیں اٹھاتا، کیونکہ... اصولی طور پر، یہ اکثر اتنا اہم نہیں ہوتا کہ آپ نے یہ یا وہ مسئلہ کیسے حل کیا، لیکن اہم یہ ہے کہ آپ اسے کیسے استعمال کرتے ہیں اور کیا آپ اسے بالکل استعمال کرتے ہیں۔ مثال کے طور پر، اگر آپ اسے نہیں دیکھتے اور الرٹس کا جواب نہیں دیتے ہیں تو آپ کا پیشہ ورانہ طور پر بنایا ہوا مانیٹرنگ سسٹم بہت کم کام کا ہے۔
سامان
سب سے پہلے آپ کو یہ سمجھنے کی ضرورت ہے کہ سب سے بڑے خطرات کہاں ہیں۔
ایک بار پھر، یہ مختلف ہو سکتا ہے. میں تسلیم کرتا ہوں کہ کہیں، مثال کے طور پر، یہ سیکورٹی کے مسائل ہوں گے، اور کہیں، سروس کے تسلسل سے متعلق مسائل، اور کہیں، شاید، کچھ اور۔ کیوں نہیں؟
آئیے فرض کریں، واضح ہو، کہ یہ اب بھی خدمت کا تسلسل ہے (یہ معاملہ ان تمام کمپنیوں میں تھا جہاں میں کام کرتا تھا)۔
پھر آپ کو سامان کے ساتھ شروع کرنے کی ضرورت ہے. یہاں ان موضوعات کی فہرست ہے جن پر توجہ دینے کے لیے:
- تنقید کی ڈگری کے لحاظ سے سامان کی درجہ بندی
- اہم سامان کا بیک اپ
- حمایت، لائسنس
آپ کو ممکنہ ناکامی کے منظرناموں کے بارے میں سوچنے کی ضرورت ہے، خاص طور پر آپ کی تنقیدی درجہ بندی کے اوپری حصے میں موجود آلات کے ساتھ۔ عام طور پر، دوہرے مسائل کے امکان کو نظر انداز کر دیا جاتا ہے، بصورت دیگر آپ کا حل اور مدد غیر معقول حد تک مہنگی ہو سکتی ہے، لیکن نیٹ ورک کے واقعی اہم عناصر کی صورت میں، جن کی ناکامی کاروبار کو نمایاں طور پر متاثر کر سکتی ہے، آپ کو اس کے بارے میں سوچنا چاہیے۔
مثال کے طور پر
ہم کہتے ہیں کہ ہم ڈیٹا سینٹر میں روٹ سوئچ کے بارے میں بات کر رہے ہیں۔
چونکہ ہم نے اتفاق کیا کہ سروس کا تسلسل سب سے اہم معیار ہے، اس لیے اس سامان کا "ہاٹ" بیک اپ (فالتو پن) فراہم کرنا مناسب ہے۔ لیکن یہ سب کچھ نہیں ہے۔ آپ کو یہ بھی فیصلہ کرنا ہوگا کہ اگر پہلا سوئچ ٹوٹ جاتا ہے تو کیا آپ کے لیے صرف ایک باقی سوئچ کے ساتھ رہنا قابل قبول ہے، کیونکہ اس کے ٹوٹنے کا خطرہ بھی ہے۔
اہم! آپ کو اس مسئلے کا خود فیصلہ کرنے کی ضرورت نہیں ہے۔ آپ کو انتظامیہ یا کمپنی کے انتظام کے خطرات، ممکنہ حل اور اخراجات کی وضاحت کرنی چاہیے۔ انہیں فیصلے کرنے چاہئیں۔
لہذا، اگر یہ فیصلہ کیا گیا تھا کہ، دوہری ناکامی کے چھوٹے امکان کو دیکھتے ہوئے، ایک سوئچ پر 4 گھنٹے کام کرنا، اصولی طور پر، قابل قبول ہے، تو آپ آسانی سے مناسب مدد لے سکتے ہیں (جس کے مطابق آلات کو 4 کے اندر تبدیل کر دیا جائے گا۔ گھنٹے)۔
لیکن ایک خطرہ ہے کہ وہ فراہم نہیں کریں گے۔ بدقسمتی سے، ہم نے ایک بار خود کو ایسی حالت میں پایا. چار گھنٹے کے بجائے سامان نے ایک ہفتے کا سفر کیا!!!
لہذا، اس خطرے پر بھی بات کرنے کی ضرورت ہے اور، شاید، یہ آپ کے لیے زیادہ درست ہوگا کہ آپ دوسرا سوئچ (تیسرا) خریدیں اور اسے اسپیئر پارٹس پیکج ("کولڈ" بیک اپ) میں رکھیں یا اسے لیبارٹری کے مقاصد کے لیے استعمال کریں۔
اہم! میعاد ختم ہونے کی تاریخوں کے ساتھ آپ کے پاس موجود تمام سپورٹ کی ایک اسپریڈ شیٹ بنائیں اور اسے اپنے کیلنڈر میں شامل کریں تاکہ آپ کو کم از کم ایک مہینہ پہلے ایک ای میل موصول ہو جائے کہ آپ اپنے تعاون کی تجدید کے بارے میں فکر مند ہونا شروع کر دیں۔
آپ کو معاف نہیں کیا جائے گا اگر آپ اپنے سپورٹ کی تجدید کرنا بھول جاتے ہیں اور جس دن آپ کا ہارڈویئر ٹوٹ جاتا ہے ختم ہو جاتا ہے۔
ہنگامی کام
آپ کے نیٹ ورک پر کچھ بھی ہو، مثالی طور پر آپ کو اپنے نیٹ ورک کے آلات تک رسائی برقرار رکھنی چاہیے۔
اہم! آپ کے پاس تمام آلات تک کنسول تک رسائی ہونی چاہیے اور یہ رسائی صارف کے ڈیٹا نیٹ ورک کی صحت پر منحصر نہیں ہونی چاہیے۔
آپ کو ممکنہ منفی منظرناموں کا بھی پیشگی اندازہ لگانا چاہیے اور ضروری اقدامات کو دستاویز کرنا چاہیے۔ اس دستاویز کی دستیابی بھی اہم ہے، اس لیے اسے نہ صرف محکمے کے لیے مشترکہ وسائل پر پوسٹ کیا جانا چاہیے، بلکہ مقامی طور پر انجینئرز کے کمپیوٹرز پر بھی محفوظ کیا جانا چاہیے۔
ہونا ضروری ہے۔
- وینڈر یا انٹیگریٹر سپورٹ کے ساتھ ٹکٹ کھولنے کے لیے درکار معلومات
- کسی بھی سامان تک پہنچنے کے بارے میں معلومات (کنسول، انتظام)
بلاشبہ، اس میں کوئی دوسری مفید معلومات بھی ہو سکتی ہے، مثال کے طور پر، مختلف آلات کے اپ گریڈ کے طریقہ کار کی تفصیل اور مفید تشخیصی کمانڈز۔
کے ملحقہ
اب آپ کو شراکت داروں سے وابستہ خطرات کا اندازہ لگانے کی ضرورت ہے۔ عام طور پر یہ
- انٹرنیٹ فراہم کرنے والے اور ٹریفک ایکسچینج پوائنٹس (IX)
- مواصلاتی چینل فراہم کرنے والے
آپ کو اپنے آپ سے کون سے سوالات پوچھنے چاہئیں؟ جیسا کہ آلات کے ساتھ، مختلف ہنگامی حالات پر غور کیا جانا چاہیے۔ مثال کے طور پر، انٹرنیٹ فراہم کرنے والوں کے لیے، یہ کچھ اس طرح ہو سکتا ہے:
- اگر انٹرنیٹ فراہم کنندہ X کسی وجہ سے آپ کو سروس فراہم کرنا بند کر دے تو کیا ہوگا؟
- کیا دوسرے فراہم کنندگان کے پاس آپ کے لیے کافی بینڈوتھ ہوگی؟
- کنیکٹیوٹی کتنی اچھی رہے گی؟
- آپ کے انٹرنیٹ فراہم کرنے والے کتنے آزاد ہیں اور کیا ان میں سے کسی ایک کی شدید بندش دوسروں کے ساتھ مسائل کا باعث بنے گی؟
- آپ کے ڈیٹا سینٹر میں کتنے آپٹیکل ان پٹ ہیں؟
- اگر ان پٹ میں سے ایک مکمل طور پر تباہ ہو جائے تو کیا ہوگا؟
ان پٹ کے بارے میں، دو مختلف کمپنیوں میں، دو مختلف ڈیٹا سینٹرز میں، ایک کھدائی کرنے والے نے کنویں کو تباہ کر دیا تھا اور صرف معجزہ سے ہماری آپٹکس متاثر نہیں ہوئی تھیں۔ یہ ایسا کوئی نادر معاملہ نہیں ہے۔
اور، یقینا، آپ کو نہ صرف یہ سوالات پوچھنے کی ضرورت ہے، بلکہ، دوبارہ، انتظامیہ کے تعاون سے، کسی بھی صورت حال میں قابل قبول حل فراہم کرنے کی ضرورت ہے۔
بیک اپ
اگلی ترجیح آلات کی ترتیب کا بیک اپ ہو سکتی ہے۔ کسی بھی صورت میں، یہ ایک بہت اہم نقطہ ہے. میں ان معاملات کی فہرست نہیں دوں گا جب آپ کنفیگریشن کھو سکتے ہیں؛ بہتر ہے کہ باقاعدہ بیک اپ بنائیں اور اس کے بارے میں نہ سوچیں۔ اس کے علاوہ، باقاعدگی سے بیک اپ تبدیلیوں کی نگرانی میں بہت مفید ہو سکتا ہے.
اہم! روزانہ بیک اپ بنائیں۔ اس پر محفوظ کرنے کے لیے یہ اتنی بڑی مقدار میں ڈیٹا نہیں ہے۔ صبح کے وقت، ڈیوٹی پر موجود انجینئر (یا آپ) کو سسٹم سے ایک رپورٹ موصول ہونی چاہیے، جس میں واضح طور پر بتایا جائے کہ بیک اپ کامیاب تھا یا نہیں، اور اگر بیک اپ ناکام رہا تو مسئلہ حل کیا جانا چاہیے یا ٹکٹ بنانا چاہیے ( نیٹ ورک ڈیپارٹمنٹ کے عمل کو دیکھیں)۔
سافٹ ویئر ورژن
یہ سوال کہ آیا یہ سامان کے سافٹ ویئر کو اپ گریڈ کرنے کے قابل ہے یا نہیں، اتنا واضح نہیں ہے۔ ایک طرف، پرانے ورژن معلوم کیڑے اور کمزوریاں ہیں، لیکن دوسری طرف، نیا سافٹ ویئر، سب سے پہلے، ہمیشہ درد سے پاک اپ گریڈ کا طریقہ کار نہیں ہے، اور دوم، نئے کیڑے اور کمزوریاں۔
یہاں آپ کو بہترین آپشن تلاش کرنے کی ضرورت ہے۔ چند واضح تجاویز
- صرف مستحکم ورژن انسٹال کریں۔
- پھر بھی، آپ کو سافٹ ویئر کے بہت پرانے ورژن پر نہیں رہنا چاہئے۔
- کچھ سافٹ ویئر کہاں واقع ہے اس کے بارے میں معلومات کے ساتھ ایک نشان بنائیں
- وقتاً فوقتاً سافٹ ویئر ورژن میں کمزوریوں اور کیڑے کے بارے میں رپورٹس پڑھیں، اور اہم مسائل کی صورت میں، آپ کو اپ گریڈ کرنے کے بارے میں سوچنا چاہیے۔
اس مرحلے پر، آلات تک کنسول تک رسائی، معاونت کے بارے میں معلومات اور اپ گریڈ کے طریقہ کار کی تفصیل، آپ اصولی طور پر، اس قدم کے لیے تیار ہیں۔ مثالی آپشن وہ ہے جب آپ کے پاس لیبارٹری کا سامان ہو جہاں آپ پورے طریقہ کار کو چیک کر سکتے ہیں، لیکن بدقسمتی سے ایسا اکثر نہیں ہوتا ہے۔
اہم سازوسامان کی صورت میں، آپ اپ گریڈ میں مدد کرنے کی درخواست کے ساتھ وینڈر کے تعاون سے رابطہ کر سکتے ہیں۔
ٹکٹ کا نظام
اب آپ آس پاس دیکھ سکتے ہیں۔ آپ کو دوسرے محکموں کے ساتھ اور محکمہ کے اندر تعامل کے لیے عمل قائم کرنے کی ضرورت ہے۔
یہ ضروری نہیں ہوسکتا ہے (مثال کے طور پر، اگر آپ کی کمپنی چھوٹی ہے)، لیکن میں کام کو اس طرح منظم کرنے کی سفارش کروں گا کہ تمام بیرونی اور اندرونی کام ٹکٹ کے نظام سے گزریں۔
ٹکٹ سسٹم بنیادی طور پر اندرونی اور بیرونی مواصلات کے لیے آپ کا انٹرفیس ہے، اور آپ کو اس انٹرفیس کو کافی تفصیل سے بیان کرنا چاہیے۔
آئیے رسائی کھولنے کے ایک اہم اور عام کام کی مثال لیتے ہیں۔ میں ایک الگورتھم کی وضاحت کروں گا جس نے کمپنیوں میں سے ایک میں بالکل کام کیا۔
مثال کے طور پر
آئیے اس حقیقت سے آغاز کرتے ہیں کہ اکثر رسائی والے صارفین اپنی خواہشات کو نیٹ ورک انجینئر کے لیے ناقابل فہم زبان میں وضع کرتے ہیں، یعنی ایپلی کیشن کی زبان میں، مثال کے طور پر، "مجھے 1C تک رسائی دیں۔"
لہذا، ہم نے کبھی بھی ایسے صارفین سے براہ راست درخواستیں قبول نہیں کیں۔
اور یہ پہلی شرط تھی۔
- رسائی کی درخواستیں تکنیکی محکموں سے آنی چاہئیں (ہمارے معاملے میں یہ یونکس، ونڈوز، ہیلپ ڈیسک انجینئرز تھے)
دوسری شرط یہ ہے کہ
- یہ رسائی لازمی طور پر لاگ ان ہونی چاہیے (اس تکنیکی شعبے کے ذریعے جس سے ہمیں یہ درخواست موصول ہوئی ہے) اور درخواست کے طور پر ہمیں اس لاگ شدہ رسائی کا لنک موصول ہوتا ہے۔
اس درخواست کی شکل ہمارے لیے قابل فہم ہونی چاہیے، یعنی
- درخواست میں یہ معلومات ہونی چاہیے کہ کون سا سب نیٹ اور کس سب نیٹ تک رسائی کھلی ہونی چاہیے، ساتھ ہی پروٹوکول اور (tcp/udp کی صورت میں) پورٹس
اس کی نشاندہی وہاں بھی ہونی چاہیے۔
- اس رسائی کو کیوں کھولا گیا ہے اس کی تفصیل
- عارضی یا مستقل (اگر عارضی ہو تو کس تاریخ تک)
اور ایک بہت اہم نکتہ منظوری ہے۔
- محکمہ کے سربراہ سے جس نے رسائی شروع کی (مثال کے طور پر، اکاؤنٹنگ)
- ٹیکنیکل ڈیپارٹمنٹ کے سربراہ کی طرف سے، جہاں سے یہ درخواست نیٹ ورک ڈیپارٹمنٹ کو آئی (مثال کے طور پر، ہیلپ ڈیسک)
اس صورت میں، اس رسائی کے "مالک" کو اس شعبے کا سربراہ سمجھا جاتا ہے جس نے رسائی کا آغاز کیا (ہماری مثال میں اکاؤنٹنگ)، اور وہ اس بات کو یقینی بنانے کے لیے ذمہ دار ہے کہ اس شعبے کے لیے لاگ ان رسائی والا صفحہ تازہ ترین رہے۔ .
لاگنگ
یہ ایسی چیز ہے جس میں آپ ڈوب سکتے ہیں۔ لیکن اگر آپ ایک فعال نقطہ نظر کو لاگو کرنا چاہتے ہیں، تو آپ کو اس ڈیٹا سیلاب سے نمٹنے کا طریقہ سیکھنے کی ضرورت ہے۔
یہاں کچھ عملی سفارشات ہیں:
- آپ کو روزانہ لاگز کا جائزہ لینے کی ضرورت ہے۔
- منصوبہ بند جائزے کی صورت میں (اور ہنگامی صورتحال نہیں)، آپ اپنے آپ کو شدت کی سطح 0، 1، 2 تک محدود کر سکتے ہیں اور اگر آپ اسے ضروری سمجھتے ہیں تو دوسری سطحوں سے منتخب پیٹرن شامل کر سکتے ہیں۔
- ایک اسکرپٹ لکھیں جو لاگز کو پارس کرے اور ان لاگز کو نظر انداز کرے جن کے پیٹرن آپ نے نظر انداز کی فہرست میں شامل کیے ہیں
یہ نقطہ نظر آپ کو وقت گزرنے کے ساتھ، لاگز کی ایک نظر انداز فہرست بنانے کی اجازت دے گا جو آپ کے لیے دلچسپ نہیں ہیں اور صرف وہی چھوڑ دیں گے جنہیں آپ واقعی اہم سمجھتے ہیں۔
اس نے ہمارے لیے بہت اچھا کام کیا۔
نگرانی
کسی کمپنی کے لیے نگرانی کے نظام کا فقدان ہونا کوئی معمولی بات نہیں ہے۔ آپ، مثال کے طور پر، لاگز پر بھروسہ کر سکتے ہیں، لیکن سامان کچھ بھی "کہنے" کے لیے وقت کے بغیر صرف "مر" سکتا ہے، یا udp syslog پروٹوکول پیکٹ گم ہو سکتا ہے اور پہنچ نہیں سکتا۔ عام طور پر، بلاشبہ، فعال نگرانی اہم اور ضروری ہے۔
میری مشق میں دو سب سے زیادہ مقبول مثالیں:
- مواصلاتی چینلز کے بوجھ کی نگرانی، اہم روابط (مثال کے طور پر، فراہم کنندگان سے جڑنا)۔ وہ آپ کو ٹریفک کے نقصان کی وجہ سے سروس کے انحطاط کے ممکنہ مسئلے کو فعال طور پر دیکھنے کی اجازت دیتے ہیں اور اس کے مطابق، اس سے بچتے ہیں۔
- نیٹ فلو پر مبنی گراف۔ وہ ٹریفک میں بے ضابطگیوں کو تلاش کرنا آسان بناتے ہیں اور ہیکر حملوں کی کچھ آسان لیکن اہم اقسام کا پتہ لگانے کے لیے بہت مفید ہیں۔
اہم! انتہائی اہم واقعات کے لیے SMS اطلاعات مرتب کریں۔ یہ نگرانی اور لاگنگ دونوں پر لاگو ہوتا ہے۔ اگر آپ کے پاس آن ڈیوٹی شفٹ نہیں ہے تو ایس ایم ایس کام کے اوقات سے باہر بھی آنا چاہیے۔
اس عمل کے ذریعے اس طرح سوچیں کہ تمام انجینئرز کو جگانا نہیں ہے۔ اس کے لیے ہمارے پاس ایک انجینئر ڈیوٹی پر تھا۔
کنٹرول تبدیل کریں۔
میری رائے میں تمام تبدیلیوں کو کنٹرول کرنا ضروری نہیں ہے۔ لیکن، کسی بھی صورت میں، آپ کو، اگر ضروری ہو تو، آسانی سے معلوم کرنے کے قابل ہونا چاہیے کہ نیٹ ورک پر کچھ تبدیلیاں کس نے کی ہیں اور کیوں۔
کچھ نکات:
- اس ٹکٹ پر کیا کیا گیا تھا اس کی تفصیل کے لیے ٹکٹ سسٹم کا استعمال کریں، مثال کے طور پر لاگو کردہ کنفیگریشن کو ٹکٹ میں کاپی کرکے
- نیٹ ورک کے سازوسامان پر تبصرہ کی صلاحیتوں کا استعمال کریں (مثال کے طور پر، جونیپر پر تبصرہ کریں)۔ آپ ٹکٹ نمبر لکھ سکتے ہیں۔
- اپنے کنفیگریشن بیک اپ کے مختلف استعمال کریں۔
آپ تبدیلیوں کے لیے روزانہ تمام ٹکٹوں کا جائزہ لیتے ہوئے اسے ایک عمل کے طور پر نافذ کر سکتے ہیں۔
پروسیسنگ
آپ کو اپنی ٹیم میں عمل کو باضابطہ بنانا اور بیان کرنا چاہیے۔ اگر آپ اس مقام پر پہنچ گئے ہیں، تو آپ کی ٹیم کے پاس پہلے سے ہی کم از کم درج ذیل عمل چل رہے ہوں گے۔
روزانہ کے عمل:
- ٹکٹوں کے ساتھ کام کرنا
- نوشتہ جات کے ساتھ کام کرنا
- کنٹرول کو تبدیل کریں
- روزانہ چیک شیٹ
سالانہ عمل:
- ضمانتوں، لائسنسوں کی توسیع
غیر مطابقت پذیر عمل:
- مختلف ہنگامی حالات کا جواب
پہلے حصے کا اختتام
کیا آپ نے دیکھا ہے کہ یہ سب ابھی تک نیٹ ورک کنفیگریشن کے بارے میں نہیں، ڈیزائن کے بارے میں نہیں، نیٹ ورک پروٹوکول کے بارے میں نہیں، روٹنگ کے بارے میں نہیں، سیکورٹی کے بارے میں نہیں... لیکن یہ، اگرچہ شاید بورنگ ہیں، یقیناً نیٹ ورک ڈویژن کے کام کے بہت اہم عناصر ہیں۔
اب تک، جیسا کہ آپ دیکھ سکتے ہیں، آپ نے اپنے نیٹ ورک میں کچھ بھی بہتر نہیں کیا ہے۔ اگر حفاظتی کمزوریاں تھیں، تو وہ رہیں، اگر خراب ڈیزائن تھی، تو وہ رہیں۔ جب تک کہ آپ ایک نیٹ ورک انجینئر کے طور پر اپنی مہارتوں اور علم کو بروئے کار نہیں لاتے، جس پر آپ نے زیادہ تر وقت، کوشش اور بعض اوقات رقم خرچ کی ہوتی ہے۔ لیکن پہلے آپ کو فاؤنڈیشن بنانے (یا مضبوط) کرنے کی ضرورت ہے، اور پھر تعمیر شروع کریں۔
درج ذیل حصے آپ کو بتائیں گے کہ غلطیوں کو کیسے ڈھونڈنا اور ختم کرنا ہے، اور پھر اپنے بنیادی ڈھانچے کو بہتر بنانا ہے۔
یقینا، آپ کو ہر چیز کو ترتیب وار کرنے کی ضرورت نہیں ہے۔ وقت نازک ہو سکتا ہے۔ اگر وسائل اجازت دیں تو متوازی طور پر کریں۔
اور ایک اہم اضافہ۔ بات چیت کریں، پوچھیں، اپنی ٹیم سے مشورہ کریں۔ آخر میں وہی ہیں جو اس سب کی حمایت کرتے ہیں اور کرتے ہیں۔
ماخذ: www.habr.com