راهنمای مصاحبه شغلی مهندس کلود

معرفی

شایستگی‌های مورد سنجش

برای آشنایی بهتر با این راهنما، توجه به موارد زیر می‌تواند مفید باشد.

• طراحی زیرساخت ابری

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

• مدیریت لینوکس و عیب‌یابی سیستم

  درک فرایندها، سرویس‌ها، مجوز فایل، مصرف CPU و حافظه، دیسک، لاگ و ابزارهای پایه خط فرمان.

• زیرساخت به‌عنوان کد

  توانایی نوشتن، بازبینی و تغییر امن منابع زیرساختی با Terraform و مدیریت وضعیت و وابستگی منابع.

• کانتینرسازی و Kubernetes

  درک مفاهیم Image، Container و Registry و آشنایی با Deployment، Service، Ingress، منابع، سلامت سرویس و روش عیب‌یابی Pod.

• شبکه و ارتباط سرویس‌ها

  توانایی تحلیل DNS، مسیر شبکه، پورت، فایروال، توازن بار، TLS و ارتباط داخلی میان سرویس‌ها.

• پایش و مدیریت رخداد

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

• امنیت و مدیریت دسترسی

  درک اصل حداقل دسترسی، تفکیک نقش‌ها، مدیریت اسرار، کلیدها، دسترسی تولید و بازبینی تغییرات.

• خودکارسازی و همکاری فنی

  توانایی استفاده از Bash یا Python برای حذف کارهای تکراری و توضیح محدودیت‌های زیرساختی به تیم توسعه و امنیت.

• مفاهیم پایه رایانش ابری

  درک مدل‌های IaaS، PaaS و SaaS، تفاوت ابر عمومی و خصوصی، مفهوم منطقه و ناحیه دسترس‌پذیری و اصول مقیاس‌پذیری و دسترس‌پذیری.

برنامه آماده‌سازی

در ادامه، مهم‌ترین موارد این بخش به تفکیک معرفی شده‌اند.

• مرور یک پروژه زیرساختی واقعی

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

• Terraform و تغییر امن زیرساخت

  تمرین کنید که تفاوت plan و apply، نقش state، وابستگی منابع، متغیرها، ماژول‌ها و خطر تغییر مستقیم منابع تولیدی را توضیح دهید. یک فایل Terraform را بخوانید و مشخص کنید کدام تغییر ممکن است باعث حذف یا جایگزینی منبع شود.

• Kubernetes و عیب‌یابی سرویس کانتینری

  مفاهیم Pod، Deployment، Service، ConfigMap، Secret، Ingress، readiness probe، liveness probe، requests و limits را مرور کنید. سناریوی CrashLoopBackOff، ImagePullBackOff و نرسیدن ترافیک به سرویس را با بررسی رویدادها، لاگ و تنظیمات شبکه تمرین کنید.

• شبکه، DNS و TLS

  مسیر یک درخواست HTTPS را از DNS تا توازن بار و سرویس داخلی مرور کنید. تفاوت شبکه خصوصی و عمومی، Security Group یا فایروال، NAT، پورت‌های ورودی و خروجی و علت خطاهای رایج گواهی TLS را آماده داشته باشید.

• پایش، لاگ و پاسخ به رخداد

  برای یک API فرضی، شاخص‌های نرخ خطا، زمان پاسخ، ترافیک، مصرف منابع و اشباع ظرفیت را تعریف کنید. توضیح دهید هشدار چگونه باید قابل اقدام باشد و هنگام افزایش خطای 5xx، کدام داشبوردها، لاگ‌ها و تغییرات اخیر را بررسی می‌کنید.

• امنیت، دسترسی و بازیابی

  اصل حداقل دسترسی، حساب‌های شخصی و سرویس، چرخش کلیدها، نگهداری اسرار، دسترسی اضطراری و ثبت تغییرات را مرور کنید. برای پشتیبان‌گیری، تفاوت داشتن فایل بکاپ با بازیابی آزمایش‌شده را روشن کنید و یک سناریوی بازگردانی را توضیح دهید.

• تمرین توضیح تجربه‌ها و پاسخ به سناریوها

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

چک‌لیست آماده‌سازی

چک‌لیست زیر کمک می‌کند هیچ نکته مهمی را از قلم نیندازید:

