التحقق من حالة AWS: دليل عملي للبقاء على المسار الصحيح

عندما يتعلق الأمر بالتحقق مما إذا كانت AWS تعمل بشكل جيد أو تواجه مشكلة، فليس كافيًا مجرد النظر إلى الضوء الأخضر أو ​​الأحمر: يتعين عليك عبور لوحة الصحة والإشارات في الوقت الفعلي والمراجعات المحددة لمواردكبفضل هذا النهج المشترك، ستعرف ما إذا كانت المشكلة عامة، أو إقليمية، أو مرتبطة بالبنية التحتية الخاصة بك، وستتمكن من التصرف دون اللجوء إلى اتخاذ خطوات عشوائية.

في هذا الدليل، سأترك لك كل شيء منظمًا بشكل جيد للتحقق من حالة AWS برأس: من لوحة معلومات AWS Health وتكاملها مع EventBridgeستتعلم كيفية عرض حالة التجديد في ACM، وتفسير عمليات فحص EC2، والتفاعل مع مقاييس وتنبيهات CloudWatch. ستتعرف أيضًا على الخطوات اللازمة في حال رفض تحميل وحدة التحكم، وكيفية التحقق من صفحة الحالة العامة، ولماذا تُعدّ أدوات خارجية مثل Downdetector مفيدة للسياق، ولكنها ليست مفيدة للأتمتة.

لوحة معلومات AWS Health: نقطة البداية

تعرض لوحة معلومات AWS Health الانقطاعات والأحداث النشطة والصيانة المخطط لها والتي قد تؤثر على خدماتك ومواردك. إنه جزء من حسابك، ولا يتطلب أي تكوين، ويوفر رؤية سياقية. حول ما يحدث. إذا لم تكن مسجلاً الدخول إلى نسخة أو وحدة تحكم معينة، فهذا هو المكان الأول الذي يجب عليك البحث فيه.

تفصيلة غالبًا ما يتم نسيانها: AWS هي شركة إقليميةاختر المنطقة الصحيحة من لوحة "الصحة"، لأنه إذا بحثت عن منطقة خاطئة، فقد تفوتك المشكلة التي تؤثر عليك. هذه الدقة تمنع التشخيص الخاطئ عندما تقتصر المشكلة على منطقة جغرافية محددة.

اعتبارًا من عام 2023، عند افتتاح حدث عام حول لوحة الصحة، يتضمن عنوان URL للمتصفح رابطًا عميقًا للحدثيتيح لك هذا مشاركة الحادث الدقيق الذي تشاهده أو إعادة فتحه والعودة إلى نفس العرض مع تحميل النافذة المنبثقة، مما يسهل العمل الجماعي أثناء وقوع حادث.

إذا لم تفتح وحدة التحكم الإدارية أو أعادت أخطاء المتصفح (على سبيل المثال، 404)، فلا تتعجل في ذلك. أولاً، تحقق مما إذا كان هناك حدث نشط ذي صلة في لوحة معلومات الصحة، ثم قم بتطبيق التدابير المحلية مثل مسح ذاكرة التخزين المؤقت وملفات تعريف الارتباط، وتجربة متصفح مختلف، والتأكد مع فريق تكنولوجيا المعلومات لديك من أن شبكتك لا تحظر نطاقات Amazon (amazon.com والنطاقات الفرعية مثل aws.amazon.com).

استيعاب الأحداث بشكل موثوق: EventBridge أفضل من RSS

هناك موجزات RSS تحتوي على أحداث صحية، ولكن تنسيقها يمكن أن تتغير بمرور الوقت وتؤدي إلى كسر تكاملاتكإن الاعتماد على RSS أو استخراج البيانات منه للحصول على خطوط الأنابيب الهامة يعد أمرا محفوفا بالمخاطر، على أقل تقدير.

الشيء القوي هو التكامل AWS Health مع Amazon EventBridgeبهذه الطريقة، يمكنك تلقي الأحداث باستخدام مخطط مستقر، في الوقت الفعلي، وجاهزة للتوجيه إلى Lambda أو قوائم الانتظار أو الإشعارات أو لوحات المعلومات الداخلية، مما يؤدي إلى إنشاء دائرة الحوادث الخاصة بك بدون أجزاء هشة.

مع EventBridge يمكنك الحصول على إمكانية التتبع والمرونة: يمكنك وضع علامات على الردود وإثرائها وربطها وأتمتتها حسب الخدمة أو المنطقة أو التأثير. وإذا تغيرت تفاصيل عرض موجز الأخبار العامة غدًا، فسيظل تكاملك كما هو.

