پروڈ کی تصدیق، ریلیز کی حکمت عملی اور اینڈ ٹو اینڈ AI ورک فلو

فائدہ:

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

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

اس حتمی یونٹ میں ہم دو چیزوں کو یکجا کرتے ہیں: (1) ریلیز کے طریقے جو خطرے کو کم کرتے ہیں (کینری، نیلے سبز، فیچر فلیگ) اور پروڈ کی تصدیق کا نظم و ضبط؛ (2) ہر ٹکڑا جو ہم نے پورے ماڈیول میں سیکھا — CI/CD، IaC، کنٹینر، نگرانی، واقعہ، لاگت، اسکرپٹ، سیکورٹی — ایک واحد AI سے چلنے والے اینڈ ٹو اینڈ ورک فلو میں اکٹھا ہوتا ہے۔ آئیے ابتدائی اقتباس کو ایک آخری بار دہراتے ہیں: AI ہر قدم پر ڈرافٹ تیار اور تیز کرتا ہے۔ لیکن آپ وہ ہیں جو "میں یہ لائیو لے رہا ہوں" کے بٹن کو دباتا ہے اور نتیجہ کی ضمانت دیتا ہے۔

ایسی حکمت عملی جاری کریں جو خطرے کو کم کرتی ہیں۔

ایک ہی وقت میں تمام صارفین پر تبدیلی کو آگے بڑھانا سب سے خطرناک طریقہ ہے۔ بالغ طریقے:

• بلیو-گرین تعیناتی: دو ایک جیسے ماحول کو برقرار رکھا جاتا ہے - "نیلا" (لائیو) اور "سبز" (نیا ورژن)۔ نیا ورژن سبز رنگ میں تیار اور آزمایا جاتا ہے، پھر ٹریفک کو اچانک سبز رنگ میں تبدیل کر دیا جاتا ہے۔ اگر کوئی مسئلہ ہو تو ٹریفک فوری طور پر نیلے رنگ کی ہو جاتی ہے۔ فاسٹ رول بیک اس کا سب سے بڑا فائدہ ہے۔
• کینری تعیناتی: نیا ورژن سب سے پہلے صارفین کی ایک چھوٹی فیصد کے لیے جاری کیا جاتا ہے (مثلاً 5%)؛ اگر میٹرکس اچھے ہیں تو آہستہ آہستہ 100% تک بڑھائیں۔ ایک مسئلہ صارف کے ایک چھوٹے سے ٹکڑے کو متاثر کرتا ہے، نہ کہ پورے صارف کو۔
• فیچر فلیگ: نیا فیچر کوڈ میں داخل ہوتا ہے لیکن جھنڈے کے ذریعے بلاک کر دیا جاتا ہے۔ جب درخواست کی جائے تو اسے بعض صارفین کے لیے کھول دیا جاتا ہے۔ تعیناتی اور "رہائی" کے درمیان فرق ہے؛ اگر کوئی مسئلہ ہے تو، جھنڈا کوڈ کو رول بیک کیے بغیر بند کر دیا جاتا ہے۔

ٹپ: تیز ترین حفاظتی جال یہ ہے کہ ہر تعیناتی سے پہلے ایک رول بیک تیار ہو۔ "اگر کچھ غلط ہو جاتا ہے، تو میں 60 سیکنڈ میں پرانے ورژن پر کیسے واپس جا سکتا ہوں؟" اگر سوال کا کوئی واضح جواب نہیں ہے، تو آپ اس تعیناتی کے لیے تیار نہیں ہیں۔

پروڈ کی تصدیق: تعیناتی ختم ہونے پر کام ختم نہیں ہوتا ہے۔

صرف اس لیے کہ ایک تعیناتی "سبز" نظر آتی ہے اس کا مطلب یہ نہیں ہے کہ یہ کام کر رہا ہے۔ منظم تصدیق:

