9.8 آن کال اور آپریشنل تیاری

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

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

اسے دو پڑوسیوں سے الگ رکھیں۔ باب 9.3 واقعہ مینجمنٹ ڈھانپتا ہے، یعنی جواب کا عمل جب کچھ فعال طور پر ٹوٹا ہو: command کے کردار، شدت کی سطحیں، ہم آہنگی، اور postmortems۔ باب 9.1 site reliability engineering (SRE) ڈھانپتا ہے، service level objectives اور error budgets کے ساتھ قابل اعتمادی کی انجینئرنگ کا وسیع نظم و ضبط۔ یہ باب واقعے کے اوپر کی طرف اور اس نظم و ضبط کے ساتھ بیٹھتا ہے۔ یہ تنگ، زیادہ ذاتی سوال پوچھتا ہے: کیا سروس چلنے کے لیے تیار ہے، اور کیا پیجر اٹھانے والا شخص تکلیف کی بجائے کامیابی کے لیے تیار ہے؟ ادارے کے پاس بہترین واقعے کا عمل ہو سکتا ہے اور پھر بھی وہ اپنے انجینئروں کو تھکا سکتا ہے، کیونکہ on-call کی تکلیف کسی بھی واقعے سے بہت پہلے طے ہو جاتی ہے، الرٹس کے معیار، runbooks کی حالت، اور شیڈول کی انسانیت سے۔

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

بنیادی اصول

• انسان کو صرف ایسے مسائل پر پیجر دیں جو فوری، قابل عمل، اور حقیقی ہوں۔
• باری اس شخص کے لیے ڈیزائن کریں جس کی زندگی ہے، ہمیشہ دستیاب مشین کے لیے نہیں۔
• پروڈکشن ٹریفک اٹھانے سے پہلے ثابت کریں کہ سروس چلانے کو تیار ہے۔
• ہر اندرونی وجہ پر نہیں، صارف کو نظر آنے والی علامات اور SLOs پر الرٹ کریں۔
• runbooks اور تیاری کے ریویو کو زندہ دستاویزات سمجھیں جو استعمال ہوتی ہیں، فائل نہیں ہوتیں۔
• جو سروس بنائے اسے اسے چلانے میں بھی مدد دینی چاہیے، انسان دوست اور سہارا یافتہ حدوں میں۔
• on-call کی صحت ناپیں اور toil کم کریں تاکہ بوجھ اوپر کی بجائے نیچے کی طرف رجحان رکھے۔

سفارشات

انسان دوست، پائیدار باری ڈیزائن کریں

شیڈول کی شکل سے شروع کریں، کیونکہ یہ کسی بھی ٹول سے زیادہ پائیداری طے کرتی ہے۔ عام نمونہ ہفتہ وار باری ہے جس میں primary جواب دہندہ پہلے پیجز لیتا ہے اور secondary بیک اپ کے طور پر کام کرتا ہے جب primary acknowledge نہ کرے یا مدد چاہے۔ تالاب اتنا بڑا رکھیں کہ کوئی ایک انجینئر چار ہفتوں میں ایک سے زیادہ بار on-call نہ ہو، اور مثالی طور پر چھ میں ایک یا اس سے آگے۔ چار یا کم لوگوں کی باری انتباہی علامت ہے: بیماری، چھٹیاں، اور چھوڑ جانا اسے انہی دو تھکے ہیروز میں ڈھا دیں گے۔

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

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

پیجنگ کی پالیسی کو قابل عمل، فوری، حقیقی مسائل کے بارے میں بنائیں

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

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

الرٹ کے معیار کو اولین درجے کی انجینئرنگ کی ترسیل سمجھیں۔ Acknowledge-to-action کا تناسب ٹریک کریں: جو پیجز بجے ان میں سے کتنے ایسے تھے جن پر انسان نے کچھ اہم کیا؟ جس الرٹ کو سہ ماہی میں ایک بار بھی عمل کی ضرورت نہ پڑی وہ حذف یا درجہ گھٹانے کا امیدوار ہے۔ اپنے الرٹس کا باقاعدہ تال پر ریویو کریں، اور کسی بھی انجینئر کو شور والے الرٹ کو چیلنج کرنے کا حق دیں۔ ہدف ایسی باری ہے جہاں صفحہ اتنا نادر ہو کہ اب بھی کچھ معنی رکھے۔

علامات اور SLOs پر الرٹ کریں، وجوہات پر نہیں

شور کاٹنے کا سب سے مؤثر طریقہ یہ بدلنا ہے کہ آپ کس پر الرٹ کرتے ہیں۔ وجوہات پر الرٹ کرنا، جیسے اونچا CPU، بھری ڈسک، یا ایک process کا دوبارہ شروع ہونا، ایسی حالتوں کے لیے پیجز کا سیلاب پیدا کرتا ہے جو شاید کسی صارف کو کبھی متاثر نہ کریں اور جنہیں نظام اکثر خود شفا دیتا ہے۔ اس کی بجائے علامات پر الرٹ کریں: کیا سروس وہ کر رہی ہے جو صارفین کو چاہیے؟ اپنے پیجنگ الرٹس کو اپنے service-level objectives (SLOs) سے باندھیں، باب 9.1 میں متعین عددی قابل اعتمادی کے اہداف، اور تب پیجر دیں جب آپ error budget اتنی تیزی سے جلا رہے ہوں کہ ہدف چوک جائیں، یا جب تاخیر یا کامیابی کی شرح جیسا صارف کو نظر آنے والا اشارہ اس لکیر کو پار کرے جو لوگ واقعی محسوس کرتے ہیں۔