ACM: مراجعة تجديدات الشهادات دون أي مشاكل

باستخدام AWS Certificate Manager، يمكنك التحقق من تجديد شهاداتك بشكل صحيح بطريقة مُدارة. تكون الشهادة مؤهلة للتجديد التلقائي عندما تكون مرتبطة بخدمات AWS (على سبيل المثال، ELB أو CloudFront) أو إذا تم تصديرها منذ إصدارها أو تجديدها الأخير.وتشكل هذه الأهلية حجر الأساس في نسيان التجديدات اليدوية.

عند بدء دورة التجديد، يعرض ACM حقل الحالة في تفاصيل الشهادة. من وحدة التحكم أو واجهة برمجة التطبيقات أو سطر الأوامر، يمكنك التحقق من RenewalStatus لمعرفة وضعك الصحي. سترى أيضًا الحالات ذات الصلة بلوحة معلومات صحتك إذا كانت هناك أي مشاكل تتطلب اهتمامك.

إذا كنت تفضل الأوامر، فإن واجهة سطر الأوامر تجعل الأمر سهلاً: تعيد عملية describe-certificate التفاصيل، بما في ذلك حالة التجديد.. على سبيل المثال:

على سبيل المثال: aws acm describe-certificate --certificate-arn arn:aws:acm:REGION:ACCOUNT:certificate/CERTIFICATE_ID

في استجابة JSON، انظر إلى حقل RenewalStatus. إذا لم يظهر هذا الحقل بعد، فهذا يعني أن ACM لم تبدأ عملية التجديد المُدار.من الجيد التخطيط مسبقًا: تحاول ACM التجديد تلقائيًا قبل حوالي 60 يومًا من انتهاء الصلاحية، وإذا حدث خطأ ما (على سبيل المثال، التحقق من صحة النطاق)، سوف تتلقى إشعارات في الصحة مسبقًا: 45، 30، 15، 7، 3 و 1 يوم.

عندما لا يتم شحن وحدة التحكم: خطوات سريعة وفعالة

عادةً ما تكون أخطاء 404 أو فشل الاتصال عند الوصول إلى وحدة التحكم AWS قابلة للحل. ابدأ بمراجعة لوحة معلومات الصحة في المنطقة التي توجد بها مواردك. لإغلاق حدث مستمر يؤثر على تلك الخدمة أو وحدة التحكم.

إذا لم تكن هناك حوادث مفتوحة، قم بتطبيق التدابير المحلية: مسح ذاكرة التخزين المؤقت وملفات تعريف الارتباط للمتصفححاول تسجيل الدخول باستخدام متصفح آخر وتأكد مع مسؤول النظام لديك من أن شبكة الشركة لا تحظر amazon.com أو النطاقات الفرعية مثل aws.amazon.com.

قد تكون المشكلة مقتصرة على مورد محدد. على سبيل المثال، قد تخضع نسخة EC2 لصيانة مخططة.ستعرض لك لوحة "الصحة" نافذة وتأثير هذا الحدث. الانتقال إلى الجذر يوفر لك الوقت.

بالإضافة إلى ذلك، إذا تم حظر حسابك، فمن الجيد دائمًا أن يكون لديك مقالات مساعدة في متناول يدك: قم بإنشاء حساب جديد وتنشيطه، أو قم بتسجيل الدخول إلى وحدة التحكم، أو اطلب المساعدة.يساعد وجود هذه الأدلة في تقليل أوقات الانتظار في أوقات التوتر.

EC2 بالتفصيل: عمليات التحقق من الحالة وما يجب فعله عند فشلها

يقوم Amazon EC2 بإجراء عمليات فحص تلقائية لكل مثيل للكشف عن مشكلات النظام الأساسي أو البرامج التي تؤثر على تطبيقاتك. يتم إجراء هذه الفحوصات كل دقيقة ووضع علامة "موافق" أو "متضرر" حسب نتيجتها.لا يمكن إيقاف تشغيلها وهي بمثابة تحذير مبكر لك.

يتم دعم كل نوع من أنواع التحقق بواسطة المقاييس في CloudWatch. إذا فشل الفحص، يرتفع المقياس المرتبط به ويصبح الوقت مناسبًا لإطلاق الإنذار.باستخدام هذا، يمكنك أتمتة الإشعارات والإجراءات لتقليل وقت التوقف.

فحوصات النظام (المنصة الأساسية)

تقوم هذه الفحوصات بمراقبة البنية الأساسية التي يتم تشغيل مثيلك عليها. عندما تفشل، فعادةً ما تكون المشكلة في النظام الأساسي والتي تتطلب تدخل AWS أو اتخاذ إجراءات لنقل المثيل إلى مضيف آخر..

