9.6 کیاوس انجینئرنگ اور لچک کی جانچ

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

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

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

انٹرپرائز اور سرکاری سیاق داؤ اور، بڑھتی تعداد میں، مینڈیٹ بڑھاتے ہیں۔ مالیاتی ضابطہ ساز اب اداروں سے توقع کرتے ہیں کہ وہ شدید-مگر-قرین قیاس منظرناموں کے مقابل آپریشنل لچک آزمائیں اور ثابت کریں کہ وہ رکاوٹ کے دوران نازک سروسز چلتی رکھ سکتے ہیں۔ سرکاری ادارے continuity-of-operations کی مشقیں چلاتے ہیں تاکہ لازمی عوامی سروسز بندشوں، آفات، اور سائبر حملوں سے بچیں۔ دونوں دنیاؤں میں “ہمارا خیال ہے کہ یہ ٹھہرے گا” آڈیٹر یا شہری کے لیے قابل قبول جواب نہیں۔ کیاوس انجینئرنگ آپ کو ثبوت دیتی ہے۔ یہ باب سائٹ ریلائیبلٹی انجینئرنگ (باب 9.1) اور باب 3.5 کی لچک کے نمونوں پر بنتا ہے، اور واقعہ مینجمنٹ (باب 9.3) اور آفت سے بحالی (باب 9.5) سے مضبوطی سے جڑتا ہے۔

بنیادی اصول

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

سفارشات

ایک بھی نقص ڈالنے سے پہلے پیشگی شرائط قائم کریں

کیاوس انجینئرنگ پختہ نظام کے لیے قوت بڑھانے والی اور ناپختہ کے لیے ذمہ داری ہے۔ شروع کرنے سے پہلے آپ کو تین چیزیں جگہ پر چاہییں۔ پہلی، مشاہدہ پذیری، یعنی میٹرکس، لاگز، اور traces جو آپ کو باہر سے دیکھنے دیں کہ آپ کا نظام کیا کر رہا ہے، کیونکہ جو تجربہ آپ دیکھ نہیں سکتے وہ کچھ نہیں سکھاتا۔ دوسری، service level objectives یا مستحکم حالت کی صحت کی مساوی تعریف (باب 9.1)، تاکہ آپ حقیقی وقت میں کامیاب تجربے کو نقصان دہ سے الگ پہچان سکیں۔ تیسری، تیز اور قابل بھروسہ rollback یا abort کا راستہ، تاکہ جس لمحے تجربہ حقیقی صارفین کو خطرے میں ڈالے آپ اسے روک کر سیکنڈوں میں عام سروس بحال کر سکیں۔ اگر آپ اپنے نظام کو ناپ نہیں سکتے، اس کی صحت مند حالت متعین نہیں کر سکتے، اور اسے کنارے سے واپس نہیں کھینچ سکتے تو ابھی کیاوس تجربات نہ چلائیں۔ پہلے وہ صلاحیتیں بنائیں۔ وہ ویسے بھی اپنی ادائیگی کر دیتی ہیں۔

مستحکم حالت متعین کریں اور حقیقی مفروضہ بنائیں

ہر تجربہ یہ لکھ کر شروع ہوتا ہے کہ عام حالت قابل پیمائش اصطلاحات میں کیسی ہے: درخواست کی کامیابی کی شرح 99.9 فیصد سے اوپر، checkout کی تاخیر 95ویں percentile پر 400 ملی سیکنڈ سے کم، قطار کی گہرائی حد سے نیچے۔ یہ آپ کی مستحکم حالت کی تعریف ہے، اور اسے صارف کو نظر آنے والی صحت کی عکاسی کرنی چاہیے، اندرونی plumbing کی نہیں۔ پھر سادہ زبان میں مفروضہ بیان کریں: “اگر ہم سفارشات کی سروس میں 300 ملی سیکنڈ کی تاخیر ڈالیں تو پروڈکٹ کا صفحہ اپنے تاخیر کے budget کے اندر پھر بھی render ہوگا کیونکہ صفحہ سفارشات کو اختیاری سمجھتا ہے اور 200 ملی سیکنڈ پر timeout کرتا ہے۔” اب آپ کے پاس قابل تردید دعویٰ ہے۔ جب آپ تجربہ چلاتے ہیں تو دو اچھی چیزوں میں سے ایک ہوتی ہے۔ یا تو نظام پیش گوئی کے مطابق برتاؤ کرتا ہے اور آپ کا اعتماد کمایا ہوا ہے، یا نہیں کرتا اور آپ نے حقیقی کمزوری سستے میں، اپنی شرائط پر، انجینئروں کے دیکھتے ہوئے ڈھونڈی۔

حقیقت پسند نقائص ڈالیں، من مانے نہیں

