12.2 چیک لسٹیں

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

انہیں اچھی طرح استعمال کرنے کی رہنمائی:

• چیک لسٹیں اتنی مختصر رکھیں کہ لوگ واقعی انہیں مکمل کریں۔ اگر چیک لسٹ معمول سے چھوڑی جاتی ہے تو وہ بہت لمبی یا بہت عمومی ہے۔
• جس شے کی مشین توثیق کر سکے (formatting، ٹیسٹ، اسکین) اسے خودکار کریں تاکہ انسان توجہ فیصلے کی اشیا پر خرچ کریں۔
• اپنی چیک لسٹوں کو version کریں اور وقتاً فوقتاً ان کا ریویو کریں۔ جو چیک لسٹ کبھی نہیں بدلتی غالباً استعمال نہیں ہو رہی۔
• جب فرق آپ کے عمل کے لیے اہم ہو تو روکنے والی اشیا کو مشورے والی اشیا سے ممتاز کریں۔

کوڈ ریویو کی چیک لسٹ

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

• تبدیلی وہ کرتی ہے جو اس کی تفصیل اور جڑا ٹکٹ کہتے ہیں۔
• دائرہ ایک منطقی مسئلے پر مرکوز ہے؛ غیر متعلقہ تبدیلیاں الگ کی گئی ہیں۔
• ڈیزائن موجودہ فن تعمیر کے مطابق ہے اور ایسی coupling نہیں لاتا جس سے بچنا آسان تھا۔
• کناروں کے معاملات، غلطی کے راستے، اور ناکامی کے طریقے سنبھالے گئے ہیں، صرف خوش گوار راستہ نہیں۔
• ٹیسٹ موجود ہیں، بامعنی ہیں، اور رویہ پسپا ہونے پر ناکام ہوں گے۔
• نام رکھنا، ساخت، اور تبصرے کوڈ کو مستقبل کے پڑھنے والے کے لیے قابل فہم بناتے ہیں۔
• کوئی secrets، credentials، tokens، یا ذاتی ڈیٹا commit نہیں ہوا۔
• سیکیورٹی کے لحاظ سے حساس ان پٹ کی مناسب توثیق، encoding، یا parameterisation ہے۔
• عوامی انٹرفیس، معاہدے، اور پسماندہ مطابقت محفوظ ہیں یا دانستہ version کیے گئے ہیں۔
• Logging، میٹرکس، اور غلطی کی رپورٹنگ production میں تبدیلی چلانے کے لیے کافی ہیں۔
• دستاویزات، runbooks، اور کنفیگریشن تبدیلی کے مطابق اپ ڈیٹ ہیں۔
• رائے روکنے والے مسائل بمقابلہ تجاویز میں الگ ہے، اور کوڈ کے بارے میں الفاظ میں۔

Pull request مصنف کی چیک لسٹ

مصنف کے لیے ریویو مانگنے سے پہلے۔

• PR اتنا چھوٹا اور مرکوز ہے کہ ایک نشست میں احتیاط سے ریویو ہو سکے۔
• تفصیل بتاتی ہے کہ کیا بدلا، کیوں، اور اس کی توثیق کیسے ہوئی۔
• جڑا ٹکٹ، issue، یا ڈیزائن دستاویز ریویو کرنے والوں کو ضروری سیاق دیتا ہے۔
• تمام خودکار جانچیں مقامی طور پر یا CI میں پاس ہیں (build، lint، format، ٹیسٹ، اسکین)۔
• نیا اور بدلا رویہ ٹیسٹوں سے ڈھکا ہے۔
• میکانکی refactors رویے کی تبدیلیوں سے الگ ہیں۔
• خود ریویو مکمل ہے: آپ نے اپنا diff لائن بہ لائن پڑھ لیا ہے۔
• کوئی debug کوڈ، commented-out بلاکس، secrets، یا آوارہ فائلیں باقی نہیں۔
• ڈیٹا بیس migrations، feature flags، اور کنفیگریشن کی تبدیلیاں دستاویزی اور الٹنے کے قابل ہیں۔
• توڑنے والی تبدیلیاں واضح طور پر migration کے راستے کے ساتھ بتائی گئی ہیں۔
• جہاں ریویو میں مدد ملے وہاں screenshots، recordings، یا نمونہ آؤٹ پٹ شامل ہیں۔
• درست ریویو کرنے والوں اور کسی بھی لازمی کردار پر مبنی منظوری دینے والوں سے درخواست کی گئی ہے۔

