הטמעת AIOps לאוטומציה של תפעול IT

ניטור המבוסס על ספים סטטיים טובע באזעקות שווא, בעוד שתאגיד אירועים ידני גוזל שעות רבות. אנו מיישמים AIOps — גישה המשתמשת בלמידת מכונה לניתוח מדדים, לוגים, אירועים ואזעקות. המטרה אינה להחליף מהנדסים אלא להפחית עייפות אזעקות, לזהות חריגות לפני שהתקלות מתרחשות, ולתאם אוטומטית אירועים ממקורות שונים לתמונה אחת. הניסיון מראה שלאחר אימוץ AIOps, נפח האזעקות יורד ב-70% ו-MTTR יורד פי 3–5.

הפער בין תיאוריה לפרקטיקה רחב במיוחד כאן. "יישום AIOps" עשוי להישמע כמו רכישת מוצר. במציאות, מדובר במאמץ רב-חודשי לבניית צינור נתונים ממדדים, אימון מודלים בסיסיים, כוונון ספים, ושילוב עם ניהול אירועים. אנו מבטיחים שהצוות שלך יקבל לא רק כלי אלא מערכת עובדת המותאמת לתשתית שלך.

מה AIOps פותר שניטור מסורתי אינו יכול

AIOps אינו רק טרנד — הוא הכרח לתשתיות גדולות. Prometheus עם כללי אזעקה מסתמך על ספים סטטיים: cpu > 80%. הבעיה: CPU תקין ביום שני בבוקר הוא 70%, בעוד שבליל ראשון הוא 10%. אזעקה ב-80% היא או שגויה (בלילה) או מאוחרת מדי (ביום שני, CPU עשוי כבר להיות 90% כשהאזעקה מופעלת).

זיהוי חריגות אינו מסתכל על ערכים מוחלטים אלא על סטייה מקו בסיס עונתי. אם CPU בדרך כלל 70% ביום שני בשעה 10:00, אבל היום הוא 40% — גם זו חריגה (השירות עשוי להפסיק לקבל תעבורה). זיהוי חריגות מדויק ב-50% יותר מספים סטטיים.

המשימה השנייה היא הפחתת רעש. בתשתית גדולה, תקלה אחת גורמת ל-50–200 אזעקות: מסד נתונים לא זמין → כל השירותים התלויים בו גם מתריעים → הניטור של אותם שירותים מתריע גם כן. תאגיד אירועים מקבץ אותם לאירוע אחד עם סיבת שורש.

כיצד אנו מיישמים AIOps בתשתית הקיימת שלך

היישום מתחיל בביקורת על הניטור הנוכחי שלך: אילו מדדים נאספים, אילו אזעקות מוגדרות, וכיצד תהליך ניהול האירועים עובד. לאחר מכן אנו מתכננים את צינור הנתונים ובוחרים מודלי ML מתאימים.

Prometheus + Grafana ML זיהוי חריגות

Grafana עם חיזוי מבוסס Prophet דרך תוסף Grafana ML:

---
# Grafana datasource для ML-обработанных метрик
apiVersion: 1
datasources:
  - name: Grafana ML
    type: grafana-ml-datasource
    url: http://grafana-ml:3000
    jsonData:
      prometheusUrl: http://prometheus:9090
---

עבור Prometheus — metricbeat עם עבודות ML או VictoriaMetrics Anomaly Detection:

---
# VictoriaMetrics anomaly detection config
schedulers:
  periodic:
    class: "scheduler.periodic.PeriodicScheduler"
    infer_every: "1m"
    fit_every: "1h"
    fit_window: "14d"
    models:
      zscore:
        class: "model.zscore.ZscoreModel"
        z_threshold: 2.5
      prophet:
        class: "model.prophet.ProphetModel"
        args:
          changepoint_prior_scale: 0.05
          seasonality_mode: "multiplicative"
          yearly_seasonality: false
          weekly_seasonality: true
          daily_seasonality: true
    queries:
      cpu_usage:
        expr: "avg by (instance) (rate(node_cpu_seconds_total{mode!='idle'}[5m]))"
        step: "1m"
        model: "prophet"
      error_rate:
        expr: "rate(http_requests_total{status=~'5..'}[5m])"
        step: "1m"
        model: "zscore"

תוצאה: מדד # Grafana datasource для ML-обработанных метрик apiVersion: 1 datasources: - name: Grafana ML type: grafana-ml-datasource url: http://grafana-ml:3000 jsonData: prometheusUrl: http://prometheus:9090 מ-0 עד 1. אזעקה מופעלת כאשר # VictoriaMetrics anomaly detection config schedulers: periodic: class: "scheduler.periodic.PeriodicScheduler" infer_every: "1m" fit_every: "1h" fit_window: "14d" models: zscore: class: "model.zscore.ZscoreModel" z_threshold: 2.5 prophet: class: "model.prophet.ProphetModel" args: changepoint_prior_scale: 0.05 seasonality_mode: "multiplicative" yearly_seasonality: false weekly_seasonality: true daily_seasonality: true queries: cpu_usage: expr: "avg by (instance) (rate(node_cpu_seconds_total{mode!='idle'}[5m]))" step: "1m" model: "prophet" error_rate: expr: "rate(http_requests_total{status=~'5..'}[5m])" step: "1m" model: "zscore" , לא כאשר anomaly_score. זה מפחית את MTTR פי 3 בהשוואה לתאגיד ידני.

תאגיד אזעקות עם Moogsoft / BigPanda / קוד מותאם אישית

