وقتی همه سرویس‌ها بحرانی هستند، هیچ سرویسی بحرانی نیست؛ خطاهای رایج در BIA

فرض کنید در یک سازمان ۶۰ سرویس فناوری اطلاعات بررسی می‌شود و خروجی کارگاه BIA این است: «۵۸ سرویس بحرانی هستند و دو سرویس هم تقریباً بحرانی». روی کاغذ، سازمان بسیار حساس به نظر می‌رسد؛ اما در جلسه بحران یک سؤال ساده همه‌چیز را به چالش می‌کشد: اگر قطع هم‌زمان چند سرویس رخ دهد، دقیقاً کدام‌یک باید زودتر برگردد؟

این همان جایی است که یک BIA ظاهراً کامل می‌تواند از نظر مدیریتی بی‌فایده باشد. BIA قرار نیست فقط فهرستی از سرویس‌های «مهم» تولید کند؛ خروجی آن باید مبنایی برای تعیین اولویت‌های تداوم، نیازمندی‌های بازیابی، منابع و وابستگی‌ها باشد. استاندارد ISO/TS 22317:2021 نیز BIA را فرایندی برای تحلیل اثر اختلال و رسیدن به «اولویت‌ها و الزامات تداوم کسب‌وکار» معرفی می‌کند، نه یک برچسب‌گذاری ساده برای دارایی‌ها یا سرویس‌ها. این سند همچنین تصریح می‌کند که در BIA ممکن است افراد نیازهای خود را بیش از حد خطیر یا برعکس بیش از حد کم اهمیت در نظر گیرند و روش BIA باید برای کاهش این سوگیری‌ها طراحی شود.

بنابراین، مسئله اصلی این نیست که یک سرویس «بحرانی است یا نیست»؛ مسئله این است که اختلال آن، در چه بازه زمانی، چه اثری بر محصولات و خدمات سازمان می‌گذارد و برای جلوگیری از عبور از آستانه غیرقابل‌قبول چه زمان و منابعی لازم است.

BIA دقیقاً چه چیزی را باید اولویت بندی کند؟

یکی از خطاهای اصلی در BIA این است که سازمان مستقیماً از «دارایی یا سرویس حوزه فناوری» شروع کند. در رویکرد استاندارد ISO/TS 22317:2021، اولویت‌بندی محصولات و خدمات نقطه شروع است و سپس فعالیت‌های اولویت‌دار، منابع و وابستگی‌های آن‌ها بررسی می‌شوند. این ترتیب مهم است، چون ارزش یک سرویس حوزه فناوری به‌تنهایی تعیین‌کننده نیست؛ ارزش آن در زنجیره ارائه محصول یا خدمت سازمان مشخص می‌شود.

برای مثال، «سامانه مدیریت مشتری» ممکن است در واحد فناوری یک سرویس حیاتی تلقی شود. اما اگر فرآیندهای فروش و پشتیبانی بتوانند برای چهار ساعت با روش دستی ادامه دهند، نتیجه BIA باید با سازمانی که بدون آن سامانه ظرف ۳۰ دقیقه با پیامد غیرقابل‌قبول مواجه می‌شود متفاوت باشد.

6 خطای رایج در اجرای BIA و اولویت‌بندی سرویس‌های سازمانی

خطای اول: برچسب بحرانی  را به یک برچسب دائمی تبدیل کنیم

بحرانی بودن نباید ویژگی ذاتی و همیشگی یک سرویس تلقی شود. یک سرویس ممکن است برای یک محصول یا فعالیت مشخص، در یک بازه زمانی مشخص، نیازمند بازیابی سریع باشد و برای فعالیت دیگری چنین ضرورتی نداشته باشد.

مثلاً در یک شرکت تولیدی، سرویس احراز هویت کارکنان در زمان شیفت تولید می‌تواند اثر مستقیم بر عملیات داشته باشد، اما همان سرویس برای یک فرایند آرشیوی که روزانه اجرا می‌شود، الزام زمانی یکسانی ندارد. اگر هر دو را صرفاً «بحرانی» بنامیم، تفاوت تصمیم‌گیری از بین می‌رود.

راهکار عملی این است که به‌جای پرسش «آیا سرویس بحرانی است؟» از چهار پرسش استفاده شود:

۱) کدام محصول، خدمت یا فعالیت به این سرویس وابسته است؟

۲) اثر اختلال در طول زمان چگونه تغییر می‌کند؟

۳) آستانه غیرقابل‌قبول اختلال چه زمانی رخ می‌دهد؟

۴) اگر چند سرویس هم‌زمان مختل شوند، ترتیب بازیابی چگونه تعیین می‌شود؟

این تغییر پرسش، BIA را از یک فرم دارایی‌محور به یک ابزار تصمیم‌گیری تبدیل می‌کند.