یہ علامت پر مبنی، SLO سے چلنے والا طریقہ باب 9.2 کی مشاہدہ پذیری اور telemetry پر منحصر ہے، کیونکہ burn-rate الرٹنگ تبھی کام کرتی ہے جب آپ کی میٹرکس، لاگز، اور traces ساختہ اور قابل بھروسہ ہوں۔ نتیجہ ڈرامائی ہے: مٹھی بھر بامعنی علامتی الرٹس سینکڑوں وجہ پر مبنی الرٹس کی جگہ لیتے ہیں، اور صفحہ پھر ایسے مسئلے سے ہم ربط ہوتا ہے جو جگانے کے لائق ہو۔ وجوہات پھر بھی اہم ہیں، لیکن وہ تشخیصی ڈیش بورڈز پر تعلق رکھتی ہیں جن سے جواب دہندہ علامتی الرٹ بجنے کے بعد رجوع کرتا ہے، پیجنگ کے راستے میں نہیں۔

آغاز سے پہلے آپریشنل تیاری لازم کریں

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

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

ایسے runbooks اور playbooks لکھیں جو واقعی استعمال ہوں

Runbook قدم بہ قدم آپریشنل دستاویز ہے: یہ سروس کیسے دوبارہ شروع کریں، یہ credential کیسے گھمائیں، یہ قطار کیسے خالی کریں، یہ الرٹ کیسے سمجھیں۔ Playbook صورت حال کی کسی قسم کے لیے وسیع تر جواب کی رہنمائی ہے۔ اگر کوئی انہیں نہ پڑھے تو دونوں بیکار ہیں، اور زیادہ تر runbooks اس لیے نہیں پڑھے جاتے کہ وہ باسی، مبہم، یا صبح تین بجے ڈھونڈنا ناممکن ہیں۔ ناکامی کے انداز براہ راست ٹھیک کریں۔ Runbook کو الرٹ سے ہی جوڑیں، تاکہ جواب دہندہ صفحے سے ایک کلک میں اس تک پہنچے۔ Runbooks کو کوڈ کے ساتھ ورژن کنٹرول میں رکھیں، جیسا باب 2.7 کے دستاویزی عمل سفارش کرتے ہیں، تاکہ وہ کسی بھی دوسرے آرٹیفیکٹ کی طرح ریویو اور اپ ڈیٹ ہوں۔ انہیں دباؤ میں، نیند میں اجنبی کے لیے لکھیں، ٹھوس کمانڈز اور متوقع نتائج کے ساتھ، ایسی نثر نہیں جو مصنف کا سیاق فرض کرے۔

Runbook کا امتحان یہ ہے کہ کیا اس کے مصنف کے علاوہ کوئی دباؤ میں اس کی کامیاب پیروی کر سکتا ہے۔ آن بورڈنگ اور game days کے دوران اس کی توثیق کریں، اور جس لمحے واقعہ ظاہر کرے کہ وہ غلط تھا runbook اپ ڈیٹ کریں۔ جھوٹ بولنے والا runbook نہ ہونے سے بدتر ہے، کیونکہ وہ تھکے جواب دہندہ کو اعتماد سے غلط سمت بھیجتا ہے۔

جو بنائیں اس کے مالک بنیں، انسان دوست حدوں میں

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

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

on-call انجینئروں کی دانستہ آن بورڈنگ کریں اور game days چلائیں

کسی کو پہلی بار اکیلے اور غیر تیار پیجر نہیں اٹھانا چاہیے۔ آن بورڈنگ کا راستہ بنائیں: ایک باری کے لیے تجربہ کار جواب دہندہ کو shadow کرنا، reverse-shadowing جہاں نیا آنے والا رہنما کی نگرانی میں قیادت کرے، ڈیش بورڈز اور runbooks کا دورہ، اور واضح نقشہ کہ کس کو escalate کرنا ہے۔ on-call جانے کی تیاری کو مفروضے کی بجائے واضح سنگ میل بنائیں۔

Game days وہ مشق ہیں جو on-call کو حقیقی بناتی ہیں۔ Game day میں آپ دانستہ ناکامی کی مشق کرتے ہیں، مثالی طور پر حقیقت پسند ماحول میں، اور on-call انجینئر کو صرف وہ ٹولز اور runbooks استعمال کر کے جواب دینے دیتے ہیں جو اس کے پاس حقیقی واقعے میں ہوں گے۔ یہاں آپ دریافت کرتے ہیں کہ runbook پرانا ہے، ڈیش بورڈ میں اشارہ غائب ہے، یا الرٹ کبھی بجتا ہی نہیں۔ Game days عضلاتی یادداشت اور اعتماد بناتے ہیں جو پہلے حقیقی صفحے کو گھبراہٹ سے طریقہ کار میں بدلتا ہے، اور وہ قدرتی طور پر باب 9.6 کی کیاوس انجینئرنگ سے جڑتے ہیں۔

