اپنا پہلا کلاؤڈ یا ڈی او اوپس رول کیسے لینڈ کریں: ہائرنگ مینیجرز واقعی کیا تلاش کرتے ہیں۔

آپ نے AWS کے تین کورسز مکمل کیے ہیں۔ 12 ڈاکر ٹیوٹوریلز کے میرے نوٹ یہ ہیں۔ آپ جانتے ہیں کہ Kubernetes کیا ہے، CI/CD کا کیا مطلب ہے، اور آپ بغیر کسی ہچکچاہٹ کے اپنے بنیادی ڈھانچے کو کوڈ میں بیان کر سکتے ہیں۔

بہر حال، درخواست چھوڑ دیتا ہے اور کچھ بھی واپس نہیں آتا ہے۔

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

سچائی کسی بھی چیز سے زیادہ آسان اور قابل عمل ہے۔ بھرتی کرنے والے مینیجر آپ کی YouTube دیکھنے کی سرگزشت نہیں دیکھ سکتے ہیں۔ وہ آپ کا GitHub دیکھ سکتے ہیں۔ زیادہ تر ابتدائی افراد سیکھنے کے لیے موزوں ہیں۔ بھرتی کیے گئے امیدوار ثبوت کے لیے بہتر بناتے ہیں۔

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

انڈیکس

تین نمونے جو ابتدائیوں کو پھنسے رکھتے ہیں۔

پیٹرن 1: ٹیوٹوریل لوپ

ہفتہ 1: ڈوکر مواد کے 8 گھنٹے دیکھیں۔ ہفتہ 2: AWS کورس شروع کریں اور اس کا 70% مکمل کریں۔ ہفتہ 3: میں اس کے بجائے Kubernetes سیریز شروع کر رہا ہوں کیونکہ یہ دلچسپ لگتا ہے۔ ہفتہ 4: آپ LinkedIn کھولتے ہیں اور حیران ہوتے ہیں کہ آپ کو کال بیک کیوں نہیں مل رہا ہے۔

سبق دیکھنا ترقی کی طرح محسوس ہوتا ہے۔ یہ آرام دہ، غیر فعال ہے اور اس میں ناکامی کی کوئی حالت نہیں ہے۔ کچھ نہیں ٹوٹتا۔ کچھ بھی غلط نہیں ہوتا۔

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

پیٹرن 2: تھیوری اور پریکٹس کے درمیان فرق

روانی سے CI/CD کی وضاحت کر سکتے ہیں۔ میں نے Kubernetes دستاویزات پڑھی ہیں۔ میں کنٹینرز اور ورچوئل مشینوں کے درمیان تصوراتی فرق کو سمجھتا ہوں۔

لیکن آپ نے کبھی بھی کوئی سادہ ایپلیکیشن نہیں لی، اسے کنٹینرائز کیا، اسے پائپ لائن سے منسلک کیا، اور پھر اسے ایک حقیقی URL کے ساتھ کلاؤڈ سرور پر تعینات کیا جسے کوئی دیکھ سکتا ہے۔

ایک انٹرویو میں، "میں سمجھتا ہوں کہ یہ کیسے کام کرتا ہے” اور "میں نے اسے بنایا ہے اور لنک یہ ہے” مساوی جوابات نہیں ہیں۔ بھرتی کرنے والے مینیجرز سینکڑوں امیدواروں کے پہلے ورژن سنتے ہیں۔ دوسرا ورژن کال بیک لیتا ہے۔

پیٹرن 3: خاموش سیکھنا

یہ شاید سب سے زیادہ تکلیف دہ نمونہ ہے کیونکہ سیکھنا حقیقی ہے۔ آپ روزانہ کام کرتے ہیں اور کوئی نہیں جانتا۔ کوئی GitHub سرگرمی نہیں ہے۔ کوئی LinkedIn پوسٹس نہیں ہیں۔ معاشرے میں اس کا کوئی وجود نہیں ہے۔ یہ صرف ایک کولڈ ایپلی کیشن ہے جو جاب بورڈ سے اے ٹی ایس سسٹم کو بھیجی گئی ہے جو آپ کا نام دیکھنے سے پہلے ہی آپ کو فلٹر کر دیتی ہے۔

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

ہائرنگ مینیجرز واقعی کس چیز کا اندازہ لگاتے ہیں۔

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

بالٹی	آستین	بنیادی عنصر
سوچنے کا طریقہ	آپ مسئلہ اور اپنے کیریئر کے بارے میں کیا سوچتے ہیں؟	عوامل 2، 7، 8، 9
پھانسی	اصل میں تعمیر اور مظاہرہ	عوامل 1 اور 3
گھڑی	چاہے صحیح لوگ جانتے ہیں کہ آپ موجود ہیں۔	عوامل 4، 5، اور 6

آئیے ہر ایک پر ایک نظر ڈالیں۔

عنصر 1: کام کا ثبوت (غیر گفت و شنید)