آپ جو نقائص متعارف کرتے ہیں انہیں ان ناکامیوں کی عکاسی کرنی چاہیے جو آپ کا نظام واقعی جھیلتا ہے۔ Fault injection، یعنی دانستہ غلطیاں ڈالنا یہ جانچنے کو کہ نظام کیسے جواب دیتا ہے، آپ کو حقیقی پروڈکشن واقعات سے لیا ہوا مینو دیتی ہے۔ سست انحصار یا saturated نیٹ ورک لنک کی نقل کرنے کو تاخیر ڈالیں۔ ناکام ہوتی نیچے کی سروس کی نقل کرنے کو HTTP 500 یا connection refusal لوٹاتی غلطیاں ڈالیں۔ دباؤ میں نظام کیسے گھٹتا ہے دیکھنے کو CPU، میموری، ڈسک، یا file descriptors کھا کر وسائل کی تھکن ڈالیں۔ پورا ڈیٹا بیس، cache، قطار، یا تیسری پارٹی کا API ناقابل رسائی بنا کر انحصار کی ناکامی ڈالیں۔ تقسیم شدہ نظام میں، جہاں اجزا الگ مشینوں پر چلتے اور ناقابل اعتماد نیٹ ورک پر بات کرتے ہیں، یہی ناکامیاں حقیقی بندشوں پر غالب ہیں۔ عملاً چیزیں توڑنے والی صاف crashes نہیں بلکہ تاخیر اور جزوی ناکامی ہے، اس لیے اپنے تجربات کو گندے درمیانے حصے کی طرف جھکائیں۔

توثیق کریں کہ آپ کی لچک کے میکانزم واقعی کام کرتے ہیں

یہاں کیاوس انجینئرنگ اپنا حصہ کماتی ہے۔ آپ کا نظام ان میکانزم سے بھرا ہے جن سے آپ کی حفاظت متوقع ہے: timeouts جو کال کرنے والے کو ہمیشہ انتظار سے روکتے ہیں، retries جو عارضی ہچکیاں ڈھانپتی ہیں، circuit breakers جو ناکام انحصار کو ہتھوڑے مارنا بند کرتے ہیں، اور failover جو primary کے مرنے پر standby پر منتقل ہوتا ہے۔ یہ نمونے، جو باب 3.5 میں ڈھکے ہیں، محدود مسئلے اور آبشاری بندش کے درمیان فرق ہیں۔ مصیبت یہ ہے کہ انہیں ان حالات میں شاذ آزمایا جاتا ہے جن کے لیے وہ موجود ہیں۔ 30 سیکنڈ پر طے timeout جب کال کرنے والے کی اپنی مہلت 2 سیکنڈ ہو کچھ نہیں کرتا۔ backoff کے بغیر retry ایک جدوجہد کرتی سروس کو thundering herd بنا دیتی ہے۔ جس circuit breaker کی مشق نہ ہوئی وہ غلط ترتیب شدہ ہو سکتا ہے اور کبھی نہ چلے، یا مسلسل چلے۔ کیاوس تجربات وہ طریقہ ہیں جس سے آپ تصدیق کرتے ہیں کہ ان میں سے ہر ایک ڈیزائن کے مطابق برتاؤ کرتا ہے جب وہ نقص واقعی آتا ہے جس سے یہ بچاتا ہے۔ فرض کریں ہر غیر آزمودہ حفاظتی میکانزم ٹوٹا ہے جب تک تجربہ دوسرا ثابت نہ کرے۔

خودکار کرنے سے پہلے game days سے شروع کریں

ایسے خودکار پلیٹ فارم سے شروع نہ کریں جو مسلسل نقائص ڈالے۔ Game day سے شروع کریں: طے شدہ، عملی مشق جہاں ٹیم جمع ہو، منظرنامہ چنے، کنٹرول شدہ ماحول میں نقص ڈالے، اور مل کر دیکھے۔ اس سے بھی پہلے، tabletop مشق، جہاں آپ نظام کو چھوئے بغیر منظرنامے پر وائٹ بورڈ پر بات کرتے ہیں، تقریباً صفر خطرے پر runbooks، الرٹنگ، اور ملکیت میں خلا سامنے لاتی ہے۔ Game days آپ کا on-ramp ہیں۔ وہ مفروضے بنانے، دھماکے کا دائرہ محدود کرنے، اور دباؤ میں نظام پڑھنے کی مہارت بناتے ہیں، اور قیادت اور ہمسایہ ٹیموں کے ساتھ وہ اعتماد بناتے ہیں جو آپ کو پروڈکشن میں تجربات چلانے دینے سے پہلے چاہیے۔ وہ واقعے کے جواب کو براہ راست مضبوط بھی کرتے ہیں، کیونکہ مہارتیں وہی ہیں جو آپ کے on-call انجینئر حقیقی واقعے میں استعمال کرتے ہیں (باب 9.3)۔ اپنے پہلے game days staging میں چلائیں، پھر خاموش اوقات میں چھوٹے دھماکے کے دائرے کے ساتھ پروڈکشن میں، پھر پھیلائیں۔