صاف ہینڈ آف چلائیں اور on-call کی صحت ناپیں

شفٹوں کے درمیان ہینڈ آف وہ جگہ ہے جہاں سیاق رستا ہے۔ مختصر، ساختہ ہینڈ آف قائم کریں: فی الحال کیا گھٹا ہوا ہے، کون سے الرٹس بجے اور دبائے گئے، کون سی تبدیلیاں جاری ہیں، کیا دیکھنا ہے۔ اسے بنیادی on-call صفائی سے جوڑیں، بشمول پالیسی کہ رخصت ہونے والا جواب دہندہ آنے والے کے لیے گڑبڑ نہ چھوڑے، اور جو کچھ آدھا ٹھیک رہ گیا ہو لکھا جائے۔

سب سے بڑھ کر، ناپیں۔ آپ وہ بوجھ منظم نہیں کر سکتے جو آپ دیکھتے نہیں۔ فی شفٹ پیجز، off-hours (شامیں، راتیں، اختتام ہفتہ) پر پڑنے والے پیجز کا حصہ، acknowledge کا وقت، اور secondary اور escalation کی تہیں کتنی بار ٹرگر ہوتی ہیں ٹریک کریں۔ صرف عدد نہیں، رجحان دیکھیں: وہ باری جس کے off-hours پیجز سہ ماہی بہ سہ ماہی چڑھیں، موجودہ مطلق گنتی سے قطع نظر، تھکن کی طرف جا رہی ہے۔ ان میٹرکس کو باقاعدہ آپریشنل ریویو میں کھلائیں جہاں ٹیم طے کرے کہ کون سا toil خودکار کر کے ہٹانا ہے، کون سے الرٹس مارنے ہیں، اور تیاری کہاں کم رہی۔ Toil، بار بار کا دستی آپریشنل کام جو ایک بار ٹھیک ہونے کی بجائے ٹریفک کے ساتھ بڑھتا ہے، کم کرنا ہی وہ طریقہ ہے جس سے نظام کے بڑھتے ہوئے on-call کا بوجھ مستقل رہتا ہے۔

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

انتخاب	فوائد	نقصانات
آپ بنائیں، آپ چلائیں	قابل اعتمادی کا تنگ رائے کا چکر؛ مالک بنیادی وجوہات ٹھیک کرتے ہیں	کم وسائل یا چھوٹی ٹیموں کے لیے ظالمانہ؛ رات کا غیر مساوی بوجھ
مرکزی SRE یا پلیٹ فارم on-call	پروڈکٹ ٹیموں کو معمول کے رات کے پیجز سے بچاتا ہے؛ گہری آپریشنل مہارت	بنانے والے کے رائے کے چکر کو کمزور کرتا ہے؛ کوڑے دان بن سکتا ہے
Follow-the-sun باری	رات بھر کسی کو پیجر نہیں؛ انسان دوست اور صحت مند	کئی علاقوں میں عملہ چاہیے؛ بھاری ہینڈ آف اوور ہیڈ
چھوٹی مقامی باری	سادہ؛ ہر کوئی نظام جانتا ہے	بیماری یا چھوڑنے پر ڈھ جاتی ہے؛ تیز تھکن
علامت اور SLO الرٹنگ	کم، بامعنی پیجز؛ کم تھکن	پختہ telemetry چاہیے؛ آہستہ بنتی وجوہات چوک سکتی ہیں
وجہ پر مبنی الرٹنگ	مسائل جلد اور مخصوص پکڑتی ہے	جواب دہندگان کو بھر دیتی ہے؛ alarm fatigue چلاتی ہے
سخت تیاری کے ریویو	پروڈکشن میں کم ناگوار حیرتیں	آغاز سست کرتے ہیں؛ کھیلے جائیں تو افسر شاہانہ لگ سکتے ہیں

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

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

1. کیا آپ ذاتی طور پر یہ باری ایک سال اٹھانے کو تیار ہوں گے، اور اگر جواب نہیں ہے تو آپ کیا بدلیں گے؟ یہ سوال تجرید کاٹتا ہے کیونکہ یہ بوجھ کو ذاتی بناتا ہے۔ گفتگو میں حقیقی اعداد لائیں: پچھلے مہینے کتنے پیجز بجے، کتنے آدھی رات یا اختتام ہفتہ کے بعد پڑے، اور اوسط acknowledgment میں کتنا وقت لگا۔ باری کے ہر شخص سے پوچھیں کہ کیا موجودہ شکل ایسی ہے جسے وہ اپنے on-call ہفتے کے خوف کے بغیر نبھا سکتا ہے، اور بلند آوازوں کے ساتھ خاموش جوابات بھی سنیں۔ اگر ایماندار جواب یہ ہے کہ باری صرف اس لیے قابل برداشت ہے کہ دو ہیروز بدترین بوجھ جذب کرتے ہیں تو آپ نے وہ نازکی پائی ہے جو پہلی بار ان میں سے کسی کے جانے پر ٹوٹے گی۔ جو نتیجہ آپ چاہتے ہیں وہ تبدیلیوں کی ٹھوس فہرست ہے، چاہے بڑا تالاب ہو، follow-the-sun تقسیم، رات کے پیجز میں کمی، یا الرٹنگ کی صفائی، ہر ایک کے ساتھ مالک اور تاریخ منسلک۔

