10.4 بڑے اور طویل العمر نظاموں کی پائیداری

جائزہ اور محرکات

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

بڑے اداروں کے لیے یہ زیادہ اہم کیوں ہے؟ ذمہ داری کا تسلسل۔ اسٹارٹ اپ اپنا سافٹ ویئر دوبارہ لکھ یا ترک کر سکتا ہے۔ قومی حکومت refactor کرتے ہوئے پنشن دینا بند نہیں کر سکتی۔ انٹرپرائزز اور ایجنسیاں ایسے نظاموں کی مالک ہیں جن کی ناکامی کے نتائج روزی، حفاظت، یا عوامی اعتماد میں ناپے جاتے ہیں۔ اور وہ ان میں سے بہت سے ایک ساتھ رکھتی ہیں، ایسے لوگوں کے عملے کے ساتھ جو دہائیوں میں آتے اور جاتے ہیں۔ مرکزی خطرات غیر معمولی نہیں۔ وہ نظام کو سمجھنے والے لوگوں کا آہستہ آہستہ گھسنا (bus factor، کتنے کم لوگ چھوڑ دیں تو نظام کا علم کھو جائے)، غیر دستاویزی علم کا چند ذہنوں میں ڈھیر ہونا، ٹیکنالوجی اسٹیک کا زندگی کے اختتام کی طرف سڑنا، اور وہ مفلوجی ہیں جو تب چھا جاتی ہے جب نظام چھونے کے لیے بہت نازک اور محفوظ طریقے سے بدلنے کے لیے بہت کم سمجھا ہوا ہو جائے۔

یہ باب نگرانی داری کے بارے میں ہے: نظام کو اپنے مصنفین سے نرمی سے آگے جینے میں مدد دینے کا دانستہ، غیر پرکشش کام۔ یہ ملکیت کے تسلسل اور bus-factor میں کمی، منصوبہ بند deprecation اور سورج غروب، علم کی منتقلی، دہائیوں طویل نظاموں کے مخصوص چیلنجز، اور اختراع اور اس استحکام کو برقرار رکھنے کے درمیان مسلسل توازن ڈھانپتا ہے جس پر شہری اور گاہک منحصر ہیں۔

بنیادی اصول

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

سفارشات

نگرانی داری اور ملکیت کا تسلسل قائم کریں

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

bus factor اور کلیدی شخص کے خطرے میں کمی کریں

علم کے ارتکاز کو فعال طور پر ناپیں اور گھٹائیں۔ اگر صرف ایک شخص نظام ڈیپلائے، debug، یا تبدیل کر سکتا ہے تو وہ ناکامی کا واحد نقطہ ہے اتنا ہی حقیقی جتنا کوئی ہارڈ ویئر۔ اسے pairing اور گردش، لازمی کوڈ ریویو، مشترک on-call، اور دانستہ قاعدے سے کم کریں کہ کسی نازک کام کے پاس بالکل ایک اہل شخص نہ ہو۔ ٹریننگ دیں تاکہ کم از کم دو (ترجیحاً تین) لوگ ہر لازمی فعل انجام دے سکیں۔ کلیدی شخص کی رخصتی کو متوقع واقعہ سمجھیں جس کی آپ مسلسل تیاری کرتے ہیں، جھٹکا جسے آپ جذب کرتے ہیں نہیں۔ دستاویزات مدد کرتی ہیں۔ لیکن ٹیم میں اصل عمل سے پھیلا کام کرنے کا علم ان دستاویزات سے کہیں زیادہ پائیدار ہے جن کی کسی نے مشق نہ کی ہو۔

علم کی منتقلی کو ادارہ جاتی بنائیں

