تاب‌آوری برنامه‌ها: نگه‌داشتن برنامه‌های ویندوز در دسترس

معرفی

برنامه‌های ویندوز اغلب به موارد بیشتری از سروری که آن‌ها را میزبانی می‌کند وابسته هستند. پایگاه‌های داده، خدمات هویتی، ذخیره‌سازی، دروازه‌ها، شبکه‌ها و نقاط پایانی کاربر می‌توانند بر این که آیا یک برنامه در طول اختلال قابل استفاده باقی می‌ماند تأثیر بگذارند. این مقاله توضیح می‌دهد که چگونه تیم‌های IT می‌توانند این وابستگی‌ها را ارزیابی کنند، تاب‌آوری را در اطراف برنامه‌های موجود ویندوز طراحی کنند، لایه‌های مناسب را نظارت کنند و آزمایش کنند که آیا برنامه‌های بازیابی واقعاً عملکردهای تجاری که کاربران به آن‌ها وابسته‌اند را حفظ می‌کنند یا خیر.

مقاومت برنامه چیست؟

تاب‌آوری برنامه به ظرفیت یک برنامه و زیرساخت اطراف آن برای ادامه ارائه عملکردهای حیاتی در طول یک اختلال و بهبود قابل پیش‌بینی پس از یک شکست اشاره دارد.

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

یک معماری مقاوم به این واقعیت اذعان دارد که شکست‌ها اجتناب‌ناپذیر هستند و به جای تلاش برای جلوگیری از هر حادثه، سازمان‌های IT سعی می‌کنند تأثیر هر یک را محدود کرده و رویه‌های بازیابی کنترل‌شده‌ای را برای حفظ یا بازگرداندن خدمات برقرار کنند.

تاب‌آوری برنامه بیشتر از زمان کارکرد سرور است

یک اشتباه رایج این است که از در دسترس بودن یک سرور به عنوان نماینده‌ای برای در دسترس بودن برنامه‌ای که بر روی سرور اجرا می‌شود، استفاده شود.

برای اینکه یک برنامه تجاری به طور واقعی در دسترس باشد، تعدادی از اجزا باید به طور همزمان در دسترس باشند:

زیرساخت → سیستم عامل → برنامه → وابستگی‌ها → مسیر دسترسی → جلسه کاربر → فرآیند کسب و کار

مشکلی در هر عنصر از این زنجیره می‌تواند منجر به غیرقابل دسترس شدن مؤثر برنامه شود.

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

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

چرا تاب‌آوری برنامه برای برنامه‌های ویندوز متفاوت است؟

شیوه‌های مدرن تاب‌آوری به طور فزاینده‌ای بر برنامه‌های بومی ابری، کانتینرها، میکروسرویس‌ها و ارکستراسیون خودکار متمرکز شده‌اند. در حالی که این‌ها رویکردهای ارزشمندی هستند، اما همیشه برای هر سازمانی قابل اجرا نیستند.

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

معماری مجدد این برنامه‌ها به عنوان میکروسرویس‌ها می‌تواند بسیار پرهزینه، از نظر فنی چالش‌برانگیز یا حتی کاملاً غیرقابل اجرا باشد اگر سازمان کنترل کد منبع را نداشته باشد.

در چنین مواردی، ممکن است ارزش قابل توجهی در مقاوم‌تر کردن عملیات مربوط به برنامه وجود داشته باشد، به جای اینکه سعی کنیم خود برنامه را مقاوم‌تر کنیم. انتشار برنامه می‌تواند بخشی از این رویکرد باشد که برنامه‌های موجود ویندوز را بر روی زیرساخت متمرکز نگه‌دارد در حالی که نحوه دسترسی کاربران به آن‌ها را تغییر می‌دهد. این می‌تواند شامل تغییرات در زیرساختی باشد که برنامه را میزبانی می‌کند، مانند حذف محدودیت‌های زیرساخت، ایجاد میزبان‌های اضافی برای برنامه، فعال‌سازی روش‌های دسترسی جایگزین و پیاده‌سازی رویه‌های بازیابی پاسخگوتر برای میزبان برنامه باشد.