2. ہر اس الرٹ کے لیے جو انسان کو پیجر دے سکتا ہے، کیا آپ وہ عمل بتا سکتے ہیں جو جواب دہندہ سے متوقع ہے؟ زیادہ تر باریوں نے کبھی اس کا آڈٹ نہیں کیا، اور یہ مشق انکشاف خیز ہے۔ پیجنگ الرٹس کی پوری فہرست نکالیں اور ہر ایک کے لیے پوچھیں کہ بجنے پر جواب دہندہ کو کیا کرنا ہے اور پچھلی سہ ماہی میں یہ کتنی بار کسی حقیقی عمل کے بغیر بجا۔ جو الرٹس امتحان میں ناکام ہوں، جن سے کوئی عمل نہ جوڑ سکے، یا جو مسلسل کسی کے چھونے سے پہلے خود حل ہو جائیں، وہ شور ہیں جو ہر دوسرے الرٹ پر اعتماد گھساتے ہیں۔ اگر آپ کے پاس acknowledge-to-action کا ڈیٹا ہے تو لائیں، اور جارحانہ طور پر حذف یا درجہ گھٹانے کو تیار رہیں۔ ہدف پیجنگ کا ایسا راستہ ہے جہاں ہر الرٹ انسانی مدد کی حقیقی درخواست ہو، اور میٹنگ کو الرٹ کی فہرست پہلے سے مختصر اور تیز کر کے ختم ہونا چاہیے۔

3. جب نیا انجینئر اس باری میں آئے تو اسے ٹھیک کیا تیار کرتا ہے، اور کیا آپ نے آزمایا کہ یہ کام کرتا ہے؟ on-call کی آن بورڈنگ اکثر ڈیزائن ہونے کی بجائے فرض کی جاتی ہے، اور خلا پہلی بار نظر آتا ہے جب نئے آنے والے کو اکیلے ایسی ناکامی میں پیجر ملے جو اس نے کبھی نہ دیکھی ہو۔ نئے جواب دہندہ کا حقیقی راستہ دیکھیں: وہ کیا shadow کرتا ہے، کون سے runbooks پڑھتا ہے، کیا حال ہی میں کسی نے ان runbooks کی پیروی کر کے تصدیق کی ہے کہ وہ اب بھی کام کرتے ہیں، اور اٹکنے پر کسے escalate کرتا ہے۔ حقیقی حالیہ واقعہ چن کر پوچھیں کہ کیا نیا ملازم، صرف موجودہ runbooks اور ڈیش بورڈز سے لیس، اسے حل کر سکتا تھا۔ ایماندار جواب عموماً باسی دستاویزات اور غائب اشارے ظاہر کرتا ہے، جو ٹھیک وہی ہے جو game days کا مقصد ہے کہ حقیقی واقعے سے پہلے سامنے لائیں۔ on-call کے لیے تیاری کے متعین سنگ میل اور ان game days کے شیڈول کے ساتھ جائیں جو اسے ایماندار رکھیں۔

4. ہمارے off-hours پیجز اصل میں کہاں پڑتے ہیں، اور کیا ہم لوگوں کی نیند کی حفاظت کو عملے یا کوریج کو بدلنے کو تیار ہیں؟ رات اور اختتام ہفتہ کے پیجز صحت کی لاگت رکھتے ہیں جسے خام گنتی چھپاتی ہے، اس لیے اوسطاً قابل برداشت لگنے والی باری پھر بھی خاموشی سے چند لوگوں کو تباہ کر سکتی ہے جنہیں اتفاق سے صبح تین بجے کی ناکامیاں ملتی ہیں۔ گھنٹے اور ہفتے کے دن کے حساب سے پیجز کی تقسیم، سروس اور جواب دہندہ کے مطابق الگ، لائیں، اور اوسط کی بجائے ارتکاز دیکھیں۔ متصادم غور حقیقی ہے: follow-the-sun کوریج کو ایک سے زیادہ علاقے میں عملہ چاہیے اور ہینڈ آف کا اوور ہیڈ جوڑتی ہے، جبکہ چھوٹی مقامی باری سادہ ہے مگر کسی کو راتوں کا مالک چھوڑتی ہے۔ دانستہ طے کریں کہ حل دوسرے علاقے کی باری ہے، مرکزی پلیٹ فارم ٹیم کا after-hours تہیں سنبھالنا، بحالی کے وقت کی ضمانت کے ساتھ رات کے مختصر بلاک، یا الرٹنگ کی صفائی جو رات کا شور اس کے ماخذ پر ہٹائے۔ انٹرپرائز اور سرکاری آپریٹرز کے لیے on-call عملے کی طرف فرض کی دیکھ بھال کو مالک اور رپورٹ شدہ میٹرک کے ساتھ رسمی ذمہ داری سمجھیں، فلاح کا نعرہ نہیں، کیونکہ ضابطہ ساز یا مزدور کونسل آخرکار آپ سے اسے دکھانے کو کہہ سکتی ہے۔

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