وہ علم پکڑیں جو ورنہ لوگوں کے ساتھ چلا جاتا۔ پہلے اس علم پر توجہ دیں جسے دوبارہ بنانا مشکل ہو: فیصلے کیوں کیے گئے، کون سے متبادل رد ہوئے اور کیوں، تیز کنارے اور نازک hacks کہاں ہیں جن پر باقی نظام خاموشی سے انحصار کرتا ہے، اور نظام دباؤ میں کیسے برتاؤ کرتا ہے۔ انتخابوں کے پیچھے دلیل، صرف انتخاب نہیں، محفوظ کرنے کو architecture decision records استعمال کریں۔ Runbooks اور آپریشنل دستاویزات نظام کے قریب رکھیں، اور ان کی باقاعدہ مشق کریں تاکہ وہ سچی رہیں۔ آن بورڈنگ کے راستے بنائیں جو نئے نگرانوں کو حقیقی قابلیت تک پہنچائیں۔ رخصتیوں کو حقیقی ہینڈ آور کے وقت کے ساتھ علم کی منتقلی کے واقعات سمجھیں۔ یاد رکھیں کہ ضمنی علم، نظام کا احساس، بنیادی طور پر اس کے ساتھ کام کر کے منتقل ہوتا ہے جس کے پاس وہ ہے، اس لیے جہاں ممکن ہو رخصت ہوتے اور آتے نگرانوں کو اوور لیپ کریں۔

deprecation، سورج غروب، اور زندگی کے اختتام کا انتظام کریں

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

دہائیوں تک نظاموں کو برقرار رکھیں

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

اختراع کو استحکام اور اعتماد کے ساتھ متوازن کریں

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

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
پرانا نظام رکھیں اور برقرار رکھیں	ادارہ جاتی علم بچاتا ہے؛ کم خلل؛ ثابت شدہ قابل اعتمادی	پرانا اسٹیک؛ نایاب مہارتیں؛ غیر برقرار ہو تو بڑھتا خطرہ
Big-bang دوبارہ تحریر	تازہ اسٹیک؛ جمع شدہ کوڑا جھاڑتی ہے	ناکامی کی بہت اونچی شرح؛ مشکل سے کمایا کناروں کا علم کھو دیتی ہے
بتدریج جدید کاری	مسلسل خطرے میں کمی؛ چلتا رہتا ہے	سست؛ مستقل فنڈنگ اور نظم و ضبط چاہیے
دستاویزات پر مبنی منتقلی	واضح، قابل تلاش ریکارڈ	برقرار نہ رکھی جائے تو سڑتی ہے؛ ضمنی علم چوکتی ہے
لوگوں پر مبنی منتقلی (pairing/گردش)	پائیدار کام کرنے کا علم؛ لچکدار ٹیمیں	موجودہ پیداواریت کی قیمت؛ دانستہ شیڈولنگ چاہیے
نازک مرکز کو منجمد کریں	قلیل مدتی زیادہ سے زیادہ استحکام	اسٹیک ناقابل دیکھ بھال ہونے تک پرانا ہوتا ہے؛ چھونے کے لیے بہت ڈراؤنا

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

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

