> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # استمرارية الأعمال BCP والتعافي من الكوارث DRP: الخطة والاختبار - URL: https://arabroot.io/articles/استمرارية-الاعمال-bcp-والتعافي-من-الكوارث-drp-الخطة-والاختبار/ - Published: 2026-10-28T12:12:30.000Z - Updated: 2026-10-28T13:53:30.000Z - Description: حولنا جرد عمليات شركة إلى طبقات تعاف بسكربت صغير، فكشف خدمة ظنها الفريق ثانوية وهي حرجة، وشرحنا MTD وRTO وRPO والموقع البديل. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الأمن السيبراني, التشغيل والنسخ الاحتياطي, الاستضافة الذاتية تسأل مديرك سؤالاً بسيطاً: لو توقف متجرنا الإلكتروني الآن، كم ساعة نتحمل قبل أن تكون الخسارة غير مقبولة؟ فيجيب «ساعتان، ثلاث على الأكثر». ثم تسأل فريق التقنية: لو تلف سيرفر قاعدة البيانات، كم نأخذ لنعيده من النسخة الاحتياطية؟ فتكون الإجابة بعد بحث «نصف يوم، ربما». هنا تظهر الفجوة التي تقع فيها أغلب الشركات: العمل يتوقع العودة في ساعتين، والتقنية تستطيع العودة في اثنتي عشرة ساعة، ولم يكتشف أحد هذا التناقض إلا الآن، في الاجتماع، وليس في الكارثة. وسد هذه الفجوة هو كل ما تعنيه استمرارية الأعمال Business Continuity والتعافي من الكوارث Disaster Recovery: أن تعرف قبل الكارثة كم تتحمل أن تخسر وكم تتحمل أن تتوقف، ثم تبني وتختبر خطة تحقق ذلك. وقد شرحنا النسخ الاحتياطي نفسه وقاعدة 3-2-1 في [مقال النسخ الاحتياطي](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)، وهذا المقال طبقة أعلى: كيف تقرر ما تحميه أولاً، وبأي سرعة، وكيف تنظم ذلك في خطة تصمد يوم الحادثة. ونبنيه بالأرقام، بسكربت صغير يحول دراسة أثر الأعمال إلى ترتيب تعاف حقيقي. [![](https://arabroot.io/content/images/2026/10/backup-321-cover-cover.webp)دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)[![](https://arabroot.io/content/images/2026/10/tabletop-exercise-cover-cover.webp)دليلتمرين الطاولة Tabletop: جرب خطة الاستجابة قبل الحادثةمشينا فريقاً على سيناريو فدية بست حقن، فأظهر التمرين خمس ثغرات في الخطة وقراراً بلا مالك، وحولنا نقاشه إلى أرقام وأوامر عمل.](https://arabroot.io/articles/%D8%AA%D9%85%D8%B1%D9%8A%D9%86-%D8%A7%D9%84%D8%B7%D8%A7%D9%88%D9%84%D8%A9-tabletop-exercise-%D8%AC%D8%B1%D8%A8-%D8%AE%D8%B7%D8%A9-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%82%D8%A8%D9%84-%D8%A7%D9%84%D8%AD%D8%A7%D8%AF%D8%AB%D8%A9/)[![](https://arabroot.io/content/images/2026/10/ir-playbooks-cover-cover.webp)دليلخطة الاستجابة للحوادث Incident Response وكتيبات التشغيل Playbooksخطة استجابة وكتيبا حساب مخترق وفدية على NIST SP 800-61r3، مع مختبر نستعيد فيه البيانات من نسخة restic.](https://arabroot.io/articles/%D8%AE%D8%B7%D8%A9-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%84%D9%84%D8%AD%D9%88%D8%A7%D8%AF%D8%AB-incident-response-%D9%88%D9%83%D8%AA%D9%8A%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%B4%D8%BA%D9%8A%D9%84/) وسوف نناقش في هذا المقال ما يلي: - لماذا لا يكفي النسخ الاحتياطي وحده للاستعداد للكارثة. - ثلاثة أرقام تحدد كل شيء: MTD وRTO وRPO، والفرق بينها الذي يخلط فيه الكثيرون. - الفرق بين خطة الاستمرارية BCP وخطة التعافي DRP وخطة طوارئ النظام ISCP. - دراسة أثر الأعمال BIA: كيف تعرف ما تحميه أولاً، والاعتماديات الخفية التي تكشفها. - تجربة عملية: سكربت يحول جرد العمليات إلى طبقات تعاف، ويكشف خدمة ظنها الفريق ثانوية. - استراتيجيات التعافي: الموقع البديل من البارد إلى المرآة، وما يقابلها في السحابة. - بنية الخطة، واختبارها، وربطها بتمرين الطاولة. - ما تطلبه الضوابط الأساسية ECC، وأخطاء شائعة، وقائمة تحقق. ## لماذا لا يكفي النسخ الاحتياطي وحده؟ قد يتساءل البعض: إذا كان لدي نسخ احتياطية جيدة، ألست مستعداً للكارثة؟ والإجابة أن النسخة الاحتياطية جزء من الحل لا كله، فهي تجيب عن سؤال واحد: من أين نعيد البيانات؟ وتترك أسئلة كثيرة بلا جواب: كم نأخذ لنعيدها؟ وبأي ترتيب؟ وأين نشغل الأنظمة إن تلف الموقع كله؟ ومن يقرر أننا في حالة كارثة؟ وماذا نقول للعملاء في الساعات الأولى؟ فالشركة التي عندها نسخ ممتازة وتأخذ ثلاثة أيام لتعرف ماذا تعيد أولاً خسرت أكثر مما لو كان عندها خطة وبعض النسخ. والفرق بين الاثنين يظهر في التعطل الكبير: عطل قرص واحد تحله النسخة، أما حريق في غرفة السيرفرات، أو فدية شفرت كل شيء بما فيه بعض النسخ، أو انقطاع مزود سحابي لمنطقة كاملة، فهذه لا تحلها نسخة، وإنما خطة تقول أين تعمل وبأي ترتيب وبأي سرعة. ولذلك فالنسخ الاحتياطي، كما في [مقال 3-2-1](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)، هو الطبقة التقنية الأولى، وخطة التعافي هي ما يبنى حولها ليجعلها مفيدة يوم الكارثة. ## ثلاثة أرقام تحدد كل شيء: MTD وRTO وRPO قبل أي خطة، تحتاج لغة مشتركة بين العمل والتقنية، وهي ثلاثة أرقام يعرفها [دليل NIST SP 800-34](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final?ref=arabroot.io) للتخطيط للطوارئ. والصورة التالية تضعها على محور زمني واحد: ![محور زمني فيه لحظة العطل Outage في المنتصف: إلى اليسار آخر نسخة احتياطية والمسافة بينها وبين العطل هي RPO أي كم بيانات تخسر، وإلى اليمين هدف عودة الخدمة والمسافة من العطل إليه هي RTO أي كم تتأخر الخدمة، وأبعد منه حد الضرر والمسافة من العطل إليه هي MTD أقصى توقف محتمل قبل ضرر غير مقبول](https://arabroot.io/content/images/2026/10/bcp-drp-01-mtd.webp) RTO أقصر من MTD دائماً، وRPO يقاس إلى اليسار (البيانات) لا إلى اليمين (الزمن) - **أقصى توقف محتمل MTD (Maximum Tolerable Downtime):** إجمالي الوقت الذي يقبل صاحب العمل أن تتوقف فيه عملية قبل أن يصبح الضرر غير مقبول. وهذا رقم عمل لا تقني: المدير هو من يقوله، بناء على الخسارة والسمعة والالتزامات. وفي مثالنا، MTD المتجر ساعتان. - **هدف زمن التعافي RTO (Recovery Time Objective):** أقصى وقت تبقى فيه الخدمة متوقفة قبل أن يصبح الأثر غير مقبول. ويجب أن يكون أقصر من MTD، لأن MTD يشمل كل شيء، بما فيه الوقت بعد عودة الخدمة لإعادة معالجة ما تراكم. فإذا كان MTD ساعتين، فقد يكون RTO ساعة ونصفاً، لتترك نصف ساعة للمعالجة. - **هدف نقطة التعافي RPO (Recovery Point Objective):** النقطة الزمنية قبل العطل التي تستطيع أن تعود إليها، أي كم بيانات تقبل أن تخسر. وهو يقاس إلى اليسار من العطل لا إلى اليمين، فهو لا يتعلق بالزمن الذي تتوقف فيه، وإنما بآخر نسخة لديك. وRPO ساعة يعني أنك قد تخسر آخر ساعة من البيانات، وهذا يحدد كم مرة تنسخ. والفرق بين RTO وRPO هو أكثر ما يخلط فيه المبتدئون. RTO عن الخدمة: متى تعود؟ وRPO عن البيانات: كم تخسر؟ فنظام يعود بسرعة ولكنه يخسر يوماً من البيانات له RTO قصير وRPO طويل، ونظام يخسر دقيقة واحدة ولكنه يأخذ يوماً ليعود له RPO قصير وRTO طويل. وكل رقم يقوده قرار تقني مختلف: RTO يقوده كيف تعيد التشغيل (موقع بديل، نسخة جاهزة)، وRPO يقوده كم مرة تنسخ. والمهم أن هذه الأرقام ليست رغبات، فكلما قصرت ارتفعت التكلفة، ولذلك تحددها دراسة تربط كل رقم بأثره الحقيقي، وهي دراسة أثر الأعمال. وهذه الأرقام الثلاثة ليست مستقلة عن بعضها، وإنما ترتبط بسلسلة: RPO يحدد كم مرة تنسخ، وتكرار النسخ يحدد كم بيانات يجب أن تنقل في كل مرة، وهذا يؤثر على RTO لأن استعادة نسخة أكبر تأخذ وقتاً أطول. فالذي يريد RPO دقيقة واحدة يحتاج تزامناً شبه لحظي، وهذا التزامن نفسه يجعل الاستعادة أسرع لأن النسخة دائماً قريبة. أي أن الاستثمار في RPO قصير يخدم RTO غالباً، وهذا ما يجعل موقع المرآة يحقق الرقمين معاً قرب الصفر، بثمن واحد مرتفع. ولكن لا تقع في فخ ملاحقة الصفر لكل شيء: فأغلب العمليات تحتمل RPO بالساعات وRTO بالساعات، والذي يحتاج الصفر قلة قليلة تحددها الدراسة، لا الخوف العام. ## BCP وDRP وISCP: من يفعل ماذا؟ الكلمات تتداخل في الحديث اليومي، ولكن لها معان مختلفة في [دليل NIST SP 800-34](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final?ref=arabroot.io)، والصورة التالية تفرق بينها: ![ثلاث لوحات: استمرارية الأعمال BCP كيف تبقى العمليات تعمل أثناء التعطل تركز على العمليات والناس لا على نظام بعينه وهي الأوسع، والتعافي من الكوارث DRP كيف نعيد الأنظمة التقنية بعد تعطل كبير تركز على السيرفرات والبيانات والموقع البديل مستوى التقنية، وخطة طوارئ النظام ISCP كيف نعيد نظاماً واحداً خطة لكل نظام مهم تفعلها DRP عند الحاجة](https://arabroot.io/content/images/2026/10/bcp-drp-02-plans.webp) BCP تفعل خطط DRP وISCP حسب الحاجة، والشركة الصغيرة قد تدمجها في وثيقة واحدة - **خطة استمرارية الأعمال BCP:** كيف تبقى العمليات تعمل أثناء التعطل؟ تركز على العمل والناس لا على نظام بعينه: كيف نستقبل الطلبات لو توقف النظام، كيف نخدم العملاء يدوياً، من يعمل من أين. وهي الأوسع، على مستوى العمل. - **خطة التعافي من الكوارث DRP:** كيف نعيد الأنظمة التقنية بعد تعطل كبير؟ تركز على السيرفرات والبيانات والموقع البديل. وهي على مستوى التقنية، تفعلها BCP عند الحاجة. - **خطة طوارئ النظام ISCP:** كيف نعيد نظاماً واحداً بعينه؟ خطة لكل نظام مهم، تحتوي خطواته التفصيلية، وتفعلها DRP. وفي شركة صغيرة قد تكون هذه كلها وثيقة واحدة، ولا بأس في ذلك، والمهم أن تغطي المستويات الثلاثة: ماذا يفعل العمل، وكيف نعيد التقنية، وخطوات كل نظام. والخطأ أن تكتب خطة تقنية بحتة لاستعادة السيرفرات، وتنسى سؤال العمل: ماذا نقول للعملاء في الساعات الأولى، ومن يقرر أننا في حالة كارثة أصلاً؟ فالتعافي التقني نصف القصة، والنصف الآخر استمرار العمل حوله. ولاحظ أن خطة التعافي من الكوارث شيء، وخطة الاستجابة للحوادث السيبرانية شيء آخر يكملها. فخطة الاستجابة، كما في [مقال خطة الاستجابة](https://arabroot.io/articles/%D8%AE%D8%B7%D8%A9-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%84%D9%84%D8%AD%D9%88%D8%A7%D8%AF%D8%AB-incident-response-%D9%88%D9%83%D8%AA%D9%8A%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%B4%D8%BA%D9%8A%D9%84/)، عن احتواء هجوم والتحقيق فيه، وخطة التعافي عن إعادة الخدمة بعد تعطل كبير أياً كان سببه، هجوماً أو حريقاً أو عطلاً. وفي حادثة فدية تجتمع الخطتان: الاستجابة تحتوي المهاجم وتحفظ الأدلة، والتعافي يعيد الخدمة من نسخة نظيفة، ولهذا يجب أن تعرف الخطتان بعضهما. ## دراسة أثر الأعمال BIA: ما تحميه أولاً لا تستطيع أن تحمي كل شيء بنفس السرعة، فالمرآة اللحظية لكل نظام تكلف أضعاف ما تكلفه نسخة يومية، ولا معنى لأن تحمي الموقع التعريفي الثابت بنفس ما تحمي به بوابة الدفع. والأداة التي تقرر من يستحق ماذا هي دراسة أثر الأعمال BIA (Business Impact Analysis)، وهي أربع خطوات كما في الصورة: ![أربع خطوات: اجرد العمليات ما العمليات التي يقوم عليها عملك المتجر والدفع والمحاسبة والبريد، ثم حدد الاعتماديات على ماذا تعتمد كل عملية قاعدة البيانات والشبكة والتخزين، ثم قدر الأثر والمهل كم تخسر كل ساعة توقف وما MTD وRPO، ثم رتب التعافي الأهم أولاً والاعتماديات قبل من يعتمد عليها، وأسفلها ما كشفه السكربت أن كشف الاحتيال كتب له الفريق 24 ساعة لكن بوابة الدفع تحتاجه 4 ساعات فاجعله 4 ساعات](https://arabroot.io/content/images/2026/10/bcp-drp-04-bia.webp) الاعتمادية الخفية تكشفها الدراسة لا الحدس: خدمة ترث أقصر مهلة يطلبها من يعتمد عليها 1. **اجرد العمليات:** ما العمليات التي يقوم عليها عملك فعلاً؟ المتجر، الدفع، المحاسبة، البريد، الموقع. لا الأنظمة، وإنما العمليات، فالنظام وسيلة والعملية غاية. 2. **حدد الاعتماديات:** على ماذا تعتمد كل عملية؟ المتجر يعتمد على قاعدة البيانات والدفع والشبكة، وقاعدة البيانات على التخزين. وهذه الخطوة أهم ما يغفل عنه الناس، كما سنرى. 3. **قدر الأثر والمهل:** كم تخسر كل ساعة توقف لكل عملية؟ وما MTD وRPO لها؟ وهذه أرقام يعطيها العمل، لا التقنية. 4. **رتب التعافي:** الأهم أولاً، والاعتماديات قبل من يعتمد عليها، فلا معنى لإعادة المتجر قبل قاعدة بياناته. والخطوة الثانية، الاعتماديات، هي التي تكشف ما لا يراه الحدس: خدمة يظنها الفريق ثانوية، وهي في الحقيقة حرجة لأن خدمة مهمة تعتمد عليها. والقاعدة التي يذكرها الدليل: كل مورد يرث أقصر مهلة يطلبها من يعتمد عليه. فقاعدة بيانات كتب لها الفريق MTD أربعاً وعشرين ساعة، ويحتاجها متجر MTD أربع ساعات، هي في الحقيقة قاعدة بأربع ساعات، سواء كتب الفريق ذلك أم لا. وهذا بالضبط ما سنقيسه في التجربة. ### كيف تقدر الأثر بالأرقام؟ الخطوة الثالثة في الدراسة، تقدير الأثر، هي الأصعب لأنها تحتاج أرقاماً لا يملكها فريق التقنية وحده. وأبسط طريقة أن تقدر لكل عملية خسارة الساعة الواحدة من التوقف، من مصادر تعرفها: متوسط المبيعات في الساعة للمتجر، وتكلفة توقف الموظفين الذين ينتظرون نظام المحاسبة، والغرامات أو الالتزامات التعاقدية إن وجدت، والأثر على السمعة الذي يصعب تسعيره ولكن لا يهمل. ولا تحتاج دقة محاسبية، فتقدير معقول يرتب العمليات أفضل من دقة لا تصل إليها. والمهم أن يشارك العمل في هذا التقدير لا التقنية وحدها، فالمدير هو من يعرف أن توقف المتجر ساعة في موسم الذروة يختلف عن توقفه ساعة في منتصف الأسبوع. ولاحظ فرقاً مهماً: الأثر ليس ثابتاً عبر الزمن. فنظام المحاسبة قد يحتمل التوقف يومين في منتصف الشهر، ولا يحتمل ساعة في يوم إقفال الرواتب. لذلك تكتب في الدراسة الأثر الأعلى، أو تحدد النوافذ الحرجة لكل عملية، حتى لا تقرر مهلة بناء على المتوسط فتفاجأ في أسوأ وقت. وهذا بالضبط ما ظهر في تمرين الطاولة في [مقال التمرين](https://arabroot.io/articles/%D8%AA%D9%85%D8%B1%D9%8A%D9%86-%D8%A7%D9%84%D8%B7%D8%A7%D9%88%D9%84%D8%A9-tabletop-exercise-%D8%AC%D8%B1%D8%A8-%D8%AE%D8%B7%D8%A9-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%82%D8%A8%D9%84-%D8%A7%D9%84%D8%AD%D8%A7%D8%AF%D8%AB%D8%A9/)، حين سألت المحاسبة عن نظامها في وقت إقفال الرواتب. ## تجربة عملية: من جرد إلى طبقات تعاف الآن نبني دراسة أثر مصغرة لشركة التوزيع بالأرقام. نكتب جرد العمليات في ملف، لكل عملية: على ماذا تعتمد، وما MTD وRPO وأثرها. ثم نشغل سكربتاً يحسب أقصر مهلة مطلوبة لكل خدمة، ويكشف التناقضات، ويرتب التعافي في طبقات. ولا يحتاج إلا Python. ```text process,depends_on,mtd_hours,rpo_hours,impact,note المتجر الإلكتروني,"قاعدة البيانات,بوابة الدفع,الشبكة",4,1,high,كل ساعة توقف خسارة مبيعات مباشرة قاعدة البيانات,التخزين,4,1,high,تعتمد عليها كل الخدمات تقريبا بوابة الدفع,"الشبكة,كشف الاحتيال",4,0.5,high,توقفها يوقف قبول الطلبات كشف الاحتيال,الشبكة,24,24,medium,ظن الفريق أنه خدمة ثانوية الموقع التعريفي,الشبكة,72,24,low,صفحات ثابتة لا تؤثر على البيع المحاسبة,قاعدة البيانات,24,24,medium,حرجة في نهاية الشهر فقط البريد,الشبكة,24,4,medium,للتواصل لا للبيع المباشر الشبكة,,2,0,high,بنية تحتية تعتمد عليها البقية التخزين,,2,1,high,بنية تحتية للبيانات ``` ولاحظ أننا كتبنا عمداً أن خدمة «كشف الاحتيال» MTD أربع وعشرون ساعة، لأن الفريق ظنها ثانوية، مع أن بوابة الدفع تعتمد عليها. والسكربت يقرأ الاعتماديات، ويحسب لكل خدمة أقصر مهلة يطلبها من يعتمد عليها، ويرتب: ```python """Turns a Business Impact Analysis sheet into a recovery plan input (NIST SP 800-34 concepts). The key check: a service inherits the TIGHTEST recovery target of everything that depends on it. A database marked 24h that a 4h store needs is really a 4h database, whether the team wrote that or not.""" import csv, sys, collections procs = {r["process"]: r for r in csv.DictReader(open(sys.argv[1], encoding="utf-8"))} deps = {p: [d.strip() for d in r["depends_on"].split(",") if d.strip()] for p, r in procs.items()} mtd = {p: float(r["mtd_hours"]) for p, r in procs.items()} dependents = {p: [x for x in procs if p in deps.get(x, [])] for p in procs} def required_mtd(p, seen=None): """The tightest MTD demanded of p: its own, and the required MTD of anything that needs p.""" seen = seen or set() if p in seen: return mtd[p] seen = seen | {p} return min([mtd[p]] + [required_mtd(x, seen) for x in dependents[p]]) req = {p: required_mtd(p) for p in procs} gaps = [(p, mtd[p], req[p]) for p in procs if req[p] < mtd[p]] print(f"{'process':20} {'stated MTD':>10} {'required MTD':>12} {'RPO':>6} {'impact':7} needed-by") for p in sorted(procs, key=lambda p: (req[p], mtd[p])): flag = " <-- tighter than stated" if req[p] < mtd[p] else "" print(f" {p[:18]:18} {mtd[p]:>8.0f}h {req[p]:>10.0f}h {procs[p]['rpo_hours']:>5}h {procs[p]['impact']:7} {len(dependents[p])}{flag}") print("\nhidden dependencies (a service is less critical on paper than what needs it):") for p, stated, real in gaps: who = ", ".join(x for x in dependents[p] if req[x] == real) or "a downstream process" print(f" {p}: team wrote {stated:.0f}h, but {who} needs {real:.0f}h -> set its target to {real:.0f}h") if not gaps: print(" none") tiers = collections.defaultdict(list) for p in procs: t = "1 (<=4h)" if req[p] <= 4 else "2 (<=24h)" if req[p] <= 24 else "3 (>24h)" tiers[t].append(p) print("\nrecovery tiers by required MTD:") for t in ("1 (<=4h)", "2 (<=24h)", "3 (>24h)"): print(f" Tier {t}: {', '.join(tiers[t]) or '-'}") print(f"\nstrictest RPO overall: {min(float(r['rpo_hours']) for r in procs.values())}h") ``` ```bash docker run --rm -v "$(pwd -W):/w" -w /w python:3.13.17-slim python bia.py bia.csv ``` والمخرج سوف يكون كما يلي: ```text process stated MTD required MTD RPO impact needed-by الشبكة 2h 2h 0h high 5 التخزين 2h 2h 1h high 1 المتجر الإلكتروني 4h 4h 1h high 0 قاعدة البيانات 4h 4h 1h high 2 بوابة الدفع 4h 4h 0.5h high 1 كشف الاحتيال 24h 4h 24h medium 1 <-- tighter than stated المحاسبة 24h 24h 24h medium 0 البريد 24h 24h 4h medium 0 الموقع التعريفي 72h 72h 24h low 0 hidden dependencies (a service is less critical on paper than what needs it): كشف الاحتيال: team wrote 24h, but بوابة الدفع needs 4h -> set its target to 4h recovery tiers by required MTD: Tier 1 (<=4h): المتجر الإلكتروني, قاعدة البيانات, بوابة الدفع, كشف الاحتيال, الشبكة, التخزين Tier 2 (<=24h): المحاسبة, البريد Tier 3 (>24h): الموقع التعريفي strictest RPO overall: 0.0h ``` في المخرج أعلاه لاحظ التالي: - **التناقض الذي كشفه:** خدمة كشف الاحتيال كتب لها الفريق أربعاً وعشرين ساعة، والسكربت يقول إن بوابة الدفع تحتاجها بأربع ساعات، فمهلتها الحقيقية أربع لا أربع وعشرون. وهذا أهم مخرج في الدراسة كلها: خدمة ظنها الفريق ثانوية تحميها بنسخة يومية، وهي في الحقيقة تحتاج حماية بأربع ساعات، ولو تعطلت لتعطل الدفع، وتعطل المتجر معه. - **الطبقات:** رتب السكربت العمليات في ثلاث طبقات بحسب المهلة الحقيقية: طبقة أولى خلال أربع ساعات فيها البنية التحتية وما يبيع مباشرة، وثانية خلال أربع وعشرين ساعة، وثالثة بعدها. وهذه الطبقات هي التي تقرر أين تنفق: الطبقة الأولى تستحق نسخة شبه لحظية وموقعاً جاهزاً، والثالثة نسخة يومية تكفيها. - **الاعتماديات أولاً:** الشبكة والتخزين في رأس القائمة رغم أنهما ليسا عمليات تبيع، لأن كل شيء يعتمد عليهما، فلا معنى لإعادة المتجر قبل الشبكة. - **أشد RPO:** صفر ساعة للشبكة وأقل من ساعة لبوابة الدفع، وهذا الرقم يحدد كم مرة تنسخ أهم البيانات، ويربط الخطة مباشرة بمقال النسخ الاحتياطي 3-2-1. ![ثلاث طبقات: الطبقة 1 خلال 4 ساعات فيها الشبكة والتخزين وقاعدة البيانات وبوابة الدفع وكشف الاحتيال والمتجر البنية التحتية ثم ما يبيع مباشرة، والطبقة 2 خلال 24 ساعة فيها المحاسبة والبريد مهم لكن يحتمل التأخير يوماً، والطبقة 3 بعد 24 ساعة فيها الموقع التعريفي صفحات ثابتة لا تؤثر على البيع](https://arabroot.io/content/images/2026/10/bcp-drp-05-tiers.webp) الطبقات تقرر أين تنفق: الطبقة الأولى نسخة شبه لحظية وموقع جاهز، والثالثة نسخة يومية وهذه الدراسة ليست وثيقة تكتب مرة، فالشركة تتغير: خدمة جديدة تضاف، أو عملية تصبح أهم بعد نمو المبيعات. لذلك تراجع كل سنة على الأقل، وبعد أي تغيير كبير، وإلا صارت تصف شركة لم تعد موجودة، كما يحدث للخطط التي تكتب وتنسى. وهذه الأرقام ليست رفاهية تنظيمية، وإنما ما يحول الخلاف بين العمل والتقنية من جدال إلى قرار. فحين يقول العمل «نريد RTO ساعة»، وتقول التقنية «الموقع الساخن الذي يحقق ذلك يكلف كذا شهرياً»، يصبح القرار واضحاً: هل خسارة الساعة أكبر من تكلفة الموقع الساخن؟ إن كانت، فالإنفاق مبرر؛ وإن لم تكن، فالعمل يقبل RTO أطول بوعي، لا بالصدفة. وهكذا تحول الدراسة قرار الاستعداد من خوف غامض إلى موازنة بين تكلفة التوقف وتكلفة الحماية، وهذا ما يفهمه المدير ويوقع عليه. ## استراتيجيات التعافي: أين تعيد التشغيل؟ بعد أن عرفت المهل، يأتي سؤال كيف تحققها، وأهم قرار فيه هو الموقع البديل Alternate Site: المكان الذي تعمل منه إذا تعطل موقعك الأصلي. ويصف [دليل NIST](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final?ref=arabroot.io) أربعة أنواع، والصورة التالية تبين المقايضة: ![أربع لوحات: بارد Cold مساحة وكهرباء وشبكة فقط بلا عتاد ولا بيانات رخيص والعودة أياماً، ودافئ Warm عتاد جاهز وبعض البيانات تحمل النسخة الأخيرة فتعمل في ساعات، وساخن Hot جاهز بالكامل وبيانات محدثة يعمل خلال وقت قصير تكلفة أعلى، ومرآة Mirrored نسخة طبق الأصل بتزامن لحظي لا خسارة بيانات تقريبا الأغلى RTO وRPO قرب الصفر](https://arabroot.io/content/images/2026/10/bcp-drp-03-sites.webp) كلما قصر RTO وRPO ارتفعت التكلفة، فاختر الموقع بحسب الطبقة لا بحسب الخوف - **الموقع البارد Cold Site:** مساحة وكهرباء وشبكة فقط، بلا عتاد ولا بيانات. رخيص، والعودة منه طويلة أياماً، لأنك تجهز كل شيء بعد الكارثة. يناسب الطبقة الثالثة. - **الموقع الدافئ Warm Site:** عتاد جاهز وبعض البيانات، تحمل عليه النسخة الأخيرة فيعمل في ساعات. متوسط التكلفة والسرعة. - **الموقع الساخن Hot Site:** جاهز بالكامل وبياناته محدثة، يعمل خلال وقت قصير. تكلفة أعلى، يناسب الطبقة الأولى. - **موقع المرآة Mirrored Site:** نسخة طبق الأصل بتزامن لحظي، لا خسارة بيانات تقريباً. الأغلى، لأنه موقع كامل يعمل دائماً. وفي السحابة تتحول هذه الأنواع إلى أنماط بأسماء أخرى، ولكنها نفس المقايضة: نسخة احتياطية فقط Backup and Restore تقابل البارد، وبيئة صغيرة جاهزة تشعل عند الحاجة Pilot Light تقابل الدافئ، ونسخة فعالة مصغرة Warm Standby، ونشط-نشط Active-Active يقابل المرآة. والميزة في السحابة أنك تدفع للموقع البديل بالاستخدام لا بالبناء، فالموقع البارد قد يكون مجرد نسخة في منطقة أخرى ونص Infrastructure as Code يبني البيئة عند الحاجة. والقاعدة واحدة في الحالتين: اختر لكل طبقة ما يحقق مهلتها بأقل تكلفة، لا أكثر، فحماية الموقع التعريفي بمرآة لحظية إنفاق في غير محله. ولا تنس أرخص استراتيجية وأكثرها إهمالاً: منع التعطل أصلاً. فالدليل يذكر الإجراءات الوقائية قبل التعافي: مصدر طاقة لا ينقطع UPS، وأقراص متوازية RAID، وتبديل تلقائي Failover، وعنقدة السيرفرات Clustering. فكل عطل تمنعه لا تحتاج أن تتعافى منه، والدينار في الوقاية أرخص من عشرة في التعافي. ### أنماط التعافي في السحابة بالتفصيل لأن أغلب الشركات الصغيرة اليوم على السحابة أو تتجه إليها، يستحق كل نمط شرحاً، فهي ليست مجرد أسماء جديدة للمواقع القديمة، وإنما تغير اقتصاد التعافي: - **نسخة واحتياطي فقط Backup and Restore:** تحتفظ بنسخ في منطقة أخرى، وعند الكارثة تبني البيئة من الصفر بنص Infrastructure as Code وتحمل النسخة. الأرخص، وRTO ساعات إلى يوم. يناسب الطبقة الثالثة وبعض الثانية. - **الشعلة الصغيرة Pilot Light:** تبقي أهم جزء يعمل دائماً بأصغر حجم، مثل قاعدة بيانات تتزامن، والبقية مطفأة جاهزة للإشعال. RTO أقصر لأن قلب النظام جاهز. يناسب الطبقة الثانية. - **الاحتياطي الدافئ Warm Standby:** نسخة كاملة من النظام تعمل بحجم مصغر، تكبرها عند الكارثة وتحول إليها الحركة. RTO دقائق إلى ساعة. يناسب الطبقة الأولى. - **نشط-نشط Active-Active:** منطقتان تعملان معاً وتستقبلان الحركة، فسقوط إحداهما لا يوقف الخدمة. RTO وRPO قرب الصفر، والأغلى، يناسب ما لا يحتمل أي توقف. والميزة الكبرى في السحابة أنك تدفع للموقع البديل بالاستخدام لا بالبناء: الموقع البارد قد يكون مجرد نسخ في منطقة أخرى ونص بناء، لا مبنى تستأجره. ولكن انتبه إلى فخين: الأول أن تظن أن مزودك السحابي يتكفل بالتعافي عنك، والحقيقة أنه مسؤول عن بنيته هو، وأنت مسؤول عن بياناتك وإعداداتك واستعادتها، وهذا ما يسمى المسؤولية المشتركة Shared Responsibility. والثاني أن تضع نسختك الاحتياطية في نفس حساب ونفس منطقة نظامك، فإذا اخترق الحساب أو سقطت المنطقة ضاع الاثنان معاً، وهذا يناقض قاعدة 3-2-1. ولتقدير حجم الاستثمار المناسب، وازن تكلفة التوقف مقابل تكلفة الحماية على مدى سنة. فإذا كان توقف المتجر ساعة يكلف مبلغاً، وموسم الذروة يرفعه أضعافاً، فاجمع الخسارة المتوقعة من احتمال التعطل عبر السنة، وقارنها بتكلفة الموقع البديل الذي يقصر التوقف. والنتيجة قد تفاجئك في الاتجاهين: أحياناً تكتشف أنك تدفع لحماية لا يبررها الأثر، وأحياناً أن ساعة واحدة من التوقف في الذروة أغلى من سنة كاملة من الموقع الساخن. وهذا الحساب هو ما يحول قرار الاستعداد من شعور إلى رقم يوقع عليه المدير بثقة. ## بنية الخطة واختبارها الخطة الجيدة ليست سرداً، وإنما وثيقة عملية يفتحها شخص مرعوب في الثالثة فجراً فيعرف ماذا يفعل. وتحتوي كحد أدنى: شروط التفعيل، أي متى نعلن أننا في حالة تعاف ومن يعلنها؛ والأدوار، من يقود ومن يتصل بمن؛ وترتيب التعافي بالطبقات من الدراسة؛ وخطوات كل نظام بالتفصيل، بما فيها من أين النسخة وكيف نتحقق أنها نظيفة؛ وجدول التواصل مع العملاء والموردين والجهات؛ وقائمة جهات الاتصال خارج ساعات العمل. ومقال [خطة الاستجابة](https://arabroot.io/articles/%D8%AE%D8%B7%D8%A9-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%84%D9%84%D8%AD%D9%88%D8%A7%D8%AF%D8%AB-incident-response-%D9%88%D9%83%D8%AA%D9%8A%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%B4%D8%BA%D9%8A%D9%84/) يفصل هذه البنية، وأغلبها مشترك بين خطتي الاستجابة والتعافي. ولكن الوثيقة وحدها لا تكفي، فالخطة التي لم تختبر لا تعمل يوم تحتاجها، والصورة التالية تبين سلم اختبارها: ![أربع درجات: مراجعة الخطة اقرأها مع الفريق هل الأرقام والأدوار والاعتماديات ما زالت صحيحة، ثم تمرين طاولة امش على سيناريو تعطل من يقرر ومتى، ثم اختبار استعادة استعد نسخة فعلاً على بيئة اختبار وقس كم استغرق مقابل RTO، ثم تجربة تبديل شغل من الموقع البديل فعلاً أقرب للواقع وأصعب](https://arabroot.io/content/images/2026/10/bcp-drp-06-test.webp) كل درجة أقرب للواقع وأصعب، والخطة الجيدة تصعد السلم تدريجياً - **مراجعة الخطة:** اقرأها مع الفريق، هل الأرقام والأدوار والاعتماديات ما زالت صحيحة؟ أرخص اختبار، ويكشف الخطة التي عفا عليها الزمن قبل أن تكتشفها الكارثة. - **تمرين الطاولة Tabletop:** امش على سيناريو تعطل، من يقرر ومتى، كما فصلنا في [مقال تمرين الطاولة](https://arabroot.io/articles/%D8%AA%D9%85%D8%B1%D9%8A%D9%86-%D8%A7%D9%84%D8%B7%D8%A7%D9%88%D9%84%D8%A9-tabletop-exercise-%D8%AC%D8%B1%D8%A8-%D8%AE%D8%B7%D8%A9-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%82%D8%A8%D9%84-%D8%A7%D9%84%D8%AD%D8%A7%D8%AF%D8%AB%D8%A9/). يكشف ثغرات الأدوار والقرارات دون أن يعطل نظاماً. - **اختبار الاستعادة:** استعد نسخة فعلاً على بيئة اختبار، وقس كم استغرق مقابل RTO. وهذا ما جربناه في [مقال النسخ الاحتياطي](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)، وهو ما يحول RTO من رقم على الورق إلى رقم مقاس. - **تجربة التبديل:** شغل من الموقع البديل فعلاً، وأوقف الأصلي، وتأكد أن العمل يستمر. أقرب للواقع وأصعب، ومكانها بعد نجاح الدرجات الأدنى. والخطأ الأشهر هنا أن يقاس RTO على الورق: «نقدر أن الاستعادة تأخذ أربع ساعات»، دون أن تجرب. فالاستعادة الحقيقية تكشف ما لا يظهر في التقدير: نسخة ناقصة، أو كلمة مرور مستودع ضاعت، أو أن تنزيل النسخة من التخزين البعيد وحده يأخذ ساعتين. والفرق بين RTO المقدر والمقاس هو الفرق بين خطة ووهم. ولتصميم خطة واقعية، ابدأ من أكثر ما يرجح أن يصيبك لا من أكثر ما يخيف. فالسيناريوهات التي تستحق خطة في أغلب الشركات الصغيرة والمتوسطة قليلة ومعروفة: فشل عتاد أو قرص، وفدية تشفر الأنظمة والنسخ القريبة، وانقطاع مزود سحابي أو مزود خدمة مهم، وخطأ بشري يحذف بيانات أو إعدادات، وكارثة مادية في الموقع مثل حريق أو فيضان. ولكل سيناريو استجابة مختلفة قليلاً: الفدية تحتاج نسخة لا يستطيع المهاجم حذفها، وانقطاع المزود يحتاج منطقة أو مزوداً بديلاً، والخطأ البشري يحتاج نسخاً تاريخية لا نسخة واحدة تكتب فوق سابقتها. فاكتب خطتك لتغطي هذه القليلة جيداً، لا لتغطي كل كارثة ممكنة بسطحية، فالعمق في القليل المهم أنفع من التغطية الواسعة التي لا تصمد عند أول اختبار. ## من الخطة إلى كتيب التشغيل Runbook الخطة تقول «أعد قاعدة البيانات»، وهذا لا يكفي في الثالثة فجراً. فالوثيقة التي تنفع فعلاً هي كتيب التشغيل Runbook: خطوات ترقيمية دقيقة لكل نظام، يستطيع أن يتبعها شخص ليس خبيراً في ذلك النظام بالذات. ويحتوي كتيب استعادة قاعدة البيانات مثلاً: من أين النسخة بالضبط، وكيف تتحقق أنها غير تالفة قبل أن تعتمد عليها، وما الأمر الدقيق للاستعادة، وكيف تتأكد أنها عملت، ومن تبلغ عند النجاح والفشل. والفرق بين خطة وكتيب أن الخطة تقرأ في اجتماع، والكتيب يتبع تحت الضغط، ولذلك يجب أن يكون بلا غموض ولا افتراضات معرفة مسبقة. وأفضل اختبار لكتيب التشغيل أن يتبعه شخص لم يكتبه. فمن يكتب الكتيب يعرف الخطوات الناقصة في رأسه، ويملؤها دون أن ينتبه، فيبدو الكتيب كاملاً وهو ليس كذلك. أما الشخص الجديد فيتوقف عند أول خطوة غامضة، فتظهر الفجوة. وهذه ممارسة بسيطة ورخيصة: اطلب من زميل لم يبن النظام أن يستعيده من الكتيب على بيئة اختبار، وراقب أين يتوقف، فكل توقف سطر يجب أن يضاف. وبهذا يتحول الكتيب من وثيقة يملكها شخص واحد إلى قدرة يملكها الفريق، وهذا هو الهدف: ألا يكون التعافي رهينة وجود شخص بعينه، فالكارثة لا تنتظر أن يكون أفضل خبرائك في المدينة. ## ماذا تطلب الضوابط الأساسية؟ الضوابط الأساسية للأمن السيبراني ECC تطلب استمرارية الأعمال في مكونين، والنصوص من [وثيقة ECC-2:2024](https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654%5FECC--2024-EN.pdf?ref=arabroot.io): | الضابط | ماذا يطلب | أين يقع في هذا المقال | | ------- | ------------------------------------------------------ | ------------------------------------------ | | 2-9-3-1 | شمول النسخ للأصول والمعلومات التقنية الحساسة | جرد العمليات في BIA وما تحميه أولاً | | 2-9-3-2 | القدرة على استعادة سريعة للبيانات والأنظمة بعد الحوادث | RTO والطبقات والموقع البديل | | 2-9-3-3 | الاختبار الدوري لفعالية استعادة النسخ | سلم الاختبار، خاصة اختبار الاستعادة المقاس | | 3-1-3-1 | ضمان استمرارية أنظمة الأمن السيبراني وإجراءاته | أن تعمل الحماية نفسها أثناء التعافي | | 3-1-3-2 | خطط استجابة للحوادث قد تؤثر على استمرارية الأعمال | ربط خطة الاستجابة بخطة التعافي | | 3-1-3-3 | تطوير خطط التعافي من الكوارث | بنية الخطة واختبارها | ولاحظ الضابط 3-1-3-1 الدقيق: ضمان استمرارية أنظمة الأمن نفسها. أي أن مراقبتك وجدار حمايتك وجمع سجلاتك يجب أن تعمل أثناء التعافي أيضاً، لا أن تتعطل مع ما تحميه. فالموقع البديل الذي يعيد المتجر دون أن يعيد المراقبة يعيدك أعمى، وهذا ما يغفل عنه من يخطط للتعافي التقني وحده. وهناك بعد إنساني يغفل عنه التخطيط التقني: من يستطيع تنفيذ الخطة إذا وقعت الكارثة في إجازة أو سفر أو مرض صاحب المعرفة الوحيد؟ فالخطة التي تعتمد على شخص واحد يعرف كيف يستعيد النظام هي نقطة فشل واحدة بشرية، أخطر من أي نقطة فشل تقنية، لأنك لا تستطيع أن تشتري احتياطياً لها بسرعة. ولذلك فجزء من الاستعداد أن يعرف أكثر من شخص كل مهمة حرجة، وأن تكون قائمة جهات الاتصال محدثة وفيها بدلاء، وأن تكون كتيبات التشغيل واضحة بما يكفي ليتبعها بديل. وهذا يربط التعافي بموضوع أوسع هو ألا تكون أي قدرة حرجة في شركتك معلقة بشخص واحد. ## أخطاء شائعة - **فجوة العمل والتقنية:** العمل يتوقع ساعتين والتقنية تستطيع اثنتي عشرة، ولا يكتشف أحد قبل الكارثة، وهذا ما تسده BIA. - **الخلط بين RTO وRPO:** الأول عن عودة الخدمة، والثاني عن البيانات المفقودة، وكل منهما يقوده قرار مختلف. - **تجاهل الاعتماديات الخفية:** خدمة تظنها ثانوية تحميها بنسخة يومية، وهي حرجة لأن خدمة مهمة تعتمد عليها. - **خطة تقنية بحتة:** تعيد السيرفرات وتنسى ماذا يقول العمل للعملاء ومن يعلن الكارثة. - **قياس RTO على الورق:** «نقدر أربع ساعات» دون أن تجرب، فتكتشف في الكارثة أن التنزيل وحده ساعتان. - **موقع بديل أغلى من اللازم:** مرآة لحظية للموقع التعريفي الثابت، إنفاق في غير محله. - **نسيان استمرارية الأمن:** تعيد الخدمة دون المراقبة، فتعود أعمى، وهذا ما يطلبه الضابط 3-1-3-1. - **خطة تكتب وتنسى:** لا تراجع بعد التغييرات، فتصف شركة لم تعد موجودة. - **إهمال الوقاية:** كل عطل تمنعه بـ UPS أو RAID أو تبديل تلقائي لا تحتاج أن تتعافى منه. ## قائمة تحقق | السؤال | كيف تتحقق | | ---------------------------------------------------- | ------------------------------------------- | | هل لكل عملية مهمة MTD وRTO وRPO متفق عليها مع العمل؟ | جدول من دراسة أثر الأعمال، معتمد من الإدارة | | هل نعرف اعتماديات كل عملية، ومهلة كل خدمة الحقيقية؟ | سكربت أو جدول يحسب أقصر مهلة مطلوبة | | هل رتبنا التعافي في طبقات، والاعتماديات أولاً؟ | قائمة التعافي بالطبقات | | هل الموقع البديل يناسب كل طبقة، لا أغلى ولا أرخص؟ | مطابقة نوع الموقع بمهلة الطبقة | | هل قست RTO باستعادة حقيقية، لا تقديراً؟ | اختبار استعادة على بيئة اختبار، بالوقت | | هل تعمل أنظمة الأمن نفسها أثناء التعافي؟ | الموقع البديل يعيد المراقبة مع الخدمة | | هل الخطة تقول من يعلن الكارثة وماذا نقول للعملاء؟ | جزء العمل في الخطة لا التقنية فقط | | متى اختبرنا الخطة آخر مرة، ومتى نراجعها؟ | جدول تمارين ومراجعة دورية | وبعد أن تبني الخطة وتختبرها، يبقى سؤال التحديث. فالدراسة التي رتبت العمليات في طبقات صحيحة اليوم قد تصبح خاطئة بعد ستة أشهر: خدمة جديدة أصبحت حرجة، أو مبيعات نمت فتغير أثر التوقف، أو مورد جديد أضاف اعتمادية لم تكن موجودة. ولهذا لا تكتمل الخطة باعتمادها، وإنما تدخل دورة مراجعة: مراجعة دورية كل سنة على الأقل، ومراجعة بعد كل تغيير كبير، وتحديث بعد كل تمرين أو حادثة حقيقية كشفت ثغرة. والخطة الحية التي تراجع هي التي تعمل يوم الكارثة، أما الخطة التي كتبت لتعتمد ثم نسيت في الدرج فهي أسوأ من لا خطة، لأنها تعطي شعوراً زائفاً بالاستعداد. ## الخلاصة - ثلاثة أرقام تقود كل شيء: MTD أقصى توقف محتمل، وRTO متى تعود الخدمة، وRPO كم بيانات تخسر، وRTO أقصر من MTD دائماً. - BCP عن استمرار العمل، وDRP عن إعادة التقنية، وISCP لكل نظام، والشركة الصغيرة قد تدمجها بشرط تغطية المستويات. - دراسة أثر الأعمال تقرر ما تحميه أولاً، وتكشف الاعتماديات الخفية: خدمة ترث أقصر مهلة يطلبها من يعتمد عليها. - في التجربة كشف السكربت خدمة كتب لها الفريق 24 ساعة وهي تحتاج 4، لأن بوابة الدفع تعتمد عليها. - الموقع البديل من البارد إلى المرآة، وفي السحابة من نسخة فقط إلى نشط-نشط، اختر لكل طبقة ما يحقق مهلتها بأقل تكلفة. - الخطة التي لم تختبر لا تعمل: اصعد سلم الاختبار من المراجعة إلى تمرين الطاولة إلى الاستعادة المقاسة. - الضوابط 2-9 و3-1 في ECC تطلب النسخ والاستعادة السريعة واختبارها وخطط التعافي واستمرارية أنظمة الأمن نفسها. وأقرب المقالات إلى هذا الموضوع في المسار: [![](https://arabroot.io/content/images/2026/10/backup-321-cover-cover.webp)دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)[![](https://arabroot.io/content/images/2026/10/tabletop-exercise-cover-cover.webp)دليلتمرين الطاولة Tabletop: جرب خطة الاستجابة قبل الحادثةمشينا فريقاً على سيناريو فدية بست حقن، فأظهر التمرين خمس ثغرات في الخطة وقراراً بلا مالك، وحولنا نقاشه إلى أرقام وأوامر عمل.](https://arabroot.io/articles/%D8%AA%D9%85%D8%B1%D9%8A%D9%86-%D8%A7%D9%84%D8%B7%D8%A7%D9%88%D9%84%D8%A9-tabletop-exercise-%D8%AC%D8%B1%D8%A8-%D8%AE%D8%B7%D8%A9-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%82%D8%A8%D9%84-%D8%A7%D9%84%D8%AD%D8%A7%D8%AF%D8%AB%D8%A9/)[![](https://arabroot.io/content/images/2026/10/ir-playbooks-cover-cover.webp)دليلخطة الاستجابة للحوادث Incident Response وكتيبات التشغيل Playbooksخطة استجابة وكتيبا حساب مخترق وفدية على NIST SP 800-61r3، مع مختبر نستعيد فيه البيانات من نسخة restic.](https://arabroot.io/articles/%D8%AE%D8%B7%D8%A9-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%84%D9%84%D8%AD%D9%88%D8%A7%D8%AF%D8%AB-incident-response-%D9%88%D9%83%D8%AA%D9%8A%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%B4%D8%BA%D9%8A%D9%84/)[![](https://arabroot.io/content/images/2026/10/risk-register-cover-cover.webp)دليلسجل المخاطر Risk Register مع SimpleRisk على سيرفركنبني سجل مخاطر حقيقياً بنموذج الهيئة ثم بأداة SimpleRisk، ونرى لماذا أعطت الأداة كل المخاطر مستوى واحداً، وكيف تكتب منهجية تعطي الأرقام معناها.](https://arabroot.io/articles/%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-risk-register-%D9%85%D8%B9-simplerisk/)[![](https://arabroot.io/content/images/2026/10/nca-ecc-cover-cover.webp)دليلالضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطةكيف تقرأ الضوابط الأساسية ECC دون أن تضيع في أرقامها، وعلى من تنطبق، وما المطلوب من جهتك فعلاً في كل مكون.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%84%D8%A7%D8%B3%D8%A7%D8%B3%D9%8A%D8%A9-%D9%84%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-nca-ecc-%D8%A8%D9%84%D8%BA%D8%A9-%D8%A8%D8%B3%D9%8A%D8%B7%D8%A9/)[![](https://arabroot.io/content/images/2026/10/compromised-linux-cover-cover.webp)دليلفحص سيرفر Linux مخترق دون أن تفسد الأدلةفحصنا سيرفراً مخترقاً في المختبر خطوة خطوة بالطريقة الصحيحة، فوجدنا برنامجاً من ملف محذوف وأمر ls مزروعاً ووقتاً مزوراً، دون أن نفسد دليلاً.](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-linux-%D9%85%D8%AE%D8%AA%D8%B1%D9%82-%D8%AF%D9%88%D9%86-%D8%A7%D9%86-%D8%AA%D9%81%D8%B3%D8%AF-%D8%A7%D9%84%D8%A7%D8%AF%D9%84%D8%A9/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال، ودراسة أثر مصغرة بسكربت على Python 3.13.17، بالاستناد إلى NIST SP 800-34 وضوابط ECC-2:2024.