# दृश्यता घटाने वाले AI एजेंट अलर्ट बदलाव

जो एजेंट मॉनिटर को ट्यून कर सकता है, वह किसी घटना को छिपा भी सकता है। शोर पैदा करने वाले थ्रेशोल्ड को ठीक करने वाला वही क्रेडेंशियल मूल्यांकन रोक सकता है, बहुत व्यापक साइलेंस लगा सकता है, नोटिफिकेशन रूट हटा सकता है या नियम डिलीट कर सकता है। इन सभी कॉल को सामान्य कॉन्फिगरेशन राइट मानने से एजेंट को आपके सबूतों पर अधिकांश टीमों की मंशा से कहीं ज्यादा नियंत्रण मिल जाता है।

सुरक्षित सीमा कार्रवाई के परिचालन प्रभाव पर आधारित होनी चाहिए। दृश्यता बढ़ाने वाला बदलाव आम तौर पर सामान्य नियंत्रणों से गुजर सकता है। ऐसा बदलाव जो किसी इंसान के वास्तविक खराबी देखने की संभावना घटाता है, उसे कड़ी समीक्षा, सीमित दायरा और वापसी का सत्यापन योग्य तरीका चाहिए। थ्रेशोल्ड संपादन, म्यूट और डिलीट को अलग रखना जरूरी है, क्योंकि इनके विफल होने और वापस लाने के तरीके अलग हैं।

यह तब भी लागू होता है जब एजेंट तकनीकी रूप से सही API अनुरोध लिखता है। मॉनिटरिंग उत्पाद अलग संसाधन देते हैं, लेकिन उनकी अनुमतियां अक्सर व्यापक रहती हैं। एक एजेंट एक ही API क्रेडेंशियल से कई उत्पादों तक भी पहुंच सकता है। उस क्रेडेंशियल के आसपास का गेटवे या वर्कफ़्लो समझे कि अनुरोधित कार्रवाई क्या करती है, समीक्षक को जोखिम वाला हिस्सा दिखाए और निष्पादन के बाद परिणाम जांचे। “मॉनिटरिंग अपडेट की अनुमति दें?” जैसा सामान्य संकेत इनमें से कुछ नहीं करता।

## सिग्नल से इंसान तक पूरी राह का मॉडल बनाएं

अलर्ट एक पाइपलाइन है और उसके किसी भी चरण में बदलाव दृश्यता घटा सकता है। मापे गए सिग्नल से शुरू करें, फिर मूल्यांकन, स्टेट निर्माण, रूटिंग, नोटिफिकेशन डिलीवरी और रिकॉर्ड रखने तक जाएं। अगर एजेंट इनमें से किसी चरण को बदल सकता है, तो नियम मौजूद रहने पर भी वह बदल सकता है कि ऑपरेटर को घटना का पता चलेगा या नहीं।

Prometheus के दस्तावेज इस विभाजन को साफ बताते हैं। Prometheus अलर्टिंग नियम एक्सप्रेशन का मूल्यांकन करके सक्रिय अलर्ट आगे भेजते हैं, जबकि Alertmanager ग्रुपिंग, इनहिबिशन, साइलेंस और डिलीवरी संभालता है। यह उपयोगी डिजाइन अंतर है, पर यही दिखाता है कि “अलर्ट संपादित कर सकता है” कितनी खतरनाक और अस्पष्ट अनुमति है। PromQL थ्रेशोल्ड बदलना और Alertmanager साइलेंस बनाना अलग चरणों को छूते हैं और अलग सबूत छोड़ते हैं।

एजेंट कार्रवाइयों की सूची बनाते समय प्रभाव की पांच श्रेणियां रखें:

- मूल्यांकन बदलाव तय करते हैं कि कोई स्थिति पेंडिंग या फायरिंग होगी या नहीं। थ्रेशोल्ड, क्वेरी एक्सप्रेशन, मूल्यांकन विंडो, डेटा न मिलने का व्यवहार और पॉज़ फ्लैग इसमें आते हैं।
- सप्रेशन बदलाव मूल्यांकन जारी रखते हैं, लेकिन नोटिफिकेशन रोकते या उनका दायरा घटाते हैं। साइलेंस, स्नूज़, मेंटेनेंस विंडो और इनहिबिशन नियम आम तौर पर यहां आते हैं, हालांकि अलग उत्पादों के अर्थ अलग हो सकते हैं।
- रूटिंग बदलाव तय करते हैं कि सक्रिय अलर्ट किसे मिलेगा। कॉन्टैक्ट पॉइंट, एस्केलेशन पाथ, लेबल मैचर और नोटिफिकेशन पॉलिसी इस श्रेणी में हैं।
- विनाशकारी बदलाव नियम, रूट या सप्रेशन रिकॉर्ड हटाते हैं। वे सबसे आसान रोलबैक लक्ष्य भी हटा देते हैं।
- साक्ष्य संबंधी बदलाव इतिहास, ऑडिट एक्सपोर्ट या रिटेंशन बदलते हैं। बाद की जांच पर असर पड़ने के कारण इन्हें डिलीट जितनी ही समीक्षा मिलनी चाहिए।