در کدام موارد ممکن است دسترسی به یک برنامه ویندوز ناموفق باشد؟

ساختن تاب‌آوری برنامه با کشف اجزایی که برای ارائه موفقیت‌آمیز یک برنامه از میزبان‌های آن به کاربران نیاز است، آغاز می‌شود. این فرآیند نقاط بالقوه شکست را که می‌تواند یک برنامه کامل را از کار بیندازد، برجسته می‌کند.

میزبان‌های برنامه

یک برنامه که بر روی یک سرور ویندوز واحد اجرا می‌شود، یک نقطه شکست واضح و واحد دارد.

مشکلات سخت‌افزاری، به‌روزرسانی‌های ویندوز، فساد سیستم‌عامل، خستگی منابع یا شکست برنامه می‌تواند هر کاربری را که به آن ماشین وابسته است، مختل کند. اگر نیازهای در دسترس بودن ایجاب کند، می‌توان چندین میزبان برنامه را به کار گرفت تا وابستگی به هر یک از ماشین‌ها کاهش یابد و ظرفیت را زمانی که یک سرور در دسترس نیست، فراهم کند.

پایگاه‌های داده، ذخیره‌سازی و سایر وابستگی‌ها

بسیاری از برنامه‌های ویندوز به خدمات خارجی وابسته هستند که به میزبان برنامه مربوط می‌شوند. این خدمات می‌توانند شامل موارد زیر باشند:

• پایگاه‌های داده SQL
• اشتراک‌گذاری فایل
• سرورهای مجوزدهی
• Active Directory
• سیستم نام دامنه (DNS)
• گواهینامه‌ها
• APIها
• میان‌افزار
• ذخیره‌سازی شبکه
• زیرساخت چاپ

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

احراز هویت و هویت

کاربران نمی‌توانند به یک برنامه سالم دسترسی پیدا کنند اگر زیرساخت احراز هویت لازم در دسترس نباشد.

تیم‌های IT باید خدمات هویتی که برنامه‌های حیاتی آن‌ها به آن‌ها وابسته است را شناسایی کرده و اطمینان حاصل کنند که برنامه‌های پشتیبان‌گیری برای زمانی که این منابع در دسترس نیستند، در نظر گرفته شده است. Active Directory، پلتفرم‌های هویت ابری، خدمات احراز هویت چندعاملی (MFA) و دروازه‌های احراز هویت می‌توانند به عنوان زنجیره‌ای از دسترسی برای یک برنامه مورد اعتماد قرار گیرند.

مسیرهای شبکه و دسترسی از راه دور

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

بیایید زنجیره کامل را تصور کنیم:

دستگاه کاربر → اینترنت یا LAN → دروازه → میزبان برنامه → خدمات پشتیبان

یک نقص در هر نقطه از این زنجیره می‌تواند مانع از انجام کار کاربران شود حتی اگر برنامه به‌خوبی در حال اجرا باشد. این موضوع به‌ویژه برای سازمان‌های توزیع‌شده که در آن برنامه ممکن است در مرکز داده فعال باشد اما برای کاربران در مکان دیگری غیرقابل دسترسی است، مرتبط است.

پایانه‌ها

مقاومت برنامه لزوماً نیاز به در دسترس بودن ایستگاه کاری عادی کاربر ندارد.

ارائه امکانات به کاربران مجاز برای دسترسی به برنامه‌های میزبانی شده مرکزی از یک دستگاه جایگزین یا از طریق یک مرورگر می‌تواند دسترسی را تضمین کند، اگر یک لپ‌تاپ در دسترس نباشد، یک دفتر غیرقابل دسترسی شود یا کارکنان نیاز داشته باشند از یک مکان دیگر کار کنند.

