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

پرسش‌های ۶۱ تا ۶۵: پشتیبان‌گیری و بازیابی بحران#

۶۱. Backup و Disaster Recovery چیست؟#

پاسخ کوتاه: backup یک نسخهٔ جداگانه و قابل بازگردانی از داده یا وضعیت لازم است؛ Disaster Recovery برنامه و توان بازگرداندن سرویس پس از اختلال بزرگ است. backup یکی از ورودی‌های DR است، نه معادل کل آن.

برای بازیابی برنامه فقط فایل داده کافی نیست: schema، کلید رمزنگاری، تنظیم، image، dependency و ترتیب راه‌اندازی نیز لازم‌اند. replication نیز backup نیست؛ حذف یا فساد منطقی می‌تواند سریع تکثیر شود. برنامهٔ DR باید failure scenario، نقش افراد، مسیر ارتباط، محیط مقصد و معیار پایان را مشخص کند. خروجی واقعی، restore آزموده‌شده و سرویس معتبر است، نه پیام «backup موفق بود».

۶۲. انواع backup کدام‌اند؟#

پاسخ کوتاه: full همهٔ دادهٔ انتخاب‌شده را می‌گیرد؛ incremental تغییر از آخرین backup مرتبط را ذخیره می‌کند؛ differential تغییر از آخرین full را نگه می‌دارد. snapshot، continuous data protection و synthetic full روش‌های دیگری‌اند و semantics آن‌ها به سامانه بستگی دارد.

backup کامل معمولاً بازیابی ساده‌تری دارد، اما تهیهٔ آن زمان و فضای بیشتری می‌خواهد. زنجیرهٔ incremental نوشتن را سبک می‌کند، اما خرابی یک جزء می‌تواند بازیابی را مختل کند. differential میان این دو قرار می‌گیرد. snapshot storage اگر در همان failure domain باشد backup مستقل به شمار نمی‌آید. نوع نسخه باید با consistency برنامه سازگار باشد؛ گرفتن snapshot crash-consistent از پایگاه در حال کار لزوماً نتیجهٔ application-consistent نمی‌دهد.

۶۳. RPO و RTO چیست؟#

پاسخ کوتاه: Recovery Point Objective یا RPO بیشترین فاصلهٔ قابل قبول نقطهٔ دادهٔ بازیابی با لحظهٔ اختلال است؛ به زبان ساده، چه مقدار داده ممکن است از دست برود. Recovery Time Objective یا RTO بیشترین زمان هدف برای بازگرداندن خدمت است.

اگر RPO یک ساعت باشد، cadence و انتقال backup باید توان رسیدن به آن را داشته باشد. RTO پانزده دقیقه با restore چندترابایتی از آرشیو سرد سازگار نیست. این‌ها هدف کسب‌وکارند، نه عددی که ابزار به‌تنهایی انتخاب کند. زمان تشخیص، تصمیم، فراهم‌سازی، restore و اعتبارسنجی را در RTO حساب کنید. RPO نزدیک صفر و RTO نزدیک صفر هزینه و پیچیدگی بالا دارد و باید برای workload توجیه شود.

۶۴. Business Continuity Planning چیست؟#

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

Business Impact Analysis فرایندهای حیاتی، dependency و پیامد توقف را شناسایی می‌کند. سپس اولویت، راهکار جایگزین، نقش و مسیر ارتباط تعیین می‌شود. DR بخش فناوری این برنامه است. نسخهٔ برنامه باید بیرون از سامانهٔ ازکارافتاده در دسترس باشد؛ شماره تماس داخل همان سرویس داخلی کافی نیست. tabletop exercise و تمرین واقعی شکاف میان سند و توان اجرا را آشکار می‌کنند.

۶۵. بهترین رویه‌های backup کدام‌اند؟#

پاسخ کوتاه: سیاست پشتیبان‌گیری را از RPO، مدت نگه‌داری (retention) و الزام قانونی استخراج کنید؛ نسخه‌ها را در failure domain و با اعتبارنامهٔ جدا نگه دارید؛ رمزنگاری، تغییرناپذیری، کنترل دسترسی و پایش داشته باشید؛ و restore را دوره‌ای تا سطح برنامه آزمایش کنید.

قاعدهٔ ۳-۲-۱—سه نسخه، دو نوع رسانه و یک نسخه بیرون محل—یادآور مفیدی است، ولی معماری دقیق نیست. نسخهٔ offline یا immutable در برابر باج‌افزار اهمیت دارد. backup باید شامل catalog و کلیدهای لازم برای decrypt باشد، اما کلید نباید بی‌حفاظ کنار داده قرار گیرد. آزمون restore باید checksum، consistency و رفتار برنامه را بسنجد و زمان واقعی را با RTO مقایسه کند.

پرسش‌های ۶۶ تا ۷۰: معماری Cloud Native#

۶۶. معماری cloud-native چیست؟#

