فراجاب

چگونه مهندس کلود شویم و اولین شغل خود را بگیریم؟

معرفی

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

در بازار ایران، موقعیت‌های ورودی ممکن است با عنوان‌های «کارآموز دواپس»، «کارشناس زیرساخت»، «کارشناس عملیات ابری»، «مهندس زیرساخت ابری» یا «Cloud Infrastructure Engineer» منتشر شوند. شرح وظایف را بخوانید. برخی از این آگهی‌ها در عمل به مدیر سیستم یا مهندس دواپس نزدیک‌ترند.

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

مخاطبان راهنما

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

سنجش آمادگی ورود

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

حداقل آمادگی عملی

  • روی Linux بتوانید فایل‌ها، فرایندها، سرویس‌ها، لاگ‌ها و مجوزهای پایه را بررسی کنید.

  • مفاهیم شبکه و ارتباط سرویس‌ها را در حد IP، DNS، پورت، HTTP، فایروال و شبکه خصوصی توضیح دهید.

  • یک سرویس ساده را با Docker اجرا کنید و متغیرهای محیطی، volume و شبکه کانتینری آن را مدیریت کنید.

  • با Terraform دست‌کم یک محیط آزمایشی قابل‌تکرار بسازید و تغییرات آن را با Git ثبت کنید.

  • برای سرویس خود یک شاخص سلامت یا هشدار پایه تعریف کنید و مسیر بررسی خطا را در مستندات بنویسید.

  • بتوانید توضیح دهید اگر سرویس در دسترس نبود، از کدام لاگ، داشبورد یا بررسی شبکه شروع می‌کنید.

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

  • یک اسکریپت ساده برای کاری تکراری، مانند بررسی فضای دیسک، وضعیت سرویس یا اعتبار گواهی بنویسید و ورودی، خروجی، خطاهای محتمل و روش اجرای آن را توضیح دهید.

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

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

مهارت‌های قابل انتقال

موانع رایج ورود

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

    به‌جای نصب جداگانه Terraform، Docker و Prometheus، یک سرویس نمونه بسازید که با خرابی، افزایش مصرف منابع یا تنظیم نادرست شبکه روبه‌رو شود. سپس مراحل تشخیص و رفع آن را در README ثبت کنید.

  • نداشتن دسترسی یا بودجه برای ابر عمومی خارجی

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

  • نمونه‌کار پر از فایل، اما بدون راهنمای اجرا

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

  • تمرکز صرف بر Kubernetes پیش از مبانی سیستم و شبکه

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

  • درخواست دادن فقط با عنوان مهندس کلود

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

  • نبود سابقه تولیدی و ترس از پاسخ‌گویی به رخداد

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

مسیرهای ورود

برای ارزیابی بهتر این مسیر، باید مزایا و چالش‌های آن را در کنار یکدیگر بررسی کرد.

مسیرهای ورود

  • خودآموزی پروژه‌محور و درخواست برای موقعیت جونیور

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

    مدت تقریبی: ۴ تا ۸ ماه با هفته‌ای ۱۲ تا ۱۵ ساعت تمرین

  • تغییر مسیر از مدیریت سیستم یا پشتیبانی فناوری اطلاعات

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

    مدت تقریبی: ۳ تا ۶ ماه با هفته‌ای ۸ تا ۱۲ ساعت تمرین

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

    توضیح مسیر: توسعه‌دهنده‌ای که با Git، API و فرایند استقرار آشناست، می‌تواند با یادگیری Linux، شبکه، Docker و Terraform به نقش‌های زیرساختی نزدیک شود. مزیت این مسیر، درک نیازهای تیم توسعه است. چالش آن، کسب تجربه در امنیت، شبکه و اداره محیط اجراست.

    مدت تقریبی: ۴ تا ۷ ماه با هفته‌ای ۱۰ تا ۱۵ ساعت تمرین

  • کارآموزی یا همکاری محدود با تیم زیرساخت

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

    مدت تقریبی: ۳ تا ۶ ماه با حداقل ۱۵ ساعت فعالیت هفتگی

  • پروژه شخصی برای یک کسب‌وکار یا تیم کوچک

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

    مدت تقریبی: ۲ تا ۵ ماه با هفته‌ای ۱۰ ساعت فعالیت