دھماکے کا دائرہ دانستہ محدود کریں

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

مسلسل، خودکار لچک کی توثیق کی طرف بڑھیں

کبھی کبھار کے game days کمزوریاں ڈھونڈتے ہیں، لیکن نظام روز بدلتے ہیں، اور پچھلی سہ ماہی کی اصلاح خاموشی سے دوبارہ بگڑ سکتی ہے۔ پختہ انتہا مسلسل توثیق ہے: لچک کے منتخب تجربات کا مجموعہ جو pipeline میں یا شیڈول پر خودکار چلے، تاکہ timeout، retry پالیسی، یا failover راستے میں regression اگلی حقیقی بندش کے دوران کی بجائے دنوں میں پکڑا جائے۔ یہاں Netflix کے Chaos Monkey جیسے ٹولز نے اپنی ساکھ کمائی، جو پروڈکشن میں instances بے ترتیب ختم کرتا ہے تاکہ انجینئر ایسی سروسز بنانے پر مجبور ہوں جو instance کا کھونا برداشت کریں۔ صرف وہ تجربات خودکار کریں جنہیں آپ دستی رنز سے پہلے سمجھتے اور ان پر بھروسہ کرتے ہیں۔ ناپختہ نظام کے اوپر مسلسل افراتفری واقعات پیدا کرنے کا طریقہ ہے، اعتماد کا نہیں۔

تجربات کو آفت سے بحالی اور واقعے کی سیکھ سے جوڑیں

کیاوس انجینئرنگ اکیلی نہیں رہتی۔ بڑے، نادر منظرنامے، پورے علاقے کو کھونا، ڈیٹا بیس کا failover، backup سے بحالی، آفت سے بحالی کی جانچ (باب 9.5) کے ہیں، اور game day اکثر ان منصوبوں کی مشق کا بہترین ذریعہ ہے بجائے انہیں غیر آزمودہ دستاویزات کے طور پر سڑنے دینے کے۔ دوسری طرف، ہر تجربہ جو کمزوری سامنے لائے اسی سیکھنے کے چکر میں جانا چاہیے جس میں حقیقی واقعہ جاتا ہے (باب 9.3): بغیر الزام تحریر، ٹریک شدہ اصلاح، اور فالو اپ تجربہ جو تصدیق کرے کہ اصلاح ٹکی ہے۔ جب کیاوس کے نتائج، آفت سے بحالی کی مشقیں، اور واقعے کے ریویو سب لچک کے کام کے ایک backlog میں بہتے ہیں تو آپ کو بکھرے ایک بار کی مشقوں کی بجائے مرکب واپسی ملتی ہے۔

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

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

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

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