Definition of Done

مشترک معیار جس پر کام کی شے کو مکمل سمجھے جانے سے پہلے پورا اترنا ہوگا۔

• ٹکٹ میں قبولیت کے معیار سب پورے اور قابل مظاہرہ ہیں۔
• کوڈ کا peer ریویو ہوا اور لازمی ریویو کرنے والوں نے منظور کیا۔
• خودکار ٹیسٹ لکھے گئے، پاس ہو رہے ہیں، اور تبدیلی کے ساتھ merge ہوئے۔
• کوڈ mainline میں merge ہوا اور پائپ لائن سے صاف ڈیپلائے ہوتا ہے۔
• متفقہ شدت کی حد کا کوئی معلوم نقص کھلا نہیں۔
• دستاویزات، مدد کا متن، اور runbooks اپ ڈیٹ ہیں۔
• مشاہدہ پذیری موجود ہے: متعلقہ logs، میٹرکس، اور alerts ہیں۔
• سیکیورٹی اور رازداری کے مضمرات پر غور اور ان کا حل کیا گیا۔
• جہاں صارف کے سامنے ہو وہاں تبدیلی کے رسائی کے تقاضے پورے ہیں۔
• Feature flags ترتیب دیے گئے اور rollout کے منصوبے پر اتفاق ہے۔
• پروڈکٹ مالک یا حصہ دار نے نتیجہ قبول کیا۔
• کوئی بھی فالو اپ کام مضمر چھوڑنے کی بجائے ٹریک شدہ ٹکٹوں کے طور پر درج ہے۔

Production launch / go-live کی تیاری

اہم تبدیلی یا نئی سروس production میں ship کرنے سے پہلے۔

• Rollout کا منصوبہ دستاویزی ہے، مرحلہ وار یا canary قدم اور کامیابی کے معیار سمیت۔
• Rollback کا منصوبہ دستاویزی، آزمایا ہوا، اور جلد انجام دینے کے قابل ہے۔
• صلاحیت اور لوڈ ٹیسٹنگ دکھاتی ہے کہ نظام متوقع اور چوٹی کی طلب پوری کرتا ہے۔
• مانیٹرنگ، ڈیش بورڈز، اور alerts launch سے پہلے لائیو اور توثیق شدہ ہیں۔
• On-call کی کوریج شیڈول ہے اور جواب دینے والے نظام کو جانتے ہیں۔
• سب سے امکانی ناکامی اور آپریشنل صورتوں کے runbooks موجود ہیں۔
• انحصار، انضمام، اور تیسری پارٹیاں تیار تصدیق شدہ ہیں اور rate limits سمجھی گئی ہیں۔
• سیکیورٹی ریویو اور لازمی دستخط مکمل ہیں۔
• ڈیٹا کی منتقلی، اگر کوئی ہو، شروع سے آخر تک آزمائی گئی اور تصدیق شدہ backout کے ساتھ ہے۔
• Feature flags تبدیلی کو دوبارہ ڈیپلائے کے بغیر بند کرنے دیتے ہیں۔
• جہاں ضروری ہو قانونی، رازداری، اور تعمیل کی منظوریاں حاصل ہیں۔
• ابلاغ کا منصوبہ حصہ داروں، سپورٹ، اور گاہکوں کو ڈھانپتا ہے۔
• Go/no-go کا فیصلہ نام زد مالکان واضح معیار کے مقابل کرتے ہیں۔

سیکیورٹی ریویو / threat-model کی چیک لسٹ

تبدیلی یا نظام کی سیکیورٹی کی کیفیت جانچنے کے لیے۔