1. صحت کی جانچ: کیا سروس بند ہے، کیا /healthz جواب دے رہا ہے؟
2. دھواں ٹیسٹ: کیا صارف کے چند انتہائی اہم راستے (لاگ ان، ادائیگی، تلاش) واقعی کام کرتے ہیں؟ خودکار اور تیز۔
3. سنہری اشاروں پر نگاہ رکھیں: پوسٹ ڈیپلائی ایرر ریٹ، لیٹنسی، کیا ٹریفک نارمل ہے؟ (یونٹ 6 پر چار سگنل۔)
4. دھیرے دھیرے پھیلائیں: ہر قدم پر میٹرکس کو دیکھیں جب آپ کینری فیصد بڑھاتے ہیں۔
5. آبزرویشن ونڈو: تعیناتی کے بعد ایک مدت (مثلاً 30 منٹ) کے لیے قریب سے نگرانی کریں؛ کپٹی مسائل فوری طور پر نظر نہیں آتے۔

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

ریلیز کی حکمت عملیوں کا موازنہ

حکمت عملی

اہم فائدہ

لاگت/پیچیدگی

سب سے زیادہ مناسب

بلیو گرین

فوری رول بیک

دو ماحول = 2x وسائل

اگر تیزی سے بازیافت ضروری ہے۔

کینری

اثر کو چھوٹے ٹکڑوں تک محدود کرتا ہے۔

ٹریفک مینجمنٹ کی ضرورت ہے۔

بہت بڑا صارف بیس

فیچر فلیگ

ریلیز سے الگ کرتا ہے۔

پرچم کے انتظام کا قرض

بتدریج/ہدف شدہ افتتاح

رولنگ اپ ڈیٹ

سادہ، وسائل کے موافق

سست رول بیک

سادہ خدمات

اینڈ ٹو اینڈ AI سے چلنے والا ورک فلو

اب آئیے پورے ماڈیول کو ایک فلو میں جوڑتے ہیں۔ مان لیں کہ آپ ایک نئی مائیکرو سروس شائع کر رہے ہیں۔ AI ہر قدم پر ڈرافٹ تیار کرتا ہے۔ آپ ہر قدم پر تصدیق کرتے ہیں:

1. کوڈ اور کنٹینر (یونٹ 4): AI ایک بہتر، محفوظ ڈاکر فائل تیار کرتا ہے۔ آپ غیر خفیہ اور سائز کی تصدیق کرتے ہیں۔
2. CI/CD (یونٹ 2): AI ٹیسٹ-build-deploy پائپ لائن لکھتا ہے؛ آپ اجازتوں کو کم کرتے ہیں اور خفیہ حوالوں کو چیک کرتے ہیں۔
3. انفراسٹرکچر (یونٹ 3): AI Terraform کے ساتھ مطلوبہ وسائل کی وضاحت کرتا ہے۔ آپ پلان آؤٹ پٹ کو پڑھتے ہیں اور غیر متوقع طور پر حذف ہونے کی تلاش نہیں کرتے ہیں۔
4. آرکیسٹریشن (یونٹ 5): AI Kubernetes مینی فیسٹس تیار کرتا ہے۔ آپ وسائل کی حد، تحقیقات، اور RBAC کی تصدیق کرتے ہیں۔
5. سیکیورٹی (یونٹ 10): AI اسکین آؤٹ پٹس کو ترجیح دیتا ہے۔ تم پہلے استحصال کرنے والوں کو پکڑو۔
6. مانیٹرنگ (یونٹ 6): AI الارم کے اصول اور ڈیش بورڈ تیار کرتا ہے۔ آپ اپنے ماضی کے ڈیٹا کے ساتھ حد کی جانچ کرتے ہیں۔
7. ریلیز اور توثیق (یہ یونٹ): AI سموک ٹیسٹ اور رول بیک پلان کا خاکہ؛ آپ کینری شروع کریں، میٹرکس دیکھیں، بٹن دبائیں۔
8. اگر واقعہ پیش آتا ہے (یونٹ 7): AI مفروضہ اور پوسٹ مارٹم خاکہ تیار کرتا ہے۔ آپ تصدیق کریں اور سبق سیکھیں۔
9. لاگت (یونٹ 8): AI نئے وسائل کے ضیاع پر نظر رکھتا ہے۔ آپ صحیح سائز کے فیصلے کرتے ہیں۔

ہر قدم پر، عام اصول مستقل رہتا ہے: AI پیدا کرتا ہے اور تیز کرتا ہے، انسان تصدیق کرتا ہے اور تصدیق کرتا ہے۔ یہ ماڈیول کا جوہر ہے۔

