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

پرسش‌های ۵۱ تا ۵۵: مدیریت پیکربندی#

۵۱. configuration management چیست؟#

پاسخ کوتاه: مدیریت پیکربندی فرایند تعریف، اعمال و کنترل وضع مطلوب سیستم‌ها در طول زمان است؛ بسته، فایل، کاربر، سرویس و سیاست (policy) نمونهٔ اقلام پیکربندی‌اند. هدف، کاهش انحراف پیکربندی (drift)—یعنی فاصله‌گرفتن وضع واقعی از وضع مطلوب—و ساخت تغییر قابل تکرار و ممیزی‌پذیر است.

فهرست دارایی‌ها (inventory) باید مشخص کند چه دارایی‌ای با چه مالک پاسخ‌گو (owner) و نقشی وجود دارد. تعریف پیکربندی در Git، بازبینی و اجرای خودکار کمک می‌کند، اما اگر تغییر دستی مجاز است باید روش کشف و اصلاح انحراف نیز وجود داشته باشد. ویژگی idempotence باعث می‌شود اجرای دوباره فقط تفاوت لازم را اعمال کند. مدیریت پیکربندی با provision اولیه هم‌پوشانی دارد، ولی چرخهٔ کامل آن شامل خط مبنا (baseline)، تغییر، راستی‌آزمایی (verification) و بازنشستگی است.

۵۲. Puppet چیست؟#

پاسخ کوتاه: Puppet ابزار مدیریت پیکربندی declarative است. کاربر resourceهایی مانند package، file و service را با وضع مطلوب تعریف می‌کند و Puppet dependency catalog را اعمال می‌کند؛ معماری رایج آن server و agent دارد، هرچند اجرای مستقل نیز ممکن است.

مزیت مدل declarative این است که «چه وضعی» از ترتیب فرمان‌ها جدا می‌شود. resource dependency باید صریح باشد تا مثلاً سرویس پس از نصب بسته و تغییر فایل reload شود. agent به‌صورت دوره‌ای drift را اصلاح و report تولید می‌کند. هزینهٔ آن نگه‌داری server، certificate، module و زبان مخصوص است. Puppet برای تغییرهای فوری تعاملی لزوماً بهترین ابزار نیست؛ در آنجا remote execution مکمل می‌شود.

۵۳. Chef چیست؟#

پاسخ کوتاه: Chef Infra مدیریت پیکربندی را با cookbook و recipe انجام می‌دهد. recipeها با DSL مبتنی بر Ruby resourceها را تعریف می‌کنند و Chef Infra Client وضع node را با policy مورد انتظار همگرا می‌کند.

Chef می‌تواند client/server یا در بعضی جریان‌ها محلی اجرا شود. cookbook واحد بازاستفاده، attribute دادهٔ پیکربندی و resource عمل idempotent را مدل می‌کند. انعطاف زبان قدرت زیادی می‌دهد، اما منطق رویه‌ای پیچیده می‌تواند convergence را سخت پیش‌بینی کند. آزمون cookbook، قفل نسخهٔ dependency و حفاظت secret لازم‌اند. در مصاحبه Chef را صرفاً «اسکریپت Ruby» ننامید؛ resource model و convergence بخش اصلی‌اند.

۵۴. Salt یا SaltStack چیست؟#

پاسخ کوتاه: Salt سامانه‌ای برای remote execution، مدیریت پیکربندی و automation رویدادمحور است. معماری شناخته‌شدهٔ master/minion پیام و اجرای موازی را هماهنگ می‌کند و حالت masterless نیز وجود دارد.

stateها وضع مطلوب را بیان می‌کنند و pillar دادهٔ هدف‌گذاری‌شده را جدا نگه می‌دارد. grain اطلاعات node برای انتخاب مقصد فراهم می‌کند. سرعت remote execution برای عملیات گسترده مفید است، اما کلید، مجوز هدف‌گیری و امنیت master اهمیت بالایی دارند؛ یک فرمان اشتباه می‌تواند هم‌زمان روی تعداد زیادی میزبان اجرا شود. batch، dry-run و محیط آزمایشی blast radius را محدود می‌کنند.

۵۵. ابزارهای مدیریت پیکربندی را چگونه مقایسه می‌کنید؟#

پاسخ کوتاه: معیارها شامل مدل declarative یا رویه‌ای، agent یا agentless، push یا pull، زبان، inventory، مقیاس، گزارش drift، اکوسیستم، سیاست دسترسی و مهارت تیم‌اند. هیچ برندهٔ مطلقی وجود ندارد.

Puppet و Chef اغلب با agent و convergence دوره‌ای شناخته می‌شوند؛ Ansible معمولاً از کنترل‌گر به مقصد push می‌کند؛ Salt هم remote execution سریع و هم state management دارد. این خلاصه است و هر محصول حالت‌های دیگری نیز دارد. یک آزمایش مناسب باید تغییر فایل، restart شرطی، failure جزئی، rollback و گزارش را بسنجد. هزینهٔ مهاجرت و ماژول‌های موجود از تفاوت syntax مهم‌تر است.