• شرح وظایف را بررسی کرده‌ام و فناوری‌های اصلی آن را با تجربه خود تطبیق داده‌ام.
• دو پروژه زیرساختی را با مسئله، تصمیم‌ها، ابزارها و نتیجه قابل‌اندازه‌گیری آماده کرده‌ام.
• یک سناریوی اختلال واقعی یا تمرینی را مرحله‌به‌مرحله برای توضیح آماده کرده‌ام.
• مفاهیم Terraform شامل state، plan، ماژول و تغییر امن را مرور کرده‌ام.
• عیب‌یابی Pod، Service، Ingress و منابع در Kubernetes را تمرین کرده‌ام.
• فرمان‌های پایه بررسی سرویس، لاگ، شبکه و مصرف منابع در لینوکس را مرور کرده‌ام.
• مسیر یک درخواست HTTPS از DNS تا سرویس را می‌توانم توضیح دهم.
• برای یک سرویس، متریک‌ها و هشدارهای مهم را مشخص کرده‌ام.
• یک نمونه از مدیریت دسترسی، Secret یا بازبینی امنیتی آماده کرده‌ام.
• پرسش‌های خود درباره آن‌کال، محیط تولید، دسترسی‌ها و پلتفرم ابری را نوشته‌ام.

سئوالاتی که از شما می‌پرسند

• فنی

  چرا زیرساخت به‌عنوان کد را به ساخت دستی منابع در پنل ابری ترجیح می‌دهید؟

  سنجش درک تکرارپذیری، بازبینی تغییرات، کنترل نسخه و خطر پیکربندی‌های ناسازگار.

  راهنمای پاسخ و نمونه پاسخ

  به Terraform، تعریف اعلامی منابع، بازبینی تغییر در Git، اجرای plan پیش از apply و جلوگیری از تفاوت محیط‌ها اشاره کنید. توضیح دهید IaC خطا را حذف نمی‌کند. state، بازبینی همکار و محدودکردن دسترسی اجرای تغییر همچنان ضروری است.

  ساخت دستی برای آزمایش کوتاه ممکن است سریع باشد، اما در محیط‌های چندگانه قابل ردگیری و تکرار نیست. با Terraform، شبکه، ماشین مجازی و قوانین دسترسی در مخزن Git ثبت می‌شوند و همکاران پیش از اعمال، خروجی plan را می‌بینند. برای تولید، state را در محل امن نگه می‌دارم، تغییرها را از طریق بازبینی انجام می‌دهم و apply مستقیم از لپ‌تاپ شخصی را محدود می‌کنم.

• فنی

  اگر یک Pod در Kubernetes وارد CrashLoopBackOff شود، چگونه عیب‌یابی می‌کنید؟

  سنجش روش تشخیص مرحله‌ای، آشنایی با لاگ، رویدادها، تنظیمات کانتینر و وابستگی‌های سرویس.

  راهنمای پاسخ و نمونه پاسخ

  از kubectl describe pod و kubectl logs، از جمله لاگ اجرای قبلی، شروع کنید. کد خروج برنامه، فرمان راه‌اندازی، متغیرهای محیطی، Secret و ConfigMap، اتصال به پایگاه داده، readiness و liveness probe و محدودیت حافظه را جداگانه بررسی کنید. میان راه‌حل موقت برای بازگرداندن سرویس و علت ریشه‌ای تمایز بگذارید.

  readiness probe مشخص می‌کند که Pod آماده دریافت ترافیک است یا خیر و در صورت ناموفق بودن، Pod از مسیر دریافت ترافیک خارج می‌شود. liveness probe برای تشخیص وضعیتی استفاده می‌شود که کانتینر دیگر قادر به ادامه کار نیست و در صورت شکست مکرر می‌تواند باعث راه‌اندازی مجدد کانتینر شود. startup probe برای برنامه‌هایی مناسب است که زمان راه‌اندازی طولانی دارند و کمک می‌کند liveness probe پیش از آماده‌شدن برنامه باعث restart زودهنگام نشود. تنظیم بیش‌ازحد حساس liveness می‌تواند یک سرویس سالم اما کند را به‌طور مکرر restart کند.

• موقعیتی

  پس از یک تغییر Terraform، بخشی از ترافیک به سرویس نمی‌رسد. چه اقدام‌هایی انجام می‌دهید؟

  سنجش مدیریت تغییر، کنترل اثر حادثه، تحلیل شبکه و پرهیز از اقدام‌های شتاب‌زده در تولید.

  راهنمای پاسخ و نمونه پاسخ

  ابتدا دامنه اثر را با متریک و گزارش کاربران مشخص کنید و تغییر اخیر را با نسخه قبلی مقایسه کنید. مسیر ترافیک شامل DNS، توازن بار، قانون فایروال، مسیر شبکه و مقصد را بررسی کنید. اگر تغییر علت محتمل است، با روش کنترل‌شده rollback کنید و هم‌زمان شواهد لازم برای تحلیل علت ریشه‌ای را نگه دارید.

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