کیا ہم واقعی کیاوس تجربات چلانے کو تیار ہیں، اور ہمیں کیسے پتہ چلے گا؟ نقائص ڈالنا اس لیے دلکش ہے کہ یہ نفیس لگتا ہے، لیکن بغیر مشاہدہ پذیری، صحت کی واضح تعریف، اور تیز rollback کے نظام پر کیاوس انجینئرنگ محض اپنی لائی ہوئی بندش ہے۔ اس بحث میں ایماندار شہادت لائیں: کیا آپ حقیقی وقت میں درخواست کی کامیابی کی شرحیں اور تاخیر دیکھ سکتے ہیں، کیا آپ کی مستحکم حالت کی متفقہ تعریف ہے، اور کیا آپ تجربہ abort کر کے سیکنڈوں میں بحال ہو سکتے ہیں؟ بڑی ٹیم کے لیے جواب اکثر سروس بہ سروس مختلف ہوتا ہے، اس لیے مفید نتیجہ تیاری کا وہ معیار ہے جو سروس کو تجربات کی اہل ہونے سے پہلے پار کرنا ہے۔ ضابطے کی ترتیبوں میں وہ تیاری کا معیار کنٹرول کے طور پر بھی کام کرتا ہے جو آپ آڈیٹر کو دکھا سکیں۔ اگر ایماندار جواب یہ ہے کہ آپ تیار نہیں تو اس سہ ماہی میں سب سے قیمتی کیاوس کا کام وہ مشاہدہ پذیری اور rollback کی صلاحیتیں بنانا ہے جو آپ کو تیار کریں۔
ہماری دھماکے کے دائرے کی پالیسی کیا ہے، اور تجربہ روکنے کا اختیار کس کے پاس ہے؟ ہر کیاوس تجربہ حقیقی صارفین کو کچھ خطرہ رکھتا ہے، اور قیمتی نتیجے اور آپ کے پیدا کیے واقعے کے درمیان فرق یہ ہے کہ آپ نے اسے کتنی سختی سے محدود کیا۔ ٹھوس حدوں پر بات کریں: ٹریفک کا کون سا حصہ، کتنے instances، کون سے ماحول، دن کے کون سے اوقات، اور کون سی میٹرک کی حدیں خودکار طور پر رن abort کرتی ہیں۔ پہلے سے طے کریں کہ ہر تجربے کو کون دیکھ رہا ہے اور واحد عمل والا kill switch کس کے پاس ہے، کیونکہ جس تجربے کو کوئی جلدی روک نہ سکے وہ محدود نہیں۔ بڑے ادارے کے لیے یہ پالیسی وہی ہے جو بہت سی ٹیموں کو تجربہ کرنے دیتی ہے بغیر اس کے کہ کوئی ایک حادثاتی طور پر مشترک انحصار گرا دے۔ جواب لکھا ہونا، ان ٹیموں سے متفقہ جن کی سروسز آپ متاثر کر سکتے ہیں، اور پروڈکشن میں کچھ بھی چلانے کی پیشگی شرط سمجھا جانا چاہیے۔
ہم کون سے لچک کے میکانزم کو اپنا محافظ مانتے ہیں، اور کیا ہم نے کبھی انہیں واقعی آزمایا ہے؟ زیادہ تر نظام timeouts، retries، circuit breakers، caches، اور failover کے راستوں سے بھرے ہیں جو ایک بار ترتیب دیے گئے اور اس ناکامی کے تحت کبھی نہیں آزمائے گئے جس کے لیے وہ ہیں۔ ان میکانزم کی فہرست بنائیں جن پر آپ انحصار کر رہے ہیں، پھر ہر ایک کے لیے پوچھیں کہ آخری بار کب حقیقی ڈالے گئے نقص کے تحت اس کے کام کرنے کی توثیق ہوئی۔ متصادم غور وقت ہے: ہر میکانزم کی توثیق انجینئرنگ کی کوشش لیتی ہے، اور فیچر کی ڈیڈ لائن ہمیشہ موجود ہے۔ اس اعتراض کے لیے جوابی شہادت لائیں، یعنی ماضی کی اس بندش کی لاگت جسے کام کرتا circuit breaker یا درست timeout محدود کر دیتا۔ جواب کو فرض کردہ تحفظات کی تسلی بخش فہرست کو تجربات کے ترجیحی backlog میں بدلنا چاہیے، ان میکانزم سے شروع کرتے ہوئے جن کی ناکامی سب سے زیادہ نقصان دے۔
ہم staging کی بجائے پروڈکشن میں تجربہ چلانے سے پہلے کیا سچ ہونا چاہیے، اور آج کن سروسز نے وہ حق کمایا ہے؟ جو نتائج آپ سب سے زیادہ چاہتے ہیں وہ پروڈکشن سے آتے ہیں، کیونکہ وہی واحد جگہ ہے جہاں آپ کا نظام حقیقی ٹریفک، حقیقی ڈیٹا، اور حقیقی پیمانے سے ملتا ہے، پھر بھی پروڈکشن وہ جگہ بھی ہے جہاں بگڑا تجربہ اصل صارفین کو نقصان دیتا ہے۔ بڑی ٹیم کے لیے ایماندار حقیقت یہ ہے کہ مختلف سروسز تیاری کی مختلف سطحوں پر ہیں، اس لیے “پروڈکشن میں کیاوس نہیں” کا یکساں قاعدہ آپ کا بہترین سیکھنا ضائع کرتا ہے جبکہ یکساں “ہاں” خود کی لائی بندشوں کو دعوت دیتا ہے۔ فی سروس شہادت لائیں: اس کی مشاہدہ پذیری کا معیار، آیا مستحکم حالت متعین اور الرٹ کے قابل ہے، rollback کتنا تیز ہے، اور صاف staging تجربات کا ریکارڈ جو اسے ترقی دینے کا جواز دے۔ انٹرپرائز اور سرکاری ترتیبوں میں پروڈکشن کے دروازے کو دستاویزی کنٹرول سے جوڑیں جو بتائے ترقی کی منظوری کون دیتا ہے اور زندہ میٹرکس سے کون سی abort شرائط جڑی ہیں، تاکہ آڈیٹر ٹیم کے حقیقی صارفین کے ساتھ فی البدیہہ کرنے کی بجائے دانستہ، شہادت پر مبنی فیصلہ دیکھے۔
جب کیاوس تجربہ کمزوری سامنے لائے تو وہ نتیجہ کہاں جاتا ہے، اور ہم اسے بے چھوئے سڑنے سے کیسے روکتے ہیں؟ وہ پروگرام جو کمزوریاں دریافت کرے مگر کبھی ٹھیک نہ کرے نہ ہونے سے بدتر ہے، کیونکہ یہ کوشش جلاتا ہے، اعتماد گھساتا ہے، اور لوگوں کو سکھاتا ہے کہ تجربات تماشا ہیں۔ متصادم دباؤ ہمیشہ فیچر کا روڈ میپ ہے: لچک کی اصلاح اگلی ریلیز جتنی فوری شاذ لگتی ہے جب تک وہ بندش نہ آ جائے جسے وہ روک سکتی تھی۔ اپنے لچک کے backlog کی موجودہ حالت بحث میں لائیں: کتنے کیاوس کے نتائج کھلے ہیں، سب سے پرانا کتنا پرانا ہے، اور کیا تجربات، آفت سے بحالی کی مشقوں، اور واقعے کے ریویو کے نتائج ایک مشترک قطار میں بہتے ہیں یا ٹیموں میں بکھرتے ہیں۔ متفق ہوں کہ ہر اصلاح کا مالک کون ہے اور فالو اپ تجربہ کون چلاتا ہے جو تصدیق کرے کہ اصلاح ٹکی ہے۔ بڑے یا ضابطے کے ادارے کے لیے اس فورم کا نام لیں جو مقررہ تال پر backlog کا ریویو کرتا اور لچک کی اصلاح کو فیچر پر ترجیح دینے کا اختیار رکھتا ہے، کیونکہ جس نتیجے کو بند کرنے کا کوئی جوابدہ نہ ہو وہ ایسا خطرہ ہے جسے آپ نے ہٹانے کی بجائے صرف دستاویزی کیا۔
کیا ہم اپنے کسی تجربے کو مسلسل توثیق میں خودکار کرنے کو تیار ہیں، اور خاص طور پر کون سے؟ کبھی کبھار کے game days کمزوریاں ڈھونڈتے ہیں، لیکن نظام روز بدلتے ہیں اور پچھلی سہ ماہی کی اصلاح خاموشی سے دوبارہ بگڑ سکتی ہے، اس لیے پختہ انتہا ان تجربات کا منتخب مجموعہ ہے جو خودکار چلے اور regressions دنوں میں پکڑے۔ خطرہ بہت جلد خودکار کرنا ہے: کمزور مشاہدہ پذیری والے ناپختہ نظام پر مسلسل افراتفری بصیرت سے تیز واقعات پیدا کرتی ہے۔ وہ تجربات کی فہرست لائیں جو آپ نے دستی طور پر اتنی بار چلائے کہ پوری طرح بھروسہ کر سکیں، دھماکے کے دائرے کے کنٹرول اور abort شرائط جو انہیں بغیر نگرانی چلنے پر حکومت کریں گی، اور وہ مانیٹرنگ جو صبح تین بجے جب کوئی نہ دیکھ رہا ہو خودکار رن کا غلط جانا پکڑے۔ بڑے انٹرپرائز یا عوامی ایجنسی کے لیے بغیر نگرانی نقص ڈالنے سے بڑھنے والی جانچ تولیں: تبدیلی کے انتظام کی منظوری، ہر خودکار رن کو چھوڑنا ہوگی آڈٹ ٹریل، اور اس طے شدہ تجربے کی واضح جوابدہی جو حقیقی واقعے سے ٹکرائے۔ صرف وہ تجربات خودکار کریں جو آپ پہلے سے سمجھتے ہیں، اور باقی دستی رکھیں جب تک وہ وہی اعتماد نہ کمائیں۔

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

