انقطع خادمي عن الخدمة واكتشفت ذلك بالصدفة بعد خمس ساعات

لم يأتِ التنبيه من خدمة مراقبة. لم يأتِ من تنبيه آلي أو webhook يطلق إلى Slack. جاء من أبدائي نظام مراقبة يمكن تخيله: فتح متصفح، وكتابة عنوان URL، والنظر إلى صفحة فارغة. كان يوم ثلاثاء بعد الظهر. كان الموقع معطلاً منذ حوالي التاسعة صباحاً، وكان الآن قد تجاوز الثانية بعد الظهر. خمس ساعات من الصمت الكامل من تطبيق ويب كان يخدم عادة آلاف الطلبات يومياً. خمس ساعات رأى فيها كل زائر صفحة خطأ، وأرجع كل استدعاء API لا شيء، وفشلت كل مهمة مجدولة بصمت في الخلفية. لم ينهار الخادم بشكل درامي. لم تكن هناك حالة ذعر kernel، لا فشل قرص، لا متجه هجوم ترك دليلاً forensic. خادم Contabo VPS توقف ببساطة عن الاستجابة لطلبات HTTP، يجلس هناك مع عنوان IP صالح ونبض على طبقة الشبكة، لكنه يرفض توفير أي حركة مرور على الويب على الإطلاق.

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

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

الفرق بين مراقبة وقت التشغيل ومعرفة أن موقعك يعمل فعلاً

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

تخيل سيناريو حيث يرجع الخادم رمز 200 حالة، لكن الصفحة معطلة. فشل اتصال قاعدة البيانات، لذا تظهر منطقة المحتوى رسالة خطأ بدلاً من قائمة المنتجات المتوقعة. فشل ملف CSS في التحميل، لذا تعرض الصفحة بصيغة HTML غير مصممة. يمنع خطأ JavaScript التطبيق الرئيسي من التهيؤ، تاركاً المستخدم ينظر إلى مؤشر تحميل لا يتحقق أبداً. يحقن أداة جهة خارجية overlay يغطي محتوى الصفحة بأكمله. في جميع هذه الحالات، يقرر جهاز المراقبة كل شيء صحي لأنه تلقى رد 200. الخادم متصل. الموقع معطل. لا أحد يعرف.

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

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

بناء خط أنابيب التنبيه الذي كان يجب أن يكون موجوداً منذ اليوم الأول

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

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

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

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

ما الذي تكلفه خمس ساعات من التوقف غير المرئي فعلاً

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

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

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

من رد الفعل إلى استباقي وعدم اكتشاف الأشياء بالصدفة مرة أخرى

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

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

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