دو سؤالی که پاسخشان معمولاً معلوم نیست
اگر همین حالا سرور اصلی از دست برود، تا چه ساعتی از داده را دارید و چند ساعت طول میکشد تا برگردید؟ این دو عدد — که در ادبیات فنی RPO و RTO نامیده میشوند — تنها چیزی هستند که یک طرح پشتیبانگیری را معنادار میکنند. سازمانی که این دو عدد را نمیداند، پشتیبانگیری ندارد؛ فایل دارد.
وقتی سرویس کند میشود، اول چه کسی میفهمد؟ اگر پاسخ «مشتری» است، پایش وجود ندارد. هدف پایش این نیست که بعد از حادثه بشود فهمید چه شد؛ این است که پیش از آنکه کسی از بیرون متوجه شود، خبر برسد.
چه کاری انجام میدهیم
- راهاندازی زیرساخت: سرور داخلی یا ابری، شبکه، گواهی TLS، و استقرار تکرارپذیر — طوری که ساختن دوبارهٔ محیط یک اسکریپت باشد، نه یک روز کار و چند چیزِ فراموششده.
- پشتیبانگیری با بازیابی آزموده: زمانبندی، نگهداری نسخهها، نگهداری خارج از محل، و — مهمترین بخش — بازیابی دورهای واقعی روی محیط جدا.
- پایش و هشدارگذاری: شاخصهای سامانه، خطاهای برنامه، فضای دیسک، اعتبار گواهی و سلامت پشتیبان، با آستانههایی که معنا دارند.
- سختسازی امنیتی: سرآیندهای امنیتی، سیاست دسترسی، مدیریت رمز و کلید، و بستن آنچه لازم نیست باز باشد.
- زیرساخت هوش مصنوعی خصوصی: سرور و منابع لازم برای اجرای مدل داخل سازمان، اگر هوش مصنوعی خصوصی در کار باشد.
- پاسخ به رخداد: در چارچوب توافق سطح خدمت، با مسیر تشدید مشخص و گزارش پس از رخداد.
پشتیبانی که آزموده نشده، پشتیبان نیست
اولین کاری که در هر پروژه زیرساخت انجام میدهیم بازیابی واقعی از روی پشتیبان موجود است، روی یک محیط جدا. نه بررسی تنظیمات، نه نگاه کردن به گزارش موفقیت — بازیابی کامل و بررسی اینکه سامانه بالا میآید و دادهاش تا کجاست.
تعداد سازمانهایی که در همین مرحله میفهمند پشتیبانشان ماههاست ناقص است — یک پایگاه داده از قلم افتاده، یک پوشه فایل هرگز وارد نشده، یا نسخهها روی همان دیسکی نگهداری میشوند که قرار است از خرابیاش محافظت کنند — از حد انتظار بیشتر است. و همهشان تا آن روز باور داشتند پشتیبان دارند.
داخلی یا ابری
پاسخ ثابتی ندارد و ما ترجیح فنی خودمان را جای تحلیل نمیگذاریم. زیرساخت داخلی کنترل کامل روی داده و هزینهای قابل پیشبینی میدهد، و در عوض کار نگهداری، تأمین قطعه و برق را به شما منتقل میکند. ابری برعکس. اگر محدودیت قانونی یا قراردادی روی خروج داده دارید، تصمیم عملاً گرفته شده است.
آنچه در هر دو حالت ثابت میماند این است که استقرار باید تکرارپذیر و مکتوب باشد. زیرساختی که فقط یک نفر میداند چطور ساخته شده، خودش یک نقطه خرابی است — و آن نقطه، آدم است.
چه چیزی تحویل میگیرید
- سند زیرساخت: چه چیزی کجا اجرا میشود، با چه دسترسی و چه وابستگی.
- اعداد RPO و RTOی مکتوب و آزموده، نه تخمینی.
- اسکریپتهای استقرار و پیکربندی، روی مخزن خودتان.
- داشبورد پایش و قواعد هشدار، با دسترسی تیم خودتان.
- گزارش ماهانه عملکرد و رخدادها.
هشت ابزار تشخیصی پایانه رایاسا — بررسی DNS، سلامت ایمیل، گواهی TLS، سرآیندهای امنیتی و زمانسنجی شبکه — همین حالا و بدون هیچ هماهنگی روی دامنه خودتان قابل اجراست. اگر میخواهید پیش از تماس، وضعیت فعلی را ببینید، از آنجا شروع کنید.
پرسشهای متداول
پشتیبان داریم؛ باز هم لازم است کاری بکنیم؟
پشتیبانی که بازیابیاش آزموده نشده، پشتیبان نیست؛ فایلی است که امیدواریم کار کند. اولین کاری که انجام میدهیم بازیابی واقعی از روی همان پشتیبان روی یک محیط جدا است. تعداد سازمانهایی که در این مرحله میفهمند پشتیبانشان ماههاست ناقص است، از حد انتظار بیشتر است.
زیرساخت داخلی بهتر است یا ابری؟
بستگی به محدودیت داده، بودجه و توان تیم داخلی دارد. زیرساخت داخلی کنترل کامل و هزینه ثابت میدهد و کار نگهداری را به شما منتقل میکند؛ ابری برعکس. تصمیم در جلسه ارزیابی و بر اساس همین سه عامل گرفته میشود، نه بر اساس ترجیح فنی ما.
پایش یعنی چه چیزی دقیقاً؟
یعنی وقتی سرویس از کار میافتد یا کند میشود، پیش از آنکه مشتری شما خبر بدهد، کسی مطلع شود. شامل شاخصهای سامانه، خطاهای برنامه، فضای دیسک، اعتبار گواهی TLS و سلامت پشتیبان — با هشدار روی آستانههایی که معنا دارند، نه هشدار برای هر نوسان.
توافق سطح خدمت شامل چه میشود؟
پنجره پاسخ به رخداد بر حسب شدت، دامنه کارهای نگهداری، گزارش ماهانه عملکرد و مسیر تشدید. مهمتر از عدد، این است که مشخص باشد چه چیزی رخداد شمرده میشود — تعریف نشدنِ همین بند است که باعث میشود ساعت سه بامداد سرِ آن بحث شود.
راهکارهای مرتبط
اگر سامانهای که قرار است مستقر شود هنوز ساخته نشده، نرمافزار اختصاصی نقطه شروع است. اگر زیرساخت را برای اجرای مدل داخل سازمان میخواهید، هوش مصنوعی خصوصی را ببینید.