بازیابی بعد از بحران: اول بفهم «سالم» یعنی چی
خلاصهٔ کامل‌تر
نویسندهٔ این مقاله که خودش CIO (یعنی مدیر ارشد فناوری اطلاعات) هست، می‌گه disaster recovery سال‌ها حول یه سؤال ساده بود: چقدر سریع می‌تونیم کسب‌وکار رو دوباره راه بندازیم؟ به گفتهٔ اون، این سؤال هنوز مهمه ولی دیگه کافی نیست. اپلیکیشن‌ها بین سرورهای داخلی، کلود و SaaS پخش شدن، دسترسی‌ها مدام عوض می‌شن و کارمندها ابزار و اتوماسیون جدید میارن، گاهی بدون اینکه IT خبر داشته باشه.
اسم این وضعیت رو گذاشته complexity sprawl، یعنی انباشته شدن تکنولوژی‌ها، هویت‌ها و یکپارچه‌سازی‌ها تا جایی که دیگه معلوم نیست حالت عادی چه شکلیه. نکتهٔ اصلیش اینه که بالا آوردن یه سیستم لزوماً یعنی بالا آوردن یه سیستم قابل اعتماد نیست. ممکنه یه هویت هک‌شده هنوز دسترسی داشته باشه، یه تنظیم عوض شده باشه یا مهاجم یه راه برگشت دیگه ساخته باشه.
به نظر نویسنده، inventory و dependency mapping (یعنی فهرست سیستم‌ها و اینکه کدوم به کدوم وابسته‌ست) جزو قابلیت‌های بازیابی‌ان، نه فقط مستندسازی. باید وقتی محیط سالمه بدونی چی حیاتیه، چی به چی وابسته‌ست، کی به چی دسترسی داره و اخیراً چی عوض شده. چون وقتی هزاران تغییر درست کنار تغییرهای احتمالاً مخرب هستن، نمی‌شه همه‌چیز رو چشم‌بسته به عقب برگردوند.
اون می‌گه بازیابی به همون اندازه که فنیه، چالش تصمیم‌گیری هم هست. تیم فنی می‌تونه بگه یه سیستم قابل برگشته یا نه، ولی سؤال سخت‌تر اینه که آیا باید برگرده، کدوم سیستم اول، و کی اعتماد کافی برای ادامهٔ کار وجود داره. CIO نباید همهٔ این تصمیم‌ها رو خودش بگیره؛ باید از قبل اولویت‌ها، مالکیت و حق تصمیم‌گیری مشخص شده باشه.
بخش آخر دربارهٔ تست کردنه. نویسنده می‌گه فقط اینکه بکاپ قابل بازگردانی باشه کافی نیست؛ باید تست کرد که سازمان می‌تونه نقطهٔ بازیابی درست رو پیدا کنه، زیر فشار تصمیم بگیره و بفهمه محیط برگشته قابل اعتماده یا نه. اگه تخصص لازم فقط دست یکی دو نفر باشه، حتی با تکنولوژی و فرایند درست هم مشکل تاب‌آوری داری. جمع‌بندیش اینه که سرعت بدون اعتماد، تاب‌آوری نیست.
نکات کلیدی:
- بالا آوردن دوبارهٔ سیستم لزوماً یعنی بالا آوردن یه سیستم قابل اعتماد نیست.
- inventory و dependency mapping باید پیوسته به‌روز بشن و جزو آمادگی بازیابی حساب بشن.
- ابزارهای هوش مصنوعی و shadow IT سرعت تغییرات رو بالا بردن و تشخیص تغییر مخرب رو سخت‌تر کردن.
- حق تصمیم‌گیری و مالکیت سیستم‌ها باید قبل از حادثه مشخص بشه، نه وسطش.
- تست بازیابی باید نقش آدم‌ها، مسیرهای escalation و پراکندگی تخصص رو هم بسنجه، نه فقط بکاپ رو.
