ایک AI سے چلنے والے اسسٹنٹ نے سات دنوں تک میری آن-کال (on-call) ڈیوٹی سنبھالی، 11 الرٹس کو پروسیس کیا اور مسئلہ حل کرنے کے میرے اوسط وقت کو 45 منٹ سے کم کر کے 20 منٹ کر دیا۔ یہ تجربہ اس لیے اہم ہے کیونکہ ایک محدود دائرہ کار والا لینگویج ماڈل سخت انسانی نگرانی کے باوجود حادثاتی ردعمل (incident response) کے وقت کو آدھا گھنٹہ کم کر سکتا ہے۔
میں نے AI کو آن-کال پر کیوں رکھا
کلاؤڈ ٹیمیں اپنی شفٹ کا زیادہ تر حصہ لاگز (logs) کی جانچ پڑتال کرنے، حالیہ ڈیپلائمنٹس (deployments) کو چیک کرنے، اور اس بات کی تصدیق کرنے میں گزارتی ہیں کہ اسکیلنگ کی درخواست محفوظ ہے۔ یہ "بورنگ" کام بار بار دہرائے جانے والے، ڈیٹا سے بھرپور، اور انسانی تھکن کا شکار ہونے والے کام ہیں۔ لارج لینگویج ماڈلز (LLMs) میں حالیہ پیش رفتوں نے بالکل اسی طرح کے پیٹرن میچنگ (pattern-matching) کے کام کو خودکار بنانے کا وعدہ کیا ہے، لیکن زیادہ تر عوامی ڈیمو سینڈ باکس (sandbox) ماحول میں چلتے ہیں۔ میں یہ دیکھنا چاہتا تھا کہ کیا یہ شور (hype) ایک پروڈکشن گریڈ کلسٹر میں برقرار رہتا ہے جو اصل میں ادائیگی کرنے والے صارفین کو خدمات فراہم کرتا ہے۔
ٹیسٹ سیٹ اپ
- رسائی (Access) – ایجنٹ ہر میٹرک، لاگ، اور ڈیپلائمنٹ کی تعریف پڑھ سکتا تھا۔ یہ صرف ایک محدود وائٹ لسٹ (whitelist) تک ہی لکھ سکتا تھا: جیسے کہ پوڈ (pod) کو ری اسٹارٹ کرنا، ریپلیکا کاؤنٹ (replica count) بڑھانا، یا کسی ڈیپلائمنٹ کو اسکیل کرنا۔ ان اقدامات کے علاوہ کسی بھی چیز کے لیے میری واضح منظوری درکار تھی۔
- کردار (Role) – میں نے ماڈل کے ساتھ ایک جونیئر انجینئر کی طرح سلوک کیا جو اپنی پہلی آن-کال شفٹ پر تھا۔ اسے الرٹ موصول ہوتا، وہ اپنا تجزیہ کرتا، اور انسیڈنٹ چینل (incident channel) میں ایک سفارش پوسٹ کرتا۔
- حفاظتی جال (Safety nets) – تمام لکھنے کے عمل (write actions) کو ایک دستی "ہاں/نہیں" (yes/no) پرامپٹ کے ذریعے روکا گیا تھا۔ میں نے اخراجات کو قابلِ پیش گوئی رکھنے کے لیے ماڈل کے ٹوکن استعمال (token usage) کی حد بھی مقرر کر دی تھی۔
جہاں AI نے کمال دکھایا
ایجنٹ کی رفتار سب سے نمایاں فائدہ تھی۔ جیسے ہی کوئی الرٹ آیا، اس نے متعلقہ لاگز حاصل کیے، حالیہ میٹرکس کا گراف بنایا، اور آخری تین ڈیپلائمنٹس کی فہرست بنائی۔ جب تک میں نے اپنا لیپ ٹاپ کھولا، ابتدائی تفتیشی کام پہلے ہی مکمل ہو چکا تھا۔ 11 الرٹس میں سے:
- 8 معمول کے مسائل تھے (میموری اسپائکس، کنٹینر ری اسٹارٹس، سادہ غلط کنفیگریشنز)۔ AI نے ہر بار صحیح طریقے سے اصل وجہ (root cause) کی نشاندہی کی۔
- اس نے ایک مائیکرو سروس میں میموری کے بتدریج اضافے کو اس سے پہلے ہی نشان زد کر دیا جب مسئلہ رات 2 بجے کے آؤٹیج (outage) میں بدلنے والا تھا، جس سے ٹیم کو جلد مداخلت کرنے کا موقع ملا۔
- پورے ہفتے کا ٹوکن استعمال تقریباً $30 رہا، جو کہ حد مقرر ہونے کی صورت میں عام آن-کال بجٹ کے اندر ہی تھا۔
یہ نتائج میعن ٹائم ٹو ریزولوشن (MTTR) میں 45 منٹ سے 20 منٹ تک کی قابلِ پیمائش کمی میں تبدیل ہو گئے، جس سے انجینئرز کو زیادہ اثر انگیز کاموں پر توجہ مرکوز کرنے کا موقع ملا۔
جہاں یہ لڑکھڑایا
اعتماد کا مطلب درستگی نہیں ہے۔ AI 11 میں سے 3 الرٹس پر پراعتماد طریقے سے غلط تھا:
- اس نے ڈیٹا بیس کنیکٹیویٹی کی विफलता (failure) کے لیے حالیہ کوڈ ڈیپلائمنٹ کو ذمہ دار ٹھہرایا، لیکن وہ وضاحت غلط تھی۔
- جب کسی غیر مانوس نیٹ ورکنگ غیر معمولی صورتحال (anomaly) کا سامنا ہوا، تو اس نے عام سی اصلاحات پیش کیں جنہوں نے بنیادی مسئلے کو حل نہیں کیا۔
- لوڈ سے متعلقہ الرٹ کے دوران، اس نے ایک سروس کو 3 سے 30 ریپلیکا تک اسکیل کرنے کی تجویز دی۔ مسئلہ لوڈ نہیں تھا بلکہ ایک غلط کنفیگریشن تھی۔
چونکہ میرے گارڈ ریلز (guardrails) کے تحت کسی بھی لکھنے کے عمل کے لیے دستی منظوری درکار تھی، اس لیے ماڈل کی غلطیوں کو نقصان پہنچانے سے پہلے ہی پکڑ لیا گیا۔ پھر بھی، اس واقعے نے ایک بنیادی خطرے کو اجاگر کیا: ماڈل ایسی سفارشات پیش کر سکتا ہے جو سننے میں معقول لگیں لیکن حقیقت میں غلط ہوں، خاص طور پر نئے مسائل کے لیے۔
لاگت اور خطرے کا انتظام
$30 کا ٹوکن بل ظاہر کرتا ہے کہ اگر استعمال کی نگرانی کی جائے تو پروڈکشن لوپ میں LLM چلانا سستا ہو سکتا ہے۔ تاہم، اصل لاگت آپریشنل خطرہ ہے۔ ڈیپلائمنٹ کو غلط طریقے سے اسکیل کرنا کلاؤڈ کے اخراجات میں بے تحاشہ اضافے کا باعث بن سکتا ہے، اور ایک اچھی ریلیز کو واپس لینا (rollback) صارفین کے اعتماد کو ٹھیس پہنچا سکتا ہے۔ اس تجربے نے دو حفاظتی اقدامات کی اہمیت پر زور دیا:
- ایکشن گیٹنگ (Action gating) – ماڈل کو صرف تجویز کرنے کی اجازت دیں، انسانی کلک کے بغیر کبھی بھی زیادہ اثر انگیز تبدیلیوں کو نافذ نہ کرنے دیں۔
- بجٹ کی حد (Budget caps) – ٹوکن کے استعمال پر سخت حد مقرر کریں اور جب ماڈل حد کے قریب پہنچ جائے تو ٹیم کو الرٹ کریں۔
آگے کیا دیکھنا ہے
تب تک، ٹیموں کو چاہیے کہ:
- AI کے تیار کردہ مشوروں کے اس تناسب پر نظر رکھیں جن کے لیے دستی مداخلت (manual override) کی ضرورت پڑتی ہے۔
- مختلف حادثاتی زمروں (معمول کے بمقابلہ نئے) میں MTTR پر اثرات کی پیمائش کریں۔
- پروڈکشن میں لکھنے کے کوئی بھی حقوق دینے سے پہلے، مصنوعی الرٹس کے ساتھ اسٹیجنگ ماحول (staging environment) میں ماڈل کا تجربہ کریں۔
آپریشنز ٹیموں کے لیے اہم نکات
- بورنگ 80% کو خودکار بنائیں – لاگ ایگریگیشن (log aggregation)، میٹرک کوریلیشن (metric correlation)، اور ابتدائی مفروضے تیار کرنے کے لیے AI کا استعمال کریں۔
- خطرناک 20% انسانوں کے لیے رکھیں – ایک مناسب حد سے زیادہ اسکیلنگ، رول بیکس (rollbacks)، اور ڈیلیشنز کو دستی منظوری کے مرحلے کے تحت ہونا چاہیے۔
- ماڈل کو ایک پارٹنر کے طور پر دیکھیں، متبادل کے طور پر نہیں – سسٹم کو جاننے والا انجینئر کسی نئے آنے والے کے مقابلے میں AI کے نتائج کی تیزی سے تصدیق کر سکتا ہے، جس سے یہ اسسٹنٹ ایک فورس ملٹی پلائر (force multiplier) بن جاتا ہے۔
ایک AI ایجنٹ ابھی تک اکیلے کلاؤڈ آپریشنز نہیں چلا سکتا، لیکن ایک ٹریاج پارٹنر کے طور پر یہ پہلے ہی کام کی رفتار میں ٹھوس اضافہ فراہم کر رہا ہے۔ اصل بات یہ ہے کہ اعتماد کو قابو میں رکھا جائے، سخت گارڈ ریلز نافذ کی جائیں، اور ماڈل کو تکراری اور مشقت طلب کاموں کو سنبھالنے دیا جائے جبکہ اہم فیصلوں کی رہنمائی انسانی مہارت کے ذریعے کی جائے۔