सिर्फ HTTP क्रिया देखकर वर्गीकरण न करें। `isPaused` को `false` से `true` करने वाला `PUT`, समाप्त हो चुके साइलेंस को हटाने वाले `DELETE` से ज्यादा खतरनाक हो सकता है। सभी प्रोडक्शन सेवाओं पर लागू मैचर बनाने वाला `POST`, एक टेस्ट नियम हटाने से ज्यादा पेज दबा सकता है। प्रभाव पहले की स्थिति, प्रस्तावित स्थिति और पाइपलाइन में संसाधन की जगह से तय होता है।

आपकी सूची में API ऑपरेशन, संसाधन प्रकार, वातावरण, मालिक सेवा, मौजूदा कॉन्फिगरेशन, प्रस्तावित कॉन्फिगरेशन और अपेक्षित प्रभाव दर्ज होने चाहिए। अगर गेटवे मौजूदा स्थिति नहीं ला सकता, तो वह अर्थपूर्ण अंतर नहीं बना सकता। ऐसी स्थिति में दृश्यता घटाने वाले राइट को रोकें या अनुरोध उस इंसान को भेजें जो मॉनिटरिंग सिस्टम सीधे देख सके।

## थ्रेशोल्ड संपादन में अर्थपूर्ण अंतर चाहिए

थ्रेशोल्ड संपादन में यह दिखना चाहिए कि पहचान का व्यवहार कैसे बदलता है, सिर्फ बदले हुए JSON फ़ील्ड नहीं। CPU सैचुरेशन को 85 प्रतिशत से 95 प्रतिशत करना साफ दिखता है। क्वेरी विंडो को पांच मिनट से तीस मिनट करना, डेटा न मिलने को स्वस्थ मानना, सीमित लेबल फ़िल्टर जोड़ना या पेंडिंग अवधि बढ़ाना भी वही व्यावहारिक नतीजा दे सकता है, जबकि कच्चे अंतर में सामान्य दिखेगा।

समीक्षक को मानकीकृत पहले और बाद का दृश्य चाहिए। मेट्रिक नियम के लिए क्वेरी, कम्पेरेटर, थ्रेशोल्ड, मूल्यांकन विंडो, पेंडिंग अवधि, डेटा न मिलने का व्यवहार, दायरे के लेबल और नोटिफिकेशन गंतव्य शामिल करें। लॉग नियम के लिए खोज एक्सप्रेशन और ग्रुपिंग या कार्डिनैलिटी सीमा दिखाएं। कंपोज़िट नियम के लिए निर्भरता बदलाव दिखाएं। जोखिम तय करने से पहले विक्रेता के फ़ील्ड नामों को इन स्थिर अवधारणाओं में बदलें।

गेटवे इस तरह का समीक्षा ऑब्जेक्ट निकाल सकता है। प्रारूप उदाहरण है, लेकिन हर फ़ील्ड का काम है:

```json
{
  "action": "alert.threshold.update",
  "resource": "payments-api/high-error-rate",
  "environment": "production",
  "before": {"threshold": 2, "window": "5m", "pending": "2m"},
  "after": {"threshold": 8, "window": "15m", "pending": "10m"},
  "effect": {
    "visibility": "decrease",
    "reasons": ["threshold raised", "window widened", "pending duration increased"]
  },
  "precondition": {"revision": "184", "config_sha256": "9a8e..."},
  "requested_by": {"agent_session": "run-7f31", "task": "reduce duplicate pages"}
}
```

एजेंट के काम का शीर्षक संदर्भ है, प्रमाण नहीं। “डुप्लिकेट पेज कम करें” आठ प्रतिशत एरर थ्रेशोल्ड को सही नहीं ठहराता। देखी गई स्थिति से जुड़ा कारण मांगें, जैसे किसी डिप्लॉयमेंट ने ज्ञात बेसलाइन बदली हो, और एजेंट ने मॉनिटर की जो सटीक स्थिति देखी उसे जोड़ें। एजेंट को खुद यह दावा न करने दें कि बदलाव कम जोखिम वाला है।

दिशा मायने रखती है। लेटेंसी थ्रेशोल्ड घटाना, मूल्यांकन विंडो छोटी करना या डेटा न मिलने की स्थिति को स्वस्थ से अलर्ट बनाना संवेदनशीलता बढ़ाता है। इन बदलावों से शोर या लागत बढ़ सकती है, पर वे उसी तरह की खराबी नहीं छिपाते। थ्रेशोल्ड बढ़ाना, विंडो चौड़ी करना, पेंडिंग अवधि बढ़ाना, लेबल हटाना, बार-बार नोटिफिकेशन बंद करना या डेटा न मिलने को स्वस्थ मानना दृश्यता घटाता है। इन बदलावों को कड़ी समीक्षा में भेजें।

कुछ बदलाव मिले-जुले होते हैं। क्वेरी एक क्षेत्र जोड़कर दूसरा निकाल सकती है, या थ्रेशोल्ड घटाते हुए पेंडिंग अवधि बढ़ा सकती है। प्रभावों का औसत लेकर उन्हें “न्यूट्रल” न कहें। अगर कोई महत्वपूर्ण हिस्सा कवरेज खोता है, प्रस्ताव को दृश्यता में कमी मानें और प्रभावित हिस्सा दिखाएं। समीक्षक सीमित समझौता मंजूर कर सकते हैं, लेकिन उन्हें लंबे एक्सप्रेशन में इसे खुद नहीं खोजना चाहिए।