آپ کے کن نازک نظاموں کی ابھی کوئی موجودہ، نام زد ٹیم کی ملکیت نہیں؟ ملکیت مسلسل تفویض ہے، یاد نہیں کہ کوڈ کس نے لکھا، اور غیر مملوکہ نازک نظام انتظار کرتی ہنگامی صورت ہے جو صرف ٹوٹنے پر نوٹس ہوتی ہے۔ اپنے سروس کیٹلاگ سے گزریں (یا بنائیں) اور جانچیں کہ ہر نظام ریکارڈ کرتا ہے کہ اس کا مالک کون ہے، یہ کس پر منحصر ہے، اور کتنا نازک ہے۔ شہادت لائیں: تین اہم نظام چنیں اور جوابدہ ٹیم کا نام اور ملکیت کا آخری ریویو کب ہوا بتانے کی کوشش کریں۔ جہاں نظام یتیم ہو، یا جہاں دوبارہ تنظیم نے اسے خاموشی سے گرا دیا ہو، وہاں مفروضے کی بجائے حقیقی ہینڈ آور کے ساتھ ملکیت دانستہ تفویض کریں۔ یقینی بنائیں کہ ملکیت میں نظام کو سمجھنے اور بدلنے کی صلاحیت شامل ہے، تاکہ نگرانی داری محض بچوں کی نگرانی میں نہ ڈھلے۔
جب آپ نظام بدلتے ہیں تو پرانے کو بند کرنے کا اصل جوابدہ کون ہے؟ ابدی متوازی دوڑ عام اور مہنگی ناکامی ہے: پرانے اور نئے نظام غیر معینہ مدت ساتھ ساتھ چلتے ہیں کیونکہ کوئی بند کرنے کا مالک نہیں، آپ کو دو نظام برقرار رکھنے پر چھوڑتے اور دونوں میں سے کسی کی حفاظت نہ دیتے۔ ہر سورج غروب کو منظم پراجیکٹ سمجھیں جس میں decommission مکمل کرنے کی نام زد جوابدہی، صارفین کی نقشہ بند فہرست، منتقلی کا راستہ، اور حقیقت پسند ٹائم لائن ہو۔ شہادت لائیں: آج آپ کی ملکیت میں کتنی “عارضی” متوازی دوڑیں یا آدھے ریٹائر نظام اب بھی دیکھ بھال کھینچ رہے ہیں؟ نظام کے چلنا بند ہونے کے بہت بعد قانونی برقراری کے قواعد پورے کرنے کو ڈیٹا اور ریکارڈز محفوظ رکھیں، مگر برقراری کو کبھی ختم نہ کرنے کا بہانہ نہ بننے دیں۔ بری طرح کیا گیا سورج غروب zombie نظام چھوڑتا ہے جو غیر برقرار مگر اب بھی انحصار شدہ ہیں، بدترین دونوں دنیاؤں کا امتزاج۔
آپ کے طویل العمر نظاموں کی کون سی مہارتیں لیبر مارکیٹ فراہم کرنا بند کر دے گی، اور آپ کی جانشینی کا منصوبہ کیا ہے؟ جو نظام بیس یا تیس سال چلتے ہیں وہ اپنی زبانوں کے ماحولیاتی نظام، اپنے فروخت کنندگان، اور پرانا اسٹیک سمجھنے والوں کے کیریئرز سے آگے جیتے ہیں، اور مارکیٹ قابل بھروسگی سے آپ کو متبادل نہیں دے گی۔ bus factor دانستہ کم کریں تاکہ کسی نازک فعل کے پاس بالکل ایک اہل شخص نہ ہو، اور ٹریننگ دیں تاکہ کم از کم دو، ترجیحاً تین، لوگ ہر لازمی کام انجام دے سکیں۔ شہادت لائیں: ہر پرانے نازک نظام کے لیے گنیں کتنے لوگ اسے محفوظ طور پر بدل سکتے ہیں اور سب سے زیادہ علم رکھنے والے ریٹائرمنٹ کے کتنے قریب ہیں۔ جواب کو جانشینوں کی دانستہ تربیت اور رخصت ہوتے اور آتے نگرانوں کے درمیان حقیقی اوور لیپ چلانا چاہیے، کیونکہ ضمنی علم (نظام کا احساس) بنیادی طور پر اس کے ساتھ کام کر کے منتقل ہوتا ہے جس کے پاس وہ ہے۔ دستاویزات حوالہ ہیں؛ جیا ہوا، ٹیم کے پاس رکھا علم ریڑھ ہے۔
آپ نے اپنا سب سے نازک طویل العمر نظام آخری بار کب بدلا، اور کیا اب بھی کوئی ایسا کرنے کی ہمت کرتا ہے؟ وہ نظام جسے ایک سال سے کسی نے نہ چھوا مستحکم نہیں، یہ “چھونے کے لیے بہت ڈراؤنا” جال کی طرف بہہ رہا ہے، جہاں ہر تبدیلی سے ڈرا جاتا ہے اور اس لیے اسٹیک خاموشی سے سپورٹ سے باہر پرانا ہوتا ہے۔ بڑے ادارے کے لیے یہ اس لیے اہم ہے کہ مفلوجی مرکب ہوتی ہے: جتنا لمبا انجماد، اتنا علم مدھم اور آخری ناگزیر تبدیلی اتنی خطرناک۔ شہادت لائیں: ہر نازک نظام کے لیے آخری دانستہ تبدیلی کی تاریخ، سب سے چھوٹی تبدیلی کا سائز جس کی کوئی آج کوشش کرے گا، اور کیا معمول کا انحصار یا سیکیورٹی patch اس ہفتے بغیر بہادری کے بھیجا جا سکتا ہے۔ متصادم غور حقیقی ہے، کیونکہ تبدیلی بھی خطرہ لاتی ہے، اس لیے ہدف ہلچل نہیں بلکہ چھوٹے، الٹنے کے قابل، اچھی طرح ٹیسٹ شدہ قدموں کی مستقل تال ہے۔ انٹرپرائز اور سرکاری ملکیتوں میں، جہاں منجمد مرکز دہائی بھر شہریوں کی سروس کے نیچے بیٹھ سکتا ہے، “ہم اسے کبھی نہیں بدلتے” کو تسلی کی بجائے سرخ جھنڈا سمجھیں، اور وہ مسلسل دیکھ بھال فنڈ کریں جو تبدیلی کا اختیار زندہ رکھتی ہے۔
آپ کی ملکیت کا کتنا حصہ ایسی ٹیکنالوجی پر چل رہا ہے جو زندگی کے اختتام پر یا قریب ہے، اور اس گھڑی کو کون ٹریک کر رہا ہے؟ پرانے runtimes، غیر سہارا یافتہ ڈیٹا بیسز، اور دیکھ بھال سے باہر فریم ورکس آہستہ ناکامی کا انداز ہیں جو اس دن اچانک بحران بن جاتا ہے جب سیکیورٹی patch آنا بند ہو۔ بڑی ٹیم کے لیے خطرہ یہ ہے کہ کوئی افق کا مالک نہیں: انفرادی ٹیمیں جو ٹوٹے اسے patch کرتی ہیں، لیکن کوئی پورٹ فولیو کا نظارہ نہیں رکھتا کہ کون سے اسٹیک کب فروخت کنندہ کی سپورٹ کھوتے ہیں۔ شہادت لائیں: ہر نازک نظام کی بنیادی ٹیکنالوجیز کی فہرست، ان کی شائع شدہ زندگی کے اختتام یا سپورٹ کے اختتام کی تاریخیں، اور آپ جو چلاتے ہیں اور جو اب بھی سہارا یافتہ ہے ان کے درمیان موجودہ خلا۔ کھنچاؤ مسلسل اپ گریڈ کی لاگت اور موخر کرنے کے خطرے کے درمیان ہے، اور موخر کرنا عموماً تب تک جیتتا ہے جب تک تباہ کن طور پر ہار نہ جائے۔ انٹرپرائز اور سرکاری ترتیبوں میں، جہاں خریداری اور توثیق کے چکر ایک سال یا زیادہ لے سکتے ہیں، زندگی کے اختتام کی تاریخ جو دور لگتی ہے اکثر پہلے ہی آپ کے lead time کے اندر ہوتی ہے، اس لیے جانشینی اور اپ گریڈ کا کام گھڑی ختم ہونے سے بہت پہلے شروع ہونا چاہیے۔
آپ کی ملکیت میں کہاں استحکام قدر ہے اور نیا پن ذمہ داری، اور آپ اس حد کو ایماندار کیسے رکھتے ہیں؟ ہر نظام ایک جیسے سلوک کو انعام نہیں دیتا: بنیادی نظام جن پر شہری اور گاہک روزانہ منحصر ہیں عموماً قابل اعتمادی اور محتاط تبدیلی کو انعام دیتے ہیں، جبکہ کنارے تجربے کو، اور دونوں کو ملانا پیسہ ضائع کرتا ہے یا بندشوں کو دعوت دیتا ہے۔ بڑے ادارے کے لیے خطرہ یہ ہے کہ عزائم اور کیریئر کی ترغیبات دلچسپ دوبارہ تحریروں کو ٹھیک اسی پائیدار مرکز میں دھکیلتی ہیں جسے بے مزہ رہنا چاہیے۔ شہادت لائیں: آپ کی ملکیت کا نقشہ جو نشان زد کرے کہ کہاں قابل اعتمادی مشن ہے اور کہاں نیا پن قدر پیدا کرتا ہے، ساتھ حالیہ تبدیلیاں جنہوں نے کسی بھی سمت میں وہ لکیر پار کی اور ان کی لاگت کیا تھی۔ متصادم غور یہ ہے کہ مستحکم مرکز کو بھی ارتقا کرنا ہے، اس لیے “مستحکم” انجماد کا بہانہ نہیں بن سکتا۔ انٹرپرائز اور سرکاری سیاق میں اس حد کو واضح نازکیت کی تہوں اور نام زد اختیار سے جوڑیں جو اس نظام کی خطرناک دوبارہ تحریر کو ویٹو کر سکے جسے عوام ناکام دیکھنا برداشت نہیں کر سکتی، تاکہ فیصلہ اس سہ ماہی میں جو سب سے بلند ہو اس کے ساتھ نہ بہے۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ مٹھی بھر انجینئروں اور کم رن وے کے ساتھ، آپ کا پائیداری کا خطرہ ایک یا دو لوگوں میں مرتکز ہے جنہوں نے وہ نظام لکھے جنہیں آپ کھونے کی استطاعت نہیں رکھتے، جیسے billing یا auth۔ عمل پر تقریباً کچھ خرچ نہ کریں، لیکن ابھی سستی، زیادہ قدر کی چیزیں کریں: ہر نازک نظام میں دوسرے شخص کو pair کریں، حیران کرنے والے حصوں کے لیے ایک صفحے کا architecture decision record لکھیں، اور ایسا runbook رکھیں جو آپ واقعی استعمال کریں۔ کسی چیز کو صرف اس لیے دوبارہ لکھنے کی خواہش کا مقابلہ کریں کہ وہ پرانی ہے، کیونکہ آپ کے سائز پر بنیادی نظام کی ناکام دوبارہ تحریر کمپنی ختم کر سکتی ہے۔

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

