موضوع 3.6 — ڈیو آپس اور انجینئرنگ کا معیار

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

یہ صحت اور نگہداشت میں کیوں اہم ہے#

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

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

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

بنیادی تصورات#

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

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

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

بنیادی ڈھانچہ بطور کوڈ (IaC)۔ سرورز کو ہاتھ سے ترتیب دینے کے بجائے، آپ مشین کے پڑھنے کے قابل فائلوں میں بنیادی ڈھانچہ متعین کرتے ہیں جو ورژن کنٹرول میں رکھی جاتی ہیں۔ ماحول دہرایا جا سکنے والا، جائزے کے قابل، اور قابلِ آڈٹ بن جاتا ہے: آپ اسے بالکل ویسا دوبارہ بنا سکتے ہیں، دیکھ سکتے ہیں کہ کس نے کیا اور کیوں بدلا، اور ثابت کر سکتے ہیں کہ جانچ اور پیداوار میل کھاتے ہیں۔ یہ قابلِ اعتماد ماحول کی بنیاد ہے (دیکھیے موضوع 4.0 — تکنیکی فن تعمیر، کلاؤڈ اور پرانے نظام)۔

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

DORA پیمانے۔ DevOps Research and Assessment (DORA) نے چار پیمانے شناخت کیے جو اعلیٰ کارکردگی والی ٹیموں کو الگ کرتے ہیں: نفاذ کی تعدد (آپ کتنی بار ریلیز کرتے ہیں)، تبدیلی کا دورانیہ (کمٹ سے پیداوار تک کتنا وقت)، تبدیلی کی ناکامی کی شرح (تبدیلیوں کا کتنا تناسب مسئلہ پیدا کرتا ہے)، اور خدمت بحال کرنے کا وقت (آپ کتنی جلدی بحال ہوتے ہیں)۔ مل کر یہ ظاہر کرتے ہیں کہ رفتار اور استحکام ساتھ بڑھتے ہیں — جو ٹیمیں سب سے زیادہ نافذ کرتی ہیں وہ سب سے کم ناکام ہوتی اور سب سے تیز بحال ہوتی ہیں۔

"آپ بناتے ہیں، آپ چلاتے ہیں"، SRE، اور مشاہدہ پذیری۔ Amazon میں مقبول، "آپ بناتے ہیں، آپ چلاتے ہیں" کا مطلب ہے کہ خدمت لکھنے والی ٹیم اسے چلاتی بھی ہے، پیجر اٹھاتی ہے، اور اس کی ناکامیاں محسوس کرتی ہے — انجینئرنگ کے انتخابات اور عملیاتی حقیقت کے درمیان رائے کا دائرہ بند کرتی ہوئی (دیکھیے موضوع 3.8 — خدمات کا انتظام اور براہِ راست عملیات)۔ سائٹ ریلائبلٹی انجینئرنگ (SRE) ایک مخصوص نفاذ ہے جو آپریشنز پر انجینئرنگ لاگو کرتا ہے، صریح بھروسے کے اہداف اور خرابی کے بجٹ کے ساتھ۔ مشاہدہ پذیری — نظام کی اندرونی حالت اس کے نتائج (پیمانے، لاگز، ٹریسز) سے سمجھنے کی صلاحیت — وہ چیز ہے جو آپ کو مریضوں اور معالجین سے پہلے مسائل پکڑنے اور تشخیص کرنے دیتی ہے۔

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

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

بہترین طریقے#

1. خدمت بنانے سے پہلے CI/CD پائپ لائن بنائیں۔ پہلے ہفتے سے خودکار تعمیر، جانچ اور نفاذ قائم کریں، تاکہ ہر تبدیلی پیداوار تک اسی دہرائے جا سکنے والے، قابلِ آڈٹ راستے سے گزرے۔ پائپ لائن وہ جگہ ہے جہاں آپ کے طبی تحفظ، سلامتی اور رسائی کے دروازے خودکار جانچ کے طور پر رہتے ہیں، ٹھیک ٹھیک بتانے والا ریکارڈ دیتے ہوئے کہ کیا اور کب نافذ ہوا، جس سے چھیڑ چھاڑ کا پتا چلتا ہے۔ ضابطہ شدہ نظام میں یہ آڈٹ کا سراغ اوور ہیڈ نہیں — یہ آپ کے طبی تحفظ کے مقدمے کا ثبوت ہے (دیکھیے موضوع 1.6 — طبی تحفظ اور خطرات کا انتظام)۔

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

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

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

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

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

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

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

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