اسٹارٹ اپ۔ رفتار اور بقا غالب ہیں، اس لیے کیاوس پلیٹ فارم پر کچھ خرچ نہ کریں۔ staging میں اس واحد انحصار کے خلاف نوے منٹ کا ایک game day چلائیں جس کی ناکامی آپ کو واقعی ختم کر دے گی، عموماً ادائیگیاں، auth، یا آپ کا بنیادی ڈیٹا اسٹور۔ نقص خام proxy یا مارے گئے process سے ڈالیں، دیکھیں کیا ٹوٹتا ہے، غائب timeout یا fallback ٹھیک کریں، اور آگے بڑھیں۔ پورا مقصد واضح اپنی لائی بندش کو سستے میں گاہک سے پہلے پکڑنا ہے، ایسا نظم و ضبط بنانا نہیں جس کا آپ عملہ نہ دے سکیں۔

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

بڑا ادارہ۔ مسئلہ مشترک انحصار کے خلاف پیمانے پر بہت سی ٹیموں کی ہم آہنگی ہے، اس لیے تیاری کا معیار، دھماکے کے دائرے کی پالیسی، اور abort-condition کی وائرنگ معیاری کریں جو ہر ٹیم کو پروڈکشن میں چلانے سے پہلے پار کرنی ہے۔ کیاوس کے نتائج، آفت سے بحالی کی مشقوں، اور واقعے کے ریویو کو واضح ملکیت والے ایک لچک کے backlog میں بھیجیں، اور آپریشنل لچک کی توقعات کو شہادت سے پورا کرنے کو سہ ماہی game days اور خودکار تجربات کا منتخب مجموعہ استعمال کریں۔ نظم و نسق کریں کہ مشترک سروس کو کون متاثر کر سکتا ہے تاکہ کسی ایک ٹیم کا تجربہ اس انفراسٹرکچر کو نہ گرا دے جس پر دوسرے منحصر ہیں۔