تین چھوٹے مقدمات

کیس 1 - کینری نے تباہی کو 5% تک محدود رکھا۔ ایک ٹیم نے کینری والے 5% صارفین کو نیا ورژن دیا۔ AI کے تیار کردہ ڈیش بورڈ نے فوری طور پر ظاہر کیا کہ اس سلائس میں غلطی کی شرح 8 فیصد تک پہنچ گئی۔ ٹیم نے اسے 100% تک بڑھائے بغیر واپس لے لیا۔ اس مسئلے نے صرف 5% صارفین کو متاثر کیا، اور یہ چند منٹوں کے لیے تھا۔ اگر بگ بینگ تعیناتی ہوتی تو تمام صارفین متاثر ہوتے۔

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

کیس 3 — تیار رول بیک 90 سیکنڈ میں محفوظ ہو گیا۔ ایک ٹیم جس نے بلیو گرین انسٹال کیا اس نے نئے ورژن کو سبز رنگ میں لے لیا۔ 2 منٹ کے بعد تاخیر دوگنی ہو گئی۔ انہوں نے پہلے سے تیار کردہ رول بیک کے ساتھ 90 سیکنڈ میں ٹریفک کو نیلے رنگ میں تبدیل کر دیا۔ انہوں نے بنیادی وجہ (نئے ورژن میں ایک سست سوال) کو دباؤ میں نہیں پایا، پھر سکون سے۔ تیار رول بیک راستے نے رکاوٹ کو تقریباً پوشیدہ بنا دیا۔

چار کاپی کرنے کے قابل ٹیمپلیٹس

1) حکمت عملی کا انتخاب جاری کریں:

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

2) دھواں ٹیسٹ / تصدیقی فہرست:

[SERVICE] کے لیے ایک ڈرافٹ اسموک ٹیسٹ اور تصدیقی فہرست تیار کریں جسے میں تعیناتی کے بعد چلاؤں گا: صحت کی جانچ، صارف کے سب سے اہم راستے، مجھے کتنے منٹ تک کن میٹرکس کی نگرانی کرنی چاہیے؟ فرض کریں کہ میں انتہائی اہم کاروباری راستوں کو نشان زد کروں گا اور اس فیلڈ کو خالی چھوڑ دوں گا۔

3) رول بیک پلان:

میں [تعیناتی طریقہ] استعمال کرتا ہوں۔ مجھے ایک واضح رول بیک پلان لکھیں: میں کس کمانڈ/اسٹیپ کے ساتھ پرانے ورژن پر واپس جاؤں، اس میں کتنا وقت لگتا ہے، خود رول بیک کے کیا خطرات ہیں (مثال کے طور پر ڈیٹا بیس کی منتقلی کو رول بیک نہیں کیا جا سکتا)، مجھے رول بیک کرنے سے پہلے کیا چیک کرنا چاہیے؟

4) اینڈ ٹو اینڈ ریلیز چیک لسٹ:

ایک نئے [SERVICE] پروجیکٹ کو جاری کرنے کے لیے آخری سے آخر تک تیاری کی چیک لسٹ تیار کریں: کوڈ/امیج سیکیورٹی، پائپ لائن، انفراسٹرکچر پلان، مانیٹرنگ اور الارمنگ، سیکیورٹی اسکیننگ، ریلیز کی حکمت عملی، رول بیک اور تصدیق۔ ہر آئٹم کو اس سوال کے ساتھ چیک کریں "کیا میں تیار ہوں؟" اسے سوال میں بدل دیں۔

کمزور فوری / مضبوط اشارہ

کمزور: "میں اسے پروڈکٹ میں کیسے حاصل کروں؟"

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

Güçlü: "میں 10 ملین صارفین کے ساتھ ادائیگی کی خدمت پیش کروں گا، ڈاؤن ٹائم کے لیے میری برداشت بہت کم ہے۔ کیا آپ Canary یا Blue-Green تجویز کرتے ہیں، کیوں؟ تعیناتی کے بعد مجھے کن اہم راستوں کی جانچ کرنی چاہیے، مجھے کتنے منٹ تک کن میٹرکس کی نگرانی کرنی چاہیے، اور 60 سیکنڈ کا رول بیک پلان کیسا ہونا چاہیے؟ میں حتمی فیصلہ کروں گا۔"

