הגדרת התראות למדדי יציבות של אפליקציית מובייל

תארו לעצמכם: אפליקציית המובייל שלכם אחרי שחרור גרסה חדשה מתחילה לאבד משתמשים, אבל אתם מגלים על כך רק 4 שעות לאחר מכן, כשכבר יש מאות פניות לתמיכה. הבעיה אינה חוסר בנתונים – מדדי יציבות נאספים, אבל התראות או שאינן מוגדרות או שיוצרות מבול של אזעקות שווא. עבור מצבים כאלה אנו מגדירים התראות המבוססות על מדדי יציבות של אפליקציות מובייל: שיעור משתמשים ללא קריסות (Crash-Free Users Rate), שיעור ANR, סיום תהליך על ידי מערכת (Watchdog Termination) ועוד. כל אות שמוגדר מצביע על הידרדרות אמיתית ודורש פעולה. בניסיון שלנו, ביצענו ביקורת והגדרנו ניטור עבור יותר מ-30 אפליקציות מובייל ב-iOS ואנדרואיד – מחברות סטארטאפ ועד חברות פינטק עם 2 מיליון משתמשים.

אילו מדדי יציבות דורשים התראות ומהם הספים שלהם?

שיעור משתמשים ללא קריסות (Crash-Free Users Rate) – אחוז המשתמשים ללא קריסות בתקופה נתונה. Google Play Console מגדיר אפליקציה גרועה ככזו עם יותר מ-1.09% קריסות לכל סשן. Apple ממליצה על יותר מ-99% משתמשים ללא קריסות. חשוב לחשב לפי משתמשים ייחודיים, לא לפי סשנים.

שיעור ANR (אנדרואיד) – מספר מקרי ANR לכל 1000 משתמשים ליום. סף גרוע: יותר מ-0.47% שיעור ANR, לפי ההנחיות של Google Play Console.

שיעור סיום תהליך על ידי מערכת (iOS) – חלק מהסשנים עם סיום תהליך על ידי מערכת. מדד טוב הוא פחות מ-0.1%.

שיעור תקיעת אפליקציה (iOS) – סשנים שבהם הממשק תקוע יותר מ-250 אלפיות השנייה. לעיון מהיר, השתמשו בטבלת הספים:

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

מדוע נרמול לפי סשנים הוא חובה?

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

כיצד התראה על קצב שינוי מפחיתה רעשי התראות?

התראה על קצב שינוי מופעלת בעקבות שינוי חד במדד (לדוגמה, עלייה של 0.5% באחוז הקריסות לשעה), ולא על חריגה מסף מוחלט. זה מפחית רעשי התראות ואזעקות שווא. בשילוב עם נרמול לפי סשנים, מקבלים מערכת אמינה שמאותתת רק על בעיות אמיתיות.

מקרה אמיתי: הגדרת התראות לאפליקציית פינטק

מהניסיון שלנו: אפליקציית פינטק עם 2 מיליון משתמשים. שיעור המשתמשים ללא קריסות עמד על 98%, אבל הצוות לא הבחין בהידרדרות במכשירים ספציפיים. לאחר ביקורת, גילינו שההתראה הוגדרה על מספר מוחלט של קריסות – 500 ליום. כשהקהל גדל ב-30%, ההתראה הופעלה כל שעתיים, והם כיבו אותה.

הגדרנו מחדש את המערכת: הגדרנו התראה על קצב שינוי בעלייה של יותר מ-0.5% באחוז הקריסות לשעה, הוספנו נרמול לפי סשנים, והגדרנו שתי רמות חומרה. לאחר שבוע, הצוות קיבל בדיוק 3 התראות, כל אחת דרשה פעולה: באג אמיתי אחד בגרסה החדשה, שתי אזעקות שווא מתעבורת בדיקות. סיננו מכשירי בדיקה לפי User-Agent, והאותות הכוזבים נעלמו.

תוצאה: זמן התגובה לאירוע ירד מ-4 שעות ל-30 דקות, ויציבות האפליקציה עלתה ל-99.5% משתמשים ללא קריסות. הגדרת התראות על קצב שינוי הפחיתה רעשי התראות והגבירה את האמון במערכת ההתראות. אם אתם רוצים מערכת כזו, צרו קשר לצורך ביקורת.

כיצד להגדיר התראות בשירותים פופולריים: מדריך שלב אחר שלב

Firebase Crashlytics

// Firebase Alert Webhook (настраивается в консоли Firebase)
// При velocity alert — POST на ваш endpoint
// Пример payload от Firebase:
// {
//   "type": "crashlytics.velocityAlert",
//   "data": {
//     "issue": {
//       "id": "issue_id",
//       "title": "Fatal Exception: java.lang.NullPointerException",
//       "crashPercentage": 2.3,
//       "firstVersion": "2.1.0",
//       "latestVersion": "2.3.1"
//     }
//   }
// }