पूर्व शर्त अनिवार्य है। समीक्षा और निष्पादन के बीच कोई दूसरा ऑपरेटर या एजेंट उसी मॉनिटर को बदल सकता है। राइट से ठीक पहले अपरिवर्तनीय रिविज़न, एंटिटी टैग या मानकीकृत कॉन्फिगरेशन का हैश मिलाएं। अलग होने पर मंजूरी रद्द करें और अंतर दोबारा बनाएं। रिविज़न 184 की मंजूरी पांच मिनट बाद मौजूद किसी भी संस्करण की मंजूरी नहीं है।

## म्यूट सीमित और दिखाई देने वाला होना चाहिए

म्यूट तभी सुरक्षित है जब उसका दायरा, शुरुआत, समाप्ति, मालिक और कारण स्पष्ट हों। अस्थायी सप्रेशन नियोजित रखरखाव और ज्ञात शोर वाली स्थितियों के लिए है। एजेंट ऐसे रिकॉर्ड अच्छी तरह तैयार कर सकते हैं क्योंकि वे प्रभावित लेबल और रखरखाव समय निकाल सकते हैं। उन्हें अनिश्चितकालीन या वैश्विक साइलेंस का बिना समीक्षा वाला रास्ता नहीं मिलना चाहिए।

उत्पाद की शब्दावली अलग व्यवहार छिपा सकती है। Datadog के डाउनटाइम दस्तावेज कहते हैं कि डाउनटाइम अलर्ट और नोटिफिकेशन को साइलेंस करता है, लेकिन मॉनिटर स्टेट बदलते रहते हैं। Google Cloud Monitoring के स्नूज़ का प्रभाव ज्यादा है: सक्रिय स्नूज़ नोटिफिकेशन और घटना निर्माण रोकता है, और मेट्रिक या SQL आधारित पॉलिसी पर लागू होने पर संबंधित घटनाएं बंद कर देता है। एजेंट दोनों को “म्यूट” कहे तो समीक्षक से महत्वपूर्ण अंतर छिप जाता है।

Prometheus Alertmanager साइलेंस में मैचर और समय सीमा होती है। आधिकारिक दस्तावेज कहते हैं कि नोटिफिकेशन रुकने के लिए आने वाले अलर्ट को सक्रिय साइलेंस के सभी मैचर से मिलना चाहिए। इसलिए मैचर का फैलाव मुख्य जोखिम है। `service="checkout"` सीमित है। `service=~".*"` या environment मैचर का न होना पूरे सिस्टम को ढक सकता है। समीक्षा कार्ड को मौजूदा अलर्ट लेबल पर मैचर हल करके गिनती और उदाहरण नाम दिखाने चाहिए, सिर्फ रेगुलर एक्सप्रेशन नहीं।

एजेंट के बनाए हर सप्रेशन में ये गुण मांगें:

- संगठन की तय अधिकतम सीमा के भीतर निश्चित समाप्ति हो, जिसे एजेंट पार न कर सके।
- दायरा नामित सेवाओं, वातावरण, क्षेत्रों या अलर्ट पहचान से बंधा हो।
- इंसान के समझने योग्य कारण में रखरखाव या घटना का नाम हो, सिर्फ “शोर कम करना” नहीं।
- ऐसा मालिक हो जिसे समाप्ति से पहले और म्यूट खत्म होने पर सूचना मिले।
- पोस्टकंडीशन क्वेरी सप्रेशन रिकॉर्ड और उसकी समाप्ति का समय साबित करे।

बार-बार आने वाली विंडो को अलग संभालें। कार्यदिवस का रखरखाव कार्यक्रम सही हो सकता है, लेकिन मूल समीक्षा के बहुत बाद भी बार-बार अंधा समय बनाता है। पुनरावृत्ति नियम, टाइम ज़ोन, अंतिम तारीख और शामिल संसाधनों को एक स्थायी पॉलिसी बदलाव की तरह मंजूर करें। इसे अस्थायी म्यूट की श्रृंखला के रूप में न छिपाएं। अंतिम तारीख हटाने वाले बदलाव को अनिश्चितकालीन साइलेंस जितनी समीक्षा चाहिए।

घटना स्वीकार करना पॉलिसी म्यूट करना नहीं है। Google Cloud के घटना दस्तावेज कहते हैं कि घटना स्वीकार करने से दोहराए जाने वाले नोटिफिकेशन नहीं रुकते; स्नूज़ या अक्षम पॉलिसी उन्हें रोकती है। कार्रवाई नाम और अनुमतियों में यह अंतर बनाए रखें। एजेंट यह स्वीकार कर सकता है कि उसने घटना संभालना शुरू किया है, पर इससे उसे बाकी सभी के पेज रोकने का अधिकार नहीं मिलता।

