حتى الآن ، لا تحتوي خدمة Bitrix24 على مئات غيغا بايت من حركة المرور ، لا يوجد أسطول ضخم من الخوادم (على الرغم من وجود الكثير منها ، بالطبع ، الخوادم الموجودة). لكن بالنسبة للعديد من العملاء ، فإنه الأداة الرئيسية للعمل في الشركة ، إنه تطبيق حقيقي مهم للأعمال. لذلك ، السقوط - حسنا ، بأي حال من الأحوال. ولكن ماذا لو حدث السقوط ، لكن الخدمة "تمردت" بسرعة بحيث لم يلاحظ أحد أي شيء؟ وكيف يمكنك إدارة تطبيق تجاوز الفشل دون أن تفقد جودة العمل وعدد العملاء؟ أخبر ألكساندر ديميدوف ، مدير الخدمات السحابية Bitrix24 ، مدونتنا عن كيفية تطور نظام النسخ الاحتياطي على مدار 7 سنوات من وجود المنتج.
"في شكل SaaS ، أطلقنا Bitrix24 منذ 7 سنوات. ربما كانت الصعوبة الرئيسية هي ما يلي: قبل إطلاقه على الملأ في شكل SaaS ، كان هذا المنتج موجودًا ببساطة في شكل حل محاصر. اشترى العملاء منا ، ووضعوه على خوادمهم ، وإنشاء بوابة للشركات - وهو حل مشترك للاتصال الموظف ، وتخزين الملفات ، وإدارة المهام ، CRM ، هذا كل شيء. وبحلول عام 2012 ، قررنا أننا أردنا إطلاقه كخدمة SaaS ، وإدارتها بأنفسنا ، وتوفير التسامح مع الخطأ والموثوقية. لقد اكتسبنا خبرة في هذه العملية ، لأنه حتى ذلك الحين لم نكن نملكها - كنا مصنعي البرمجيات فقط ، وليس موردي الخدمات.
عند بدء تشغيل الخدمة ، أدركنا أن أهم شيء هو ضمان التسامح مع الخطأ وموثوقيته وتوافره المستمر ، لأنه إذا كان لديك موقع ويب عادي بسيط ، ومتجر ، على سبيل المثال ، وقد انخفض عنك ويكذب ساعة - أنت وحدك تعاني ، تفقد الطلبات ، تفقد العملاء ، ولكن بالنسبة للعميل نفسه - بالنسبة له هذا ليس بالغ الأهمية. كان مستاءً بالطبع ، لكنه ذهب واشترى من موقع آخر. وإذا كان هذا تطبيقًا يعمل جميعًا داخل الشركة ، والاتصالات ، والحلول مرتبطة به ، فإن الشيء الأكثر أهمية هو كسب ثقة المستخدمين ، أي عدم التراجع عنها وعدم السقوط. لأن كل العمل يمكن أن يستيقظ إذا كان هناك شيء في الداخل لا يعمل.
بيتريكس 24 كما ادارة العلاقات مع
النموذج الأولي الأول الذي جمعناه قبل عام من الإطلاق العام ، في عام 2011. تجمع في حوالي أسبوع ، بدا ، الملتوية - كان يعمل حتى. وهذا يعني أنه كان من الممكن الدخول إلى النموذج ، وإدخال اسم البوابة هناك ، وكانت بوابة جديدة تتكشف ، ويجري إعداد قاعدة مستخدمين. نظرنا فيه ، وقمنا بتقييم المنتج من حيث المبدأ ، وقمنا بإيقاف تشغيله ، ووضعنا اللمسات الأخيرة عليه بعد عام. نظرًا لأن لدينا مهمة كبيرة: لم نكن نريد إنشاء قاعدتين رمزيتين مختلفتين ، لم نكن نريد دعم منتج منفصل محاصر ، حلول سحابية منفصلة - أردنا القيام بكل هذا ضمن نفس الكود.
أحد تطبيقات الويب النموذجية في ذلك الوقت هو خادم واحد يتم تشغيل بعض رموز php عليه ، وقاعدة mysql ، ويتم تنزيل الملفات ، ويتم وضع المستندات والصور في daddy - حسنًا ، كل هذا يعمل. للأسف ، من المستحيل تشغيل خدمة ويب مستدامة بشكل حاسم في هذا الصدد. ذاكرة التخزين المؤقت الموزعة غير مدعومة هناك ، النسخ المتماثل لقاعدة البيانات غير معتمد.
قمنا بصياغة المتطلبات: هذه القدرة على أن تكون موجودة في مواقع مختلفة ، لدعم النسخ المتماثل ، من الناحية المثالية أن تكون موجودة في مختلف مراكز البيانات الموزعة جغرافيا. افصل منطق المنتج ، وفي الواقع ، تخزين البيانات. ديناميكي تكون قادرة على القياس وفقا للحمل ، وجعل عموما احصائيات. من هذه الاعتبارات ، في الواقع ، كانت هناك متطلبات للمنتج ، والتي قمنا بتطويرها للتو خلال العام. خلال هذا الوقت ، في منصة اتضح أنها موحدة - للحلول المعبأة ، لخدمتنا - قدمنا الدعم لتلك الأشياء التي نحتاجها. دعم النسخ المتماثل mysql على مستوى المنتج نفسه: أي أن المطور الذي يكتب الكود لا يفكر في كيفية توزيع طلباته ، ويستخدم api ، ويمكننا توزيع طلبات الكتابة والقراءة بشكل صحيح بين الأسياد والعبيد.
لقد قدمنا دعمًا على مستوى المنتج للعديد من متاجر الكائنات السحابية: تخزين google ، و amazon s3 ، - بالإضافة إلى دعم دعم المكدس المفتوح. لذلك ، كانت ملائمة لنا كخدمة وللمطورين الذين يعملون مع حل محاصر: إذا استخدموا api فقط للعمل ، فلا يفكرون في مكان حفظ الملف ، سواء محليًا على نظام الملفات أو في تخزين ملفات الكائنات .
نتيجة لذلك ، قررنا على الفور أننا نحتفظ على مستوى مركز بيانات بأكمله. في عام 2012 ، أطلقنا بشكل كامل في Amazon AWS ، لأن لدينا بالفعل تجربة مع هذه المنصة - تم استضافة موقعنا على الإنترنت هناك. لقد انجذبتنا إلى حقيقة أن هناك العديد من مناطق الوصول في كل منطقة في منطقة الأمازون - في الواقع ، في مصطلحاتها ، العديد من مراكز البيانات مستقلة إلى حد ما عن بعضها البعض وتسمح لنا بالحجز على مستوى مركز بيانات كامل: إذا فشل بشكل مفاجئ ، يتم نسخ قواعد البيانات الرئيسية - الرئيسية ، وخوادم تطبيقات الويب محجوزة ، ويتم نقل الثابت إلى تخزين كائن s3. الحمولة متوازنة - في ذلك الوقت من الأمازون ، ولكن بعد فترة وجيزة وصلنا إلى موازيننا الخاصة ، لأننا كنا بحاجة إلى منطق أكثر تعقيدًا.
ما أرادوه ، فهم حصلوا عليه ...
كل الأشياء الأساسية التي أردنا تقديمها - التسامح مع الخوادم نفسها وتطبيقات الويب وقواعد البيانات - عملت كل شيء جيدًا. أبسط سيناريو: إذا فشلت بعض تطبيقات الويب ، فسيكون كل شيء بسيطًا - يتم إيقافها عن الرصيد.
إن موازن الماكينة (الذي كان آنذاك من منطقة الأمازون) هو الذي عطل الجهاز نفسه الذي وضع علامة غير صحية ، وأوقف تشغيل توزيع الحمل عليها. نجحت الأمازون autoscaling: عندما زاد الحمل ، أضيفت سيارات جديدة إلى مجموعة autoscaling ، تم توزيع الحمل على السيارات الجديدة - كل شيء على ما يرام. من خلال موازناتنا ، يكون المنطق متماثلًا تقريبًا: إذا حدث شيء ما لخادم التطبيقات ، فإننا نزيل الطلبات منه ونطرد هذه الأجهزة ونبدأ تشغيلها ونواصل العمل. لقد تغير المخطط الخاص بكل هذه السنوات قليلاً ، لكنه مستمر في العمل: إنه بسيط ومفهوم ولا توجد أي صعوبات في ذلك.
نحن نعمل في جميع أنحاء العالم ، والحمل الأقصى للعملاء مختلف تمامًا ، وبطريقة جيدة ، يجب أن نكون قادرين على القيام بأعمال صيانة معينة مع أي من مكونات نظامنا في أي وقت - بشكل غير مرئي للعملاء. لذلك ، لدينا الفرصة لإغلاق قاعدة البيانات من العمل ، وإعادة توزيع الحمل على مركز البيانات الثاني.
كيف يعمل كل شيء؟ - نقوم بتحويل حركة المرور إلى مركز بيانات عامل - إذا كان ذلك حادثًا في مركز البيانات ، فعندئذ يكون تمامًا ، إذا كان هذا هو العمل المخطط لنا مع أي قاعدة واحدة ، فإننا جزءًا من حركة المرور التي تخدم هؤلاء العملاء ، ننتقل إلى مركز البيانات الثاني ، يتوقف النسخ المتماثل. إذا كنت بحاجة إلى أجهزة جديدة لتطبيقات الويب ، فكلما زاد الحمل على مركز البيانات الثاني ، يبدأ تشغيله تلقائيًا. ننتهي من العمل ، تتم استعادة النسخ المتماثل ، ونعيد التحميل بالكامل مرة أخرى. إذا كنا بحاجة إلى عكس بعض الأعمال في العاصمة الثانية ، على سبيل المثال ، تثبيت تحديثات النظام أو تغيير الإعدادات في قاعدة البيانات الثانية ، ثم ، بشكل عام ، نكرر نفس الشيء ، فقط في الاتجاه الآخر. وإذا كان هذا حادثًا ، فسنقوم بكل شيء في صورة مبتذلة: في نظام المراقبة ، نستخدم آلية معالجات الأحداث. إذا نجحت العديد من الفحوصات بالنسبة إلينا وأصبحت الحالة حرجة ، فسيتم تشغيل هذا المعالج ، وهو معالج يمكنه تنفيذ هذا المنطق أو ذاك. لكل قاعدة بيانات ، سجلنا أي خادم هو الفشل لذلك ، وحيث تحتاج إلى تبديل حركة المرور إذا كان غير متوفر. نحن - كما طورنا تاريخيا - نستخدمه بشكل أو بآخر nagios أو أي من شوكاته. من حيث المبدأ ، توجد آليات مماثلة في أي نظام مراقبة تقريبًا ، فنحن لا نستخدم شيئًا أكثر تعقيدًا حتى الآن ، لكن ربما نستخدمه في يوم من الأيام. الآن يتم تشغيل المراقبة بسبب عدم إمكانية الوصول ولديه القدرة على تبديل شيء ما.
هل حجزنا كل شيء؟
لدينا العديد من العملاء من الولايات المتحدة الأمريكية ، والعديد من العملاء من أوروبا ، والعديد من العملاء الأقرب إلى الشرق - اليابان وسنغافورة وما إلى ذلك. بالطبع ، نسبة كبيرة من العملاء في روسيا. أي أن العمل بعيد عن أن يكون في منطقة واحدة. يريد المستخدمون استجابة سريعة ، وهناك متطلبات لمراقبة القوانين المحلية المختلفة ، وفي كل منطقة نحتفظ بمركزين للبيانات ، بالإضافة إلى بعض الخدمات الإضافية التي ، مرة أخرى ، ملائمة لوضعها داخل منطقة واحدة - للعملاء الموجودين في هذه المنطقة عمل المنطقة. REST معالجات وخوادم التخويل ، فهي أقل أهمية بالنسبة للعميل ككل ، يمكنك التبديل بينها مع تأخير صغير مقبول ، لكنك لا ترغب في اختراع الدراجات ، وكيفية مراقبتها وماذا تفعل بها. لذلك ، إلى أقصى حد نحاول استخدام الحلول الحالية ، وليس لتطوير بعض الكفاءة في منتجات إضافية. وفي مكان ما ، نستخدم التبديل على مستوى نظام أسماء النطاقات بشكل تافه ، ونحدد مدى حيوية الخدمة بنفس نظام أسماء النطاقات. لدى Amazon خدمة Route 53 ، ولكنها ليست مجرد نظام أسماء النطاقات الذي يمكنك تسجيل كل شيء فيه ، إنها أكثر مرونة وسهولة. من خلاله ، يمكنك إنشاء خدمات موزعة جغرافيًا باستخدام عمليات تحديد الموقع الجغرافي ، عند استخدامها لتحديد من أين أتى العميل ومنحهم سجلات معينة - باستخدامه يمكنك إنشاء تصميمات تجاوز الفشل. يتم تكوين نفس الفحوصات الصحية في Route 53 نفسه ، ويمكنك تحديد نقاط النهاية التي تتم مراقبتها وتعيين المقاييس وتحديد البروتوكولات التي تحدد مدى فاعلية الخدمة - tcp و http و https؛ ضبط تكرار الشيكات التي تحدد ما إذا كانت الخدمة حية أم لا. وفي نظام أسماء النطاقات نفسه ، أنت تصف ما سيكون أساسيًا ، وما سيكون ثانويًا ، حيث يمكنك التبديل إذا تم تشغيل الفحص الصحي الداخلي في المسار 53. كل هذا يمكن القيام به مع بعض الأدوات الأخرى ، ولكن ما هو أكثر ملاءمة - بمجرد التهيئة ثم لا نفكر في كيف نفعل الشيكات ، وكيف نتحول: كل شيء يعمل من تلقاء نفسه.
أول "لكن" : كيف وكيف نحتفظ بالطريق 53 نفسه؟ هل يحدث إذا حدث شيء له؟ لحسن الحظ ، لم نخطو مطلقًا في هذا أشعل النار ، ولكن مرة أخرى ، أمامي ، سأحصل على قصة لماذا اعتقدنا أننا ما زلنا بحاجة إلى الحجز. نحن هنا نضع القشة مقدما. عدة مرات في اليوم نقوم بالتفريغ الكامل لجميع المناطق التي لدينا في الطريق 53. تتيح لك واجهة برمجة تطبيقات Amazon من إرسالها بأمان إلى JSON ، وقمنا برفع العديد من الخوادم الزائدة حيث نقوم بتحويلها ، وتحميلها في شكل تهيئة ، وبصورة تقريبية ، لدينا تكوين نسخ احتياطي. في هذه الحالة ، يمكننا نشرها يدويًا بسرعة ، ولن نفقد بيانات إعدادات نظام أسماء النطاقات.
الثاني "لكن" : ما هو غير محجوز في هذه الصورة؟ الموازن نفسه! لقد جعلنا توزيع العملاء حسب المنطقة بسيطًا جدًا. لدينا bitrix24.ru ، bitrix24.com ، .de نطاقات - الآن هناك 13 نطاقات مختلفة تعمل في مناطق مختلفة للغاية. لقد توصلنا إلى ما يلي: لكل منطقة موازناتها الخاصة. من الأسهل التوزيع حسب المنطقة ، اعتمادًا على مكان الحمل الأقصى على الشبكة. إذا كان هذا هو الفشل على مستوى أي موازن واحد ، فإنه يتم ببساطة إيقاف تشغيله وإزالته من نظام أسماء النطاقات. في حالة حدوث مشكلة مع مجموعة من الموازنات ، يتم حجزها في مواقع أخرى ، ويتم التبديل بينها باستخدام نفس المسار 53 ، لأنه بسبب فترة قصيرة ttl ، يحدث التبديل لمدة أقصاها 2 ، 3 ، 5 دقائق.
الثالث "لكن" : ما الذي لم يتم حجزه بعد؟ S3 ، صحيح. نحن ، بوضع الملفات التي يتم تخزينها من قبل المستخدمين في S3 ، نعتقد بصدق أنه كان خارقة للدروع وليس هناك حاجة لحجز أي شيء هناك. لكن التاريخ يظهر ما يحدث بشكل مختلف. بشكل عام ، تصف Amazon S3 على أنها خدمة أساسية ، لأن Amazon نفسها تستخدم S3 لتخزين صور الأجهزة والتكوينات وصور AMI واللقطات ... وإذا تعطلت s3 ، كما حدث مرة واحدة في هذه السنوات السبع ، وكمية bitrix24 التي نستخدمها ، تتبعها مروحة تسحب مجموعة من كل شيء - عدم إمكانية بدء تشغيل الأجهزة الظاهرية ، وتعطل واجهة برمجة التطبيقات ، وهلم جرا.
و S3 يمكن أن تسقط - لقد حدث مرة واحدة. لذلك ، توصلنا إلى المخطط التالي: قبل بضع سنوات ، لم تكن هناك مستودعات عامة للكائنات الخطيرة في روسيا ، وكنا نفكر في خيار القيام بشيء خاص بنا ... لحسن الحظ ، لم نبدأ في القيام بذلك ، لأننا سنبحث في هذا الفحص الذي لم نقم به تمتلك ، وربما فعلت ذلك. الآن Mail.ru لديها مخازن متوافقة مع s3 ، Yandex لديها ، وعدد من مقدمي لا يزال لديهم. ونتيجة لذلك ، توصلنا إلى استنتاج مفاده أننا نريد ، أولاً ، التكرار ، وثانياً ، القدرة على العمل مع النسخ المحلية. بالنسبة لمنطقة روسية معينة ، نستخدم خدمة Mail.ru Hotbox ، والتي تتوافق مع s3. لم نكن بحاجة إلى أي تعديلات خطيرة على الكود داخل التطبيق ، وقمنا بالآلية التالية: في s3 هناك مشغلات تعمل على إنشاء / حذف كائنات ، أمازون لديها خدمة مثل Lambda - هذا هو رمز تشغيل بدون خادم سيتم تنفيذه فقط عندما يتم تشغيل بعض المشغلات.
لقد فعلنا ذلك بكل بساطة: إذا وقع المشغل لدينا ، فسنقوم بتنفيذ التعليمات البرمجية التي ستنسخ الكائن إلى مستودع Mail.ru. لبدء العمل بشكل كامل مع النسخ المحلية من البيانات ، نحتاج أيضًا إلى المزامنة العكسية ، بحيث يمكن للعملاء الموجودين في الجزء الروسي العمل على تخزين أقرب منهم. Mail على وشك إكمال المشغلات في المستودع الخاص به - سيكون من الممكن إجراء التزامن العكسي بالفعل على مستوى البنية التحتية ، لكننا الآن نقوم بذلك على مستوى الكود الخاص بنا. إذا رأينا أن العميل قد وضع نوعًا من الملفات ، فعندئذٍ على مستوى الكود لدينا نضع الحدث في قائمة الانتظار ، ونقوم بمعالجته ونقوم بالنسخ المتماثل العكسي. لماذا هو سيء: إذا كان لدينا نوع من العمل مع كائناتنا خارج منتجنا ، وهذا يعني ، من خلال بعض الوسائل الخارجية ، أننا لن نأخذ ذلك في الاعتبار. لذلك ، ننتظر حتى النهاية عندما تظهر المشغلات على مستوى التخزين بحيث لا يتم نسخ الكائن الذي جاء إلينا بصرف النظر عن مكان تشغيل الرمز.
على مستوى الرمز ، لكل عميل ، يتم تسجيل كل المستودعات: واحد يعتبر الرئيسي ، والآخر هو النسخ الاحتياطي. إذا كان كل شيء على ما يرام ، فنحن نعمل مع وحدة التخزين الأقرب إلينا: أي ، عملائنا الموجودين في Amazon ، يعملون مع S3 ، والذين يعملون في روسيا ، يعملون مع Hotbox. إذا كانت خانة الاختيار تعمل ، فيجب أن يتصل الفشل بعد ذلك ، وسنتحول العملاء إلى وحدة تخزين أخرى. يمكننا ضبط هذه العلامة بشكل مستقل حسب المنطقة ويمكننا تبديلها جيئة وذهابا. في الممارسة العملية ، لم نستخدم هذا بعد ، لكننا تصورنا هذه الآلية ونعتقد أننا سنحتاج في يوم من الأيام إلى هذا المفتاح ونستخدمه. بمجرد أن حدث بالفعل.
أوه ، وهرب الأمازون الخاص بك ...
يصادف شهر أبريل هذا العام ذكرى بدء أقفال Telegram في روسيا. المزود الأكثر تضررا الذي جاء تحت هذا هو الأمازون. ولسوء الحظ ، عانت الشركات الروسية التي عملت في جميع أنحاء العالم أكثر.
إذا كانت الشركة عالمية وروسيا لأنها جزء صغير للغاية ، 3-5 ٪ - حسنا ، بطريقة أو بأخرى ، يمكنك التبرع بها.
إذا كانت هذه شركة روسية بحتة - أنا متأكد من أنك بحاجة إلى تحديد موقع محلي - جيدًا ، فمن الجيد أن المستخدمين أنفسهم سيكونون مريحين ومريحين ، وستكون هناك مخاطر أقل.
وإذا كانت هذه شركة تعمل على مستوى العالم ، ولديها حصص متساوية تقريبًا من العملاء من روسيا ومن أي مكان في العالم؟ إن اتصال القطاعات مهم ، ويجب أن تعمل مع بعضها البعض على أي حال.
في نهاية مارس 2018 ، أرسل Roskomnadzor رسالة إلى أكبر المشغلين تفيد بأنهم يخططون لحظر عدة ملايين من الأمازون للملكية الفكرية من أجل منع ... رسول Zello. بفضل هؤلاء الموفرين - قاموا بتسريب الرسالة بنجاح إلى الجميع ، وكان هناك فهم بأن الاتصال مع Amazon قد ينهار. كان يوم الجمعة ، ركضنا إلى الزملاء من servers.ru في حالة من الذعر ، بعبارة: "الأصدقاء ، نحن بحاجة إلى العديد من الخوادم التي لن تكون في روسيا ، وليس في Amazon ، ولكن ، على سبيل المثال ، في مكان ما في أمستردام ،" من أجل أن نكون قادرين على الأقل ، بطريقة ما ، على وضع الشبكات الافتراضية الخاصة الخاصة بنا والوكيل الخاصين بنا في بعض نقاط النهاية التي لا يمكننا التأثير على الإطلاق ، على سبيل المثال الخطوط الطرفية من نفس s3 - لا يمكننا محاولة رفع خدمة جديدة والحصول على عنوان IP آخر ، ما زلت بحاجة للوصول إلى هناك. في غضون أيام قليلة ، قمنا بإعداد هذه الخوادم ، وقمنا برفعها ، وبشكل عام ، معدة لبدء الأقفال. من الغريب أن ILV ، الذي ينظر إلى الضجة والفزع المثار ، قال: "لا ، لن نمنع أي شيء الآن". (ولكن هذا هو بالضبط حتى اللحظة التي بدأوا فيها منع البرقيات.) وبعد إعداد الخيارات الالتفافية وإدراك أنهم لم يدخلوا القفل ، لم نقم بتفكيك الأمر برمته. لذلك ، فقط في حالة.
وفي عام 2019 ، ما زلنا نعيش في ظروف الأقفال. نظرت الليلة الماضية: حوالي مليون IP تستمر في حجبها. صحيح أن أمازون تم إلغاء حظرها بالكامل تقريبًا ، في ذروتها وصل إلى 20 مليون عنوان ... بشكل عام ، فإن الحقيقة هي أن الاتصال ، والاتصال الجيد - قد لا يكون. فجأة. قد لا يكون لأسباب فنية - الحرائق والحفارات ، كل ذلك. أو ، كما رأينا ، ليست تقنية بالكامل. لذلك ، يمكن لشخص كبير وكبير ، مع AS-kami ، توجيهه بطرق أخرى - الاتصال المباشر وأشياء أخرى موجودة بالفعل في المستوى l2. ولكن في إصدار بسيط ، تمامًا مثلنا أو حتى أصغر ، فيمكنك ، في حال وجودها ، التكرار على مستوى الخوادم التي يتم رفعها في مكان آخر ، والتي تم تكوينها مسبقًا عبر الشبكات الافتراضية الخاصة الوكيل ، مع القدرة على تبديل التكوينات بسرعة في تلك القطاعات التي لديك اتصال بالغ الأهمية . كان هذا مفيدًا لنا أكثر من مرة ، عندما بدأت شركة Amazon locks في المرور عبر S3 في أسوأ الحالات ، ولكن تدريجياً حدث كل هذا خطأ.
وكيفية حجز ... مزود كامل؟
الآن ليس لدينا أي سيناريو في حالة فشل الأمازون كله. لدينا سيناريو مماثل بالنسبة لروسيا. استضافنا نحن في روسيا مزود واحد ، اخترنا أن يكون لدينا عدة مواقع. وقبل عام واجهنا مشكلة: على الرغم من أن هذين هما مركزان للبيانات ، فقد تكون هناك بالفعل مشاكل على مستوى تكوين شبكة الموفر والتي ستؤثر على كل من مراكز البيانات على أي حال. ويمكننا الحصول على عدم إمكانية الوصول في كلا الموقعين. بالطبع ، هذا ما حدث. في النهاية ، قمنا بإعادة تعريف الهيكل الداخلي. لم يتغير الأمر كثيرًا ، لكن بالنسبة لروسيا لدينا الآن موقعان ، وهما ليسا مزودًا واحدًا ، لكنهما مختلفان. إذا فشل أحدهم ، يمكننا التبديل إلى آخر.
نظريا ، نحن نفكر في أن تقوم أمازون بالحجز على مستوى مزود آخر ؛ ربما غوغل ، ربما شخص آخر ... لكن في حين لاحظنا في الممارسة العملية أنه إذا تعطلت أمازون على مستوى منطقة التوافر نفسها ، فإن الحوادث على مستوى المنطقة بأكملها أمر نادر الحدوث. لذلك ، من الناحية النظرية لدينا فكرة أننا قد نقوم بالحجز "Amazon - وليس Amazon" ، لكن في الممارسة العملية لم يحدث هذا بعد.
بضع كلمات عن الأتمتة
هل تحتاج دائما الأتمتة؟ من المناسب أن نتذكر تأثير Dunning-Krueger. على المحور س ، معرفتنا وخبرتنا ، التي نكتسبها ، وعلى المحور ص - الثقة في أعمالنا. في البداية ، نحن لا نعرف شيئًا ولست متأكداً على الإطلاق. ثم نعرف القليل ونصبح واثقين جدًا - وهذا ما يسمى "ذروة الغباء" ، ويتضح بشكل جيد من خلال صورة "الخرف والشجاعة". علاوة على ذلك ، لقد تعلمنا بالفعل القليل ومستعدون للدخول في المعركة. ثم نخطو بعض أشعل النار الخطيرة ، نقع في وادي اليأس عندما يبدو أننا نعرف شيئًا ما ، لكن في الواقع لا نعرف الكثير. بعد ذلك ، كلما اكتسبت خبرة ، أصبحنا أكثر ثقة.
يتم وصف منطقنا حول التبديل التلقائي إلى حادث أو آخر بشكل جيد جدًا في هذا الرسم البياني. — , . , , , . -: false positive, - , , -, . , - — . , . , . ولكن! , , , , , , …
استنتاج
7 , , - , — -, , , , — — . - , , , . — , , — . , - — s3, , . , , - - . . , , — : , — ? , - , , - «, ».
حل وسط معقول بين الكمالية والقوى الحقيقية ، والوقت ، والمال الذي يمكنك إنفاقه على المخطط الذي ستحصل عليه في النهاية.هذا النص هو نسخة مستكملة وموسعة من تقرير ألكساندر ديميدوف في المؤتمر الذي يستغرق وقت الجهوزية يوم 4 .