بڑا ادارہ۔ آپ کا چیلنج پورٹ فولیو کا پیمانہ ہے: بہت سے طویل العمر نظام، بہت سی ٹیمیں، اور عملہ جو دہائیوں میں گھومتا ہے۔ سروس کیٹلاگ میں ٹیم کی سطح کی ملکیت معیاری کریں، ملکیت بھر bus factor ناپیں، اور big-bang دوبارہ تحریروں پر داؤ لگانے کی بجائے مسلسل بتدریج جدید کاری فنڈ کریں۔ زندگی کے اختتام کے افق مرکزی طور پر منظم کریں تاکہ کوئی نازک اسٹیک خاموشی سے سپورٹ سے باہر نہ ہو، اور ہر سورج غروب کو decommission مکمل کرنے کی نام زد جوابدہی کے ساتھ آڈٹ شدہ پراجیکٹ کے طور پر چلائیں۔

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

مثالیں

اسٹارٹ اپ۔ پانچ افراد کے اسٹارٹ اپ کے پاس پہلے ہی ایک نظام ہے جسے وہ کھونے کی استطاعت نہیں رکھتا: billing سروس جو ایک بانی نے پہلے مہینے میں لکھی اور جو اب ہر گاہک کا چارج چلاتی ہے۔ صرف وہی بانی اسے سمجھتا ہے، اس لیے ٹیم bus factor کو تعریف کی بجائے حقیقی خطرہ سمجھتی ہے۔ وہ دوسرے انجینئر کو پورے billing سائیکل سے pair کرتے ہیں، مختصر architecture decision record لکھتے ہیں کہ عجیب retry منطق کیوں موجود ہے، اور کوڈ کے ساتھ runbook رکھتے ہیں جس کی وہ واقعے کے دوران واقعی مشق کرتے ہیں۔ وہ اسے صرف اس لیے دوبارہ لکھنے کی مزاحمت کرتے ہیں کہ یہ پرانی اور غیر پرکشش ہے، اور اس کی بجائے اسے چھوٹے الٹنے کے قابل قدموں میں بہتر کرتے ہیں، تاکہ کمپنی کو زندہ رکھنے والی سروس ایک سے زیادہ ذہن سمجھیں۔

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

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