6. “آپ بنائیں، آپ چلائیں” ہماری خدمت کہاں واقعی کرتا ہے، اور کہاں یہ اس ٹیم کے لیے خاموشی سے ظالمانہ ہے جسے ہم نے اپنی سروس چلانے کے وسائل نہیں دیے؟ مکمل ملکیت وہ رائے کا چکر بناتی ہے جو بنانے والوں کو شور والے الرٹس ٹھیک کرنے اور قابل چلانے کے لیے ڈیزائن کرنے پر لاتا ہے، لیکن انسان دوست باری کا عملہ دینے کو بہت چھوٹی ٹیم پر مسلط ہو تو یہ جوابدہی کے بھیس میں سست تھکن کا انجن بن جاتی ہے۔ نقشہ لائیں کہ کون سی ٹیم کون سے پیجر کی مالک ہے، ہر باری واقعی کتنی بڑی ہے جب آپ ان لوگوں کو نکالیں جو کبھی مشکل صفحہ نہیں لیتے، اور ہر ٹیم کے پاس آپریشنز اچھی طرح چلانے کو کون سا پلیٹ فارم، ٹولنگ، اور تربیت ہے۔ متصادم کشش عالمگیر ملکیت کے صاف اصول اور اس گندی حقیقت کے درمیان ہے کہ کچھ تہوں کو سب سے مشکل قابل اعتمادی کے کام کی مشترک ملکیت یا after-hours کوریج دینے کو مرکزی SRE یا پلیٹ فارم ٹیم چاہیے۔ جو نتیجہ آپ چاہتے ہیں وہ ہر سروس کی ایماندار درجہ بندی ہے، مکمل مملوکہ، مشترک مملوکہ، یا مرکزی طور پر ڈھکی، اور ہر اس ٹیم کے لیے وسائل کے خلا کا نام جس سے آپ وہ چلانے کو کہہ رہے ہیں جو وہ برقرار نہیں رکھ سکتی۔ بڑے یا عوامی ادارے کے لیے پلیٹ فارم سپورٹ اور عملے کے لیے خریداری اور بھرتی کے lead times جوڑیں جو انسان دوست ملکیت فرض کرتی ہے، کیونکہ جس ٹیم کو آپ متعلقہ کھڑکی میں عملہ نہیں دے سکتے اسے آپ ناکامی کے لیے تیار کر رہے ہیں۔

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

اسٹارٹ اپ۔ مٹھی بھر انجینئروں کے ساتھ ہر کوئی on-call ہے اور ہیرو کی باری کے چھپنے کی جگہ نہیں۔ اپنا نایاب وقت ان دو تبدیلیوں پر لگائیں جو سب سے تیز ادا کرتی ہیں: وجہ پر مبنی الرٹس حذف کریں اور اپنے بنیادی بہاؤ کو ٹریک کرنے والے چند SLOs پر ہی پیجر دیں، اور باقی ہر الرٹ سے ایک صفحے کا runbook جوڑیں۔ مفصل ٹولنگ اور follow-the-sun چھوڑ دیں؛ مشترک اسپریڈ شیٹ، primary سے secondary تک خودکار escalation، اور سخت قاعدہ کہ بری رات اگلی صبح کی چھٹی خریدتی ہے آپ کو کسی بھی پلیٹ فارم کی خریداری سے زیادہ دور لے جائیں گے۔

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

بڑا ادارہ۔ مسئلہ بہت سی ٹیموں میں مستقل مزاجی ہے: مشترک پروڈکشن کی تیاری کا ریویو، عام پیجنگ کی پالیسی، اور ورژن کنٹرول میں runbook کا ذخیرہ تاکہ ٹیموں کے بیچ منتقل ہوتا انجینئر on-call کا نظام فوراً سمجھے۔ on-call کی صحت کو off-hours صفحے کی حدوں کے ساتھ منظم میٹرک بنائیں جو ریویو ٹرگر کریں، escalation اور ہینڈ آف معیاری کریں تاکہ کوئی صفحہ خاموشی سے نہ گرے، اور مرکزی پلیٹ فارم ٹیم کو سب سے مشکل تہوں کی مشترک مالک بننے دیں۔ باریوں کے پورٹ فولیو کو ویسے ہی منظم کریں جیسے سروسز کے پورٹ فولیو کو، toil، صفحے کے بوجھ، اور تھکن کے خطرے کے ڈیٹا کو باقاعدہ آپریشنل ریویو میں کھلاتے ہوئے۔