في الحالات التي يدعمها نظام EBS، يكون الإجراء الفعال هو إيقاف وبدء تشغيل المثيل لنقله إلى مضيف جديدإذا كانت مثيلاتك تستخدم مخزن المثيلات (Linux)، فيمكنك اختيار الإنهاء والاستبدال، مع العلم أن وحدات التخزين المؤقتة تُفقد عند إيقاف التشغيل.

المقياس الذي يعكس هذا الفشل هو فشل فحص الحالة_النظامإنه مثالي للتنبيهات التي تؤدي إلى تشغيل كتب التشغيل، أو الاسترداد التلقائي، أو فتح حالة دعم إذا استمرت المشكلة.

هناك خصوصية مع Bare Metal: قد يؤدي إعادة التشغيل من نظام التشغيل إلى حدوث خطأ مؤقت في فحص النظام.عندما تعود الحالة إلى العمل مرة أخرى، ستعود الحالة إلى "موافق" دون أي تدخل إضافي.

فحوصات المثيلات (الاتصال والبرمجيات)

تقوم هذه الفحوصات بتحليل صحة نظام التشغيل وشبكة المثيل نفسه. يقوم EC2 بالتحقق من صحة الاتصال عن طريق إرسال طلبات ARP إلى NIC للتحقق من استجابتها.عادةً ما يتطلب الفشل هنا إجراء تعديلات من جانبك.

إذا فشل الاختبار، فقد حان الوقت للتصرف: أعد تشغيل المثيل، وتحقق من جدار الحماية/iptables، وتحقق من سجلات النظام، وتأكد من استجابة الشبكة.عندما يكون السبب هو البرنامج أو التكوين، الانتظار ليس كافيا.

المقياس الذي يجب مراقبته هو فشل التحقق من الحالة. استخدمه لتشغيل التنبيهات التي تقوم بتشغيل إجراءات التشخيص (جمع السجلات، أو عمليات إعادة التشغيل المتحكم فيها، أو التراجعات إذا اكتشفت أنها لا تتعافى).

مرة أخرى، في Bare Metal، قد يظهر خطأ مؤقت عند إعادة التشغيل من نظام التشغيل. عندما يكمل المثيل عملية التمهيد، تعود الاختبارات عادةً إلى "موافق".لذلك لا داعي للذعر.

الشيكات المرفقة في EBS (الإدخال/الإخراج على المجلدات)

تتحقق هذه الفحوصات مما إذا كانت وحدات تخزين EBS المرفقة قابلة للوصول ويمكنها إكمال عمليات الإدخال/الإخراج. يشير المقياس الثنائي StatusCheckFailed_AttachedEBS إلى التدهور عند فشل وحدة تخزين واحدة أو أكثر..

قد يكون الخطأ في هذا الصدد ناتجًا عن مشكلات حسابية أساسية أو مشكلات في EBS. يمكنك توقع التخفيف من حدة المشكلة من AWS أو اتخاذ إجراء:استبدال وحدات التخزين، وإيقاف وتشغيل المثيل لنقله إلى مضيف آخر، أو مراجعة حجم IOPS إذا رأيت اختناقات.

إذا لم يحقق الحمل الخاص بك عمليات الإدخال/الإخراج ولكن ظهر التدهور، يمكن لدورة التوقف والبدء حل مشكلات المضيف التي تؤثر على إمكانية الوصول إلى وحدة التخزين.. استكمل بمقاييس EBS الأصلية في CloudWatch للكشف عن أنماط الأداء الضعيفة.

في مجموعات التوسع التلقائي، قم بتكوين السياسة لـ إزالة الحالات التي بها إخفاقات مستمرة في فحص EBS المرفقستتمكن من الحفاظ على أسطولك سليمًا دون تدخل يدوي وتجنب التوقف لفترات طويلة.

التنبيهات والأتمتة: CloudWatch + التوسع التلقائي

مع كل مقاييس الصحة، يصبح CloudWatch بمثابة جهازك العصبي. تحديد الحدود وإنشاء التنبيهات وتنظيم الإجراءات: الإشعارات، وLambda، واسترداد المثيل أو استبداله. وهو الأساس للاستجابات التلقائية والمتسقة.

إذا كنت بحاجة إلى استمرارية العمل، ففكر في أتمتة واستبدال: يمكن للتوسع التلقائي إيقاف تشغيل الحالات الفاشلة وتشغيل حالات جديدة، بينما تقوم التنبيهات الخاصة بك بتنشيط قنوات الإشعار المناسبة (البريد الإلكتروني، أو Slack، أو PagerDuty، أو أي شيء تستخدمه).