• اعتماد کی حدیں اور ڈیٹا کے بہاؤ پہچانے اور دستاویزی ہیں۔
• تصدیق ہر اس داخلی نقطے پر نافذ ہے جہاں اس کی ضرورت ہے۔
• اجازت کی جانچیں ہر عمل اور وسیلے کے لیے least privilege نافذ کرتی ہیں۔
• تمام بیرونی ان پٹ کی توثیق ہوتی ہے، اور آؤٹ پٹ اس کی منزل کے مطابق encode ہوتا ہے۔
• Secrets منظم vault میں ذخیرہ ہیں، کوڈ یا config میں کبھی نہیں، اور گھمائے جا سکتے ہیں۔
• ڈیٹا ترسیل اور ذخیرے میں خفیہ ہے جیسا درجہ بندی تقاضا کرے۔
• انحصار کا معلوم کمزوریوں کے لیے اسکین ہوتا ہے اور وہ موجودہ رکھے جاتے ہیں۔
• غیر معتبر ان پٹ کے لیے injection، deserialisation، اور SSRF کے خطرے کم کیے گئے ہیں۔
• سیکیورٹی سے متعلق واقعات حساس ڈیٹا ریکارڈ کیے بغیر log ہوتے ہیں۔
• Rate limiting، quotas، اور غلط استعمال سے تحفظات ظاہر کردہ endpoints کی حفاظت کرتے ہیں۔
• غلطی کے پیغامات stack traces، اندرونی تفصیلات، یا حساس تفصیل افشا نہیں کرتے۔
• STRIDE یا اس جیسے طریقے سے پہچانے گئے خطرات تخفیف یا قبول شدہ خطرے کے ساتھ ریکارڈ ہیں۔
• سیکیورٹی ٹیسٹنگ (SAST، DAST، یا penetration testing) منصوبہ بند یا مکمل ہے۔

رازداری اور ڈیٹا کے تحفظ (DPIA طرز) کی چیک لسٹ

اس پروسیسنگ کے لیے جس میں ذاتی یا حساس ڈیٹا شامل ہو۔

• جمع کیا گیا ذاتی ڈیٹا فہرست بند، درجہ بند، اور ضرورت کی حد تک کم سے کم کیا گیا ہے۔
• ہر پروسیسنگ کے مقصد کی قانونی بنیاد یا اختیار دستاویزی ہے۔
• مقصد کی حد نافذ ہے: ڈیٹا صرف بیان کردہ مقاصد کے لیے استعمال ہوتا ہے۔
• برقراری کی مدتیں متعین ہیں اور حذف یا anonymisation خودکار ہے۔
• ڈیٹا کے مالک کے حقوق (رسائی، اصلاح، حذف، پورٹیبلٹی) پورے کیے جا سکتے ہیں۔
• رضامندی، جہاں اس پر انحصار ہو، آزادانہ دی گئی، مخصوص، اور قابل منسوخی ہے۔
• تیسری پارٹیاں اور processors مناسب ڈیٹا کے تحفظ کی شرائط کے پابند ہیں۔
• سرحد پار منتقلیوں کے لیے مناسب قانونی منتقلی کا میکانزم ہے۔
• ذاتی ڈیٹا تک رسائی محدود، log شدہ، اور ریویو ہوتی ہے۔
• افراد کو رازداری کے خطرات کا اندازہ لگا کر کم یا escalate کیا گیا ہے۔
• ڈیٹا کی خلاف ورزی کی شناخت اور اطلاع کے عمل متعین ہیں۔
• فیچر کے لیے privacy by design اور default کے انتخاب دستاویزی ہیں۔
• جہاں ضروری ہو ڈیٹا کے تحفظ کے افسر یا رازداری کے ریویو کرنے والے نے دستخط کیے ہیں۔

رسائی (WCAG) کی چیک لسٹ

صارف کے سامنے انٹرفیسز کے لیے، WCAG کے اصولوں سے ہم آہنگ۔