معماری تحویل برنامه می‌تواند بخشی از یک استراتژی گسترده‌تر تداوم کسب‌وکار باشد.

فرایند ساخت تاب‌آوری برنامه برای برنامه‌های ویندوز چیست؟

هیچ فناوری واحدی نمی‌تواند برنامه را مقاوم کند. تیم‌های IT باید به جای آن، تعداد خرابی‌هایی را که می‌تواند یک عملکرد کامل را متوقف کند کاهش دهند و برای مکانیزم‌های بازیابی کنترل‌شده برای مواردی که باقی می‌مانند آماده شوند.

1. شناسایی برنامه‌های حیاتی و فرآیندهای کسب‌وکار

همه برنامه‌ها به یک درجه از حفاظت نیاز ندارند. با تعیین اینکه کدام برنامه‌ها از عملیات اصلی پشتیبانی می‌کنند، کدام کاربران به آن‌ها وابسته‌اند و تحمل زمان خاموشی آن‌ها شروع کنید.

دو هدف بازیابی نیازهای تجاری را به مشخصات فنی ترجمه می‌کند. راهنمای برنامه‌ریزی اضطراری NIST زمان هدف بازیابی (RTO) و نقطه هدف بازیابی (RPO) را به عنوان پارامترهای کلیدی برای تعیین الزامات بازیابی تعریف می‌کند:

• هدف زمان بازیابی (RTO): مدت زمان قابل قبول برای خرابی قبل از اینکه خدمات بازگردانده شود.
• هدف نقطه بازیابی (RPO): یک بازه از دست دادن داده قابل قبول، که به صورت زمان اندازه‌گیری می‌شود.

یک برنامه که به طور فشرده برای پردازش سفارشات استفاده می‌شود ممکن است زمان بازیابی هدف (RTO) چند دقیقه‌ای داشته باشد، در حالی که یک برنامه گزارش‌گیری مالی که یک بار در هفته اجرا می‌شود می‌تواند چند روز زمان خاموشی را تحمل کند.

RTO و RPO نوع حفاظت لازم برای یک برنامه را تعریف می‌کنند: انتقال فوری، بازسازی سریع خدمات یا صرفاً یک رویه بازیابی مستند.

2. نقشه زنجیره وابستگی کامل برنامه

تمام مواردی را که باید برای انجام وظیفه برنامه وجود داشته باشد، مستند کنید.

به فایل اجرایی یا سرور ویندوز محدود نشوید. پایگاه‌های داده، ذخیره‌سازی، احراز هویت، DNS، شبکه، گواهینامه‌ها، سیستم‌های مجوز، دروازه‌ها و خدمات خارجی را فراموش نکنید.

برای هر کدام، بپرسید:

اگر این از بین برود، چه بر سر برنامه می‌آید؟

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

3. نقاط بحرانی تک‌نقطه‌ای از بین ببرید

پس از ایجاد درخت وابستگی، تعیین کنید که کدام اجزا باید به صورت اضافی درآیند، بر اساس اهمیت کسب و کار و اهداف بازیابی.

در مورد تحویل برنامه‌های ویندوز، این ممکن است شامل استقرار چندین سرور برنامه به جای تکیه بر قابلیت‌های یک میزبان واحد باشد. با یک لایه تعادل بار، جلسات می‌توانند در طول عملیات عادی بین نمونه‌های برنامه توزیع شوند. در صورت بروز خرابی در میزبان، اتصالات ورودی می‌توانند به نمونه‌های سرور برنامه سالم هدایت شوند.

برنامه‌ریزی برای افزونگی باید تحت تأثیر تحلیل وابستگی قرار گیرد، با این حال. چندین سرور برنامه که به یک پایگاه داده حیاتی، دروازه شبکه یا لایه ذخیره‌سازی واحد دسترسی دارند، هنوز یک نقطه شکست واحد را ارائه می‌دهند.