اس پورے مضمون سے ایک نکتہ یہ ہے: کوئی پورٹ فولیو کا مطلب ہے کوئی سنجیدہ غور نہیں۔ درخواست دہندگان کے پول میں سب سے زیادہ تکنیکی طور پر قابل امیدوار کام کے ثبوت کے بغیر پوشیدہ ہیں۔

یہ پیچیدہ لوگوں کو متاثر کرنے کے بارے میں نہیں ہے۔ یہ ظاہر کرتا ہے کہ سسٹم کو شروع سے ہی تعینات، دستاویزی اور آپریشنل کیا جا سکتا ہے۔

یہاں ایک چیک لسٹ ہے جو ہر پورٹ فولیو پروجیکٹ کو پورا کرنا ضروری ہے اس سے پہلے کہ آپ اسے مکمل سمجھ سکیں:

• تقسیم کیا گیا ہے: ایک حقیقی URL ہے جسے آپ شیئر کر سکتے ہیں، نہ کہ صرف "یہ میرے کمپیوٹر پر کام کرتا ہے”۔

• میرے پاس CI/CD پائپ لائن ہے۔: کوڈ کی تبدیلیاں خود بخود جانچ اور تعینات کی جاتی ہیں۔

• انفراسٹرکچر کوڈ میں بیان کیا گیا ہے۔: AWS کنسول میں دستی طور پر ان پر کلک کیے بغیر

• اس میں نگرانی اور انتباہ کے افعال ہیں۔: صارفین کے بتانے سے پہلے جانیں کہ مسائل کب پیش آتے ہیں۔

• یہ دستاویزی ہے۔: README وضاحت کرتا ہے کہ یہ کیا کرتا ہے، اسے کیسے چلانا ہے، اور یہ کیسے کام کرتا ہے۔

• یہ GitHub پر عوامی طور پر دستیاب ہے۔: بار بار کاموں کو ظاہر کرنے والی اصل کمٹ ہسٹری شامل ہے۔

اگر آپ کا پروجیکٹ تمام چھ معیارات پر پورا اترتا ہے، تو یہ کام کا ثبوت بن جاتا ہے۔ اگر 6 میں سے 4 مل جاتے ہیں، تو پروجیکٹ آگے بڑھ رہا ہے۔ براہ کرم اپنی درخواست شروع کرنے سے پہلے اسے مکمل کریں۔

تین منصوبے جو اس سب کا احاطہ کرتے ہیں۔

آپ کو 10 منصوبوں کی ضرورت نہیں ہے۔ آپ کو 2-3 پروجیکٹس کی ضرورت ہوگی جو ایک ساتھ DevOps ٹیکنالوجیز کی مکمل رینج کا مظاہرہ کریں۔

پروجیکٹ 1: مکمل اسٹیک تعیناتی پائپ لائن

یہ ایک بنیادی DevOps پروجیکٹ ہے جسے ہر ابتدائی کو پہلے بنانا چاہیے۔

ایک سادہ ویب ایپلیکیشن کا انتخاب کریں، جیسے کہ Python Flask ایپ، Node.js API، یا جامد سائٹ۔ ڈوکر کے ساتھ کنٹینرائز کریں۔ ایک CI/CD پائپ لائن لکھیں جو آپ کے ٹیسٹ چلاتی ہے، ایک Docker امیج بناتی ہے، اور جب بھی آپ اپنی مین برانچ کی طرف دھکیلتے ہیں تو اسے خود بخود آپ کے کلاؤڈ سرورز پر تعینات کر دیتی ہے۔ آپ Nginx کو ریورس پراکسی کے طور پر بھی ترتیب دے سکتے ہیں اور ایک اپ ٹائم مانیٹر شامل کر سکتے ہیں (UptimeRobot میں مفت درجے کا ہوتا ہے)۔

ٹولز: GitHub ایکشنز، Docker، AWS EC2 یا Render.com، Nginx۔

مینیجرز کی خدمات حاصل کرنے سے یہ کیوں اہمیت رکھتا ہے: اس سے ثابت ہوتا ہے کہ تعیناتی کا پورا ورک فلو شروع سے آخر تک خودکار ہو سکتا ہے۔ ہائرنگ مینیجرز آپ کے URL پر جا کر دیکھ سکتے ہیں کہ کیا چل رہا ہے اور آپ کی پائپ لائن کی سرگزشت کا معائنہ کر سکتے ہیں۔

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

پروجیکٹ 2: ٹیرافارم کے ساتھ کوڈ کے طور پر انفراسٹرکچر

ایک مکمل ماحول فراہم کرنے کے لیے ٹیرافارم کوڈ لکھیں، بشمول ایک VPC، پبلک اور پرائیویٹ سب نیٹس، مناسب حد تک حفاظتی گروپ کے قوانین کے ساتھ EC2 مثالیں، اور دور دراز صحت کے لیے S3 بالٹی۔ یہ دیکھنے کے لیے کہ آیا آپ کا کوڈ واقعی کام کرتا ہے، اسے حذف کریں اور اسے شروع سے دوبارہ بنائیں۔ ایک GitHub ایکشن ورک فلو شامل کریں جو چلتا ہے۔ terraform plan کھینچنے کی درخواست اور terraform apply مین میں ضم ہونے پر۔