حکومت۔ خریداری کے قواعد، شفافیت، اور عوامی جوابدہی کام کو شکل دیتے ہیں۔ Continuity-of-operations کے مینڈیٹ اکثر ویسے بھی باقاعدہ مشقیں مانگتے ہیں، اس لیے انہیں زندہ game days کے طور پر چلائیں جو حقیقی نتائج دیں بجائے binder کے جسے کوئی نہیں کھولتا، اور ہر تجربے، اس کے دھماکے کے دائرے، اور اس کے نتیجے کی آڈٹ ٹریل رکھیں۔ جہاں fault-injection کی ٹولنگ خریدی جائے مطالبہ کریں کہ وہ سیکیورٹی اور ڈیٹا سنبھالنے کے قواعد میں فٹ ہو، اور شہریوں کے سامنے کی سروسز پر پروڈکشن تجربات تنگ طور پر محدود، منظور شدہ کھڑکیوں کے لیے رکھیں۔ کیاوس پروگرام جو ثبوت پیدا کرتا ہے ٹھیک وہی ہے جو نگرانی کا ادارہ یا آڈیٹر دیکھنے کی توقع کرتا ہے۔

مثالیں

اسٹارٹ اپ۔ پندرہ افراد کا اسٹارٹ اپ مٹھی بھر سروسز پر ویب ایپ چلاتا ہے اور تیسری پارٹی کے ادائیگی کے API پر منحصر ہے۔ کسی کے پاس کیاوس پلیٹ فارم کا وقت نہیں، اس لیے ٹیم staging میں نوے منٹ کا game day چلاتی ہے۔ وہ مفروضہ بناتے ہیں: اگر ادائیگی کا API غلطیاں لوٹانے لگے تو checkout کو واضح retry کا پیغام دکھانا اور آرڈر کو قطار میں رکھنا چاہیے، crash نہیں ہونا۔ وہ سادہ proxy سے 500 جوابات ڈالتے ہیں، اور دریافت کرتے ہیں کہ فرنٹ اینڈ غیر معینہ مدت تک لٹک جاتا ہے کیونکہ کلائنٹ کال کا کوئی timeout نہیں۔ وہ timeout اور دوستانہ fallback جوڑتے ہیں، اصلاح کی تصدیق کو تجربہ دوبارہ چلاتے ہیں، اور مشترک دستاویز میں دو پیراگراف کا نوٹ لکھتے ہیں۔ کل لاگت: ایک دوپہر اور ایک بہت حقیقی bug جو گاہک کے ٹکرانے سے پہلے پکڑا گیا۔

بڑا ادارہ۔ عالمی بینک کو ضابطہ سازوں کے سامنے شدید-مگر-قرین قیاس منظرناموں کے مقابل آپریشنل لچک دکھانی ہے۔ اس کی قابل اعتمادی کی ٹیم سہ ماہی game days اور پروڈکشن میں خودکار تجربات کا مجموعہ چلاتی ہے۔ ایک منظرنامہ کم ٹریفک کی کھڑکی میں بنیادی لین دین کے ڈیٹا بیس کو اس کے standby پر failover کرتا ہے، سختی سے محدود دھماکے کے دائرے اور لین دین کی کامیابی کی شرح سے جڑی abort شرائط کے ساتھ۔ پہلی دوڑ ظاہر کرتی ہے کہ نیچے کی مصالحت کی سروس کی retry پالیسی میں کوئی backoff نہیں، جو لوڈ کا اچھال پیدا کرتی ہے جو آفت سے بحالی کے منصوبے (باب 9.5) میں recovery-time objective سے کہیں آگے بحالی میں تاخیر کرتا ہے۔ نتیجہ واقعے کے ریویو والے ہی backlog میں جاتا ہے، retry پالیسی exponential backoff سے ٹھیک ہوتی ہے، اور فالو اپ تجربہ تصدیق کرتا ہے کہ failover اب ہدف کے اندر مکمل ہوتا ہے۔ پوری مشق ضابطہ ساز کے لیے ثبوت بن جاتی ہے۔