म्यूट समाप्त होने पर उसका रिकॉर्ड न मिटाएं। अनुरोधित दायरा, हल किया गया दायरा, बनाने वाले की पहचान, मंजूरी, शुरुआत, अंत और अंतिम स्थिति रखें। घटना समीक्षा में समाप्त हो चुका साइलेंस अक्सर वही सबूत होता है जो बताता है कि सिग्नल ऑन-कॉल ऑपरेटर तक क्यों नहीं पहुंचा।

## डिलीट से पहले रिकवरी का प्रमाण चाहिए

मॉनिटर डिलीट करना नियंत्रण स्तर का ऐसा बदलाव है जिसकी कोई स्वचालित समाप्ति नहीं होती। इंसान साधारण थ्रेशोल्ड दोबारा बना सकता है, लेकिन टिप्पणियां, पहचान, रूटिंग संबंध, डैशबोर्ड संदर्भ और इतिहास वापस न आएं। इसलिए सीमित म्यूट के मुकाबले डिलीट की मंजूरी ज्यादा कड़ी होनी चाहिए, भले एजेंट नियम को पुराना बताए।

AWS `cloudwatch:DeleteAlarms` को अलग अनुमति के रूप में दर्ज करता है और एजेंट क्रेडेंशियल में भी यह अलगाव रहना चाहिए। CloudWatch `DeleteAlarms` API कई अलार्म नाम लेता है और किसी दिए नाम के गलत होने पर भी सही नाम वाले अलार्म डिलीट कर सकता है। AWS बाद में `DescribeAlarms` चलाकर पुष्टि की सलाह देता है। इन बातों के कारण सामान्य सफलता संदेश सुरक्षित नहीं है: गेटवे को अनुरोधित समूह दर्ज करके हर परिणाम अलग सत्यापित करना चाहिए।

Grafana का अलर्टिंग प्रोविज़निंग API भी अलर्ट नियमों के लिए अलग अपडेट और डिलीट एंडपॉइंट देता है, साथ ही पूरे नियम समूह हटा सकता है। एक नियम और पूरे समूह के डिलीट की मंजूरी का वाक्य कभी एक जैसा न हो। समूह में नियमों की संख्या, फ़ोल्डर, वातावरण और सक्रिय स्थिति दिखाएं। मंजूरी के बाद सूची बदल गई हो तो समूह डिलीट रोक दें।

एजेंट के प्रोडक्शन मॉनिटर डिलीट करने से पहले पुनर्स्थापित किया जा सकने वाला एक्सपोर्ट और निर्भरता जांच मांगें। एक्सपोर्ट में पूरा नियम, नोटिफिकेशन संदर्भ, लेबल और दोबारा बनाने के लिए जरूरी स्रोत जानकारी हो। उसे एजेंट के लिखने योग्य रास्ते से बाहर रखें और मंजूरी रिकॉर्ड में उसका डाइजेस्ट जोड़ें। स्क्रीनशॉट बैकअप नहीं है और एजेंट का सारांश जटिल क्वेरी दोबारा नहीं बना सकता।

निर्भरता जांच में उस मॉनिटर पहचान का संदर्भ देने वाले डैशबोर्ड, कंपोज़िट अलार्म, रनबुक, डिप्लॉयमेंट जांच, सर्विस कैटलॉग और नोटिफिकेशन रूट खोजें। हर उत्पाद सभी संबंध नहीं दिखाता, इसलिए बताएं कि कौन सी जांच हुई और कौन सी नहीं हो सकी। अज्ञात निर्भरताएं जोखिम बढ़ाती हैं, वे साफ स्थिति का प्रमाण नहीं हैं।

डिलीट को दो भागों में चलाएं:

1. एजेंट डिलीट का प्रस्ताव देता है, मौजूदा एक्सपोर्ट देता है, नियम पुराना होने का कारण बताता है और विकल्प हो तो उसे पहचानता है।
2. समीक्षक सटीक संसाधन रिविज़न मंजूर करता है, फिर गेटवे उसे डिलीट करके स्वतंत्र रूप से अनुपस्थिति जांचता है और एक्सपोर्ट संभालता है।

पुराने गैर-प्रोडक्शन नियमों को मालिक और रिपॉज़िटरी पाथ से समूह में देखा जा सकता है। प्रोडक्शन डिलीट अलग-अलग दिखाएं, जब तक वे एक ही समीक्षा किए कॉन्फिगरेशन हटाने से न आए हों और उनका रोलबैक समान न हो। सुविधा 80 असंबंधित मॉनिटर को एक मंजूरी में रखने का कारण नहीं है।

अगर जांच के दौरान शोर रोकना लक्ष्य है, तो डिलीट गलत कार्रवाई है। सीमित म्यूट लगाएं। संवेदनशीलता बदलनी हो तो थ्रेशोल्ड संपादित करें। कवरेज हटानी हो तो विकल्प या स्वीकार की गई कमी स्पष्ट होने के बाद ही डिलीट करें। इन रास्तों को एक “अलर्ट ठीक करें” टूल में न मिलाएं।

## जोखिम दृश्यता के नुकसान से तय होता है