طراحی با دسترسی بالا بنابراین باید خدمات برنامه را به عنوان یک موجودیت یکپارچه در نظر بگیرد. برای محیط‌های Windows Server که به افزونگی در سطح زیرساخت نیاز دارند، مستندات خوشه‌بندی Failover مایکروسافت راهنمایی‌های بیشتری در مورد توپولوژی‌های دسترسی بالا و بازیابی از فاجعه ارائه می‌دهد.

۴. جداسازی برنامه‌ها از نقاط پایانی فردی

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

متمرکز کردن برنامه‌ها بر روی میزبان‌های ویندوز مدیریت شده و ارائه رابط کاربری برنامه به کاربران این ریسک را از بین می‌برد. داده‌ها و وضعیت برنامه بر روی میزبان ویندوز مدیریت شده ذخیره می‌شود و توسط نقاط پایانی مجاز دسترسی پیدا می‌کند.

با انجام این کار، ما برنامه را برای کاربران در دسترس قرار می‌دهیم حتی اگر آنها دستگاه‌ها یا مکان‌های خود را تغییر دهند. در حالی که متمرکز کردن برنامه‌ها مشکلات زیرساختی را از بین نمی‌برد، اما به انتقال آن به محیطی کمک می‌کند که می‌تواند توسط IT کنترل شود.

۵. ارائه بیش از یک روش دسترسی عملی

مقاومت همچنین می‌تواند با اجتناب از وابستگی غیرضروری به یک نوع نقطه پایانی یا روش اتصال واحد به دست آید.

بسته به معماری تحویل برنامه، کاربران می‌توانند از روش‌های مختلف استفاده کنند. دسترسی از راه دور روش‌ها، از جمله یک کلاینت سازگار با RDP، راه‌انداز برنامه اختصاصی، پورتال وب یا جلسه مرورگر HTML5.

روش‌های اتصال جایگزین نباید با افزونگی زیرساخت اشتباه گرفته شوند. اگر همه به یک سرور ناکام وابسته باشند، برنامه همچنان در دسترس نخواهد بود.

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

6. نظارت قبل از اینکه کاهش عملکرد به یک قطعی تبدیل شود

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

شاخص‌های مفید در محیط‌های برنامه‌نویسی ویندوز شامل استفاده از CPU، فشار حافظه، ظرفیت دیسک و I/O، استفاده از شبکه، جلسات فعال، فرآیند برنامه، زمان پاسخ، اتصال ناموفق و در دسترس بودن خدمات وابسته است.

نظارت بر روند این امر حیاتی است، زیرا یک سرور که به طور مکرر به محدودیت‌های خود نزدیک می‌شود، می‌تواند همچنان آنلاین باشد در حالی که تجربه کاربری به تدریج کاهش می‌یابد.

هشدارهای آستانه به مدیران این امکان را می‌دهد که پیش‌زمینه‌های یک حادثه را قبل از اینکه کاربران دسترسی خود را از دست بدهند، بررسی کنند.

برنامه‌ریزی برای اوج‌های ظرفیت و انتقال به حالت پشتیبان

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

برنامه‌ریزی برای ظرفیت باید نه تنها الگوهای استفاده روزمره را در نظر بگیرد بلکه همچنین باید اوج‌ها را به دلیل تقاضاهای فصلی، تغییر شیفت‌ها، رشد یا نیازهای میزبانی برای برنامه‌های دیگر نیز در نظر بگیرد.

به‌ویژه در محیط‌های میزبانی چندسروری، باید از دست دادن یک سرور واحد با اطمینان از اینکه سایر گره‌های میزبانی ظرفیت اضافی برای پذیرش هر فرآیندی که در غیر این صورت بر روی گره ناکام اجرا می‌شد، جبران شود.

در غیر این صورت، رویه‌های انتقال ممکن است به سادگی یک حادثه جداگانه را به یک مشکل گسترده در عملکرد سیستم تبدیل کنند.