פלטפורמות AIOps מסחריות (Moogsoft, BigPanda) קולטות אזעקות מ-Prometheus, PagerDuty, ServiceNow ומתאמות אותן באמצעות ML. למי שמעדיף קוד פתוח, אנו בונים לוגיקת תאגיד מותאמת אישית.

תאגיד פשוט: קיבוץ אזעקות לפי חלון זמן ותוויות משותפות:

from collections import defaultdict
from datetime import datetime, timedelta

def correlate_alerts(alerts: list[dict], window_minutes: int = 5) -> list[dict]:
    """Группирует алерты, произошедшие в одном временном окне."""
    incidents = []
    used = set()
    for i, alert in enumerate(alerts):
        if i in used:
            continue
        group = [alert]
        alert_time = datetime.fromisoformat(alert['startsAt'])
        for j, other in enumerate(alerts[i+1:], i+1):
            if j in used:
                continue
            other_time = datetime.fromisoformat(other['startsAt'])
            # Алерт в том же временном окне
            if abs((other_time - alert_time).total_seconds()) < window_minutes * 60:
                # И в той же namespace или на том же node
                if (alert['labels'].get('namespace') == other['labels'].get('namespace') or
                        alert['labels'].get('node') == other['labels'].get('node')):
                    group.append(other)
                    used.add(j)
        if len(group) > 1:
            incidents.append({
                "type": "correlated_incident",
                "root_cause_candidate": min(group, key=lambda a: a['startsAt']),
                "related_alerts": group[1:],
                "alert_count": len(group),
            })
        else:
            incidents.append({"type": "single_alert", **alert})
    return incidents

האזעקה הראשונה בקבוצה היא מועמדת לסיבת שורש. זה לא מדויק, אבל נותן למהנדס נקודת התחלה נכונה.

זיהוי חריגות בלוגים עם OpenSearch / Elasticsearch

OpenSearch ML Commons מספק זיהוי חריגות מובנה ללוגים:

PUT _plugins/_anomaly_detection/detectors
{
  "name": "error-rate-detector",
  "description": "Detect anomalies in error log rate",
  "time_field": "@timestamp",
  "indices": ["app-logs-*"],
  "feature_attributes": [
    {
      "feature_name": "error_count",
      "feature_enabled": true,
      "aggregation_query": {
        "error_count": {
          "value_count": {
            "field": "level",
            "script": {
              "source": "doc['level.keyword'].value == 'ERROR' ? 1 : 0"
            }
          }
        }
      }
    }
  ],
  "detection_interval": {
    "period": {
      "interval": 5,
      "unit": "Minutes"
    }
  },
  "window_delay": {
    "period": {
      "interval": 1,
      "unit": "Minutes"
    }
  }
}

הגלאי לומד מ-14 ימים של נתונים היסטוריים ולאחר מכן מסמן עליות חריגות בשגיאות לפני שהן מגיעות לספי SLO.

LLM לסיכום אירועים

GPT-4 או LLM מקומי (LLaMA דרך Ollama) לסיכום אירועים מלוגים ומדדים:

import openai
from datetime import datetime, timedelta

def summarize_incident(prometheus_url: str, incident_start: datetime):
    # Собираем метрики за период инцидента
    metrics = fetch_prometheus_metrics(prometheus_url, incident_start)
    logs = fetch_logs_from_loki(incident_start, incident_start + timedelta(hours=1))
    prompt = f"""You are a DevOps SRE. Analyze the following metrics and logs from a production incident and provide:
1. Root cause hypothesis
2. Affected services
3. Timeline of events
4. Recommended immediate actions

Metrics (last 30 min): {metrics}
Relevant log entries: {logs[:3000]}
Respond in Russian."""
    response = openai.chat.completions.create(
        model="gpt-4-turbo",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=1000,
    )
    return response.choices[0].message.content

התוצאה נשלחת ל-Slack כאשר נוצר אירוע — מהנדסים מקבלים סיכום מובנה במקום 200 שורות של אזעקות.

תוצאות צפויות

השוואה לפני ואחרי יישום AIOps בתשתית טיפוסית (1000+ שרתים):

חיסכון משמעותי בעלויות תפעול מושג באמצעות הפחתת זמן תורנות ואבחון מהיר יותר.

מה כלול בעבודה שלנו

• ביקורת על תהליכי ניטור וניהול אירועים קיימים.
• תכנון צינור נתונים: איסוף מדדים, לוגים, אירועים.
• הגדרת זיהוי חריגות למדדים מרכזיים (CPU, זיכרון, שגיאות).
• יישום תאגיד אזעקות — קיבוץ אזעקות, הפחתת רעש.
• זיהוי חריגות בלוגים — זיהוי דפוסים חריגים בלוגים.
• סיכום אירועים מבוסס LLM לניתוח מהיר.
• תיעוד והדרכת צוות.
• תמיכת ייצוב לשבועיים.

למה לבחור בנו

המהנדסים שלנו הם מומחים מוסמכים עם ניסיון מעשי רב ביישום AIOps. השלמנו מעל 20 פרויקטים לחברות בתחומי הקמעונאות, הפינטק והתקשורת. אנו מבטיחים הפחתת MTTR פי 3–5 לאחר סיום הפרויקט. תקופת ההחזר ליישום AIOps עומדת בממוצע על שישה חודשים באמצעות הפחתת זמן ניתוח אירועים ופחות תורנויות.

קבלו ייעוץ: ננתח את הניטור שלכם ונציע תוכנית יישום. צרו קשר כדי לדון בפרטים.