راهکارهای سازمانی زیرساخت

وقتی فروشگاه، سامانهٔ داخلی یا API شما از دسترس خارج می‌شود، هزینه فقط زمان بازیابی نیست؛ سفارش از دست‌رفته و تماس کاربر هم هست. پرسش اصلی این است که کدام بخش معماری امروز تک‌نقطه‌ای است: یک سرور، یک سوییچ، یک دیسک یا یک دیتابیس.

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

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

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

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

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

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

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

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

پاسخ ما: کارهای تکراری و زمان‌بر — اعمال وصلهٔ امنیتی، پایش منابع و بررسی سلامت بکاپ — به تیم فنی ما سپرده می‌شود و پیکربندی هر سرور مستند می‌ماند تا به حافظهٔ یک نفر وابسته نباشد. سبک‌ترین شکل شروع، تحویل گرفتن یک ماشین مجازی به‌صورت مدیریت‌شده است؛ همان الگو بعداً روی سرورهای بزرگ‌تر هم قابل تکرار است.