• فنی

  برای یک API، چه متریک‌هایی را پایش می‌کنید و کدام هشدارها را تنظیم می‌کنید؟

  سنجش توانایی تبدیل سلامت سرویس به شاخص‌های قابل اقدام و پرهیز از هشدارهای پرنویز.

  راهنمای پاسخ و نمونه پاسخ

  چهار سیگنال اصلی را پوشش دهید: ترافیک، خطا، زمان پاسخ و اشباع. نرخ خطای 5xx، تاخیر صدکی، درخواست بر ثانیه، مصرف CPU و حافظه، اتصال‌های پایگاه داده و ظرفیت دیسک را متناسب با معماری سرویس پایش کنید. هشدارها را بر اساس اثر مشکل بر کاربران و تداوم آن طراحی کنید، نه هر نوسان کوتاه‌مدت.

  برای API ابتدا نرخ درخواست، نرخ خطای 4xx و 5xx و تاخیر صدکی مانند p95 را می‌بینم. میانگین زمان پاسخ برای تشخیص تجربه کاربر کافی نیست. سپس اشباع CPU، حافظه، ظرفیت دیسک، تعداد اتصال‌ها و خطاهای وابستگی مانند پایگاه داده یا سرویس بیرونی را پایش می‌کنم. هشدار بحرانی را برای نرخ خطای پایدار یا عبور تاخیر از آستانه توافق‌شده می‌گذارم و هشدار مصرف CPU را فقط وقتی مهم می‌دانم که همراه با اثر روی سرویس باشد.

• فنی

  تفاوت readiness probe و liveness probe چیست و تنظیم نادرست آن‌ها چه اثری دارد؟

  سنجش درک چرخه حیات سرویس کانتینری و تاثیر سلامت‌سنجی بر ترافیک و راه‌اندازی مجدد.

  راهنمای پاسخ

  توضیح دهید readiness تعیین می‌کند Pod آماده دریافت ترافیک هست یا نه. liveness برای تشخیص فرایند گیرکرده و راه‌اندازی مجدد است. به startup probe برای برنامه‌های کندراه‌انداز اشاره کنید. هشدار دهید که liveness تهاجمی می‌تواند سرویس سالم اما کند را پیوسته بازراه‌اندازی کند.

• نمونه‌کار

  در نمونه‌کار زیرساختی خود چه چیزی را خودتان طراحی کرده‌اید و چگونه قابل اجراست؟

  سنجش اصالت نمونه‌کار، توانایی مستندسازی و درک رابطه میان کد زیرساخت، سرویس و پایش.

  راهنمای پاسخ و نمونه پاسخ

  معماری را از روی مخزن خود شرح دهید: منابع Terraform، فایل‌های کانتینر، روش اجرای محیط، متغیرهای لازم و حذف امن منابع. اگر محیط آموزشی است، محدودیت آن را صادقانه بگویید. وجود README، نمودار ساده معماری و راهنمای بازیابی یا عیب‌یابی از ادعای پروژه بزرگ مهم‌تر است.

  در نمونه‌کارم یک API کانتینری را روی محیط آزمایشی اجرا کرده‌ام. شبکه و منابع اصلی با Terraform تعریف شده‌اند و تنظیمات سرویس در مخزن Git قرار دارد. در README مراحل راه‌اندازی، متغیرهای لازم و روش حذف منابع را نوشته‌ام. برای پایش، متریک‌های خطا و زمان پاسخ را در Grafana نمایش داده‌ام. این پروژه ترافیک تولیدی ندارد، اما عمداً سناریوی قطع اتصال پایگاه داده و بررسی لاگ را نیز مستند کرده‌ام.