ٹولز: Terraform، AWS (یا Azure/GCP)، GitHub ایکشنز۔

یہ کیوں اہمیت رکھتا ہے: ٹیرافارم کے ساتھ کوڈ کے طور پر انفراسٹرکچر کلاؤڈ انفراسٹرکچر چلانے والی تقریباً ہر کمپنی کے لیے ضروری مہارت ہے۔ یہ ظاہر کرنا کہ آپ لکھ سکتے ہیں، ورژن کنٹرول کر سکتے ہیں، اور Terraform کو خودکار کر سکتے ہیں، بنیادی پیشہ ورانہ صلاحیتوں کو ظاہر کرتا ہے۔

پروجیکٹ 3: نگرانی اور مشاہداتی اسٹیک

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

ٹولز: پرومیتھیس، گرافانا، الرٹ مینیجر، نوڈ ایکسپورٹ، ڈوکر کمپوز۔

یہ کیوں اہمیت رکھتا ہے: زیادہ تر ابتدائی پورٹ فولیوز مشاہدے کا کوئی کام بالکل نہیں کرتے ہیں۔ یہ پروجیکٹ فوری طور پر ظاہر کرتا ہے کہ آپ پروڈکشن انجینئرنگ کے ساتھ ساتھ تعیناتی کو بھی سمجھتے ہیں۔ آپ کی درخواست کا جائزہ لینے والا کوئی بھی سینئر DevOps انجینئر یا SRE اس کا نوٹس لے گا اور آپ کو نمایاں کرے گا۔

عنصر 2: نظام کی سطح کی سوچ

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

یہاں کچھ ذہنی ٹیسٹ ہیں جو بھرتی کرنے والے مینیجرز پورے انٹرویو میں چلتے ہیں: کیا آپ صارف کی درخواست کو اس لمحے سے ٹریس کر سکتے ہیں جب صارف بٹن پر کلک کرتا ہے اس لمحے تک جب وہ جواب دیکھتے ہیں، اور وضاحت کر سکتے ہیں کہ درمیان میں ہر پرت پر کیا ہوتا ہے؟

یہاں ایک ویب درخواست کا مکمل سفر ہے، ایک جدید انفراسٹرکچر کا نقشہ جو ہر DevOps انجینئر کو سمجھنا چاہیے۔

قدم	فرش	کیا ہو رہا ہے اور کیا غلط ہو سکتا ہے؟
1	آپ کا براؤزر	صارف یو آر ایل داخل کرتا ہے۔ براؤزر کو سرور تلاش کرنا ہوگا۔
2	DNS کی توثیق	ڈومینز کو آئی پی ایڈریسز میں تبدیل کیا جاتا ہے۔ اگر آپ کا DNS کنفیگریشن غلط ہے تو آپ کے صارفین آپ سے بالکل بھی رابطہ نہیں کر سکیں گے۔
3	سی ڈی این / ایج نیٹ ورک	ٹریفک پہلے CDN (Cloudflare، CloudFront) تک پہنچتی ہے۔ جامد اثاثے قریب ترین کنارے سے پیش کیے جاتے ہیں۔ SSL یہاں ختم ہوتا ہے۔
4	لوڈ بیلنسر	دستیاب ایپلیکیشن سرورز کی درخواستوں کو روٹ کرتا ہے۔ اگر تمام اہداف غیر صحت بخش ہیں، تو صارفین کو 502/503 غلطی موصول ہوگی۔
5	کمپیوٹ/ایپلی کیشن سرور	ایپلیکیشن کوڈ کنٹینرز، VMs، یا سرور لیس فنکشنز میں چلتا ہے۔ کاروباری منطق پر عمل کیا جاتا ہے۔
6	ڈیٹا بیس پرت	ایک درخواست ڈیٹا بیس سے پڑھتی ہے یا لکھتی ہے۔ سست سوالات یا مکمل ڈسک کے نتیجے میں سست ردعمل یا بندش ہوتی ہے۔
7	کیشے پرت	Redis یا Memcached کیشے اکثر ڈیٹا کو پڑھتے ہیں۔ کیشے کی کمی اضافی ڈیٹا بیس بوجھ کا سبب بنتی ہے۔
8	جواب واپس	جواب اسٹیک کو بیک اپ لے جاتا ہے اور صارف نتیجہ دیکھتا ہے۔
9	لاگنگ اور مانیٹرنگ	مندرجہ بالا تمام مراحل کے لیے لاگز اور میٹرکس برآمد کرنے کی ضرورت ہے۔ اچھی نگرانی صارفین کو مسائل دریافت کرنے سے پہلے انتباہ کرتی ہے۔

انٹرویو میں یہ کیوں ضروری ہے؟ ایک سوال کا جواب دینے والے دو امیدواروں پر غور کریں۔ "براہ کرم ہمیں بتائیں کہ کیا پروڈکشن کے دوران کوئی مسئلہ پیش آیا ہے۔”