اپنی ٹیم کے ساتھ زیرِ بحث لانے کے سوالات#

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

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

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

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

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

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

عملی مثال: صحت اور نگہداشت کی ایک مثال#

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

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

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

شعبہ جاتی زاویے#

اسٹارٹ اپ#

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

چھوٹا کاروبار#

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

بڑا ادارہ#

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

حکومت#

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

عام ناکامی کے طریقے#

• "تبدیلی خطرہ ہے" کا فالج۔ محفوظ محسوس کرنے کے لیے شاذ نافذ کرنا، جو بڑی، خطرناک، کم سمجھی ہوئی ریلیزیں اور غیر پیچ شدہ نظر اندازی پیدا کرتا ہے۔ تریاق: آزمودہ واپسی کے ساتھ چھوٹی، بار بار، الٹنے کے قابل تبدیلیاں۔
• ڈیو اور آپس کے درمیان دیوار۔ ڈویلپرز "کوڈ دیوار کے پار پھینک دیتے ہیں" الگ آپریشنز ٹیم کو جو بنیادی وجوہات ٹھیک نہیں کر سکتی؛ کوئی پورے دائرے کا مالک نہیں۔ تریاق: مشترکہ ملکیت اور "آپ بناتے ہیں، آپ چلاتے ہیں"، انسانی طور پر معاون۔
• دستی، برف کے ٹکڑے جیسے نفاذ۔ ریلیزیں ایک شخص اور ویکی صفحے پر منحصر ہیں؛ ماحول بھٹکتے ہیں اور "جانچ میں کام کیا، پیداوار میں ٹوٹا" معمول ہے۔ تریاق: CI/CD اور بنیادی ڈھانچہ بطور کوڈ۔
• پیمانے بطور ڈنڈا۔ DORA کے اعداد ٹیموں کو درجہ دینے کے لیے استعمال ہوتے ہیں، ہیر پھیر اور چھپا ہوا خطرہ چلاتے ہوئے۔ تریاق: انہیں نظامی تشخیص کے طور پر استعمال کریں، جیسا DORA کی اپنی رہنمائی ہے۔
• الرٹ سے نابینا آپریشنز۔ مشاہدہ پذیری نہیں، اس لیے مریض اور معالج ناکامیاں پہلے پاتے ہیں۔ تریاق: پیمانے، لاگز، ٹریسز، اور صارف کے اثر پر الرٹنگ۔
• نظر انداز شدہ سپلائی چین۔ غیر پیچ شدہ انحصار اور غیر اسکین شدہ اجزا خلاف ورزی بن جاتے ہیں۔ تریاق: مسلسل اسکیننگ، سافٹ ویئر بل آف میٹریلز، اور محفوظ پائپ لائنیں۔
• اتفاقی بے نقابی۔ لاپروائی سے کیا گیا کھلے عام کوڈنگ، رازوں یا مریض کے ڈیٹا کا لیک۔ تریاق: راز کا سخت انتظام اور شائع کرنے سے پہلے اسکیننگ، بطور ڈیفالٹ بند کی طرف پسپائی نہیں۔

پختگی کا ماڈل#

جانچ فہرست#