الرؤية الكاملة تأتي من مصادر مترابطة: مقاييس وسجلات CloudWatch والتتبعات وأحداث AWS Health عبر EventBridgeباستخدام هذا المربع، ستتمكن من التمييز ما إذا كانت المشكلة في تطبيقك، أو المثيل، أو الحجم، أو النظام الأساسي، وستتمكن من الرد بدقة.

المصادر الرسمية والسياقية لمعرفة ما إذا كان AWS يفشل

عندما تنتشر شائعات السقوط - مثل انقطاع عالمي في AWS والتي تسببت في إخفاقات جسيمة، والمثالي هو إعطاء الأولوية للمصادر الرسمية. تحقق من صفحة status.aws.amazon.com العامة لمعرفة الحالة حسب الخدمة والمنطقة.، واستخدم لوحة معلومات AWS Health إذا قمت بتسجيل الدخول للحصول على معلومات خاصة بالحساب.

توفر المصادر الخارجية سياقًا وإشارات اجتماعية إضافية. يعكس Downdetector الارتفاعات في تقارير المستخدمين، ويلخص Stack Status حالة العديد من مقدمي الخدمة.إنها مفيدة لتقدير مدى الوصول، على الرغم من أنها لا تحل محل القنوات الرسمية.

ومع ذلك، فإنه يميز بين الرؤية والأتمتة. بالنسبة لاستيعاب الأحداث البرمجية، يعد EventBridge أفضل من موجزات RSS أو الكشط.، لأن التنسيقات الخارجية يمكن أن تتغير وتتركك في منتصف الحادث.

كيف تظهر القطرات الكبيرة وما الذي يمكنك توقعه

تميل الحوادث الكبرى إلى التركيز في المناطق ذات الاستخدام الكثيف (مثل الساحل الشرقي للولايات المتحدة)، يتم الشعور بالتأثير في السلاسل: التخزين، والحوسبة، وقواعد البيانات أو DNSليس من غير المألوف أن نرى خدمات مثل S3، أو EC2، أو RDS، أو Route 53، أو Kinesis مدرجة ضمن الخدمات المتأثرة بارتفاع مستوى الأخطاء.

في هذه الحالات، قد تواجه شركات البث وأدوات التعاون والتجارة الإلكترونية أو تطبيقات الهاتف المحمول تأخيرًا وأخطاء مصادقة وفشلًا متقطعًا. النمط غير متساوٍ: فهو يعمل مع بعض المستخدمين، ولا يعمل مع آخرين.، وفقًا للطرق ونقاط التواجد والمناطق النشطة.

عادةً ما تنشر القنوات الرسمية تحديثات منتظمة: التعرف الأولي على السبب (على سبيل المثال، مشكلات حل DNS على واجهة برمجة التطبيقات)، ونشر إجراءات التخفيف، وتوصيات إعادة المحاولةمع تقدم عملية الاسترداد، تقل الأخطاء وتعود حركة المرور إلى وضعها الطبيعي.

في بلدان أو قطاعات معينة، ستشاهد عناوين رئيسية حول خدمات محددة متأثرة. يمكن أن تتأثر المنصات مثل Netflix وDisney+ وSlack والبنوك أو التطبيقات الشائعة جدًا عندما تعاني المنطقة التي يعتمدون عليها، وحتى الشركات في أمريكا اللاتينية (مثل iFood، وMercado Livre، وPicPay في الحوادث الماضية) شعرت بالهزة.

التأثير الاقتصادي والسمعي للسقوط

وبعيدًا عن الجانب الفني، فإن انقطاع الخدمة السحابية له تكلفة حقيقية: الخسائر في الدقيقة، والدعم المثقل، والعملاء المحبطين، والضغط الإعلاميويتم تضخيم تأثير الشبكة من خلال مركزية بعض ركائز الإنترنت.

إن المنظمات التي تدير خدمات حيوية تعرف هذا جيدًا: إذا تكررت الإخفاقات، فإن الثقة تتآكل واستعادة صورة العلامة التجارية تكلف أكثر من الإصلاح الفني نفسه.

وتجلب هذه الأزمات درساً واضحاً ولكن غير مريح: نحن نعتمد بشكل كبير على البنى التحتية المشتركةإن التصميم من أجل المرونة وافتراضات الفشل الواقعية لم يعد خيارا.

استراتيجيات لكي نكون أكثر مرونة في مواجهة الحادث التالي