خطای دوم: یکسان انگاشتن  MTPD و RTO

پارامترهای MTPD و RTO هر دو به زمان مربوط‌اند، اما مفهوم یکسانی ندارند. استاندارد ISO/TS 22317:2021 در خروجی‌های BIA، MTPD را به برآورد زمانی مرتبط می‌کند که پس از اختلال، اثرات نامطلوب برای محصول یا خدمت به سطح غیرقابل‌قبول می‌رسند؛ RTO نیز به‌عنوان یک نیازمندی بازیابی برای فعالیت‌های اولویت‌دار مطرح می‌شود.

اگر یک سازمان برای سرویس پرداخت خود RTO را «چهار ساعت» تعیین کند، این عدد به‌تنهایی پاسخ نمی‌دهد که آیا تحمل اختلال چهار ساعت است یا فقط هدف سازمان این است که قبل از آن سرویس را برگرداند. در طراحی BIA باید رابطه منطقی بین آستانه تحمل و هدف بازیابی روشن باشد.

یک کنترل ساده برای مستند BIA این است: برای هر فعالیت، دو ستون مستقل تعریف گردد:

• پارامتر MTPD: بعد از چه مدتی ادامه اختلال از منظر کسب‌وکار غیرقابل‌قبول می‌شود؟
• پارامتر RTO: سازمان می‌خواهد فعالیت تا چه زمانی دوباره قابل‌استفاده شود؟

اگر پارامتر RTO از MTPD بزرگ‌تر باشد، باید توضیح مکتوبی برای این ناسازگاری وجود داشته باشد؛ در غیر این صورت، خروجی BIA از نظر تصمیم‌گیری قابل اتکا نیست.

خطای سوم: پارامتر RPO  را برای همه سرویسها یکسان تعیین کنیم

پارامتر RPO پاسخ یک سؤال متفاوت است: 

در بازیابی، سازمان تا چه میزان از دست رفت داده را می‌پذیرد؟

این موضوع به ماهیت فعالیت و داده وابسته است و لزوماً با بحرانی بودن یک سرویس یکی نیست.

دو سرویس ممکن است نیازمند بازیابی سریع باشند، اما یکی داده‌هایی داشته باشد که از دست رفتن چند دقیقه از آن‌ها قابل‌تحمل نیست و دیگری بتواند با بازسازی داده‌های چند ساعت گذشته ادامه دهد. بنابراین «بحرانی» بودن نباید خودکار به یک RPO ثابت منجر شود.

در عمل، پارامتر RPO باید با جریان داده، نقطه‌های پشتیبان‌گیری، قابلیت تکثیر، وابستگی‌های زیرساختی و روش بازسازی سازگار باشد. اگر BIA یک RPO بسیار سخت‌گیرانه تعیین کند ولی معماری فنی سازمان توان دستیابی به آن را نداشته باشد، BIA به‌جای اینکه نیاز کسب‌وکار را به برنامه بازیابی منتقل کند، یک شکاف پنهان ایجاد کرده است.

خطای چهارم: وابستگیها را در انتهای کار اضافه کنیم 

در بسیاری از سازمان ها ابتدا سرویس‌ها رتبه‌بندی می‌شوند و در مرحله‌ای جداگانه از تیم فناوری پرسیده می‌شود «این سرویس به چه چیزهایی وابسته است؟». این ترتیب می‌تواند نتیجه را گمراه کند.

استاندارد ISO/TS 22317:2021 شناسایی منابع، وابستگی‌ها، تأمین‌کنندگان، شرکا و ذی‌نفعان را بخشی از خروجی‌های BIA می‌داند. یک سرویس با RTO یک‌ساعته، اگر به سامانه  احراز هویت، لینک ارتباطی، دیتابیس، DNS، نیروی متخصص و یک تأمین‌کننده بیرونی وابسته باشد، عملاً به همان اندازه سریع قابل بازیابی نیست مگر اینکه این زنجیره نیز برای آن هدف آماده باشد.

برای هر فعالیت اولویت‌دار، یک زنجیره وابستگی ثبت کنید:

محصول/خدمت ← فعالیت ← سرویس/سامانه ← داده ← زیرساخت ← نیروی انسانی ← تأمین‌کننده/شریک.

سپس برای هر حلقه مشخص کنید RTO، RPO، ظرفیت جایگزین و مسئول بازیابی چیست. این کار معمولاً سرویس‌هایی را آشکار می‌کند که در فهرست BIA «کم‌اهمیت» دیده شده‌اند اما در عمل گلوگاه چند سرویس مهم هستند.

خطای پنجم: همه واحدها نیاز زمانی خود را بدون چالش وارد BIA کنند