• CI/CD پائپ لائن ہر تبدیلی کو ایک قابلِ آڈٹ راستے سے تعمیر، جانچتی اور نافذ کرتی ہے، تحفظ/سلامتی/رسائی کے دروازے انکوڈ کیے ہوئے۔
• تبدیلیاں چھوٹی، بار بار، اور آزادانہ طور پر الٹنے کے قابل ہیں (فیچر فلیگز، کینری یا بلو گرین ریلیزیں)۔
• معلوم اچھی حالت پر واپسی باقاعدہ آزمائی جاتی ہے اور دستاویزی، مختصر وقت میں مکمل ہوتی ہے۔
• بنیادی ڈھانچہ اور ترتیب ورژن کنٹرول والے کوڈ کے طور پر متعین ہیں؛ جانچ اور پیداواری ماحول میل کھاتے ہیں۔
• چاروں DORA پیمانے نظامی اشارے کے طور پر ٹریک ہوتے ہیں، افراد یا ٹیموں کو درجہ دینے کے لیے استعمال نہیں ہوتے۔
• ترسیلی ٹیمیں پیداوار میں اپنی خدمات کی مالک ہیں، انسانی، فنڈ شدہ آن کال اور بامعنی مشاہدہ پذیری (پیمانے، لاگز، ٹریسز، الرٹنگ) کے ساتھ۔
• انحصار کی فہرست اور خودکار اسکیننگ ہے؛ سافٹ ویئر بل آف میٹریلز موجود ہے اور راز محفوظ ہیں۔
• انجینئرنگ کے معیارات، کوڈ کا جائزہ، اور "مکمل" کی تعریف پر اتفاق ہے؛ تکنیکی قرض ٹریک اور منصوبہ بند کام کے طور پر چکایا جاتا ہے۔
• نیا سورس کوڈ جہاں محفوظ ہو بطور ڈیفالٹ کھلا ہے، سخت جانچ کے ساتھ کہ کوئی مریض کا ڈیٹا یا راز بے نقاب نہ ہو۔
• انجینئرنگ کی مشق دستاویزی ہے تاکہ نیا انجینئر، آڈیٹر، یا تحفظ کا افسر سمجھ سکے کہ کیا چلتا ہے اور کیوں (دیکھیے موضوع 10.3)۔

کلیدی ماخذ#

• نکول فارسگرین، جیز ہمبل اور جین کم، Accelerate: The Science of Lean Software and Development and DevOps — DORA کی تحقیق اور چار کلیدی پیمانے۔
• DORA (DevOps Research and Assessment) — سالانہ State of DevOps رپورٹیں اور صلاحیتوں کا کیٹلاگ — dora.dev۔
• جیز ہمبل اور ڈیوڈ فارلی، Continuous Delivery — نفاذ کی پائپ لائن اور ریلیز کی خودکاری۔
• بیٹسی بیئر وغیرہ (مدیران)، Site Reliability Engineering — پیداواری نظام چلانے پر Google کی SRE کتاب۔
• NHS انگلینڈ — NHS سروس اسٹینڈرڈ اور NHS ڈیجیٹل سروس مینوئل (بشمول کھلے عام کوڈنگ اور کھلے معیارات)۔
• GOV.UK سروس مینوئل / گورنمنٹ سروس اسٹینڈرڈ (GDS) — "نیا سورس کوڈ کھلا بنائیں"، مسلسل ترسیل، اور خدمت چلانا۔
• نیشنل سائبر سیکیورٹی سینٹر (NCSC) — محفوظ سافٹ ویئر ڈیولپمنٹ اور سپلائی چین کی سلامتی پر رہنمائی۔
• NHS انگلینڈ — طبی خطرات کے انتظام کے معیارات DCB0129 اور DCB0160 (انجینئرنگ کی تبدیلی بطور طبی تحفظ کے مقدمے کا حصہ)۔

حوالہ جات#

1. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
2. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
3. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
4. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
5. Version control — Wikipedia — https://en.wikipedia.org/wiki/Version_control
6. Infrastructure as code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
7. Platform engineering — Wikipedia — https://en.wikipedia.org/wiki/Platform_engineering
8. DevOps Research and Assessment (DORA) — Wikipedia — https://en.wikipedia.org/wiki/DevOps_Research_and_Assessment
9. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Supply chain attack — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_attack
12. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
13. Accelerate: The Science of Lean Software and DevOps — Nicole Forsgren, Jez Humble & Gene Kim (IT Revolution) — https://itrevolution.com/product/accelerate/
14. DORA — DevOps Research and Assessment — Google Cloud / DORA — https://dora.dev/
15. Continuous Delivery — Jez Humble & David Farley — https://continuousdelivery.com/
16. Site Reliability Engineering — Google (O'Reilly) — https://sre.google/books/
17. NHS Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard-points
18. Making source code open and reusable — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable
19. Secure software development and supply chain security — National Cyber Security Centre (NCSC) — https://www.ncsc.gov.uk/collection/developers-collection
20. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety