فليكن فيضانًا ، ولكن يجب أن تعمل درجة 1C! نتفاوض مع رجال الأعمال حول DR

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



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



إنه لأمر رائع أن يتمكن متخصص تكنولوجيا المعلومات من التفاوض مع الشركة ومناقشة الحاجة إلى الحماية. لكنني رأيت أكثر من مرة كيف قامت الشركة بالاقتصاد في حل التعافي من الكوارث (DR) ، حيث اعتبرته زائدة عن الحاجة. عندما وقع حادث ، كان التعافي الطويل يهدد بالخسائر ، ولم يكن العمل جاهزًا. يمكنك تكرار ما تشاء: "لكنني أخبرتك" - لا يزال يتعين على خدمة تكنولوجيا المعلومات استعادة الخدمات.







من وجهة نظر مهندس معماري ، سأخبرك كيف تتجنب هذا الموقف. سأعرض في الجزء الأول من المقال الأعمال التحضيرية: كيفية مناقشة ثلاثة أسئلة مع العميل لاختيار أدوات الحماية: 

• ماذا نحمي؟
  
  
• ما الذي نحمي منه؟
  
  
• ما مدى قوتنا التي نحميها؟ 
  
  

في الجزء الثاني سنتحدث عن خيارات الإجابة على السؤال: بماذا ندافع. سأقدم أمثلة لحالات حول كيفية قيام العملاء المختلفين ببناء حمايتهم.

ما نحميه: توضيح وظائف العمل المهمة 

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



قد يجد متخصص في تكنولوجيا المعلومات صعوبة في التفاوض لعدة أسباب:

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

أرغب في تنظيم المحادثة على النحو التالي: 

1. نشرح للأعمال التجارية أن الحوادث تقع للجميع ، وأن التعافي منها يستغرق وقتًا. أفضل شيء هو توضيح الموقف وكيف يحدث والعواقب المحتملة.
   
   
2. نظهر أنه لا يعتمد كل شيء على خدمة تكنولوجيا المعلومات ، لكنك مستعد للمساعدة في خطة عمل في منطقة مسؤوليتك.
   
   
3. نطلب من العميل التجاري الإجابة: في حالة حدوث نهاية العالم ، ما هي العملية التي يجب استعادتها أولاً؟ من يشارك فيها وكيف؟ 
   
   
   
   يحتاج العمل إلى إجابة بسيطة ، على سبيل المثال: من الضروري أن يواصل مركز الاتصال تسجيل التطبيقات على مدار الساعة طوال أيام الأسبوع.
   
   
4. - . 
   
   , .
   
   
   
   : - , . 1 -, .
   
   
5. , . : 
   
   
   • ( ),   
     
     
   • , ( ), 
     
     
   • ( ).
   
   
   
6. نكتشف نقاط الفشل المحتملة: عُقد النظام التي يعتمد عليها أداء الخدمة. بشكل منفصل ، نحتفل بالعقد التي تدعمها الشركات الأخرى: مشغلي الاتصالات ومقدمي الاستضافة ومراكز البيانات وما إلى ذلك. باستخدام هذا ، يمكنك الرجوع إلى العميل التجاري للخطوة التالية.
   
   

ما نحمي منه: المخاطر

ثم نكتشف من العميل التجاري المخاطر التي نحميها في المقام الأول. سنقسم جميع المخاطر بشكل مشروط إلى مجموعتين: 

• ضياع الوقت بسبب تعطل الخدمة ؛
  
  
• فقدان البيانات بسبب التأثير المادي والعوامل البشرية وما إلى ذلك.
  
  

يخشى العمل أن يفقد كل من البيانات والوقت - كل هذا يؤدي إلى خسارة المال. لذا مرة أخرى نطرح أسئلة حول كل مجموعة خطر: 

• هل يمكننا تقدير مقدار فقدان البيانات والوقت الضائع لهذه العملية؟ 
  
  
• ما هي البيانات التي لا يمكن أن نخسرها؟ 
  
  
• أين لا نسمح بالتوقف عن العمل؟ 
  
  
• ما هي الأحداث الأكثر احتمالًا والأكثر تهديدًا لنا؟
  
  

بعد المناقشة ، سوف نفهم كيفية تحديد أولويات نقاط الفشل. 

ما مدى قوتنا التي نحميها: RPO و RTO 

عندما يتم فهم النقاط الحرجة للفشل ، نحسب RTO و RPO. 