حکومت۔ خریداری کے قواعد، شفافیت، اور فرض کی دیکھ بھال انتظام کو شکل دیتے ہیں۔ on-call عملے کی صحت کو رسمی، قابل آڈٹ تقاضا سمجھیں، اور جہاں رات کا عملہ محدود ہو وہاں follow-the-sun آپریشنز کے شراکت دار سے معاہدہ کریں تاکہ کسی سرکاری ملازم کو معمول سے صبح تین بجے پیجر نہ ملے۔ ہر مکمل تیاری کا ریویو آڈٹ آرٹیفیکٹ کے طور پر رکھیں، runbooks اس جواب دہندہ کے چلانے کے لیے لکھیں جس نے نظام نہیں بنایا، کیونکہ پانچ سال بعد اسے چلانے والے اس کے مصنفین نہیں ہوں گے، اور شہریوں کے اسے حقیقت میں ملنے سے پہلے game days سے موسمی چوٹی کی مشق کریں۔

مثالیں

اسٹارٹ اپ۔ بارہ افراد کا اسٹارٹ اپ اپنی پہلی ادائیگی والی پروڈکٹ لانچ کرتا ہے اور تمام چھ انجینئروں کو primary اور secondary کے ساتھ ہفتہ وار باری پر رکھتا ہے۔ پہلے مہینے میں پیجر ہر رات بجتا ہے، زیادہ تر CPU اور ڈسک کے الرٹس پر جو خود حل ہو جاتے ہیں، اور دو انجینئر خاموشی سے نوکری ڈھونڈنے لگتے ہیں۔ ٹیم رک کر دوبارہ بناتی ہے: وہ ہر وجہ پر مبنی الرٹ حذف کرتے ہیں، checkout اور search کے لیے دو SLOs متعین کرتے ہیں، اور صرف error-budget کی burn پر پیجر دیتے ہیں۔ پیجز تقریباً چالیس ہفتہ وار سے تین تک گرتے ہیں۔ وہ ایک صفحے کی تیاری کی چیک لسٹ جوڑتے ہیں جسے ہر نئی سروس کو پاس کرنا ہے اور ہر runbook کو سیدھا اس کے الرٹ سے جوڑتے ہیں۔ on-call لوگوں کے چھوڑنے کی وجہ سے کام کا قابل انتظام حصہ بن جاتا ہے، اور انہوں نے یہ مہنگے ٹول کی بجائے اسپریڈ شیٹ اور نظم و ضبط سے کیا۔

بڑا ادارہ۔ عالمی ادائیگی کی کمپنی “آپ بنائیں، آپ چلائیں” ماڈل کے تحت سینکڑوں سروسز چلاتی ہے، مرکزی پلیٹ فارم ٹیم کی پشت پناہی کے ساتھ جو پیجنگ کا نظام، تیاری کے ریویو کا عمل، اور ورژن کنٹرول میں مشترک runbook کا ذخیرہ فراہم کرتی ہے۔ ہر سروس آغاز سے پہلے دستاویزی پروڈکشن کی تیاری کا ریویو پاس کرتی ہے، جو SLOs، الرٹنگ، runbooks، صلاحیت، اور rollback ڈھانپتا ہے۔ on-call کی صحت ٹریک شدہ میٹرک ہے: وہ ٹیمیں جن کے off-hours پیجز حد سے بڑھیں خودکار ریویو ٹرگر کرتی ہیں، اور پلیٹ فارم ٹیم بوجھ گرنے تک قابل اعتمادی کے کام کی مشترک ملکیت کی پیشکش کرتی ہے۔ Game days حقیقت پسند failure injection کے مقابل سہ ماہی چلتے ہیں۔ چونکہ معیار یکساں ہے اور ٹولنگ مشترک، انجینئر ٹیموں کے بیچ منتقل ہو کر on-call کا نظام فوراً سمجھتا ہے، اور قیادت فی ٹیم دیکھ سکتی ہے کہ انسانی بوجھ پائیدار ہے یا نہیں۔

حکومت۔ قومی ٹیکس ایجنسی سخت موسمی چوٹیوں اور شہریوں کے لیے دستیاب رہنے کی قانونی ذمہ داری کے ساتھ فائلنگ کا نظام چلاتی ہے۔ چونکہ افرادی قوت ایک ٹائم زون میں مرتکز ہے اور رات کا عملہ محدود، ایجنسی آپریشنز کے شراکت دار کے ساتھ follow-the-sun انتظام معاہدہ کرتی ہے تاکہ کسی سرکاری ملازم کو معمول سے آدھی رات کو پیجر نہ ملے، اور on-call عملے کی صحت اور فرض کی دیکھ بھال کو رسمی تقاضا سمجھتی ہے۔ ہر سروس کی تبدیلی ڈیپلائمنٹ سے پہلے آپریشنل تیاری کا ریویو پاس کرتی ہے، چیک لسٹ آڈٹ کے لیے رکھی جاتی ہے۔ Runbooks اس جواب دہندہ کے چلانے کو لکھے جاتے ہیں جس نے نظام نہیں بنایا، کیونکہ پانچ سال بعد اسے چلانے والے وہ نہیں ہوں گے جنہوں نے لکھا۔ فائلنگ کے موسم میں ایجنسی چوٹی کے لوڈ کے منظرنامے کے خلاف game days چلاتی ہے، تاکہ جواب دہندگان ابھار سے حقیقت میں ملنے سے پہلے مشق میں ملیں۔

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

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