8. حفاظت از داده‌ها و پیکربندی

یک سرور ویندوز جایگزین کمکی ندارد اگر IT نتواند اجزای لازم برای کارکرد برنامه را بازیابی کند.

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

استراتژی بسته به هدف زمان بازیابی (RTO) و هدف نقطه بازیابی (RPO) برنامه متفاوت خواهد بود.

بالاخره، اطمینان حاصل کنید که یک پشتیبان موفق برابر با یک بازیابی موفق نیست. تیم‌های IT باید آزمایش کنند که آیا امکان بازیابی کل سرویس برنامه از داده‌ها و پیکربندی‌های محافظت‌شده وجود دارد یا خیر.

9. کاهش شعاع انفجار تغییرات

همیشه اینطور نیست که یک فاجعه غیرمنتظره باعث اختلالات شود. این اختلالات ممکن است به دلیل بهبودهای پیاده‌سازی شده نیز ایجاد شوند. بنابراین، وصله‌های ویندوز، به‌روزرسانی‌های برنامه و درایور، تغییرات سیاست امنیتی و پیکربندی نیز می‌توانند تأثیر منفی بر در دسترس بودن برنامه داشته باشند. توصیه می‌شود در صورت امکان از ایجاد تغییرات مشابه در تمام میزبان‌های تولید به طور همزمان خودداری شود.

در یک تنظیم چند سروری، امکان انجام تغییرات بهبود به صورت مرحله‌ای وجود دارد، که به مدیر این امکان را می‌دهد تا اطمینان حاصل کند که همه چیز به درستی کار می‌کند. قابلیت بازگشت به تغییرات انجام شده نیز ضروری است.

بنابراین، هنگام طراحی رویه‌های اضطراری، گزینه‌های بازگشت نیز باید در نظر گرفته شوند. این فرآیند باید به‌خوبی مستند شود و کارکنان باید بدانند در صورت شکست یک تغییر چه کاری انجام دهند، به‌جای اینکه صرفاً آن را به صلاحدید خود واگذار کنند.

طراحی برای کاهش تدریجی

تاب‌آوری به معنای حفظ ۱۰۰٪ از عملکردهای عادی در تمام زمان‌ها نیست.

در برخی موارد، حفظ عملیات برای کاربران یا برنامه‌های کلیدی ممکن است از نگهداری تمام خدمات برای همه کاربران مهم‌تر باشد. اولویت‌ها می‌توانند قبل از وقوع یک حادثه توسط تیم‌های IT تعیین شوند.

اگر ظرفیت موجودی وجود داشته باشد که بتوان از آن استفاده کرد، ممکن است منطقی باشد که ابتدا آن را به تولید، خدمات مشتری، مالی یا سایر عملکردها اختصاص دهیم.

این یک کاهش زیبا است: حفظ توانایی اجرای عملکردهایی که بیشترین ارزش تجاری را تولید می‌کنند، به جای اینکه اجازه دهیم شکست عناصر کمتر حیاتی باعث سقوط کل سیستم شود.

چگونه باید تیم‌های IT به نظارت بر تاب‌آوری برنامه‌ها بپردازند؟

نظارت بر سرورهای فردی ممکن است مفید باشد، اما نظارت بر تاب‌آوری باید خدمات کلی برنامه را همان‌طور که توسط کاربران درک می‌شود، منعکس کند.

یک مدل واقع‌گرایانه شامل چندین لایه است:

لایه	چه چیزی را نظارت کنیم	مثال شکست
میزبان	سی پی یو، رم، دیسک، در دسترس بودن سیستم عامل	سرور بیش از حد بارگذاری شده یا آفلاین است
برنامه	وضعیت پردازش و خدمات	خرابی برنامه
وابستگی	پایگاه داده، DNS، هویت، ذخیره‌سازی	برنامه راه‌اندازی می‌شود اما نمی‌تواند عمل کند
دسترسی	دروازه، پورتال، مسیر شبکه	کاربران نمی‌توانند متصل شوند
جلسه	کاربران فعال، شکست‌ها، تأخیر	برنامه آنلاین است اما غیرقابل استفاده است
عملکرد کسب و کار	تکمیل موفقیت‌آمیز جریان کار	کاربر نمی‌تواند وظیفه مورد نیاز را کامل کند