حکومت۔ شہریوں کے سامنے فوائد کا پورٹل چلانے والی قومی ایجنسی پر رکاوٹوں کے دوران آپریشنز کا تسلسل برقرار رکھنا لازم ہے۔ اپنے تسلسل کے منصوبے کو binder سمجھنے کی بجائے جسے کوئی نہیں کھولتا، ایجنسی سالانہ تسلسل کی مشق کو زندہ game day کے طور پر چلاتی ہے۔ ٹیم بنیادی ڈیٹا سینٹر کے کھونے کی نقل کرتی اور ثانوی سائٹ پر failover چلاتی ہے، جبکہ الگ سے شناخت کی توثیق کے انحصار میں تاخیر ڈالتی ہے یہ دیکھنے کو کہ پورٹل نرمی سے گھٹتا ہے یا نہیں۔ وہ سیکھتے ہیں کہ غیر آزمودہ نگرانی کے خلا نے on-call ٹیم کو شناخت کی سروس کے سست ہونے سے اندھا رکھا، اس لیے الرٹس دیر سے بجے۔ ایجنسی مشاہدہ پذیری کا خلا بند کرتی ہے، runbooks اپ ڈیٹ کرتی ہے، اور اگلے سال کے لیے وہی مشق شیڈول کرتی ہے، تعمیل کے تقاضے کو نازک عوامی سروس کی حقیقی، آزمودہ لچک میں بدلتے ہوئے۔

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

کیاوس انجینئرنگ کی واپسی ان بندشوں سے آتی ہے جو کبھی نہیں ہوتیں۔ بڑی سروس کی ایک بڑی بندش کی لاگت کھوئی آمدنی، ضابطے کے جرمانوں، اصلاح کی محنت، اور ساکھ کے نقصان میں دسیوں ہزار سے لاکھوں تک ہو سکتی ہے جو سروس بحال ہونے کے بہت بعد تک رہتا ہے۔ کیاوس تجربات ان ناقابل پیش گوئی، مہنگی حیرتوں کو سستے، طے شدہ نتائج میں بدلتے ہیں جنہیں آپ اپنی ٹائم لائن پر، انجینئروں کے دیکھتے ہوئے اور rollback تیار رکھ کر ٹھیک کرتے ہیں۔ کنٹرول شدہ game day میں ٹوٹا timeout ڈھونڈنا ایک دوپہر کی لاگت ہے۔ اسے حقیقی واقعے میں ڈھونڈنا بندش، سب کی بھاگ دوڑ، اور آپ کے صارفین کے اعتماد کی لاگت ہے۔ حساب game day کے حق میں بہت زیادہ جھکا ہے۔

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

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

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

پختگی کا ماڈل

سطح 1، آغاز: لچک فرض کی جاتی ہے، آزمائی نہیں جاتی۔ ناکامیاں حقیقی واقعات کے دوران پروڈکشن میں دریافت ہوتی ہیں۔ کوئی game days نہیں، کوئی fault injection نہیں، اور اکثر صحت مند حالت کی کوئی واضح تعریف نہیں۔ ٹیم اپنی کمزوریاں مشکل طریقے سے سیکھتی ہے، ایک بندش ایک وقت میں۔
سطح 2، ترقی: ٹیم کبھی کبھار game days چلاتی ہے، عموماً staging میں، متعین منظرنامے اور مفروضے کے ساتھ۔ چند کلیدی سروسز کے لیے مستحکم حالت متعین ہے اور بنیادی مشاہدہ پذیری موجود ہے۔ نتائج پکڑے جاتے ہیں اور کچھ ٹھیک ہوتے ہیں، لیکن عمل ٹیموں میں غیر مستقل ہے اور قائم شدہ طریقے کی بجائے انفرادی چیمپئنز پر منحصر ہے۔
سطح 3، معیار بندی: کیاوس تجربات دستاویزی، ادارے بھر کا عمل ہیں جن میں نافذ دھماکے کے دائرے کی پالیسیاں، abort شرائط، اور تیاری کے معیار ہیں جو سروس کو پروڈکشن میں تجربہ کرنے سے پہلے پار کرنے ہیں۔ تجربات پروڈکشن میں کنٹرول شدہ حالات میں چلتے ہیں، نتائج واقعے کے ریویو اور آفت سے بحالی کی مشقوں کے ساتھ مشترک لچک کے backlog میں بہتے ہیں، اور لچک کے میکانزم مفروضے کی بجائے توثیق شدہ ہیں۔ ہر ٹیم ایک ہی playbook پر چلتی ہے۔
سطح 4، انتظام: پروگرام بنیادی خطوط کے مقابل ڈیٹا سے ناپا اور کنٹرول کیا جاتا ہے۔ آپ لچک کی coverage (کن نازک سروسز اور کن میکانزم، جیسے timeouts، retries، circuit breakers، اور failover، کی حقیقی ڈالے گئے نقص کے تحت توثیق ہوئی اور کتنی حالیہ)، تجربات کے نتائج سامنے لانے کی شرح، لچک کا نتیجہ بند کرنے کا اوسط وقت، اور پہلے سے توثیق شدہ میکانزم کتنی بار دوبارہ بگڑتا ہے ٹریک کرتے ہیں۔ یہ میٹرکس مقررہ تال پر ریویو ہوتی ہیں، پروڈکشن میں ترقی رائے کی بجائے شہادت پر دروازہ بند ہے، اور تجربات ابھی غیر توثیق شدہ میکانزم کے ناپے خطرے سے ترجیح پاتے ہیں۔
سطح 5، ہم آہنگی: تجربات کا منتخب مجموعہ مسلسل اور خودکار چلتا ہے، regressions دنوں میں پکڑتا ہے، اور پروگرام نظام اور اس کے خطرے کی تصویر بدلنے کے ساتھ ڈھلتا ہے۔ کیاوس انجینئرنگ ادارے بھر ترسیل کی pipelines، واقعے کی سیکھ، اور آفت سے بحالی کی جانچ کے ساتھ مربوط ہے، تاکہ نئی سروسز ڈیفالٹ طور پر لچک کی توثیق وراثت میں پائیں۔ لچک نظام کی مسلسل توثیق شدہ خاصیت ہے، اور قیادت پروگرام کو خصوصی مہم کی بجائے شہادت پر نکھاری جانے والی معیاری خطرے کی انتظام کاری سمجھتی ہے۔

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