فرق: دوسرا پرامپٹ پیمانہ، رواداری اور رول بیک کی توقع دیتا ہے۔ اس کے لیے حکمت عملی + تصدیق + کالعدم کرنے کی ضرورت ہوتی ہے اور فیصلہ انسان پر چھوڑتا ہے۔

عام غلطیاں

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

خلاصہ میں

پروڈ پر جانا سلسلہ کی سب سے اہم کڑی ہے اور یہ "امید" سے نہیں بلکہ کنٹرول شدہ حکمت عملی کے ساتھ کیا جاتا ہے: نیلا سبز فوری رول بیک فراہم کرتا ہے، کینری اثر کو ایک چھوٹے سے ٹکڑے تک محدود کرتا ہے، خصوصیت کے پرچم کی تعیناتی کو ریلیز سے الگ کرتا ہے۔ تعیناتی ختم ہونے پر کام ختم نہیں ہوتا۔ صحت کی جانچ، دھوئیں کے ٹیسٹ اور گولڈن سگنل کی نگرانی کے ذریعے منظم تصدیق ضروری ہے۔ AI پورے ماڈیول میں ہر قدم پر ڈرافٹ تیار اور تیز کرتا ہے — ڈاکر فائل سے پائپ لائن تک، ٹیرافارم سے الارم رول تک، پوسٹ مارٹم سے لاگت کے تجزیہ تک۔ لیکن قابل شخص باقی رہتا ہے جو ہر قدم کی تصدیق کرتا ہے، گو لائیو بٹن کو دباتا ہے اور نتائج کی تصدیق کرتا ہے۔ یہ اینڈ ٹو اینڈ AI سے چلنے والے DevOps کا سنہری اصول ہے۔

درخواست کا کام

شائع کرنے کے لیے ایک سروس (حقیقی یا خیالی) کا انتخاب کریں۔ (1) ایک حکمت عملی کا انتخاب کریں جو آپ کے سیاق و سباق کے ساتھ "ریلیز حکمت عملی کے انتخاب" کے سانچے کے مطابق ہو اور اس کی وجہ لکھیں۔ (2) "سموک ٹیسٹ / تصدیقی فہرست" ٹیمپلیٹ کے ساتھ تیار کردہ ایک تصدیقی فہرست رکھیں اور انتہائی اہم کاروباری راستے خود شامل کریں۔ (3) "رول بیک پلان" ٹیمپلیٹ کے ساتھ 60 سیکنڈ کا رول بیک پلان تیار کریں اور چیک کریں کہ آیا اس میں کوئی ناقابل واپسی اقدامات ہیں۔

چیک لسٹ

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

ماڈیول امتحان

1. کلاؤڈ میں DevOps اور AI کے لیے درج ذیل میں سے کون سی بہترین پوزیشننگ ہے؟

• الف) مصنوعی ذہانت ایک معاون اور فیصلہ سازی کا آلہ ہے۔ مصنوعات کو متاثر کرنے والے اہم فیصلوں کے لیے لوگ ذمہ دار ہیں ✔
• ب) مصنوعی ذہانت انسانی منظوری کے بغیر مصنوعات کی تعیناتی اور خفیہ گردش کو حتمی شکل دے سکتی ہے۔
• C) مصنوعی ذہانت صرف دستاویزات لکھنے کے لیے مفید ہے، اس کا بنیادی ڈھانچے سے کوئی تعلق نہیں ہے۔
• D) آڈٹ غیر ضروری ہے کیونکہ مصنوعی ذہانت ہمیشہ انجینئر سے زیادہ قابل اعتماد کمانڈز تیار کرتی ہے۔

تفصیل: یہ ایک معاون اور فیصلہ سازی کا آلہ ہے جو ٹیکسٹ انٹینسی کام جیسے مصنوعی ذہانت پائپ لائن، کنفیگریشن، اسکرپٹ اور لاگ کو تیز کرتا ہے۔ ڈاؤن ٹائم، رقم اور سیکورٹی کو متاثر کرنے والے فیصلوں کی ذمہ داری، جیسے پروڈکشن ریلیز، خفیہ انتظام اور حتمی درخواست، اہل انجینئر کے پاس رہتی ہے۔

