आपका primary region बिगड़ा हुआ है और बिज़नेस failover चाहता है। मुझे पूरी प्रक्रिया बताइए।

बिगाड़ का दायरा और यह पक्का करें कि failover सचमुच इंतजार करने से तेज है या नहीं, क्योंकि failover मुफ्त नहीं है और आंशिक outage कभी कभी पहले ही ठीक हो जाते हैं। किसी मालिक से साफ फैसला लें, फिर runbook चलाएं: तय डेटा नुकसान मानते हुए replica promote करें, DNS या routing परत पर traffic खिसकाएं, असली request से पुष्टि करें, और बताएं। failback की योजना बाद में सोच समझकर बनाएं, जब primary स्थिर हो जाए।

पहली बात यह है कि failover एक फैसला है, सहज प्रतिक्रिया नहीं। मुझे दायरा जानना है, कि यह एक service है या पूरा region, और provider क्या कह रहा है, क्योंकि अगर अनुमान पंद्रह मिनट का है तो तीस मिनट लेने वाला और डेटा गंवाने वाला failover बुरा विकल्प है। तो मैं वह आकलन incident commander या बिज़नेस मालिक तक पहुंचाता हूं और वे साफ तौर पर फैसला लेते हैं, क्योंकि रात तीन बजे किसी को अकेले डेटा नुकसान नहीं मानना चाहिए। फैसला हो जाने के बाद मैं सुधार करने के बजाय runbook चलाता हूं। दूसरे region में replica promote करता हूं, यह जानते हुए कि हम नाकामी के वक्त जो replication lag था उसे मान रहे हैं, और मैं वह नंबर बाद के reconciliation के लिए लिख लेता हूं। routing परत पर traffic खिसकाता हूं, और यहां मैं जांचता हूं कि health check और record की अवधि इतनी छोटी हों कि जल्दी हिल सकें, क्योंकि लंबे समय तक cache हुआ record इसे उम्मीद से कहीं ज्यादा लंबा खींच देता है। फिर dashboard के बजाय असली request से पुष्टि। और failback अपने आप में कामकाजी घंटों में की गई एक योजनाबद्ध चीज है, कभी भी जल्दबाजी में किया गया दूसरा failover नहीं।