کاروباری جواز: محرکات، ROI اور TCO

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

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

ضد نمونے اور خامیاں

ہیرو maintainer۔ ایک ناقابل بدل شخص جو نظام سمجھتا ہے؛ اس کی رخصتی وجودی واقعہ ہے۔
منجمد کرو اور بھول جاؤ۔ نازک نظام کو “مکمل” قرار دینا، دیکھ بھال بند کرنا، اور اس کے اسٹیک کو ناقابل دیکھ بھال میں پرانا ہوتے دیکھنا۔
ناکام دوبارہ تحریر۔ ادارے کو مکمل تبدیلی پر داؤ پر لگانا جو کوڈ شدہ علم پھینکتی اور عموماً حد سے بڑھتی یا ناکام ہوتی ہے۔
یتیم نظام۔ موجودہ مالک کے بغیر نازک سافٹ ویئر، صرف ٹوٹنے پر نوٹس ہوتا ہے۔
دستاویزات کا تھیٹر۔ پرانی، غیر مشق شدہ دستاویزات کے ڈھیر جن پر کوئی بھروسہ نہیں کرتا۔
ابدی متوازی دوڑ۔ پرانے اور نئے نظام غیر معینہ مدت ساتھ چلتے ہیں کیونکہ بند کرنے کا کوئی جوابدہ نہیں۔
ضمنی علم کا نقصان۔ ماہرین کو اوور لیپ کے بغیر جانے دینا، تاکہ نظام کا احساس غائب ہو جائے۔
چھونے کے لیے بہت ڈراؤنا۔ اتنا کم سمجھا نظام کہ کسی بھی تبدیلی سے ڈر لگے، جو اس کے سڑنے کی ضمانت ہے۔