• تمام مواد صرف کی بورڈ سے قابل رسائی اور قابل عمل ہے۔
• Focus کی ترتیب منطقی ہے اور نظر آنے والا focus اشارہ موجود ہے۔
• متن کے رنگ کا تضاد ہدف کا تناسب پورا کرتا ہے (عموماً مرکزی متن کے لیے 4.5:1)۔
• تصاویر اور غیر متنی مواد کا بامعنی متبادل متن ہے۔
• فارم کے فیلڈز کے ساتھ منسلک لیبل اور واضح غلطی کے پیغامات ہیں۔
• Headings، landmarks، اور ساخت semantic طور پر markup ہیں۔
• تعاملی اجزا معاون ٹیکنالوجی کو درست نام، کردار، اور حالت ظاہر کرتے ہیں۔
• مواد reflow ہوتا اور 200% zoom پر اور چھوٹی اسکرینوں پر قابل استعمال رہتا ہے۔
• وقت کی حدیں ایڈجسٹ ہو سکتی ہیں، اور حرکت یا خودکار چلتا مواد روکا جا سکتا ہے۔
• رنگ معلومات پہنچانے کا واحد ذریعہ نہیں۔
• میڈیا کے captions ہیں اور، جہاں ضرورت ہو، transcripts یا آڈیو بیان۔
• انٹرفیس screen reader اور خودکار رسائی کی ٹولنگ سے آزمایا گیا ہے۔

API ڈیزائن ریویو کی چیک لسٹ

API شائع یا تبدیل کرنے سے پہلے۔

• وسیلے اور عمل کے نام مستقل اور قابل پیش گوئی ہیں۔
• معاہدہ مشین کے پڑھنے کے قابل schema (مثلاً OpenAPI) میں متعین ہے۔
• Versioning کی حکمت عملی متعین ہے اور پسماندہ مطابقت محفوظ یا منظم ہے۔
• Pagination، filtering، اور sorting مستقل روایات کی پیروی کرتے ہیں۔
• غلطی کے جوابات مستقل ساخت، کوڈ، اور قابل عمل پیغامات استعمال کرتے ہیں۔
• تصدیق اور اجازت ہر عمل کے لیے متعین ہے۔
• ان پٹ کی توثیق اور سائز کی حدیں متعین اور نافذ ہیں۔
• جن اعمال میں دوبارہ کوششوں کی توقع ہو ان کے لیے idempotency متعین ہے۔
• Rate limits، quotas، اور throttling کا رویہ دستاویزی ہے۔
• Timeouts، دوبارہ کوششیں، اور ناکامی کے معنی clients کے لیے واضح ہیں۔
• جوابات میں حساس ڈیٹا کی نمائش کم سے کم اور مدلل ہے۔
• دستاویزات میں ہر عمل اور غلطی کی صورت کے لیے مثالیں ہیں۔
• Deprecation کی پالیسی اور sunset کی ٹائم لائنز متعین ہیں۔

فن تعمیراتی فیصلے (ADR) کے ریویو کی چیک لسٹ

مجوزہ architecture decision record کا ریویو کرنے کے لیے۔

• سیاق اور حل ہونے والا مسئلہ واضح بیان ہیں۔
• فیصلہ غیر مبہم طور پر واحد انتخاب کے طور پر بیان ہے۔
• کم از کم دو حقیقت پسند متبادل زیر غور آئے اور ان کا موازنہ ہوا۔
• نتائج، مثبت اور منفی دونوں، دستاویزی ہیں۔
• غیر فعلی اثرات (کارکردگی، سیکیورٹی، لاگت، آپریشن پذیری) مخاطب ہیں۔
• فیصلہ موجودہ اصولوں اور پچھلے ADRs سے ہم آہنگ ہے، یا انہیں واضح طور پر بدلتا ہے۔
• متاثرہ ٹیموں اور حصہ داروں سے مشورہ کیا گیا۔
• الٹنے کی صلاحیت اور تبدیلی کی لاگت کا اندازہ لگایا گیا ہے۔
• مفروضے اور پابندیاں واضح کی گئی ہیں۔
• حالت (proposed، accepted، superseded) طے اور تاریخ شدہ ہے۔
• فیصلہ دریافت کے قابل ہے اور متعلقہ نظاموں سے جڑا ہے۔
• کوئی بھی فالو اپ اعمال یا migrations ٹریک شدہ کام کے طور پر درج ہیں۔