امیدوار A: "ویب سائٹ بند ہے۔”

امیدوار B: "پچھلی تعیناتی میں میموری لیک ہونے کی وجہ سے ایپ کنٹینر کی میموری ختم ہوگئی، جس کی وجہ سے لوڈ بیلنس کی صحت کی جانچ ناکام ہوگئی۔ ہم نے گرافانا کے میموری میٹرکس کے ذریعے اس کی نشاندہی کی، اسے واپس کر دیا، اور کنٹینر کی خصوصیت میں میموری کی حد شامل کی۔”

ایک ہی واقعہ۔ یہ بالکل مختلف جواب ہے۔ سسٹمز کی سطح کی سوچ میں فرق پڑتا ہے۔

عنصر 3: سافٹ ویئر انجینئرنگ کے بنیادی اصول

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

یہاں وہ بنیادی باتیں ہیں جو واقعی اہم ہیں، اور اگر ان میں سے کوئی غائب ہو تو کیا کرنا چاہیے۔

1. لینکس اور کمانڈ لائن

DevOps ٹولز لینکس پر چلتے ہیں۔ CI/CD جابز لینکس کنٹینرز میں چلتی ہیں۔ SSH ہر سرور کا سامنے کا دروازہ ہے۔ اگر آپ ٹرمینل کے ساتھ آرام دہ نہیں ہیں، تو آپ پیداواری ماحول کے لیے تیار نہیں ہیں۔ یہ ایک ضرورت ہے، ترجیح نہیں۔

ہر روز لینکس کی مشق کرنا شروع کریں۔ لینکس فاؤنڈیشن کا مفت تعارفی مواد ایک ٹھوس نقطہ آغاز ہے۔ اور یہاں لینکس کی بنیادی باتوں پر ایک ٹھوس فری کوڈ کیمپ کورس ہے۔

2. نیٹ ورکنگ کی بنیادی باتیں

DNS، TCP/IP، HTTP/HTTPS، لوڈ بیلنسنگ، فائر والز، VPC، سب نیٹ۔ یہ تصورات تمام کلاؤڈ فن تعمیر میں ظاہر ہوتے ہیں۔ ان کے بغیر، Terraform اور Kubernetes جادو کے خانے ہیں۔ اوپر والے عنصر 2 میں درخواست کے بہاؤ کا مطالعہ کریں جب تک کہ آپ اسے دیکھے بغیر میموری سے کھینچ نہ لیں۔

شروع کرنے میں آپ کی مدد کے لیے یہاں کمپیوٹر نیٹ ورکنگ کی بنیادی باتوں کا کورس ہے۔

3. اسکرپٹ: Bash اور Python

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

یہاں ابتدائیوں کے لیے لینکس شیل اسکرپٹنگ پر ایک مفید ٹیوٹوریل ہے۔

4. گٹ اور ورژن کنٹرول

ہاں git commit اور git push. برانچنگ کی حکمت عملی، پل کی درخواستیں، تنازعات کو ضم کرنا، ری بیسز، اور ٹیگ شدہ ریلیز پیشہ ورانہ ڈی او اوپس ٹیموں کے لیے تمام معیاری طریقے ہیں۔ اپنے ذاتی مطالعہ کے نوٹس سمیت ہر چیز کے لیے Git کا استعمال کریں۔ جان بوجھ کر برانچنگ ورک فلو کی مشق کریں۔

یہاں ان تمام Git بنیادی باتوں پر ایک مکمل کتاب ہے جن کی آپ کو جاننے کی ضرورت ہے (اور کچھ مزید جدید عنوانات)۔

5. ڈوکر اور کنٹینرز

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

شروع کرنے میں آپ کی مدد کے لیے یہاں کچھ Docker اور Kubernetes کورسز ہیں:

عنصر 4: مواصلات کی مہارت

تکنیکی مہارت آپ کی حدود کا تعین کرتی ہے۔ آپ کی مواصلات کی مہارت اس بات کا تعین کرتی ہے کہ آپ کتنی جلدی اپنے مقاصد تک پہنچ جاتے ہیں۔ یہ انٹری لیول DevOps امیدواروں میں سب سے زیادہ مستقل طور پر کم سمجھا جانے والا عنصر ہے۔

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

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

سمجھوتہ اظہار: "میں نے Y کے بجائے X کا انتخاب کرنے کی وجہ یہ ہے…” یہ تکنیکی انٹرویو میں سب سے زیادہ طاقتور جملے میں سے ایک ہے۔ اس سے ظاہر ہوتا ہے کہ آپ سمجھتے ہیں کہ ہر فیصلے کے فائدے اور نقصانات ہوتے ہیں اور یہ کہ آپ نے محض ٹیوٹوریل کاپی کرنے کے بجائے شعوری، عقلی انتخاب کیا ہے۔

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

ایک آسان ٹیسٹ یہ ہوگا: GitHub پر اپنا سب سے حالیہ پروجیکٹ کھولیں اور README کو اس طرح پڑھیں جیسے یہ ہائرنگ مینیجر پہلی بار دیکھ رہا ہو۔ کیا یہ آپ کے سوال کا جواب دیتا ہے؟

• یہ پروجیکٹ کیا کرتا ہے اور آپ نے اسے کیوں بنایا؟

• فن تعمیر کیسا لگتا ہے؟

• میں اسے مقامی طور پر کیسے چلا سکتا ہوں اور اسے کیسے تعینات کروں؟

• آپ نے کیا فیصلہ کیا اور کیوں کیا؟

• اگر آپ کوشش کرتے رہیں تو آپ کیا بہتر کر سکتے ہیں؟

اگر آپ نے ان میں سے دو یا زیادہ کا جواب "نہیں” میں دیا ہے، تو براہ کرم درخواست دینے سے پہلے README کو دوبارہ لکھیں۔ یہ واحد عمل ردعمل کی شرح کو نمایاں طور پر بہتر بناتا ہے۔

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

فیکٹر 5: شدت سے زیادہ مستقل مزاجی

ہائرنگ مینیجرز پیٹرن کی شناخت کرنے والی مشینیں ہیں۔ وہ آپ کے ریزیومے پر ایک لفظ پڑھنے سے پہلے ایک تاثر بنانے کے لیے آپ کے GitHub شراکت کے گراف، LinkedIn کی سرگرمی، اور سیکھنے کی رفتار کو دیکھتے ہیں۔

binge Learning اپروچ، ہفتے کے آخر میں 10 گھنٹے اور اس کے بعد ہفتوں کچھ بھی نہیں، نتیجہ ایک GitHub گراف کی صورت میں نکلتا ہے جو آپ کو بتاتا ہے کہ کیا غلط ہے۔ 6 مہینوں تک روزانہ 30 منٹ کے لیے فوکسڈ پریکٹس مہینے میں 10 گھنٹے کھانے سے بہتر ہے۔ چھ ماہ تک، ایک دن کا پریکٹیشنر 90 گھنٹے کا گہرا کام مکمل کر لے گا۔ Binge سیکھنے والوں میں نمایاں طور پر بدتر برقرار تھا، جس نے 60 اسکور کیا۔

عملی طور پر مستقل مزاجی پیدا کرنے کا طریقہ یہاں ہے:

• دن کا وہ وقت منتخب کریں جس کی آپ حفاظت کرنا چاہتے ہیں۔ ترقی کے لیے 30 منٹ کافی ہیں۔

• ایک خاص مقصد کے ساتھ چار ہفتے کے سیکھنے کے اسپرنٹ کی وضاحت کریں: "Terraform کا استعمال کرتے ہوئے ایک VPC بنائیں اور تعینات کریں اور ایک README لکھیں، نہ کہ "Terraform سیکھیں۔”

• ذاتی مطالعہ کا جریدہ رکھیں۔ تاریخیں لکھیں، آپ نے کیا مطالعہ کیا، آپ نے کیا تخلیق کیا، آپ کو کس چیز نے الجھا دیا، وغیرہ۔

• سپرنٹ کے اختتام پر، اس بات کا اندازہ لگائیں کہ آپ نے کیا بنایا ہے اور منصوبہ بنائیں کہ آگے کیا ہے۔

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

عنصر 6: نیٹ ورکنگ اور مرئیت

یہ وہ عنصر ہے جس سے زیادہ تر ابتدائی لوگ سب سے زیادہ انکار کرتے ہیں اور وہ ہے جو ملازمت کے وقت میں سب سے بڑا حقیقی فرق پیدا کرتا ہے۔

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

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

ان کمیونٹیز میں شامل ہوں جہاں DevOps انجینئرز حقیقت میں بات کرتے ہیں: AWS صارف گروپس، مقامی DevOps میٹ اپس، DevOps Discord سرورز، اور Reddit کمیونٹیز جیسے r/devops اور r/kubernetes۔ آپ کو ماہر بننے کی ضرورت نہیں ہے۔ مخصوص سوالات پوچھیں، جو آپ واقعی جانتے ہیں اس کے جواب دیں، اور مستقل طور پر دکھائیں۔ 3-6 ماہ بعد لوگ آپ کا نام پہچان لیں گے۔

لنکڈ ان مواد

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

عوامی سطح پر اچھے سوالات پوچھیں۔

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

یہاں ایک ٹھوس تین ماہ کی مرئیت سپرنٹ ہے:

مدت	کارروائی
ہفتہ 1~2	اپنی LinkedIn کی سرخی کو اپ ڈیٹ کریں: "کلاؤڈ/DevOps انجینئرز ٹریننگ میں │ AWS، Docker، اور Terraform کے ساتھ عمارت”۔ 20 DevOps انجینئرز، بھرتی کرنے والوں، ہائرنگ مینیجرز، اور مزید کے ساتھ جڑیں۔ جڑتے وقت ایک مختصر ذاتی نوٹ شامل کریں۔
ہفتہ 3~4	اپنی پہلی LinkedIn پوسٹ لکھیں۔ دستاویز کریں جو آپ نے اس ہفتے بنایا یا سیکھا۔ ایماندار اور مخصوص بنیں۔ 150-200 الفاظ کافی ہونے چاہئیں۔
2 ماہ	ایک کمیونٹی میں شامل ہوں۔ براہ کرم اپنا تعارف کروائیں۔ ہفتے میں ایک سوال کا جواب دیں۔
3 ماہ	ہفتے میں ایک بار مسلسل پوسٹ کریں۔ دوسرے لوگوں کی پوسٹس کے ساتھ مشغول ہونے کی کوشش کریں۔ بھرتی کرنے والوں کی تلاش میں ظاہر ہونا شروع کریں۔

تین مہینوں کے بعد، آپ کی سرگرمی آپ کے علاقے میں "DevOps” تلاش کرنے والے بھرتی کرنے والوں کے ذریعے دیکھی جائے گی۔ کچھ بہترین داخلہ سطح کے DevOps مواقع صرف اس قسم کی کم مرئیت سے آتے ہیں۔

عنصر 7: ملکیت

یہ عنصر شخصیت کی قسم کے مقابلے میں قابل مشاہدہ رویے کے قریب ہے۔ بھرتی کرنے والے مینیجرز اس بات کا ثبوت تلاش کر رہے ہیں کہ آپ نے جو کام شروع کیا ہے اسے مکمل کر لیا ہے، نہ کہ صرف اس بات کا ثبوت کہ آپ نے کام شروع کر دیا ہے۔

اس کے برعکس مندرجہ ذیل ہے:

جو HR مینیجرز اکثر دیکھتے ہیں۔	HR مینیجرز کیا دیکھنا چاہتے ہیں۔
"میں نے ایک Kubernetes پروجیکٹ شروع کیا اور بہت ساری پریشانیوں کا سامنا کرنا پڑا۔”	"یہ ایک مکمل پروجیکٹ ہے، AWS پر تعینات، CI/CD پائپ لائن کے ساتھ، نگرانی کی گئی، اور اب اس URL پر قابل رسائی ہے۔”
"میں نے ٹیرافارم کورس کے ذریعے کام کرتے ہوئے XYZ کے بارے میں بہت کچھ سیکھا۔”	"میں نے اسے ختم کیا، اسے دستاویزی شکل دی، اور جو کچھ میں نے سیکھا اس کے بارے میں لکھا۔”

ملکیت کے تین اجزاء ہیں۔ سب سے پہلے، کام کرو. ایک مکمل اور سادہ منصوبہ 10 نامکمل اور پیچیدہ منصوبوں سے 10 گنا زیادہ قیمتی ہے۔ دوسرا، جب کوئی مسئلہ پیش آتا ہے، تو آپ کو الزام لگائے بغیر ذمہ داری قبول کرنی چاہیے۔ ملکیت کا مطلب ہے وجہ کی نشاندہی کرنا، اسے ٹھیک کرنا، اور اسے دوبارہ ہونے سے روکنے کے لیے نگرانی شامل کرنا۔ تیسرا، اس بات کا انتظار نہ کریں کہ کوئی اور آپ کو بتائے کہ آگے کیا سیکھنا ہے۔ اپنی سیکھنے کی سمت کا انتخاب کریں۔ خلا کو دیکھیں، شناخت کریں کہ اسے کیسے بند کیا جائے، اور اسے بند کریں۔ ملازمت کی تفصیل میں ‘جونیئر جو آزادانہ طور پر کام کر سکتا ہے’ کا اصل مطلب ہے۔

عنصر 8: کاروباری بیداری

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

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

یہاں کچھ بینچ مارک سوالات ہیں جو آپ آرام سے جواب دے سکتے ہیں۔

• اگر آپ کی کمپنی کے پاس 99.9% SLA ہے، تو اسے ہر ماہ کتنے منٹ کا ڈاؤن ٹائم لگے گا؟ (تقریباً 43 منٹ)

• آن ڈیمانڈ EC2 مثالوں سے محفوظ مثالوں میں کام کے بوجھ کو منتقل کرنے کی تخمینی لاگت کی بچت کیا ہے؟ (تقریباً 40-60%)

• اگر آپ کی CI/CD پائپ لائن فی تعمیر میں 45 منٹ لیتی ہے اور روزانہ 20 بلڈز چلاتی ہے، تو آپ کے پاس ہر ہفتے ڈویلپر کے انتظار کا کتنا وقت ہوگا؟

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

بنانے کی ایک سادہ عادت: جب بھی آپ پروجیکٹ دستاویزات یا انٹرویوز میں تکنیکی فیصلوں کی وضاحت کرتے ہیں تو ایک کاروباری جہت شامل کریں۔ "ہم نے آٹو اسکیلنگ کو کنفیگر کیا” بن جاتا ہے "ہم نے ٹریفک میں اضافے کو سنبھالنے کے لیے آٹو اسکیلنگ کو کنفیگر کیا، زیادہ پروویژننگ کے اخراجات کو ختم کیا اور اپنے تخمینی ماہانہ کلاؤڈ اخراجات کو تقریباً $X تک کم کیا۔”

عنصر 9: سیکھنے کی چستی

ہر کوئی جلدی سیکھنے والا ہونے کا دعوی کرتا ہے۔ یہ تکنیکی درخواست فارم میں سب سے زیادہ استعمال ہونے والا جملہ ہے۔ اسے حقیقت میں سمجھنے کا طریقہ یہاں ہے:

انٹرویو میں یہ کہنا بہت ضروری ہے کہ "میں ایک تیز سیکھنے والا ہوں”۔ سوال یہ ہے کہ کیا یہ ثابت ہو سکتا ہے؟ ثبوت درج ذیل ہے: "میں نے پہلے کبھی GitHub ایکشنز کا استعمال نہیں کیا تھا۔ مجھے ایک پراجیکٹ کے لیے ایک CI/CD پائپ لائن کی ضرورت تھی جو میں بنا رہا تھا۔ 48 گھنٹوں میں، میرے پاس کام کرنے والی پائپ لائن چل رہی تھی، Docker امیجز بنانا، اور AWS پر تعینات تھا۔”

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

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

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

90 دن کا ایکشن پلان

آپ کو اپنے پہلے DevOps انٹرویو کے لیے جہاں سے تیار ہونا ہے وہاں سے لے جانے کے لیے یہاں ایک مخصوص، ترتیب وار منصوبہ ہے۔

مہینہ 1: فاؤنڈیشن کی تعمیر

پروف آف ورک سیکشن میں پروجیکٹ 1 پر پوری توجہ مرکوز کریں۔ اسے مکمل طور پر بنائیں۔ اسے تقسیم کریں۔ ریئل ٹائم URL حاصل کریں۔ پروجیکٹ 2 شروع نہ کریں جب تک کہ پروجیکٹ 1 چیک لسٹ کے تمام چھ معیارات پر پورا نہ اترے۔

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

مہینہ 2: پیمانے پر عمل درآمد کریں اور مرئیت حاصل کرنا شروع کریں۔

پروجیکٹ 2 شروع کریں (Terraform IaC)۔ اپنی پہلی LinkedIn پوسٹ لکھیں۔ اسے وسیع ہونے کی ضرورت نہیں ہے، اسے صرف مخصوص ہونے کی ضرورت ہے۔ ایک کمیونٹی میں شامل ہوں اور اپنا تعارف کروائیں۔

مہینہ 3: اپنا پورٹ فولیو مکمل کریں اور ہر چیز کو دستاویز کریں۔

تینوں پروجیکٹس کو مکمل چیک لسٹ معیارات پر مکمل کریں۔ تمام READMEs کو پولش کریں۔ ایک فن تعمیر کا خاکہ شامل کریں۔ اپنے GitHub پروفائل کو بہتر بنائیں، اپنے بہترین تین ریپوزٹریوں کو پن کریں، ایک پروفائل README لکھیں جس میں یہ بتایا جائے کہ آپ کون ہیں اور آپ کیا بناتے ہیں، اور اپنے لائیو پروجیکٹ URL میں ایک لنک شامل کریں۔

4 مہینے کے بعد: حکمت عملی بنائیں اور اسے لاگو کریں۔

اپنی درخواست 4 ماہ سے پہلے شروع نہ کریں۔ براہ کرم کام کے اصل ثبوت کے ساتھ درخواست دیں۔ فی ہفتہ 100 کی بجائے 5 سے 10 اعلیٰ معیار کی ایپلی کیشنز کا ہدف رکھیں۔ GitHub سے لائیو یو آر ایل اور ہر ایپلیکیشن میں اپنے بہترین پروجیکٹس شامل کریں۔ کمیونٹی کنکشن والی کمپنیوں میں کردار کے لیے، درخواست دینے سے پہلے ان سے رابطہ کریں۔

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

90 دن کا مکمل تجزیہ یہ ہے:

مدت	توجہ مرکوز	اہم قدم
ہفتہ 1~2	لینکس کی بنیادی باتیں۔ اپنا GitHub پروفائل ترتیب دیں۔ پروجیکٹ 1 شروع کریں۔	کی بنیاد پر
ہفتہ 3~4	پروجیکٹ 1 CI/CD پائپ لائن کو مکمل کریں۔ تقسیم ریئل ٹائم URL حاصل کریں۔ براہ کرم README لکھیں۔	کام کا پہلا ثبوت
2 ماہ	پروجیکٹ 2 شروع کریں۔ یہ میری پہلی LinkedIn پوسٹ ہے۔ ایک کمیونٹی میں شامل ہوں۔	مرئیت شروع ہوتی ہے۔
2 ~ 3 ماہ	مکمل پروجیکٹ 2. سہاروں کی نگرانی (پروجیکٹ 3)۔ LinkedIn پر ہفتہ وار پوسٹ کریں۔	بلڈنگ مومنٹم
3 ماہ	چیک لسٹ معیارات کے لیے تینوں منصوبوں کو مکمل کریں۔ پولش README اور GitHub پروفائل۔	پورٹ فولیو کی تکمیل
4 ماہ یا اس سے زیادہ	حکمت عملی سے درخواست کریں۔ پوسٹ کرتے رہیں اور کمیونٹی میں حصہ لیتے رہیں۔	فعال ملازمت کی تلاش