پختگی کا ماڈل

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

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

سطح 3: معیار بندی۔ نگرانی داری کے عمل دستاویزی اور ادارے بھر نافذ ہیں۔ ٹیم کی سطح کی ملکیت سروس کیٹلاگ میں ریکارڈ اور دوبارہ تنظیم سے بچتی ہے۔ گردش اور کراس ٹریننگ سے bus-factor میں کمی مستقل قاعدہ ہے، architecture decision records اور مشق شدہ runbooks متوقع ہیں، جدید کاری پالیسی کے طور پر بتدریج ہے، اور ہر سورج غروب decommission مکمل کرنے کی نام زد جوابدہی کے ساتھ منظم پراجیکٹ کے طور پر چلتا ہے۔

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

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

بحث کے لیے خیالات

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

اہم نکات

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

حوالہ جات اور مزید مطالعہ

Michael Feathers, Working Effectively with Legacy Code
Titus Winters, Tom Manshreck, and Hyrum Wright, Software Engineering at Google
Frederick P. Brooks Jr., The Mythical Man-Month
Nat Pryce and Steve Freeman, Growing Object-Oriented Software, Guided by Tests
Sam Newman, Monolith to Microservices
Martin Fowler, Refactoring and writings on the Strangler Fig pattern
Betsy Beyer et al., Site Reliability Engineering and The Site Reliability Workbook (Google)
Diomidis Spinellis, Code Reading: The Open Source Perspective
U.S. Government Accountability Office, reports on federal legacy IT modernisation