استكشاف أخطاء الشبكة وإصلاحها
منهجية لمشكلات اتصال VPC، وتحليل سجلات الشبكة، وتصحيح CloudFront، والوصلات الهجينة، ومراقبة الشبكة في CloudWatch.
كل موضوع آخر في هذا المجال بنى شيئاً. وهذا الموضوع يفكّكه حين يتوقّف عن العمل. اتصال تنتهي مهلته وأمامك أربعة متّهمين معقولين، ونسبة إصابة ذاكرة مؤقتة تنهار بلا أي نشر، وVPN يبلّغ أنه available ولا شيء يعبره. والذي يفصل بين إصلاح في عشرين دقيقة وانقطاع في ثلاث ساعات ليس معرفة خدمات أكثر، بل امتلاك ترتيب تعمل به ومعرفة أي مصدر دليل يستطيع فعلاً رؤية القفزة التي تشكّ فيها.
ما الذي يغطيه هذا الموضوع
- مشي مرتّب من المصدر إلى الوجهة يجد المكوّن المانع بدل التخمين، وReachability Analyzer ورموز التفسير التي يعيدها
- قراءة سجلّ تدفّق VPC حقلاً حقلاً، ونمط ACCEPT ثم REJECT الذي يفصل منع مجموعة الأمان عن منع network ACL
- الحركة التي لا تلتقطها VPC Flow Logs إطلاقاً، ومتى يكون الجواب Transit Gateway Flow Logs أو سجلات وصول ELB أو سجلات WAF أو سجلات استعلامات Resolver
- الاستعلام عن السجلات على الحجم بـ CloudWatch Logs Insights وAmazon Athena
- تشخيص CloudFront من ترويسات الاستجابة وحقول نوع النتيجة، وأسباب 403 و502 و504، وكيف تجد بُعد مفتاح الذاكرة المؤقتة الذي يمزّق نسبة إصابتك
- تشخيص الوصلات الهجينة من الأسفل صعوداً: Phase 1 مقابل Phase 2 مقابل BGP في VPN، والطبقات 1 و2 و3 في Direct Connect
- أعطال التوجيه وDNS التي تترك وصلة سليمة تماماً لا تحمل أي حركة
- Internet Monitor وNetwork Flow Monitor وNetwork Synthetic Monitor، والمقاييس لكل مورد التي تمسك أعطالاً لم يبلّغ عنها أحد
لماذا هذا مهم
المهمّة 5.3 في الاختبار استكشاف أخطاء بالكامل، وأسئلتها مبنية بكسر شيء واحد بالضبط في معمارية سليمة فيما عداه. والمرشّحون الذين يتعثّرون هم من يعرفون كل خدمة على حدة وليس لديهم منهج لتضييق أربعة متّهمين إلى واحد. والمرشّحون الذين ينجحون يقرأون العَرَض أولاً: انتهاء المهلة ورفض الاتصال يشيران إلى طبقتين مختلفتين، وسجلّ REJECT واحد وزوج ACCEPT ثم REJECT يشيران إلى جدارين مختلفين، وخطأ 502 وخطأ 504 يشيران إلى نصفين مختلفين من الاتصال بالأصل.
والانضباط نفسه هو ما يصنع الفارق أثناء المناوبة. فتسمية القفزة التي تشكّ فيها قبل فتح أي كونسول تختار أداتك عنك، والاختيار الصحيح هو معظم العمل.
