# AWS CloudFormation स्टैक रिफैक्टरिंग विफल: CloudWatch अलार्म, रोलबैक त्रुटियाँ और रिकवरी

58 CloudWatch अलार्म और आठ मेट्रिक फ़िल्टर को एक अलग CloudFormation स्टैक में ले जाने से हमारे ऐप की रिलीज़ रुक गईं। सोर्स स्टैक `UPDATE_ROLLBACK_FAILED` पर पहुँच गया; खाली डेस्टिनेशन स्टैक `ROLLBACK_FAILED` पर। रोलबैक के पाँच अनुरोध स्वीकार हुए, लेकिन स्टैक फिर भी ठीक नहीं हुए। आखिरकार AWS की आंतरिक टीम ने उन्हें ठीक किया। फिर एक साथ कई संसाधन ले जाने का हमारा अगला प्रयास एक अलग त्रुटि के साथ विफल हो गया।

हम अपने ओपन-सोर्स फ़्लैशकार्ड ऐप की मॉनिटरिंग को अलग कर रहे थे। यह वही प्रोजेक्ट है जिसके [एजेंट API के बारे में मैंने यहाँ लिखा था](/hi/gyan/sql-jaisi-dsl-se-17-agent-tools-badale/)। सोर्स में 497 भौतिक संसाधन थे। हम मॉनिटरिंग के 66 संसाधन दूसरे स्टैक में ले जाना चाहते थे और डेटाबेस को वहीं रखना चाहते थे। जिस असर की हमने पुष्टि की, वह रिलीज़ का रुकना था; ऐप बंद होने या डेटा खोने की पुष्टि नहीं हुई थी।

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

## आपकी रिफैक्टरिंग अटकी है, तो यहाँ से शुरू करें

| क्या दिख रहा है | अगला कदम |
| --- | --- |
| रिफैक्टरिंग का प्रीव्यू पूरा हो गया है | `Status` के साथ `ExecutionStatus` और उसका कारण भी पढ़ें। ऑपरेशन चलाने से पहले हर प्रस्तावित संसाधन मैपिंग की तुलना अपनी शुरुआती स्थिति के रिकॉर्ड से करें। |
| `UPDATE_ROLLBACK_FAILED` या रिफैक्टरिंग का विफल रोलबैक | ऑपरेशन, दोनों स्टैक और समय सहित त्रुटियों का रिकॉर्ड रखें। दोबारा कोशिश तभी करें जब पता हो कि कौन-सी आवश्यक शर्त बदल चुकी है। |
| `AlarmName` के null होने या असमर्थित टैग स्कीमा की त्रुटि | सटीक संदेश को उसके ऑपरेशन से जोड़कर रखें। हमारी घटना में ये अलग-अलग चरणों में आए थे। |
| इन्वेंटरी और सिस्टम टैग मेल नहीं खाते | भौतिक ID और प्रोवाइडर की सेटिंग्स की तुलना दोनों स्टैक की इन्वेंटरी से करें। स्वामित्व स्पष्ट होने तक निर्भर डिप्लॉयमेंट रोकें। |
| AWS का कहना है कि रिकवरी पूरी हो गई | स्टैक का काम करना, संसाधनों का सुरक्षित रहना, ऐप की स्थिति और सामान्य डिप्लॉयमेंट, इन सबकी अलग-अलग जाँच करें। |

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

![एक कामगार साबुत मिट्टी के बर्तनों की ट्रे छोटी नाव में उतार रहा है, जबकि एक बड़ी मालवाहक नाव नहर के खुले लॉक से गुज़र रही है](/articles/aws-cloudformation-stack-refactoring-failed.webp)

## दोबारा कोशिश करने से पहले मौजूदा स्थिति दर्ज करें

ये कमांड AWS की स्थिति केवल पढ़ती हैं। कोटेशन में दिए हर प्लेसहोल्डर की जगह अपना मान रखें, JSON को निजी तौर पर सुरक्षित रखें और शामिल हर स्टैक के लिए स्टैक वाली कमांड दोहराएँ। टेम्पलेट और आउटपुट में संवेदनशील जानकारी हो सकती है।