اسمحوا لي أن أذكركم بأن RTO (هدف وقت الاسترداد) هو الوقت المسموح به من لحظة وقوع الحادث إلى الاسترداد الكامل للخدمة. في لغة الأعمال ، هذا هو وقت التوقف المقبول. إذا عرفنا مقدار الأموال التي جلبتها العملية ، فيمكننا حساب الخسائر من كل دقيقة من وقت التعطل وحساب الخسارة المسموح بها. 



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







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

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

 

بعد ذلك ، يحتاج مسؤول النظام إلى التحقق من صحة قاعدة البيانات ، وتوصيلها بـ 1C وبدء الخدمات. يستغرق الأمر ساعة أخرى ، مما يعني أن RTO من جانب المسؤول هي بالفعل ساعتان و 15 دقيقة. يحتاج المستخدم إلى 15 دقيقة أخرى: قم بتسجيل الدخول ، وتحقق من ظهور المعاملات الضرورية. ساعتان و 30 دقيقة هي إجمالي وقت الاسترداد للخدمة في هذا المثال.

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

كيف نحمي: اختيار الأدوات لمختلف المخاطر

بعد مناقشة جميع النقاط ، يتفهم العميل بالفعل تكلفة الحادث للشركة. الآن يمكنك تحديد الأدوات ومناقشة الميزانية. سأعرض بأمثلة من حالات العملاء الأدوات التي نقدمها للمهام المختلفة. 



لنبدأ بالمجموعة الأولى من المخاطر: الخسائر بسبب تعطل الخدمة. يجب أن توفر الحلول لهذه المهمة RTO جيدة.

1.  
   
   
   
   — . , , , - .
   
   
   
   , . . , 2 . , .
   
   
   
   RTO: . .
   
   : . 
   
   : , , - .
   
   
2.   
   
   
   
   RTO, .
   
   
   
   active-passive active-active. , . . , .
   
   
   
   RTO: .
   
   : , .
   
   : - . .
   
   

   : - . . DR , . . 
   
    
   
   . .

3. 
   
   
   
   , ,   2 -. - , --. , . 
   
   
   
   RTO: 0.
   
   : . 
   
   : , , . 
   
   

   : . : 
   
   
   
   

   • . 
     
     
   • . : «» «». «» , . «» . . . 
     
     

   
   
   , . . 

4.  
   
   
   
   , : . , . DR: VMware vCloud Availability (vCAV). on-premise . vCAV . 
   
   
   
   RPO RTO: 5 . 
   
   
   
   : , , . vCAV, , PAYG (10% ).
   
   

   : 6 . : , — . , . 
   
    
   
   VMware vCloud Availability. - 5 . , - . 

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



5. لا تنسى النسخ الاحتياطية



يعلم الجميع أنك بحاجة لعمل نسخ احتياطية ، حتى لو كان لديك أروع حل لاستعادة البيانات بعد الكوارث. لذا سأذكر بإيجاز بعض النقاط.



بالمعنى الدقيق للكلمة ، النسخ الاحتياطي ليس DR. ولهذا السبب: 

• يستغرق وقتا طويلا. إذا تم قياس البيانات بوحدة تيرابايت ، فستستغرق استعادة البيانات أكثر من ساعة. تحتاج إلى استعادة ، تعيين شبكة ، التحقق مما يتم تشغيله ، معرفة أن البيانات مرتبة. لذلك لا يمكنك تحقيق RTO جيد إلا إذا كان هناك القليل من البيانات. 
  
  
• قد لا يتم استرداد البيانات في المرة الأولى ، وتحتاج إلى إتاحة الوقت لإجراء ثانٍ. على سبيل المثال ، هناك أوقات لا نعرف فيها الوقت المحدد لفقدان البيانات. لنفترض أن الخسارة قد لوحظت في الساعة 15.00 ، ويتم عمل نسخ كل ساعة. من الساعة 15.00 نراقب جميع نقاط الاسترداد: 14:00 و 13:00 وما إلى ذلك. إذا كان النظام حرجًا ، نحاول تقليل عمر نقطة الاستعادة. ولكن إذا لم يتم العثور على البيانات اللازمة في النسخة الاحتياطية الجديدة ، فإننا نأخذ النقطة التالية - هذا وقت إضافي. 
  
  

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



يجب أن تشتمل خطة التعافي من الكوارث النهائية على أداتين على الأقل:  

• أحد الخيارات 1-4 ، والذي سيحمي الأنظمة من الأعطال والأعطال.
  
  
• النسخ الاحتياطي لحماية البيانات من الضياع. 
  
  

من المفيد أيضًا الاهتمام بقناة اتصال احتياطية في حالة تعطل مزود الإنترنت الرئيسي. وفويلا! - DR على الحد الأدنى للرواتب جاهز بالفعل.