حقل Status يختفي من AWS Organizations في 9 سبتمبر: حدّث السكربتات
سينسحب حقل Status من واجهات AWS Organizations في 9 سبتمبر 2026، لذا يجب نقل السكربتات والتكاملات إلى State قبل الموعد. تؤكد صفحة إطلاق State من AWS أن الحقلين يبقيان متاحين مؤقتًا في DescribeAccount وListAccounts وListAccountsForParent، ثم يتوقف ظهور Status.
لا يقتصر التحديث المطلوب قبل 9 سبتمبر 2026 على استبدال اسم مفتاح: اجرد مواضع الاعتماد، وحدّث AWS CLI وSDK، ثم اختبر القيم الخمس وطلبات لا تحتوي على Status. السبب أن State يفصل حالات كان Status يجمعها، وقد يغيّر قرار الأتمتة حتى عندما يخص الحساب نفسه.
حوّل منطق القرار، لا اسم الحقل فقط
يقبل Status ثلاث قيم: ACTIVE وSUSPENDED وPENDING_CLOSURE. أما State فيقبل PENDING_ACTIVATION وACTIVE وSUSPENDED وPENDING_CLOSURE وCLOSED؛ وبذلك يميز الحساب الذي لم يكتمل تسجيله عن الحساب الجاهز، ويفصل الإغلاق عن التعليق الذي تفرضه AWS.
تجمع وثائق حالة حسابات AWS المعاني والقيود المهمة: PENDING_ACTIVATION لحساب غير قابل للاستخدام قبل إكمال التسجيل، وACTIVE لحساب عامل، وSUSPENDED لحساب قيّدت AWS الوصول إليه، وPENDING_CLOSURE لطلب إغلاق قيد المعالجة مع بقاء الحساب قابلًا للاستخدام، وCLOSED لحساب لا يمكنه الوصول إلى خدمات AWS خلال فترة ما بعد الإغلاق البالغة 90 يومًا.
استخدم جدول التحويل التالي نقطة بداية لمراجعة قواعد الأعمال، لا تحويلًا حسابيًا ثابتًا:
- Status=ACTIVE: قد تقابله State بقيمة PENDING_ACTIVATION أو ACTIVE. لا تبدأ تهيئة الموارد قبل التأكد من أن القيمة الجديدة هي ACTIVE.
- Status=SUSPENDED: قد تقابله State بقيمة SUSPENDED أو CLOSED. وجّه الأولى إلى مسار التعليق الذي تفرضه AWS، والثانية إلى معالجة الإغلاق أو الاستعادة.
- Status=PENDING_CLOSURE: تبقى PENDING_CLOSURE في State، لكنها حالة مؤقتة تختلف عن CLOSED ولا ينبغي دمجهما في فرع واحد.
راجع كل شرط سلبي أيضًا. فاستبدال شرط من نوع «Status لا تساوي SUSPENDED» بالمفتاح الجديد وحده قد يسمح خطأً بمرور PENDING_ACTIVATION أو PENDING_CLOSURE أو CLOSED.
اجرد الواجهات والمستهلكين الثانويين
ابحث في المستودعات عن Status، وصيغ الوصول مثل account.Status، ومفاتيح JSON، ومسارات JMESPath، وأنواع enum، ومخططات التحقق، وأعمدة SQL. وسّع الجرد إلى وظائف Lambda وخطوط CI/CD وطوابير الرسائل ومستودعات البيانات والتقارير؛ فقد تستقبل طبقة الجمع State بصورة صحيحة ثم تحذفه طبقة ذات مخطط قديم.
يجب أن يشمل الجرد DescribeAccount وListAccounts وListAccountsForParent، وأن يضم ListDelegatedAdministrators إذا كان مستخدمًا. يوضح الشرح التقني لـAWS Organizations أن الواجهات الأربع أضافت State بقيمه الخمس، وأن وحدة التحكم وملف Organization_accounts_information.csv يعرضان State بدل Status؛ لذلك تحتاج عمليات استيراد CSV إلى رأس العمود الجديد وملف تصدير حديث.
سجّل لكل اعتماد الواجهة أو الملف، وإصدار الأداة، والقيم المقبولة، والقرار الناتج، ومالك التغيير. هذه القائمة تكشف الفجوة بين دعم الحقل في عميل AWS وبين وصوله سليمًا إلى التنبيه أو التقرير أو قرار الأتمتة.
حدّث CLI وSDK والشفرة بترتيب قابل للرجوع
لعرض State في استجابات API، استخدم AWS CLI 2.29.0 أو أحدث، أو إصدارًا من SDK صدر بعد 9 سبتمبر 2025. افحص النسخة الفعلية داخل صور الحاويات ووكلاء CI وبيئات Lambda أو التشغيل، لا نسخة محطة المطور وحدها.
- حدّث CLI أو SDK وثبّت الإصدار في ملف الاعتماد أو صورة البناء، ثم أعد إنشاء ملف القفل عند الحاجة.
- أضف State إلى نموذج البيانات الداخلي واجعله الحقل المفضل عند وجوده. يمكن إبقاء الرجوع إلى Status مؤقتًا خلال النشر التدريجي، لكن يجب ألا يكون مطلوبًا لنجاح المعالجة.
- استبدل الفروع الثنائية بقوائم صريحة للقيم المقبولة. عالج القيمة غير المعروفة كحالة مستقلة تُسجّل أو توقف القرار بأمان، لا كمرادف لـACTIVE.
- حدّث مخططات JSON وأنواع enum وقواعد التحقق وتسلسل الرسائل وأعمدة التخزين. اختبر أن كل طبقة تحفظ State عند الكتابة وإعادة القراءة.
- عدّل مستهلكي Organization_accounts_information.csv لاستخدام State، واختبرهم بملف مُصدّر حديثًا بدل ملف محفوظ يحتفظ بالبنية القديمة.
أثناء فترة وجود الحقلين، يمكن تسجيل State وStatus مع معرّف الحساب والواجهة المستخدمة لمقارنة قرارات النظام. اجعل هذا القياس مؤقتًا؛ الغرض كشف الفروع القديمة، لا إنشاء اعتماد جديد على Status.
اختبر الحالات الخمس وحمولة بلا Status
أنشئ fixture مستقلة لكل قيمة. يجب أن ينتظر PENDING_ACTIVATION اكتمال التسجيل، وأن يمر ACTIVE فقط إلى العمليات المخصصة للحساب الجاهز، وأن يوجّه SUSPENDED إلى معالجة تقييد AWS، بينما يذهب CLOSED إلى مسار الإغلاق أو الاستعادة.
اختبر PENDING_CLOSURE منفصلة عن CLOSED: الأولى طلب إغلاق لم تكتمل معالجته وقد يظل الحساب خلالها عاملًا، أما الثانية فتمنع الوصول إلى خدمات AWS خلال فترة ما بعد الإغلاق. لا تحذف سجل الحساب تلقائيًا عند ظهور أي منهما؛ احتفاظ نظام الجرد بالسجل قرار مختلف عن قابلية الحساب للاستخدام.
غطّ ثلاث حمولات توافق على الأقل:
- استجابة تحتوي State وStatus معًا، مع إثبات أن القرار يعتمد State.
- استجابة تحتوي State فقط، لمحاكاة الوضع بعد 9 سبتمبر 2026.
- استجابة تحمل قيمة State لا يعرفها إصدار التطبيق، للتأكد من عدم تصنيفها تلقائيًا ضمن حالة قائمة.
أضف اختبار pagination إلى ListAccounts وListAccountsForParent؛ نجاح الصفحة الأولى لا يثبت فحص جميع الحسابات. وإذا مرت الاستجابة عبر طابور أو مخزن وسيط، اختبر serialization ثم إعادة القراءة حتى لا تسقط State بين المنتج والمستهلك.
اجعل غياب Status شرط قبول للنشر
قبل النشر، شغّل DescribeAccount على عينات تمثل الحالات المتاحة وقارن القرار التشغيلي القديم بالجديد. لا تشترط تطابق النصين: ظهور State بقيمة CLOSED إلى جانب Status بقيمة SUSPENDED مثال على اختلاف مقصود يجب أن ينتج معالجة أدق.
اجعل بوابة الإصدار ترفض أي schema ما زال يشترط Status. راقب غياب State، والقيم غير المعروفة، وأخطاء فك JSON، والحقول الفارغة في التقارير، وفشل استيراد CSV، وعدد مرات استخدام مسار الرجوع إلى Status.
بعد اجتياز دورة إنتاج كاملة باستخدام State، أزل مسار الرجوع والعدادات الخاصة بـStatus، ثم أعد البحث في المستودعات والمخططات. معيار الاكتمال هو استمرار جميع المسارات في العمل عندما تكون State موجودة ولا يصل Status إطلاقًا.
اقرأ أيضًا:
اشترك في نشرتنا الإخبارية
احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.