عامل‌های هوش مصنوعی با پیش‌بینی خطی Prometheus از قطعی‌های ساعت ۲ صبح جلوگیری

تصور کنید یک مهندس SRE باشد که به‌جای بیدار شدن با هشدار بحرانی در ساعت ۳ صبح یکشنبه، دوشنبه صبح با یک درخواست تغییر (PR) دقیق روی میز کارش می‌بیند که می‌گوید: «دیسک دیتابیس تا ۹ روز دیگر پر می‌شود؛ این مقدار را افزایش دهید». این تغییر رویکرد، تفاوت میان واکنش اضطراری و مدیریت پیش‌دستانه در زیرساخت‌های ابری است. در واقع، تیم‌های SRE اغلب با «احمقانه‌ترین» نوع قطعی‌ها دست‌وپنجه نرم می‌کنند؛ حوادثی که می‌توانستند با پاسخ به یک سوال ساده در هفته یک‌بار برای هر کلاستر پیش‌بینی شوند: چه منبعی زودتر از همه تمام می‌شود، چه زمانی این اتفاق می‌افتد و کوچک‌ترین تغییری که ۳۰ روز فرصت خریداری می‌کند چیست؟

بسیاری از قطعی‌های زیرساختی در کوبرنتیز (Kubernetes) از یک الگوی دردناک و قابل‌پیش‌بینی پیروی می‌کنند. برای مثال، یک درخواست حجم ذخیره‌سازی (PVC) — شبیه به یک سطل آب است که اگر لبه‌اش پر شود، کل آشپزخانه را خیس می‌کند — ناگهان در ساعت ۳ صبح یکشنبه به ۱۰۰٪ می‌رسد و دیتابیس Postgres دیگر اجازه نوشتن داده نمی‌دهد. یا یک NodePool به سقف CPU خود می‌رسد و تمام پادهای جدید در وضعیت Pending می‌مانند و برای یک ساعت در این حالت می‌مانند. یا یک سهمیه Namespace (Quota) پر می‌شود و CI نمی‌تواند Runnerهای خود را زمان‌بندی کند. طبق گزارش منتشر شده در devtocash.com، این شکست‌ها اجتناب‌پذیر هستند چون سیگنال‌های آن‌ها معمولاً یک هفته پیش از حادثه روی داشبوردها دیده می‌شوند. همان‌طور که در راهنمای Pod Pending / FailedScheduling برای مدیریت بحران‌های ساعت ۲ صبح توضیح داده شده، هدف ما در اینجا سیستمی است که اجازه ندهد وضعیت هرگز به ساعت ۲ صبح برسد.

راهکار این است که از هوش مصنوعی زاینده (Generative AI) — مثل دستیاری که میلیاردها صفحه مستند را خوانده و حالا می‌تواند منطق آن‌ها را به عمل تبدیل کند — نه برای پیش‌بینی سری‌های زمانی (Time Series) که LLMها در آن ضعیف هستند، بلکه به‌عنوان یک لایه استدلالی روی قوانین ثبت (Recording Rules) پایدار Prometheus استفاده شود. این رویکرد باعث می‌شود ریاضیات پیش‌بینی از تصمیم‌گیری عامل جدا شود.

موتور پیش‌بینی

این سامانه بر توابع predict_linear و deriv در Prometheus تکیه دارد تا قوانین ثبت ایجاد کند. این قوانین یک خوانش پایدار و ارزان برای عامل فراهم می‌کنند و تضمین می‌کنند که LLM هرگز محاسبات برون‌یابی (Extrapolation) خام انجام ندهد. پیش‌بینی در اینجا کاملاً حسابی (Arithmetic) و قابل تست است و هیچ مدلی در ریاضیات سری‌های زمانی دخالت ندارد.

چهار قانون اصلی در capacity-rules.yaml رایج‌ترین نقاط اتمام منابع را پوشش می‌دهند:

• اتمام PVC (capacity:pvc_days_to_full): تعداد روزهای باقی‌مانده تا پر شدن حجم را بر اساس شیب ۶ ساعته محاسبه می‌کند. از عبارت kubelet_volume_stats_available_bytes / clamp_min(-deriv(kubelet_volume_stats_available_bytes[6h]), 1) / 86400 استفاده می‌کند. تابع clamp_min نرخ کاهش را در یک بایت بر ثانیه کف می‌زند تا وقتی شیب صفر یا مثبت است (که در غیر این صورت منجر به تعداد روزهای بی‌نهایت می‌شد)، محاسبات منفجر نشوند.
• نسبت CPU در NodePool (capacity:nodepool_cpu_limit_ratio): میزان CPU درخواست شده فعلی را در برابر سقف سخت‌افزاری یک NodePool در Karpenter رصد می‌کند: karpenter_nodepool_usage{resource_type="cpu"} / karpenter_nodepool_limit{resource_type="cpu"}. اگر از Cluster Autoscaler استفاده شود، این مورد با محاسبات max-size در ASG جایگزین می‌شود.
• پیش‌بینی ۷ روزه (capacity:nodepool_cpu_limit_ratio_7d): پیش‌بینی می‌کند که نسبت CPU در NodePool بر اساس رشد ۲۴ ساعت گذشته، در یک هفته آینده به کجا می‌رسد: predict_linear(capacity:nodepool_cpu_limit_ratio[24h], 7*24*3600).
• فشار ResourceQuota (capacity:quota_ratio): نسبت مصرف به سقف سخت در هر Namespace و منبع را نظارت می‌کند: kube_resourcequota{type="used"} / on (namespace, resourcequota, resource) kube_resourcequota{type="hard"}.

مدیریت حافظه (Memory) نیز از طریق نسخه‌ای مشابه از قوانین NodePool با استفاده از resource_type="memory" انجام می‌شود. در حالی که عامل روی «سوختن آرام» (Slow Burn) متمرکز است، خود قوانین ثبت همچنان باید دارای هشدار باشند؛ برای مثال، اگر capacity:pvc_days_to_full < 3 باشد، فارغ از فعال بودن عامل، باید یک هشدار (Page) ارسال شود. ارزش ویژه عامل در شناسایی ریسک‌هایی است که آستانه هشدارهای سنتی را رد نمی‌کنند؛ مثلاً ریسکی که ۹ روز دیگر در روز سه‌شنبه رخ می‌دهد، زمانی که یک PR دو خطی هنوز یک تغییر خسته‌کننده و ساده است.

ابزارها و نرده‌های ایمنی

عامل دسترسی آزاد به کوئری‌ها ندارد. در عوض، از سه ابزار خواندنی ساخته شده با FastMCP استفاده می‌کند که به‌جای تعداد بایت‌های خام یا تاریخچه، اعداد محاسبه شده (روزها، نسبت‌ها و تعداد) را برمی‌گردانند. این رویکرد مشابه یک سرور Prometheus MCP است اما با سطح دسترسی محدودتر.

جزئیات ابزارها:

• pvc_forecast(max_days=30): لیست PVCهایی که پیش‌بینی می‌شود در بازه زمانی مشخص پر شوند را برمی‌گرداند (بدترین‌ها در اولویت). این ابزار days_to_full و capacity_gib (مشتق شده از kubelet_volume_stats_capacity_bytes) را ارائه می‌دهد تا عامل بتواند بدون انجام محاسبات تبدیل بایت به گیگابایت، یک اندازه جدید و مشخص پیشنهاد دهد. هر چیزی بالای ۳۶۵ روز به عنوان «بدون نگرانی» تلقی می‌شود.
• nodepool_headroom(): نسبت فعلی سقف CPU، نسبت پیش‌بینی شده برای ۷ روز آینده و تعداد پادهایی که در یک ساعت گذشته غیرقابل زمان‌بندی (Unschedulable) بوده‌اند را از طریق sum(kube_pod_status_unschedulable) or vector(0) برمی‌گرداند.
• quota_pressure(threshold=0.8): Namespaceهایی را شناسایی می‌کند که هر یک از منابع ResourceQuota آن‌ها از آستانه مشخص شده عبور کرده است.

برای جلوگیری از تبدیل شدن عامل به یک «حادثه هزینه‌ای»، سیاست‌های سخت‌گیرانه‌ای در سطح کد اجرا شده است. مدل مجبور است از طرحواره‌ای (Schema) پیروی کند که در آن متن آزاد فقط در بخش استدلال (Reasoning) مجاز است؛ هر فیلدی که یک اسکریپت روی آن عمل می‌کند باید یک Enum یا یک عدد محدود باشد. طرحواره FINDINGS_TOOL برای فیلد kind (pvc, nodepool, quota)، urgency (this_week, this_month, watch) و action (expand_pvc, raise_nodepool_limit, raise_quota, investigate_growth, none) از Enumهای خاص استفاده می‌کند.