إذا لم يكن من الممكن إغلاق عملك، فهناك تكتيكات من شأنها تقليل المخاطر التشغيلية. خذ بعين الاعتبار بنية متعددة المناطق لتوزيع الحمل بين مناطق AWS المختلفة. وتجنب نقطة واحدة من الفشل الجغرافي.

عندما تبرر حالة الاستخدام ذلك، قم بتقييم السحابة المتعددة. إن توزيع الوظائف الأساسية على موفر آخر (Azure، GCP) يوفر لك شبكة أمان.على الرغم من أنها تنطوي على قدر أكبر من التعقيد وتكاليف التنسيق.

في طبقة التسليم، تساعد شبكة CDN المُهيأة جيدًا على تجاوز العواصف. تتيح لك خدمات مثل CloudFront أو البدائل مثل Cloudflare تقديم محتوى ثابت حتى لو كان مصدرك متعثرًا.، مما يمنح المستخدمين والأنظمة استراحة.

لا شيء من هذا يعمل بدون تنظيم: تحديد خطة الاستجابة للحوادث مع الأدوار والقنوات والتصعيد والاتصالات الخارجيةفي اللحظات الحارة، الوضوح يوفر دقائق ثمينة.

أفضل الممارسات للتحقق من حالة AWS دون الضياع

Centraliza la observabilidad: استخدم لوحة معلومات AWS Health لسياق المنصة وCloudWatch للمقاييس التشغيليةيمنعك هذا النهج المزدوج من أن تفاجأ بأي طبقة.

مع الشهادات، الأتمتة. راقب RenewalStatus في ACM وتفاعل مع التنبيهات المتصاعدة من لوحة معلومات الصحة حتى لا تصل إلى تاريخ انتهاء الصلاحية بالخطأ.

ضبط التنبيهات على مقاييس EC2 الرئيسية. StatusCheckFailed_System وStatusCheckFailed_Instance وStatusCheckFailed_AttachedEBS ضرورية، المرتبطة بإجراءات الاسترداد أو إعادة التشغيل أو الفشل أو الاستبدال عبر التوسع التلقائي، وفقًا لاتفاقية مستوى الخدمة (SLA) الخاصة بك.

وإذا قاومت وحدة التحكم، فتذكر القائمة التالية: التحقق من الأحداث الصحية في المنطقة الصحيحةامسح ذاكرة التخزين المؤقت وملفات تعريف الارتباط، غيّر متصفحك، وتأكد من قسم تكنولوجيا المعلومات من عدم حظر نطاقات AWS. هذه الفحوصات البسيطة تحل أكثر مما تظن.

الموارد ذات الصلة ومساعدة الحساب

لتوسيع وتعزيز عملياتك، راجع الوثائق الخاصة بالخدمات المعنية. AWS Health وEventBridge لتوجيه الأحداث، وACM للتجديدات، ومرجع CloudWatch/EC2 للمقاييس والإجراءات.، تشكل مجموعة قوية.

• لوحة معلومات الصحة في AWS:إمكانية رؤية الأحداث العامة والأحداث الخاصة بالحساب، دون الحاجة إلى أي تكوين إضافي.
• أمازون إيفينت بريدج:استيعاب موثوق للأحداث الصحية مع قواعد مرنة للتوجيه إلى وجهات متعددة.
• مدير شهادات AWS (ACM):تتبع حالة التجديد والإشعارات المتدرجة قبل انتهاء الصلاحية.
• أمازون EC2 + كلاود واتش:الفحوصات في الدقيقة، ومقاييس الحالة، والتنبيهات التي تؤدي إلى استجابات تلقائية.

إذا كانت لديك أسئلة حول الوصول إلى حسابك أو إدارته، فيرجى الرجوع إلى مقالات الدعم الأكثر شيوعًا: كيفية إنشاء حساب جديد وتنشيطه، وكيفية تسجيل الدخول إلى وحدة التحكم، وكيفية طلب المساعدة بشأن حسابك ومواردك.إن تحديد موقعها يسرع العملية عندما لا يكون هناك شيء مناسب.

إن النظر إلى لوحة واحدة لا يخبرنا بالقصة كاملة: تتطلب عملية التحقق من صحة AWS الجمع بين سياق لوحة معلومات الصحة، والاستيعاب الموثوق به مع EventBridge، وإشارات ACM، وفحوصات EC2.بفضل الإنذارات المدروسة جيدًا والخطط الواضحة، تصل التشخيصات بشكل أسرع، وتصبح الاستجابات أكثر دقة، وتصبح العمليات أكثر سلاسة حتى عندما تزداد حركة المرور أو تحدث اضطرابات إقليمية.