शुरुआत कॉलर, स्टैक की स्थिति और रिफैक्टरिंग के सटीक ऑपरेशन से करें:

```bash
aws --profile '<profile>' --region '<region>' sts get-caller-identity \
  --output json --no-cli-pager

aws --profile '<profile>' --region '<region>' cloudformation describe-stacks \
  --stack-name '<stack-id>' --output json --no-cli-pager

aws --profile '<profile>' --region '<region>' cloudformation describe-stack-refactor \
  --stack-refactor-id '<refactor-id>' --output json --no-cli-pager
```

`get-caller-identity` आपके जाँच वाले सेशन की पहचान बताता है। यह उन सभी रोल की पहचान नहीं बताता जिन्हें CloudFormation ने विफलता के दौरान इस्तेमाल किया था। स्टैक में `RoleARN` मौजूद हो तो उसे रिकॉर्ड में रखें और ऑपरेशन चलाने वाली पहचान की अलग से जाँच करें।

फिर इवेंट, इन्वेंटरी, टेम्पलेट और प्रस्तावित कार्रवाइयाँ इकट्ठा करें:

```bash
aws --profile '<profile>' --region '<region>' cloudformation describe-stack-events \
  --stack-name '<stack-id>' --output json --no-cli-pager

aws --profile '<profile>' --region '<region>' cloudformation list-stack-resources \
  --stack-name '<stack-id>' --output json --no-cli-pager

aws --profile '<profile>' --region '<region>' cloudformation get-template \
  --stack-name '<stack-id>' --output json --no-cli-pager

aws --profile '<profile>' --region '<region>' cloudformation list-stack-refactor-actions \
  --stack-refactor-id '<refactor-id>' --output json --no-cli-pager

aws --profile '<profile>' --region '<region>' cloudformation list-stack-refactors \
  --output json --no-cli-pager
```

पेजिनेशन चालू रहता है। `--no-cli-pager` टर्मिनल का व्यूअर बंद करता है, पेजिनेशन नहीं। पूरे प्रमाण इकट्ठा करते समय `--no-paginate` न जोड़ें और `--max-items` की सीमा लगाने पर बाकी नतीजे लेना न भूलें। CLI के नतीजे जानबूझकर सीमित रखे हों, तो लौटाए गए टोकन को `--starting-token` में देकर आगे बढ़ें; सीधे API कॉल करने वालों को हर `NextToken` का इस्तेमाल करके बाकी नतीजे लेने होंगे। [CLI के पेजिनेशन विकल्प](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-refactors.html) और [ListStackRefactors API](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_ListStackRefactors.html) देखें।

हर प्रभावित अलार्म के लिए प्रोवाइडर की स्थिति और टैग की तुलना स्टैक की इन्वेंटरी से करें:

```bash
aws --profile '<profile>' --region '<region>' cloudwatch describe-alarms \
  --alarm-names '<alarm-name>' --output json --no-cli-pager

aws --profile '<profile>' --region '<region>' cloudwatch list-tags-for-resource \
  --resource-arn '<alarm-arn>' --output json --no-cli-pager
```

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

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

AWS Support के लिए ये विवरण निजी तौर पर इकट्ठा करें: अकाउंट और रीजन, स्टैक और ऑपरेशन ID, UTC टाइमलाइन, सटीक त्रुटियाँ और अनुरोध ID, कमिट और CI रन, रोल/पॉलिसी के प्रमाण, टेम्पलेट की तुलनाएँ, स्किप किए गए ID, रिकवरी के प्रयास और ऐप पर असर। अगर Support घटना की स्थिति जस की तस रखने को कहे, तो यह रोक हटने तक केवल स्थिति पढ़ते रहें।

## सफल प्रीव्यू का मतलब सफल स्थानांतरण नहीं था