BIA ذاتاً با قضاوت سازمانی سروکار دارد. استاندارد ISO/TS 22317:2021 صراحتاً اشاره می‌کند که افراد مختلف می‌توانند دیدگاه‌های متفاوتی درباره زمان‌بحرانی بودن یا میزان اثر اختلال داشته باشند و برخی نیازهای خود را بیش از حد بحرانی یا بیش از حد کم اهمیت برآورد کنند.

بنابراین BIA نباید فقط یک پرسش‌نامه جمع‌آوری‌شده باشد. اگر مدیر هر واحد RTO را یک ساعت اعلام کند، این عدد هنوز «نیازمندی معتبر» نیست؛ باید با شواهد عملیاتی، تعهدات قراردادی، الزامات قانونی، درآمد یا خدمت وابسته، حجم تراکنش، روش دستی جایگزین و اثر زنجیره‌ای آن بررسی شود.

یک روش مفید، درخواست دلیل و شواهد برای نیازمندی‌های سخت‌گیرانه است. هرجا واحدی RTO بسیار کوتاه اعلام می‌کند، حداقل یکی از این شواهد را بخواهید:

 SLA/قرارداد، الزام قانونی، سناریوی عملیاتی، داده تاریخی، وابستگی فرایندی یا برآورد مالی/عملیاتی. 

هدف، رد کردن نظر واحد کسب‌وکار نیست؛ هدف تبدیل «احساس اهمیت» به «نیاز قابل دفاع» است.

خطای ششم:  بحرانی بودن سرویس را با دسترس پذیری بالا آن  یکی بدانیم 

دسترس پذیری بالا مهم است، اما دسترس پذیری بالا به‌تنهایی BIA نیست. BIA درباره اثر اختلال بر کسب‌وکار و نیازهای تداوم تصمیم می‌گیرد؛ معماری فنی باید نشان دهد برای برآورده کردن این نیازها چه راهکارهایی لازم است.

برای نمونه، ممکن است یک سرویس ۹۹٫۹۹٪ دسترس پذیری داشته باشد، اما در صورت خرابی کامل مرکز داده هنوز RTO مورد انتظار کسب‌وکار را پوشش ندهد. برعکس، یک سرویس داخلی ممکن است دسترس‌پذیری پایین‌تری داشته باشد ولی به دلیل وجود روش دستی، MTPD طولانی‌تری داشته باشد.

پس خروجی BIA نباید با عبارت «این سرویس باید همیشه در دسترس باشد» تمام شود. باید به نیاز قابل‌اندازه‌گیری تبدیل شود: چه مدت اختلال قابل‌تحمل است، چه داده‌ای باید حفظ شود، چه منابعی لازم است و وابستگی‌ها چه هستند.

یک چارچوب عملی برای جلوگیری از بحرانی فرض  کردن همه چیز

برای یک BIA سازمانی، می‌توان از یک مدل چهارمرحله‌ای استفاده کرد. این مدل الزام استاندارد نیست؛ یک چارچوب اجرایی پیشنهادی برای تبدیل نتایج BIA به تصمیم‌های قابل‌استفاده است.

مرحله ۱ — Business First: ابتدا محصولات و خدمات و سپس فعالیت‌های پشتیبان آن‌ها فهرست گردد. از شروع مستقیم با CMDB یا فهرست سرورها خودداری شود.

مرحله ۲ — Time-Based Impact: اثر اختلال در چند نقطه زمانی ثبت شود؛ مثلاً ۳۰ دقیقه، ۲ ساعت، ۸ ساعت، ۲۴ ساعت و ۷۲ ساعت. اعداد فقط نمونه‌اند و باید متناسب با کسب‌وکار تعیین شوند.

مرحله ۳ — Requirement Validation: برای MTPD، RTO و RPO منطق و شواهد ثبت گردد و موارد متعارض به مالک کسب‌وکار و مدیریت ارجاع شود.

مرحله ۴ — Dependency-Aware Priority: اولویت نهایی پس از بررسی منابع و وابستگی‌ها تثبیت شود. یک سرویس کم‌اولویت که پیش‌نیاز چند فعالیت اولویت‌دار است، ممکن است در برنامه بازیابی جایگاه متفاوتی پیدا کند.

در پایان می‌توان یک جدول تصمیم‌گیری داشت:

سطوح پیشنهادی اولویت‌بندی تصمیم‌گیری (P1 تا P4)

•  P1: فعالیت‌های مأموریت‌محور/غیرقابل‌تعویق
•  P2: فعالیت‌های زمان‌بحرانی با پنجره تحمل محدود
•  P3: فعالیت‌های مهم با امکان تأخیر کنترل‌شده
•  P4: فعالیت‌های قابل‌تعویق یا دارای جایگزین موقت

این چهار سطح نمونه‌اند و نباید به‌عنوان طبقه‌بندی اجباری ISO معرفی شوند. نکته مهم این است که معیارهای هر سطح قبل از شروع ارزیابی تعریف و با مدیریت تأیید شوند.