व्यावहारिक पॉलिसी कार्रवाइयों को इस आधार पर क्रम देती है कि वे कितनी दृश्यता, कितने बड़े दायरे में और कितनी देर के लिए हटाती हैं। वातावरण लेबल मदद करते हैं, लेकिन सिर्फ प्रोडक्शन होना पर्याप्त नहीं। स्टेजिंग अलर्ट रिलीज़ गेट बचा सकता है, जबकि प्रोडक्शन चेतावनी का कोई पेजिंग गंतव्य न हो। प्रभाव और संदर्भ से जोखिम निकालें।

एकदिश नियम रखें: दायरा, अवधि या अपरिवर्तनीयता बढ़ाने वाला कोई भी कारक समीक्षा स्तर को घटा नहीं सकता। इससे व्यापक म्यूट को सिर्फ इसलिए हल्का व्यवहार नहीं मिलता कि एंडपॉइंट उसे शेड्यूल कहता है। लक्ष्य फिलहाल स्वस्थ हो तो भी डिलीट सामान्य नहीं दिखता।

शुरुआती मैट्रिक्स ऐसा हो सकता है:

- दृश्यता में वृद्धि, जैसे थ्रेशोल्ड घटाना या गंतव्य जोड़ना: सेशन प्राधिकरण और ऑडिट।
- न्यूट्रल मेटाडेटा, जैसे समान अर्थ वाला विवरण संपादन: सेशन प्राधिकरण और ऑडिट।
- सीमित अस्थायी कमी, जैसे एक गैर-प्रोडक्शन अलर्ट को 30 मिनट म्यूट करना: स्पष्ट एक-क्लिक समीक्षा।
- प्रोडक्शन में कमी, जैसे थ्रेशोल्ड बढ़ाना या प्रोडक्शन क्षेत्र निकालना: अर्थपूर्ण अंतर के साथ कड़ी समीक्षा।
- व्यापक या बार-बार होने वाली कमी, जैसे वैश्विक मैचर या साप्ताहिक म्यूट: कड़ी समीक्षा और नामित मालिक।

“कड़ी समीक्षा” का अर्थ सिर्फ एक और पुष्टि संवाद नहीं होना चाहिए। मंजूरी को कार्रवाई डाइजेस्ट, मौजूदा संसाधन रिविज़न, हल किए दायरे, अवधि और प्रमाणित एजेंट सेशन से बांधें। सबसे ऊंचे स्तर के लिए Touch ID जैसी मानवीय उपस्थिति जांच या संगठन से मंजूर दूसरे समीक्षक की मांग रखें। एजेंट को व्यापक अनुरोध कई छोटी कॉल में बांटकर सीमा से नीचे जाने न दें। छोटे समीक्षा समय में संबंधित प्रस्ताव जोड़कर उनका संयुक्त दायरा निकालें।

अर्थ बदलने वाला फ़ील्ड न मिलने पर डिफ़ॉल्ट रूप से रोकें। अगर गेटवे नहीं जानता कि किसी नियम में `noDataState: OK` उसे शांत बनाएगा या नहीं, तो फ़ील्ड नाम देखकर सुरक्षा अनुमान न लगाए। ऐसा उत्पाद अडैप्टर जोड़ें जो अर्थ समझता हो या सीधे मानवीय कार्रवाई मांगें। “अज्ञात” वर्गीकरण का नतीजा है, कम जोखिम की श्रेणी नहीं।

पॉलिसी में रूटिंग और क्रेडेंशियल भी शामिल हों। एजेंट हर थ्रेशोल्ड रखकर भी ऑन-कॉल गंतव्य हटा सकता है, रिसीवर बदल सकता है या लेबल बदलकर नियम को रूट से बाहर कर सकता है। मॉनिटरिंग कॉन्फिगरेशन संपादित करने वाला क्रेडेंशियल ऑडिट रिटेंशन या नोटिफिकेशन पहचान अपने आप संपादित न कर सके। प्रदाता पर अनुमतियां अलग करें और एक्शन गेटवे पर यह सीमा दोहराएं।

बचने के तरीकों से मैट्रिक्स जांचें। देखें कि एजेंट म्यूट के बजाय मूल्यांकन रोक सकता है, डिलीट के बजाय असंभव थ्रेशोल्ड लगा सकता है, रूट हटाने के बजाय नकारात्मक मैचर जोड़ सकता है या घटना से ज्यादा देर का साइलेंस बना सकता है। एक ही दृश्यता नुकसान के हर रास्ते को समान या ऊंची समीक्षा पर पहुंचना चाहिए।

## मंजूरी में परिणाम स्पष्ट होना चाहिए

समीक्षक कुछ सेकंड में समझ पाए कि कौन सी कवरेज खोएगी, फिर मंजूरी से बाहर गए बिना विस्तार देख सके। पहले प्रस्तावित परिणाम दिखाएं, फिर प्रमाण। कच्चे अनुरोध बॉडी विस्तार नियंत्रण के पीछे रखें, क्योंकि प्रदाता पेलोड जरूरी फ़ील्ड को डिफ़ॉल्ट और प्रस्तुति मेटाडेटा में छिपाते हैं।