AWS की अंतर्निहित [CloudFormation स्टैक रिफैक्टरिंग](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stack-refactoring.html) मौजूदा संसाधनों के गुण और डेटा सुरक्षित रखते हुए उन्हें नए सिरे से व्यवस्थित करती है। स्थानांतरण की कोशिश से पहले संसाधनों की पात्रता, स्टैक पॉलिसी, निर्भरताओं और स्टैक पर निर्भर स्यूडो-पैरामीटर से जुड़ी पाबंदियाँ जाँचें। कॉन्फ़िगरेशन में बदलाव अलग अपडेट में करें।

API रिफैक्टर ऑपरेशन बनाने और उसे चलाने में फ़र्क करता है। बाद में हुए हमारे एक विफल प्रयोग में ये दोनों फ़ील्ड मिले:

```json
{
  "Status": "CREATE_COMPLETE",
  "ExecutionStatus": "ROLLBACK_COMPLETE"
}
```

प्रीव्यू पूरा हो चुका था; स्थानांतरण रोलबैक हो गया था। कारण बताने वाले दोनों फ़ील्ड भी पढ़ें: `StatusReason` और `ExecutionStatusReason`। [DescribeStackRefactor API का रेफ़रेंस](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DescribeStackRefactor.html) इन्हें अलग-अलग परिभाषित करता है।

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

```text
Resource handler returned message: "Cannot invoke "String.equals(Object)" because the return value of "software.amazon.cloudwatch.alarm.ResourceModel.getAlarmName()" is null" (HandlerErrorCode: InternalFailure)
```

`AlarmName` का null होना समस्या को आगे जाँच के लिए भेजने में उपयोगी प्रमाण था। इससे ऐसा कोई उपाय पता नहीं चला जिसे हम खुद लागू करके समस्या ठीक कर सकते।

## रोलबैक के पाँच स्वीकृत अनुरोधों के बाद भी हम अटके रहे

हमारे पाँच प्रयासों में 22 अलार्म स्किप करने का एक पुष्ट अनुरोध और 27 सितंबर को 08:39 UTC पर AWS इंजीनियर के कहने पर किया गया एक और प्रयास शामिल था। सर्विस ने अनुरोध स्वीकार किए, लेकिन उनके ऑपरेशन विफल रहे। कॉल दोहराने से प्रगति साबित नहीं हुई।

AWS `continue-update-rollback` और `ResourcesToSkip` के इस्तेमाल को एक खास रिकवरी प्रक्रिया तक सीमित रखता है: रोलबैक के दौरान विफल हुए पात्र संसाधन ही स्किप करें, उनकी संख्या जितनी ज़रूरी हो उतनी ही रखें और अगले अपडेट से पहले स्किप किए गए संसाधनों को टेम्पलेट के अनुरूप लाएँ। स्किप होने से यह साबित नहीं होता कि लाइव संसाधन टेम्पलेट से मेल खाता है। यह निर्णय लेने के लिए [AWS की रोलबैक प्रक्रिया](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-continueupdaterollback.html) का पालन करें।

