شب پایانی دو حرکت مکمل دارد: نخست باید وضعیت موجود را قابل دیدن کنیم، سپس workload را با شواهد و راهبرد مناسب جابه‌جا یا نوسازی کنیم. مهاجرت بدون baseline راه موفقیت را مبهم می‌کند و پایش بدون تصمیم فقط داده می‌سازد. این ده پاسخ مسیر ارزیابی تا cutover را جمع‌بندی می‌کنند.

پرسش‌های ۱۳۱ تا ۱۳۵: پایش زیرساخت#

۱۳۱. infrastructure monitoring چیست؟#

پاسخ کوتاه: پایش زیرساخت گردآوری و ارزیابی نشانه‌های (signals) compute، storage، network، platform و dependency برای تشخیص سلامت، ظرفیت و failure است. هدف پشتیبانی از SLO و عملیات است، نه سبز نگه‌داشتن همهٔ نمودارها.

CPU، memory، disk latency، packet loss، queue و سلامت control plane نمونه‌اند. metric باید با topology و inventory پیوند بخورد تا بدانیم کدام سرویس و owner اثر می‌گیرد. threshold ثابت برای همهٔ میزبان‌ها مناسب نیست؛ trend، seasonality و saturation مهم‌اند. black-box check رفتار قابل مشاهده از بیرون و white-box metric وضعیت داخلی را نشان می‌دهد و هر دو لازم‌اند. signal گمشده نیز ممکن است خودش failure باشد.

۱۳۲. ابزارهای monitoring کدام‌اند؟#

پاسخ کوتاه: Prometheus و Alertmanager، Zabbix، Nagios، Grafana و سرویس‌های مدیریت‌شدهٔ ارائه‌دهندگان ابر نمونه‌اند؛ OpenTelemetry استاندارد و ابزار تولید و انتقال telemetry است، نه یک backend کامل پایش.

انتخاب بر پایهٔ مدل داده، pull یا push، discovery، cardinality، retention، چندمستاجری (multi-tenancy)، alerting، integration و هزینهٔ عملیات است. یک ابزار ممکن است metric عالی و log ضعیف داشته باشد. vendor agent نیازمند بررسی privilege و egress است. قبل از مهاجرت ابزار، use case و پرس‌وجوهای حیاتی را فهرست کنید. داشتن دو سامانه در دورهٔ گذار مفید است، اما قاعدهٔ تکراری می‌تواند هشدار دوگانه بسازد.

۱۳۳. بهترین رویه‌های monitoring چیست؟#

پاسخ کوتاه: از SLO و failure mode آغاز کنید، signal کم اما معنادار بسازید، alert را بر symptom کاربر و اقدام‌پذیری تنظیم کنید، dashboard را به runbook و owner وصل کنید و مسیر telemetry را نیز پایش کنید.

چهار signal طلایی latency، traffic، error و saturation نقطهٔ شروع خوبی‌اند، نه نسخهٔ کامل. alert باید severity، context، لینک و روش silence داشته باشد. threshold را با داده و burn rate تنظیم کنید تا fatigue کم شود. label پرکاردینال و retention نامحدود هزینه می‌سازد. تغییر rule مانند کد review و آزمون شود. پس از incident بپرسید کدام signal زودتر یا دقیق‌تر می‌توانست کمک کند.

۱۳۴. APM چیست؟#

پاسخ کوتاه: Application Performance Monitoring یا Management رفتار برنامه را با transaction، trace، error، dependency و گاهی profile مشاهده می‌کند تا latency و failure تا سطح component یا query دنبال شوند.

APM با infrastructure monitoring مکمل است: CPU اشباع را می‌بینیم و trace نشان می‌دهد کدام مسیر یا dependency زمان مصرف کرده است. نمونه‌برداری (sampling) حجم را کنترل می‌کند، اما ممکن است رخداد نادر را از دست بدهد؛ نمونه‌برداری انتهایی (tail sampling) پس از دیدن نتیجه تصمیم می‌گیرد، بنابراین دقیق‌تر ولی پیچیده‌تر است. instrumentation دادهٔ حساس و overhead دارد. trace بدون context release، service و user impact تشخیص را کامل نمی‌کند.

۱۳۵. log management چیست؟#

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

timestamp هماهنگ، level، service، environment و correlation ID زمینه می‌دهند. password، token و دادهٔ شخصی نباید ثبت شوند و redaction باید نزدیک منبع انجام شود. centralization از گم‌شدن log میزبان ephemeral جلوگیری می‌کند. ingestion failure و dropped event را پایش کنید. indexکردن همهٔ فیلدها گران است؛ tier و retention بر اساس ارزش انتخاب شوند. log تغییرناپذیر ممیزی ممکن است policy جدا بخواهد.

پرسش‌های ۱۳۶ تا ۱۴۰: مهاجرت به ابر#

۱۳۶. cloud migration چیست؟#

پاسخ کوتاه: مهاجرت ابری انتقال یا بازطراحی application، داده و عملیات از محیط فعلی به سرویس‌های ابری یا میان ابرهاست. پروژه فقط copy workload نیست؛ شبکه، هویت، امنیت، هزینه، تیم و مدل بهره‌برداری نیز تغییر می‌کنند.

