بازار کار زیرساخت ایران در ۲۰ آبان ۱۴۰۵: آیندهٔ DevOps، SRE، مدیر سیستم و مهندس شبکه
فهرست نوشته
اگر پاسخ یک‌خطی بخواهیم، این چهار شغل نه با هوش مصنوعی (AI) حذف می‌شوند و نه به شکل امروز دست‌نخورده می‌مانند. کارهای تکراری، دستورمحور و قابل‌بررسی با یک تست ساده ارزان‌تر و خودکارتر می‌شوند. در مقابل، طراحی برای خرابی، امنیت، بازیابی، کنترل تغییر و فهم وابستگی‌های واقعی ارزش بیشتری پیدا می‌کند. جنگ اهمیت طراحی برای خرابی و بازیابی را بیشتر کرده، اما الزاماً شغل بیشتری نساخته است: سازمان به پایداری بیشتری نیاز دارد، در حالی که پول و توان استخدامش کمتر شده است.
این نوشته برای کسی است که اکنون در DevOps، مهندسی قابلیت اطمینان سایت یا SRE، مدیریت سیستم و مهندسی شبکه کار می‌کند یا می‌خواهد وارد یکی از این مسیرها شود. وضعیت قابل مشاهده تا ۲۰ آبان ۱۴۰۵ را از پیش‌بینی جدا می‌کنیم، اثر AI را در سطح وظیفه می‌سنجیم و در پایان به یک برنامهٔ عملی برای شش تا دوازده ماه آینده می‌رسیم.
این تحلیل چه چیزی را می‌تواند بگوید؟#
در ایران آمار عمومی و پیوسته‌ای نداریم که تعداد شاغلان یا آگهی‌های هر چهار نقش را با تعریف یکسان نشان دهد. عنوان‌ها نیز روی هم می‌افتند؛ ممکن است یک شرکت همان کار را «DevOps Engineer» و شرکتی دیگر «Linux Administrator» یا «Platform Engineer» بنامد. بنابراین هیچ عددی در این نوشته، اندازهٔ دقیق بازار ایران نیست.
سه دسته شواهد را کنار هم می‌گذاریم:
- دادهٔ آگهی و حقوق ایران، برای دیدن فشار اقتصادی و رفتار استخدام؛
- دادهٔ جهانی نقش‌ها، برای تشخیص جهت اتوماسیون و مهارت‌های در حال رشد؛
- رخدادهای واقعی جنگ و اینترنت، برای فهمیدن اینکه سازمان اکنون بابت چه نوع خرابی‌ای هزینه می‌دهد.
اعداد جهانی را به ایران تعمیم نمی‌دهیم و نتیجه‌های آینده را به‌صورت سناریو می‌نویسیم، نه پیشگویی. در تاریخ این نوشته، حملات متقابل ادامه دارد و تلاش‌های دیپلماتیک بیشتر شده است، اما توافق جامع نزدیک به نظر نمی‌رسد. گزارش ۱۸ آبان رویترز دربارهٔ وضعیت جنگ و مذاکرات
بازار ایران: کار حیاتی‌تر شده، استخدام نه#
آخرین برآورد اکتبر ۲۰۲۶ صندوق بین‌المللی پول برای ایران، انقباض ۷٫۶ درصدی تولید ناخالص داخلی و تورم متوسط ۷۸٫۶ درصدی در سال ۲۰۲۶ است. این‌ها پیش‌بینی‌اند، نه اندازه‌گیری نهایی سال، و خود جنگ دامنهٔ خطا را بزرگ می‌کند. بااین‌حال جهت کلی روشن است: بنگاه‌ها هم‌زمان با افت تقاضا، افزایش هزینه و نااطمینانی روبه‌رو هستند. برآورد رشد ایران ، برآورد تورم ایران
آخرین دادهٔ عمومی استخدام که در این تحلیل یافته‌ام مربوط به اردیبهشت است، نه بازار روز آبان، و همهٔ گروه‌های شغلی جاب‌ویژن را یک‌جا می‌سنجد. با این محدودیت، شدت شوک را خوب نشان می‌دهد: در هفتهٔ دوم اردیبهشت ۱۴۰۵، تعداد آگهی‌ها ۵۳ درصد کمتر از میانگین دورهٔ مشابه دو سال گذشته بود. در همان گزارش، بیش از ۷۳۰۰ شرکت از آغاز جنگ حدود ۲۰ هزار موقعیت ثبت کرده بودند و حدود ۱۵ هزار مورد به دورهٔ پس از آتش‌بس مربوط می‌شد. پس بازار متوقف نشده بود، اما تعداد آگهی‌ها با روند عادی فاصلهٔ زیادی داشت. گزارش کامل جاب‌ویژن دربارهٔ اثر جنگ بر بازار کار
این گزارش کل اقتصاد نیست و به کاربران یک کاریابی آنلاین محدود می‌شود. نظرسنجی بعدی همان پلتفرم نیز از میان کارجویان فعال انجام شده بود؛ بنابراین عدد ۵۲ درصد ازدست‌دادن شغل را نمی‌توان به همهٔ شاغلان ایران نسبت داد. ارزش این داده در نشان‌دادن جهت است: عرضهٔ نیروی جویای کار سریع‌تر از فرصت‌های تازه رشد کرده و قدرت انتخاب کارفرما بیشتر شده است. روش و محدودیت نظرسنجی کارجویان
عدد حقوق هم به‌تنهایی خبر خوب نیست. ایران‌تلنت میانهٔ حقوق خالص درخواستی کارشناس DevOps و SRE در تهران را برای ۱۴۰۵ حدود ۵۹ میلیون تومان و بازهٔ میانی را ۴۷ تا ۶۹ میلیون گزارش می‌کند. عدد مقایسه‌ای ۱۴۰۴، حقوق دریافتی ۴۰ میلیون تومان است؛ چون یکی درخواست و دیگری دریافت واقعی است، رشد اسمی ۴۸ درصدی را نباید رشد قطعی حقوق یا قدرت خرید دانست. به‌ویژه وقتی برآورد تورم از آن بالاتر است. داده و تعریف حقوق DevOps و SRE در ۱۴۰۵
برآیند این سه نشانه چنین است: می‌توان انتظار داشت در کوتاه‌مدت، تعداد فرصت‌ها و قدرت خرید زیر فشار بماند؛ در عین حال سازمان‌هایی که بانک، پرداخت، درمان، ارتباطات، انرژی، دیتاسنتر یا سرویس داخلی را اداره می‌کنند نمی‌توانند عملیات زیرساخت را کنار بگذارند. نیاز فنی با بودجهٔ استخدام یکی نیست. ممکن است تیم کوچک‌تر شود و همان تیم کوچک، سامانه‌ای حساس‌تر را با آماده‌باش سنگین‌تر اداره کند.
AI شغل را یک‌جا نمی‌گیرد؛ وظیفه را جدا می‌کند#
هوش مصنوعی مولد در تولید خروجی‌هایی که نمونهٔ فراوان و روش بررسی سریع دارند مفید است: ساخت پیش‌نویس زنجیرهٔ خودکار ساخت و استقرار (pipeline)، تبدیل یک پیکربندی به قالب، نوشتن تست، خلاصه‌کردن لاگ و ساخت خط زمانی رخداد. اما تولیدشدن پاسخ با درست‌بودن آن در محیط واقعی فرق دارد. توپولوژی ناقص، نسخهٔ متفاوت، مقدار محرمانهٔ فاش‌شده یا یک فرض غلط دربارهٔ ترتیب جابه‌جایی هنگام خرابی می‌تواند پیشنهاد ظاهراً معقول را خطرناک کند.
در پیمایش ۲۰۲۶ Stack Overflow، فقط ۶٫۶ درصد پاسخ‌دهندگان گفتند برای تصمیم‌های مهم کاری به خروجی AI اعتماد می‌کنند؛ ۴۸ درصد اعتماد را به حالتی محدود کردند که بتوانند نتیجه را آسان بررسی کنند. در همان پیمایش، ۱۹٫۹ درصد گفته‌اند در استقرار، عملیات یا عیب‌یابی سامانهٔ عملیاتی از AI یا عامل استفاده می‌کنند؛ این پرسش میزان خودمختاری عامل را نشان نمی‌دهد. این پیمایش نمونهٔ همهٔ متخصصان جهان یا ایران نیست، ولی مرز فعلی استفاده را خوب نشان می‌دهد: استفاده عملیاتی آغاز شده است، اما اعتماد به تصمیم مهم هنوز محدود و مشروط به بررسی است. دادهٔ اعتماد و وظایف واگذارشده به AI
پژوهش DORA نیز از نزدیک پنج هزار متخصص نتیجه‌ای هم‌جهت دارد. در دادهٔ ۲۰۲۵، پذیرش AI با نرخ تحویل نرم‌افزار بیشتر و پایداری کمتر هم‌بستگی داشت؛ این رابطهٔ مشاهده‌ای، علیت را ثابت نمی‌کند. تست خودکار، بازخورد سریع، تغییر کوچک و معماری کم‌وابسته کمک می‌کنند سرعت بیشتر به رخداد بیشتر تبدیل نشود. گزارش DORA ۲۰۲۵
| کاری که بیشتر خودکار می‌شود | کاری که ارزش انسانی آن بیشتر می‌شود |
|---|---|
| تولید پیش‌نویس YAML، Terraform و Ansible | مشخص‌کردن محدودیت، دامنهٔ اثر تغییر و معیار قبولی |
| خلاصه‌کردن هشدار و لاگ | تشخیص ارتباط علّی میان چند سامانه و تصمیم زیر فشار |
| پیشنهاد دستور عیب‌یابی | سنجش خطر دستور، دسترسی لازم و مسیر بازگشت |
| ساخت راهنمای عملیاتی اولیه | آزمودن راهنما در خرابی واقعی و به‌روز نگه‌داشتن آن |
| تغییر تکراری روی تعداد زیادی منبع | طراحی سیاست، تأیید، انتشار آزمایشی و بازگشت |
| پاسخ به پرسش مستنداتی | پذیرفتن مسئولیت امنیت، هزینه و پیامد کسب‌وکار |
گزارش مه ۲۰۲۶ بنیاد لینوکس هم با ادعای «حذف همهٔ مشاغل فناوری اطلاعات (IT)» سازگار نیست. در پیمایش ۴۰۰ مسئول استخدام و آموزش IT، اثر خالص مورد انتظار AI بر استخدام IT در ۲۰۲۶ مثبت ۳۱ درصد و برای عملیات IT مثبت ۱۷ درصد بود. در عین حال، سازمان‌ها برای پرکردن شکاف مهارت بیشتر سراغ آموزش نیروی موجود می‌رفتند تا استخدام تازه. این اعداد ادراک پاسخ‌دهندگان‌اند و رکود یا وضعیت ایران را اندازه نمی‌گیرند؛ پیام مهم برای تازه‌کار این است که رشد کار لزوماً به رشد موقعیت ورودی منجر نمی‌شود. گزارش State of Tech Talent 2026
سرنوشت محتمل هر نقش#
این جابه‌جایی برای همهٔ سطح‌ها یکسان نیست. کارآموز یا نیروی تازه‌کاری که از تیکت‌های ساده تجربه می‌گرفت، با ورودی‌های کمتری روبه‌رو می‌شود و باید توانش را با آزمایشگاه و نمونه‌کار قابل بررسی نشان دهد. نیروی ارشد راحت‌تر جای AI را در فرایند مشخص می‌کند، اما با خطر دیگری روبه‌روست: گسترده‌ترشدن مسئولیت و آماده‌باش بدون افزایش متناسب تعداد نفرات.
| نقش | جهت محتمل | بخش بیشتر در معرض فشار | مزیت ماندگارتر |
|---|---|---|---|
| DevOps | تبدیل‌شدن به مهندسی پلتفرم | زنجیرهٔ استقرار و استقرار تکراری | پلتفرم خودخدمت، سیاست و امنیت زنجیرهٔ تأمین |
| SRE | مقاوم‌تر، اگر نقش واقعاً مهندسی باشد | دسته‌بندی هشدار و گزارش رخداد | SLO، ظرفیت، فرماندهی رخداد و بازیابی |
| مدیر سیستم | بیشترین فشار برای تغییر شکل | نصب، وصله‌کردن و مدیریت کاربر به‌صورت دستی | خودکارسازی، هویت، زیرساخت ترکیبی و بازیابی |
| مهندس شبکه | دوپاره‌شدن میان اپراتوری و معماری | تنظیم یک‌به‌یک دستگاه و مرکز عملیات شبکهٔ سطح اول | معماری، خودکارسازی، امنیت و سنجش سرتاسری |
DevOps: از نگه‌دارندهٔ زنجیرهٔ استقرار به سازندهٔ پلتفرم#
اگر ارزش فرد به نوشتن چند فایل یکپارچه‌سازی و تحویل پیوسته (CI/CD)، کپی‌کردن Helm chart و اجرای دستی استقرار محدود باشد، بخش بزرگی از کارش زیر فشار قالب‌های آماده و AI قرار می‌گیرد. در عوض، سازمانی که تیم‌های متعدد دارد به یک مسیر استاندارد و امن از ثبت تغییر تا محیط عملیاتی نیاز پیدا می‌کند. این همان جایی است که مهندسی پلتفرم معنا پیدا می‌کند: تیم زیرساخت یک مسیر خودخدمت با حفاظ‌های سیاستی می‌سازد، نه اینکه برای هر تیم نقش اپراتور دستی را بازی کند.
مهارت‌های باارزش‌تر شامل GitOps برای همگام‌کردن وضعیت سامانه از Git، تعریف سیاست به‌صورت کد (Policy as Code)، امنیت زنجیرهٔ تأمین نرم‌افزار، مدیریت مقادیر محرمانه، کنترل هزینه و تعریف زیرساخت در کد (Infrastructure as Code) است. جنگ یک نیاز دیگر اضافه می‌کند: مخزن خروجی ساخت (artifact registry) و آینهٔ داخلی آن، خروجی ساخت امضاشده و فرایند استقراری که با قطع سرویس خارجی کاملاً از کار نیفتد.
این تغییر فقط نام تازه نیست. گزارش سه‌ماههٔ سوم ۲۰۲۶ بنیاد Cloud Native Computing Foundation یا CNCF می‌گوید ۹۳ درصد پاسخ‌دهندگان در سازمانی با استانداردسازی DevOps یا پلتفرم داخلی کار می‌کنند. این آمار جهانی، تعداد شغل ایران را نشان نمی‌دهد، اما جهت شیوهٔ کار و سازمان‌دهی زیرساخت را نشان می‌دهد: پلتفرم DevOps بیشتر مانند یک محصول داخلی اداره و استاندارد می‌شود. گزارش CNCF و SlashData
SRE: تقاضا برای قضاوت مهندسی باقی می‌ماند#
مهندسی قابلیت اطمینان سایت (Site Reliability Engineering یا SRE) پایداری را با ابزار مهندسی نرم‌افزار اداره می‌کند. AI می‌تواند هشدارها را خوشه‌بندی، رخدادهای مشابه را پیدا و خط زمانی را خلاصه کند؛ اما تعیین هدف سطح خدمت (Service Level Objective یا SLO)، سیاست مصرف بودجهٔ خطا، تصمیم دربارهٔ ادامه یا توقف انتشار و فرماندهی رخداد هنوز به فهم سامانه و تعهد کسب‌وکار وابسته است.
از نظر نوع وظایف، متخصص SRE که واقعاً SLO، مشاهده‌پذیری، ظرفیت، مدیریت رخداد و مهندسی بازیابی می‌داند در این تحلیل مقاوم‌تر به نظر می‌رسد. در مقابل، اگر عنوان SRE فقط نام دیگری برای پایش داشبورد و بستن هشدار باشد، همان بخش کار سریع‌تر خودکار می‌شود. معیار آینده تعداد ابزارهای رزومه نیست؛ توان تبدیل خرابی مبهم به فرضیه، آزمایش کم‌خطر و تصمیم مستند است.
مدیر سیستم: بیشترین فشار برای تغییر شکل#
مدیریت کاربر، نصب تکراری، وصله‌کردن دستی، تنظیم سرور از پنل و پاسخ به تیکت‌های قابل پیش‌بینی بیشترین قابلیت اتوماسیون را دارند. ادارهٔ سرویس‌های «نرم‌افزار به‌عنوان خدمت» یا SaaS و زیرساخت ابری نیز تعداد سرورهایی را که یک سازمان مستقیم نگه‌داری می‌کند کاهش می‌دهد. ادارهٔ آمار نیروی کار آمریکا (BLS) برای ۲۰۲۵ تا ۲۰۳۵، افت ۴ درصدی شغل مدیر شبکه و سیستم‌های رایانه‌ای (Network and Computer Systems Administrators) را پیش‌بینی می‌کند؛ این عدد مربوط به آمریکاست، اما توضیحش ــ انتقال وظایف به DevOps، سرویس مدیریت‌شده و اتوماسیون ــ برای فهم جهت تغییر مفید است. پیش‌بینی و توضیح BLS
این نقش حذف نمی‌شود؛ از «نگه‌داری یک سرور» به ادارهٔ ناوگان و تداوم سرویس می‌رود. دانش عمیق Linux، مدیریت هویت، مجازی‌سازی، Ansible، پشتیبان آفلاین، آزمون بازیابی، سامانهٔ نام دامنه (DNS) و پروتکل زمان شبکه (NTP) داخلی، برق و منبع تغذیهٔ بدون وقفه (UPS) و ظرفیت قطعهٔ یدکی در زیرساخت محلی ایران مزیت واقعی‌اند. مدیر سیستمی که خرابی سخت‌افزار، قطع اینترنت و ازدسترفتن سرویس بالادست را در طراحی می‌بیند با کسی که فقط دستور نصب حفظ کرده در یک بازار نیست.
مهندس شبکه: پیکربندی دستی کم‌ارزش‌تر، معماری مهم‌تر#
پیکربندی یک‌به‌یک سوئیچ و مسیریاب، بررسی اولیهٔ هشدار و تغییرهای استاندارد با قالب، رابط برنامه‌نویسی (API) و AI خودکارتر می‌شوند. در مقابل، طراحی مسیر، امنیت، مقابله با منع خدمت توزیع‌شده (DDoS)، جداسازی شبکه، DNS، پروتکل دروازهٔ مرزی (BGP)، شبکهٔ دیتاسنتر و اتصال بارهای کاری AI پیچیده‌تر شده‌اند. BLS برای معمار شبکه (Computer Network Architect) در آمریکا رشد ۸ درصدی تا ۲۰۳۵ پیش‌بینی می‌کند، در حالی که اداره و نگه‌داری روزمرهٔ شبکه و سیستم را کاهشی می‌بیند. این اختلاف از خود عنوان‌ها مهم‌تر است: بازار از اپراتور دستگاه به مهندس سامانهٔ شبکه حرکت می‌کند. پیش‌بینی Network Architect
جنگ یک درس فنی روشن هم داده است. هنگام خاموشی دوم ایران، Cloudflare در ۹ اسفند ۱۴۰۴ افت ترافیک مشاهده‌شده در شبکهٔ خود به کمتر از یک درصد مقدار قبلی را ثبت کرد و بازیابی جزئی از ۵ خرداد، پس از ۸۷ روز، آغاز شد. اعلان پیشوندهای IPv4 در BGP تا حد زیادی باقی مانده بود، اما ترافیک مشاهده‌شده تقریباً از بین رفته بود و فضای IPv6 اعلام‌شده تقریباً صفر بود. پس دیدن مسیر در BGP اثبات دسترسی کاربر نیست؛ مهندس شبکه به سنجهٔ فعال بیرونی، تراکنش مصنوعی و سنجش صفحهٔ داده (data plane) نیاز دارد. تحلیل فنی Cloudflare از خاموشی و بازیابی
جنگ چه مهارت‌هایی را از «خوب است داشته باشیم» به «ضروری» تبدیل کرد؟#
اثر جنگ به حملهٔ سایبری محدود نیست؛ می‌تواند برق، مسیر فیبر، قطعه، نیروی انسانی و چند مرکز دادهٔ ظاهراً مستقل را هم‌زمان مختل کند. در مارس ۲۰۲۶، دو مرکز Amazon Web Services یا AWS در امارات مستقیماً آسیب دیدند و یک مرکز در بحرین نیز پس از فرود پهپاد در نزدیکی آن خسارت دید. AWS سپس از مشتریان منطقهٔ بحرین خواست بار کاری را به مناطق دیگر منتقل کنند. این رخداد یادآوری کرد که چند ناحیهٔ دسترس‌پذیری (Availability Zone) در یک منطقه، بازیابی بحران (Disaster Recovery یا DR) جغرافیایی نیست. گزارش آسیب مراکز امارات و بحرین ، اعلام رسمی AWS دربارهٔ اختلال منطقهٔ بحرین
برای تیم زیرساخت، پیام عملی جنگ این‌هاست:
- دست‌کم یک نسخه را بیرون دامنهٔ خرابی نگه دارید. استقرار چندناحیه‌ای
(
Multi-AZ) را با DR چندمنطقه‌ای، و تکثیر برخط را با پشتیبان مستقل یکی نگیرید؛ تکثیر می‌تواند حذف یا فساد داده را نیز منتقل کند. یک کپی تغییرناپذیر یا آفلاین با دسترسی و کلید بازیابی مستقل نگه دارید و بازیابی آن را واقعاً بیازمایید. - حالت تنزل‌یافته طراحی کنید. مشخص کنید هنگام قطع اینترنت بین‌الملل، کدام قابلیت محلی ادامه می‌یابد، کدام داده در صف می‌ماند و کدام عملیات باید امن متوقف شود. صف باید سقف مشخص داشته باشد؛ هر عملیات باید بدون ایجاد اثر دوباره قابل تکرار باشد و پس از بازگشت اتصال نیز راهی برای آشتی‌دادن داده‌ها وجود داشته باشد.
- وابستگی‌های خارجی و صفحه‌های کنترل را فهرست کنید. DNS، ارائه‌دهندهٔ هویت، registry، مخزن بسته، پیام‌رسان رخداد، درگاه پرداخت و سرور مجوز می‌توانند بدون خرابی سرور اصلی، سرویس را متوقف کنند. برای دسترسی اضطراری، حساب محلی محدود و کنترل‌شده‌ای در نظر بگیرید که به اینترنت، پیامک یا ارائه‌دهندهٔ هویت خارجی وابسته نباشد.
- شبکه را از داخل و بیرون بسنجید. سلامت رابط و BGP کافی نیست؛ نتیجهٔ واقعی حل نام، اتصال رمزنگاری‌شده با امنیت لایهٔ انتقال (TLS)، ورود و تراکنش کاربر را از چند نقطه پایش کنید.
- امنیت تجهیزات متصل را جدی بگیرید. هشدار مشترک نهادهای آمریکایی دربارهٔ هدف‌گیری کنترل‌گرهای منطقی برنامه‌پذیر (PLC) متصل به اینترنت در زیرساخت حیاتی آمریکا، نه گزارشی از حمله به تجهیزات داخل ایران بود. اقدام‌های دفاعی آن برای فناوری عملیاتی (OT) قابل استفاده‌اند: دسترسی شبکه به PLC را سخت‌گیرانه محدود کنید، فایل پروژهٔ در حال اجرا را برای تغییر غیرمجاز اعتبارسنجی کنید و راهنمای امنیتی سازنده را در استقرار به کار ببرید. هشدار مشترک CISA و FBI
مهم‌تر از همه، هیچ هدف سطح خدمتی از جان آدم‌ها مهم‌تر نیست. طرح تداوم کسب‌وکار باید امکان توقف امن، آماده‌باش از راه دور در صورت وجود ارتباط امن، جانشین مشخص و منع حضور اجباری نیروی فنی در محل خطر را پوشش دهد. اگر ارتباط امن وجود ندارد، توقف امن و جانشینی ازپیش‌تعریف‌شده بر ادامهٔ کار به هر قیمت اولویت دارد. قهرمان‌بازی در دیتاسنتر، مهندسی قابلیت اطمینان نیست.
سه سناریو تا ۲۰ آبان ۱۴۰۶#
کاهش پایدار تنش#
اگر توافق سیاسی، اینترنت نسبتاً پایدار و امکان تجارت بهتر شود، استخدام احتمالاً یک‌باره به سطح پیش از بحران برنمی‌گردد. نخست پروژه‌های عقب‌افتادهٔ بازسازی، مهاجرت سامانه‌ها و زیرساخت، امنیت و DR بودجه می‌گیرند. نیروی ارشد و میان‌رده‌ای که بتواند ریسک را کم و سرویس موجود را استاندارد کند زودتر از موقعیت‌های کاملاً ورودی سود می‌برد.
ادامهٔ فرسایش فعلی#
در این سناریو، بانک، اپراتور، سلامت، انرژی، دیتاسنتر، زیرساخت عمومی و پلتفرم‌های بزرگ گزینشی استخدام می‌کنند، اما کسب‌وکارهای کوچک و وابسته به مصرف یا اینترنت جهانی محتاط می‌مانند. ادغام نقش‌ها بیشتر می‌شود: مسئولیت خودکارسازی، آماده‌باش و بخشی از امنیت بر دوش یک نفر می‌افتد. خطر اصلی برای شاغل فقط بیکاری نیست؛ فرسودگی، مسئولیت نامحدود و حقوقی است که از تورم عقب می‌ماند.
تشدید دوباره و خاموشی گسترده#
موج تازهٔ جنگ می‌تواند استخدام، پرداخت و دورکاری برون‌مرزی را سریع مختل یا متوقف کند، در حالی که بار پاسخ به رخداد روی تیم‌های موجود ناگهان بالا می‌رود. در این وضعیت، مهارت DR و شبکه حیاتی‌تر می‌شود، اما «حیاتی‌شدن مهارت» تضمین افزایش حقوق یا امنیت شغلی نیست. دورکاری خارجی هم پشتیبان بدون ریسک نیست: دسترسی به ابزار به اتصال و سیاست ارائه‌دهنده، و دریافت دستمزد به مسیر پرداخت موجود وابسته می‌ماند. راهنمای OFAC فقط برخی خدمات ابری مرتبط با ارتباطات اینترنتی را تحت شرایط مشخص مجاز می‌داند؛ این راهنما مجوز کلی استفاده از هر سرویس ابری نیست. راهنمای رسمی وزارت خزانه‌داری آمریکا دربارهٔ خدمات ارتباطی و ابری
برای شش ماه آینده چه چیزی بسازیم؟#
مدرک و فهرست ابزار به‌تنهایی تفاوت نمی‌سازند. یک نمونه‌کار کوچک اما قابل آزمایش بسازید که نشان دهد تغییر و خرابی را می‌فهمید:
- یک سرویس ساده را با Terraform یا Ansible و زنجیره‌ای قابل تکرار مستقر کنید؛
بررسی ایستا (
lint)، تست، تأیید، انتشار آزمایشی و بازگشت را در مخزن نشان دهید. - برای سرویس یک شاخص سطح خدمت (Service Level Indicator یا SLI) و SLO تعریف کنید، سپس داشبورد و هشدار را به رفتار کاربر وصل کنید؛ هشدار صرف مصرف پردازنده نمونهٔ کافی نیست.
- حد قابل قبول ازدسترفتن داده (Recovery Point Objective یا RPO) و زمان هدف بازیابی (Recovery Time Objective یا RTO) را بنویسید، پشتیبان بگیرید و در یک محیط آزمایشی تازه بازیابی کنید. زمان و نتیجه را ثبت کنید؛ گزارش شکست بازیابی از ادعای «پشتیبان داریم» باارزش‌تر است.
- قطع DNS خارجی، registry یا مسیر اینترنت را در آزمایشگاه شبیه‌سازی کنید و حالت تنزل‌یافته را مستند کنید.
- برای شبکه از
containerlabیا محیط مشابه استفاده کنید؛ پیکربندی را از قالب بسازید، پیش از اعمال اعتبارسنجی کنید و با سنجهٔ فعال مستقل صفحهٔ داده را بسنجید. - از AI برای تولید پیش‌نویس و فرضیه استفاده کنید، اما مقدار محرمانه را وارد
ابزاری با سیاست نامشخص حریم خصوصی و نگه‌داری داده نکنید. خروجی را به نمایش
تفاوت‌ها (
diff) تبدیل کنید، ابتدا به‌صورت فقط‌خواندنی یا در محیط آزمایش اجرا کنید و برای تغییر محیط عملیاتی تأیید انسانی و مسیر بازگشت نگه دارید.
سپس مسیر را بر اساس نقش متمرکز کنید: DevOps روی پلتفرم و زنجیرهٔ تأمین، SRE روی SLO و رخداد، مدیر سیستم روی خودکارسازی و بازیابی، و مهندس شبکه روی API، امنیت و سنجش سرتاسری. لازم نیست هم‌زمان Kubernetes، پنج سرویس ابری و سه سازندهٔ تجهیزات شبکه را سطحی یاد بگیرید. یک سامانه را آن‌قدر کامل بسازید که بتوانید دربارهٔ حالت خرابی، هزینه و دلیل انتخاب‌ها دفاع کنید.
هنگام ارزیابی پیشنهاد کار نیز فقط عدد حقوق را نپرسید. اندازه و ترکیب تیم، تناوب آماده‌باش، جبران شیفت، اختیار توقف تغییر، آخرین مانور بازیابی، وابستگی به اینترنت خارجی و برنامهٔ سازمان برای قطع برق یا تخلیهٔ محل را روشن کنید. پاسخ مبهم به این پرسش‌ها بخشی از ریسک واقعی پیشنهاد است.
جمع‌بندی#
تا ۲۰ آبان ۱۴۰۵، شواهد موجود نشان نمی‌دهند که DevOps، SRE، مدیریت سیستم یا مهندسی شبکه در حال ناپدیدشدن‌اند. در عوض، بازار سخت‌تر و مرز میان دو نوع نیروی زیرساخت پررنگ‌تر شده است: اپراتوری که فرمان و تنظیم تکراری اجرا می‌کند، و مهندسی که دامنهٔ خرابی، امنیت، هزینه، وابستگی، روش سنجش و مسیر بازگشت را می‌فهمد.
AI فاصلهٔ این دو را بیشتر می‌کند. جنگ نیز ارزش دستهٔ دوم را بالا می‌برد، ولی هم‌زمان بودجه، قدرت خرید و ظرفیت استخدام را پایین می‌آورد. بنابراین هدف معقول برای سال پیش رو «یادگرفتن ابزار داغ بعدی» نیست؛ باید بتوانیم با کمک AI سریع‌تر کار کنیم، بدون اینکه کلید محیط عملیاتی را بی‌حفاظ به آن بدهیم، و سامانه‌ای بسازیم که در قطع ارتباط، خرابی منطقه و کمبود آدم به شکلی قابل پیش‌بینی تنزل پیدا کند و قابل بازیابی بماند.