• موقعیتی

  یک سرویس باید در دو محیط یا دو منطقه اجرا شود. چه پرسش‌هایی پیش از طراحی می‌پرسید؟

  سنجش طراحی مبتنی بر نیاز کسب‌وکار، شناخت بازیابی، داده و هزینه، نه صرفاً تکثیر منابع.

  راهنمای پاسخ و نمونه پاسخ

  درباره RTO و RPO، نوع و محل داده، سازگاری داده، حجم ترافیک، وابستگی‌های تک‌منطقه‌ای، نیاز قانونی یا امنیتی، بودجه و روش آزمون بازیابی پرسش کنید. تفاوت فعال فعال و فعال غیرفعال را با هزینه، پیچیدگی و هدف دسترس‌پذیری توضیح دهید.

  پیش از انتخاب معماری، می‌پرسم حداکثر زمان توقف قابل قبول و حداکثر داده قابل از دست‌رفتن چقدر است. سپس مشخص می‌کنم کدام داده حالت‌دار است، تکثیر آن چگونه انجام می‌شود و آیا سرویس‌های وابسته در هر دو محیط در دسترس‌اند. برای ترافیک، DNS یا توازن بار و شیوه failover را بررسی می‌کنم. اجرای Active-Active همیشه انتخاب بهتر نیست. اگر RTO و RPO اجازه دهند، معماری Active-Passive می‌تواند هزینه و پیچیدگی کمتری داشته باشد. انتخاب معماری باید بر اساس نیاز دسترس‌پذیری، نوع داده، وابستگی‌ها، هزینه و امکان آزمون بازیابی انجام شود.

• رفتاری

  از رخدادی بگویید که برای رفع سریع اختلال، تیم توسعه و زیرساخت نظر متفاوتی داشتند.

  سنجش همکاری هنگام فشار عملیاتی، استفاده از شواهد فنی و توانایی حفظ امنیت تغییر.

  راهنمای پاسخ

  نمونه‌ای را انتخاب کنید که اختلاف درباره rollback، افزایش ظرفیت، تغییر تنظیمات یا دورزدن کنترل دسترسی بوده است. توضیح دهید چگونه اثر کاربر، متریک‌ها، ریسک تغییر و مسئول تغییر را روشن کردید. نتیجه باید شامل بازگرداندن سرویس و ثبت اقدام پیشگیرانه باشد، نه صرفاً توافق تیم.

• رفتاری

  زمانی را شرح دهید که یک تغییر زیرساختی نتیجه ناخواسته داشت.

  سنجش مسئولیت‌پذیری، شفافیت در گزارش خطا و یادگیری از تغییرات تولیدی.

  راهنمای پاسخ

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

• موقعیتی

  برای دسترسی اضطراری به محیط تولید چه رویکردی دارید؟

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

  راهنمای پاسخ و نمونه پاسخ

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

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

• فنی

  چگونه هزینه زیرساخت ابری را بدون کاهش کورکورانه پایداری مدیریت می‌کنید؟

  سنجش نگاه عملیاتی به هزینه، ظرفیت، منابع بلااستفاده و تاثیر تصمیم‌های کاهش هزینه بر سرویس.

  راهنمای پاسخ و نمونه پاسخ

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

  ابتدا هزینه را بر اساس محیط، سرویس و مالک برچسب‌گذاری می‌کنم تا بدانیم هر بخش چه مصرفی ایجاد می‌کند. سپس منابع بلااستفاده، نمونه‌های بیش‌ازحد بزرگ، دیسک‌ها و IPهای رهاشده، ترافیک خروجی و ظرفیت رزروشده را با الگوی مصرف و زمان‌های اوج مقایسه می‌کنم. کاهش ظرفیت را فقط با بررسی متریک، SLO و نیاز دسترس‌پذیری سرویس پیشنهاد می‌دهم. مثلاً سرویس بحرانی را صرفاً به دلیل میانگین مصرف پایین کوچک نمی‌کنم. تغییر را ابتدا در محیط آزمایشی یا روی بخش محدودی از بار اعمال می‌کنم، اثر آن را می‌سنجم و اگر شاخص‌های پایداری افت کند، امکان بازگشت سریع را حفظ می‌کنم.

• نمونه‌کار

  در یکی از پروژه‌های خود چگونه پشتیبان‌گیری و بازیابی را آزمایش کردید؟

  سنجش تفاوت سیاست نوشته‌شده با توان بازیابی واقعی و درک زمان و نقطه بازیابی.

  راهنمای پاسخ و نمونه پاسخ

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

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

پرسش‌های شما از پنل مصاحبه

• زیرساخت فعلی بیشتر بر ابر عمومی، ابر خصوصی یا ترکیبی است و چرا این مدل انتخاب شده است؟

  نوع محیط، دامنه مهارت‌های لازم و محدودیت‌های عملیاتی نقش را روشن می‌کند.