واقعے کے ردعمل کی چیک لسٹ

فعال production واقعے کے دوران۔

• واقعے کا اعلان کریں اور واحد incident commander مقرر کریں۔
• شدت، دائرہ، اور گاہک پر اثر کا اندازہ لگا کر بتائیں۔
• مخصوص ابلاغی چینل اور واقعے کا ریکارڈ کھولیں۔
• واضح کردار تفویض کریں: commander، ابلاغ کا لیڈ، اور آپریشنز کا لیڈ۔
• بنیادی وجہ کے تجزیے پر تخفیف اور سروس کی بحالی کو ترجیح دیں۔
• حصہ داروں کو مقررہ تال پر باقاعدہ status اپ ڈیٹس پوسٹ کریں۔
• واقعات، اعمال، اور فیصلوں کی ٹائم لائن جیسے وہ ہوتے ہیں ریکارڈ کریں۔
• ضرورت پر اضافی جواب دینے والوں یا فروخت کنندگان تک escalate کریں۔
• اگر ڈیٹا یا ضابطہ شامل ہو تو قانونی، سیکیورٹی، اور تعمیل کو مطلع کریں۔
• اصلاح کی توثیق کریں اور تصدیق کریں کہ نظام پوری طرح بحال ہو گیا۔
• واقعے کو رسمی طور پر بند کریں اور حل بتائیں۔
• لوگوں کے منتشر ہونے سے پہلے بلا الزام postmortem شیڈول کریں۔

Postmortem کی چیک لسٹ

واقعے کے بعد کے retrospective ریویو کے لیے۔

• ریویو بلا الزام ہے اور نظاموں اور معاون عوامل پر مرکوز ہے۔
• واقعے کی حقائق پر مبنی، timestamp شدہ ٹائم لائن دستاویزی ہے۔
• گاہک اور کاروباری اثر مقدار شدہ ہے (دورانیہ، دائرہ، لاگت)۔
• Detection کا تجزیہ ہوا: مسئلہ کیسے اور کب نوٹس ہوا۔
• ردعمل کا تجزیہ ہوا: کیا مددگار تھا اور کس نے بحالی سست کی۔
• معاون وجوہات پہچانی گئیں، صرف واحد بنیادی وجہ نہیں۔
• جو اچھا ہوا وہ بھی ریکارڈ ہے، اور جو غلط ہوا وہ بھی۔
• Action items مخصوص ہیں، مالکان کو تفویض ہیں، اور ان کی آخری تاریخیں ہیں۔
• Action items روک تھام، detection، اور تخفیف کو مخاطب کرتے ہیں۔
• فالو اپ اشیا معمول کے backlog میں تکمیل تک ٹریک ہوتی ہیں۔
• postmortem وسیع طور پر بانٹا گیا ہے تاکہ دوسرے اس سے سیکھ سکیں۔
• واقعات میں نظامی پیٹرن کا وقتاً فوقتاً ریویو ہوتا ہے۔

On-call کی تیاری کی چیک لسٹ

کسی کے on-call شفٹ لینے سے پہلے۔

• جواب دینے والے کو تمام نظاموں، ڈیش بورڈز، اور آلات تک رسائی ہے جو اسے چاہییں۔
• Alerting جواب دینے والے تک قابل بھروسگی سے پہنچتی ہے اور آزمائی گئی ہے۔
• Escalation کے راستے اور ثانوی on-call کے رابطے معلوم اور موجودہ ہیں۔
• سب سے عام اور سب سے شدید alerts کے runbooks موجود ہیں۔
• جواب دینے والے نے ان نظاموں کے لیے onboarding یا shadowing مکمل کی ہے۔
• حالیہ تبدیلیاں، جاری واقعات، اور معلوم مسائل handoff ہو چکے ہیں۔
• Alert کی حدیں شور اور جھوٹے pages کم کرنے کو ٹیون ہیں۔
• جواب دینے والا جانتا ہے کہ واقعے کا اعلان کیسے کریں اور commander تک کیسے پہنچیں۔
• جواب دینے والے کے کام کے ماحول سے production تک رسائی ممکن ہے۔
• ابلاغی چینل اور حصہ داروں کے رابطے دستاویزی ہیں۔
• On-call کا شیڈول شائع ہے اور کوریج میں کوئی خلا نہیں۔
• On-call کا معاوضہ، توقعات، اور کام کے بوجھ کی حدیں واضح ہیں۔