2. مصنوعی ذہانت کے ذریعے تیار کردہ DevOps کمانڈ یا کنفیگریشن کو نافذ کرنے سے پہلے تصدیقی نظم و ضبط کے لیے سب سے درست اظہار کون سا ہے؟

• A) اگر آؤٹ پٹ ہموار اور پر اعتماد نظر آتا ہے تو اسے براہ راست پروڈ میں چلایا جا سکتا ہے۔
• ب) آؤٹ پٹ صرف اس صورت میں محفوظ ہے جب کوئی نحوی غلطیاں نہ ہوں، مزید جانچ کی ضرورت نہیں ہے۔
• C) آؤٹ پٹ کو سورس سے جوڑیں، پلان/ڈرائی رن کریں، اور اسے اپنے سسٹم کے سیاق و سباق کے ساتھ فلٹر کریں۔ پھر اپلائی کریں ✔
• D) پہلی کوشش براہ راست پروڈ میں کرنا اور نتیجہ دیکھنا تیز ترین تصدیق ہے۔

وضاحت: تین قدمی توثیق ضروری ہے: آؤٹ پٹ کو ماخذ سے جوڑنا (اصل میں آفیشل دستاویزات میں کمانڈ/پرچم ہے)، اسے خشک چلانا (دیکھنا کہ پلان/--dry-run کے ساتھ کیا ہوتا ہے)، اور اسے سسٹم فلٹر سے گزرنا (کیا یہ اس کے آرکیٹیکچرل اور سیکیورٹی سیاق و سباق میں فٹ بیٹھتا ہے)۔ روانی کا مطلب درستگی نہیں ہے۔

3. ایک حقیقی ڈیٹا بیس پاس ورڈ پر مشتمل .env فائل کے ساتھ کسی غلطی یا تعیناتی کے مسئلے کے بارے میں مصنوعی ذہانت سے پوچھتے وقت صحیح طریقہ کیا ہے؟

• A) اصلی رازوں کو <PLACEHOLDER> کے ساتھ چھپائیں؛ صرف نقاب پوش غلطی اور سیاق و سباق کا اشتراک کریں ✔
• ب) پوری .env فائل کو پیسٹ کرنے سے مسئلہ تیزی سے حل ہوجاتا ہے۔
• C) چونکہ راز پہلے سے ہی بیس 64 ہیں، اس لیے سادہ پیسٹ کرنا محفوظ ہے۔
• D) پاس ورڈ چسپاں کرنا محفوظ ہے کیونکہ مصنوعی ذہانت اسے کبھی محفوظ نہیں کرتی ہے۔

تفصیل: AI پرامپٹ میں کوئی حقیقی راز چسپاں نہیں کیا جاتا ہے۔ پاس ورڈز اور ٹوکنز جیسی قدروں کو <PLACEHOLDER> کے ساتھ چھپایا جاتا ہے؛ صرف غلطی کا پیغام اور ضروری سیاق و سباق کا اشتراک کیا جاتا ہے۔ اگر راز پہلے ہی افشاء ہو چکا ہے تو اسے فوری طور پر منسوخ کر کے گھمایا جائے۔

4. درج ذیل میں سے کون سی سی آئی/سی ڈی پائپ لائن میں رازوں (پاس ورڈ، ٹوکن) کا صحیح انتظام ہے؟

• A) اسے پلیٹ فارم کے خفیہ ذخیرے میں رکھا جاتا ہے اور اسے حوالہ کے ذریعہ بلایا جاتا ہے (جیسے ${{ secrets.X }})، سادہ متن میں نہیں لکھا جاتا ✔
• ب) سہولت کے لیے پائپ لائن YAML پر سادہ متن میں لکھا گیا۔
• ج) ہر کام کے شروع میں ایکو اور لاگ دبانے سے اس کی تصدیق کی جاتی ہے۔
• D) اگر وسیع ترین اجازت کے ساتھ تعریف کی جائے (سب لکھیں)، تو سیکورٹی بڑھ جاتی ہے۔

