تداوم کسبوکار و بکاپ, مجله راگا
هزینه واقعی قطعی سرویس و نقطه شروع تداوم کسبوکار
شهریور
صبح روز پرداخت حقوق و تسویه با پیمانکاران است. در سازمان فرضی این روایت، کارکنان واحد مالی نمیتوانند وارد سامانه شوند. ابتدا همه تصور میکنند اختلال کوتاه است؛ یک تماس با پشتیبانی، چند دقیقه انتظار و ادامه کار. اما وقتی تماسهای منابع انسانی بیشتر میشود و یکی از پیمانکاران درباره پرداخت معوق پیگیری میکند، مسئله از اتاق سرور خارج شده است. مدیرعامل زمان مشخص میخواهد و مدیر فناوری هنوز در حال بررسی زنجیره وابستگی سامانه است.
چند ساعت بعد، دسترسی برقرار میشود. روی نمایشگر مانیتورینگ همه چیز عادی به نظر میرسد، اما برای واحد مالی کار تمام نشده است. باید مشخص شود کدام پرداخت انجام شده، کدام درخواست در صف مانده و آیا اطلاعات ثبتشده پیش از اختلال سالم است. اعتماد به سامانه نیز فوراً به وضعیت قبل برنمیگردد. این فاصله میان بازگشت فنی سرویس و بازگشت واقعی عملیات، نقطه شروع بحث تداوم کسبوکار است.
برای تصمیم درباره زیرساخت، ابتدا باید بدانیم چه کاری در سازمان نباید متوقف بماند، توقف آن چه پیامدی دارد و چه سطحی از خدمت باید در زمان اختلال حفظ شود. پاسخ این پرسشها تعیین میکند بودجه محدود را کجا صرف کنیم و از راهکار فنی چه انتظاری داشته باشیم.
تداوم کسبوکار چه مسئلهای را حل میکند
تداوم کسبوکار یعنی سازمان برای ادامه فعالیتهای اولویتدار خود هنگام اختلال و بازگشت کنترلشده به وضعیت عادی، برنامه و توان اجرایی داشته باشد. این موضوع کارکنان، فرایندها، تأمینکنندگان، ارتباطات و فناوری را در بر میگیرد. در مثال پرداخت حقوق، داشتن نسخه پشتیبان لازم است، اما باید مسئول تصمیم، مسیر ارتباط با کارکنان و روش رسیدگی به پرداختهای نامشخص نیز معلوم باشد.
مدیر فناوری میتواند سرور را راهاندازی کند؛ تعیین اولویت حقوق در برابر تسویه یک قرارداد، تصمیم مشترک مدیران کسبوکار است. اگر این اولویتها از قبل مشخص نشده باشند، تیم فنی در روز حادثه با چند درخواست فوری و متعارض مواجه میشود. هر مدیر واحد، سرویس خودش را مهمترین سرویس سازمان میداند و زمان محدود تیم بین درخواستها تقسیم میشود.
راهنمای برنامهریزی تداوم سامانههای اطلاعاتی NIST، تحلیل اثر بر کسبوکار را مبنایی برای تعیین نیازها و اولویتهای بازیابی قرار میدهد. کاربرد این نگاه برای سازمان ما روشن است: قبل از خرید راهکار، باید اثر توقف فعالیتها و وابستگی آنها به منابع مشخص شود. [۱]
هزینه قطعی در کدام بخشهای سازمان دیده میشود
بخشی از هزینه، مستقیم و قابل ثبت است؛ مانند اضافهکاری برای بازسازی اطلاعات، هزینه خدمات اضطراری و جریمهای که واقعاً طبق قرارداد ایجاد شده است. اما هر تأخیر لزوماً جریمه ندارد و نباید برای بزرگتر نشان دادن مسئله، هزینه فرضی را قطعی حساب کنیم. واحد مالی باید مشخص کند چه هزینهای پرداخت شده و چه هزینهای صرفاً یک احتمال است.
بخش دیگری به بهرهوری مربوط میشود. کارشناسان مالی، مدیران تأییدکننده و نیروهای منابع انسانی بخشی از روز را صرف پیگیری اختلال کردهاند. برای برآورد اولیه میتوان زمان ازدسترفته را محاسبه کرد، اما ضرب تعداد کارکنان در کل ساعات قطعی همیشه دقیق نیست. ممکن است بعضی کارکنان کار جایگزین داشته باشند و بخشی از فعالیت بعداً جبران شود.
در کنار این موارد، تأخیر در تصمیم و تعهد نیز اهمیت دارد. اگر گزارش نقدینگی آماده نباشد، یک تصمیم خرید یا تأمین مالی به تعویق میافتد. اگر پرداخت پیمانکار نامشخص بماند، رابطه کاری تحت فشار قرار میگیرد. این آثار را بهتر است با شرح پیامد و بازه برآورد ثبت کنیم؛ تبدیل فوری تمام آنها به یک عدد بزرگ، اعتبار گزارش را کاهش میدهد.
چرا اعتبار سازمان با روشن شدن سرور ترمیم نمیشود
کارکنان و طرفهای قرارداد معمولاً نمیدانند علت اختلال چه بوده است. آنها نتیجه را میبینند: سازمان در زمان وعدهدادهشده نتوانسته تعهدش را انجام دهد یا درباره وضعیت پاسخ روشنی بدهد. اگر ارتباطات مبهم باشد، افراد برای توضیح خلأ اطلاعات به حدس و شنیدهها متوسل میشوند. در چنین شرایطی، کیفیت اطلاعرسانی میتواند به اندازه سرعت رفع اختلال بر تجربه آنها اثر بگذارد.
این موضوع به معنی اعلام جزئیات فنی یا انتشار عجولانه علت حادثه نیست. یک پیام مشخص میتواند بگوید چه خدمتی تحت تأثیر قرار گرفته، اقدام موقت چیست و بهروزرسانی بعدی چه زمانی انجام میشود. اگر علت هنوز تأیید نشده، بهتر است همان وضعیت گفته شود. وعده زمان بازگشت بدون پشتوانه، ممکن است فشار بعدی را بیشتر کند.
برای سنجش اثر اعتباری هم میتوان از نشانههای قابل مشاهده استفاده کرد: تعداد شکایتها، موارد تشدید پیگیری، درخواست تضمین بیشتر یا تغییر رفتار یک شریک تجاری. این شواهد از یک ادعای کلی درباره «نابودی برند» مفیدترند. هدف، شناخت حساسیت روابط سازمان است تا تصمیم درباره پایداری به تجربه واقعی ذینفعان متصل شود.
تحمل قطعی برای همه سرویسها یکسان نیست
سامانه مالی در روز پرداخت حقوق با همان سامانه در یک روز کمتراکنش، حساسیت زمانی یکسانی ندارد. ممکن است گزارش مدیریتی هفتگی چند ساعت تأخیر را تحمل کند، اما تأیید پرداختی با مهلت مشخص، زمان بسیار کمتری در اختیار سازمان بگذارد. بنابراین یک عدد مشترک برای تمام سامانهها، تفاوت فرایندها را پنهان میکند.
برای شروع، هر مالک فرایند باید پاسخ دهد توقف از چه زمانی به بعد پیامد جدی ایجاد میکند، حداقل فعالیت قابلقبول چیست و چه کارهایی میتوانند موقتاً به روش دیگری انجام شوند. پاسخ باید به زمانهای حساس نیز اشاره کند؛ پایان ماه، روز تسویه، زمان ارائه گزارش و دورههای اوج فعالیت ممکن است نیاز متفاوتی داشته باشند.
در این مرحله، دو مفهوم در گفتوگوی مدیران وارد میشود: RTO برای هدف زمانی بازیابی، و RPO برای نقطه زمانی دادهای که باید به آن بازگردیم. اینها اهداف طراحی و توافق هستند و تحقق آنها باید آزموده شود. جزئیات تعیین و سنجش این دو شاخص را در مقاله «از بکاپ موفق تا بازیابی موفق» دنبال میکنیم.
یک برآورد ساده برای جلسه مدیریت
بهتر است جلسه نخست با یک سناریوی محدود آغاز شود: «سامانه مالی در روز پرداخت حقوق چهار ساعت در دسترس نیست.» این چهار ساعت فقط فرض تمرین است و به معنی زمان مجاز سازمان نیست. سپس هر واحد اثر توقف را از نگاه خودش توضیح دهد. خروجی باید بین هزینه قطعی، اثر قابل برآورد و پیامد هنوز نامعلوم تفاوت بگذارد.
برای مثال، اگر ده نفر در این مدت هرکدام دو ساعت کار غیرقابلجبران داشته باشند، مجموع زمان ازدسترفته بیست نفرساعت است. تبدیل آن به هزینه به مبنای مورد توافق واحد مالی نیاز دارد. اگر همان کار بعداً با اضافهکاری جبران شده، باید مراقب بود یک هزینه را هم به شکل زمان ازدسترفته و هم به شکل اضافهکاری دوباره نشماریم.
در بخش پرداختها نیز مبلغ کل حقوق معوق، لزوماً زیان سازمان نیست؛ این مبلغ پیش از حادثه هم تعهد سازمان بوده است. هزینه واقعی میتواند هزینه تأخیر، دوبارهکاری، مغایرت یا پیامد قراردادی باشد. این تفکیک کمک میکند گزارش برای مدیرعامل قابل دفاع باشد و تصمیم سرمایهگذاری بر پایه بزرگنمایی خسارت شکل نگیرد.
وابستگیهایی که در نام سامانه دیده نمیشوند
وقتی میگوییم «سامانه مالی»، ممکن است فقط نرمافزار کاربردی را به یاد بیاوریم. اما ورود کاربر، نامگذاری شبکه، پایگاه داده، ذخیرهسازی، ارتباط با بانک و دسترسی مدیر تأییدکننده هم در انجام یک پرداخت نقش دارند. بازگشت یکی از این اجزا بهتنهایی به معنی امکان انجام کار نیست. برای همین، فهرست تجهیزات باید به نقشه وابستگی سرویس تبدیل شود.
در نقشه اولیه لازم نیست تمام شبکه با جزئیات مستند شود. از یک عملیات واقعی شروع کنید: کارشناس وارد میشود، فایل پرداخت را آماده میکند، مدیر آن را تأیید میکند و نتیجه دریافت میشود. هر مرحله را به سرویسهای پشتیبانش وصل کنید. سپس بپرسید اگر هر جزء در دسترس نباشد، چه بخشهایی از فرایند متوقف میشود.
وابستگی انسانی هم باید دیده شود. ممکن است تنها فردی که کلید لازم یا روش انجام عملیات اضطراری را میداند در دسترس نباشد. همچنین قرارداد پشتیبانی، شماره تماس تأمینکننده یا مستند بازیابی نباید فقط روی همان سامانه مختلشده نگهداری شود. برنامه زمانی قابل اجراست که منابع اجرای آن در شرایط حادثه قابل دسترسی باشند.
تفاوت نقش HA و بازیابی پس از بحران
دسترسپذیری بالا یا HA برای کاهش توقف ناشی از برخی خرابیها طراحی میشود. بازیابی پس از بحران یا DR، به بازگرداندن سرویس پس از سناریوهای شدیدتر میپردازد. دامنه هرکدام به معماری و سناریوی آزمون وابسته است. وجود دو سرور یا یک سایت دوم، بهخودیخود اثبات نمیکند که همه انواع اختلال پوشش داده شدهاند.
برای نمونه، اگر یک خطای منطقی داده یا حذف اشتباه به محیط دوم هم منتقل شود، داشتن نسخه دوم فعال الزاماً پاسخ مسئله نیست. در مقابل، اگر مشکل فقط خرابی یک جزء باشد، معماری مناسب میتواند نیاز به بازیابی کامل از بکاپ را کاهش دهد. باید روشن باشد هر لایه برای کدام خرابی طراحی شده و کدام ریسک خارج از پوشش آن باقی میماند.
از همینجا نقش بکاپ، تکثیر داده، جداسازی دسترسی و برنامه عملیات اضطراری از هم قابل تشخیص میشود. انتخاب درست معمولاً حاصل کنار هم قرار گرفتن چند قابلیت است. سازمان به نقشهای نیاز دارد که نشان دهد چه سناریویی با چه روشی پاسخ داده میشود، نه فقط فهرستی از قابلیتهای خریداریشده.
با بودجه محدود از کجا شروع کنیم
در سازمان فرضی ما، مدیر مالی با تعویض یکجای زیرساخت موافق نیست. این محدودیت میتواند نقطه شروع یک برنامه مرحلهای باشد. نخست باید شکافهایی شناسایی شوند که با اصلاح دسترسی، مستندسازی، تعیین مسئول یا آزمون بازیابی قابل کاهشاند. این اقدامات هم هزینه و زمان دارند، اما همیشه نیازمند خرید تجهیزات جدید نیستند.
مرحله بعد به سرویسهایی اختصاص مییابد که اثر توقف آنها بیشتر و توان بازیابیشان ضعیفتر است. ممکن است سامانه مالی پیش از سامانه آرشیو در اولویت قرار گیرد. سپس برای هر اصلاح، نتیجه موردانتظار تعیین شود: کاهش یک وابستگی، کوتاه شدن زمان تشخیص، دسترسی به نسخه قابل بازیابی یا امکان ادامه یک عملیات حداقلی.
بودجه تجهیز باید به شکاف مشخص متصل شود. اگر محدودیت اصلی سرعت بازگرداندن داده است، باید توان ذخیرهسازی و مسیر بازیابی بررسی شود. اگر مشکل، اشتراک دسترسی مدیریت بکاپ با محیط اصلی است، صرف افزایش ظرفیت پاسخ کافی نمیدهد. چنین تفکیکی کمک میکند سرمایهگذاری موجود حفظ شود و هزینه جدید هدف روشن داشته باشد.
تمرینی که پیش از حادثه ارزش دارد
یک جلسه کوتاه با حضور مالی، منابع انسانی، فناوری و نماینده مدیریت برگزار کنید. سناریو همان اختلال روز پرداخت باشد. از هر فرد بخواهید اقدام نخست، اطلاعات لازم و شخصی را که باید با او هماهنگ شود توضیح دهد. اگر دو نفر تصور میکنند دیگری مسئول اطلاعرسانی است، یک شکاف واقعی پیدا کردهاید.
در ادامه، وضعیت را تغییر دهید: مدیر اصلی در دسترس نیست؛ اتصال بانکی برقرار نشده؛ بخشی از پرداختها نتیجه نامشخص دارند. هدف تمرین، غافلگیر کردن یا مقصر پیدا کردن نیست. باید ببینید تصمیمها با اطلاعات موجود قابل انجاماند یا به دانستههای شفاهی یک فرد وابستهاند. برای هر شکاف، یک اقدام، مسئول و موعد تعیین کنید.
پس از رفع موارد اولیه، تمرین فنی کنترلشده لازم میشود. آزمون باید با دامنه و هماهنگی مشخص انجام شود تا خود باعث اختلال ناخواسته نشود. نتیجه مفید، گزارشی از زمان واقعی، وابستگیهای کشفشده و کارهای باقیمانده است. عبارت «تست انجام شد» بدون این اطلاعات، برای تصمیم بعدی مدیریت کافی نیست.
ادامه کار موقت به کنترل نیاز دارد
در جلسه مالی، یکی از مدیران پیشنهاد میدهد پرداختها از روی فایل روز قبل انجام شوند. این پیشنهاد ممکن است برای بخشی از کار قابل بررسی باشد، اما باید اعتبار فهرست، اختیار تأیید و روش جلوگیری از پرداخت تکراری روشن شود. روش موقت نباید کنترلهایی را که برای حفاظت از منابع سازمان طراحی شدهاند، بیدلیل حذف کند. صاحب فرایند باید حدود استفاده از آن را مشخص کند.
همچنین اطلاعات ثبتشده در دوره اختلال باید بعداً با سامانه اصلی تطبیق داده شوند. مسئول ثبت، محل نگهداری و ترتیب ورود دوباره داده اهمیت دارند. اگر چند واحد مستقل فایلهای متفاوت بسازند، بازگشت به وضعیت عادی میتواند زمان بیشتری از رفع مشکل فنی بگیرد. بهتر است یک مرجع مشخص برای ثبت اقدامات اضطراری وجود داشته باشد تا بعداً بتوان جریان تصمیم و عملیات را بازسازی کرد.
این جزئیات نشان میدهد برنامه تداوم باید در سطح انجام کار نوشته شود. عبارت «در صورت اختلال دستی انجام شود» برای پرداخت سازمانی کافی نیست؛ روش، ظرفیت، مسئول و کنترل لازم باید قابل اجرا باشند.
نتیجه قابل پیگیری برای مدیریت
یک موضوع دیگر هم باید ثبت شود: چه کسی اختیار اعلام بازگشت عملیات را دارد؟ در سامانه مالی، تأیید تیم زیرساخت برای روشن بودن اجزا لازم است، اما مالک فرایند باید امکان انجام کار و وضعیت تراکنشها را تأیید کند. معیار تحویل میتواند ورود موفق، مشاهده داده موردانتظار و اجرای یک گردش کار کنترلشده باشد. وقتی این معیار از قبل نوشته شده باشد، عبارت «سامانه بالا آمده» برای همه معنای یکسانی پیدا میکند و پرونده حادثه زودتر از موعد بسته نمیشود.
مدیرعامل سازمان فرضی در پایان بررسی، درخواست خرید فوری همه تجهیزات را تصویب نمیکند. او با یک تصمیم مشخص موافقت میکند: سه سرویس حیاتی انتخاب شوند، مالک کسبوکاری هرکدام مشخص شود و وضعیت واقعی بازیابی آنها با شواهد بررسی شود. بر این اساس، تیم فناوری میتواند پیشنهاد مرحلهای و قابل دفاع ارائه کند.
برای سازمان شما نیز نقطه شروع میتواند همین باشد. سه سرویس را انتخاب کنید و برای هرکدام پیامد قطعی، زمان حساس، حداقل خدمت قابلقبول، وابستگیهای اصلی و آخرین آزمون بازیابی را بنویسید. هر خانهای که پاسخ روشن ندارد، موضوع گفتوگو و ارزیابی بعدی است؛ لازم نیست برای آغاز کار منتظر سندی بسیار بزرگ بمانید.
راگا میتواند در بررسی این وابستگیها و تبدیل نیاز کسبوکار به نقشه راه زیرساخت همراه سازمان باشد. خروجی مطلوب، مشخص شدن اولویت اصلاحات و انتخاب راهکار متناسب با شرایط شماست. پرسش بعدی این مسیر روشن است: وقتی اهداف کسبوکار معلوم شد، آیا بکاپ فعلی واقعاً میتواند سرویس را با داده مناسب و در زمان موردنیاز بازگرداند؟
منابع
[۱] NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems | مشاهده منبع
مطالب مرتبط در سایت راگا
برای آشنایی بیشتر با راهکار مرتبط، راهکارهای بکاپ و بازیابی اطلاعات راگا را ببینید.