SLO کی تعریف کی چیک لسٹ

service level objective متعین کرتے ہوئے۔

• صارف کا سفر یا صلاحیت جس کی SLO حفاظت کرتی ہے واضح پہچانی گئی ہے۔
• Service level indicators (SLIs) واضح، قابل پیمائش مقداروں کے طور پر متعین ہیں۔
• جہاں ممکن ہو SLIs صارف کے نقطۂ نظر سے ناپے جاتے ہیں۔
• ہدف اس سطح پر ہے جو صارفین کو واقعی چاہیے، 100% نہیں۔
• پیمائش کی کھڑکی (مثلاً rolling 28 دن) متعین ہے۔
• ہدف سے اخذ شدہ error budget شمار اور سمجھا گیا ہے۔
• پالیسی طے کرتی ہے کہ error budget ختم ہونے پر کیا ہوتا ہے۔
• SLIs کے ڈیٹا کے ماخذ قابل اعتماد اور instrument شدہ ہیں۔
• Alerting صرف حد کی خلاف ورزیوں سے نہیں، burn rate سے جڑی ہے۔
• مالکان اور حصہ دار متفق ہیں کہ SLO حقیقت پسند اور بامعنی ہے۔
• SLO دستاویزی ہے اور ڈیش بورڈ پر نظر آتی ہے۔
• SLOs کا ریویو اور نظر ثانی کرنے کا شیڈول موجود ہے جیسے سروس ارتقا پائے۔

CI/CD پائپ لائن کی چیک لسٹ

continuous integration اور delivery کی پائپ لائن کے لیے۔

• ہر commit خودکار build اور ٹیسٹ چلاتا ہے۔
• پائپ لائن جلد ناکام ہوتی اور نتائج مصنفین کو واضح رپورٹ کرتی ہے۔
• Linting، formatting، اور static analysis خودکار چلتے ہیں۔
• Unit، integration، اور متعلقہ end-to-end ٹیسٹ پائپ لائن میں چلتے ہیں۔
• سیکیورٹی اور انحصار کی اسکیننگ ہر build پر چلتی ہے۔
• Build artefacts version شدہ، ناقابل تغیر، اور registry میں ذخیرہ ہیں۔
• Secrets محفوظ طریقے سے شامل کیے جاتے ہیں اور logs میں کبھی نہیں چھپتے۔
• ڈیپلائے خودکار اور ماحول میں قابل تکرار ہیں۔
• ڈیپلائے کی حکمت عملی (canary، blue-green، rolling) متعین اور استعمال ہوتی ہے۔
• Rollback خودکار یا واحد دستاویزی عمل ہے۔
• پائپ لائن کی اجازتیں least privilege کی پیروی کرتی ہیں اور قابل آڈٹ ہیں۔
• پائپ لائن کی کنفیگریشن version control میں کوڈ کے طور پر ذخیرہ ہے۔
• جہاں ضروری ہو build کا ماخذ اور software bill of materials تیار ہوتے ہیں۔

Infrastructure-as-code ریویو کی چیک لسٹ

کوڈ کے طور پر متعین انفراسٹرکچر کا ریویو کرنے کے لیے۔

