62% آن-کال انجینئرز 12 ماہ کے اندر بھرپور ہو جاتے ہیں (پیجرڈٹی 2026)۔ یہ ایک لوگوں کا مسئلہ نہیں ہے۔ یہ ایک انجینئرنگ ڈیزائن کا مسئلہ ہے۔ ہر بھرپور رٹیشن کے تین بنیادی وجوہات: 1. علامات پر ایلرٹنگ، وجوہات پر نہیں CPU اسپائکس، کیو ڈیپتھ، ریکسٹ ریٹ — ان میں سے کوئی بھی واقعہ نہیں ہے۔ ان سب نے 3 بجے صبح لوگوں کو جگا دیا۔ 2. پرانے رن بکس پیج فائر ہوتا ہے۔ رن بک ایک نام بدل دیا گیا سروس کی طرف اشارہ کرتا ہے۔ انجینئر ایڈرینالین اور بے خوابی کے ساتھ سسٹم کو ریورس انجینئرنگ کرتا ہے۔ 3. غیر مساوی لوڈ کے لیے مساوی شفٹس ہفتے کے آخر کا دن سپر بول ہے۔ ہفتے کے دن ایک سپرینٹ ہے۔ ایک جیسا رٹیشن دونوں کو ایک جیسا سمجھتا ہے۔ بہترین ٹیمز کے چار حل: 1. ایرر بجٹ آن-کال کام کو ہفتے کے 25% تک محدود رکھیں۔ اس سے زیادہ ہو تو فیچر ورک روک دیا جائے۔ گوگل SRE نے اس کا طریقہ کار تحریر کیا ہے۔ 2. SLOs سے منسلک ایلرٹس اگر کوئی بات صارف کے قابل مشاہدہ SLO کی خلاف ورزی سے متعلق نہیں، تو وہ شور ہے۔ آن-کال کا 23% وقت غلط مثبت نتائج (بلیملس 2026) پر خرچ ہوتا ہے۔ 3. رن بک-اور-ڈیلیٹ ہر پروڈکشن ایلرٹ کے ساتھ ایک موجودہ رن بک ضرور ہو، ورنہ ایلرٹ حذف کر دیا جائے۔ آپ اپنے آدھے ایلرٹس ختم کر دیں گے۔ اسی کا مقصد ہے۔ 4. لوڈ-ایوار رٹیشنز چوٹی کے وقتوں کے لیے زیادہ توجہ یا مختصر شفٹس درکار ہوتے ہیں۔ ایک سائز فٹس ال — جس نے چوٹی کا شفٹ لیا، اسے سزا دی جاتی ہے۔ اگر آپ انجینئرنگ لیدرشپ کرتے ہیں، تو آن-کال ڈیزائن آپ کا فرض ہے۔ نہ HR۔ نہ آپ کا EM۔ آپ۔ اس هفتے: ڈاش بورڈ کھولیں، پیجز کا شمار کریں، پوچھیں کہ ان میں سے کتنے پل랫 فارم نے حل کرنے چاہئیں، انسان نہیں۔ #EngineeringLeadership #OnCall #SRE