उपयोगी थ्रेशोल्ड वृद्धि मंजूरी कहती है: “Payments high-error अलर्ट 10 मिनट तक 8 प्रतिशत से ऊपर रहने पर फायर होगा; अभी यह 2 मिनट तक 2 प्रतिशत से ऊपर रहने पर फायर होता है।” फिर प्रोडक्शन, प्रभावित क्षेत्र, मौजूदा फायरिंग स्टेट, कारण और रोलबैक दिखाती है। म्यूट बताता है कि कौन से अलर्ट नोटिफिकेशन रोकेंगे, मूल्यांकन और घटना निर्माण जारी रहेगा या नहीं, और सप्रेशन कब खत्म होगा। डिलीट बताता है कि नियम स्थायी रूप से हटेगा और सहेजा एक्सपोर्ट पहचानता है।

अस्पष्ट समूह इंसान तक पहुंचने से पहले रोककर मंजूरी थकान घटाएं। “अलर्ट साफ करें” वाला एजेंट अनुरोध समीक्षा योग्य नहीं है। एजेंट से तीन स्पष्ट उद्देश्यों में एक मांगें: पहचान को ट्यून करना, नोटिफिकेशन अस्थायी रूप से दबाना या कवरेज हटाना। हर उद्देश्य के लिए जरूरी प्रमाण तय हो। इंसान परिचालन समझौता तय करे, एजेंट की योजना का अनुमान न लगाए।

मंजूरी का पाठ विश्वसनीय गणना से आए। एजेंट कारण और काम का संदर्भ दे सकता है, लेकिन पहले की स्थिति, अंतर, दृश्यता की दिशा, दायरा, अवधि, सक्रिय घटनाएं और कार्रवाई डाइजेस्ट गेटवे निकाले। एजेंट के दिए पाठ को चिह्नित करें। वरना प्रभावित एजेंट वैश्विक साइलेंस को सामान्य विवरण संपादन बता सकता है।

मंजूरी को छोटे निष्पादन समय से बांधें। डिप्लॉयमेंट, घटना और नियम रिविज़न बदलने पर सही निर्णय पुराना हो सकता है। निष्पादन के समय संसाधन फिर लाएं, पूर्व शर्त मिलाएं, पुष्टि करें कि म्यूट फैला नहीं है और प्रमाणित प्रक्रिया वही समीक्षा किया सेशन है। कोई बंधन बदले तो रुकें और फिर पूछें।

इनकार उपयोगी हो, लेकिन बचने का तरीका न बताए। `REVIEW_REQUIRED_VISIBILITY_DECREASE` जैसा संरचित कारण, वर्गीकृत प्रभाव और एजेंट को देने वाले फ़ील्ड लौटाएं। अंदरूनी सीमा न बताएं जिससे एजेंट बैच सीमा के ठीक नीचे रहे। एजेंट प्रस्ताव बदल सकता है, पॉलिसी निर्णय नहीं।

आपात स्थिति के लिए अलग रास्ता चाहिए। सक्रिय घटना में ऑन-कॉल ऑपरेटर पेज तूफान रोकने के लिए तेज, सीमित म्यूट चाहता हो सकता है। पहले से छोटा अधिकतम दायरा और अवधि तय करें, ऑपरेटर को मजबूती से प्रमाणित करें, घटना पहचान दर्ज करें और टीम को तुरंत बताएं। आपात गति बातचीत छोटी करे, जिम्मेदारी या समाप्ति न मिटाए।

## प्रस्ताव और निष्पादन अलग रखें

एजेंट मॉनिटरिंग बदलाव तैयार कर सके, लेकिन उसके पास हमेशा उपलब्ध निष्पादन रास्ता न हो। वर्कफ़्लो को पढ़ना, प्रस्ताव, मंजूरी, निष्पादन और सत्यापन में बांटें। एजेंट रीड एक्सेस से शोर का निदान करके सटीक प्रस्ताव बना सकता है। गेटवे राइट क्रेडेंशियल रखता है और पॉलिसी पूरी होने पर ही इस्तेमाल करता है।

प्रस्ताव अपरिवर्तनीय दस्तावेज है, बातचीत का वादा नहीं। उसे पहचान और डाइजेस्ट दें। प्रदाता खाता, संसाधन पहचान, कार्रवाई श्रेणी, मानकीकृत पहले और बाद की स्थिति, संसाधन रिविज़न, हल किया दायरा, कारण, कार्य संदर्भ, रोलबैक और सत्यापन योजना शामिल करें। एजेंट कोई फ़ील्ड बदले तो नया डाइजेस्ट बनाएं और पुरानी मंजूरी रद्द करें।

छोटा पॉलिसी अंश सीमा को ऐसे दिखा सकता है:

```yaml
actions:
  alert.threshold.update:
    classify: semantic_diff
    require_review_when: visibility == "decrease"
    bind: [resource_revision, proposal_digest, agent_session]
  alert.mute.create:
    require: [scope, starts_at, ends_at, owner, reason]
    deny_when: ends_at == null
    aggregate_by: [agent_session, environment]
  alert.rule.delete:
    require_review: always
    require: [restorable_export, dependency_check, rollback_owner]
    bind: [resource_revision, proposal_digest, agent_session]
```