• تبدیلیاں مکمل طور پر کوڈ میں ظاہر ہیں اور پائپ لائن سے لاگو ہوتی ہیں۔
• Apply سے پہلے plan یا dry-run آؤٹ پٹ کا ریویو ہوتا ہے۔
• State محفوظ طریقے سے locking کے ساتھ ذخیرہ ہے تاکہ ہم وقتی تبدیلیاں رکیں۔
• وسائل نام رکھنے، tagging، اور ملکیت کی روایات کی پیروی کرتے ہیں۔
• Least-privilege IAM کردار اور پالیسیاں استعمال ہوتی ہیں، جہاں بچ سکے wildcards کے بغیر۔
• نیٹ ورک کی نمائش کم سے کم ہے؛ کوئی غیر ارادی عوامی رسائی نہیں۔
• Secrets اور حساس قدریں ہارڈ کوڈ ہونے کی بجائے vault سے حوالہ دی جاتی ہیں۔
• Storage، ڈیٹا بیس، اور ترسیل کے لیے خفیہ کاری چالو ہے۔
• تبدیلیاں idempotent اور دوبارہ لاگو کرنے کے لیے محفوظ ہیں۔
• Blast radius سمجھا گیا ہے؛ تباہ کن تبدیلیاں واضح بتائی گئی ہیں۔
• تبدیلی کی لاگت کے اثر پر غور ہوا ہے۔
• ماڈیولز دوبارہ قابل استعمال، version شدہ، اور آزمودہ ہیں۔
• حد سے باہر کی تبدیلیاں پکڑنے کو drift کی شناخت موجود ہے۔

AI/ML ماڈل ریلیز کی چیک لسٹ

مشین لرننگ ماڈل production میں ریلیز کرنے سے پہلے۔

• ماڈل کا مطلوبہ استعمال، دائرہ، اور حدود دستاویزی ہیں۔
• Training اور evaluation کے ڈیٹا کا ماخذ، لائسنسنگ، اور رضامندی کی توثیق ہوئی ہے۔
• ڈیٹا اور ماڈل version شدہ اور قابل تکرار ہیں۔
• کارکردگی نمائندہ، روکے ہوئے ٹیسٹ ڈیٹا پر جانچی گئی ہے۔
• متعلقہ ذیلی گروہوں میں انصاف اور تعصب کا اندازہ لگایا گیا ہے۔
• ماڈل کا موجودہ یا بنیادی لکیر کے مقابل جائزہ لیا گیا ہے۔
• ناکامی کے طریقے، کناروں کے معاملات، اور تقسیم سے باہر کا رویہ سمجھا گیا ہے۔
• حفاظت، غلط استعمال، اور نقصان دہ آؤٹ پٹ کے خطرات کا اندازہ لگا کر کم کیے گئے ہیں۔
• Drift، ڈیٹا کے معیار، اور کارکردگی کے گرنے کی مانیٹرنگ موجود ہے۔
• پچھلے ماڈل یا قاعدے پر مبنی راستے پر rollback یا fallback موجود ہے۔
• نتیجہ خیز فیصلوں کے لیے انسانی نگرانی یا اپیل فراہم ہے۔
• رازداری کا ریویو training ڈیٹا اور inference کے ان پٹس اور آؤٹ پٹس کو ڈھانپتا ہے۔
• حصہ داروں کے لیے model card یا مساوی دستاویز شائع ہے۔

ڈیٹا پائپ لائن کے معیار کی چیک لسٹ

analytics یا پروڈکٹس کو کھلانے والی ڈیٹا پائپ لائن کے لیے۔

• ماخذ ڈیٹا کی schemas کی توثیق ہوتی ہے اور schema کی تبدیلیاں پکڑی جاتی ہیں۔
• Ingestion دیر سے، دہرائے، اور بے ترتیب ریکارڈ درست سنبھالتی ہے۔
• ڈیٹا کے معیار کی جانچیں (مکمل ہونا، انفرادیت، رینجز) خودکار چلتی ہیں۔
• ناکام ریکارڈ quarantine ہو کر ظاہر ہوتے ہیں، خاموشی سے نہیں گرائے جاتے۔
• تبدیلیاں نمائندہ اور کناروں کے ان پٹس سے آزمائی جاتی ہیں۔
• پائپ لائن idempotent ہے اور ناکامی کے بعد دوبارہ چلانا محفوظ ہے۔
• آؤٹ پٹس کی تازگی اور latency توقعات کے مقابل مانیٹر ہوتی ہے۔
• Lineage دستاویزی ہے تاکہ صارفین جانیں ڈیٹا کہاں سے آتا ہے۔
• ذاتی اور حساس ڈیٹا مناسب طور پر درجہ بند، masked، یا محدود ہے۔
• Backfills اور دوبارہ پروسیسنگ معاون اور دستاویزی ہیں۔
• Alerting مالکان کو ناکامیوں اور معیار کی خلاف ورزیوں سے مطلع کرتی ہے۔
• برقراری اور حذف کی پالیسیاں ذخیرہ شدہ ڈیٹا پر نافذ ہیں۔
• Downstream صارفین اور SLAs دستاویزی ہیں۔