موفقیت باید پیش از شروع تعریف شود: کاهش lead time، خروج از data center، تاب‌آوری یا دسترسی منطقه‌ای. discovery و dependency map جلوی مهاجرت یک جزء بدون وابستگی‌هایش را می‌گیرد. landing zone، اتصال، IAM، logging و guardrail پیش از موج workload آماده می‌شوند. cutover طرح rollback، freeze، validation و ارتباط می‌خواهد. پس از انتقال نیز rightsizing و modernization ادامه دارد؛ قبض ابر پایان پروژه نیست.

۱۳۷. راهبردهای cloud migration کدام‌اند؟#

پاسخ کوتاه: چارچوب رایج هفت R شامل rehost، replatform، refactor/re-architect، repurchase، relocate، retain و retire است. نام‌ها میان providerها کمی فرق دارند؛ مهم تصمیم آگاهانه برای هر workload است.

Rehost کمترین تغییر را می‌دهد و سریع‌تر است، ولی مزیت cloud و بدهی را محدود حل می‌کند. Replatform تغییر هدفمند مانند استفاده از database مدیریت‌شده دارد. Refactor معماری را عمیق عوض می‌کند و پرریسک‌تر است. Repurchase محصول SaaS را جایگزین می‌کند؛ relocate پلتفرم سازگار را تقریباً بدون طراحی مجدد جابه‌جا می‌کند؛ retain فعلاً نگه می‌دارد و retire حذف می‌کند. همهٔ سامانه‌ها نباید یک R بگیرند.

۱۳۸. cloud assessment چیست؟#

پاسخ کوتاه: assessment وضعیت فنی و کسب‌وکاری workload را برای تصمیم مهاجرت بررسی می‌کند: owner، ارزش، dependency، مصرف، داده، مجوز، compliance، RTO/RPO، هزینه و آمادگی تیم.

inventory کشف‌شده با CMDB یا مصاحبهٔ owner تطبیق داده می‌شود؛ port باز به‌تنهایی dependency کسب‌وکار را نشان نمی‌دهد. baseline حداقل چند چرخهٔ بار را پوشش دهد تا sizing بر peak لحظه‌ای یا میانگین خام بنا نشود. هر workload راهبرد، موج، مانع و معیار پذیرش می‌گیرد. ارزیابی باید گزینهٔ retain و retire را نیز مجاز بداند؛ فرض «همه چیز باید مهاجرت کند» نتیجه را منحرف می‌کند.

۱۳۹. application modernization چیست؟#

پاسخ کوتاه: modernization تغییر application، data یا delivery برای بهبود قابلیت تغییر، مقیاس، امنیت یا عملیات است. می‌تواند از ارتقای runtime و containerization تا جداسازی component یا استفاده از سرویس مدیریت‌شده گسترده باشد.

microservice تنها شکل نوسازی نیست. modular monolith، CI بهتر، API پایدار و حذف dependency منسوخ ممکن است ارزش بیشتر و ریسک کمتر داشته باشند. ابتدا bottleneck و outcome را مشخص کنید. الگوی strangler امکان جایگزینی تدریجی بخش‌ها را می‌دهد. migration داده، سازگاری عقب و مشاهدهٔ دو مسیر لازم‌اند. بازنویسی کامل بدون feedback اغلب زمان و ریسک را بالا می‌برد و دانش رفتار قدیمی را از دست می‌دهد.

۱۴۰. ابزارهای cloud migration کدام‌اند؟#

پاسخ کوتاه: ابزارها در دسته‌های discovery و assessment، انتقال VM، replication و انتقال داده یا database، تبدیل، validation و cost modeling قرار می‌گیرند. AWS، Azure و Google Cloud برای بخش‌هایی از این چرخه سرویس‌های اختصاصی دارند و ابزارهای ثالث نیز وجود دارند.

نام ابزار را پس از مسئله انتخاب کنید. agent ممکن است دسترسی عمیق بخواهد؛ bandwidth، encryption، consistency و downtime روی روش انتقال اثر دارند. ابزار replication cutover application را کامل نمی‌کند و تبدیل schema صحت query را تضمین نمی‌کند. proof of concept روی workload نماینده، checksum یا reconciliation داده، آزمون کارکرد و performance، و طرح rollback لازم‌اند. قابلیت و نام محصولات تغییر می‌کند؛ مستندات provider را هنگام طراحی دوباره بررسی کنید.

جمع‌بندی مسیر اصلی#

برای پایش از تجربهٔ کاربر به signal و اقدام برسید؛ برای مهاجرت از outcome به inventory، راهبرد، موج و validation. ابزار در هر دو بخش وسیله است. با این شب، ۱۴۰ پرسش اصلی منبع پوشش داده شد؛ موضوع‌های Advanced DevOps & Cloud و پرسش‌های عمیق Terraform طبق دامنه فقط در راهنمای دوره معرفی شده‌اند.

منابع#