از هشدار CloudWatch تا پولریکوئست: ترمیم خودکار حادثه با DevOps Agent و Kiro
هوش مصنوعیخلاصهٔ کاملتر
مسئلهای که این مقاله سراغش رفته برای هر تیم عملیاتی آشناست: ساعت دو بامداد یک حادثه شلیک میشه و مهندس on-call باید تلهمتری رو بین CloudWatch، پایپلاینهای استقرار و لاگ اپلیکیشن همبسته کنه، بعد دستی اصلاحیه بنویسه و مستقرش کنه — فرایندی که معمولاً ساعتها طول میکشه. به گفتهٔ AWS، سرویس DevOps Agent نیمهٔ اول این کار رو خودکار کرده و در دورهٔ پیشنمایش مشتریها تا ۷۵٪ کاهش MTTR، ۸۰٪ تحقیقات سریعتر و ۹۴٪ دقت در تشخیص ریشهٔ خطا گزارش کردن.
ولی نویسندهها میگن تحلیل و توصیه فقط نصف ماجراست: یکی هنوز باید یافتهها رو بخونه، اصلاحیه رو بنویسه، تستش کنه و مستقرش کنه. این مقاله نشون میده چطور میشه اون نیمهٔ دوم رو هم خودکار کرد.
معماری پیشنهادی یک پل رویدادمحور و کاملاً سرورلسه. وقتی DevOps Agent تحلیل کاهش اثر رو تموم میکنه، رویداد چرخهٔ عمرش با منبع aws.aidevops و نوع جزئیات Mitigation Completed روی گذرگاه پیشفرض EventBridge منتشر میشه. یک rule اون رویداد رو میگیره و یک تابع Lambda رو صدا میزنه.
اون Lambda با استفاده از متادیتای رویداد به API سرویس DevOps Agent وصل میشه و دو شیء کلیدی رو بیرون میکشه: خلاصهٔ کاهش اثر (چه اقدامی و چرا) و برنامهٔ اجرا (دستورالعمل گامبهگام). این بستهٔ ساختاریافته روی یک صف SQS منتشر میشه. با رسیدن پیام به صف، یک Lambda دیگه اجرای CodeBuild رو استارت میزنه و محتوای پیام رو بهعنوان متغیر محیطی پاس میده.
نقطهٔ اتصال اصلی، حالت headless در Kiro CLI 2.0 هست که اجازه میده این ابزار بهشکل برنامهنویسیشده و بدون ترمینال تعاملی داخل پایپلاین اجرا بشه. احراز هویت با کلید API انجام میشه که از Secrets Manager کشیده میشه و هیچوقت داخل کد هاردکد نمیشه. مراحل buildspec هم مشخصه: نصب و پیکربندی، تبدیل بستهٔ ساختاریافته به یک پرامپت ترمیم به زبان طبیعی با یک اسکریپت پایتون، ساخت شاخهٔ جدید با نامی برگرفته از شناسههای اجرا برای ردیابی، اجرای Kiro، و در نهایت اعتبارسنجی و کامیت.
چیزی که از نظر نویسندهها Kiro رو از تولید کد عمومی به ترمیم واقعی تبدیل میکنه، فایل steering هست؛ فایلی که در مخزن کامیت میشه و دانش پایدار دربارهٔ پروژه به ابزار میده. این فایل عملاً حفاظ کار خودکاره: ساختار مخزن، چارچوب تصمیم برای تشخیص تغییر زیرساختی از اپلیکیشنی، محدودیت دامنه (حداکثر سه فایل، بدون فایل جدید، بدون وابستگی تازه، بدون حذف)، فهرست فایلهای محافظتشده، و یک قاعدهٔ fail-safe: اگه پرامپت مبهم بود، هیچ تغییری نده بهجای اینکه حدس بزنه.
قبل از کامیت هم چند حفاظ دیگه اعمال میشه: بررسی تعداد فایلهای تغییریافته، تشخیص فایلهای محافظتشده، اعتبارسنجی نحوی پایتون با py_compile و لینت YAML. اگه همهشون پاس بشن، تغییرات کامیت و پوش میشن و یک پولریکوئست ساخته میشه که عنوانش اقدام کاهش اثر و توضیحاتش استدلال خود DevOps Agent هست، بههمراه شناسهها برای ردیابی کامل تا حادثهٔ اولیه.
دروازهٔ انسانی عمداً همینجا گذاشته شده. نویسندهها تصریح میکنن که به ایجنتها برای تحقیق، تحلیل و پیشنهاد اصلاحیه اعتماد میکنن، ولی تصمیم نهایی استقرار با انسانه. بعد از تأیید و مرج، پایپلاین استقرار تغییر رو در محیط هدف اعمال میکنه و کل چرخه — از هشدار تا اصلاحیهٔ مستقرشده — بهجای ساعتها در چند دقیقه تموم میشه.
نکات کلیدی:
- DevOps Agent تحقیق و برنامهٔ کاهش اثر رو تولید میکنه؛ Kiro CLI کد رو اصلاح میکنه
- مسیر رویداد: EventBridge ← Lambda ← SQS ← CodeBuild با Kiro در حالت headless
- فایل steering دامنهٔ تغییر رو محدود و فایلهای حساس رو ممنوع میکنه
- قاعدهٔ fail-safe: در ابهام هیچ تغییری اعمال نشه
- تنها نقطهٔ دخالت انسان، تأیید پولریکوئسته
- کلید API از Secrets Manager خونده میشه و هاردکد نمیشه
