در خردادماه ۱۴۰۴، حملات سایبری به شبکه بانکی بخشی از خدمات برخی از بانکها را مختل کرد. دامنه اختلال به اندازهای بود که بانک مرکزی با هماهنگی دادستانی کل کشور، برای چکهای صادرشده از حسابهای این دو بانک در بازه مشخص، محدودیتهای مربوط به چک برگشتی را بهطور موقت به تعویق انداخت. یک سال بعد، در ۲۴ خردادماه ۱۴۰۵، حمله دیگری زیرساخت ارتباطی مشترک چند بانک را هدف قرار داد و خدمات آنها را برای مدتی مختل کرد. چند روز بعد نیز خدمات کارتی این بانکها با اختلال روبهرو شد و بخشی از خدمات خودپرداز، همراهبانک و پایانههای فروش برای جلوگیری از آسیب بیشتر موقتاً متوقف شد.
به گزارش روابط عمومی آلیاسیس، اهمیت این اتفاقها فقط در منشأ آنها یا تعداد سامانههایی که از دسترس خارج شدند نیست. هرکدام به شکلی نشان دادند که در بانکداری دیجیتال، خرابی فناوری خیلی زود از مرز واحد فناوری عبور میکند و به مسئلهای برای خود کسبوکار تبدیل میشود. وقتی دسترسی مشتری به حساب، پرداخت، خودپرداز یا سایر خدمات پایه محدود میشود، دیگر با یک رخداد فنی صرف روبهرو نیستیم؛ مسئله این است که بانک در همان شرایط چه مقدار از خدمت خود را میتواند حفظ کند.
بانکداری دیجیتال، فناوری را از یک ابزار پشتیبان به بخشی از خود عملیات بانکی تبدیل کرده است. انتقال وجه، پرداخت، احراز هویت، مدیریت حساب، اعتبارسنجی و بسیاری از تعاملات روزمره مشتریان امروز مستقیماً به شبکه، مراکز داده، سامانههای نرمافزاری و مجموعهای از وابستگیهای فنی متصلاند. از طرف دیگر، پیچیدهترشدن این زیرساختها یک واقعیت را روشنتر کرده است؛ نمیتوان انتظار داشت هیچ بخشی از سیستم هرگز خراب نشود. تجهیزات از مدار خارج میشوند، ارتباطات قطع میشوند، حملات سایبری رخ میدهند و تغییرات نرمافزاری گاهی نتایجی پیشبینینشده دارند.
در چنین شرایطی، مفهوم تحمل اختلال اهمیت پیدا میکند. تحمل اختلال به این معنا نیست که سازمان خرابی را بپذیرد یا همه چیز را به بازیابی پس از بحران بسپارد. مسئله این است که بانک از قبل بداند چه چیزی ممکن است از کار بیفتد، خرابی تا کجا میتواند پیش برود، کدام خدمات باید در هر شرایطی ادامه پیدا کنند و برای بازگرداندن بخشهای از دسترفته چقدر زمان در اختیار دارد. به این معنا، تحمل اختلال یکی از قابلیتهای اصلی تداوم است؛ یعنی توان ادامهدادن خدمت، حتی وقتی بخشی از سیستم دیگر در شرایط عادی کار نمیکند.
چهار گفتوگو با علیرضا بزرگمهری، فرهاد اینالویی، نیما امیرشکاری و مصطفی ثابتی، هرکدام بخشی از این مسئله را روشن میکنند؛ از دیدن اثر واقعی خرابی و محدودکردن دامنه آن گرفته تا بازیابی، نقش نیروی انسانی و تصمیمگیری درباره خدماتی که در بحران باید حفظ شوند.
دسترسپذیری کافی نیست
سالها «دسترسپذیری» یکی از معیارهای اصلی ارزیابی زیرساخت فناوری بوده است؛ معیاری که نشان میدهد یک سامانه در یک بازه مشخص چه میزان در دسترس و قابل استفاده بوده و چند دقیقه یا چند ساعت از مدار خارج شده است. این شاخص هنوز مهم است، اما برای بانکداری دیجیتال کافی نیست. ممکن است سامانهای در بیشتر روزهای سال در دسترس باشد، اما همان چند ساعت اختلال در یک خدمت حیاتی، تعداد زیادی مشتری و بخش بزرگی از عملیات بانک را درگیر کند.
تداوم کسبوکار سؤال را کمی متفاوت مطرح میکند. بهجای اینکه فقط بپرسیم یک سامانه چند ساعت از دسترس خارج شده، باید ببینیم بانک در همان مدت چه خدماتی را از دست داده، چه بخشهایی را توانسته فعال نگه دارد و تا چه زمانی قادر بوده اختلال را بدون توقف عملیات حیاتی تحمل کند. ممکن است یک بانک چند مرکز داده، تجهیزات جایگزین و ابزارهای متعدد پایش داشته باشد، اما هنگام وقوع اختلال نتواند تشخیص دهد خرابی یک سوئیچ شبکه یا پایگاه داده دقیقاً کدام خدمات را تحت تأثیر قرار داده است. در چنین شرایطی، تعداد تجهیزات بهتنهایی چیزی درباره توان واقعی بانک برای ادامه خدمت نمیگوید.
همین تغییر نگاه را میتوان در چارچوبهای تداوم و تابآوری نیز دید. استاندارد ISO 22301 بر آمادگی، پاسخگویی و بازیابی عملیات تأکید دارد و اصول تابآوری عملیاتی کمیته بازل نیز توجه را از صرفاً بازگشت پس از بحران به توان ادامه عملیات حیاتی در زمان اختلال میبرد. چارچوب امنیت سایبری NIST CSF 2.0 نیز مدیریت ریسک را فقط به محافظت محدود نمیکند و شناسایی، پاسخگویی و بازیابی را در همان چرخه قرار میدهد. منطق مشترک این چارچوبها ساده است: نمیتوان جلوی همه رخدادها را گرفت؛ پس باید برای زمانی که بخشی از کنترلها از کار میافتند نیز آماده بود.
علیرضا بزرگمهری؛ تداوم از فهم اثر اختلال شروع میشود
علیرضا بزرگمهری، عضو هیئتمدیره انجمن علمی تحول دیجیتال ایران، مسئله تداوم را از زاویه مدیریت خدمات فناوری اطلاعات دنبال میکند. از نگاه او، پیش از هر واکنشی باید بتوان فهمید اختلال از کجا آغاز شده و اثر آن تا کدام خدمات بانک پیش رفته است.
بانکهای بزرگ معمولاً با کمبود ابزارهای پایش روبهرو نیستند. سرورها، شبکه، رخدادهای امنیتی و نرمافزارها هرکدام با ابزارها و داشبوردهای جداگانهای رصد میشوند. بحران زمانی ایجاد میشود که اطلاعات این سامانهها به یک تصویر مشترک از وضعیت بانک تبدیل نشود. در لحظه اختلال، تیمها ممکن است دادههای زیادی در اختیار داشته باشند، اما همچنان ندانند مشکل از کجا آغاز شده، چه بخشهایی را درگیر کرده و کدام خدمت بانکی تحت تأثیر قرار گرفته است. چالش اصلی در چنین وضعیتی، برقراری ارتباط میان دادههای پراکنده و فهمیدن اثر واقعی اختلال بر خدمات بانک است.
بزرگمهری این مسئله را از زاویه مدیریت خدمات فناوری اطلاعات توضیح میدهد. از نگاه او، مدیریت خدمات باید بتواند میان دادههای پراکنده زیرساخت و خدمتی که بانک به مشتری ارائه میکند ارتباط برقرار کند. وقتی اختلالی رخ میدهد، تیم فنی نباید برای پیدا کردن منشأ مشکل ناچار باشد چندین ابزار را جداگانه بررسی کند. باید بتواند مسیر یک خدمت را از ماشین مجازی و سرور فیزیکی تا کارت شبکه، سوئیچ و روتر دنبال کند و در همان لحظه بفهمد اختلال از کجا آغاز شده، چه خدماتی به آن وابستهاند و مسئول رسیدگی به مشکل چه کسی است.
«مسئله این نیست که ابزار پایش نداریم؛ اتفاقاً ابزار زیاد داریم. اما یک جا سرورها را پایش میکنیم، جای دیگر شبکه را میبینیم و اطلاعات امنیتی و وضعیت نرمافزارها هم هرکدام در سامانه جداگانهای هستند. مشکل اینجاست که این اطلاعات کنار هم قرار نمیگیرند تا یک تصویر واحد به ما بدهند. مدیریت خدمات فناوری اطلاعات باید این نقش را داشته باشد؛ یعنی دادههای پراکنده را به هم وصل کند و نشان بدهد اگر یک جزء از زیرساخت دچار مشکل شد، دقیقاً کدام خدمت تحت تأثیر قرار میگیرد. وقتی این ارتباط از قبل مشخص باشد، در زمان بحران لازم نیست تیمها بین چند ابزار مختلف بگردند تا بفهمند مشکل کجاست و میتوان خیلی سریعتر واکنش نشان داد.»
ارزش پایش زمانی مشخص میشود که به بانک کمک کند زودتر بفهمد اختلال چه اثری گذاشته است. اینکه فقط بدانیم کدام سامانه یا تجهیز از کار افتاده، کافی نیست. باید مشخص شود این خرابی کدام خدمت را درگیر کرده، دامنه اثر آن تا کجاست و بانک چقدر برای کنترل وضعیت فرصت دارد. هرچه این تصویر زودتر شکل بگیرد، تصمیمگیری سریعتر میشود و احتمال گسترش اختلال پایینتر میآید.
فرهاد اینالویی؛ معماری باید از تداوم محافظت کند
فرهاد اینالویی، پژوهشگر بانکداری دیجیتال و عضو هیئتمدیره هلدینگ فناوری بانک گردشگری، تداوم را از زاویه معماری فناوری بررسی میکند. از نگاه او، نحوه طراحی و ارتباط اجزای یک سیستم تعیین میکند که اختلال در یک بخش تا کجا گسترش پیدا کند و چه تعداد از خدمات بانک را با خود درگیر کند.
هرچه اجزای یک سیستم بیشتر به یکدیگر گره خورده باشند، احتمال اینکه یک خرابی کوچک دامنه بزرگتری پیدا کند بیشتر میشود. ممکن است منشأ اختلال فقط یک جزء باشد، اما وابستگیهای پنهان باعث شوند چند خدمت دیگر نیز همزمان از دسترس خارج شوند. به همین دلیل، توان تحمل اختلال تا حد زیادی به معماری سیستم وابسته است؛ اینکه خرابی یک جزء تا کجا اجازه دارد پیش برود.
اینالویی پیشنهاد میکند بانک را بهجای یک ساختار بزرگ و یکپارچه، مجموعهای از خدمات مشخص ببینیم که هرکدام مرز و مسئولیت روشنی دارند. در چنین مدلی، برای خدمتی مانند کارتبهکارت میتوان مشخص کرد چه افرادی از فناوری، امنیت، کسبوکار و حتی حقوقی در قبال آن مسئولاند و این خدمت به چه اجزایی وابسته است. هرچه مرز خدمات و مالکیت آنها روشنتر باشد، هنگام خرابی نیز تشخیص منشأ مشکل و تصمیمگیری درباره آن سادهتر میشود.
«اگر بانک را یک سیستم بزرگ و یکپارچه طراحی کنیم، طبیعی است که خرابی یک بخش بتواند قسمتهای دیگری را هم با خودش درگیر کند. من ترجیح میدهم هر خدمت بانکی را یک سرویس مستقل ببینم که مسئولیتش مشخص است. مثلاً در سرویس کارتبهکارت باید معلوم باشد چه کسی از سمت فناوری، امنیت، کسبوکار یا حقوقی مسئول تصمیمگیری است و تغییرات آن را چه کسانی مدیریت میکنند. هرچه مرز این سرویسها دقیقتر و سطح تفکیک آنها بیشتر باشد، کنترل اثر یک خرابی هم سادهتر میشود. تابآوری هم فقط این نیست که چند مرکز داده داشته باشیم یا سرور بیشتری بخریم. نوع معماری، استانداردهایی که استفاده میکنیم و حتی شیوه ارتباط اجزای مختلف با یکدیگر تعیین میکند که در زمان اختلال سیستم چقدر میتواند خودش را حفظ کند.»
اهمیت معماری ریزخدمتها در این بحث فقط به توسعه سریعتر نرمافزار محدود نمیشود. از منظر تحمل اختلال، مزیت مهمتر آن این است که میتواند خرابی را در همان بخشی که آغاز شده محدود نگه دارد. قرار نیست هیچ بخشی از سامانه هرگز از کار نیفتد؛ مهم این است که خرابی یک خدمت به بخشهای دیگر سرایت نکند و یک مشکل محدود، دامنه بزرگی از خدمات بانک را از دسترس خارج نکند. معماری مناسب بیش از آنکه مانع وقوع خرابی شود، به بانک کمک میکند اثر آن را مهار کند.
همین موضوع درباره زیرساخت پشتیبان هم صدق میکند. داشتن دو مرکز داده یا دو مسیر ارتباطی لزوماً به این معنا نیست که بانک واقعاً دو مسیر مستقل در اختیار دارد. ممکن است هر دو مرکز داده از یک شرکت ارائهدهنده خدمات، یک مسیر ارتباطی یا یک زیرساخت مشترک برای احراز هویت استفاده کنند. در این حالت، اختلال در همان نقطه مشترک میتواند هر دو مسیر را همزمان از کار بیندازد. بنابراین هنگام طراحی مسیر جایگزین باید بررسی شود که مسیر دوم واقعاً مستقل است یا همان وابستگیهای مسیر اول را با خود دارد.
نیما امیرشکاری؛ تداوم پس از شکست کنترلها
نیما امیرشکاری، تحلیلگر اقتصاد دیجیتال، مسئله تداوم را از نقطهای بررسی میکند که پیشگیری دیگر کافی نبوده و اختلال رخ داده است. از نگاه او، سازمان باید پیش از بحران بداند اگر بخشی از سیستم از دسترس خارج شد، بازیابی از کجا آغاز میشود، چه خدماتی باید زودتر برگردند و چه کسانی مسئول این فرایند هستند.
بخش زیادی از سرمایهگذاری امنیتی سازمانها صرف جلوگیری از رخداد میشود. فایروال، کنترل دسترسی، ابزارهای تشخیص و سیاستهای امنیتی همه برای این طراحی شدهاند که حادثه اتفاق نیفتد یا احتمال آن کمتر شود. این رویکرد ضروری است، اما یک محدودیت دارد: در یک سیستم پیچیده نمیتوان با اطمینان فرض کرد هیچ حمله یا خرابیای هرگز از کنترلها عبور نخواهد کرد.
امیرشکاری پیشنهاد میکند بخشی از طراحی امنیت و تداوم از همان ابتدا برای زمانی انجام شود که حادثه رخ داده و بخشی از سیستم از دسترس خارج شده است. در این نگاه، بازیابی نباید تصمیمی باشد که بعد از بحران گرفته میشود. نقطه بازیابی، افراد مسئول، نسخههای پشتیبان قابل استفاده و حداقل سطحی از خدمت که باید در زمان کوتاهی دوباره فعال شود، باید از قبل مشخص باشند. سؤال اصلی این است که اگر امروز بخشی از سیستم از کار افتاد، بانک میداند از کجا باید بازیابی را شروع کند، چه چیزی را در اولویت برگرداند و این کار چقدر زمان میبرد یا نه.
«نمیشود همه سرمایهگذاری سازمان را بر این فرض گذاشت که هیچ حملهای نباید موفق شود. باید از قبل بدانیم اگر حمله اتفاق افتاد، عملیات چطور برمیگردد؛ نقطه بازیابی کجاست، چه کسانی مسئولاند، نسخههای پشتیبان تا چه اندازه قابل استفادهاند و حداقل چه سطحی از خدمت را میتوان در نیم ساعت یا یک ساعت دوباره فعال کرد. از طرف دیگر، امنیت و تداوم فقط مسئله فناوری نیست. فردی که دسترسی حساس دارد، خروج یک نیروی کلیدی، از دست رفتن دانش عملیاتی یا افشای اطلاعات ورود میتواند به همان اندازه خرابی یک سرور به عملیات آسیب بزند. برای همین، اگر قرار است سیستم در برابر اختلال دوام بیاورد، باید نیروی انسانی، آموزش و فرایندهای پشتیبان را هم در کنار فناوری دید.»
این نگاه نشان میدهد تداوم فقط به زیرساخت فنی محدود نیست. گاهی مشکل از یک سرور یا شبکه شروع نمیشود؛ ممکن است دانشی فقط در اختیار یک نفر باشد، یک دسترسی حیاتی جایگزین نداشته باشد یا تیمی بدون چند نیروی کلیدی نتواند کارش را ادامه دهد. در چنین شرایطی، تابآوری بانک به همان اندازه که به فناوری وابسته است، به توزیع دانش، جانشینپروری و آمادگی نیروی انسانی هم بستگی دارد. بانک باید بتواند حتی در نبود موقت بعضی افراد یا از دست رفتن بخشی از دانش عملیاتی، خدمات اصلی خود را ادامه دهد.
بانک تابآور بانکی نیست که هیچوقت دچار خرابی نشود. تفاوت در این است که وقتی اختلال رخ میدهد، میداند از کجا باید شروع کند، اثر خرابی تا کجا پیش رفته و چگونه میتوان آن را محدود کرد. در عین حال، از قبل مشخص کرده کدام خدمات حیاتی باید در اولویت بازگردند، این بازگشت چقدر زمان میبرد و در این فاصله چه سطحی از خدمت باید حفظ شود.
مصطفی ثابتی؛ تداوم در گرو حفظ خدمات حیاتی است
مصطفی ثابتی، مدیرعامل هلدینگ توسعه فناوری اطلاعات گردشگری ایران، تداوم را از زاویه اولویتبندی خدمات در شرایط بحران بررسی میکند. از نگاه او، وقتی منابع و ظرفیت عملیاتی محدود میشوند، بانک نمیتواند همه خدمات را با یک سطح اهمیت حفظ کند و باید از قبل بداند کدام خدمات حیاتیاند و کدام قابلیتها میتوانند موقتاً کنار گذاشته شوند.
یکی از تصمیمهای مهم در زمان بحران این است که بانک بداند کدام خدمات باید حفظ شوند و کدام خدمات میتوانند موقتاً کنار گذاشته شوند. تداوم به این معنا نیست که همه خدمات باید با همان ظرفیت و کیفیت شرایط عادی ادامه پیدا کنند. در یک اختلال جدی، منابع و زیرساخت محدود میشوند و اگر بانک بخواهد همه چیز را همزمان حفظ کند، ممکن است توان خود را برای نگهداشتن خدمات حیاتی از دست بدهد.
ثابتی این تغییر اولویت را با مثالی روشن توضیح میدهد. وقتی سطح ریسک بالا میرود، خدمات نوآورانه دیگر در اولویت نخست نیستند و تمرکز به سمت خدمات پایهای مثل خرید و پرداخت برمیگردد. او این وضعیت را به بازگشت به سطوح پایه هرم مازلو تشبیه میکند؛ یعنی سازمان در شرایط عادی میتواند به توسعه و نوآوری فکر کند، اما در بحران ابتدا باید مطمئن شود نیازهای اصلی همچنان پاسخ داده میشوند.
«در شرایطی که سطح ریسک بالا میرود، همه خدمات را نمیتوان با همان کیفیت و ظرفیت روزهای عادی ادامه داد. گاهی بانک ناچار است بعضی سرویسهای نوآورانه را موقتاً کنار بگذارد تا خدمات پایهای مانند خرید و پرداخت بدون وقفه باقی بمانند. این جابهجایی اولویت را میتوان به بازگشت به سطوح پایه هرم مازلو تشبیه کرد؛ یعنی در شرایط بیثبات، حفظ نیازهای اصلی بر توسعه و نوآوری مقدم میشود. با این حال، مسئله فقط به مدیریت بحرانهای امروز محدود نیست. اگر بانک برای مدت طولانی از فناوریهای روز، استانداردهای جدید و تجربههای بینالمللی فاصله بگیرد، ممکن است زیرساختی داشته باشد که هنوز کار میکند، اما بهتدریج انعطاف و توان سازگاری خود را با تغییرات آینده از دست میدهد.»
این نگاه یک نکته مهم را روشن میکند: در زمان اختلال قرار نیست همه خدمات با هر قیمتی حفظ شوند؛ مهم این است که بانک از قبل بداند کدام خدمات نباید متوقف شوند. میتوان این سطح را حداقل خدمات ضروری بانک در نظر گرفت؛ مجموعهای از خدماتی که مشتری حتی در شرایط شدید هم باید به آنها دسترسی داشته باشد. مشخصکردن این سطح کمک میکند منابع محدود در زمان بحران به مهمترین خدمات اختصاص پیدا کند و اولویتها همان لحظه بحران تعیین نشوند.
ثابتی در کنار بحرانهای ناگهانی، به یک خطر تدریجی هم اشاره میکند. ممکن است زیرساخت بانک امروز بدون مشکل کار کند، اما بهمرور از فناوریهای جدید، استانداردهای روز و مدلهای تازه همکاری فاصله بگیرد. این فاصله شاید فوراً به اختلال منجر نشود، اما بهتدریج توان بانک برای سازگارشدن با تغییرات را کمتر میکند. بنابراین تداوم فقط به آمادگی برای بحران امروز مربوط نیست؛ بانک باید بتواند زیرساخت و شیوه کار خود را با تغییرات آینده هم هماهنگ نگه دارد.
چهار مسیر برای تداوم
این چهار گفتوگو هرکدام از زاویهای متفاوت به مسئله نگاه میکنند، اما در نهایت به یک نقطه مشترک میرسند. بزرگمهری بر این تأکید دارد که بانک باید بتواند اختلال را بهموقع ببیند و اثر آن را بر خدمات مختلف تشخیص دهد. اینالویی نشان میدهد نوع معماری و مشخصبودن مسئولیت هر خدمت تعیین میکند خرابی تا کجا گسترش پیدا کند. امیرشکاری توجه را به زمانی میبرد که کنترلها جواب ندادهاند و سازمان باید برای بازیابی آماده باشد. ثابتی هم بر این نکته تأکید میکند که در شرایط بحرانی، حفظ خدمات حیاتی ممکن است به معنای کنارگذاشتن موقت بخشی از خدمات دیگر باشد.
کنار هم قرار دادن این تجربهها نشان میدهد توان تحمل اختلال به یک ابزار، یک تیم یا یک راهکار فنی محدود نمیشود. داشتن نسخه پشتیبان، مرکز داده دوم یا ابزارهای پایش لازم است، اما هیچکدام بهتنهایی تضمین نمیکنند بانک در زمان بحران بتواند به کار خود ادامه دهد. این توان زمانی شکل میگیرد که بانک وابستگی میان خدمات و زیرساختها را بشناسد، اختلال را زود تشخیص دهد، جلوی گسترش آن را بگیرد، مسیرهای پشتیبان واقعی داشته باشد، خدمات حیاتی را از سایر قابلیتها تفکیک کند و برای بازگرداندن آنچه از دست رفته از قبل برنامه مشخصی داشته باشد.
اگر بخواهیم این مجموعه را در یک چارچوب ساده جمعبندی کنیم، تحمل اختلال بر شش توان اصلی استوار است:
تحمل اختلال = شناخت وضعیت + محدودکردن دامنه خرابی + مسیر پشتیبان + تشخیص سریع + اولویتبندی خدمات + بازیابی
شناخت درست وضعیت به بانک کمک میکند بفهمد اختلال از کجا شروع شده و چه خدماتی را درگیر کرده است. بعد از آن، مسئله اصلی مهار اثر خرابی است تا یک مشکل محدود به بخشهای دیگر سرایت نکند. وجود مسیرهای پشتیبان مستقل امکان ادامه خدمت را بیشتر میکند و تشخیص سریع نیز فاصله میان وقوع اختلال و واکنش به آن را کاهش میدهد. در کنار اینها، بانک باید از قبل بداند در شرایط محدودیت کدام خدمات اولویت دارند و خدمات از دسترفته با چه ترتیب و در چه زمانی باید دوباره به مدار برگردند.
تداوم به یک روش نیاز دارد
وقتی این تجربهها کنار هم قرار میگیرند، یک کمبود مشترک هم دیده میشود. بانک ممکن است ابزار پایش داشته باشد، اما تصویر یکپارچهای از وابستگیهای خدمت نداشته باشد. ممکن است چند مسیر پشتیبان ساخته باشد، اما نداند آیا واقعاً از یکدیگر مستقلاند. ممکن است برای جلوگیری از حمله هزینه زیادی کرده باشد، اما مسیر بازگشت خدمت بعد از شکست کنترلها روشن نباشد. حتی ممکن است دهها خدمت در اختیار داشته باشد، بدون اینکه از قبل تعیین کرده باشد در بحران کدامیک باید زنده بماند.
این فاصله را نمیتوان فقط با خرید ابزار بیشتر پر کرد. آنچه لازم است، یک روش منسجم برای مواجهه با اختلال است؛ روشی که از خود خدمت حیاتی شروع کند و بعد سراغ فناوری، فرایند، انسان و وابستگیهای آن برود. بتواند نشان دهد هر خدمت به چه اجزایی وابسته است، کدام نقاط میتوانند شکست را به بخشهای دیگر منتقل کنند و چه سطحی از خدمت باید حتی در شرایط شدید حفظ شود.
چنین روشی باید بهجای تکیه صرف بر سناریوهای فرضی، از رخدادهای واقعی و تجربه شکستهای گذشته یاد بگیرد. اختلالها را به شواهد قابل بررسی تبدیل کند، الگوهای تکرارشونده را پیدا کند و بر اساس آنها نقاط آسیبپذیر سازمان را پیش از بحران بیازماید. مسئولیت تصمیمگیری، زمان قابلتحمل برای اختلال، مسیر جایگزین و ترتیب بازیابی نیز نباید در لحظه حادثه تعیین شوند؛ باید پیش از آن روشن شده باشند.
این روش در عین حال نمیتواند یک چکلیست ثابت باشد. فناوری تغییر میکند، وابستگیها بیشتر میشوند و ریسکهایی که امروز مهماند ممکن است چند سال بعد شکل دیگری پیدا کنند. بنابراین روش تداوم باید بتواند با دریافت شواهد تازه، شناخت خود از وضعیت را بهروز کند و آموختههای هر اختلال را دوباره وارد طراحی سازمان کند.
در بانکداری دیجیتال نمیتوان احتمال خرابی را به صفر رساند. مسئله این است که سازمان پیش از رخداد بداند چه چیزی باید ادامه پیدا کند، هنگام اختلال بتواند بفهمد چه اتفاقی افتاده و پس از آن بداند چگونه کنترل را به دست آورد. جای خالی چنین روشی، همان چیزی است که در بسیاری از ضعفهای مطرحشده در این چهار گفتوگو دیده میشود.
علاقهمندان آشنایی بیشتر با این نگاه به تداوم، تابآوری و شیوه مواجهه سازمانها با اختلال میتوانند، به وب سایت خانه تکنوکراتها و کانال آپارات مراجعه کنند.
