إن القول بأن الموقع يجب أن يكون دائمًا يمكن الوصول إليه يعد سلوكًا سيئًا ومبتذلاً ، ولكن إمكانية الوصول بنسبة 100 ٪ ، على الرغم من أنه شرط مسبق ، لا تزال في الغالب مثالية لا يمكن الوصول إليها. الآن في السوق ، هناك الكثير من الحلول التي تعد بأقصى وقت للتشغيل أو تقدم حلولًا لزيادة ذلك ، ولكن تطبيقها ليس فقط ليس مفيدًا دائمًا ، وفي بعض الحالات يمكن أن يؤدي إلى زيادة المخاطر وتقليل توفر المشروع. في هذه المقالة ، سنستعرض الأخطاء الكلاسيكية التي نواجهها باستمرار. معظم المشاكل أولية ، لكن الناس يسمحون بها مرارًا وتكرارًا.
مقدمة ضرورية: قبل محاولة ضمان أقصى وقت تشغيل للمشروع ، يجب عليك ربط التكاليف وتكلفة التوقف. عادة ، هذا مهم جدًا للشركات التي يعتمد عملها على عمل الشركات الأخرى - حلول B2B وخدمات API وخدمات التوصيل. سيؤدي عدم إمكانية الوصول حتى لبضع دقائق ، على الأقل إلى التحميل على مركز الاتصال من العملاء غير الراضين. بالنسبة للشركات من نوع آخر ، على سبيل المثال ، متجر صغير عبر الإنترنت ، أو شركة يعمل عملاؤها من 9 إلى 18 ، يمكن أن تكون إمكانية الوصول حتى لعدة ساعات أرخص من موقع النسخ الاحتياطي الكامل.
1. توطين المشروع بأكمله في مركز بيانات واحد / منطقة واحدة لاستضافة السحابة
لقد قام تسويق الاستضافة السحابية بإصلاح المفهوم الخاطئ بشكل راسخ في رؤوس الأشخاص: الاستضافة السحابية ليست مرتبطة بالأجهزة وهذا يعني أن البنية التحتية السحابية لن تسقط. أظهرت ثلاث أعطال على مدار 24 ساعة في Amazon Web Services ، وأحدث تعطل cloud4y ، وفقدان بيانات cloudmouse أن توطين البيانات والمشروع نفسه في مركز بيانات واحد هو طريقة مضمونة للحصول على ساعات طويلة من التوقف دون القدرة على رفع المشروع بسهولة إلى موقع آخر. يخلق قانون البيانات الشخصية ، في هذا الصدد ، مشاكل إضافية. نحن نعتقد أن أي استضافة سحابية يجب أن تمر بالعديد من الحوادث الكبرى من أجل معرفة كيفية منعها (البرق الذي يضرب أمازون ، مشاكل تكوين الشبكة المتعلقة بالعامل البشري ، إلخ) ، وإذا مرت الاستضافة السحابية الغربية بهذه السلسلة من الكوارث ، ثم العديد من المواقع الروسية لم تفعل ذلك بعد ، ويجب أخذ ذلك في الاعتبار.
الوضع هو نفسه تقريبا مع مراكز البيانات "الحديد". غالبًا ما نرى تهيئة العميل ، حيث يتم حجز العديد من الخوادم في موقع واحد ، في حالة فشل أحدها ، ومع ذلك ، في تجربتنا ، هناك مشاكل في الشبكة عندما يتعذر الوصول إلى العديد من الرفوف في مركز بيانات واحد أو مركز البيانات بأكمله ككل يحدث في كثير من الأحيان أكثر من تعطل الخادم الواحد ، ويجب أيضًا أن يؤخذ هذا في الاعتبار.
يتضمن سير عمل المشروع الموصى به من قبل AWS استخدام مناطق توفر افتراضية متعددة لتحقيق أقصى وقت تشغيل للمشروع.
2. عدم وجود ازدواجية كافية في موقع المحمية
لذلك ، توصلنا إلى استنتاج عادي حول الحاجة إلى وجود موقع احتياطي لتحقيق أقصى وقت تشغيل للمشروع ، ومع ذلك ، من أجل التحول إليه ، يجب أن تكون البيانات كافية لموقع الإنتاج. الشيء المهم هنا ليس الإنشاء الأولي للاحتياطي - هذا إجراء بسيط ومفهوم إلى حد ما ، ومزامنة ومراقبة مزامنة المزيد من التغييرات أكثر أهمية. بادئ ذي بدء ، نحن نتحدث عن:
- تكوين الكتلة / مزامنة البيانات في الكتلة عندما نتحدث عن موقع معقد
- تزامن بنية الملف ومراقبة تأخر المزامنة
- تتبع التغييرات في تكوين الخادم
- تصحيح أخطاء عمليات المراقبة والإضافة إلى تزامن المشاريع / الخدمات الجديدة على الموقع.
- تتبع إضافة خدمات ثانوية جديدة (طوابير جديدة ، وآليات معالجة وتفاعلات ، وما إلى ذلك).
- المراقبة المستمرة الكافية لجميع هذه العمليات.
3. عدم وجود خطة تحويل والتحول المنتظم إلى موقع النسخ الاحتياطي
أي ، حتى أفضل مراقبة ، لا يمكن أن تضمن أن يكون موقع النسخ الاحتياطي جاهزًا للتبديل عند الحاجة إليه حقًا. من تجربتنا ، سيحدث حادث عند التبديل الأول إلى الاحتياطي ، وسيحدث هذا عدة مرات. في تقاريرهم ، يقول Stack Overflow أنه استغرق منهم حوالي خمسة تحويلات إلى الاحتياطي ، قبل أن يقتنعوا أنه أصبح الآن جاهزًا تمامًا لقبول حركة المرور بعد الحادث. لذلك ، في خطة العمل لزيادة وقت تشغيل المشروع ، من الضروري تضمين مفاتيح الاختبار إلى الاحتياطي ، ومراعاة أن مثل هذه التبديل سيؤدي إلى وقوع حادث. بعد العمل وإصلاح آلية التبديل في الوثائق ، تحتاج إلى الاستمرار في التبديل بانتظام إلى الاحتياطي للتأكد من أن كل شيء لا يزال يعمل.
4. توطين موقع الحجز على نفس القناة / في نفس منطقة السحابة
إذا كانت مواقع الإنتاج والاحتياطيات ضمن نفس الشركة المضيفة ، فمن المحتمل تمامًا أنه في حالة وقوع حادث سيتوقف كلا الموقعين عن العمل على الفور. أثرت العديد من الحوادث الكبرى في AWS على الفور على جميع مناطق التوفر في منطقة واحدة ، سقطت Selectel في نفس الوقت الذي وقعت فيه مراكز البيانات في سانت بطرسبرغ وموسكو ، يمكن للشركات التحدث عن العزلة الكاملة ، ولكن الحادث cloud4y ، الذي أدى إلى عدم إمكانية الوصول الكامل إلى Bitrix24 يشير إلى أنه حتى في مثل هذه الحالات هناك مخاطر كبيرة. المثالية ، من وجهة نظرنا ، هي التكوين حيث يوجد تكوين احتياطي واحد في نفس شركة الاستضافة (لاستخدام الوسائل العادية للتبديل إلى احتياطي ، مثل VRRP ) ، ومنصة احتياطية ثانوية في شركة استضافة أخرى.
5. وضع نسخ متطابقة على المواقع الرئيسية والمحمية.
حتى استخدام موقع احتياطي تم التحقق منه واستخدام موقع ثانوي في مركز بيانات آخر لا يضمن جاهزية الاحتياطي للاستيلاء بسرعة على حمل الإنتاج. ويرجع ذلك إلى جوهر التكرار: سيؤدي إصدار جديد من التعليمات البرمجية التي أدت إلى حمل فادح في بيئة الإنتاج إلى إنشاء نفس الحمل بالضبط على موقع النسخ الاحتياطي ، وسيتعذر الوصول إلى المشروع تمامًا. كحل بسيط ، يجب أن تكون هناك آلية للتراجع إلى الإصدار السابق ، ومع ذلك ، في سباق الأعمال للإصدارات ، هذا غير ممكن دائمًا ، ثم نبدأ في التفكير في موقع نسخ احتياطي آخر مع الإصدار السابق. يجب أن نتحدث أيضًا عن النسخ الاحتياطية : الحذف العرضي للبيانات على الموقع الرئيسي سيؤثر أيضًا على موقع النسخ الاحتياطي ، لذلك يجب أن تفكر في النسخ المتماثل المتأخر (لمدة 15 دقيقة في الساعة) حتى تتمكن من التبديل إلى قاعدة بيانات لم تحدث بعد عملية قاتلة.
6. الاعتماد على الخدمات الخارجية التي يحصل عليها المشروع.
لكن هذا لا يكفي. يستخدم عدد كبير من المشاريع الآن خدمات خارجية لتقديم خدماتها الخاصة. يستخدم معظم الأشخاص الرسائل القصيرة للمصادقة المزدوجة ، وتحسب المتاجر عبر الإنترنت أوقات التسليم باستخدام خدمات التسليم ، ويتم قبول الدفع من خلال بوابات الدفع التابعة لجهات خارجية ، وإذا سقطت هذه الخدمات ، فلا يهم إذا كان هناك حجز أم لا ، فسيظل المشروع غير متاح. نادرًا ما نرى حجز خدمات خارجية ، ولكن ، في غضون ذلك ، هذه هي بالضبط نفس المشاريع التي قد تواجه مشاكل في موقع الحجز ، أو قد لا يكون هناك احتياطي على الإطلاق. وإذا كانت الخدمة الخارجية غير متوفرة ، فستكون خدمة عملائك مستحيلة أيضًا. نوصي بأن تقوم بتكرار جميع الأنظمة الخارجية المهمة ، ومراقبة توفرها وأن يكون لديك خطة لتبديلها في حالة وقوع حادث.
هذا بعيد كل البعد عن الأشياء الأساسية على الأقل. نناقش هذا بمزيد من التفاصيل في اجتماعات uptime.community ، سيكون الاجتماع التالي في أكتوبر ، ولكن في الوقت الحالي يمكنك الدردشة في مجموعة البرقية .