مارتین اسپیر، رهبر تیم عملکرد چتجیپیتی در اوپنایآی، تصویری از دو تسریع همزمان ترسیم میکند: نرخِ ترسناک رشد کاربران از یک سو، و دگرگونی بنیادین در گردشکار توسعه نرمافزار با ورود کدنویسی عاملمحور از سوی دیگر. او که بیست سال سابقه در مهندسی عملکرد دارد — از روزهای نخستین نتفلیکس در ابر تا مدیریت زیرساخت در پیکپی و استارتاپ استنتاج پراسیل — معتقد است لحظه حال аналоги دقیقی با روزهای اول رایانش ابری دارد: در آن روزها پرسش این بود که «آیا دادهام در ابر امن است؟» و امروز پرسش شده است: «آیا محصول ما در میان طوفان کدهای عاملمحور زنده میماند؟»
دو تسریع همزمان: رشد کاربران و حجم کد
اسپیر سه متغیر کلیدی را شمارش میکند که قواعد بازی را به کلی تغییر دادهاند:
- سرعت رشد نمایی: شرکتها دیگر سالها برای رسیدن به اولین میلیون کاربر صرف نمیکنند. چتجیپیتی در تنها پنج روز به این رقم رسید — milieuxی که در دوران پیش از هوش مصنوعی مولد gầnبهغيرممکن بود.
- انفجار حجم کد در تولید: ابزارهای عاملمحور باعث شده منطقهای بسیار بیشتر در واحد زمان به محیط تولید برسد.
- افول نظارت انسانی بر جزئیات: لایه انتزاعی بالا رفته و توسعهدهندگان دیگر جزئیات همه تغییرات را قبل از استقرار (Deployment) درک نمیکنند.
این سهگانه، فشار را نه تنها بر عملکرد، بلکه بر کل زنجیره تأمین نرمافزار — از گیتهاب و گیتلب تا خط لولههای CI/CD — تشدید کرده است.
از پیشنمایش تحقیقاتی به پدیده جهانی
چتجیپیتی در نوامبر ۲۰۲۲ بهعنوان یک «پیشنمایش تحقیقاتی» راهاندازی شد، نه یک اپلیکیشن مصرفی مقیاسپذیر برای صدها میلیون کاربر. اما کاربران با سرعتی شگفتانگیز فرا رسیدند. وقتی پیشنمایش تحقیقاتی به محصول واقعی تبدیل میشود، نیازمندیهای تاخیر، قابلیت اطمینان و پشتیبانی غیرقابلمذاکره میشوند. اسپیر آمار رسمی فوریه ۲۰۲۶ را به اشتراک میگذارد: ۹۰۰ میلیون کاربر فعال هفتگی، معادل ۱۱ درصد جمعیت بشر. برای درک مقیاس، یادآوری میکند که تولید تصویر در تنها هفت روز اول، بیش از ۷۰۰ میلیون تصویر توسط ۱۳۰ میلیون کاربر را به وجود آورد — جهشی که زیرساخت را به آستانه فروپاشی کشاند.
چالش مقیاس: ۹۰۰ میلیون کاربر هفتگی
چت از نظر محاسباتی کارِ «سبک» نیست. هر پرسش، طیف وسیعی از پردازشهای موازی، استنتاج مدل، بازیابی داده و ارکستراسیون سرویسهای میکرو را به راه میاندازد. رشد یکنواخت نبود؛ پر از جهشهای وایرال بود که با عرضه هر قابلیت جدید — از تولید تصویر تا جستجوی وب — تشدید میشد. تیم عملکرد اوپنایآی باید سیستمی طراحی کند که نه تنها بار فعلی را تحمل کند، بلکه حاشیه امنی برای جهشهای بعدی داشته باشد. این بدان معناست که مهندسی عملکرد دیگر یک تابع «بهینهسازی کوئری دیتابیس» نیست، بلکه معماریپذیری کل پلتفرم را دیکته میکند.
وقتی عاملها کد مینویسند: لایه انتزاعی بالاتر
اسپیر به نکته ظریف اما حیاتی اشاره میکند: در گذشته فرض بر این بود که مهندس معماری تغییرات را درک کرده و تایید میکند. با کدنویسی عاملمحور، این تضمین از بین رفته. عاملها میتوانند وابستگیهای پنهان، حلقههای بیپایان یا الگوی دسترسی به حافظهی ناکارآمد معرفی کنند که هیچ بازبینی انسانی پیش از استقرار آن را bắt نمیکند. این پدیده، که برخی به آن «شلختگی هوش مصنوعی» میگویند، الزامی میسازد که مشاهدگی (Observability)، استقرار کاناری (Canary Deployments) و آزمایشهای بار خودکار به بخش جداییناپذیر چرخه توسعه تبدیل شوند، نه مراحل اختیاری.
مهندسی عملکرد در عصر جدید: سه ستون فقرات
دروس اسپیر فراتر از چتجیپیتی قابل تعمیم است: هر سازمانی که در مقیاس بزرگ عمل میکند — یا قصد دارد به سرعت مقیاس یابد — باید سه ستون را تقویت کند:
- مقیاسپذیری طراحیشده از روز اول: حتی اگر محصول پیشنمایش تحقیقاتی باشد.
- اتوماسیون کنترل کیفیت عملکرد: در خط لوله CI/CD تا مانع رگرسهای تاخیر شود.
- فرهنگ مسئولیت مشترک: بین تیمهای محصول، پلتفرم و کارایی.
او تأکید میکند: «مهندسی عملکرد لولهکشی خانه است؛ کسی نمیبیند تا زمانی که مسدود شود و همه جا آب بگیرد.» در دنیایی که عاملها کد مینویسند و کاربران به صدها میلیون برمیشوند، لولهکشی باید قبل از باز شدن شیر آب، بینقص باشد.
آیا سازمان شما برای لحظهای که عاملها کد بنویسند و کاربران به میلیاردها برسند، لولهکشیاش را چک کرده است؟