यह डिजाइन नमूना है, किसी खास पॉलिसी इंजन के बारे में दावा नहीं। यह तीन सामान्य विफलताएं रोकता है: पुराने थ्रेशोल्ड अंतर को मंजूरी देना, अनिश्चितकालीन म्यूट बनाना और रिकवरी सामग्री के बिना नियम डिलीट करना। शब्दावली इतनी छोटी रखें कि हर अडैप्टर प्रदाता ऑपरेशन को समान अर्थ से जोड़ सके।

निष्पादन में चुनी कार्रवाई के लिए सबसे कम सक्षम क्रेडेंशियल इस्तेमाल करें। थ्रेशोल्ड अपडेट को डिलीट अनुमति नहीं चाहिए। साइलेंस बनाने वाले को नोटिफिकेशन गंतव्य नियंत्रित करने की जरूरत नहीं। प्रदाता यह अलगाव न दे सके तो गेटवे सीमित स्वीकृत ऑपरेशन लागू करे और एजेंट का कोई भी HTTP आगे भेजने के बजाय अनुरोध खुद बनाए।

प्रदाता का सीक्रेट एजेंट को थोड़ी देर के लिए भी न दें। प्लेसहोल्डर बदलने पर भी टूल शक्तिशाली क्रेडेंशियल के आसपास मनचाहा अनुरोध बना सकता है। क्षमता आधारित निष्पादन ज्यादा सुरक्षित है: एजेंट सत्यापित पैरामीटर देता है और विश्वसनीय कोड क्रेडेंशियल लगाकर ज्ञात एंडपॉइंट कॉल करता है। प्रतिक्रिया डेटा भी सीमित करें, क्योंकि मॉनिटरिंग API संपर्क पते, अंदरूनी लेबल और परिचालन नोट दिखा सकते हैं।

इडेम्पोटेंसी और पुनः प्रयास मायने रखते हैं। टाइम आउट हुई create कॉल सफल हो सकती है और अंधा पुनः प्रयास अलग पहचान वाला डुप्लिकेट म्यूट बना सकता है। प्रदाता समर्थन करे तो अनुरोध पहचान दें, पुनः प्रयास से पहले इच्छित स्थिति खोजें और हर प्रयास दर्ज करें। डिलीट के लिए अस्पष्ट प्रतिक्रिया के बाद सटीक अनुरोधित समूह जांचकर ही पुनः प्रयास तय करें।

## सत्यापन में वापस आई दृश्यता जांचें

सफल HTTP प्रतिक्रिया सिर्फ यह साबित करती है कि प्रदाता ने अनुरोध स्वीकार किया, यह नहीं कि मॉनिटरिंग अभी भी काम कर रही है। सत्यापन में इच्छित स्थिति और बची रहने वाली दृश्यता शर्तें जांचें। संभव हो तो स्वतंत्र रीड रास्ते और ऐसा क्रेडेंशियल इस्तेमाल करें जो देखे गए परिणाम बदल न सके।

थ्रेशोल्ड संपादन के लिए नियम फिर लाकर मानकीकृत कॉन्फिगरेशन को मंजूर प्रस्ताव से मिलाएं। पुष्टि करें कि नियम सक्षम है, गंतव्य हल होते हैं और क्वेरी पार्स होती है। प्रदाता नियम मूल्यांकन या प्रीव्यू देता हो तो हाल के ज्ञात समय पर चलाएं। सेवा के पास स्थापित सिंथेटिक सिग्नल न हो तो सिर्फ संपादन जांचने के लिए प्रोडक्शन घटना न बनाएं।

म्यूट के लिए सटीक मैचर या पॉलिसी समूह, शुरुआत, अंत, मालिक और स्थिति सत्यापित करें। जहां हो सके, दो जांच तय करें: एक समाप्ति से कुछ पहले और दूसरी ठीक बाद। बाद की जांच साबित करे कि सप्रेशन निष्क्रिय है और मेल खाने वाला अलर्ट अपेक्षित स्थिति फिर बना सकता है। कोई दूसरा ओवरलैपिंग म्यूट उसी दायरे पर हो तो “समाप्त” लेबल पर्याप्त नहीं।

डिलीट के लिए हर वस्तु की अनुपस्थिति जांचें और एक्सपोर्ट किया कॉन्फिगरेशन रखें। `DeleteAlarms` के बाद `DescribeAlarms` चलाने की CloudWatch सलाह अच्छा न्यूनतम है, लेकिन अनुपस्थिति यह साबित नहीं करती कि विकल्प मौजूद है। प्रस्ताव में विकल्प हो तो उसे लाएं, सक्षम होना जांचें और उसकी कवरेज हटाए गए नियम से मिलाएं।

सत्यापन परिणाम मशीन के पढ़ने योग्य बनाएं:

```json
{
  "proposal_id": "chg-2025",
  "execution": "accepted",
  "checks": [
    {"name": "approved revision applied", "status": "pass"},
    {"name": "rule enabled", "status": "pass"},
    {"name": "notification route resolves", "status": "pass"},
    {"name": "production regions covered", "status": "fail", "missing": ["eu-west"]}
  ],
  "final_status": "failed_closed",
  "remediation": "rollback_requested"
}
```

