किसी बैकएंड service के लिए किस चीज़ पर alert लगाना है, यह आप कैसे तय करते हैं?

उन लक्षणों पर alert लगाएं जो यूज़र को महसूस होते हैं, और उन्हें service level objectives की तरह परिभाषित करें: edge पर नापी गई availability और latency, साथ ही सही होने के संकेत जैसे नाकाम payments या ऐसी queue जो खाली होना बंद कर दे। page तभी करें जब कोई objective चूकने का खतरा हो, error budget की burn rate के हिसाब से, ताकि धीमा खिसकाव एक ticket बने और तेज़ burn किसी को जगाए। CPU ज़्यादा होने जैसे कारण आधारित alerts को dashboard पर रखें, page पर नहीं।

मैं वहीं से शुरू करता हूं जो यूज़र को महसूस होगा: requests का नाकाम होना, requests का धीमा होना, और वे domain की चीज़ें जो इन दोनों से बुरी हैं, जैसे orders का confirm न होना या consumer lag का लगातार चढ़ते जाना। ये objectives बन जाते हैं जिनका एक लक्ष्य होता है, मान लीजिए 99.9 प्रतिशत requests सफल और 95वें percentile की latency तीन सौ मिलीसेकंड से कम, और नापा जाता है load balancer पर न कि app के भीतर, ताकि वे नाकामियां भी गिनी जाएं जो मेरे कोड को कभी दिखतीं ही नहीं। फिर alert की गंभीरता burn rate से आती है: महीने भर का error budget एक घंटे में जलाना तुरंत page करता है, जबकि कई दिनों में धीमा burn एक ticket है। CPU, memory या disk जैसे कारण वाले metrics dashboard और capacity alerts तक ही रहते हैं, क्योंकि व्यस्त CPU जो किसी को महसूस न हो, वह घटना नहीं है। हर page पर कुछ करने लायक होना चाहिए, इसलिए वह किसी runbook से जुड़ा होता है, और जो alert बिना किसी कार्रवाई के बजा उसकी समीक्षा होती है। एक टीम में इसी तरह हमने pager का शोर लगभग दो तिहाई घटा दिया था, और असली जीत यह थी कि बचे हुए alerts को गंभीरता से लिया जाने लगा।