Self-healing की सुरक्षित सीमाएँ तय करें
पूरा हुआस्पष्ट अधिकार, verification और stop conditions के साथ ज्ञात recovery कार्रवाइयाँ automate करें। Runtime recovery को software बदलने से अलग रखें।
प्रकाशक Taigaहम कैसे लिखते हैं
अपनी समझ जाँचेंController worker दो बार restart कर चुका है। Queue बढ़ रही है और database तक पहुँच नहीं है। Policy को क्या करना चाहिए?अभ्यास करें
आप क्या सीखेंगे
- Self-healing और स्थायी software correction का अंतर समझें।
- सीमित recovery policy और स्वतंत्र success checks तय करें।
- पहचानें कि automation कब रुककर escalate करे।
ज्ञात स्थिति को recover करें
Self-healing तय failure अपने आप पहचानकर अधिकृत recovery कार्रवाई का प्रयास करता है। Failed process restart करना या unhealthy instance बदलना उदाहरण हो सकते हैं। कार्रवाई failure और service के state model के अनुसार होनी चाहिए।
Kubernetes failed workload instances बदल सकता है और declared state के अनुसार system को ला सकता है। यह खराब application logic या हर storage failure नहीं सुधारता। Infrastructure recovery और software correctness को अलग checks चाहिए। Kubernetes self-healing।
Mechanism से पहले objective तय करें। Export restore होने का अर्थ है योग्य काम सही पूरा होता है। चलता container केवल एक पूर्वशर्त है।
तीन तरह के बदलाव अलग करें
| बदलाव | उदाहरण | जरूरी निर्णय |
|---|---|---|
| Runtime recovery | एक failed stateless worker बदलना | पहले से स्वीकृत recovery policy इसकी अनुमति दे सकती है |
| Software correction | Worker रोकने वाला memory leak ठीक करना | Review, tests, release controls और production verification |
| Policy change | स्वीकार्य restart rate या access scope बढ़ाना | Policy owner का स्पष्ट approval |
Recovery के बाद agent सुधार प्रस्तावित कर सकता है। वह नया software change है। उसे recovery controller से असीमित अधिकार नहीं मिलने चाहिए।
Check fail होने पर controller अपने success criteria भी नहीं बदल सकता। अन्यथा system सेवा सुधारे बिना सुधार की रिपोर्ट दे सकता है।
शुरू करने से पहले recovery policy लिखें
यह policy काल्पनिक है। इसके आँकड़े design choices समझाते हैं; ये सुझाए गए defaults नहीं हैं।
| Policy field | काल्पनिक export-worker नियम |
|---|---|
| Trigger | Worker heartbeat 90 seconds से नहीं है और queue में काम है |
| Preconditions | दूसरा worker healthy है; dependency checks pass हैं; compromise या integrity failure का संदेह नहीं |
| स्वीकार्य कार्रवाई | वर्तमान स्वीकृत artifact से एक worker बदलना |
| State protection | Jobs durable storage और सत्यापित idempotency key इस्तेमाल करते हैं |
| सीमा | 15 मिनट में अधिकतम दो replacements; एक समय में कभी एक से अधिक नहीं |
| Cooldown | Replacement के बाद अगले प्रयास से पहले पाँच मिनट रुकना |
| सफलता | Synthetic job सही पूरा होता है और प्रभावित queue घटने लगती है |
| रोकना और escalate करना | कोई precondition fail हो, सीमा आ जाए या सफलता सत्यापित न हो सके |
Least-privileged identity इस्तेमाल करें। Policy version, trigger के प्रमाण, कार्रवाई, resource और परिणाम log करें। Controller बंद करने का स्वतंत्र तरीका दें। Escalation पाने वाला मानव जिम्मेदार व्यक्ति तय करें।
सफल recovery के साथ failure paths भी जाँचें
Retry side effect दोहरा सकता है। Worker file store करके job acknowledge करने से पहले रुक सकता है। अगला execution देने से पहले idempotency जाँचें। Cloud native failure का उदाहरण देखें।
Retries overloaded dependency पर दबाव बढ़ा सकते हैं। सीमित प्रयास, timeouts और उचित backoff इस्तेमाल करें। सभी instances में एक साथ retries से बचें। AWS बताता है कि backoff और jitter यह बढ़ता दबाव कम करने में कैसे मदद करते हैं। Retry guidance।
काल्पनिक policy को तीन cases पर जाँचें। अकेला रुका worker recover होना चाहिए। Database outage पर बार-बार replacement रुकना चाहिए। अनिश्चित integrity failure पर automation रुककर response decision माँगे।
Missing telemetry भी जाँचें। Heartbeat न होने का अर्थ failed worker या failed collection path हो सकता है। Controller को अपनी कार्रवाई के लिए पर्याप्त प्रमाण चाहिए, AI की व्याख्या पर भरोसा नहीं।
मापें कि policy मदद करती है या नहीं
सत्यापित recoveries, असफल प्रयास, escalations, दोहराया काम और उपयोगकर्ताओं पर असर की अवधि दर्ज करें। समान परिस्थितियों में पुराने संचालन के तरीके से तुलना करें।
मूल दोष को engineering work के रूप में बनाए रखें। Leaking process बार-बार restart करने से तत्काल असर घट सकता है, जबकि leak जारी रहे। Observation को स्थायी सुधार से जोड़ने के लिए self-improvement पढ़ें।
अभ्यास करें
इस पाठ के काल्पनिक export worker के लिए recovery policy बनाएँ। Trigger, exclusions, स्वीकार्य कार्रवाई, retry limit, cooldown, success check और escalation owner तय करें। Database outage और अज्ञात data-integrity failure पर इसे जाँचें।
Worksheet डाउनलोड करें (Markdown)यह चयन हटाने से इस browser में सहेजी गई पूरी प्रगति मिट जाती है।
प्रगति इसी browser में रहती है। कोई account या tracking नहीं।
स्रोत और आगे पढ़ें
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