یک نرده ایمنی حیاتی، سقف ۱.۵ برابر است: عامل نمی‌تواند افزایشی بیش از ۱۵۰٪ مقدار فعلی را پیشنهاد دهد. اگر حجمی بیش از این نیاز داشته باشد، سیستم آن را برای بررسی انسانی علامت‌گذاری می‌کند. رشد فراتر از این سقف سیگنالی است که نشان می‌دهد بار کاری (Workload) نیاز به گفتگو دارد، نه فقط یک دیسک بزرگ‌تر. علاوه بر این، تابع validate هرگونه گسترش PVC که منجر به حجمی بالای ۲ ترابایت شود را رد می‌کند، زیرا چنین حجمی نیاز به یک برنامه انسانی دارد. همچنین اعتبارسنج را بررسی می‌کند که PVCها نتوانند کوچک شوند.

از یافته تا درخواست تغییر (PR)

عامل از الگوی «PR به‌جای kubectl» پیروی می‌کند؛ یعنی هرگز مستقیماً با خوشه ارتباط برقرار نمی‌کند، بلکه یک PR در مخزن GitOps می‌سازد. دستورالعمل‌های سیستم (System Prompt) به عامل می‌گوید که وقتی نرخ پر شدن یک PVC نشان می‌دهد در ۳۰ روز آینده بیش از ۲ برابر رشد می‌کند، به‌جای افزایش سقف، گزینه investigate_growth را ترجیح دهد، زیرا این معمولاً نشانه یک نشت (Leak) یا نبود سیاست‌های حذف داده (Retention Policy) است.

برای مثال، یک PR برای افزایش سقف NodePool در فایل infra/karpenter/nodepool-general.yaml ممکن است CPU را از «۳۲۰» به «۴۸۰» ارتقا دهد. متن PR از یک قالب (Template) تولید می‌شود، نه توسط مدل، و شامل موارد زیر است:

• شواهد: نسبت فعلی (مثلاً ۰.۸۴) و پیش‌بینی ۷ روزه (۱.۰۲) بر اساس شیب رشد ۲۴ ساعته.
• فوریت: دسته‌بندی شده در گروه‌های this_week (زیر ۷ روز)، this_month (زیر ۳۰ روز) یا watch.
• هزینه‌ها: تخمین دلتای هزینه (مثلاً ۱۴۲۰+ دلار در ماه برای ۱۶۰ vCPU از نوع m6i on-demand) که توسط یک جستجوی قیمت در Wrapper محاسبه شده است. یک PR بدون دلتای هزینه، «نیمه PR» تلقی می‌شود چون بازبین باید بداند آیا این رشد ارزش پرداخت هزینه را دارد یا خیر.
• استدلال: منطق عامل (مثلاً: «استخر General در حدود ۶ روز آینده با رشد فعلی درخواست‌ها به سقف می‌رسد؛ HPA روی checkout-api از دوشنبه ۲۲ رپلیکا اضافه کرده است»).

برای گسترش PVC، عامل باید تأیید کند که StorageClass دارای allowVolumeExpansion: true است و PVC در Git (توسط Helm یا Kustomize) مدیریت می‌شود. اگر یک PVC توسط volumeClaimTemplates در یک StatefulSet ایجاد شده باشد، عامل طوری برنامه‌ریزی شده که مستقیماً Claim را هدف قرار دهد، زیرا ویرایش Template روی Claimهای موجود اثر نمی‌گذارد. Wrapper این را به عنوان یک قانون سخت کد کرده است: یافته‌های expand_pvc که منبع Git ندارند، به investigate_growth تنزل یافته و یک یادداشت دریافت می‌کنند.

استقرار و اعتبارسنجی

این عامل به‌عنوان یک CronJob هر دوشنبه ساعت ۶ صبح اجرا می‌شود تا رشد آخر هفته در شیب ۲۴ ساعته ثبت شده و پیش از اعمال تغییرات هفته جاری، تحلیل شود.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: capacity-agent
  namespace: sre-agents
