अच्छा page किसे कहते हैं, और शोर मचाते on call रोटेशन की सफाई आप कैसे करेंगे?

अच्छा page जरूरी होता है, उस पर कुछ किया जा सकता है, और वह यूजर पर असर से जुड़ा होता है, साथ में runbook का लिंक लगा होता है। बाकी सब टिकट या डैशबोर्ड होना चाहिए। रोटेशन साफ करने के लिए एक महीने के page निकालें, हर अलर्ट पर उनकी गिनती करें, और जो भी नियमित तौर पर acknowledge होकर बिना किसी कार्रवाई के बंद हो जाता है उसे हटा दें या नीचे कर दें। कारण आधारित अलर्ट की जगह लक्षण आधारित SLO burn rate अलर्ट लाएं और हर शिफ्ट के लिए page का बजट तय करें।

मेरी कसौटी सीधी है: क्या इसमें अभी किसी इंसान की जरूरत है, क्या वह इंसान इसके बारे में कुछ कर सकता है, और क्या किसी यूजर को इसकी परवाह है। इनमें से कोई भी ना है, तो वह टिकट या ग्राफ है, page नहीं। सफाई के लिए मैं हमेशा डेटा से शुरू करता हूं, तो मैं अलर्ट नियम के हिसाब से बंटे एक महीने के page निर्यात करता हूं और एक कॉलम जोड़ता हूं कि जवाब देने वाले ने असल में किया क्या। पिछली बार जब मैंने यह किया, तो चार नियम 70% से ज्यादा page के लिए जिम्मेदार थे और उनमें से हर एक acknowledge करके बिना किसी कार्रवाई के बंद हुआ था। वे ट्यून नहीं हुए, हटा दिए गए। फिर मैंने disk 80% पर है और pod रीस्टार्ट हुआ जैसे कारण आधारित नियमों की दीवार की जगह SLO पर burn rate अलर्ट लगा दिए, ताकि हम तब page करें जब यूजर को इस दर से नुकसान हो रहा हो कि एरर बजट खत्म हो जाए, और कारणों को जांच के दौरान डैशबोर्ड पर दिखने दें। हमने प्रति शिफ्ट दो से कम page का लक्ष्य रखा और उसके टूटने को टिकट वाला दोष माना, जिससे बात ईमानदार बनी रही।