התראות מותאמות אישית על מדדים עסקיים: הזמנות, המרות, שגיאות אתר

תארו לעצמכם: בין לילה, שיעור ההמרה בקופה צונח ב-40%, והניטור הטכני שותק — CPU תקין, זמן השהייה תקין. רק בבוקר המנכ"ל רואה את המספרים ב-Google Analytics ומפסיד הכנסות. חוקי התראה מותאמים אישית על מדדים עסקיים פותרים את זה: אתם לומדים על ירידה בהזמנות או עלייה בשגיאות תשלום תוך 5 דקות. הקמנו התראות כאלה לעשרות פרויקטים של מסחר אלקטרוני, SaaS ותוכן. הגישה פשוטה: לבצע אינסטרומנטציה לקוד עם מדדי Prometheus, להגדיר ספים תוך התחשבות בעונתיות, ולהגדיר ניתוב ל-Slack או PagerDuty. התוצאה — זמן התגובה לבעיות קריטיות לעסק מצטמצם משעות לדקות. לפי מחקר, שעת השבתה בקופה עולה למסחר אלקטרוני גדול בממוצע 4.5–6.5 אלף דולר. במאמר זה נסקור אילו מדדים לנטר, כיצד ליישם התראות על Prometheus ו-CloudWatch, וכיצד להימנע מהצפה בהתראות שווא.

אילו מדדים עסקיים לנטר?

המדדים תלויים בסוג המוצר. אנו מזהים שלוש קטגוריות עיקריות.

מסחר אלקטרוני

• מספר ההזמנות שהושלמו לשעה (ירידה חדה) — קריטי להכנסות
• המרה מעגלת קניות לתשלום — אם היא יורדת מתחת לקו הבסיס ב-X%, זהו אות לבדוק את שער התשלום
• הכנסות לשעה מתגלגלת — עוזר לזהות חריגות במהירות
• מספר שגיאות התשלום — חשוב לצוות הטכני

SaaS

• הרשמות משתמשים חדשים (אפס בשעות האחרונות) — אות לכשל בתהליך ההרשמה
• משתמשים פעילים מקוונים — ירידה בלתי צפויה עשויה להצביע על בעיית API
• בקשות API מלקוחות מפתח — גידול או ירידה חריגים

פרויקטי תוכן

• צפיות בדפים — ירידה חדה = בעיית SEO או CDN
• שיעור נטישה — עלייה חדה עשויה להצביע על טעינה איטית
• טפסים שנשלחו — אפס בשעות האחרונות מצביע על באג בטפסים

כיצד אנו מיישמים התראות על מדדים עסקיים

אנו משתמשים בשתי גישות עיקריות: Prometheus (לסביבות מתארחות עצמית) ו-CloudWatch (ל-AWS). הבחירה תלויה בתשתית שלכם. מניסיון, Prometheus מציע גמישות רבה יותר בהתאמה אישית, בעוד ש-CloudWatch משתלב טוב יותר עם Lambda ו-API Gateway.

יישום באמצעות Prometheus

בצעו אינסטרומנטציה לקוד עם לקוח Prometheus:

from prometheus_client import Counter, Histogram

orders_completed = Counter(
    'orders_completed_total',
    'Total completed orders',
    ['payment_method', 'product_category']
)

order_value = Histogram(
    'order_value_rub',
    'Order value in dollars',
    buckets=[100, 500, 1000, 2500, 5000, 10000, 25000, 50000]
)

payment_errors = Counter(
    'payment_errors_total',
    'Payment processing errors',
    ['error_code', 'payment_provider']
)

חוקי התראה למדדים עסקיים:

groups:
  - name: business_alerts
    rules:
      - alert: NoOrdersReceived
        expr: |
          ( rate(orders_completed_total[30m]) == 0 and hour() >= 9 and hour() <= 22 )
        for: 5m
        labels:
          severity: critical
          team: business
        annotations:
          summary: "No orders completed in last 30 minutes during business hours"
          runbook_url: "https://wiki.company.com/runbooks/no-orders"
      - alert: ConversionDropped
        expr: |
          rate(orders_completed_total[1h]) / rate(cart_checkout_started_total[1h]) < 0.3
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Checkout conversion dropped to {{ $value | humanizePercentage }}"
      - alert: PaymentErrorRateHigh
        expr: |
          rate(payment_errors_total[5m]) > 0.5
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "{{ $value }} payment errors/sec — potential payment gateway issue"

יישום באמצעות CloudWatch (AWS)