پرسش‌های ۵۶ تا ۶۰: مقیاس و دسترس‌پذیری#

۵۶. scalability چیست؟#

پاسخ کوتاه: مقیاس‌پذیری توان سامانه برای پاسخ‌گویی به رشد بار با افزودن منابع و بدون افت نامتناسب کیفیت است. scale up منابع یک node را بیشتر می‌کند؛ scale out تعداد nodeها را افزایش می‌دهد.

افزودن CPU راه‌حل هر bottleneck نیست. باید load model، بخش اشباع‌شده، latency و هزینه را اندازه گرفت. مقیاس افقی به stateless بودن کامل نیاز ندارد، اما state باید تقسیم، تکثیر یا در سامانه‌ای مناسب نگه‌داری شود. پایگاه داده، lock و dependency خارجی ممکن است محدودکننده باشند. پاسخ خوب می‌گوید ظرفیت تا چه بار و با چه SLO سنجیده شده است؛ «بی‌نهایت مقیاس می‌گیرد» ادعای معناداری نیست.

۵۷. high availability چیست؟#

پاسخ کوتاه: High Availability یا HA طراحی برای ادامهٔ ارائهٔ خدمت در برابر خرابی‌های تعریف‌شده و رسیدن به هدف دسترس‌پذیری است. افزونگی، حذف single point of failure، health check و failover اجزای معمول‌اند.

دو instance در یک rack یا zone ممکن است در برابر همان خرابی مشترک آسیب‌پذیر باشند. domain خرابی باید روشن باشد: process، node، zone یا region. افزونگی بدون آزمون failover اطمینان کاذب می‌دهد و replication اشتباه می‌تواند خرابی داده را تکثیر کند. HA با backup و DR یکسان نیست؛ HA تداوم خدمت را در برابر خرابی‌های متداول و ازپیش‌طراحی‌شده هدف می‌گیرد، درحالی‌که DR بازیابی از رخدادهای نادرتر و گسترده‌تر را نیز پوشش می‌دهد.

۵۸. load balancing چیست؟#

پاسخ کوتاه: load balancer درخواست یا اتصال را میان backendهای واجد شرایط توزیع می‌کند. الگوریتم‌هایی مانند round robin، least connections و hashing بر اساس نوع ترافیک انتخاب می‌شوند و health check مقصد ناسالم را کنار می‌گذارد.

لایهٔ ۴ با اتصال شبکه و لایهٔ ۷ با پروتکل برنامه مانند HTTP تصمیم می‌گیرد. sticky session می‌تواند مهاجرت تدریجی را آسان کند، ولی توزیع و failover را پیچیده می‌کند؛ state بیرونی اغلب انتخاب بهتری است. timeout، retry و connection draining باید هماهنگ باشند، وگرنه retry storm یا قطع درخواست طولانی رخ می‌دهد. خود load balancer نیز باید در معماری دسترس‌پذیر باشد.

۵۹. auto scaling چیست؟#

پاسخ کوتاه: auto scaling ظرفیت را بر اساس policy و signal افزایش یا کاهش می‌دهد. target tracking، threshold مرحله‌ای، زمان‌بندی یا طول صف نمونهٔ ورودی‌اند؛ حداقل، حداکثر و cooldown از نوسان کنترل‌نشده جلوگیری می‌کنند.

CPU همیشه نمایندهٔ تقاضا نیست؛ برای worker صف، backlog و زمان انتظار بهتر است. scale-out زمان bootstrap دارد و برای جهش ناگهانی ممکن است دیر برسد، پس headroom لازم است. scale-in باید connection و کار در حال اجرا را drain کند و دادهٔ محلی را از بین نبرد. افزایش replica مشکل dependency اشباع‌شده را حل نمی‌کند. هزینه و SLO هر دو باید در policy دیده شوند.

۶۰. disaster recovery چیست؟#

پاسخ کوتاه: Disaster Recovery یا DR مجموعهٔ طراحی، داده، زیرساخت و رویه برای بازگرداندن خدمت پس از اختلال جدی است. سناریو می‌تواند از دست‌رفتن site، خرابی گستردهٔ داده یا حملهٔ باج‌افزاری باشد.

راهبردهایی مانند backup/restore، pilot light، warm standby و active-active هزینه و زمان بازیابی متفاوت دارند. runbook باید owner، معیار اعلام بحران، ترتیب بازیابی، dependency، ارتباطات و بازگشت به حالت عادی را مشخص کند. کپی داده در همان حساب و دسترسی، دفاع کافی در برابر compromise نیست. DR فقط سند نیست؛ آزمون دوره‌ای باید نشان دهد RPO و RTO واقعاً دست‌یافتنی‌اند.

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

مدیریت پیکربندی با reconciliation انحراف را کم می‌کند؛ مقیاس و HA نیز با feedback و automation ظرفیت و خرابی را مدیریت می‌کنند. در هر پاسخ domain و معیار را روشن کنید: کدام میزبان‌ها، کدام failure، چه حجم بار و چه زمان بازیابی؟ بدون این مرزها، واژه‌ها بیشتر شعارند تا طراحی.

منابع#