آپ فیصلہ کیسے کرتے ہیں کہ آپ کے ادارے کی کون سی سروس پہلے پروڈکشن میں کیاوس تجربات چلانے کا حق کماتی ہے، اور ایسا ہونے سے پہلے کیا سچ ہونا چاہیے؟
جب کیاوس تجربہ سنگین کمزوری سامنے لائے تو اصلاح کا مالک کون ہے، اور آپ اس نتیجے کو backlog میں بے چھوئے پڑے رہنے سے کیسے روکتے ہیں؟
آپ کے سیاق میں کیاوس تجربے، آفت سے بحالی کی مشق، اور game day کے درمیان لکیر کہاں ہے، اور کیا یہ فرق ان کی منصوبہ بندی کے لیے بھی اہم ہے؟
آپ کسی شکی ایگزیکٹو کو کیسے قائل کریں گے کہ پروڈکشن میں دانستہ ناکامی ڈالنا حقیقی بندشوں کے انتظار کی موجودہ حالت سے زیادہ محفوظ ہے؟
اگلے مہینے آپ کی ٹیم کا سب سے چھوٹا، سب سے قیمتی پہلا تجربہ کیا ہو سکتا ہے، اور اسے چلانے سے آپ کو کیا روکے گا؟
تسلسل کے مینڈیٹ والی شہریوں کے سامنے کی عوامی سروس اور چھوٹے صارف اڈے والے اندرونی انٹرپرائز ٹول کے لیے لچک کی جانچ کیسے مختلف ہونی چاہیے؟

اہم نکات

کیاوس انجینئرنگ لچک پر اعتماد بنانے کے لیے نظم و ضبط والا، مفروضے سے چلنے والا تجربہ ہے، بے ترتیب توڑ پھوڑ نہیں۔
ایک بھی نقص ڈالنے سے پہلے مشاہدہ پذیری، مستحکم حالت کی تعریف، اور تیز rollback قائم کریں۔
حقیقت پسند نقائص (تاخیر، غلطیاں، وسائل کی تھکن، انحصار کی ناکامی) ڈالیں اور انہیں اس توثیق کے لیے استعمال کریں کہ timeouts، retries، circuit breakers، اور failover واقعی کام کرتے ہیں۔
tabletop مشقوں اور game days سے شروع کریں، دھماکے کا دائرہ دانستہ محدود کریں، اور پروڈکشن اور خودکاری کی طرف اپنا راستہ کمائیں۔
تجربات کو آفت سے بحالی کی جانچ (باب 9.5) اور واقعے کی سیکھ (باب 9.3) سے جوڑیں تاکہ نتائج ایک لچک کے backlog میں مرکب ہوں۔
نتائج کو بغیر الزام سمجھیں اور ٹھیک کریں؛ جس تجربے کا سبق نظر انداز ہو وہ کسی تجربے سے بدتر ہے۔

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

Casey Rosenthal, Nora Jones, Chaos Engineering: System Resiliency in Practice
Russ Miles, Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation
Mikolaj Pawlikowski, Chaos Engineering: Crash Test Your Applications
Ali Basiri et al., Chaos Engineering (IEEE Software, 2016)
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
Principles of Chaos Engineering, principlesofchaos.org