ایماندارانہ خود تشخیص: آپ کہاں کھڑے ہیں؟

ذیل میں ہر ایک بیان کو دیکھیں۔ پوری طرح ایماندار رہو۔ یہ آپ کے لیے ہے، کسی اور کے لیے نہیں۔

نام	اگر جواب نفی میں ہو تو کیا کریں۔
ویب درخواستوں کو آخر سے آخر تک بیان کیا جا سکتا ہے (DNS → لوڈ بیلنسر → کمپیوٹ → ڈیٹا بیس → لاگ)۔	عنصر 2 کا مطالعہ کریں جب تک کہ آپ اسے میموری سے نہیں کھینچ سکتے۔
لائیو یو آر ایل کے ساتھ کم از کم ایک تعینات شدہ پروجیکٹ ہے۔	یہ ترجیح ہے 1۔ ابھی کچھ بھی زیادہ اہم نہیں ہے۔
میرے بہترین پروجیکٹس میں CI/CD پائپ لائنز ہیں جو خود بخود پش پر لگ جاتی ہیں۔	اسے اس ہفتے اپنے موجودہ پروجیکٹس میں شامل کریں۔
تحریری بنیادی ڈھانچہ بطور کوڈ (Terraform یا CloudFormation)۔	پروجیکٹ 2 اگلا تعمیراتی ہدف ہے۔
میرے پروجیکٹ میں ایک README ہے جو فن تعمیر اور فیصلوں کی وضاحت کرتا ہے۔	README کو دوبارہ لکھنے کے لیے آج ایک گھنٹہ نکالیں۔
گزشتہ 30 دنوں میں لنکڈ ان پر سیکھنے کا مواد شائع کیا گیا۔	آج ہی کچھ پوسٹ کریں اور جو کچھ آپ نے پچھلے ہفتے لکھا اسے دستاویز کریں۔
میرا تعلق ایک سے زیادہ DevOps کمیونٹی سے ہے۔	اس ہفتے r/devops یا AWS Discord سرور میں شامل ہوں۔
آپ باش اسکرپٹ لکھ سکتے ہیں جو حقیقی دنیا کے آٹومیشن کے مسائل کو حل کرتی ہیں۔	اگلے 30 دنوں تک ہر روز 30 منٹ تک اپنی اسکرپٹ کی مشق کریں۔
میں وضاحت کر سکتا ہوں کہ میں نے کیا بنایا، میں نے ہر فیصلہ کیوں کیا، اور میں کیا تبدیل کروں گا۔	ہر پروجیکٹ کو اونچی آواز میں کہنے کی مشق کریں جب تک کہ آپ روانی نہ بن جائیں۔

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

نتیجہ

یہاں وہ ہے جو زیادہ تر ابتدائی افراد ابھی تک نہیں جانتے ہیں:

آپ کے اور DevOps جاب کے درمیان فرق سرٹیفیکیشنز میں فرق، آپ کے مکمل کیے گئے کورسز میں فرق، یا آپ نے جن ٹولز کے بارے میں سنا ہے ان کی تعداد میں فرق نہیں ہے۔ کام کے ثبوت، مرئیت، اور عملدرآمد کی مستقل مزاجی میں فرق ہیں۔

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

راستہ کوئی راز نہیں ہے۔ یہ صرف ایک چیز ہے۔ 2-3 مکمل پروجیکٹس بنائیں جو پوری چیک لسٹ پر پورا اتریں۔ ہر چیز کی دستاویز کریں۔ اپنی کمیونٹی میں اور LinkedIn پر نظر آتے رہیں۔ حکمت عملی بنائیں اور اسے لاگو کریں۔ آراء کی بنیاد پر اعادہ کریں۔

اگر آپ اپنے DevOps سفر کو سپورٹ کرنے کے لیے پیداواری سطح کا حوالہ چاہتے ہیں جس میں حقیقی Terraform ماڈیولز، CI/CD ورک فلو ٹیمپلیٹس، بنیادی ڈھانچے کی رن بکس، اور حقیقی آغاز کے ماحول میں استعمال ہونے والے پلیٹ فارم انجینئرنگ کے نمونے شامل ہوں، تو Startup DevOps فیلڈ گائیڈ آپ کے کیریئر کے اسی مرحلے کے لیے بنایا گیا ہے۔

آپ اور آپ کے پہلے DevOps کردار کے درمیان معلومات کا فرق آپ کے خیال سے کم ہے۔ پھانسی کا فرق وہ جگہ ہے جہاں کام ہے۔ آج ہی شروع کریں۔

حوالہ جات اور تجویز کردہ وسائل