• مالکیت Kubernetes، شبکه، CI/CD و پاسخ‌گویی به رخداد میان چه تیم‌هایی تقسیم شده است؟

  عنوان مهندس کلود در شرکت‌ها دامنه یکسانی ندارد و این پرسش مرز مسئولیت را مشخص می‌کند.

• فرایند اعمال تغییر در تولید چگونه است و چه کسی دسترسی apply به Terraform دارد؟

  بلوغ کنترل تغییر و میزان ریسک عملیاتی محیط را نشان می‌دهد.

• آن‌کال چگونه برنامه‌ریزی می‌شود و رخدادهای خارج از ساعت اداری چه سطحی از پاسخ را می‌طلبند؟

  این موضوع مستقیماً بر شرایط کار و مسئولیت نقش اثر می‌گذارد.

• مهم‌ترین اختلال یا گلوگاه زیرساختی تیم در چند ماه اخیر چه بوده است؟

  به شما نشان می‌دهد مسئله واقعی موقعیت چیست و انتظار کارفرما از نیروی جدید کدام است.

• پایش و لاگ متمرکز با چه ابزارهایی انجام می‌شود و هشدارهای فعلی چقدر قابل اقدام هستند؟

  کیفیت عملیات روزمره و حجم هشدارهای غیرضروری را آشکار می‌کند.

• برای پشتیبان‌گیری و بازیابی، آخرین آزمون بازگردانی چه زمانی انجام شده است؟

  این پرسش تفاوت میان سیاست مکتوب و آمادگی عملیاتی را روشن می‌کند.

اشتباه‌های رایج

در ادامه تعدادی از اشتباهاتی که اغلب افراد در مصاحبه شغل «مهندس کلود» انجام می‌دهند، آمده است. پرهیز از انجام این اشتباهات، می‌تواند شانس شما را برای پذیرفته شدن از مصاحبه و استخدام نهایی بیشتر کند.

• معرفی Terraform به‌عنوان ابزار جادویی

  درباره state، بازبینی plan، مدیریت اسرار، وابستگی منابع و خطر apply نادرست نیز صحبت کنید.

• پاسخ مبهم به تجربه Kubernetes

  به جای گفتن «با Kubernetes کار کرده‌ام»، یک Deployment، Service، خطای واقعی و روش عیب‌یابی آن را توضیح دهید.

• نادیده گرفتن شبکه در عیب‌یابی

  در سناریوهای اختلال، DNS، پورت، فایروال، مسیر شبکه، توازن بار و TLS را در زنجیره بررسی قرار دهید.

• برابر دانستن بکاپ با بازیابی

  تناوب بکاپ، محل نگهداری، RTO، RPO و آخرین آزمون restore را از هم تفکیک کنید.

• پیشنهاد دسترسی گسترده برای سرعت بیشتر

  اصل حداقل دسترسی، حساب شخصی، ثبت فعالیت و دسترسی اضطراری زمان‌دار را مطرح کنید.

• تمرکز صرف بر ابزار و نه تصمیم فنی

  برای هر ابزار، مسئله‌ای که حل کرده، گزینه‌های جایگزین، محدودیت و اثر آن بر پایداری یا هزینه را بیان کنید.

• قول دادن به دسترس‌پذیری بدون تعریف نیاز

  پیش از پیشنهاد معماری، درباره RTO، RPO، داده حالت‌دار، ترافیک و بودجه پرسش کنید.

پس از مصاحبه

پرسش‌های پرتکرار

اگر درباره این راهنما پرسشی دارید، ممکن است پاسخ آن را در میان موارد زیر پیدا کنید.

آموزش‌های مرتبط در فرادرس

• آموزش مانیتورینگ در لینوکس Linux آموزش ویدئویی
• آموزش مقدماتی کوبرنتیز، مدیریت کانتینرها با Kubernetes + گواهینامه آموزش ویدئویی
• آموزش داکر جادی، مفاهیم و شروع کار با Docker (رایگان) + گواهینامه آموزش ویدئویی
• آموزش مقدماتی مانیتورینگ شبکه با زبیکس Zabbix + گواهینامه آموزش ویدئویی
• چگونه مهندس دواپس شویم؟، راهنمای مسیر شغلی DevOps آموزش متنی
• Microsoft Azure چیست؟، هر آنچه باید درباره مایکروسافت آژور بدانید آموزش متنی

منابع پیشنهادی

• AWS Well-Architected Framework مستنداتdocs.aws.amazon.com
• AWS Well-Architected Labs وب‌سایتwellarchitectedlabs.com