مطالعه موردی: چرا سامانه‌های هم‌سطح نیازمند RTO متفاوتی هستند؟

فرض کنید یک سازمان سه فعالیت دارد: پاسخ‌گویی به مشتری، پرداخت حقوق و گزارش‌گیری مدیریتی. هر سه از سامانه‌های فاوا استفاده می‌کنند.

اگر فقط نام سرویس‌ها مدنظر قرار گیرد، ممکن است هر سه «مهم» باشند. اما در BIA، اثر زمانی متفاوت است. اختلال سامانه پاسخ‌گویی ممکن است پس از چند ساعت باعث افزایش صف و نقض SLA شود؛ اختلال پرداخت حقوق ممکن است در یک روز مشخص اثر شدیدتری داشته باشد؛گزارش‌گیری مدیریتی شاید با تأخیر یک‌روزه همچنان قابل انجام باشد.

نتیجه درست این نیست که یکی «مهم» و دو مورد «غیرمهم» هستند. نتیجه این است که هرکدام نیاز تداوم متفاوتی دارند. بنابراین، BIA خوب به تیم DR نمی‌گوید «این سه سرویس بحرانی هستند»؛ می‌گوید «برای این فعالیت‌ها، در این شرایط و با این وابستگی‌ها، این نیازهای بازیابی باید برآورده شوند».

نشانه های یک سند BIA که باید دوباره بررسی شود

اگر در خروجی BIA یکی از این الگوها دیده می‌شود، ارزش دارد روش کار بازبینی شود:

• بیش از بخش بزرگی از سرویس‌ها بدون تفکیک زمانی بحرانی شده‌اند.
• تقریباً همه RTOها یکسان هستند.
• MTPD در مستندات وجود ندارد یا با RTO خلط شده است.
• RPO برای سرویس‌های متفاوت به‌صورت کپی‌شده تعیین شده است.
• وابستگی‌های شخص ثالث یا نیروی انسانی ثبت نشده‌اند.
• هیچ شواهدی برای نیازهای زمانی سخت‌گیرانه وجود ندارد.
• اولویت‌ها فقط توسط فناوری تعیین شده‌اند و مالک کسب‌وکار نقش تصمیم‌گیر نداشته است.
• خروجی BIA به برنامه بازیابی، ظرفیت زیرساخت یا سناریوهای آزمون متصل نشده است.

وجود هرکدام از این موارد به‌تنهایی اثبات نمی‌کند که BIA نادرست است، اما نشان می‌دهد باید منطق تصمیم‌گیری و شواهد پشت آن دوباره بررسی شود.

جمع‌بندی و نتیجه‌گیری عملیاتی

BIA زمانی ارزش واقعی ایجاد می‌کند که منابع محدود سازمان را به تصمیم‌های قابل دفاع درباره تداوم کسب‌وکار متصل کند. بحرانی لحاظ کردن همه سرویس‌ها ممکن است در نگاه اول محافظه‌کارانه باشد، اما اگر تفاوت میان اولویت‌ها، زمان تحمل اختلال، هدف بازیابی، نیاز داده و وابستگی‌ها را از بین ببرد، عملاً کارکرد اولویت‌بندی را تضعیف می‌کند.

استاندارد ISO/TS 22317:2021 بر خروجی‌هایی مانند اولویت محصولات و خدمات، اثر اختلال در طول زمان، MTPD، RTO، منابع و وابستگی‌ها تأکید دارد؛ NIST نیز بر پیوند دادن نتایج BIA با مأموریت‌های سازمان، دارایی‌ها و اولویت‌بندی بازیابی تأکید می‌کند. بنابراین یک BIA قابل اتکا باید بتواند به یک سؤال عملی پاسخ دهد: «اگر منابع بازیابی کافی برای همه چیز هم‌زمان نداریم، چرا این فعالیت باید قبل از آن یکی بازیابی شود؟»

اگر پاسخ این سؤال در مستند BIA روشن، مستند و قابل دفاع نیست، احتمالاً هنوز با یک فهرست سرویس‌های بحرانی روبه‌رو هستیم، نه یک ابزار تصمیم‌گیری تداوم کسب‌وکار.

اگر سازمان شما در تعیین اولویت سرویس‌ها، محاسبه دقیق RTO/RPO، زنجیره وابستگی‌ها یا هم‌راستاسازی فرایندهای تداوم کسب‌وکار با ریسک‌های فناوری با چالش روبه‌رو است، تیم تخصصی ما در امن‌افزار گستر آپادانا می‌تواند در طراحی، ممیزی و استقرار چارچوب‌های استاندارد ISO 22301 و ISO 22317 همراه شما باشد. جهت دریافت مشاوره تخصصی به بخش خدمات مشاوره امنیت اطلاعات و سایبری و تداوم کسب‌وکار مراجعه کنید.