لایه عملکرد کسب و کار یکی از ساده‌ترین لایه‌ها برای نادیده گرفتن است.

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

چگونه باید تاب‌آوری برنامه آزمایش شود؟

یک معماری تاب‌آوری که هرگز یک شکست کنترل‌شده را تجربه نکرده است، حاوی فرضیات آزمایش‌نشده است.

از تست استفاده کنید تا واکنش سیستم را زمانی که اجزای کلیدی در دسترس نیستند ارزیابی کنید. تست‌ها باید شامل آفلاین کردن یک میزبان برنامه، متوقف کردن یک سرویس برنامه، شبیه‌سازی از دست دادن یک مسیر شبکه، تأیید رفتار دروازه یا بارگذاری متوازن، بازیابی از پشتیبان و دسترسی به برنامه از یک نقطه پایانی جایگزین باشد.

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

روش‌های عملیاتی جزء جدایی‌ناپذیر یک سیستم مقاوم هستند. رویه‌های افزایش هشدار: چه کسی هشدار را دریافت می‌کند؟ چه کسی صلاحیت آغاز انتقال به حالت پشتیبان را دارد؟ مدارک و اعتبارنامه‌های بازیابی کجا ذخیره می‌شوند؟ کدام وابستگی باید ابتدا آنلاین شود؟

فراوانی فنی کمترین فایده را دارد اگر فرآیندهای بازیابی دسترسی آزمایش نشده باشند.

چک لیست تاب آوری برنامه چیست؟

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

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

همه پاسخ‌ها به زیرساخت‌های گران‌قیمت با دسترسی بالا نیاز ندارند. سطح مناسب حفاظت به هزینه و تأثیر عملیاتی زمان‌های غیرقابل دسترسی بستگی دارد.

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

چگونه TSplus می‌تواند به در دسترس بودن برنامه‌های ویندوز کمک کند؟

برای سازمان‌هایی که به برنامه‌های موجود ویندوز وابسته هستند، ما می‌توانیم با متمرکز کردن برنامه‌ها بر روی سرورهای ویندوز مدیریت‌شده و ارائه آن‌ها به کاربران از طریق کلاینت‌های سازگار با RDP، دسترسی به سبک RemoteApp یا یک پورتال وب HTML5، در بهبود دسترسی کمک کنیم. این وابستگی به نقاط پایانی کاربر فردی را کاهش می‌دهد و به تیم‌های IT انعطاف‌پذیری بیشتری می‌دهد زمانی که کاربران نیاز دارند از دستگاه یا مکان دیگری متصل شوند.

TSplus دسترسی از راه دور همچنین می‌تواند از استقرارهای چندسروری با بارگذاری متوازن و دسترسی مبتنی بر دروازه پشتیبانی کند. هنگامی که با پایگاه‌های داده مقاوم، ذخیره‌سازی، خدمات هویت و شبکه ترکیب شود، این معماری می‌تواند وابستگی به یک میزبان برنامه واحد را کاهش دهد و به حفظ دسترسی به برنامه‌های حیاتی ویندوز در طول اختلال زیرساخت کمک کند.

نتیجه

تاب‌آوری برنامه به درک کامل مسیر بین زیرساخت و استفاده تجاری بستگی دارد. افزونگی، نظارت، پشتیبان‌گیری، برنامه‌ریزی ظرفیت و رویه‌های بازیابی زمانی مؤثرترین هستند که حول وابستگی‌های مشخص برنامه و اهداف بازیابی طراحی شده باشند.

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