في فصل الصيف، ينخفض نشاط الشراء وكثافة التغييرات في البنية التحتية لمشاريع الويب بشكل تقليدي، كما يخبرنا Captain Obvious. ببساطة لأنه حتى متخصصي تكنولوجيا المعلومات يذهبون في بعض الأحيان في إجازة. و CTO أيضًا. يصبح الأمر أكثر صعوبة بالنسبة لأولئك الذين يظلون في مناصبهم، لكن هذا ليس هو الهدف الآن: ربما هذا هو السبب في أن الصيف هو أفضل فترة للتفكير ببطء في مخطط الحجز الحالي ووضع خطة لتحسينه. وتجربة إيجور أندريف من والذي تحدث عنه في المؤتمر .
هناك العديد من المخاطر التي يمكن أن تقع فيها عند إنشاء مواقع النسخ الاحتياطي. ومن المستحيل تمامًا الوقوع فيها. وما يفسدنا في كل هذا، كما في أشياء أخرى كثيرة، هو الكمالية و... الكسل. نحن نحاول أن نفعل كل شيء، كل شيء، كل شيء على أكمل وجه، لكننا لسنا بحاجة إلى القيام بذلك على أكمل وجه! ما عليك سوى القيام بأشياء معينة، ولكن القيام بها بشكل صحيح، وإكمالها حتى تعمل بشكل صحيح.
تجاوز الفشل ليس شيئًا ممتعًا وممتعًا "فليكن"؛ هذا شيء يجب أن يفعل شيئًا واحدًا بالضبط - تقليل وقت التوقف عن العمل حتى تخسر الخدمة، الشركة، أموالًا أقل. وفي كل أساليب الحجز أقترح التفكير في السياق التالي: أين المال؟
الفخ الأول: عندما نبني أنظمة كبيرة وموثوقة ونقوم بالتكرار، فإننا نقلل من عدد الحوادث. هذه فكرة خاطئة رهيبة. عندما ننخرط في التكرار، فمن المرجح أن نزيد عدد الحوادث. وإذا فعلنا كل شيء بشكل صحيح، فسنقوم بشكل جماعي بتقليل وقت التوقف عن العمل. سيكون هناك المزيد من الحوادث، لكنها ستحدث بتكاليف أقل. ما هو الحجز؟ - وهذا من تعقيد النظام. أي تعقيد أمر سيء: لدينا المزيد من التروس، والمزيد من التروس، في كلمة واحدة، المزيد من العناصر - وبالتالي، فرصة أكبر للانهيار. وسوف ينكسرون حقًا. وسوف ينكسرون في كثير من الأحيان. مثال بسيط: لنفترض أن لدينا موقع ويب يحتوي على PHP وMySQL. ويجب حجزها بشكل عاجل.
Shtosh (ج) نأخذ الموقع الثاني، ونبني نظامًا متطابقًا... يصبح التعقيد أكبر مرتين - لدينا كيانان. نقوم أيضًا بطرح منطق معين لنقل البيانات من موقع إلى آخر - أي تكرار البيانات، ونسخ البيانات الثابتة، وما إلى ذلك. لذلك، فإن منطق النسخ المتماثل عادة ما يكون معقدا للغاية، وبالتالي، فإن التعقيد الإجمالي للنظام لا يمكن أن يكون 2، ولكن 3، 5، 10 مرات أكبر.
الفخ الثاني: عندما نبني أنظمة معقدة وكبيرة حقًا، فإننا نتخيل ما نريد أن نحصل عليه في النهاية. Voila: نريد الحصول على نظام فائق الموثوقية يعمل دون أي توقف، ويتحول خلال نصف ثانية (أو الأفضل من ذلك، على الفور)، ونبدأ في تحقيق الأحلام. ولكن هناك أيضًا فارق بسيط: كلما كان وقت التبديل المطلوب أقصر، أصبح منطق النظام أكثر تعقيدًا. كلما كان علينا أن نجعل هذا المنطق أكثر تعقيدًا، كلما انهار النظام في كثير من الأحيان. ويمكن أن ينتهي بك الأمر في موقف مزعج للغاية: نحن نحاول بكل قوتنا تقليل وقت التوقف عن العمل، ولكن في الواقع نحن نجعل كل شيء أكثر تعقيدًا، وعندما يحدث خطأ ما، سيصبح وقت التوقف أطول في النهاية. هنا غالبًا ما تجد نفسك تفكر: حسنًا... سيكون من الأفضل عدم إجراء حجز. سيكون من الأفضل أن تعمل بمفردها ومع فترة توقف مفهومة.
كيف يمكنك محاربة هذا؟ نحن بحاجة إلى التوقف عن الكذب على أنفسنا، والتوقف عن تملق أنفسنا بأننا سنقوم ببناء سفينة فضائية هنا الآن، ولكن يجب أن نفهم بشكل كافٍ إلى متى يمكن أن يكذب المشروع. وفي هذا الوقت الأقصى، سنختار الأساليب التي سنستخدمها بالفعل لزيادة موثوقية نظامنا.
لقد حان الوقت لـ "قصص من W"... من الحياة بالطبع.
المثال رقم واحد
تخيل موقعًا إلكترونيًا لبطاقة العمل لمصنع لف الأنابيب رقم 1 في مدينة ن. مكتوب بأحرف كبيرة - مصنع لف الأنابيب رقم 1. يوجد أدناه الشعار: "أنابيبنا هي الأنابيب الأكثر استدارة في N." وفيما يلي رقم هاتف الرئيس التنفيذي واسمه. نحن نتفهم أنك بحاجة إلى إجراء حجز - وهذا أمر مهم جدًا! لنبدأ في معرفة ما يتكون منه. Html-statics - أي صورتان حيث يناقش المدير العام، في الواقع، نوعًا من الصفقة التالية على الطاولة في الحمام مع شريكه. نبدأ في التفكير في التوقف. يتبادر إلى الذهن: تحتاج إلى الاستلقاء هناك لمدة خمس دقائق، لا أكثر. ثم يطرح السؤال: كم عدد المبيعات التي تمت من موقعنا هذا بشكل عام؟ كم-كم؟ ماذا يعني "صفر"؟ وهذا يعني: لأن الجنرال أجرى جميع المعاملات الأربع في العام الماضي على نفس الطاولة، مع نفس الأشخاص الذين يذهبون معهم إلى الحمام ويجلسون على الطاولة. ونحن نفهم أنه حتى لو كان الموقع يجلس لمدة يوم، فلن يحدث شيء فظيع.
وبناء على المعلومات التمهيدية، هناك يوم لإثارة هذه القصة. لنبدأ بالتفكير في مخطط التكرار. ونحن نختار نظام التكرار الأكثر مثالية لهذا المثال: نحن لا نستخدم التكرار. هذا الأمر برمته يمكن أن يثيره أي مسؤول في نصف ساعة مع فترات استراحة من الدخان. قم بتثبيت خادم ويب وإضافة الملفات - هذا كل شيء. سوف تعمل. لا تحتاج إلى مراقبة أي شيء، ولا تحتاج إلى إيلاء اهتمام خاص لأي شيء. وهذا يعني أن الاستنتاج من المثال الأول واضح تمامًا: الخدمات التي لا تحتاج إلى حجز لا تحتاج إلى حجزها.
المثال رقم اثنين
مدونة الشركة: هناك أشخاص مدربون خصيصًا يكتبون الأخبار، وقد شاركنا في معرض كذا وكذا، لكننا أصدرنا منتجًا جديدًا آخر، وما إلى ذلك. لنفترض أن هذا هو PHP القياسي مع WordPress، وقاعدة بيانات صغيرة وقليل من البيانات الثابتة. بالطبع، يتبادر إلى الذهن مرة أخرى أنه لا ينبغي عليك الاستلقاء تحت أي ظرف من الظروف - "لا تزيد عن خمس دقائق!" هذا كل شيء. لكن دعونا نفكر أكثر. ماذا تفعل هذه المدونة؟ يأتي الأشخاص إلى هناك من Yandex، ومن Google بناءً على بعض الاستفسارات، بشكل عضوي. عظيم. هل المبيعات لها علاقة بالموضوع؟ عيد الغطاس : ليس حقا. تنتقل حركة الإعلانات إلى الموقع الرئيسي، الموجود على جهاز مختلف. لنبدأ بالتفكير في مخطط الحجز. من الجيد أن يتم رفعه في بضع ساعات، وسيكون من الجيد الاستعداد لذلك. سيكون من المعقول أخذ جهاز من مركز بيانات آخر، ووضع البيئة عليه، أي خادم ويب، PHP، وWordPress، وMySQL، وتركه هناك. في الوقت الحالي، عندما ندرك أن كل شيء معطل، نحتاج إلى القيام بأمرين - طرح تفريغ MySQL على بعد 50 مترًا، وسوف يطير إلى هناك في دقيقة واحدة، وطرح عدد معين من الصور من النسخة الاحتياطية هناك. وهذا أيضاً ليس موجوداً، والله أعلم إلى متى. وهكذا يرتفع الأمر برمته خلال نصف ساعة. لا يوجد تكرار، أو سامحني الله، تجاوز الفشل التلقائي. الخلاصة: ما يمكننا طرحه بسرعة من النسخة الاحتياطية لا يحتاج إلى نسخ احتياطي.
المثال رقم ثلاثة، أكثر تعقيدا
متجر على الانترنت. PHP مع القلب المفتوح هو أنب قليلا، الخلية مع قاعدة صلبة. هناك الكثير من الأشياء الثابتة (بعد كل شيء، يحتوي المتجر عبر الإنترنت على صور عالية الدقة جميلة وكل هذه الأشياء)، وRedis للجلسة وElasticsearch للبحث. نبدأ في التفكير في التوقف. وهنا، بالطبع، من الواضح أن المتجر عبر الإنترنت لا يمكنه الاستلقاء دون ألم لمدة يوم. ففي نهاية المطاف، كلما طال أمد الكذب، كلما خسرنا المزيد من المال. الأمر يستحق الإسراع. كم ثمن؟ أعتقد أنه إذا استلقينا لمدة ساعة، فلن يصاب أحد بالجنون. نعم، سنخسر شيئًا ما، لكن إذا بدأنا العمل الجاد، فسوف يزداد الأمر سوءًا. نحدد مخطط التوقف المسموح به في الساعة.
كيف يمكن حجز كل هذا؟ أنت بحاجة إلى سيارة في أي حال: ساعة من الوقت قليلة جدًا. Mysql: هنا نحتاج بالفعل إلى النسخ المتماثل، النسخ المتماثل المباشر، لأنه في غضون ساعة لن تتم إضافة 100 جيجابايت إلى التفريغ. الإحصائيات والصور: مرة أخرى، في غضون ساعة، قد لا يكون هناك وقت لإضافة 500 جيجابايت. لذلك، من الأفضل نسخ الصور على الفور. Redis: هذا هو المكان الذي تصبح فيه الأمور مثيرة للاهتمام. في Redis، يتم تخزين الجلسات - ولا يمكننا أخذها ودفنها. لأن هذا لن يكون جيدًا جدًا: سيتم تسجيل خروج جميع المستخدمين، وسيتم إفراغ سلاتهم، وما إلى ذلك. سيضطر الأشخاص إلى إعادة إدخال اسم المستخدم وكلمة المرور الخاصة بهم، وقد ينفصل العديد من الأشخاص ولا يكملون عملية الشراء. مرة أخرى، سوف تنخفض التحويلات. من ناحية أخرى، يتم تحديث Redis بشكل مباشر، وربما لا تكون هناك حاجة أيضًا إلى آخر المستخدمين الذين قاموا بتسجيل الدخول. والحل الوسط الجيد هو أخذ Redis واستعادته من نسخة احتياطية من الأمس، أو إذا كنت تفعل ذلك كل ساعة، فمن ساعة مضت. ولحسن الحظ، فإن استعادته من نسخة احتياطية يعني نسخ ملف واحد. والقصة الأكثر إثارة للاهتمام هي Elasticsearch. من قام باختيار النسخ المتماثل لـ MySQL؟ من قام باختيار النسخ المتماثل لـ Elasticsearch؟ ولمن عملت بشكل طبيعي بعد ذلك؟ ما أعنيه هو أننا نرى كيانًا معينًا في نظامنا. يبدو أنه مفيد - ولكنه معقد.
معقدة بمعنى أن زملائنا المهندسين ليس لديهم خبرة في العمل معها. أو أن هناك تجربة سلبية. أو نفهم أن هذه لا تزال تقنية جديدة إلى حد ما مع الفروق الدقيقة أو الخام. نعتقد... اللعنة، المرونة أيضًا صحية، وتستغرق أيضًا وقتًا طويلاً لاستعادتها من نسخة احتياطية، فماذا علي أن أفعل؟ نحن نفهم أن المرونة في حالتنا تستخدم للبحث. كيف يبيع متجرنا الإلكتروني؟ نذهب إلى المسوقين ونسأل من أين يأتي الناس بشكل عام. يجيبون: "90٪ من Yandex Market يأتون مباشرة إلى بطاقة المنتج." وإما أن يشتروها أو لا يشترونها. لذلك، يحتاج 10٪ من المستخدمين إلى البحث. والحفاظ على النسخ المرن، وخاصة بين مراكز البيانات المختلفة في مناطق مختلفة، لديه الكثير من الفروق الدقيقة. أي مخرج؟ نحن نأخذ المرونة من موقع محجوز ولا نفعل شيئًا بها. وإذا طال الأمر فمن المحتمل أن نثيره يوما ما، لكن هذا ليس مؤكدا. في الواقع، الاستنتاج هو نفسه، زائد أو ناقص: نحن، مرة أخرى، لا نحتفظ بالخدمات التي لا تؤثر على المال. لإبقاء الرسم التخطيطي أكثر بساطة.
المثال الرابع، أكثر صعوبة
المتكامل: بيع الزهور، استدعاء سيارة أجرة، بيع البضائع، بشكل عام، أي شيء. شيء خطير يعمل على مدار الساعة طوال أيام الأسبوع لعدد كبير من المستخدمين. مع مكدس مثير للاهتمام، حيث توجد قواعد مثيرة للاهتمام، والحلول، والحمل العالي، والأهم من ذلك، من المؤلم الاستلقاء لأكثر من 24 دقائق. ليس فقط وليس كثيرًا لأن الناس لن يشتروا، ولكن لأن الناس سيرون أن هذا الشيء لا يعمل، فسوف ينزعجون وقد لا يعودون على الإطلاق.
نعم. خمس دقائق. ماذا سنفعل حيال هذا؟ في هذه الحالة، نحن، مثل البالغين، نستخدم كل الأموال لبناء موقع نسخ احتياطي حقيقي، مع تكرار كل شيء، وربما حتى التحول تلقائيًا إلى هذا الموقع قدر الإمكان. وبالإضافة إلى ذلك، عليك أن تتذكر القيام بشيء مهم: في الواقع، كتابة لوائح التبديل. يمكن أن تكون اللوائح، حتى لو كان كل شيء لديك آليًا، بسيطة جدًا. من السلسلة "تشغيل كذا وكذا برنامج نصي غير معقول"، "انقر فوق مربع الاختيار كذا وكذا في الطريق 53" وما إلى ذلك - ولكن يجب أن يكون هذا نوعًا من قائمة الإجراءات الدقيقة.
وكل شيء يبدو واضحا. يعد تبديل النسخ المتماثل مهمة تافهة، وإلا فسوف يقوم بالتبديل من تلقاء نفسه. إعادة كتابة اسم المجال في DNS هي من نفس السلسلة. المشكلة هي أنه عندما يفشل مثل هذا المشروع، يبدأ الذعر، وحتى أقوى المسؤولين الملتحين يمكن أن يكونوا عرضة له. بدون تعليمات واضحة "افتح الجهاز، تعال إلى هنا، عنوان الخادم الخاص بنا لا يزال هكذا"، فمن الصعب الالتزام بالحد الزمني المخصص للإنعاش وهو 5 دقائق. حسنًا، بالإضافة إلى ذلك، عندما نستخدم هذه اللوائح، فمن السهل تسجيل بعض التغييرات في البنية التحتية، على سبيل المثال، وتغيير اللوائح وفقًا لذلك.
حسنًا، إذا كان نظام الحجز معقدًا للغاية وفي مرحلة ما ارتكبنا خطأً، فيمكننا تدمير موقع النسخ الاحتياطي الخاص بنا، بالإضافة إلى تحويل البيانات إلى قرع على كلا الموقعين - سيكون هذا أمرًا محزنًا تمامًا.
المثال رقم خمسة، المتشددين كاملة
خدمة دولية تضم مئات الملايين من المستخدمين حول العالم. جميع المناطق الزمنية موجودة، وحمولة عالية بأقصى سرعة، ولا يمكنك الاستلقاء على الإطلاق. دقيقة - وسوف يكون حزينا. ما يجب القيام به؟ احجز مرة أخرى حسب البرنامج الكامل. لقد فعلنا كل ما تحدثت عنه في المثال السابق، وأكثر من ذلك بقليل. عالم مثالي، والبنية التحتية لدينا متوافقة مع جميع مفاهيم مطوري IaaC. وهذا هو، كل شيء في بوابة، وما عليك سوى الضغط على الزر.
ما المفقود؟ واحد - التمارين. إنه مستحيل بدونهم. يبدو أن كل شيء على ما يرام معنا، لدينا عموما كل شيء تحت السيطرة. نضغط على الزر، كل شيء يحدث. وحتى لو كان الأمر كذلك - ونحن ندرك أن الأمر لا يحدث بهذه الطريقة - فإن نظامنا يتفاعل مع بعض الأنظمة الأخرى. على سبيل المثال، هذا نظام أسماء النطاقات من الطريق 53، وتخزين S3، والتكامل مع بعض واجهات برمجة التطبيقات. لن نكون قادرين على التنبؤ بكل شيء في هذه التجربة التأملية. وحتى نسحب المفتاح فعليًا، لن نعرف ما إذا كان سيعمل أم لا.
ربما هذا كل شيء. لا تكن كسولًا أو تبالغ في ذلك. وقد يكون الجهوزية معك!
المصدر: www.habr.com