بیشتر سازمان‌هایی که «طرح تداوم کسب‌وکار» دارند، در واقع سندی دارند که یک بار برای ممیزی نوشته شده، در پوشه‌ای است، و هیچ‌کس محتوایش را به یاد نمی‌آورد. روز حادثه، آن سند کمکی نمی‌کند.
اول: چه چیزی واقعاً حیاتی است
همهٔ سرویس‌ها به یک اندازه مهم نیستند و تظاهر به اینکه هستند، طرح را غیرقابل اجرا می‌کند. با کسب‌وکار بنشینید و بپرسید: اگر این سرویس چهار ساعت نباشد چه می‌شود؟ اگر دو روز نباشد چه؟
پاسخ‌ها معمولاً غافلگیرکننده‌اند. گاهی سامانه‌ای که تیم فنی حیاتی می‌داند، برای کسب‌وکار قابل تحمل است — و برعکس.
دوم: سناریوهای واقعی، نه فهرست بلند
طرحی که برای بیست سناریو نوشته شده، معمولاً برای هیچ‌کدام آماده نیست. چهار سناریو تقریباً همهٔ حالت‌های عملی را پوشش می‌دهد:
- خرابی یک سرور یا سرویس
- از دست رفتن یا رمزگذاری‌شدن داده
- از دسترس خارج شدن کل محل (برق، آتش، دسترسی)
- در دسترس نبودن افراد کلیدی
سناریوی چهارم بیشترین بی‌توجهی را می‌بیند و در عمل شایع‌ترین است.
سوم: چه کسی چه کاری می‌کند
در ساعت سه بامداد، کسی سند سی‌صفحه‌ای نمی‌خواند. آنچه لازم است یک صفحه است با سه چیز: چه کسی تصمیم می‌گیرد، با چه کسی تماس گرفته شود (با شماره)، و گام‌های اول چیست.
این یک صفحه باید جایی باشد که بدون شبکهٔ سازمان در دسترس باشد. طرح تداومی که فقط روی سرور فایل سازمان است، در سناریویی که همان سرور از دسترس خارج شده بی‌فایده است.
چهارم: تمرین
این تنها بخشی است که طرح واقعی را از سند تشریفاتی جدا می‌کند. لازم نیست تمرین پرهزینه باشد:
- یک بازیابی واقعی از نسخهٔ پشتیبان، هر فصل
- یک تمرین گفتاری: «فرض کنید سرور اصلی از کار افتاده — قدم به قدم بگویید چه می‌کنید»
- آزمون فهرست تماس: آیا شماره‌ها هنوز درست‌اند؟
هر تمرین، چند فرض اشتباه را آشکار می‌کند. بهتر است آن‌ها را در تمرین کشف کنید تا در حادثه.
خلاصه: طرحی که تمرین نشده، فرض است نه طرح — دقیقاً مثل نسخهٔ پشتیبانی که آزمون بازیابی نشده.