اپنانے کی لاگت زیادہ تر ایک بار کی اور معمولی ہے۔ آپ تیاری کی چیک لسٹ لکھتے ہیں، الرٹس وجوہات سے علامات پر منتقل کرتے ہیں، runbooks ورژن کنٹرول میں رکھتے ہیں، اور on-call کی صحت کی میٹرکس لگاتے ہیں۔ بار بار کی لاگت الرٹس کا ریویو کرنے، game days چلانے، اور انسان دوست شیڈولنگ کی پابندی کا نظم و ضبط ہے۔ نظر اندازی کی لاگت خاموشی سے مرکب ہوتی ہے: شور والے الرٹس تھکن پیدا کرتے ہیں، تھکن چھوٹے حقیقی واقعات اور رخصتیں پیدا کرتی ہے، اور ہر رخصت آپریشنل علم ساتھ لے جاتی ہے، جو باقی رہنے والوں پر بوجھ بڑھاتی ہے۔ قیادت کے سامنے دلیل رکھنے کو on-call کی صحت کو ان میٹرکس سے جوڑیں جو وہ پہلے سے دیکھتے ہیں: واقعات کی تعدد اور دورانیہ، acknowledge کا وقت، غیر منصوبہ بند چھوڑ جانا، اور off-hours صفحے کا رجحان۔ وہ باری جس کے off-hours پیجز نظام کے بڑھنے کے ساتھ گر رہے ہوں اس کا براہ راست ثبوت ہے کہ آپ کی قابل اعتمادی کی سرمایہ کاری کام کر رہی ہے اور آپ کے انجینئر اگلے سال بھی یہاں ہوں گے۔

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

• ہیرو باری: دو یا تین لوگ خاموشی سے ہر مشکل صفحہ جذب کرتے ہیں، اس لیے شیڈول کاغذ پر ٹھیک لگتا ہے اور ان میں سے کسی کے جاتے ہی ڈھ جاتا ہے۔
• وجوہات پر پیجنگ: صارف کو نظر آنے والی علامات کی بجائے CPU، میموری، اور ڈسک پر الرٹنگ، جواب دہندگان کو ان پیجز سے بھرنا جنہیں کبھی انسان کی ضرورت نہ تھی۔
• برداشت شدہ alert fatigue: مہینوں پیجنگ کے راستے میں چھوڑے معلوم شور والے الرٹس کیونکہ انہیں حذف کرنا خطرناک لگتا ہے، یہاں تک کہ جواب دہندگان سب کچھ نظر انداز کرنے لگیں۔
• Runbook کی سڑاند: لانچ پر ایک بار لکھی دستاویزات، کبھی اپ ڈیٹ نہیں، اور صبح تین بجے تھکے جواب دہندہ کی پیروی کرنے پر اعتماد سے غلط۔
• سہارے کے بغیر ملکیت: “آپ بنائیں، آپ چلائیں” ایسی ٹیم پر مسلط کرنا جو باری کا عملہ دینے کو بہت چھوٹی ہو یا اسے انسان دوست طریقے سے چلانے کا پلیٹ فارم اور ٹولنگ نہ رکھتی ہو۔
• تیاری کا تھیٹر: ریویو کی چیک لسٹ جو سروس کے ناکام ہونے کا حقیقی سامنا کرنے کی بجائے دروازہ پار کرنے کو بھری گئی۔
• لانچ اور ترک: سروس بغیر باری، بغیر الرٹس، اور بغیر runbooks کے بھیجنا، پھر خلا کو پہلی بندش میں دریافت کرنا۔
• بغیر ناپا بوجھ: فی شفٹ پیجز یا off-hours پیجز کا ڈیٹا نہیں، اس لیے لوگوں کے چھوڑنے تک تھکن نظر نہیں آتی۔
• پہلا صفحہ، کوئی مشق نہیں: نئے انجینئر کو shadowing اور game day کے بغیر on-call رکھنا، پھر اس کے جم جانے پر حیران ہونا۔

پختگی کا ماڈل