وضاحت: YAML کو سادہ متن میں راز نہیں لکھا جاتا۔ اسے پلیٹ فارم کے خفیہ ذخیرہ میں رکھا جاتا ہے اور حوالہ جات کے ساتھ بلایا جاتا ہے جیسے ${{ secrets.X }}۔ مزید برآں، کم از کم اختیار کے اصول کے ساتھ، ٹوکن اجازتوں کو محدود کر دیا جاتا ہے اور خفیہ لاگ کو ریکارڈ نہیں کیا جاتا ہے۔

5. Terraform کے ساتھ انفراسٹرکچر مینجمنٹ میں، لائیو تبدیلی کو لاگو کرنے سے پہلے کونسا سب سے اہم قدم اٹھانا ہے؟

• A) براہ راست 'terraform apply' چلانا؛ منصوبہ وقت کا ضیاع ہے۔
• ب) ریاستی فائل کا عوامی ذخیرہ میں بیک اپ لینا
• C) 'ٹیرافارم پلان' چلائیں اور آؤٹ پٹ میں تباہ/تبدیل لائنوں کو چیک کریں، پھر لاگو کریں ✔
• D) فراہم کنندہ ورژن کو اَن انسٹال کریں اور یقینی بنائیں کہ تازہ ترین ورژن خود بخود آجائے

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

6. اس کا کیا مطلب ہے اور اگر ٹیرافارم پلان آؤٹ پٹ میں پروڈکشن ڈیٹا بیس کے لیے '-/+' کی جگہ ظاہر ہوتی ہے تو کیا کرنا چاہیے؟

• A) ماخذ کو صرف سائٹ پر اپ ڈیٹ کیا جائے گا، کوئی خطرہ نہیں ہے۔
• ب) وسائل کو حذف کر کے دوبارہ بنایا جائے گا۔ ڈیٹا کے ضائع ہونے کا خطرہ ہے، اگر توقع نہ ہو تو درخواست کو روک دیا جائے ✔
• C) ایک نیا وسیلہ شامل کرنے سے موجودہ ڈیٹا بیس متاثر نہیں ہوتا ہے۔
• D) یہ صرف ایک انتباہ ہے، محفوظ طریقے سے نظر انداز کیا جا سکتا ہے

وضاحت: '-/+ تبدیل کریں' کا مطلب ہے کہ وسائل کو حذف کر کے دوبارہ بنایا جائے گا۔ ڈیٹا بیس کے لیے، اس کا مطلب ہے ڈیٹا کا نقصان۔ اگر توقع نہیں کی جاتی ہے تو، درخواست کو روک دیا جانا چاہئے، تبدیلی کو ایک محفوظ طریقہ میں تبدیل کیا جانا چاہئے، یا غیر تبدیل شدہ فیلڈ کو اچھوتا چھوڑ دیا جانا چاہئے.

7. مندرجہ ذیل میں سے کون سا ڈاکر فائل کی حفاظت اور سائز کے لحاظ سے تیار ہونے کے لیے درست ہے؟

• A) سہولت کے لیے، تصویر میں راز کو ENV کے ساتھ سرایت کرنا اور اسے جڑ کے طور پر چلانا
• ب) ہمیشہ ':latest' ٹیگ کا استعمال کریں اور بنیادی تصویر کو ہر ممکن حد تک بڑا رکھیں
• سی) سنگل اسٹیج کی تعمیر اور حتمی تصویر میں تمام تعمیراتی ٹولز کو چھوڑنا
• D) راز کو سرایت نہ کرنا، غیر مجاز صارف کے ساتھ کام کرنا، چھوٹی اور مستحکم بیس امیج اور ملٹی اسٹیج بلڈ کا استعمال کرنا ✔

تفصیل: ایک پروڈکشن کے لیے تیار امیج: راز کو سرایت نہیں کرتا (رن ٹائم کے وقت اسے انجیکشن لگاتا ہے)، روٹ کے بجائے غیر مجاز USER کے ساتھ چلتا ہے، ایک چھوٹی اور ورژن والی بیس امیج (سلم/الپائن، نہیں :latest) استعمال کرتا ہے، اور ملٹی اسٹیج بلڈ کے ساتھ چھوٹا کیا جاتا ہے۔ اشاعت سے پہلے اسے کمزوریوں کے لیے بھی اسکین کیا جاتا ہے۔