پاسخ کوتاه: cloud-native رویکردی برای ساخت و بهره‌برداری بارهای کاری کم‌وابسته (loosely coupled)، امن، تاب‌آور، قابل مدیریت، پایدار و قابل مشاهده (observable) است که تغییر را به‌صورت برنامه‌پذیر و تکرارپذیر انجام می‌دهد. این رویکرد در ابر عمومی، خصوصی یا hybrid ممکن است.

container، API اعلانی، automation، microservice و service mesh نمونهٔ فناوری‌اند، نه چک‌لیست اجباری. یک monolith خوب‌ساخت نیز می‌تواند ویژگی‌های cloud-native مانند stateless process، automation و observability داشته باشد. هدف استفاده از مزیت محیط پویا بدون پنهان‌کردن failure است. هزینهٔ توزیع‌شدگی، شبکه، امنیت و skill تیم باید با ارزش مقیاس و استقلال تغییر سنجیده شود.

۶۷. microservice چیست؟#

پاسخ کوتاه: microservice یک جزء قابل استقرار مستقل پیرامون یک قابلیت کسب‌وکار با قرارداد روشن است. تیم مالک چرخهٔ کامل آن است و سرویس باید coupling با سایر اجزا را تا حد لازم محدود کند.

اندازهٔ خط کد تعریف‌کننده نیست. جداسازی داده و release استقلال می‌دهد، اما consistency توزیع‌شده، latency، versioning API، tracing و عملیات را دشوارتر می‌کند. پایگاه مشترک میان همهٔ سرویس‌ها استقلال را کم می‌کند. شکستن زودهنگام monolith می‌تواند distributed monolith بسازد. پاسخ خوب می‌گوید microservice وقتی ارزش دارد که مرز دامنه، تیم و نیاز تغییر مستقل روشن باشد.

۶۸. service mesh چیست؟#

پاسخ کوتاه: service mesh لایهٔ زیرساختی برای ارتباط service-to-service است که قابلیت‌هایی مانند هویت workload، mTLS، telemetry و کنترل ترافیک را بدون پیاده‌سازی جدا در هر برنامه ارائه می‌کند.

data plane ترافیک را عبور می‌دهد و control plane policy و پیکربندی را توزیع می‌کند. پیاده‌سازی می‌تواند sidecar یا مدل‌های دیگر باشد. mesh جای API gateway برای ورودی کاربر یا منطق کسب‌وکار را کامل نمی‌گیرد. هزینهٔ latency، مصرف resource، ارتقا و عیب‌یابی دارد؛ برای چند سرویس ساده شاید توجیه نشود. امنیت نیز به policy درست و حفاظت control plane وابسته است.

۶۹. event-driven architecture چیست؟#

پاسخ کوتاه: در معماری رویدادمحور، تولیدکننده (producer) رخدادِ واقعیتی را منتشر می‌کند و مصرف‌کننده‌ها (consumers) مستقل به آن واکنش نشان می‌دهند. broker یا stream معمولاً انتقال، نگه‌داری و تحویل را هماهنگ می‌کند.

این مدل coupling زمانی را کم و توسعهٔ مصرف‌کننده‌های جدید را آسان می‌کند، اما ordering، duplicate، schema evolution و مشاهدهٔ جریان را پیچیده می‌کند. «exactly once» غالباً به تعریف دقیق دامنه نیاز دارد؛ consumer idempotent و deduplication عملی‌ترند. event با command تفاوت دارد: رخداد می‌گوید چه اتفاقی افتاده و نباید با نام مبهم و payload بدون قرارداد منتشر شود. dead-letter queue نیز جای رفع علت شکست نیست.

۷۰. اصول 12-Factor App چیست؟#

پاسخ کوتاه: 12-Factor مجموعه‌ای از اصول برای برنامه‌های سرویس‌محور است: یک codebase، dependency صریح، config در environment، backing service متصل‌شونده، جدایی build/release/run، فرایندهای stateless، binding به port، concurrency با process، disposability، شباهت محیط‌ها، log به‌صورت stream و task مدیریتی یک‌باره.

این اصول قانون تغییرناپذیر یا تعریف کامل امنیت نیستند. environment variable برای هر secret در هر پلتفرم بهترین راه نیست؛ اصل مهم جدایی config از کد و artifact است. log به stdout نیز بدون جمع‌آوری، ساختار و retention کافی نیست. در مصاحبه سه اصل را به رفتار عملی وصل کنید: artifact یکسان ارتقا می‌یابد، state ماندگار بیرون process است و process سریع شروع و graceful متوقف می‌شود.

جمع‌بندی مصاحبه‌ای#

تاب‌آوری با ادعا ساخته نمی‌شود؛ با هدف، جداسازی failure domain و تمرین بازیابی سنجیده می‌شود. Cloud Native نیز انتخاب مجموعه‌ای از نشان‌های تجاری نیست. اگر معماری پیچیده‌تر می‌شود، باید استقلال تغییر، مقیاس یا قابلیت اطمینان مشخصی در برابر آن به دست آید.

منابع#