• سطح 1، آغاز: on-call غیر رسمی اور ردعملی ہے۔ چند لوگوں کو کچھ ٹوٹنے پر فون کیا جاتا ہے، الرٹس وجوہات پر بجتے اور زیادہ تر شور ہیں، runbooks غائب یا باسی ہیں، سروسز بغیر تیاری کی جانچ کے لانچ ہوتی ہیں، اور کوئی انسانی بوجھ نہیں ناپتا جب تک کوئی تھک یا چھوڑ نہ جائے۔
• سطح 2، ترقی: بنیادی عمل ظاہر ہوتے ہیں مگر ٹیم بہ ٹیم مختلف ہیں۔ کچھ باریوں کے متعین primary، secondary، اور escalation ہیں، کچھ الرٹس ٹیون اور کچھ runbooks لکھے ہیں، اور تیاری کی چیک لسٹ موجود ہے مگر غیر مستقل لاگو ہے۔ جو ٹیمیں پروا کرتی ہیں ان میں پیجز گنے جا سکتے ہیں، رات کے پیجز عام ہیں، اور on-call کی آن بورڈنگ ڈیزائن ہونے کی بجائے فی البدیہہ ہے۔
• سطح 3، معیار بندی: تیاری کے ریویو آغاز سے پہلے دستاویزی قدم ہیں، ٹیموں میں نافذ۔ پیجنگ عام پالیسی کے مطابق علامت اور SLO پر مبنی ہے، runbooks ورژن کنٹرول میں رہتے اور الرٹس سے جڑتے ہیں، آن بورڈنگ میں shadowing اور game days شامل ہیں، ہینڈ آف ساختہ شکل پر چلتے ہیں، اور escalation اتنی یکساں ہے کہ ٹیموں کے بیچ منتقل ہوتا انجینئر نظام کو فوراً پہچانتا ہے۔
• سطح 4، انتظام: on-call بنیادی خطوط کے مقابل ناپا اور کنٹرول کیا جاتا ہے۔ فی شفٹ پیجز، off-hours کا حصہ، acknowledge کا وقت، escalation کی تعدد، اور acknowledge-to-action کا تناسب فی ٹیم ٹریک اور اہداف سے موازنہ ہوتے ہیں، اس لیے تھکن کی طرف بڑھتی باری لوگوں کے چھوڑنے کے بعد کی بجائے پہلے نظر آتی ہے۔ حدیں ریویو ٹرگر کرتی ہیں، الرٹ کے معیار کا آڈٹ اس شہادت پر ہوتا ہے کہ کون سے پیجز حقیقی عمل تک پہنچے، اور عملے اور ملکیت کے فیصلے واقعاتی کہانیوں کی بجائے ڈیٹا سے چلتے ہیں۔
• سطح 5، ہم آہنگی: on-call کی صحت مسلسل بہتر ہوتا، ادارے بھر مربوط نتیجہ ہے۔ نظام کے بڑھنے کے ساتھ صفحے اور off-hours کے رجحان گرتے ہیں، toil منظم طور پر خودکار کر کے ہٹایا جاتا ہے، follow-the-sun یا مساوی نیند کی حفاظت کرتا ہے، game days اور failure injection معمول ہیں، اور ادارہ ہر شفٹ سے سیکھنے پر ملکیت، کوریج، اور تیاری کے معیار کو ڈھالتا ہے، خطرے کی تصویر بدلنے پر ٹیموں اور علاقوں میں بوجھ دوبارہ متوازن کرتے ہوئے۔

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

1. جن پیجز پر حقیقی عمل ہوا اور جو خود حل ہو گئے ان کا آپ کا موجودہ تناسب کیا ہے، اور اسے ناپنے کو کیا لگے گا؟
2. اگر آپ کا سب سے زیادہ علم رکھنے والا جواب دہندہ کل چھوڑ جائے تو کون سی سروسز چلانے کے لیے غیر محفوظ ہو جائیں گی، اور کیوں؟
3. “آپ بنائیں، آپ چلائیں” آپ کی کہاں اچھی خدمت کرتا ہے، اور کم وسائل والی ٹیم کے لیے کہاں خاموشی سے ظالمانہ ہے؟
4. آپ نے آخری بار نئے انجینئر کو حقیقت پسند حالات میں اپنے کسی runbook کی پیروی کرتے کب دیکھا، اور کیا ٹوٹا؟
5. کیا پچھلی چار سہ ماہیوں میں آپ کے off-hours پیجز اوپر جا رہے ہیں یا نیچے، اور کیا اس عدد کا کوئی مالک ہے؟
6. تیاری کے ریویو کا کون سا آئٹم، اگر آپ اسے سختی سے نافذ کرتے، آپ کے حالیہ برے لانچ کو روک دیتا؟

اہم نکات

• on-call کی تیاری کسی بھی واقعے سے پہلے آپ کے الرٹس، runbooks، اور باری کے معیار سے طے ہوتی ہے، بندش کے دوران بہادری سے نہیں۔
• انسان کو صرف فوری، قابل عمل، اور صارف کو نظر آنے والے مسائل پر پیجر دیں؛ علامات اور SLOs پر الرٹ کریں، اور باقی سب ٹکٹس اور ڈیش بورڈز کو بھیجیں۔
• باریاں ان لوگوں کے لیے ڈیزائن کریں جن کی زندگی ہے: کافی بڑے تالاب، جہاں ممکن ہو follow-the-sun، خودکار escalation، اور عزت دیا گیا بحالی کا وقت۔
• آغاز سے پہلے پروڈکشن کی تیاری کے ریویو سے ثابت کریں کہ سروسز تیار ہیں، runbooks کو ورژن کنٹرول میں رکھیں اور الرٹس سے جوڑیں، اور game days سے مشق کریں۔
• on-call کی صحت، خاص طور پر off-hours پیجز اور acknowledge کا وقت، ناپیں، اور لوگوں سے مزید برداشت مانگنے کی بجائے toil اور شور کاٹ کر بوجھ نیچے لائیں۔

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

• Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
• Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
• Rob Ewaschuk, “My Philosophy on Alerting,” in Site Reliability Engineering appendix
• John Allspaw and Jesse Robbins (eds.), Web Operations: Keeping the Data on Time
• Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps
• Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook
• Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
• World Health Organisation, ICD-11, entry on burn-out as an occupational phenomenon