8. Kubernetes میں تعیناتی کے لیے وسائل کی حدود کی وضاحت نہ کرنے کا سب سے اہم خطرہ کیا ہے؟

• A) Pod کبھی شروع نہیں ہوتا کیونکہ حد ایک مطلوبہ فیلڈ ہے۔
• ب) مانیٹرنگ بورڈ پر صرف ایک انتباہ ظاہر ہوتا ہے، آپریشن متاثر نہیں ہوتا ہے۔
• C) Kubernetes خود بخود محفوظ طے شدہ حدود کو نافذ کرتا ہے، کوئی خطرہ نہیں۔
• D) پوڈ لامحدود طور پر بڑھ سکتا ہے اور نوڈ کے وسائل کو استعمال کر سکتا ہے، اس طرح ہمسایہ کی خدمات کو تباہ کر سکتا ہے ✔

وضاحت: ایک پوڈ جس میں وسائل کی کوئی حد نہیں ہے وہ لامحدود طور پر بڑھ سکتا ہے، اس نوڈ کے تمام وسائل استعمال کر سکتا ہے جس پر یہ چل رہا ہے، اور پڑوسی خدمات کو کریش کر سکتا ہے، مثال کے طور پر، میموری لیک ہونے کے ساتھ۔ اسی لیے درخواستوں/حدود کا تعین مضبوطی کی بنیاد ہے۔

9. نگرانی اور الارم سیٹ اپ میں 'الرٹ تھکاوٹ' سے کیسے بچا جائے؟

• A) زیادہ سے زیادہ میٹرکس پر الارم سیٹ کریں اور ہر اتار چڑھاؤ کے ساتھ الرٹس تیار کریں۔
• ب) تمام الارم کو سب سے زیادہ شدت کی سطح پر سیٹ کریں۔
• C) وقت مقرر کیے بغیر فوری اقدار کے ساتھ الارم کو متحرک کرنا (کے لیے)
• D) الارم کو ایکشن پر مبنی اور صحیح عجلت پر رکھنا، تاریخی ڈیٹا کے ساتھ دہلیز کی جانچ کرنا، غیر ضروری کو ضم کرنا ✔

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

10. پیداوار کے واقعے کے دوران ترجیحی آرڈر کیا ہے؟

• ا) سب سے پہلے اصل وجہ تلاش کریں اور صرف اس صورت میں کم کریں جب وجہ واضح ہو۔
• ب) پہلے پوسٹ مارٹم رپورٹ لکھیں، پھر سروس کو ٹچ کریں۔
• C) پہلے کم کریں (سروس بحال/بحال کریں)، بعد میں بنیادی وجہ کا تجزیہ چھوڑ کر ✔
• D) پہلے واقعے کے ذمہ دار شخص کو تلاش کریں اور اس کی اطلاع دیں۔

تشریح: سنہری اصول ہے 'پہلے کم کرو، بعد میں تحقیق کرو'۔ مقصد یہ ہے کہ سب سے پہلے سروس کو بحال کیا جائے یا اسے ایک معروف-اچھے ورژن پر واپس لایا جائے (کمی کرنا)؛ دباؤ کم ہونے کے بعد بنیادی وجہ کا تجزیہ سکون سے کیا جاتا ہے۔ اصل وجہ تلاش کرنے کا انتظار کرنے سے ریکوری ٹائم (MTTR) بڑھ جاتا ہے۔

11. بے قصور پوسٹ مارٹم کلچر کا بنیادی مقصد کیا ہے؟

• ا) غلطی کرنے والے شخص کی نشاندہی کرنا اور اس کی ذمہ داری اس پر ڈالنا
• ب) نظام اور عمل پر توجہ مرکوز کرنا اور سیکھنے کی حوصلہ افزائی کرنا؛ ✔ اسباق سیکھنا جو الزام لگانے کی بجائے تکرار کو روکتا ہے۔
• ج) کبھی بھی واقعے کی اطلاع نہ دیں اور اس بات کو یقینی بنائیں کہ اسے بھول گیا ہے۔
• D) صرف تکنیکی تفصیلات لکھنا اور قابل عمل اشیاء شامل نہیں کرنا

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

