حول ممارسات منظومة السحابة الموثوقة والمرنة
التطبيقات الموثوقة هي:
- القدرة على التكيف والتعافي من الإخفاقات، وهي تواصل العمل بأقل قدر من وقت التعطل وفقدان البيانات قبل الاستعادة الكاملة.
- متوفر للغاية (HA) ويعمل كما هو مصمم في حالة صحية دون وقت توقف كبير.
- الحماية من فشل المنطقة من خلال التصميم الجيد لاستعادة القدرة على العمل بعد الكوارث.
وفهم كيفية عمل هذه العناصر معا وكيفية تأثيرها على التكلفة أمر أساسي لبناء تطبيق موثوق به. يمكن أن يساعدك ذلك في تحديد مقدار وقت التوقف المقبول والتكلفة المحتملة لأعمالك والوظائف الضرورية أثناء الاستعادة.
مهندس الموثوقية
عند تكوين تطبيق سحابي، استخدم ما يلي للإنشاء بموثوقية.
- تحديد المتطلبات.
حدد متطلبات التوفر والاستعادة استنادًا إلى أحمال العمل التي تجلبها إلى السحابة واحتياجات الأعمال.
- تطبيق أفضل الممارسات المعمارية.
اتبع الممارسات المثبتة، وحدد نقاط الفشل المحتملة في البنية، وحدد كيفية استجابة التطبيق للفشل.
- اختبار بالمحاكات وعمليات الفشل القسرية.
محاكاة الأخطاء وتحفيز حالات الفشل القسري واختبار الكشف والاستعادة من حالات الفشل هذه.
- توزيع التطبيقات بشكل متسق.
إصدار للإنتاج باستخدام عمليات موثوقة وقابلة للتكرار وأتمتة حيثما أمكن.
- مراقبة صحة التطبيق.
اكتشف حالات الفشل وراقب مؤشرات الفشل المحتملة وقياس سلامة تطبيقاتك.
- إدارة حالات الفشل والكوارث.
تحديد وقت حدوث الفشل وتحديد كيفية معالجته استنادًا إلى الاستراتيجيات الراسخة.
تحديد المتطلبات
حدد متطلبات التوفر والاستعادة استنادًا إلى أحمال العمل التي تجلبها إلى السحابة واحتياجات الأعمال.
ضع في اعتبارك ما يلي عند تحديد احتياجات أعمالك ومطابقة خطة الموثوقية بها:
- تحديد أحمال العمل ومتطلباتها
حمل العمل هو قدرة أو مهمة مميزة يتم فصلها منطقيًا عن أحمال العمل الأخرى، من حيث منطق العمل ومتطلبات تخزين البيانات. ولكل عبء عمل متطلبات مختلفة للتوفر وقابلية التوسع واتساق البيانات واستعادة القدرة على العمل بعد الكوارث.
- تحديد أنماط الاستخدام
تؤدي كيفية استخدام التطبيق دورًا في المتطلبات. تحديد الاختلافات في الاحتياجات خلال الفترات الحرجة وغير الحرجة. على سبيل المثال، لا يمكن أن تفشل معالجة نهاية الشهر في التطبيق أثناء نهاية الشهر، ولكنها قد تعالج الفشل في أوقات أخرى. لضمان وقت التشغيل، يمكن إضافة مكونات إضافية أو تكرار أثناء الفترات الحرجة وإزالتها عند عدم إضافتها لقيمة.
- تحديد المكونات والمسارات الهامة
قد لا تكون كل مكونات النظام على نفس القدر من الأهمية مثل مكونات أخرى. على سبيل المثال، قد يكون لديك مكون اختياري يضيف قيمة تزايدية، ولكن يمكن تشغيل حمل العمل بدون الحاجة. تعرف على مكان وجود هذه المكونات، وعلى العكس من ذلك، على مكان وجود الأجزاء الحرجة لحجم العمل. سيساعد ذلك على تحديد نطاق قياسات التوفر والموثوقية وتخطيط إستراتيجيات الاستعادة لتحديد أولوية المكونات ذات الأهمية القصوى.
- تحديد التبعيات الخارجية وتأثير الفشل اللاحق
إذا كان عبء العمل يعتمد على الخدمات الخارجية، قد يؤثر فشل هذه التبعيات سلباً على توفر حمل العمل. تنفيذ أساليب لفصل التكامل لعزله عن الفشل في المراحل اللاحقة.
- تحديد متطلبات توفر حمل العمل
وعادة ما يتم تعريف الإتاحة العالية (HA) من حيث هدف وقت التشغيل. يعني هدف HA 99% على سبيل المثال أن مورد معين يمكن أن يكون غير متاح لمدة 3.65 أيام في السنة. تم تصميم Oracle Cloud Infrastructure (OCI) لتزويدك ببيئة متاحة للغاية. تقوم OCI بنشر اتفاقية مستوى الخدمة (SLA) لكل خدمة من خدماتها والتي تصف التزامات Oracle بوقت التشغيل والاتصال بتلك الخدمات ويجب مراجعتها لمعرفة كيفية مطابقتها لمتطلباتك. تحتوي بعض الخدمات في OCI على مستويات عالية من HA مضمنة، ولا سيما الخدمات المدارة بواسطة Oracle مثل قاعدة البيانات المستقلة. للتأكد من أن هيكل التطبيق يفي بمتطلبات العمل الخاصة بك، حدد اتفاقيات مستوى الخدمة الهدف لكل حمل عمل شامل التبعيات الخارجية. حساب تكلفة وتعقد استيفاء متطلبات الإتاحة، بالإضافة إلى تبعيات التطبيق.
- إنشاء مقاييس الاستعادة — هدف وقت الاستعادة (RTO) وهدف نقطة الاستعادة (RPO)
RTO هو الحد الأقصى للوقت المقبول الذي يمكن فيه عدم إتاحة التطبيق بعد وقوع حادث كارثة.
RPO هو الحد الأقصى لمدة فقدان البيانات المقبول أثناء الكارثة.
لاشتقاق هذه القيم، قم بإجراء تقييم مخاطرة وتأكد من فهم تكلفة ومخاطر وقت التعطل أو فقدان البيانات في التنظيم.
- تحديد كارثة
ووجود خطط ومتطلبات موثقة توثيقا جيدا لاستعادة القدرة على العمل بعد الكوارث أمر هام، ولكن الطابع الفوضوي لهذا الحدث يمكن أن يخلق ارتباكا. فهم ما يشكل كارثة لشركتك، وتحديد الأدوار الرئيسية التي ستكون مطلوبة أثناء الكارثة، ووضع خطة اتصال محددة جيدا للبدء في الاستجابة للكوارث.
تطبيق أفضل الممارسات المعمارية
عند تصميم بنيتك، قم بالتركيز على تنفيذ الممارسات التي تفي بمتطلبات أعمالك، وتحديد نقاط الفشل، وتقليل نطاق الفشل إلى الحد الأدنى.
النظر في أفضل الممارسات التالية:
- تحديد مكان حدوث الفشل
قم بتحليل البنية لتحديد أنواع حالات الفشل التي قد يعاني منها التطبيق والتأثيرات المحتملة لكل منها واستراتيجيات الاستعادة الممكنة.
- تحديد مستوى التكرار المطلوب، استنادًا إلى متطلبات HA وDR
يعتمد مستوى التكرار المطلوب لكل حمل عمل على احتياجات العمل والعوامل في التكلفة الإجمالية للتطبيق.
- تصميم قابلية التوسيع
يجب أن يكون التطبيق السحابي قادرًا على التوسيع لاستيعاب التغييرات في الاستخدام. ابدأ بمكونات منفصلة، وقم بتصميم التطبيق للاستجابة تلقائيًا لتحميل التغييرات كلما أمكن. ضع حدود الضبط في الاعتبار أثناء التصميم حتى يمكنك التوسيع بسهولة في المستقبل.
- استخدام موازنة التحميل لتوزيع الطلبات
تقوم الموازنة المحملة بتوزيع طلبات التطبيق على طبعات الخدمة الصحية عن طريق إزالة الطبعات غير الصحية من التناوب. ستجعل معلومات الحالة الخارجية الضبط الخلفي شفافًا للمستخدم النهائي. إذا تم تتبع الحالة في جلسة العمل، فقد تكون هناك حاجة للالتزام.
- إنشاء متطلبات التوفر والمرونة في تصميمك
المرونة هي قدرة النظام على التعافي من حالات الفشل والاستمرار في العمل. الإتاحة هي نسبة الوقت الذي يعمل فيه النظام. تنفيذ أفضل الممارسات عالية التوفر، مثل تجنب نقاط الفشل المفردة وتفكيك أحمال العمل حسب هدف مستوى الخدمة. استخدم الميزات القياسية لطبقة البيانات، مثل استمرارية التطبيق والمعاملات غير المتزامنة لضمان كل من التوفر والمرونة.
- تنفيذ المدين
قم بتصميم الحل لاستيفاء متطلبات RTO وRPO المحددة. تأكد من إمكانية توصيل كل مكونات حل DR داخل RTO الخاص بك. قم بحماية بياناتك حتى تتمكن من الوصول إلى RPO. تعتبر كيفية تخزين البيانات ونسخها احتياطيًا واستنساخها أمرًا بالغ الأهمية.
- إنشاء نسخة احتياطية من بياناتك
وحتى مع وجود بيئة مستنسخة تماماً للحد من الكوارث، لا تزال النسخ الاحتياطية المنتظمة حرجة. نسخ البيانات احتياطيًا والتحقق منها بشكل منتظم، والتأكد من عدم وجود حساب مستخدم واحد لديه صلاحية الوصول إلى كل من بيانات الإنتاج والنسخ الاحتياطي.
- اختر أساليب الاستنساخ لبيانات التطبيق
يتم تخزين بيانات التطبيق في مخازن بيانات مختلفة وقد تحتوي على متطلبات إتاحة مختلفة. قم بتقييم أساليب الاستنساخ ومواقعه لكل نوع من أنواع مخزن البيانات للتأكد من استيفائها لمتطلبات HA وRPO.
- فهم آثار الفشل وأثره على التأهب للكوارث
هل ستحتاج إلى تكوين طبعة منطقة أخرى للاستنساخ لاستيفاء متطلبات أحمال العمل؟ هل ستحتاج إلى القلق بشأن اتساق البيانات عند الفشل؟
- توثيق واختبار عمليات تجاوز الفشل والخروج
من الواضح أن تعليمات التوثيق لفشل متجر بيانات جديد واختبارها بشكل منتظم للتأكد من دقتها وسهولة متابعتها.
- تأكد من أن خطة استعادة البيانات الخاصة بك تستوفي RTO
تأكد من أن إستراتيجية النسخ الاحتياطي والاستنساخ توفر أوقات استعادة البيانات التي تتوافق مع RTO وكذلك RPO. حساب كل أنواع البيانات التي يستخدمها التطبيق، بما في ذلك البيانات المرجعية والملفات وقواعد البيانات.
- إنشاء نسخة احتياطية من بياناتك
اختبار بالمحاكات وحالات الفشل الإجبارية
ويتطلب اختبار الموثوقية قياس كيفية أداء عبء العمل من طرف إلى طرف في ظروف الفشل التي تحدث بشكل متقطع فقط.
- اختبار سيناريوهات الفشل الشائعة من خلال تحفيز الفشل الفعلي أو محاكاتها
استخدم اختبار حقن الخطأ لاختبار السيناريوهات الشائعة (بما في ذلك توليفات حالات الفشل) ووقت الاستعادة.
- تحديد حالات الفشل التي تحدث فقط تحت التحميل
اختبار تحميل الذروة، باستخدام بيانات الإنتاج أو البيانات الاصطناعية القريبة من بيانات الإنتاج قدر الإمكان، لمعرفة كيفية أداء التطبيق في ظل ظروف العمل الحقيقي.
- إجراء تدريبات لاستعادة القدرة على العمل بعد الكوارث
:: وضع خطة لاستعادة القدرة على العمل بعد الكوارث واختبارها دوريا للتأكد من نجاحها.
- تنفيذ اختبار تجاوز الفشل والخلف
تأكد من فشل الخدمات التابعة للتطبيق وفشلها مرة أخرى بالترتيب الصحيح.
- إجراء اختبارات المحاكاة
ويمكن لاختبار سيناريوهات الحياة الحقيقية أن يسلط الضوء على المسائل التي يلزم معالجتها. وينبغي أن تكون السيناريوهات قابلة للتحكم وغير مخلة بالعمل. إعلام الإدارة بخطط اختبار المحاكاة.
- اختبارات صحية
تكوين اختبارات الحالة لموازين التحميل ومديري حركة المرور للتحقق من مكونات النظام الهامة. قم باختبارها للتأكد من استجابتها بشكل مناسب.
- نظم مراقبة الاختبار
تأكد من أن نظم الرصد تقوم بالإبلاغ الموثوق به عن المعلومات الحيوية والبيانات الدقيقة للمساعدة في تحديد الإخفاقات المحتملة.
- تضمين خدمات الطرف الثالث في سيناريوهات الاختبار
اختبار نقاط الفشل المحتملة بسبب تعطل خدمة الطرف الثالث، بالإضافة إلى الاستعادة.
- تعلم من المشكلات التي تمت مواجهتها أثناء الاختبارات
وإذا كشف الاختبار عن مشاكل أو ثغرات، فتأكد من تحديدها ومعالجتها إما بإضافة رصد إضافي أو بتعديل العمليات التشغيلية.
توزيع التطبيقات بشكل متسق
يتضمن التوزيع تزويد خدمات وموارد Oracle Cloud Infrastructure (OCI) وتوزيع تعليمات التطبيق البرمجية وتطبيق إعدادات التكوين. قد يتضمن التحديث المهام الثلاث جميعها أو مجموعة فرعية منها.
- أتمتة عملية نشر التطبيق
أتمتة أكبر عدد ممكن من العمليات. وينبغي، إن أمكن، القضاء على عمليات النشر اليدوية في الإنتاج، وإن كان ذلك مقبولا في بيئات أقل لتعزيز السرعة والمرونة.
- الاستفادة من الأتمتة لاختبار التعليمة البرمجية قبل النشر
يعد اختبار الأخطاء ومواطن الضعف الأمنية والوظائف والأداء والتكامل أمرًا بالغ الأهمية لتقليل المشكلات التي يكتشفها المستخدمون النهائيون إلى الحد الأدنى. يجب أن تمنع حالات فشل الاختبار إصدار التعليمات البرمجية في الإنتاج.
- تصميم عملية الإصدار الخاصة بك لزيادة التوفر إلى أقصى حد
إذا كانت عملية الإصدار الخاصة بك تتطلب وصول الخدمات إلى وضع عدم الاتصال أثناء التوزيع، فلن يكون التطبيق متاحًا حتى تعود إلى وضع الاتصال. الاستفادة من ميزات تجهيز النظام الأساسي وإنتاجه. يمكنك، إن أمكن، إصدار عمليات نشر جديدة إلى مجموعة فرعية من المستخدمين لمراقبة حالات الفشل في الساعات الأولى.
- وجود خطة إلغاء تعديلات للنشر
قم بتصميم عملية إلغاء التعديلات للعودة إلى آخر إصدار جيد معروف وتقليل وقت التوقف إلى أدنى حد في حالة فشل النشر. يمكن لأتمتة إلغاء التعديلات عند فشل النشر منع وقت التوقف غير الضروري.
- عمليات نشر الأرشيف والمراجعة
في حالة استخدام تقنيات النشر المرحلي، يتم تشغيل أكثر من إصدار واحد من التطبيق في الإنتاج. تنفيذ استراتيجية قوية لتسجيل الدخول للحصول على أكبر قدر ممكن من المعلومات الخاصة بالنسخة.
- توثيق عملية إصدار التطبيق
حدد عملية الإصدار وتوثيقها بوضوح، وتأكد من إتاحتها لفريق العمليات بأكمله.
مراقبة صحة التطبيق
تنفيذ أفضل الممارسات للمراقبة والتنبيهات في التطبيق بحيث يمكنك اكتشاف حالات الفشل وتنبيه عامل التشغيل إلى إصلاحها.
- تنفيذ التتبع حول مكالمات الخدمة
يمكن أن تساعد بيانات الأداء الأساسية على توفير بيانات اتجاه الاستهلاك التي يمكن استخدامها لتحديد مشكلات الأداء بشكل استباقي قبل أن تؤثر على المستخدمين.
- تنفيذ الفحوص الصحية
قم بتشغيلها بانتظام من خارج التطبيق لتحديد تدهور صحة التطبيق وأدائه. وينبغي أن تكون هذه الفحوص أكثر من مجرد اختبارات ثابتة للصفحات، وينبغي أن تعكس سلامة التطبيق الشاملة.
- التحقق من عمليات سير العمل الطويلة الأجل
يمكن أن يؤدي التقاط المشكلات مبكرًا إلى تقليل الحاجة إلى إلغاء تعديلات سير العمل بأكمله أو تنفيذ معاملات تعويضية متعددة.
- صيانة سجلات النظام والتطبيق والتدقيق
استخدم خدمة تسجيل مركزية لتخزين السجلات.
- إعداد نظام الإنذار المبكر
حدد مؤشرات الأداء الأساسية (KPI) لصحة التطبيق، مثل الاستثناءات العابرة وكمية المكالمة عن بُعد، وقم بتعيين قيم الحد المناسبة لكل منها. إرسال تنبيه إلى العمليات عند بلوغ قيمة الحد.
- تدريب مشغلات متعددة لمراقبة التطبيق وتنفيذ خطوات الاستعادة اليدوية
تأكد من وجود عامل تشغيل مدرب واحد نشط دائمًا.
إدارة حالات الفشل والكوارث
قم بإنشاء خطة استعادة، وتأكد من أنها تغطي استعادة البيانات وحالات الانقطاع المؤقت للشبكة وحالات فشل الخدمة التابعة وحالات تعطل الخدمة على مستوى المنطقة. ضع في اعتبارك أجهزة VM والتخزين وقواعد البيانات وخدمات OCI الأخرى في إستراتيجية الاستعادة.
- خطة اتصالات دعم OCI
قبل الحاجة، قم بإنشاء عملية للاتصال بدعم OCI.
- توثيق واختبار خطة استعادة القدرة على العمل بعد الكوارث
كتابة خطة استعادة القدرة على العمل بعد الكوارث تعكس تأثير فشل التطبيق على الأعمال. أتمتة عملية الاستعادة قدر الإمكان وتوثيق أية خطوات يدوية. قم باختبار عملية استعادة القدرة على العمل بعد الكوارث بشكل منتظم لمراجعة الخطة وتحسينها.
- فهم الأدوار الرئيسية اللازمة لتنسيق عملية إعداد التقارير
تأكد من تنسيق جهود DR تنسيقًا جيدًا وتحديد أولويات التطبيقات استنادًا إلى قيمة الأعمال.
- فشل الإعداد للتطبيق
قم بالتحضير لمجموعة من حالات الفشل، بما في ذلك الأخطاء التي تتم معالجتها تلقائيًا، وتلك التي تؤدي إلى تقليل الوظائف، وتلك التي تتسبب في عدم توفر التطبيق. وينبغي أن يبلغ الطلب المستعملين بالمسائل المؤقتة.
- استعادة من تلف البيانات
في حالة حدوث فشل في مخزن بيانات، تحقق من عدم اتساق البيانات عندما يصبح المتجر متاحًا مرة أخرى، ولا سيما في حالة استنساخ البيانات. استعادة بيانات تالفة من النسخة الاحتياطية.
- استعادة من انقطاع مؤقت للشبكة
قد تتمكن من استخدام البيانات المخزنة في الذاكرة المخبئية للتشغيل محليًا بوظيفة تطبيق مخفضة. إذا لم يكن الأمر كذلك، فكر في وقت توقف التطبيق أو فشل الانتقال إلى منطقة أخرى. تخزين بياناتك في موقع بديل حتى تتم استعادة الاتصال.
- استعادة من فشل خدمة تابعة
تحديد الوظيفة التي لا تزال متاحة وكيفية استجابة التطبيق.
- استعادة من تعطل الخدمات على نطاق المنطقة
حالات تعطل الخدمة على نطاق المنطقة غير شائعة، ولكن يجب أن يكون لديك إستراتيجية لمعالجتها، خاصة بالنسبة للتطبيقات الحرجة. قد تتمكن من إعادة توزيع التطبيق على منطقة أخرى أو إعادة توزيع حركة المرور.
- تعلم من اختبارات DR وتحسين العمليات
ضمان تسجيل أية مشكلات تتم مواجهتها أثناء اختبار DR، ومعالجة خطط معالجة هذه المشكلات في الاختبارات المستقبلية أو حالات الفشل.