آخرین اخبار
همهٔ اخبار
حاکمیت و استراتژی گزارش بحرانیت ۲/۱۰

چالش جدید مدیران فناوری (CIO): چگونه در بازسازی سیستم‌ها، تفاوت بین «وضعیت عادی» و «وضعیت آلوده» را تشخیص دهیم؟

چالش جدید مدیران فناوری (CIO): چگونه در بازسازی سیستم‌ها، تفاوت بین «وضعیت عادی» و «وضعیت آلوده» را تشخیص دهیم؟

سال‌هاست که استراتژی‌های بازیابی فاجعه (Disaster Recovery) حول یک پرسش ساده چرخیده‌اند: با چه سرعتی می‌توانیم کسب‌وکار را دوباره آنلاین کنیم؟ اگرچه سرعت همچنان اهمیت دارد، اما برای مدیران ارشد فناوری (CIO) امروزی، این پاسخ دیگر کافی نیست.

پیچیدگی فراتر از کنترل (Complexity Sprawl)

محیط‌های فناوری در سازمان‌های بزرگ به شدت پویا شده‌اند. استفاده از زیرساخت‌های ابری (Cloud)، پلتفرم‌های SaaS، و ورود ابزارهای هوش مصنوعی (AI) به جریان‌های کاری، باعث ایجاد پدیده‌ای به نام Complexity Sprawl شده است. این تجمع تکنولوژی‌ها، هویت‌ها (Identities) و فرآیندها، درک از وضعیت نرمال (Normal) محیط را دشوار می‌کند.

مشکل اصلی اینجاست: وقتی حادثه‌ای رخ می‌دهد، چگونه می‌فهمید که دقیقاً به چه وضعیتی در حال بازگشت هستید؟ بازیابی یک سیستم لزوماً به معنای بازیابی یک سیستم قابل اعتماد (Trustworthy) نیست. یک هویت (Identity) آلوده ممکن است همچنان دسترسی‌های نامناسب داشته باشد یا یک مهاجم راه بازگشتی (Backdoor) در محیط ایجاد کرده باشد. همچنین ممکن است وابستگی‌های سیستم (Dependencies) از آخرین زمان تست برنامه بازیابی تغییر کرده باشند.

راهکار: دید پذیری و نقشه‌برداری وابستگی‌ها

برای داشتن اطمینان، سازمان‌ها باید پیش از وقوع حادثه، دید پذیری (Visibility) کافی داشته باشند. مدیریت موجودی دارایی‌ها و نقشه‌برداری وابستگی‌ها (Dependency Mapping) نباید صرفاً یک تمرین مستندسازی باشد، بلکه باید به عنوان یک قابلیت عملیاتی در نظر گرفته شود. مدیران باید بدانند چه سیستم‌هایی حیاتی هستند، چه چیزی به چه چیزی وابسته است و چه تغییراتی اخیراً در محیط رخ داده است.

موضوع Shadow IT نیز با سرعت گرفتن تغییرات، چالش بزرگتری شده است. وقتی کارمندان ابزارهای جدید یا جریان‌های کاری خودکار (Automation) را بدون اطلاع بخش IT می‌کنند، دید پذیری سازمان کاهش می‌یابد که این امر در زمان بازیابی، تصمیم‌گیری را بسیار دشوار می‌کند.

تصمیم‌گیری در شرایط بحرانی

در زمان وقوع حادثه، سخت‌ترین تصمیمات لزوماً فنی نیستند. تیم‌های فناوری می‌توانند بگویند آیا چیزی قابل بازیابی است یا خیر، اما سوالات دشوارتر این هستند که: آیا باید آن را بازیابی کرد؟ کدام سیستم‌ها باید در اولویت باشند؟ و چه زمانی سازمان می‌تواند با اطمینان عملیات را از سر بگیرد؟

مدیران باید پیش از وقوع بحران، حقوق تصمیم‌گیری (Decision Rights) را مشخص کنند. این تصمیمات فراتر از امنیت سایبری است و امنیت، هویت، زیرساخت، ابری و عملیات کسب‌وکار را در بر می‌گیرد.

تست کردن سازمان، نه فقط بک‌آپ‌ها

تمرین‌های بازیابی نباید فقط به بررسی فنی قابلیت بازیابی نسخه‌های پشتیبان (Backup) محدود شود. یک تمرین معنادار باید توانایی سازمان را در شناسایی نقطه بازیابی صحیح، مدیریت وابستگی‌ها و تصمیم‌گیری تحت فشار را بسنجد. شکاف در مهارت‌های انسانی (Skills Gap) می‌تواند در زمان بحران به یک شکاف عملیاتی تبدیل شود. بازیابی یک قابلیت سازمانی است که باید به طور مداوم تمرین شود تا حافظه عملیاتی (Operational Muscle Memory) تیم‌ها تقویت گردد.

در نهایت، سرعت بدون اطمینان، تاب‌آوری (Resilience) نیست. پرسش اصلی برای مدیران فناوری دیگر این نیست که «چقدر سریع برمی‌گردیم؟»، بلکه این است که «از کجا می‌دانیم به چه وضعیتی بازمی‌گردیم؟»