اوپن سورس intake اور لائسنس ریویو کی چیک لسٹ

اوپن سورس جزو اپنانے سے پہلے۔

• جزو کا لائسنس پہچانا گیا ہے اور منظور شدہ فہرست پر ہے۔
• لائسنس کی ذمہ داریاں (attribution، copyleft، notices) سمجھی اور پوری کی گئی ہیں۔
• آپ کے تقسیم کے ماڈل کے ساتھ لائسنس کی مطابقت کی تصدیق ہے۔
• پراجیکٹ فعال طور پر برقرار ہے اور صحت مند کمیونٹی رکھتا ہے۔
• معلوم کمزوریاں جانچی گئیں اور ورژن موجودہ ہے۔
• انحصار اور اس کے transitive انحصار کی فہرست بنی ہے۔
• سیکیورٹی کی کیفیت اور ماضی کے واقعات کی تاریخ کا ریویو ہوا ہے۔
• جزو نمایاں تکرار کے بغیر حقیقی ضرورت پوری کرتا ہے۔
• جزو کے اخراج کی لاگت اور بدلے جانے کی صلاحیت پر غور ہوا ہے۔
• جزو software bill of materials میں درج ہے۔
• نام زد مالک اپ ڈیٹس اور advisories ٹریک کرنے کا ذمہ دار ہے۔
• ترمیم ہو تو واپس شراکت اور اندرونی-fork کی پالیسیوں کی پیروی ہوتی ہے۔

فروخت کنندہ / تیسری پارٹی کے خطرے کی چیک لسٹ

بیرونی فروخت کنندہ یا سروس شامل کرنے سے پہلے۔

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

حکومتی تعمیل (ATO / FedRAMP طرز) کی تیاری کی چیک لسٹ

ان نظاموں کے لیے جنہیں چلانے کی رسمی اجازت درکار ہو۔

• نظام کی حد اور ڈیٹا کے بہاؤ متعین اور خاکہ بند ہیں۔
• ڈیٹا اثر کی سطح اور حساسیت سے زمرہ بند ہے۔
• قابل اطلاق کنٹرول کی بنیادی لکیر منتخب اور ڈھالی گئی ہے۔
• نظام کا سیکیورٹی منصوبہ دستاویزی کرتا ہے کہ ہر کنٹرول کیسے نافذ ہے۔
• کنٹرولز نافذ، شہادت شدہ، اور منصوبے سے نقشہ بند ہیں۔
• مسلسل نگرانی اور کمزوری کی اسکیننگ فعال ہیں۔
• عمل اور سنگ میل کا منصوبہ کھلے نتائج کو اصلاح تک ٹریک کرتا ہے۔
• رسائی کا کنٹرول، آڈٹ logging، اور شناخت کا انتظام تقاضے پورے کرتے ہیں۔
• خفیہ کاری منظور شدہ الگورتھم اور توثیق شدہ ماڈیولز استعمال کرتی ہے۔
• واقعے کے ردعمل کا منصوبہ دستاویزی اور آزمایا گیا ہے۔
• ہنگامی اور disaster-recovery کا منصوبہ دستاویزی اور آزمایا گیا ہے۔
• کنٹرولز کا آزاد جائزہ یا آڈٹ مکمل ہے۔
• اجازت دینے والے افسر کے پاس اجازت دینے کو درکار خطرے کا جائزہ ہے۔
• دوبارہ اجازت کے ٹرگرز اور جاری اجازت کی تال متعین ہیں۔