מערך שיעור: Alert Service

משך: 2 שעות אקדמיות (90 דקות), רובן עבודת צוותים.

מטרת השיעור: החברים האחראים על Alert בכל צוות יממשו BackgroundService עם Redis Deduplication.

בסוף השיעור: Alert Service עובד — צורך אנומליות, מונע כפילות, שולח התראות ברורות.

דגש קריטי: הדגישו את Alert Fatigue כבעיה אמיתית ומוכרת בתעשייה, לא רק “תכונה נחמדה”.

מהלך השיעור#

דגשים להעברת השיעור#

• ודאו שהצוותים בודקים אינטגרציה מלאה של 3 השירותים (Collector→Analyzer→Alert) בשלב מוקדם בשיעור — זה הרגע שכל התכנון “מתגשם” בפועל.
• Deduplication בכיוון הפוך מ-Cache-Aside שווה הבהרה מפורשת — קל להתבלבל בין “בדיקה כדי לחסוך חישוב” ל"בדיקה כדי למנוע פעולה כפולה".
• Alert Fatigue שווה דיון קצר עם דוגמאות מהחיים (התראות אפליקציה שמתעלמים מהן) — עוזר לסטודנטים להבין שזו לא רק “עוד פיצ’ר” אלא שיקול עיצוב אמיתי.

מושגים#

Deduplication — מניעת פעולה כפולה על אותו אירוע. BackgroundService — דפוס לצריכה רציפה ברקע. Alert Fatigue — הצפת התראות שגורמת להתעלמות.

תרגיל חשיבה#

שאלת פתיחה: “בעבודה אמיתית, כמה פעמים קיבלתם (או שמעתם על) התראה חוזרת-ונשנית עד שפשוט התעלמתם ממנה — גם כשהיא הייתה חשובה?”

מהלך: תנו לסטודנטים לשתף חוויות (גם מחיי היומיום — אפליקציות, מייל). הובילו לתובנה: Alert Fatigue הוא לא בעיה תיאורטית — היא הסיבה שמערכות production אמיתיות משקיעות מאמץ רב ב-Deduplication ו-Rate Limiting על התראות, בדיוק כמו מה שבונים עכשיו.

מה המרצה מראה בסוף: הריצו את שלושת השירותים (Collector→Analyzer→Alert) עם רצף ערכים חריגים ממושך — הראו שרק התראה אחת נשלחת (לא אחת לכל אירוע חריג), ואז המתינו ל-TTL וחזרו על התרחיש — התראה נוספת אחת. ההדגמה החיה מוכיחה שהDeduplication עובד בפועל, לא רק בתיאוריה.