12. کلاؤڈ لاگت کی اصلاح (FinOps) میں، کمٹڈ ڈسکاؤنٹس (محفوظ/بچت کے منصوبے) پر جانے سے پہلے کونسا منطقی قدم اٹھانا ہے؟

• A) سب سے طویل ممکنہ عزم پہلے لیں، ضائع ہونے کے بارے میں بعد میں سوچیں۔
• ب) سب سے پہلے، فضلہ کو صاف کریں (بیکار بندش، صحیح سائز)، پھر پرعزم استعمال کا عہد کریں ✔
• ج) تمام وسائل کو فوری طور پر اسپاٹ صلاحیت پر منتقل کریں۔
• D) انوائس ڈیٹا کا جائزہ لیے بغیر مہنگی ترین چیز کو حذف کرنا

وضاحت: فضلہ کو پہلے صاف کرنا ضروری ہے (بے کار وسائل کو بند کرنا، بڑے وسائل کو کم کرنا)۔ بصورت دیگر، آپ ضائع شدہ استعمال کو رعایتی قیمت پر 1-3 سال کے لیے مقفل کر دیں گے۔ صحیح سائز اور بیکار صفائی کے لیے کسی عزم کی ضرورت نہیں ہے اور یہ خطرے سے پاک ہونے کے قریب ہیں۔

13. اگر AI کی تجویز کردہ اسکرپٹ میں 'rm -rf "$DIR"/' لائن ہو تو سب سے اہم حفاظتی اقدام کیا ہے؟

• A) اسکرپٹ کو بغیر پڑھے براہ راست پروڈ میں چلانے سے رفتار بڑھ جائے گی۔
• ب) سیٹ -euo پائپ فیل اور خالی متغیر کنٹرول شامل کریں اور پہلے ڈرائی رن کے ساتھ کوشش کریں ✔
• ج) متغیر نام کو مختصر کرنا کافی ہے۔
• D) rm کی بجائے rm -rf --force استعمال کرنے سے مسئلہ حل ہوجاتا ہے۔

وضاحت: اگر $DIR خالی ہے، تو یہ بیان روٹ ڈائریکٹری کو حذف کرنے کی کوشش کر سکتا ہے۔ غیر متعینہ متغیر پر 'set -u' کے ساتھ رکنا اور یہ چیک کرنا کہ متغیر کو حذف کرنے سے پہلے خالی نہیں ہے (جیسے [ -n "$DIR" ] || exit 1) تباہی سے بچاتا ہے۔ مزید برآں، تباہ کن کارروائیوں کو پہلے ڈرائی رن کے ساتھ آزمایا جانا چاہیے۔

14. اگر کلاؤڈ ایکسیس کلید غلطی سے کسی عوامی ذخیرے میں لیک ہو جائے تو سب سے پہلے کیا کرنا ہے؟

• A) کلید کو فوری طور پر منسوخ کریں اور تجدید کریں (گھمائیں)؛ صرف حذف کرنا کافی نہیں ہے ✔
• ب) بس فائل کو سٹوریج سے ڈیلیٹ کر دیں اور کلید محفوظ ہے۔
• ج) کچھ نہیں کرنا کیونکہ کسی نے اسے نہیں دیکھا
• D) سٹوریج کو نجی بنانے سے کلید کو گھمانے کی ضرورت ختم ہو جاتی ہے۔

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

15. مندرجہ ذیل میں سے کون سا طریقہ پروڈ کا نیا ورژن جاری کرتے وقت خطرے کو کم کرتا ہے؟

• A) تمام صارفین کو ایک ہی وقت میں نیا ورژن دینا (بگ بینگ) اور رول بیک پلان تیار نہ کرنا
• ب) 'سبز' ظاہر ہوتے ہی تعیناتی کو ختم کرنے پر غور کرتے ہوئے، اضافی تصدیق نہ کرتے ہوئے
• C) ایک کنٹرول شدہ حکمت عملی کا استعمال جیسے کینری/بلیو گرین/فیچر فلیگ، ریڈی میڈ رول بیک پلان اور اسموک ٹیسٹ + تعیناتی کے بعد میٹرک مانیٹرنگ ✔
• D) اہم کاروباری راستوں کی جانچ کو مکمل طور پر مصنوعی ذہانت پر چھوڑنا اور ان کا بالکل تعین نہ کرنا۔

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