לפרויקטי AWS, אנו משתמשים ב-CloudWatch. הקוד עובר אינסטרומנטציה דרך SDK (boto3) — שליחת מדדי OrdersCompleted ו-OrderRevenue עם ממדים PaymentMethod ו-Environment. חוקי ההתראה מוגדרים ב-Terraform:

resource "aws_cloudwatch_metric_alarm" "no_orders" {
  alarm_name = "no-orders-30min"
  comparison_operator = "LessThanThreshold"
  evaluation_periods = 1
  metric_name = "OrdersCompleted"
  namespace = "MyApp/Business"
  period = 1800
  statistic = "Sum"
  threshold = 1
  treat_missing_data = "breaching"
  dimensions = {
    Environment = "production"
  }
  alarm_description = "No orders in 30 minutes"
  alarm_actions = [aws_sns_topic.critical_alerts.arn]
}

כיצד להגדיר התראות למדדים עונתיים?

ספים קבועים עובדים בצורה גרועה עבור מדדים עם עונתיות. בערב שישי, ההזמנות גבוהות פי 3 מאשר בבוקר יום שני. CloudWatch Anomaly Detection בונה תחזית המבוססת על נתונים היסטוריים ומפעיל התראה רק כאשר החריגה חורגת מהרצועה. בפרויקטים שלנו, זה מפחית התראות שווא ב-70%.

resource "aws_cloudwatch_metric_alarm" "orders_anomaly" {
  alarm_name = "orders-anomaly"
  comparison_operator = "LessThanLowerOrGreaterThanUpperThreshold"
  evaluation_periods = 2
  threshold_metric_id = "e1"

  metric_query {
    id = "e1"
    expression = "ANOMALY_DETECTION_BAND(m1, 2)"
    return_data = true
  }

  metric_query {
    id = "m1"
    return_data = false

    metric {
      metric_name = "OrdersCompleted"
      namespace = "MyApp/Business"
      period = 300
      stat = "Sum"
    }
  }
}

ניתוב התראות עסקיות

התראות עסקיות לא אמורות להעיר מפתחים בלילה. אנו מגדירים ניתוב דרך Alertmanager: התראות עם תווית team=business ו-severity=critical נשלחות ל-Slack, בעוד ש-PaymentErrorRateHigh נשלחת ל-PagerDuty, מכיוון שזו בעיה טכנית.

---
routes:
  - match:
      team: business
      severity: critical
    receiver: business-slack
  - match:
      team: business
      alertname: PaymentErrorRateHigh
    receiver: pagerduty-oncall

מדוע התראות עסקיות מייצרות התראות שווא? כיצד לתקן

התראות שווא הן כאב הראש העיקרי של הניטור. הן גורמות לכם להתעלם מאזהרות. כמה כללים:

• השתמשו בזיהוי חריגות במקום ספים קבועים עבור מדדים עם עונתיות.
• הוסיפו חלונות זמן "for" (למשל, 5 דקות) — קפיצות קצרות טווח לא יפעילו התראה.
• עבור התראות לא קריטיות (המרה ירדה ב-10%), השתמשו בעדיפות נמוכה כדי לא להעמיס על האחראים.
• בחנו באופן קבוע התראות על בסיס נתונים היסטוריים והשביתו התראות מיותרות.

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

• אינסטרומנטציה לקוד עם מדדים (2–4 ימים)
• הגדרת חוקי התראה וניתוב (1–2 ימים)
• זיהוי חריגות למדדים עונתיים (יום אחד)
• לוח מחוונים עסקי ב-Grafana (1–2 ימים)
• תיעוד על מדדים והתראות
• הדרכת צוות על התראות עסקיות
• תמיכה לאחר פריסה: 30 ימי ליווי

תהליך העבודה

1. אנליטיקה — הגדרת מדדים עסקיים וקו הבסיס שלהם, בחירת הכלי (Prometheus, CloudWatch או אחר)
2. אינסטרומנטציה — הוספת מדדים לקוד, הגדרת ייצוא
3. חוקי התראה — כתיבת חוקים תוך התחשבות בעונתיות ובעדיפויות עסקיות
4. ניתוב — הגדרת הודעות לצוותים שונים ולשעות שונות ביום
5. לוח מחוונים — יצירת לוח מחוונים עסקי ב-Grafana עם גישת קריאה בלבד למנכ"ל
6. בדיקה ופריסה — בדיקת התראות על נתונים היסטוריים, פריסה לייצור

לוחות זמנים ליישום

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