از مولتیتسکینگ تا DevOps: سفر من به دنیای زیرساخت ابری با AWS
مقدمه: جایی که همهچیز تغییر کرد
اگر کسی چند سال پیش به من میگفت که روزی معماری زیرساخت یک پروژه روی AWS را از صفر تا صد برعهده میگیرم، شاید فقط لبخند میزدم و به اسکرامبورد روزانهام برمیگشتم. من مونا بزرگیام، کسی که مسیرش را از اسکرام مستری و مدیریت تیمهای تولید آغاز کرد، با چند مهارت پراکنده در توسعه و تجربهکاری از نزدیک با تیمهای فنی. اما یک روز تصمیم گرفتم از منطقه امنم خارج شوم.
و آن روز، آغاز سفرم به دنیای DevOps بود.
⸻
آغاز مسیر: از پراکندگی به عمق
مولتیتسکینگ تا مدتها بخشی از هویت کاری من بود. تواناییِ مدیریت همزمان چند کار، برایم یک مزیت محسوب میشد. اما وقتی وارد پروژهای شدم که نیاز به طراحی و راهاندازی زیرساخت از پایه در AWS داشت، فهمیدم که اینجا «عمق» مهمتر از «تعداد» است.
در دنیای زیرساخت، تمرکز، تحلیل، و درک روابط پیچیده سرویسها، پایهی هر تصمیم است. دیگر خبری از کارهای سریع و چکباکسهای روزانه نبود. هر گام، با خودش دهها گره فنی و مفهومی میآورد.
⸻
پروژه: راهاندازی زیرساخت از صفر روی AWS
پروژهای که من به آن وارد شدم، یک فرصت واقعی بود: طراحی کل زیرساخت یک محصول از نقطه صفر، بدون هیچ ساختار قبلی، روی AWS. نه تنها مسئول انتخاب سرویسهای کلیدی مانند EC2، S3، RDS، و VPC بودم، بلکه باید فرآیندهای CI/CD را هم با استفاده از ابزارهایی مثل CodePipeline، CodeBuild و CodeDeploy پیادهسازی میکردم.
ساده نبود. اصلاً ساده نبود.
⸻
لحظات بحران، لحظات یادگیری
در شروع کار، حتی ورود به پنل AWS و شناخت محیط برایم استرسآور بود. با ارورها و پیامهایی مواجه میشدم که پیش از آن حتی اسمشان را نشنیده بودم. تنظیم IAM، تعریف Ruleهای امنیتی، راهاندازی Auto Scaling، ساختن Policyهای دقیق برای هر رول…
اما هر بنبست، تبدیل میشد به یک مسیر تازه. یاد گرفتم مستندات AWS بهترین دوست من است. هر بار که گرهای باز میکردم، انگار کمی بیشتر خودم را میشناختم.
⸻
یادگیریهایی که زندگی حرفهایام را تغییر داد
۱. ساختار تفکر زیرساختی
AWS فقط یک سری ابزار نیست؛ یک طرز فکر است. یاد گرفتم که هر تصمیم، در مقیاس بالا، پیامد دارد. تفکر سیستمی بخشی از دیانای DevOps است.
۲. CI/CD یعنی آرامش تیم
راهاندازی فرآیندهای استقرار خودکار با CodePipeline و CodeBuild، یک بازی عوضکن برای تیم ما بود. کمتر خطا، بیشتر اعتماد، انتشار سریعتر.
۳. امنیت فقط یک گزینه نیست
درک دقیق از IAM، طراحی Least Privilege، بررسی لاگها، و تعریف دسترسیها با دقت میلیمتری — اینها نهفقط امنیت را حفظ میکنند، بلکه مسئولیتپذیری را هم افزایش میدهند.
۴. مانیتورینگ بهجای انتظار
با CloudWatch و ابزارهای مانیتورینگ دیگر، آموختم که باید پیش از وقوع خطاها، سیگنالهای آن را ببینم و آماده باشم.
⸻
تجربهای که من را ساخت
این پروژه برای من فقط یک مسئولیت نبود، یک مسیر بود؛ مسیری برای ساختهشدن.
من امروز هنوز خودم را مهندس DevOps نمیدانم — اما کسی هستم که تصمیم گرفت در مسیرش قدم بگذارد و از هر پیچ این مسیر، چیزی بسازد.
⸻
اگر تو هم به DevOps فکر میکنی…
این ۴ نکته را جدی بگیر:
1. هیچچیز را حفظ نکن — بفهم.
2. امنیت را از روز اول طراحی کن، نه در آخرین مرحله.
3. مستندسازی، نجاتبخش تو و تیم تو در آینده است.
4. سکوت کن، اما سوال بپرس. وقتی گیر کردی، Google و مستندات AWS رفیقهات هستن.
⸻
جمعبندی: هنوز در مسیرم، اما دیگر آن آدم سابق نیستم
من هنوز در میانهی پروژهام. هنوز زیرساخت کامل نشده. هنوز دارم هر روز یاد میگیرم و هر روز با چالش تازهای روبهرو میشوم. اما حالا با اطمینان میگویم که مسیر DevOps، مسیر آدمهاییست که دوست دارند هم مهارت تکنیکی داشته باشند، هم نگاه کلان، هم توانایی حل مسئله، و هم حوصله یادگیری عمیق.
امیدوارم روزی از پایان این پروژه برایتان بگویم — اما فعلاً، همین مسیر، همین مبارزه، همین رشد… زیباترین داستان من است.