راه‌های کسب تجربه

  • ساخت یک محیط آزمایشی قابل‌تکرار

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

  • اجرای سناریوی اختلال کنترل‌شده

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

  • مشارکت مستنداتی در پروژه‌های متن‌باز

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

  • خودکارسازی یک کار تکراری واقعی

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

  • کمک به تیم‌های توسعه در محیط آزمایشی

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

نمونه‌کار و درخواست شغل

راهنمای نمونه‌کار

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

اجزای ضروری نمونه‌کار

  • README فارسی یا انگلیسی روشن شامل مسئله، معماری، پیش‌نیازها و مراحل اجرای پروژه.

  • فایل‌های Terraform یا ابزار مشابه برای تعریف زیرساخت قابل‌تکرار.

  • فایل‌های Docker و تنظیمات اجرای سرویس، بدون کلید، رمز عبور یا نشانی داخلی واقعی.

  • نمودار ساده ارتباط سرویس، پایگاه داده، شبکه و مسیر دسترسی کاربران.

  • پایش پایه با یک داشبورد، شاخص سلامت یا هشدار قابل‌توضیح.

  • بخش «سناریوی خرابی و بازیابی» شامل آنچه آزموده‌اید و نتیجه آن.

  • فهرست تصمیم‌ها و محدودیت‌ها: مثلاً دلیل انتخاب volume، شبکه خصوصی یا سطح دسترسی.

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

  • زیرساخت قابل‌تکرار برای یک سرویس کانتینری

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

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

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

  • استقرار چندسرویسی با شبکه و دسترسی محدود

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

  • پشتیبان‌گیری و بازیابی آزمایش‌شده

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

راهنمای رزومه و درخواست شغل

رزومه نخستین مهندس کلود باید بر شواهد عملی تمرکز کند. عنوان شغلی موردنظر، مهارت‌های مرتبط و پیوند مخزن نمونه‌کار را در نیمه بالایی رزومه قرار دهید. عبارت‌هایی مانند «مسلط به همه سرویس‌های AWS» یا «متخصص Kubernetes» بدون سابقه تولیدی، اعتماد ایجاد نمی‌کند.

رزومه و پروفایل حرفه‌ای

  • برای هر پروژه، مسئله، ابزار، مسئولیت و خروجی را بنویسید. مثلاً «تعریف محیط آزمایشی با Terraform و مستندسازی بازیابی پایگاه داده».

  • نام ابزارها را فقط وقتی درج کنید که بتوانید کاربردشان در پروژه را توضیح دهید.

  • تجربه‌های قبلی در پشتیبانی، شبکه، توسعه، دانشگاه یا پروژه دانشجویی را با تمرکز بر عیب‌یابی، خودکارسازی و مستندسازی بازنویسی کنید.

  • لینک GitHub یا GitLab و در صورت وجود، پروفایل LinkedIn را درج کنید. مخزن باید مرتب، بدون اطلاعات حساس و دارای README باشد.

یافتن و انتخاب فرصت

برای جست‌وجوی فرصت، آگهی‌های جاب‌ویژن، جابینجا، ایران‌تلنت، کوئرا جابز و LinkedIn را با عنوان‌های فارسی و انگلیسی نزدیک بررسی کنید. افزون بر «Cloud Engineer»، عبارت‌های «مهندس زیرساخت ابری»، «کارشناس زیرساخت»، «کارآموز دواپس»، «Cloud Operations» و «Cloud Infrastructure Engineer» را جست‌وجو کنید.