spec:
  schedule: "0 6 * * 1"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: capacity-agent
          restartPolicy: Never
          containers:
          - name: agent
            image: ghcr.io/example/capacity-agent:1.4.0
            env:
            - name: PROM_URL
              value: http://prometheus.monitoring.svc:9090
            - name: MODE
              value: "shadow"
            envFrom:
            - secretRef: { name: capacity-agent-github }

برای اطمینان از قابلیت اطمینان، ابتدا در حالت MODE=shadow اجرا می‌شود؛ در این حالت یافته‌ها فقط در یک کانال ارسال می‌شوند و PRی ساخته نمی‌شود تا مهندسان دقت آن را در ۴ چرخه هفتگی بسنجند. یک مورد مثبت کاذب (False Positive) رایج، «حجم‌های چرخه‌ای» (Cyclic Volumes) هستند — حجم‌های موقتی (Scratch) که هر شب پر و خالی می‌شوند. اگر حالت Shadow این‌ها را شناسایی کند، بازه قانون PVC را می‌توان برای حجم‌هایی که دارای انوتیشن capacity-agent/cyclic: "true" هستند به [24h] تغییر داد تا ابزار pvc_forecast آن را رعایت کند.

از نظر امنیتی، ServiceAccount این عامل هیچ دسترسی RBAC به کوبرنتیز ندارد. عامل فقط به دسترسی HTTP به Prometheus و دسترسی نوشتن در GitHub نیاز دارد که شعاع تخریب (Blast Radius) را در مقایسه با عامل‌هایی که دسترسی kubectl دارند، به شدت کاهش می‌دهد. این موضوع آن را به اولین عامل ایده‌آل برای تیم‌هایی تبدیل می‌کند که تازه با اتوماسیون LLM آشنا شده‌اند.

محدودیت‌های منطق خطی

باید به خاطر داشت که برون‌یابی خطی یک خط‌کش است، نه گوی بلورین. این سیستم نمی‌تواند رویدادهای «پله‌ای» مثل لانچ محصولات، پیک‌های جمعه سیاه یا مهاجرت‌های دیتابیس را پیش‌بینی کند. همچنین نمی‌تواند پادهای بدون Resource Request را ببیند، زیرا متریک‌های مصرف Karpenter به این درخواست‌ها متکی هستند. خوشه‌هایی با درخواست‌های نامنظم، فشار را کمتر از مقدار واقعی گزارش می‌کنند؛ این موضوع باید ابتدا با یک سیاست Kyverno یا LimitRange اصلاح شود.

علاوه بر این، نسبت‌های Quota نشان نمی‌دهند که آیا خودِ سهمیه درست است یا خیر. یک Namespace که ۸۵٪ از سهمیه‌ای که دو سال پیش به‌صورت تصادفی تعیین شده است را مصرف می‌کند، نیاز به گفتگو دارد و اکشن raise_quota اغلب بیشترین نرخ رد شدن در بازبینی را دارد. در نهایت، این طراحی فرض می‌کند که Retention در Prometheus حداقل یک روز داده با رزولوشن ۵ دقیقه‌ای را پوشش می‌دهد تا نویز در شیب‌ها ایجاد نشود.

در نهایت، این عامل مکمل دانش انسانی از تقویم کسب‌وکار است. این سیستم تجربه SRE را از واکنش به هشدارهای ساعت ۳ صبح، به بررسی یک PR مستدل در کنار قهوه صبحگاهی تبدیل می‌کند. پیشنهاد می‌شود ابتدا با قوانین ثبت (Recording Rules) شروع کنید — چون حتی بدون عامل هم ارزشمند هستند — سپس در هفته دوم ابزارها و حالت Shadow را اضافه کنید.

📌 آخرین نسخه این راهنما و کتابخانه کامل راهنمای DevOps، SRE، کوبرنتیز، مشاهده‌پذیری و هزینه ابری را در devtocash.com بخوانید.

گام بعدی شما

• ابتدا قوانین ثبت (Recording Rules) Prometheus را برای PVC و NodePool پیاده‌سازی کنید؛ این قوانین حتی بدون عامل هم ارزشمند هستند.
• یک عامل ساده با دسترسی Read-only به این قوانین بسازید و آن را در حالت Shadow اجرا کنید.
• برای هر تغییر پیشنهادی، حتماً فیلد «تخمین هزینه» را اضافه کنید تا فرآیند تایید توسط مدیران مالی تسریع شود.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.