התראה על קצב שינוי מופעלת בעקבות עלייה חדה באחוז הסשנים המושפעים. הגדרת הסף מתבצעת ב-Firebase Console.

Sentry עם בדיקת CRON

# Sentry API — создание Monitor через REST
import requests

response = requests.post(
    "https://sentry.io/api/0/organizations/YOUR_ORG/monitors/",
    headers={"Authorization": "Bearer YOUR_TOKEN"},
    json={
        "name": "Crash-Free Rate Drop",
        "type": "cron_job",
        "config": {
            "schedule_type": "interval",
            "schedule": [1, "hour"]
        }
    }
)

אבל קל יותר דרך הממשק: // Firebase Alert Webhook (настраивается в консоли Firebase) // При velocity alert — POST на ваш endpoint // Пример payload от Firebase: { "type": "crashlytics.velocityAlert", "data": { "issue": { "id": "issue_id", "title": "Fatal Exception: java.lang.NullPointerException", "crashPercentage": 2.3, "firstVersion": "2.1.0", "latestVersion": "2.3.1" } } } . תנאי: # Sentry API — создание Monitor через REST import requests response = requests.post( "https://sentry.io/api/0/organizations/YOUR_ORG/monitors/", headers={"Authorization": "Bearer YOUR_TOKEN"}, json={ "name": "Crash-Free Rate Drop", "type": "cron_job", "config": { "schedule_type": "interval", "schedule": [1, "hour"] } } ) בשעה אחת. פעולה: הודעה ל-Slack Issues → Alerts → New Alert Rule.

Datadog המבוסס על מדדי RUM

# Datadog Monitor query (Metric Alert)
rum(mobile,*).crash_count{env:production,service:ios-app}.rollup(sum, 3600)
# Условие: > 100 крэшей в час → CRITICAL
# > 50 крэшей в час → WARNING

עבור שיעור משתמשים ללא קריסות:

# Вычисляемая метрика в Datadog
(1 - (sum:rum.crash_count{service:ios-app} / sum:rum.session_count{service:ios-app})) * 100
# Алерт: если < 99% → WARNING, < 98% → CRITICAL

ניתוב התראות

---
# PagerDuty + Alertmanager (для Prometheus-based мониторинга)
route:
  group_by: ['service', 'platform']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
        service: mobile
      receiver: pagerduty-mobile-oncall
    - match:
        severity: warning
        service: mobile
      receiver: slack-mobile-channel
receivers:
  - name: pagerduty-mobile-oncall
    pagerduty_configs:
      - service_key: YOUR_PD_SERVICE_KEY
  - name: slack-mobile-channel
    slack_configs:
      - api_url: YOUR_SLACK_WEBHOOK
        channel: '#mobile-stability'

מה כוללת עבודת הגדרת ההתראות

• ניתוח מדדי יציבות קיימים וזיהוי אזורים בעייתיים.
• הגדרת התראות על קצב שינוי ב-Crashlytics, Sentry, Datadog עבור המחסנית שלכם.
• הגדרת ערוצי הודעות (Slack, PagerDuty, Telegram) עם הבחנה לפי חומרה.
• כתיבת runbook לכל סוג התראה: מה לעשות כשהיא מופעלת.
• הדרכת הצוות על מערכת הניטור.
• תמיכה למשך שבועיים לאחר ההשקה – התאמת ספים וטיפול באירועים.

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

הגדרת התראות בסיסית בשירות אחד – מ-4 שעות. אינטגרציה מלאה עם ניתוב ותיעוד – 1–2 ימים. העלות מחושבת באופן אישי לפי המחסנית והיקף העבודה.

טעויות נפוצות בהגדרת התראות

• סף אחד לכל הגרסאות. גרסה חדשה עם קהל קטן עשויה להיות עם שיעור קריסות גבוה שאינו מובהק סטטיסטית. הוסיפו תנאי Number of users affected > 50 לפני הבדיקה.
• ללא התראה על שיפור. אם שיעור המשתמשים ללא קריסות עולה בחדות, ייתכן שמדובר בתיקון חם מוצלח. התראות דו-כיווניות עוזרות להעריך את השפעת השחרור.
• התעלמות ממדדי רקע (ANR, Watchdog). המשתמש אולי לא רואה קריסה, אבל איכות העבודה נפגעת.

לבחירת כלי, השתמשו בטבלת ההשוואה:

צרו קשר כדי להזמין ביקורת יציבות לאפליקציה שלכם. אנו מבטיחים הגדרת התראות שקופה שלא תיצור רעש. המהנדסים שלנו הם מפתחים מוסמכים של Apple ו-Google עם ניסיון רב שנים. קבלו ייעוץ – נעריך את הפרויקט שלכם ונציע פתרון אופטימלי.