विफल शर्त पर पहले से तय प्रतिक्रिया होनी चाहिए। सुरक्षित विकल्पों में बंधे एक्सपोर्ट पर स्वचालित रोलबैक, उस एजेंट सेशन के अगले राइट रोकना और मॉनिटरिंग मालिक को पेज करना शामिल है। ऑटोमेशन चालू होने से पहले हर कार्रवाई के लिए चुनें। विफलता पैदा करने वाले एजेंट को यह तय न करने दें कि वह महत्वपूर्ण है या नहीं।

सत्यापन प्रदाता API के अर्थ में बदलाव भी पकड़ता है। Grafana अलर्ट नियमों में `isPaused` फ़ील्ड दर्ज करता है; उत्पाद अपडेट या अडैप्टर की गलती राउंड ट्रिप में इसे छोड़ सकती है। मानकीकृत पोस्टकंडीशन अपडेट सफल होने पर भी अनचाहा पॉज़ पकड़ेगा। कैप्चर किए अनुरोध और प्रतिक्रिया नमूनों के साथ अडैप्टर टेस्ट रखें और अज्ञात फ़ील्ड से मूल्यांकन, सप्रेशन, रूटिंग या डिलीट प्रभावित हो तो रोकें।

## ऑडिट रिकॉर्ड एजेंट से बचा रहना चाहिए

ऑडिट रिकॉर्ड से घटना समीक्षक दोबारा बना सके कि एजेंट ने क्या देखा, क्या प्रस्ताव दिया, किसने मंजूर किया, क्या चला और सत्यापन ने क्या पाया। प्रदाता ऑडिट लॉग मदद करते हैं, पर उनमें पूरा अर्थपूर्ण अंतर या एजेंट सेशन पहचान कम ही होती है। एजेंट की राइट अनुमति से बाहर अलग कार्रवाई रिकॉर्ड रखें।

ऑपरेटिंग सिस्टम दे सके तो प्रक्रिया पहचान और कोड साइनिंग अथॉरिटी दर्ज करें, सिर्फ एजेंट का बताया नाम नहीं। पहचान को प्रस्ताव और निष्पादन वाले सेशन से बांधें। प्रदाता खाता, संसाधन रिविज़न, प्रस्ताव डाइजेस्ट, मंजूरी तरीका, समीक्षक, समय, आउटबाउंड ऑपरेशन, हटाई गई संवेदनशील जानकारी वाली प्रतिक्रिया, सत्यापन जांच और रोलबैक परिणाम रखें। हैश चेन या केवल लिखे जा सकने वाले स्टोरेज से बाद की छेड़छाड़ पहचानना आसान होता है।

Datadog के Audit Trail दस्तावेज मॉनिटर बनने, बदलने, डिलीट होने और रिज़ॉल्व होने के अलग प्रश्न देते हैं और कॉन्फिगरेशन अंतर दिखा सकते हैं। प्रदाता का यह प्रमाण उपयोगी है, लेकिन इसे गेटवे रिकॉर्ड से जोड़ें। प्रदाता दिखा सकता है कि किस सर्विस खाते ने मॉनिटर बदला, जबकि गेटवे बताता है कि किस एजेंट प्रक्रिया ने वह खाता इस्तेमाल किया और किस इंसान ने सटीक प्रभाव मंजूर किया।

जब MCP समर्थित एजेंट HTTP से मॉनिटरिंग API तक पहुंचता है, Sallyport इस सीमा में काम करता है: उसका वॉल्ट API क्रेडेंशियल एजेंट से दूर रखता है, प्रति कॉल keys हर उपयोग पर मंजूरी मांग सकती हैं, और Sessions तथा Activity जर्नल केवल लिखे जा सकने वाले एन्क्रिप्टेड हैश-चेन लॉग से बनते हैं। यह व्यवस्था आपके लिए मॉनिटरिंग के अर्थ वर्गीकृत नहीं करती; कॉल करने वाले टूल को थ्रेशोल्ड अपडेट, म्यूट और डिलीट अलग करके सही समीक्षा प्रमाण दिखाना होगा।

रोके गए प्रयास भी ऑडिट करें। डिलीट की जगह असंभव थ्रेशोल्ड लगाने, साइलेंस मैचर फैलाने या एक व्यापक म्यूट को छोटी कॉल में बांटने की कोशिश खराब योजना या प्रभावित प्रक्रिया का संकेत हो सकती है। इनकार रिकॉर्ड में वर्गीकरण परिणाम और प्रस्ताव डाइजेस्ट हो, सीक्रेट नहीं।

अंत में पुनर्स्थापन का अभ्यास करें। एक गैर-प्रोडक्शन नियम चुनें, उसे एक्सपोर्ट करें, सीमित सप्रेशन लगाएं, समाप्ति सत्यापित करें, समीक्षा के तहत डिलीट करें और कैप्चर की सामग्री से वापस लाएं। पुष्टि करें कि रिकॉर्ड हर चरण जोड़ता है। टीम नियंत्रित अभ्यास नहीं दोहरा सकती तो एजेंट के चुपचाप दृश्यता घटाने के बाद वास्तविक घटना भी नहीं दोहरा पाएगी।