مهندس قابلیت اطمینان هوش مصنوعی
AI SRE
مهندس قابلیت اطمینان هوش مصنوعی همان کار Site Reliability Engineering (SRE) را انجام می‌دهد، روی سیستم‌هایی که مدل‌های هوش مصنوعی را سرو می‌کنند یا آموزش می‌دهند: تعریف SLO، پایش، on-call، رسیدگی به حادثه و خودکارسازی، این بار برای سرویس inference، خوشهٔ GPU و کارهای آموزش مدل. در آگهی‌های ۲۰۲۶ عنوان دقیق «AI SRE» برای این شغل پیدا نکردیم. کارفرماها همین کار را با عنوان‌هایی مثل Site Reliability Engineer, Inference Infrastructure (Cohere)، AI Reliability Engineering (Anthropic) یا Production Engineer, LLM Serving (FuriosaAI) آگهی می‌کنند. خود عبارت «AI SRE» در بازار بیشتر نام دسته‌ای از ابزارهاست: ایجنت‌های هوش مصنوعی که بررسی حادثه را خودکار می‌کنند. کار با این ابزارها هم کم‌کم به شرط‌های آگهی‌های SRE اضافه می‌شود.
مقدمه و تعریف شغل
طبق ویکی‌پدیا، Site Reliability Engineering رشته‌ای در مهندسی نرم‌افزار و زیرساخت است که دسترس‌پذیری و کارایی سیستم‌های در حال اجرا را پایش و بهتر می‌کند و تکیه‌اش بر خودکارسازی است. مهندس قابلیت اطمینان هوش مصنوعی همین کار را روی سیستم‌های AI انجام می‌دهد: سرویس‌هایی که مدل زبانی را به کاربر می‌رسانند، خوشه‌های GPU و کارهای آموزش مدل. ابزارها و روش‌ها همان SRE است، یعنی SLO، error budget، پایش، on-call و postmortem. آنچه عوض می‌شود سیستم زیر دست است. Anthropic این کار را «قابلیت اطمینان در هر قدم از SDK تا شبکه، لایهٔ API، زیرساخت سرو و شتاب‌دهنده‌ها» توصیف می‌کند. FuriosaAI معیارهایی مثل زمان رسیدن اولین توکن را پایش می‌کند و Thinking Machines سلامت کارهای آموزش را. در بازار ۲۰۲۶ این شغل عنوان ثابتی ندارد و با نام‌های SRE، Production Engineer یا AI Reliability آگهی می‌شود. «AI SRE» بیشتر نام ابزارهایی است که بخشی از این کار را خودکار می‌کنند.
Ben Treynor Sloss در کتاب SRE گوگل می‌نویسد وقتی در ۲۰۰۳ به گوگل آمد، مسئول یک «تیم پروداکشن» هفت‌نفره شد و چون تا آن زمان فقط مهندس نرم‌افزار بود، آن را همان‌طور طراحی کرد که اگر خودش SRE بود دوست داشت کار کند؛ همان گروه به تیم SRE امروز گوگل تبدیل شد. همین کتاب می‌گوید اصطلاح DevOps اواخر ۲۰۰۸ رایج شد. با بزرگ شدن سیستم‌های ML، شاخه‌ای تخصصی شکل گرفت: طبق بیوگرافی USENIX، Todd Underwood تیم‌های ML SRE گوگل را بنیان گذاشت و بعد قابلیت اطمینان پلتفرم پژوهشی OpenAI و سپس Anthropic را بر عهده گرفت. مقالهٔ Llama 3 شرکت Meta در ۲۰۲۴ نشان داد مسئله چقدر جدی است: در ۵۴ روز آموزش روی ۱۶ هزار GPU، ۴۱۹ توقف پیش‌بینی‌نشده رخ داد و حدود ۷۸٪ آن‌ها به سخت‌افزار برمی‌گشت. در ۲۰۲۶ دو روند کنار هم دیده می‌شود. آزمایشگاه‌های مدل، پلتفرم‌های inference و ابرهای GPU برای این کار SRE استخدام می‌کنند. همزمان Gartner در ژانویهٔ ۲۰۲۶ راهنمای بازار «ابزارهای AI SRE» را منتشر کرد و در The SRE Report 2026، ۴۹٪ پاسخ‌دهندگان گفتند AI کار تکراری‌شان را کم کرده است. در ۳۰۶ تابلوی استخدامی که در اکتبر ۲۰۲۶ بررسی کردیم، هیچ آگهی‌ای عنوان «AI SRE» نداشت.
چه چیزی می‌سازید؟
مثال‌های واقعی از خروجی کار یک مهندس قابلیت اطمینان هوش مصنوعی
SLO برای سرویس مدل زبانی
Anthropic از تیم AI Reliability می‌خواهد برای سیستم‌های سرو LLM هدف‌های سطح سرویس تعریف کند و بین دسترس‌پذیری، تأخیر و سرعت توسعه توازن بگذارد. ElevenLabs همین را با هر تیم محصول و به تفکیک محصول و مشتری می‌خواهد.
پایش مسیر توکن
FuriosaAI در کل مسیر درخواست metric، log، trace و هشدار می‌سازد و دسترس‌پذیری، خطا، زمان رسیدن اولین توکن (TTFT)، تأخیر بین توکن‌ها، throughput و مصرف شتاب‌دهنده را دنبال می‌کند.
بازیابی خودکار کارهای آموزش
Thinking Machines از SRE تیم post-training پایش و بازیابی خودکاری می‌خواهد که کار آموزش یا خودش را درست کند یا سریع شکست بخورد، نه اینکه بی‌صدا متوقف بماند، و checkpoint و تحمل خطا را طوری بهتر کند که خرابی سخت‌افزار «چند دقیقه هزینه داشته باشد، نه چند روز».
خط لولهٔ تعمیر GPU
Fluidstack می‌نویسد در مقیاس آن‌ها خرابی GPU یک تیکت نیست، مسئلهٔ throughput است، و اتوماسیونی می‌سازد که تراشه را از تشخیص خطا تا triage، RMA و برگشت به سرویس بدون دخالت انسان ببرد. Wayve هم تشخیص سلامت نودهای GPU و بازیابی خودکار را جزو کار SRE آورده است.
انتشار امن مدل و safeguard
تیم Safeguards ML Infra در Anthropic برای هر مدل تازه safeguardها را پیکربندی و بررسی می‌کند، classifierهای تازه را با canary منتشر می‌کند و اختیار rollback دارد. باید ثابت کند safeguard درست روی مدل درست در همهٔ پلتفرم‌ها (سرویس خود Anthropic، AWS Bedrock، GCP Vertex) فعال است.
ابزار بررسی حادثه با کمک AI
Baseten ساختن ابزار کمک‌گرفته از AI برای triage و رسیدگی به حادثه را جزو پروژه‌های SRE نام برده و از runbookها می‌خواهد طوری نوشته شوند که با زمینهٔ کم و به‌شکل امن اجرا شوند. Fireworks هم ابزار بررسی کمک‌گرفته از AI را بخشی از ابزارهای تیم قابلیت اطمینان می‌داند.
تخصص‌های مختلف مهندس قابلیت اطمینان هوش مصنوعی
این شغل یک عنوان واحد نیست — مسیرهای تخصصی متعددی دارد
قابلیت اطمینان سرویس LLM
LLM Serving Reliability
SLO، پایش و ظرفیت سرویس‌هایی که مدل زبانی را به کاربر می‌رسانند. در آگهی‌های Cohere (Model Serving)، Anthropic (AI Reliability Engineering)، FuriosaAI (LLM Serving) و Crusoe (Managed AI) دیده می‌شود.
قابلیت اطمینان آموزش مدل
Training & Post-training Reliability
سلامت کارهای آموزش و post-training: checkpoint، تحمل خطا، زمان‌بندی و کار نزدیک با پژوهشگران در طول اجرای مدل. آگهی‌های Thinking Machines و Wayve نمونه‌اند.
قابلیت اطمینان ناوگان GPU
GPU Fleet / Compute Reliability
سلامت سخت‌افزار در مقیاس بزرگ: تشخیص خرابی GPU، firmware، RMA و برگشت به سرویس، تا سطح دیتاسنتر. در Fluidstack، Firmus، d-Matrix و SpaceXSI (xAI) دیده می‌شود.
انتشار امن مدل
Release & Safeguard Reliability
مدیریت تغییر در پروداکشن: canary، اعتبارسنجی پس از استقرار، rollback و هماهنگی انتشار مدل تازه روی چند پلتفرم ابری. آگهی Staff+ SRE تیم Safeguards در Anthropic بر همین تمرکز دارد.
عملیات با کمک AI
AI-assisted Operations
ساختن یا به کار گرفتن ایجنت‌ها و ابزارهای مبتنی بر LLM برای بررسی و دسته‌بندی حادثه. در آگهی‌های Fireworks، Baseten و d-Matrix آمده و همان چیزی است که شرکت‌هایی مثل Resolve AI، Traversal، incident.io و Rootly با نام «AI SRE» می‌فروشند.
تفاوت با شغل‌های مشابه
کجا این شغل تمام می‌شود و شغل دیگری شروع می‌شود؟
روش‌ها یکی است: SLO، error budget، on-call، postmortem و کاهش toil. فرق در سیستم زیر دست است: سرور مدل، GPU و کار آموزش، با معیارهایی مثل TTFT و خرابی‌های سخت‌افزاری که در سرویس وب معمولی کمتر دیده می‌شود. بسیاری از آگهی‌ها دانش ML را پیش‌شرط نمی‌دانند. Baseten می‌نویسد تجربهٔ قبلی ML لازم نیست و در آگهی Fireworks تجربه با GPU و زیرساخت ML جزو موارد «ترجیحی» است، نه الزامی. پس این شغل بیشتر یک تخصص درون SRE است تا حرفه‌ای جدا.
طبق ویکی‌پدیا، SRE شبیه DevOps است و هر دو می‌خواهند سیستم‌های در حال اجرا قابل اتکاتر و در دسترس‌تر باشند. مهندس DevOps بیشتر روی مسیر تحویل نرم‌افزار، CI/CD و پلتفرم داخلی کار می‌کند. SRE مالک قابلیت اطمینان سرویس در پروداکشن است، با هدف‌های عددی و on-call. ابزارها مشترک‌اند، از Kubernetes و Terraform تا Prometheus، و در آگهی‌ها مرز نرم است؛ طبق ITJobsWatch، ۶۲٫۲٪ آگهی‌هایی که در بریتانیا مهارت SRE را نام می‌برند DevOps را هم نام می‌برند.
معمار زیرساخت AI خوشهٔ GPU را طراحی می‌کند: کدام سخت‌افزار، کدام شبکه، چه ذخیره‌سازی. SRE آن خوشه و سرویس‌های روی آن را در حال کار نگه می‌دارد: پایش سلامت نودها، بازیابی خودکار، رسیدگی به حادثه و برنامه‌ریزی ظرفیت. دو نقش به هم نزدیک‌اند و SRE یکی از مسیرهای رسیدن به نقش معمار است. آگهی Staff SRE در Wayve پیش‌بینی ظرفیت GPU و ذخیره‌سازی را هم جزو کار می‌داند.
مهندس LLMOps و MLOps چرخهٔ عمر مدل و برنامه‌های مبتنی بر آن را اداره می‌کند: نسخه‌بندی، ارزیابی، pipeline استقرار و پایش کیفیت پاسخ. SRE روی دسترس‌پذیری، تأخیر و ظرفیت سرویسی تمرکز دارد که مدل در آن اجرا می‌شود، و مالک فرایند حادثه است. نقطهٔ تماس دو نقش استقرار و پایش است. آگهی Anthropic برای Safeguards نشان می‌دهد SRE هم با انتشار مدل سروکار دارد: canary، اعتبارسنجی پس از استقرار و rollback.
تأثیر در صنایع مختلف
مهندس قابلیت اطمینان هوش مصنوعی در همه صنایع مشغول به کار است — نه فقط شرکت‌های فناوری
آزمایشگاه‌های مدل پایه
Anthropic، Thinking Machines، Cohere و SpaceXSI (xAI) برای سرو مدل، آموزش و ابررایانه تیم قابلیت اطمینان جدا دارند و بالاترین بازه‌های حقوق در آگهی‌های این حوزه هم از همین‌جاست.
پلتفرم‌های inference
Fireworks به گفتهٔ آگهی‌اش روزانه بیش از ۴۰ تریلیون توکن سرو می‌کند و Baseten، طبق آگهی، inference شرکت‌هایی مثل Cursor و Notion را اجرا می‌کند. قابلیت اطمینان در این شرکت‌ها خود محصول است.
ابرهای GPU و دیتاسنترهای AI
Crusoe، Fluidstack، Runpod، Nebius، Firmus و Highrise (Hut 8) خوشهٔ GPU اجاره می‌دهند و برای سلامت ناوگان، شبکه و سرویس‌های مدیریت‌شده SRE و Production Engineer استخدام می‌کنند.
سازندگان تراشهٔ AI
FuriosaAI سرویس LLM روی تراشه‌های RNGD خودش را با Production Engineer اداره می‌کند و d-Matrix تیم SRE برای خوشه‌های GPU، محیط آزمایشگاه و ابر دارد.
پلتفرم‌های داده و AI سازمانی
Databricks برای محصولات بلادرنگ خود، از جمله Model Serving، Production Engineer با on-call بین منطقه‌های زمانی استخدام می‌کند.
خودروی خودران و AI فیزیکی
Wayve برای پلتفرم‌هایی که GPU، Kubernetes و ذخیره‌سازی را در اختیار تیم‌های توسعهٔ AI می‌گذارند Staff SRE می‌خواهد، چون ناوگان GPU و دادهٔ این شرکت سریع بزرگ می‌شود.
محصولات AI بلادرنگ
ElevenLabs می‌نویسد بیشتر استفاده از پلتفرمش بلادرنگ و حساس به تأخیر است و SRE باید برای هر محصول SLA و SLO تعریف کند.
سازندگان ابزار AI SRE
Resolve AI، Traversal، incident.io، Rootly و Microsoft (Azure SRE Agent) ایجنت‌هایی می‌فروشند که حادثه را بررسی و علت را پیدا می‌کنند. آگهی‌های این شرکت‌ها بیشتر برای مهندس نرم‌افزار و AI است تا SRE.
تصورات غلط رایج
قبل از تصمیم‌گیری، این باورهای اشتباه را بشناسید
AI SRE یک عنوان شغلی رایج است
در ۳۰۶ تابلوی استخدامی که در اکتبر ۲۰۲۶ بررسی کردیم، هیچ آگهی‌ای این عنوان را نداشت. همین کار با نام‌هایی مثل Site Reliability Engineer, Inference Infrastructure، Production Engineer, LLM Serving یا AI Reliability Engineering آگهی می‌شود. «AI SRE» در بازار بیشتر نام محصول است: Resolve AI خودش را «AI SRE platform» می‌نامد و Traversal «AI SRE برای سیستم‌های پیچیده». برای جستجوی شغل، عنوان‌های SRE و Production Engineer را در شرکت‌های AI جستجو کنید.
برای این کار باید متخصص یادگیری ماشین باشید
آگهی‌ها خلاف این را می‌گویند. Baseten می‌نویسد تجربهٔ قبلی ML لازم نیست، Anthropic برای Safeguards آشنایی با پژوهش ML و معماری transformer را لازم نمی‌داند و می‌گوید آن را سر کار یاد می‌گیرید، و Wayve تجربهٔ مشابه در پلتفرم‌های بزرگ را هم مرتبط می‌داند. آنچه همه می‌خواهند Linux، برنامه‌نویسی، Kubernetes و تجربهٔ پروداکشن است. دانش GPU و سرو مدل امتیاز است و با زمان اضافه می‌شود.
ایجنت‌های AI SRE به‌زودی جای SRE را می‌گیرند
به گزارش IT Brief، Gartner در راهنمای بازار این ابزارها توصیه می‌کند تیم‌های SRE موجود با این ابزارها تقویت شوند، نه اینکه ساختار سازمان از نو چیده شود. ابزارهایی مثل Azure SRE Agent در حالت Review برای اقدام‌ها تأیید انسان می‌خواهند. در The SRE Report 2026، ۴۹٪ گفتند AI کار تکراری‌شان را کم کرده، ۳۵٪ تغییری ندیدند و ۱۶٪ گفتند بیشتر شده است. کار در حال تغییر است و آگهی‌ها حالا از SRE می‌خواهند خودش این ابزارها را بسازد یا به کار بگیرد.
SRE یعنی فقط بالا نگه داشتن سرویس
در The SRE Report 2026 نزدیک به دو سوم پاسخ‌دهندگان گفتند کند شدن سرویس به اندازهٔ قطعی جدی است. در سرویس LLM این مهم‌تر است، چون کاربر زمان رسیدن اولین توکن و سرعت تولید پاسخ را حس می‌کند. Fireworks هم می‌نویسد مشتری ممکن است تجربهٔ بدی داشته باشد در حالی که همهٔ سیستم‌ها داخل SLO خودشان‌اند، و SRE باید برای این خرابی‌ها هم مسئول پیدا کند.
هدف قابلیت اطمینان باید ۱۰۰٪ باشد
کتاب SRE گوگل می‌گوید ۱۰۰٪ تقریباً برای هر سیستمی هدف اشتباهی است، چون کاربر فرق ۱۰۰٪ و ۹۹٫۹۹۹٪ را حس نمی‌کند. error budget از همین‌جا می‌آید: فاصلهٔ هدف تا ۱۰۰٪ بودجه‌ای است که تیم می‌تواند برای انتشار سریع‌تر و آزمایش خرج کند.
یک روز کاری واقعی
در هر سطح روز کاری چه شکلی است؟
جونیور (۰–۲ سال)
کار شما معمولاً در تیم SRE یا DevOps و زیر نظر مهندس ارشد است. طبق آگهی early talent شرکت Nebius، کار این سطح کمک به عملیات روزانه، انجام کارهای مشخص از backlog، نوشتن تست و مستندات، و یادگیری Linux، Kubernetes، Helm و Terraform است.
- ◆مرور هشدارهای روز قبل و ثبت آن‌هایی که بی‌دلیل فعال شده‌اند
- ◆انجام یک کار مشخص از backlog تیم، مثل افزودن یک metric یا هشدار
- ◆نوشتن یا به‌روز کردن runbook برای خرابی‌ای که هفتهٔ قبل تکرار شد
- ◆همراهی با نفر on-call در رسیدگی به یک حادثه و یادداشت‌برداری
- ◆مستند کردن کار انجام‌شده و به‌روز کردن وضعیت تیکت‌ها
میانی (۲–۵ سال)
مسئول قابلیت اطمینان یک سرویس یا بخشی از پلتفرم هستید و در on-call نفر اول. آگهی‌های FuriosaAI و Thinking Machines تصویر این سطح را می‌دهند: پایش مسیر درخواست، پیدا کردن گلوگاه، رسیدگی به حادثه و کار نزدیک با تیم‌های inference یا پژوهش.
- ◆مرور داشبورد SLO و بررسی هر جا که error budget سریع‌تر از انتظار خرج شده
- ◆پیدا کردن علت افزایش تأخیر در یکی از مسیرهای routing، صف یا batching
- ◆اجرای load test برای تغییر تازه و انتشار آن با canary
- ◆پشتیبانی از تیم پژوهش وقتی یک کار آموزش وسط اجرا متوقف می‌شود
- ◆نوشتن postmortem و تبدیل اقدام اصلاحی به اتوماسیون
ارشد و Staff (۵+ سال)
اثر شما از طریق تیم‌های دیگر است. Fireworks از این سطح می‌خواهد تعریف «قابل اتکا» را برای کل شرکت تعیین کند، از SLO و error budget تا انتظار از on-call، و استاندارد را با اعتبار و ابزار مفید جا بیندازد، نه با دستور.
- ◆بازبینی آمادگی پروداکشن یک سرویس تازه پیش از انتشار
- ◆هدایت حادثه‌ای که چند تیم را درگیر کرده و هماهنگی ارتباطات
- ◆بررسی خرابی‌های «بین سیستم‌ها»، مثل retry که بار را چند برابر می‌کند
- ◆برنامه‌ریزی ظرفیت با تیم زیرساخت برای ریسک چندمنطقه‌ای
- ◆مرور سند طراحی همکاران و مربی‌گری مهندسان تازه
مسئولیت‌ها و وظایف
مسئولیت‌های اصلی
وظایف روزانه و مهارت‌های مورد نیاز در این شغل
- ◈تعریف SLI، SLO و error budget برای سرویس‌های مدل و تعیین معیار آمادگی پروداکشن
- ◈ساختن پایش، هشدار و داشبورد در کل مسیر درخواست: از API تا سرور مدل و GPU
- ◈حضور در on-call، رهبری رسیدگی به حادثه و پیدا کردن علت ریشه‌ای
- ◈خودکارسازی کارهای تکراری عملیات و تبدیل runbook به ابزار یا بازیابی خودکار
- ◈پایش سلامت GPU و نودها، و همکاری در checkpoint و تحمل خطای کارهای آموزش
- ◈برنامه‌ریزی ظرفیت، load test و بررسی هزینهٔ محاسبات
- ◈نوشتن postmortem بدون مقصرتراشی و پیگیری اقدام‌های اصلاحی تا پایان
- ◈کار با تیم‌های inference، آموزش، زیرساخت و محصول و جا انداختن استانداردها بدون اختیار رسمی
مهارت‌های مورد نیاز
مهارت‌های فنی، نرم و حوزه‌ای که یک مهندس قابلیت اطمینان هوش مصنوعی موفق به آن‌ها نیاز دارد
پایهٔ مهندسی و زیرساخت
درونیات Linux و عیب‌یابی کارایی؛ Fireworks پنج سال و Thinking Machines «پایهٔ محکم» در آن را می‌خواهند
TCP/IP، HTTP و gRPC (آگهی Fireworks)؛ در کار با خوشهٔ GPU، InfiniBand و RDMA هم امتیاز است
نوشتن ابزار و کد سیستمی در حد پروداکشن، نه فقط اسکریپت (Fireworks، Crusoe)
اداره کردن و عیب‌یابی خوشه در پروداکشن؛ در تقریباً همهٔ آگهی‌ها
Terraform، Helm یا Ansible؛ d-Matrix می‌خواهد همهٔ تغییرها با کد انجام شود، نه دستی
Argo CD یا Flux (Wayve، Baseten)
سیستم‌های چندمنطقه‌ای و چندابری؛ Cohere تجربه با GCP، Azure، AWS و OCI را می‌خواهد
روش SRE
شرط مشترک آگهی‌های Fireworks، Runpod، Crusoe، FuriosaAI و ElevenLabs
metric، log و trace با Prometheus، Grafana و OpenTelemetry؛ طبق ITJobsWatch در ۵۲٫۹٪ آگهی‌های بریتانیا با عنوان SRE آمده است
Runpod بهتر کردن نسبت سیگنال به نویز و کم کردن خستگی از هشدار را جزو کار می‌داند
رهبری حادثه، پیدا کردن علت ریشه‌ای و پیگیری اقدام‌ها تا پایان
production readiness review، canary و rollback (Runpod، FuriosaAI، Anthropic)
benchmark با طول ورودی و خروجی و همزمانی واقعی (FuriosaAI)
تزریق خطا و آزمون تاب‌آوری؛ Anthropic و Fireworks آن را نام برده‌اند
مهارت‌های ویژهٔ AI و مهارت‌های نرم
prefill و decode، batching، KV-cache و زمان‌بندی درخواست، و اثرشان بر تأخیر (FuriosaAI)
اثر GPU و TPU بر تأخیر و throughput (Cohere) و پایش سلامت و کارایی GPU (Runpod، Fluidstack)
checkpoint، تحمل خطا، Slurm یا Ray و NCCL (Thinking Machines)
ساختن ایجنت یا ابزار LLM برای بررسی و دسته‌بندی حادثه (Fireworks، Baseten، d-Matrix)
جا انداختن استاندارد با اعتبار و ابزار مفید، نه دستور (Fireworks)
postmortem، runbook و سند طراحی؛ Runpod مهارت عالی نوشتن را شرط گذاشته است
نقشه راه و مسیر آموزشی
نقشه راه تبدیل شدن به مهندس قابلیت اطمینان هوش مصنوعی
این مسیر گام به گام شما را از صفر تا حرفه‌ای هدایت می‌کند.
پایه: Linux، شبکه و برنامه‌نویسی
SRE پیش از هر چیز مهندس نرم‌افزار است. آگهی Fireworks پنج سال تجربه با درونیات Linux، عیب‌یابی کارایی سیستم و مبانی شبکه (TCP/IP، HTTP، gRPC) و پنج سال برنامه‌نویسی با Python، Go، C++ یا Rust می‌خواهد. Crusoe صریحاً تجربهٔ ساختن سیستم پروداکشن «فراتر از اسکریپت و Bash» را شرط گذاشته است. این مرحله را با کار روی چند ماشین Linux، خواندن متریک‌های کارایی و نوشتن ابزارهای کوچک با Python یا Go جلو ببرید.
اصول SRE: SLO، error budget، on-call و postmortem
زبان مشترک همهٔ آگهی‌های این حوزه همین مفاهیم است. Runpod تعریف SLI و SLO، رهبری رسیدگی به حادثه، postmortem بدون مقصرتراشی و بازبینی آمادگی پروداکشن را می‌خواهد و ElevenLabs تعریف SLA و SLO با هر تیم محصول. کتاب‌های SRE گوگل رایگان‌اند. فصل‌های Implementing SLOs و Alerting on SLOs در Workbook نشان می‌دهند SLO چطور به هشدار تبدیل می‌شود.
Kubernetes، زیرساخت به‌صورت کد و observability
سرویس‌های AI در این آگهی‌ها تقریباً همه روی Kubernetes اجرا می‌شوند. Baseten تجربهٔ عملی گسترده با Kubernetes، ابزارهای پایش (VictoriaMetrics، Prometheus، Loki، ELK، Grafana)، Terraform و Helm و GitOps با Flux یا Argo CD را می‌خواهد. Cohere حتی Kubernetes operator اختصاصی برای استقرار مدل‌های زبانی دارد. هدف این مرحله این است که بتوانید یک سرویس را از صفر با کد بالا بیاورید و با metric، log و trace ببینید چه می‌گذرد.
سیستم‌های AI: سرو LLM، GPU و آموزش توزیع‌شده
تفاوت اصلی با SRE عمومی همین‌جاست. FuriosaAI از Production Engineer سرویس LLM درک prefill و decode، batching، مدیریت KV-cache و زمان‌بندی درخواست را می‌خواهد و پایش معیارهایی مثل زمان رسیدن اولین توکن (TTFT)، تأخیر بین توکن‌ها و throughput را. Cohere آشنایی با اثر GPU و TPU روی تأخیر و throughput را می‌خواهد. در سمت آموزش، Thinking Machines تجربه با PyTorch، Ray، Slurm و شبکه‌های InfiniBand و NCCL را امتیاز می‌داند. مقالهٔ Llama 3 و کتاب رایگان Stas Bekman نشان می‌دهند خوشه‌های بزرگ آموزش در عمل چطور خراب می‌شوند.
حادثه‌های بزرگ، تست تاب‌آوری و ابزارهای AI SRE
در سطح ارشد، کار از رفع خرابی به پیشگیری می‌رسد. Fireworks از مهندس می‌خواهد خرابی‌هایی را پیدا کند که «بین سیستم‌ها» زندگی می‌کنند، مثل retry که بار را چند برابر می‌کند، و تست تزریق خطا و load test را بخشی از ابزارهای تیم می‌داند. همین آگهی ساختن ایجنت یا ابزار مبتنی بر LLM برای بررسی و دسته‌بندی حادثه را امتیاز می‌داند. برای دیدن نگاه یک متخصص با سابقه به ML و SRE، سخنرانی Todd Underwood را ببینید و برای آمار وضعیت حرفه، The SRE Report 2026 را بخوانید.
ابزارها و استک فنی
ابزارهایی که هر مهندس AI باید بشناسد، دسته‌بندی‌شده بر اساس اولویت
ارکستراسیون و زیرساخت به‌صورت کد
بستر اجرای سرویس‌های مدل در بیشتر آگهی‌ها؛ Cohere برای استقرار مدل‌های زبانی Kubernetes operator اختصاصی دارد و Baseten زیرساخت Kubernetes چندابری را به SRE می‌سپارد
Observability
جمع‌آوری metric و نوشتن قاعدهٔ هشدار؛ در آگهی‌های Fireworks، Runpod، FuriosaAI و d-Matrix آمده است
سرو مدل و GPU
موتور متن‌باز سرو LLM با metricهای آماده برای Prometheus؛ FuriosaAI تجربه با vLLM، SGLang، llm-d یا TensorRT-LLM را امتیاز می‌داند
خروجی گرفتن metricهای سلامت و مصرف GPU برای Prometheus؛ Runpod آشنایی با ابزارهای پایش GPU را می‌خواهد
مدیریت حادثه، تست تاب‌آوری و AI SRE
پلتفرم مدیریت حادثه که Baseten آشنایی با آن را امتیاز می‌داند؛ محصول AI SRE خودش با نام Investigations علت ریشه‌ای را از روی telemetry و تغییرات کد پیدا می‌کند
تزریق خطای برنامه‌ریزی‌شده روی Kubernetes؛ برای تمرین همان failure injection که Fireworks جزو ابزار تیم می‌داند
مسیر پیشرفت شغلی
از جونیور تا Staff Engineer — چه مهارت‌هایی نیاز دارید و چه درآمدی انتظار داشته باشید
ورود: SRE تازه‌کار، DevOps یا بک‌اند
۰ تا ۲ سال
بیشتر آگهی‌های این حوزه سابقهٔ چندساله می‌خواهند. یک راه ورود برنامه‌های early talent است: Nebius برای SRE - Early Talent در آمستردام دانشجو، تازه‌فارغ‌التحصیل یا متخصص اول راه را می‌پذیرد، برای ۳ تا ۶ ماه از ژانویهٔ ۲۰۲۷. کار در این سطح کمک به عملیات روزانه، انجام کارهای مشخص از backlog و یادگیری Linux، Kubernetes، Helm و Terraform است. راه رایج دیگر شروع با SRE یا DevOps در هر شرکتی و رفتن به سمت تیم‌هایی است که سرویس AI دارند.
SRE / Production Engineer در شرکت AI
۲ تا ۵ سال
مسئولیت قابلیت اطمینان یک سرویس یا یک بخش از پلتفرم: تعریف SLO، ساختن پایش و هشدار، on-call و نوشتن runbook. FuriosaAI برای Production Engineer سرویس LLM سه سال سابقه می‌خواهد و Thinking Machines برای SRE تیم post-training چهار سال؛ بازهٔ اعلام‌شده در آگهی Thinking Machines ۳۰۰ تا ۳۵۰ هزار دلار است.
Senior SRE / AI Infrastructure Reliability
۵+ سال
تعیین استاندارد قابلیت اطمینان برای چند تیم، رهبری حادثه‌ها و پیدا کردن خرابی‌های بین سیستم‌ها. بیشتر آگهی‌ها در این سطح‌اند: Cohere، Fireworks، Runpod و Databricks هر کدام پنج سال یا بیشتر می‌خواهند. بازه‌های اعلام‌شده در آمریکا: Runpod ۱۵۰ تا ۲۰۰ هزار، Databricks ۱۶۴٫۲ تا ۲۲۵٫۷ هزار و Fireworks ۲۰۰ تا ۲۹۰ هزار دلار حقوق پایه.
Staff / Principal / مدیر SRE
۷+ سال
قابلیت اطمینان در سطح کل سازمان یا ناوگان GPU. d-Matrix برای Sr Staff SRE هفت سال سابقه می‌خواهد و Anthropic برای Staff+ SRE تیم Safeguards هشت سال را از ویژگی‌های نامزد قوی می‌داند. بازهٔ اعلام‌شده برای Staff در تیم AI Reliability شرکت Anthropic در آمریکا ۳۲۵ تا ۴۸۵ هزار دلار و در لندن ۳۲۵ تا ۳۹۰ هزار پوند است. مسیر مدیریتی هم هست: SpaceXSI (xAI) مدیری می‌خواهد که تیم SRE ابررایانه‌هایش را بزرگ کند.
چالش‌ها و جنبه‌های منفی
واقعیت‌هایی که کمتر در آگهی‌های شغلی می‌بینید — قبل از ورود بدانید
خرابی سخت‌افزار در مقیاس بزرگ
شرکت بزرگدر خوشه‌های بزرگ GPU، خرابی جزو کار روزمره است. Meta در مقالهٔ Llama 3 گزارش داد در ۵۴ روز آموزش روی ۱۶ هزار GPU، ۴۶۶ توقف رخ داد که ۴۱۹ تای آن پیش‌بینی‌نشده بود. حدود ۷۸٪ توقف‌های پیش‌بینی‌نشده به سخت‌افزار برمی‌گشت و مشکلات GPU به‌تنهایی ۵۸٫۷٪ آن‌ها بود. با این حال فقط سه بار دخالت دستی جدی لازم شد. مقاله می‌گوید چون آموزش همزمان است، خرابی یک GPU ممکن است کل کار را از نو راه بیندازد. کار SRE همین خودکارسازی است.
معیارهای تازه برای کیفیت سرویس
عمومیدر سرویس LLM فقط بالا بودن سرویس کافی نیست. FuriosaAI زمان رسیدن اولین توکن، تأخیر بین توکن‌ها، تأخیر کل و throughput را جدا پایش می‌کند و گلوگاه را در routing، صف، batching، cache و شبکه دنبال می‌کند. طول و هزینهٔ هر درخواست به ورودی و خروجی آن بستگی دارد، پس SLO و load test باید الگوی واقعی ترافیک را بازتاب دهند.
اطمینان کم در پایش سیستم‌های AI
عمومیدر The SRE Report 2026 فقط ۱۳٪ پاسخ‌دهندگان گفتند در پایش قابلیت اطمینان سیستم‌های AI/ML اطمینان زیاد یا خیلی زیاد دارند. ابزارها و روش‌های این حوزه هنوز جا نیفتاده‌اند. Thinking Machines در شرط‌های ترجیحی‌اش تجربهٔ ساختن ابزار observability «مخصوص آموزش ML، نه فقط زیرساخت عمومی» را آورده است.
اعتماد به ایجنت‌های AI SRE
عمومیابزارهای AI SRE می‌توانند علت محتمل را پیدا کنند و راه رفع پیشنهاد دهند، اما تصمیم دربارهٔ اجرای خودکار با تیم است؛ Azure SRE Agent بسته به تنظیمات یا خودش اقدام می‌کند یا منتظر تأیید می‌ماند. NeuBird و Firefly از راهنمای Gartner نقل می‌کنند سازمانی که فقط ابزار عملیاتی بخرد در رفع واکنشی حادثه بهتر می‌شود، نه در بهتر کردن قابلیت اطمینان سیستم. در The SRE Report 2026 هم ۶۰٪ مدیران گفتند AI کار تکراری را کم کرده، در برابر ۳۸٪ کارشناسان.
کار تکراری و فشار on-call
تحقیقاتیطبق The SRE Report 2026، میانهٔ سهم کار تکراری (toil) ۳۴٪ از کار است. کتاب SRE گوگل سقف ۵۰٪ برای کار عملیاتی می‌گذارد تا وقت کافی برای مهندسی بماند. در شرکت‌های AI فشار همزمان با سرعت انتشار مدل است: Thinking Machines می‌نویسد شما همان کسی هستید که وقتی یک کار آموزش ساعت ۲ بامداد متوقف می‌شود با او تماس می‌گیرند.
ورود سخت برای تازه‌کارها
عمومیبیشتر آگهی‌هایی که دیدیم سطح ارشد بودند: Cohere، Fireworks، Runpod و Databricks پنج سال یا بیشتر، d-Matrix هفت سال. کمترین سابقه سه سال بود (FuriosaAI). برنامه‌هایی مثل SRE - Early Talent در Nebius استثنا هستند. راه معمول این است که اول در SRE یا DevOps تجربهٔ پروداکشن جمع کنید و بعد به تیم‌های AI بروید.
حقوق و بازار کار جهانی
حقوق جهانی مهندس قابلیت اطمینان هوش مصنوعی
حقوق سالانه در کشورهای مختلف بر اساس داده‌های منتشرشده؛ منبع هر ردیف با آیکون کنار نام کشور باز می‌شود.
* ارقام سالانه‌اند. منبع هر رقم:
- levels.fyi, updated Oct 22, 2026, title 'Site Reliability Engineer' (all SRE, not AI-specific), total comp (377 submissions): 25th–75th pct; median
- Fireworks AI posting, MTS AI Infrastructure Reliability (San Mateo, 5+ years), posted Aug 17, 2026: base salary range; median = midpoint
- levels.fyi, updated Oct 22, 2026, title 'Site Reliability Engineer' (all SRE, not AI-specific), total comp (47 submissions): 25th–75th pct; median
- Cohere posting, SRE Inference Infrastructure (Toronto, 5+ years), posted Jan 12, 2026: Canada base salary range; median = midpoint
- levels.fyi, updated Oct 22, 2026, title 'Site Reliability Engineer' (all SRE, not AI-specific), total comp (62 submissions): 25th–75th pct; median
- levels.fyi, updated Oct 22, 2026, title 'Site Reliability Engineer' (all SRE, not AI-specific), total comp (42 submissions): 25th–75th pct; median
- levels.fyi, updated Oct 22, 2026, title 'Site Reliability Engineer' (all SRE, not AI-specific), total comp (48 submissions): 25th–75th pct; median
- levels.fyi, updated Oct 22, 2026, title 'Site Reliability Engineer' (all SRE, not AI-specific), total comp (21 submissions): 25th–75th pct; median
- levels.fyi, updated Oct 22, 2026, title 'Site Reliability Engineer' (all SRE, not AI-specific), total comp (28 submissions): 25th–75th pct; median
- levels.fyi, updated Oct 22, 2026, title 'Site Reliability Engineer' (all SRE, not AI-specific), total comp (27 submissions): 25th–75th pct; median
- levels.fyi, updated Oct 22, 2026, title 'Site Reliability Engineer' (all SRE, not AI-specific), total comp (142 submissions): 25th–75th pct; median
چگونه از صفر شروع کنیم
برنامه گام‌به‌گام برای ورود به مهندسی هوش مصنوعی
ماه ۱: مرور اصول SRE با نگاه AI
فصل‌های SLO و هشدار در Workbook گوگل را دوباره بخوانید و سخنرانی Todd Underwood دربارهٔ ML و SRE را ببینید تا بدانید سیستم‌های ML کجا با سرویس معمولی فرق دارند.
ماه ۲: سرو LLM
یک مدل کوچک را با vLLM اجرا کنید و metricهای آن را بشناسید: صف، مصرف KV-cache، زمان رسیدن اولین توکن و تأخیر بین توکن‌ها.
ماه ۳: GPU روی Kubernetes
زمان‌بندی GPU روی Kubernetes و پایش سلامت GPU با DCGM Exporter را تمرین کنید.
ماه ۴: SLO و هشدار برای سرویس مدل
پروژه‌های اول و دوم نمونه‌کار را بسازید: داشبورد SLO و هشدار بر اساس burn rate برای سرویس vLLM.
ماه ۵: خرابی و بازیابی
با Chaos Mesh خرابی تزریق کنید و بخش قابلیت اطمینان مقالهٔ Llama 3 را بخوانید تا با خرابی‌های واقعی خوشه‌های آموزش آشنا شوید.
ماه ۶: ابزار بررسی حادثه و درخواست شغل
دستیار بررسی حادثه با LLM را بسازید، نمونه‌کارها را در GitHub با توضیح تصمیم‌هایتان منتشر کنید و برای نقش‌های SRE و Production Engineer در شرکت‌های AI درخواست بفرستید.
پروژه‌های پیشنهادی برای رزومه
سرو یک LLM کوچک روی Kubernetes با داشبورد SLO
متوسطیک مدل کوچک open-weight را با vLLM روی یک خوشهٔ محلی (kind یا minikube) یا یک GPU ابری اجرا کنید. metricهای vLLM را با Prometheus جمع کنید و در Grafana زمان رسیدن اولین توکن، تأخیر بین توکن‌ها، throughput و نرخ خطا را نشان دهید. برای هر کدام یک SLO بنویسید و توضیح دهید چرا این عدد را انتخاب کردید.
هشدار بر اساس burn rate برای یک API مدل
متوسطبا روش فصل Alerting on SLOs در Workbook گوگل، برای همان سرویس هشدار چندپنجره‌ای بر اساس سرعت مصرف error budget بسازید. با تولید بار و خطای مصنوعی نشان دهید هشدار کی فعال می‌شود و کی نه، و یک runbook کوتاه برای پاسخ به هر هشدار بنویسید.
load test و برنامه‌ریزی ظرفیت inference
پیشرفتهمثل آنچه FuriosaAI از Production Engineer می‌خواهد، benchmark بسازید که طول ورودی و خروجی، همزمانی و الگوی ترافیک واقعی را شبیه‌سازی کند. توزیع تأخیر و throughput را در تنظیمات مختلف batching بسنجید و یک گزارش ظرفیت بنویسید: با این سخت‌افزار تا چند درخواست همزمان SLO حفظ می‌شود.
بازیابی خودکار یک job آموزش از خرابی
پیشرفتهیک آموزش کوچک PyTorch با checkpoint منظم بنویسید و با Chaos Mesh پاد آن را وسط کار از بین ببرید یا تأخیر شبکه اضافه کنید. نشان دهید job چقدر کار را از دست می‌دهد و چطور خودکار از آخرین checkpoint ادامه می‌دهد؛ همان هدفی که Thinking Machines با عبارت «خرابی سخت‌افزار باید چند دقیقه هزینه داشته باشد، نه چند روز» نوشته است.
دستیار بررسی حادثه با LLM
متوسطیک ابزار کوچک بسازید که هنگام هشدار، metricها، logها و تغییرات اخیر را جمع کند، با یک LLM خلاصه و علت محتمل را بنویسد و runbook مناسب را پیشنهاد دهد. هر اقدامی که سیستم را تغییر می‌دهد فقط با تأیید انسان اجرا شود. این همان مهارتی است که Fireworks با عنوان AI-assisted operations و Baseten با «ابزار کمک‌گرفته از AI برای triage حادثه» می‌خواهند.
مثال‌های واقعی و Case Studies
داستان‌های واقعی از مهندسانی که در این حوزه تأثیرگذار بوده‌اند
در کتاب SRE گوگل، نویسندهٔ فصل مقدمه و «معاون مهندسی گوگل و بنیان‌گذار SRE گوگل» معرفی شده است. به گفتهٔ خودش در همین فصل، تا پیش از آمدن به گوگل در ۲۰۰۳ همهٔ کارش مهندسی نرم‌افزار بود.
می‌نویسد وقتی در ۲۰۰۳ به گوگل آمد، مسئول یک «تیم پروداکشن» هفت‌نفره شد و آن را طوری طراحی کرد که اگر خودش SRE بود دوست داشت کار کند؛ همان گروه به تیم SRE امروز گوگل تبدیل شد. تعریف معروف SRE از اوست: «SRE همان چیزی است که وقتی از یک مهندس نرم‌افزار بخواهید تیم عملیات طراحی کند، به دست می‌آید.» این فصل سقف ۵۰٪ برای کار عملیاتی SREها و ایدهٔ error budget را توضیح می‌دهد، با این استدلال که ۱۰۰٪ تقریباً برای هیچ سیستمی هدف درستی نیست.
ابزارهای AI تازه‌اند، اما چارچوب فکری SRE همان است. کسی که SLO و error budget را خوب بفهمد، می‌تواند آن را به سرویس مدل زبانی هم ببرد؛ فقط معیارها عوض می‌شوند.
طبق بیوگرافی USENIX در SREcon25، مسئول قابلیت اطمینان در Anthropic است. پیش از آن قابلیت اطمینان پلتفرم پژوهشی OpenAI را رهبری می‌کرد و قبل‌تر در گوگل Senior Engineering Director و مسئول مهندسی ظرفیت ML در Alphabet بود.
طبق همان بیوگرافی، تیم‌های ML Site Reliability Engineering گوگل را بنیان گذاشت و رهبری کرد؛ تیم‌هایی که سرویس‌های AI/ML داخلی و بیرونی را می‌سازند و مقیاس می‌دهند. با چند همکار کتاب Reliable Machine Learning: Applying SRE Principles to ML in Production را منتشر کرد (O’Reilly، ۲۰۲۲). در سخنرانی SREcon22 با عنوان «SRE and ML: Why It Matters» گفت SREها احتمالاً باید دربارهٔ ML بدانند و وضعیت استفاده از ML برای خودکارسازی پروداکشن را با نگاهی «بسیار بدبینانه» بررسی کرد.
مسیر او نشان می‌دهد این تخصص از درون SRE رشد کرده، نه از پژوهش ML. نکتهٔ دیگر نگاه شکاک او به خودکارسازی با ML است؛ همان پرسشی که امروز دربارهٔ ایجنت‌های AI SRE مطرح است.
به گفتهٔ سایت خودش، کارشناسی و کارشناسی ارشد علوم کامپیوتر را از QUT و RMIT در استرالیا گرفته و در National Australia Bank، DigitalOcean، Dropbox و Gremlin کار کرده است. اکنون VP Product در استارتاپ Statype است.
طبق سایتش، در Dropbox تیم‌های SRE مسئول پایگاه‌داده و سیستم‌های ذخیره‌سازی مورد استفادهٔ بیش از ۵۰۰ میلیون کاربر را رهبری کرد و مدیر حادثهٔ on-call (IMOC) برای حادثه‌های شدید در سطح شرکت بود. بعد Principal SRE در Gremlin شد و روی chaos engineering کار کرد، یعنی آزمایش‌های کنترل‌شده برای پیدا کردن نقطه‌های قابل بهبود. در فهرست کارهایش اثری با عنوان «0 To 100 Days - Running DRTs at Dropbox» آمده و هم‌نویسندهٔ کتاب الکترونیکی «Reducing MTTD» با مهندسانی از LinkedIn، Amazon و Twitter است.
تاب‌آوری را باید تمرین کرد. در The SRE Report 2026 فقط ۱۷٪ سازمان‌ها گفتند به‌طور منظم آزمایش chaos یا تاب‌آوری را در پروداکشن اجرا می‌کنند. کسی که این مهارت را دارد، در سیستم‌های AI هم که خرابی سخت‌افزار در آن‌ها رایج است، مزیت دارد.
نمونه آگهی استخدام واقعی + تحلیل
یک آگهی واقعی از شرکت فعال در حال استخدام، با تحلیل هر بخش
Member of Technical Staff, AI Infrastructure Reliability
تحلیل نیازمندی‌ها
Systems fundamentals: 5+ years with Linux internals, system performance troubleshooting, and networking fundamentals (TCP/IP, HTTP, gRPC).
پنج سال کار با درونیات Linux و عیب‌یابی کارایی یعنی این آگهی سطح ارشد است. وقتی سرویس کند می‌شود باید بتوانید از CPU و حافظه تا شبکه را بررسی کنید، نه فقط داشبورد را نگاه کنید.
ضروریSoftware engineering: 5+ years in Python, Go, C++, or Rust, writing production-grade tools and systems code.
SRE در این شرکت نرم‌افزار می‌نویسد، نه فقط اسکریپت. ابزار پایش، اتوماسیون بازیابی و ابزار بررسی حادثه همه کد پروداکشن‌اند و باید مثل هر کد دیگری قابل نگهداری باشند.
ضروریCloud-native operations: Operating and debugging Kubernetes, Terraform, and Docker in high-throughput production.
سه ابزار پایه‌ای که در بیشتر آگهی‌های این حوزه تکرار می‌شوند. «high-throughput» یعنی تجربه روی سیستمی که بار واقعی و زیاد دارد، نه فقط پروژهٔ آزمایشی.
ضروریDistributed systems: High-throughput control planes, microservices, or multi-region setups.
بیشتر خرابی‌های سخت در سیستم‌های توزیع‌شده رخ می‌دهند. تجربه با چند منطقهٔ ابری یا control plane پرترافیک نشان می‌دهد با خرابی جزئی، تأخیر شبکه و وابستگی بین سرویس‌ها سروکار داشته‌اید.
ضروریReliability fundamentals: Fault-tolerant design, SLO/SLA management, automated failover, high-availability architecture.
هستهٔ دانش SRE: طراحی سیستمی که با خرابی یک بخش از کار نیفتد، تعریف و مدیریت SLO و SLA، و failover خودکار. این همان چیزی است که کتاب‌های SRE گوگل آموزش می‌دهند.
ضروریInfluence without authority: You can get other teams to adopt a standard through credibility and useful tooling rather than mandate.
در این نقش استاندارد را خودتان تعیین می‌کنید، اما اجرایش دست تیم‌های دیگر است. راه پیشبرد، ساختن ابزاری است که استفاده از استاندارد را آسان کند و اعتباری که از حل مسائل واقعی به دست می‌آید.
مهمObservability tooling: Prometheus, Grafana, OpenTelemetry, and alerting people actually act on.
این مورد در بخش «Preferred» آمده است. عبارت آخرش مهم است: هشداری که کسی به آن واکنش نشان ندهد فقط نویز است. هشدار خوب کم، دقیق و قابل اقدام است.
مفیدGPU and ML infrastructure exposure: GPUs, inference serving, or distributed training.
در شرکتی که کارش سرو و آموزش مدل است، تجربه با GPU و ML هم فقط «ترجیحی» است، نه الزامی. یعنی پایهٔ قوی SRE اولویت دارد و دانش AI را می‌شود سر کار یاد گرفت.
مفیدAI-assisted operations: Building agents or LLM-based tooling for investigation, triage, or automation.
این همان معنای دوم «AI SRE» است: ساختن ایجنت یا ابزار مبتنی بر LLM که بررسی و دسته‌بندی حادثه را خودکار کند. هنوز ترجیحی است، اما نشان می‌دهد این مهارت به آگهی‌ها راه پیدا کرده است.
مفیدتحلیل مسئولیت‌ها
Define reliability standards: SLOs, error budgets, production readiness criteria. Not written in a vacuum: you instrument the systems and read the real telemetry the numbers come from.
SLO را پشت میز نمی‌نویسید. اول سیستم را ابزارگذاری می‌کنید و از داده‌های واقعی می‌فهمید چه عددی معقول است. معیار آمادگی پروداکشن هم یعنی تعیین اینکه یک سرویس پیش از انتشار چه چیزهایی باید داشته باشد.
Own the reliability toolchain: Logging and telemetry pipelines, alerting standards, failure injection, load testing, self-healing automation, and AI-assisted investigation tooling.
فهرست کامل ابزارهای یک تیم قابلیت اطمینان در یک خط: از جمع‌آوری log و telemetry تا تزریق خطا، load test، بازیابی خودکار و ابزار بررسی با کمک AI. مالکیت یعنی این ابزارها را می‌سازید و نگه می‌دارید.
Keep customer experience from falling through the cracks: Per-service reliability is necessary but not sufficient. A customer can hit a bad experience while every system sits inside its SLO. You make sure those failures get an owner and a fix.
نکتهٔ مهمی دربارهٔ SLO: هر سرویس ممکن است عدد خودش را رعایت کند و باز هم مشتری تجربهٔ بدی داشته باشد. SRE باید از دید مشتری به کل مسیر نگاه کند و برای این خرابی‌ها مسئول پیدا کند.
Own the seams: The hardest failures live between systems: retries that amplify load, timeouts that do not compose, dependencies nobody mapped. You find them before customers do and drive fixes through the teams that own them.
سخت‌ترین خرابی‌ها در مرز بین سیستم‌ها هستند: retry که بار را چند برابر می‌کند، timeoutهایی که با هم جور نیستند، وابستگی‌هایی که کسی ثبت نکرده. این کار نیاز به دید کلی دارد و رفع آن از طریق تیم‌های مالک انجام می‌شود.
Run incident management: Coordinate live production issues, run blameless postmortems, and track follow-ups to completion.
هماهنگی حادثه در لحظه، postmortem بدون مقصرتراشی و پیگیری اقدام‌ها تا پایان. بخش سوم معمولاً فراموش می‌شود و ارزش واقعی postmortem در همان است.
Reduce toil: Automate repetitive operational work so growth does not turn into an unsustainable on-call load.
اگر کار عملیاتی با رشد ترافیک زیاد شود، on-call تحمل‌ناپذیر می‌شود. خودکارسازی کارهای تکراری همان اصلی است که کتاب SRE گوگل با سقف ۵۰٪ برای کار عملیاتی بیان می‌کند.
Partner across the org: Cloud infrastructure on capacity and multi-region risk, inference and training on failure modes in the serving and training stacks, performance on zero-downtime rollouts, product and control plane on customer-facing reliability.
شرکای کاری شما همهٔ تیم‌ها هستند: زیرساخت ابری برای ظرفیت، تیم‌های inference و آموزش برای خرابی‌های خاص مدل، تیم کارایی برای انتشار بدون قطعی، و تیم محصول برای تجربهٔ مشتری. بخش AI این نقش همین‌جاست.
نتیجه‌گیری کلی
این آگهی هر دو معنای «AI SRE» را نشان می‌دهد. شرط‌های اصلی همه SRE کلاسیک‌اند: Linux، برنامه‌نویسی، Kubernetes و Terraform، سیستم‌های توزیع‌شده و SLO. تجربه با GPU و ML فقط ترجیحی است و ساختن ایجنت برای بررسی حادثه هم کنار آن آمده است. به گفتهٔ آگهی، Fireworks روزانه بیش از ۴۰ تریلیون توکن سرو می‌کند. بازهٔ حقوق پایه ۲۰۰ تا ۲۹۰ هزار دلار است، در کنار سهام. برای مقایسه، Runpod برای SRE با پنج سال سابقه ۱۵۰ تا ۲۰۰ هزار دلار و Anthropic برای Staff در تیم AI Reliability ۳۲۵ تا ۴۸۵ هزار دلار اعلام کرده‌اند. ارقام levels.fyi در جدول حقوق برای SRE به‌طور کلی است و مخصوص AI نیست. ITJobsWatch هم میانهٔ حقوق آگهی‌های عنوان SRE در بریتانیا را ۸۰ هزار پوند گزارش می‌کند، کمتر از رقم levels.fyi که بیشتر از شرکت‌های بزرگ فناوری می‌آید.
آینده و روندها
پیش‌بینی ۵–۱۰ ساله و مهارت‌هایی که باید یاد بگیرید
طبق ITJobsWatch، در ۶ ماه تا ۲۲ اکتبر ۲۰۲۶، ۶۲۵ آگهی دائم در بریتانیا مهارت Site Reliability Engineering را نام برده‌اند، در برابر ۴۲۱ در همین بازهٔ ۲۰۲۵ و ۷۲۵ در ۲۰۲۴. سهم این آگهی‌ها از کل آگهی‌های دائم از ۰٫۸۶٪ به ۰٫۵۲٪ رسیده است، پس تعداد بیشتر شده ولی سهم کمتر. ۱۴٫۷٪ این آگهی‌ها به AI هم اشاره کرده‌اند. آمار جداگانه‌ای برای SRE در سیستم‌های AI وجود ندارد.
منبع: ITJobsWatch (UK, 6 months to 22 Oct 2026)
مهارت‌های نوظهور که باید یاد بگیرید
پیش‌بینی‌های آینده
در The SRE Report 2026 (Catchpoint، بخشی از LogicMonitor)، بیش از نیمی از ۴۱۸ پاسخ‌دهندهٔ نظرسنجی تابستان ۲۰۲۵ گفتند قصد دارند ظرف ۱۲ ماه سیستم‌های agentic AI را در پروداکشن مستقر کنند.
به نقل Cast AI و IT Brief از راهنمای بازار ابزارهای AI SRE که Gartner در ژانویهٔ ۲۰۲۶ منتشر کرد، Gartner پیش‌بینی می‌کند تا ۲۰۲۹، ۸۵٪ سازمان‌ها از ابزارهای AI SRE استفاده کنند، در برابر کمتر از ۵٪ در ۲۰۲۵.
به نقل Firefly از همان گزارش، Gartner پیش‌بینی می‌کند تا ۲۰۲۹، ۷۵٪ سازمان‌ها درس‌هایی را که AI از داده‌های SRE بیرون می‌کشد وارد طراحی و تحویل محصول کنند، در برابر ۱۰٪ در ۲۰۲۵.
ابزارهای AI SRE همان بخشی از کار را هدف گرفته‌اند که امروز نقطهٔ ورود این حرفه است: triage هشدار، جمع کردن شواهد و پیدا کردن علت محتمل. Gartner پیش‌بینی می‌کند استفاده از این ابزارها در سازمان‌ها سریع زیاد شود، پس ارزش مهندس به سمت طراحی، تعیین استاندارد و قضاوت دربارهٔ اجرای خودکار می‌رود. به نقل NeuBird و Firefly، خود Gartner هشدار می‌دهد ابزاری که فقط روی عملیات تمرکز کند، سازمان را در رفع واکنشی حادثه بهتر می‌کند، نه در قابلیت اطمینان. ریسک دیگر تمرکز بازار است: آگهی‌هایی که دیدیم بیشتر در آزمایشگاه‌های مدل، پلتفرم‌های inference، ابرهای GPU و شرکت‌های تراشه بودند و بیشترشان پنج سال سابقه یا بیشتر می‌خواستند. سهم آگهی‌های SRE از کل آگهی‌های بریتانیا هم طبق ITJobsWatch در دو سال اخیر کم شده است.
منابع
اطلاعات این صفحه در تاریخ ۳۰ مهر ۱۴۰۵ از این ۴۸ منبع بررسی شده است.
- Member of Technical Staff, AI Infrastructure Reliability — Fireworks AI (job posting)
- Site Reliability Engineer, Inference Infrastructure — Cohere (job posting)
- Site Reliability Engineer, Post Training — Thinking Machines Lab (job posting)
- Staff Software Engineer, AI Reliability — Anthropic (job posting, US)
- Staff Software Engineer, AI Reliability Engineering — Anthropic (job posting, London)
- Staff+ Site Reliability Engineer, Safeguards ML Infra — Anthropic (job posting)
- Staff SRE, AI Infrastructure — Wayve (job posting)
- Senior Production Engineer, Managed AI — Crusoe (job posting)
- Site Reliability Engineer — Baseten (job posting)
- Site Reliability Engineer — Runpod (job posting)
- Production Engineer, LLM Serving — FuriosaAI (job posting)
- Senior Production Engineer - Realtime Products — Databricks (job posting)
- Site Reliability Engineer, Compute — Fluidstack (job posting)
- Sr Staff Site Reliability Engineer, AI Infrastructure — d-Matrix (job posting)
- Site Reliability Engineer, AI Infrastructure — Firmus Technologies (job posting)
- Site Reliability Engineer (SRE) - Early Talent — Nebius (job posting)
- Site Reliability Engineer — ElevenLabs (job posting)
- Manager, Supercomputer Site Reliability Engineering — SpaceXSI / xAI (job posting)
- levels.fyi — Site Reliability Engineer salary, United States
- levels.fyi — Site Reliability Engineer salary, Canada
- levels.fyi — Site Reliability Engineer salary, United Kingdom
- levels.fyi — Site Reliability Engineer salary, Germany
- levels.fyi — Site Reliability Engineer salary, Netherlands
- levels.fyi — Site Reliability Engineer salary, Switzerland
- levels.fyi — Site Reliability Engineer salary, Australia
- levels.fyi — Site Reliability Engineer salary, Singapore
- levels.fyi — Site Reliability Engineer salary, India
- ITJobsWatch — Site Reliability Engineering (UK skill trends)
- ITJobsWatch — Site Reliability Engineer (UK job title)
- Gartner — Market Guide for AI Site Reliability Engineering Tooling (abstract, 26 Jan 2026)
- Cast AI — Gartner Market Guide for AI SRE Tooling
- IT Brief UK — Gartner names Komodor key vendor in AI SRE tooling
- NeuBird — 2026 Gartner Market Guide for AI SRE Tooling
- Firefly — Named in Gartner's 2026 AI SRE Guide
- The SRE Report 2026 — Catchpoint / LogicMonitor
- The SRE Report 2026: Reliability Is Being Redefined — LogicMonitor (press release)
- The Llama 3 Herd of Models (arXiv 2407.21783)
- Google SRE Book — Chapter 1: Introduction (Benjamin Treynor Sloss)
- Site reliability engineering — Wikipedia
- Running ML in Production — Todd Underwood, SREcon25 Americas (USENIX)
- SRE and ML: Why It Matters — Todd Underwood, SREcon22 EMEA (USENIX)
- Tammy Bryant Butow — personal site
- ResolveAI — AI SRE platform
- Traversal — The AI SRE for complex systems
- incident.io — AI SRE for root cause analysis
- Rootly — AI SRE
- Overview of Azure SRE Agent — Microsoft Learn
- Production Metrics — vLLM documentation