برای هر درخواست، رزومه را با شرح وظایف آگهی تطبیق دهید. اگر آگهی بر Linux و Docker تأکید دارد، پروژه‌ای را برجسته کنید که این دو را واقعاً نشان می‌دهد. اگر Terraform یا Kubernetes در آگهی الزام شده است، بهتر است پیش از مصاحبه بتوانید کاربرد آن را توضیح دهید و یک تمرین یا پروژه مرتبط برای ارائه داشته باشید. اگر در بخشی از نیازمندی‌ها فاصله دارید، میزان انطباق کلی خود با آگهی را نیز در نظر بگیرید. در پیام کوتاه درخواست، به یک پروژه مرتبط اشاره کنید و از ارسال متن یکسان برای همه شرکت‌ها پرهیز کنید.

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

چک‌لیست آمادگی درخواست

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

  • یک مخزن Git مرتب با README، معماری و مراحل اجرای پروژه آماده کرده‌اید.
  • در مخزن نمونه‌کار هیچ کلید، رمز عبور، توکن یا نشانی داخلی واقعی وجود ندارد.
  • حداقل یک پروژه قابل‌تکرار با ابزارهایی مانند Docker و Terraform دارید یا می‌توانید کاربرد آن‌ها را در یک تمرین عملی توضیح دهید.
  • برای پروژه خود یک سناریوی اختلال و گزارش تشخیص و بازیابی ثبت کرده‌اید.
  • می‌توانید کاربرد Linux، شبکه، Git و اسکریپت‌نویسی را در پروژه خود توضیح دهید.
  • رزومه شما به‌جای فهرست ابزارها، خروجی پروژه‌ها و مسئولیت‌ها را نشان می‌دهد.
  • لینک GitHub یا GitLab در رزومه بررسی و قابل‌دسترسی شده است.
  • عنوان‌های نزدیک به مهندس کلود را در جست‌وجوی فرصت‌های شغلی وارد کرده‌اید.
  • برای هر آگهی، بخش مهارت‌ها و پروژه‌های رزومه را با نیاز همان موقعیت تطبیق داده‌اید.
  • پرسش‌های خود درباره آن‌کال، سطح دسترسی و ساختار تیم را پیش از گفت‌وگو آماده کرده‌اید.

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

در این بخش، به تعدادی از پرسش‌های رایج درباره این مسیر پاسخ داده شده است.

برای اولین شغل مهندس کلود چند نمونه‌کار لازم است؟

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

آیا گواهی‌نامه برای استخدام مهندس کلود کافی است؟

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

آیا می‌توان از شغل مدیر سیستم وارد مهندسی کلود شد؟

بله، این یکی از مسیرهای نزدیک است. تجربه Linux، سرویس‌ها، مجوزها، پشتیبان‌گیری و عیب‌یابی ارزشمند است. برای نزدیک شدن به مهندسی کلود، باید خودکارسازی، زیرساخت به‌عنوان کد، کانتینرسازی و مفاهیم سرویس‌های ابری را به آن اضافه کنید.

برای موقعیت جونیور، Kubernetes ضروری است؟

به آگهی بستگی دارد. برخی تیم‌ها Kubernetes را می‌خواهند و برخی بیشتر بر Linux، Docker، شبکه و Terraform تمرکز دارند. پیش از ورود عمیق به Kubernetes، مطمئن شوید می‌توانید یک سرویس کانتینری و خطاهای پایه شبکه و سیستم را مدیریت کنید.

اگر سابقه کار رسمی ندارم، در رزومه چه بنویسم؟

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

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

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

برچسب‌ها و کلیدواژه‌ها

ورود به شغل مهندس کلوداستخدام مهندس کلوداولین شغل Cloud Engineerرزومه مهندس کلودنمونه‌کار مهندس کلودکارآموزی کلوداستخدام مهندس زیرساخت ابریاستخدام Cloud Infrastructure Engineerپورتفولیو Terraformپروژه Docker و Kubernetes