AWS DevOps Agent: عیبیابی خودکار پایپلاین گیتهاب
هوش مصنوعیخلاصهٔ کاملتر
تو این پست از وبلاگ AWS اومده که حلقهٔ تریاژ دستی خرابیهای CI/CD چهقدر وقت میبره: لاگ رو بخون، ریشه رو پیدا کن، فیکس بنویس، PR باز کن، منتظر ریویو بمون و دوباره ورکفلو رو اجرا کن. برای سازمانی که دهها یا صدها ورکفلوی GitHub Actions روی چندین ریپو داره، همین حلقه خیلی زود چند ساعت کار میشه. AWS DevOps Agent یه ایجنت خودمختار و همیشهروشنه که همون لحظهٔ خرابی وارد میشه و همون استدلالی رو پیش میبره که یه SRE باتجربه پیش میبرد.
به گفتهٔ نویسنده جریان کار سادهست: توسعهدهنده کد پوش میکنه، یکی از مرحلههای پایپلاین میشکنه و یه وبهوک با جزئیات حادثه ایجنت رو صدا میزنه. از اونجا ایجنت لاگ ورکفلو رو میخونه، سورسکد و کانفیگ و کامیتهای اخیر رو نگاه میکنه و خرابی رو با تاریخچهٔ دیپلوی و لاگهای Amazon CloudWatch تطبیق میده تا به ریشهٔ اصلی برسه. راهاندازیش هم یعنی ساختن یه Agent Space، وصلکردن گیتهاب و تنظیم وبهوکی که با امضای HMAC احراز هویت میشه.
نکتهٔ کلیدی معماری اینه که GitHub App فقط دسترسی خواندنی میده؛ برای بررسی کافیه ولی برای اقدام نه. برای همین باید GitHub MCP Server رو هم بهعنوان ابزار سفارشی توی Agent Space ثبت کنی تا ایجنت یه کانال نوشتن داشته باشه و بتونه برنچ بسازه و پولریکوئست باز کنه. نویسنده توصیه میکنه فقط ابزارهای لازم رو فعال کنی — عملاً create_pull_request و create_or_update_file کفایت میکنه — و توکن گیتهاب هم fine-grained و محدود به همون ریپوها باشه.
مقاله دو سناریوی واقعی رو نشون میده. اولی یه خطای کامپایل TypeScript با کد TS2353ه که ایجنت از روی لاگ بیلد و تعریف اینترفیس میفهمه یه پراپرتی نامعتبر به آبجکت اضافه شده و PR حذفش رو باز میکنه. دومی یه خرابی دیپلویه: مسیر سکرت توی Secrets Manager عوض شده، دیپلوی CDK موفق میشه ولی تسکهای ECS موقع بالا اومدن کرش میکنن؛ ایجنت از لاگ CloudWatch به ResourceNotFoundException میرسه و مسیر درست رو برمیگردونه.
نویسنده تأکید میکنه ایجنت فقط PR باز میکنه و هیچوقت مرجش نمیکنه؛ برای برنچهای پروداکشن باید حداقل یه ریویوئر انسانی و قوانین branch protection داشته باشی. رصد فعالیت ایجنت از راه ژورنال بررسی و متریکهای CloudWatch هم توصیه شده. ضمناً این راهکار منابع قابلصورتحساب AWS میسازه، پس اگه دیگه لازمش نداری پاکشون کن.
نکات کلیدی:
- ایجنت با وبهوک خرابی GitHub Actions فعال میشه و خودش ریشهیابی میکنه.
- GitHub App فقط خوندنیه؛ برای باز کردن PR اصلاحی به GitHub MCP Server نیاز داری.
- لاگ بیلد، سورسکد، کامیتها، تاریخچهٔ دیپلوی و لاگهای CloudWatch کنار هم بررسی میشن.
- تشخیص تستهای flaky هم از روی تاریخچهٔ اجراها ممکنه.
- PR ساختهشده حتماً باید ریویو انسانی بشه؛ ایجنت خودش مرج نمیکنه.