1 अक्टूबर को लगभग 22:00 UTC पर दोनों स्टैक के स्टेटस बदले। अगली सुबह AWS Support ने पुष्टि की कि उसकी आंतरिक टीम ने दोनों स्टैक ठीक कर दिए हैं और डिप्लॉयमेंट फिर शुरू हो सकते हैं। हमें उस अटकी हुई स्थिति से निकालने के लिए उस टीम का धन्यवाद। AWS ने आंतरिक मरम्मत की कोई कमांड नहीं दी और न ही यह पुष्टि की कि उसने सर्विस के लिए कोई सामान्य पैच जारी किया है। संवेदनशील विवरण हटाकर तैयार किया गया घटनाक्रम हमारी [निश्चित कमिट से जुड़ी घटना-प्रक्रिया](https://github.com/kirill-markin/flashcards-open-source-app/blob/d66cc6d02cc698654539d38361b5ed573b707963/docs/aws-infrastructure-changes.md) में है।

## RDS वाली व्याख्या इस पर निर्भर थी कि रीड किस पहचान से हुई

AWS ने शुरुआती विफलता की वजह एक्ज़िक्यूशन रोल में `rds:DescribeDBInstances` अनुमति की कमी बताई। उसका कहना था कि स्टैक के आउटपुट में RDS एंडपॉइंट पता करने के लिए यह रीड ज़रूरी थी, भले ही डेटाबेस ऐप के स्टैक में ही रहने वाला था।

यह AWS का आकलन था। हमारी स्वतंत्र जाँच से पूरी मूल वजह साबित नहीं हुई। हमने बताए गए रोल पर `AdministratorAccess` देखा था और IAM सिमुलेशन में भी अनुमति मिली थी। लेकिन इन दोनों से यह पता नहीं चला कि विफलता के समय कौन-सी पॉलिसी लागू थी या सर्विस का वास्तविक सेशन क्या था।

कई पहचानों का हिसाब रखना पड़ता है: CI कॉलर, डिप्लॉयमेंट या लुकअप के लिए assume किए गए रोल, अंतर्निहित रिफैक्टर API का कॉलर और CloudFormation का एक्ज़िक्यूशन रोल। आपके शेल से डेटाबेस रीड सफल होने पर केवल उस पहचान की जाँच होती है जिसे वह शेल इस्तेमाल करता है। [सर्विस रोल के दस्तावेज़](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-servicerole.html) बताते हैं कि CloudFormation कब कॉन्फ़िगर किए गए रोल के क्रेडेंशियल इस्तेमाल करता है; [IAM सिमुलेटर के दस्तावेज़](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html) बताते हैं कि सिमुलेशन लाइव अनुरोध से अलग क्यों हो सकता है।

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

## कई अलार्म एक साथ ले जाने पर आई अगली त्रुटि RDS के बिना भी दोहराई गई

AWS की आंतरिक रिकवरी के बाद प्रोडक्शन में कई संसाधन एक साथ ले जाने का एक और प्रयास रोलबैक हो गया। एक अलग प्रयोग में 58 अलार्म और अंतर्निहित रिफैक्टरिंग से बने डेस्टिनेशन के साथ वही त्रुटि दोहराई गई। उस प्रयोग में RDS की कोई निर्भरता नहीं थी। स्टैक ARN का प्रीफ़िक्स हटाने के बाद कारण यह था:

```text
Stack Refactor does not support AWS::CloudWatch::Alarm because the resource type defines an unsupported tag schema.
```

केवल RDS रीड इस बाद वाले नतीजे की व्याख्या नहीं कर सकती थी। संदेश का दावा भी हमारे प्रयोगों से साबित हुई बात से व्यापक लगता था: अंतर्निहित रिफैक्टरिंग से अलार्म स्थानांतरित करने के कई प्रयास सफल रहे थे।

| प्रयोग | देखा गया नतीजा |
| --- | --- |
| अपने-आप बने या स्पष्ट रूप से दिए नाम वाले एक-एक अलार्म, जिनमें टैग अनुपस्थित, खाली या मौजूद थे | अंतर्निहित रिफैक्टरिंग से स्थानांतरण सफल; भौतिक पहचान, डेस्टिनेशन टैग और सफ़ाई की पुष्टि हुई। |
| अंतर्निहित रिफैक्टरिंग से बने डेस्टिनेशन, जिनमें 2, 10 और 25 अलार्म थे | सफल; ID, कॉन्फ़िगरेशन, डेस्टिनेशन के सिस्टम टैग और सफ़ाई की पुष्टि हुई। |
| अंतर्निहित रिफैक्टरिंग से बना डेस्टिनेशन, 58 अलार्म और कोई RDS नहीं | असमर्थित टैग स्कीमा की त्रुटि के साथ रोलबैक हुआ। |
| 58 अलार्म का अलग मामला, जिसमें डेस्टिनेशन पहले से बनाया गया था | `InternalFailure` लौटा, जो अलग त्रुटि थी। |
| दो प्रभावित अलार्म स्थानांतरित किए, फिर उसी डेस्टिनेशन में दो और | दोनों स्थानांतरण सफल; सभी 58 मूल पहचान और कॉन्फ़िगरेशन सुरक्षित रहे। |

सार्वजनिक रिकॉर्ड में [2/10/25 वाला रन](https://github.com/kirill-markin/flashcards-open-source-app/actions/runs/37039188642), [58 अलार्म वाला रन](https://github.com/kirill-markin/flashcards-open-source-app/actions/runs/37040911612) और [डेस्टिनेशन दोबारा इस्तेमाल करने वाला रन](https://github.com/kirill-markin/flashcards-open-source-app/actions/runs/37043811213) शामिल हैं। लॉग की उपलब्धता की अवधि खत्म हो सकती है या उन्हें देखने के लिए साइन इन करना पड़ सकता है; निश्चित कमिट वाले घटना दस्तावेज़ में निष्कर्ष सुरक्षित हैं।

अंतर्निहित रिफैक्टरिंग से बने डेस्टिनेशन वाला एक मामला डेस्टिनेशन के `RoleARN` के बिना भी सफल रहा, इसलिए केवल उस फ़ील्ड की अनुपस्थिति से विफलता दोहराई नहीं गई। इम्पोर्ट से तैयार किया गया एक अस्थायी परीक्षण भी सफल रहा, लेकिन हमने प्रोडक्शन की रिकवरी के लिए इम्पोर्ट इस्तेमाल नहीं किया। स्पष्ट नाम वाला इम्पोर्ट प्रयोग शुरू ही नहीं हुआ, इसलिए उससे कोई नतीजा नहीं मिलता।

25 अलार्म का बैच हमारे परीक्षण में सफल रहा था; इससे AWS की कोई सीमा साबित नहीं हुई। संसाधनों की संख्या, डेस्टिनेशन कैसे बना और रोलबैक के बाद क्या बचा रहा, ये जाँच के उपयोगी पहलू थे। ये नतीजे न तो सर्विस के भीतर की मूल वजह बताते हैं, न इस बात की गारंटी देते हैं कि छोटे बैच किसी दूसरे स्टैक को ठीक कर देंगे।

## रोलबैक के बाद स्टैक की इन्वेंटरी और टैग मेल नहीं खा रहे थे

अलग वातावरण में किए गए 58 अलार्म वाले प्रयोग की विफलता के बाद CloudFormation की इन्वेंटरी में अलार्म वापस सोर्स में थे। फिर भी 49 अलार्म पर सिस्टम टैग उस डेस्टिनेशन का नाम बता रहे थे जिसे बाद में हटा दिया गया था; केवल नौ पर सोर्स का नाम था। सफ़ाई के दौरान `GetTemplate` में `InternalFailure` भी आया।

इसलिए केवल `aws:cloudformation:stack-id` पर आधारित स्वामित्व की जाँच गलत तस्वीर देती। हमने स्टैक की इन्वेंटरी, भौतिक ID, लाइव कॉन्फ़िगरेशन और टैग की अलग-अलग तुलना की। निर्भर रिलीज़ शुरू करने से पहले इस असंगति को सुलझाना ज़रूरी था।

रिकवरी के प्रयोग में हमने उसी डेस्टिनेशन में पहले दो अलार्म और फिर दो और अलार्म भेजे। दोनों स्थानांतरणों के बाद सभी 58 पहचान और कॉन्फ़िगरेशन सुरक्षित रहे। स्थानांतरित किए गए चारों अलार्म के सिस्टम टैग सही थे। हमने संरक्षित `aws:` टैग खुद नहीं लिखे। बाद में सफ़ाई की पुष्टि भी हुई और परीक्षण के लिए बनाए गए कोई स्टैक या अलार्म बाकी नहीं रहे।

दो पुराने विवरण नई जाँच को भी भटका सकते थे। स्टैक ठीक होने के बाद भी अलार्म की 22 `UPDATE_FAILED` पंक्तियाँ बची हुई थीं; केवल उन पंक्तियों से यह साबित नहीं होता था कि अभी कोई भौतिक अलार्म विफल है। एक अप्रचलित प्रीव्यू `ListStackRefactors` से गायब हो गया था, लेकिन उसकी सटीक ID से उसे अब भी पढ़ा जा सकता था। टाइमस्टैम्प की तुलना प्रोवाइडर की लाइव स्थिति से करें और ज्ञात ऑपरेशन का विवरण सीधे उसकी ID से पढ़ें, भले ही वह सूची में न आए। हमारी [निश्चित कमिट वाली स्वामित्व गाइड](https://github.com/kirill-markin/flashcards-open-source-app/blob/d66cc6d02cc698654539d38361b5ed573b707963/docs/monitoring-stack-migration.md) में दोनों अवलोकन दर्ज हैं।

## रिकवरी एक सामान्य रिलीज़ के साथ पूरी हुई

प्रोडक्शन का स्थानांतरण अंतर्निहित रिफैक्टरिंग के चार बैचों में पूरा हुआ: आठ मेट्रिक फ़िल्टर, फिर 25 अलार्म, 25 अलार्म और आठ अलार्म। माइग्रेशन के दौरान सभी 497 मूल भौतिक संसाधनों की पहचान और प्रकार सुरक्षित रहे। मॉनिटरिंग के सभी 66 संसाधन मॉनिटरिंग स्टैक में पहुँच गए।

हमने रिकवरी से जुड़े चार सवाल अलग रखे:

| रिकवरी का परिणाम | कौन-से प्रमाण इकट्ठा करें |
| --- | --- |
| स्टैक का काम करना | दोनों स्टैक के नए स्टेटस और हर ज्ञात रिफैक्टर ऑपरेशन की स्पष्ट स्थिति। |
| संसाधन, कॉन्फ़िगरेशन और डेटा का सुरक्षित रहना | पहले और बाद की पहचान व सेटिंग्स की तुलना, साथ में संबंधित सर्विस के डेटा की जाँच। केवल भौतिक ID का न बदलना डेटा की अखंडता साबित नहीं कर सकता। |
| ऐप का ठीक काम करना | मौजूदा हेल्थ चेक और संबंधित वेब, Agent API तथा MCP स्मोक फ़्लो। |
| सामान्य डिप्लॉयमेंट कर पाने की क्षमता | सामान्य रिलीज़ प्रक्रिया से सफलतापूर्वक डिप्लॉय किया गया कोई ज्ञात कमिट। |

अलग स्टैक बनने के बाद [पहली सामान्य रिलीज़](https://github.com/kirill-markin/flashcards-open-source-app/actions/runs/37061435128), कमिट `ad297a8` पर, सफल रही। [उसके बाद की सामान्य रिलीज़](https://github.com/kirill-markin/flashcards-open-source-app/actions/runs/37073868147), कमिट `0a530c7` पर, सभी नौ जॉब और तीनों स्मोक फ़्लो में सफल रही। प्लेटफ़ॉर्म, वेब और एडमिन ने अपेक्षित कमिट के डिप्लॉय होने की सूचना दी।

उस बाद वाली रिलीज़ ने जानबूझकर एक अपरिवर्तनीय `AWS::Lambda::Version` को बदला। बाकी 496 मूल पहचान, जिनमें मॉनिटरिंग के सभी 66 संसाधन शामिल थे, नहीं बदलीं। यह तुलना माइग्रेशन के दौरान सभी 497 पहचान सुरक्षित रहने वाली तुलना से अलग है: सामान्य रिलीज़ में नया Lambda वर्ज़न बनना पहले के माइग्रेशन के नतीजे को गलत नहीं ठहराता। [निश्चित कमिट पर सुरक्षित समापन के प्रमाण](https://github.com/kirill-markin/flashcards-open-source-app/blob/d66cc6d02cc698654539d38361b5ed573b707963/docs/monitoring-stack-migration.md#verified-completion-evidence) में दोनों दर्ज हैं।

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


---
*[View the styled HTML version of this page](https://kirill-markin.com/hi/gyan/aws-cloudformation-stack-refactoring-vifal)*

*Tip: Append `.md` to any URL on https://kirill-markin.com to get a clean Markdown version of that page.*