איך הפכנו את סלאק למערכת התראות עסקיות מבוססות דאטה?
אורלי הופרט
VP Data At Travelier (formerly Bookaway Group)
אין ויכוח שדשבורדים יעילים ומאפשרים שקיפות למדדי החברה אבל לעיתים מורכב לזהות שינויים בזמן אמת ויכול להיות לזה מחיר כבד.
כולנו מכירים את המשתמשים שמרעננים דשבורדים שוב ושוב באובססיביות לצד אנליסטים אשר מזהים בעיה או שינוי מגמה ראשוני אך רק באיחור של כמה ימים מתחילים להבין לעומק את מקור ההשפעה והשינוי. הדבר מייצר תחושת החמצה ולרב עולה לחברות הרבה מאוד כסף שלא לדבר על בזבוז זמן של צוותי ניתוח.
אנחנו ב-Travelier מאמינים בדמוקרטיזציה של דאטה. צוות ה-Data Engineering וה-BI אחראים לספק לאנליסטים ולמשתמשים העסקיים בכל הדומיינים וחברות הבת גישה מלאה לדאטה על מנת לקבל החלטות מדויקות ובזמן אמת. גילינו כי רוב המשתמשים ייגשו לדאטה בממוצע פעם ביום, לפעמים גם פעם ביום וחצי. הדבר מייצר פער של עד 36 שעות בגישה למידע ברגעי אמת. בנוסף, חברות הבת שלנו פרוסות בכל העולם כך שגם אזורי זמן יכולים להוות אתגר זיהוי.
לאור ההבנה כי יש פער בין שעת השינוי/בעיה לבין נקודת זיהוי הבעיה ע״י המשתמש, החלטנו להרחיב את ארגז הכלים שאנו מציעים למשתמשים שלנו, קרי עובדי החברה.
היה לנו חשוב לייצר עבורם כלי המאפשר לקבל מידע באופן מיידי לצד היכולת להיות פרואקטיביים, יעילים ולהגיב במהירות ברגע שאירוע קורה.
בבלוג הזה אשתף איך בנינו מערכת התראות מבוססת דאטה על ה DWH שלנו, המאפשרת הגדרה מהירה וקלה של התראות הנשלחות ישירות בסלאק של בעליי העניין הרלוונטים.
את הכלי בנינו בעזרת ה stack הטכנולוגי הקיים שלנו (Airflow, Python, BigQuery) ולהלן הפרמטרים שהגדרנו:
- קלות שימוש הגדרה וניהול של התראות בצורה קלה ב google sheet בעזרת ידע ב SQL בלבד ללא צורך בתמיכה של מפתחים
- רלוונטיות
- התראות לסביבת התקשורת הטבעית של היוזרים שלנו (AKA Slack) עם אפשרות להגדיר ערוץ ספציפי ביצירת ההתראה כך שיוזרים יירשמו רק להתראות הרלוונטיות להם
- כל המידע בסלאק בלי צורך להוריד קבצים או לעבור בלינק לדשבורד
- גמישות
- אין הגבלה על סוגי ההתראות, כל התראה שניתן לתרגם לשאילתא ניתנת למימוש, מערכי סף בהם שאילתא ללא תוצאות לא תשלח כהתראה ועד אנומליות בדאטה ובדיקות נכונות נתונים.
בבלוג הזה אנסה לשתף בקוד פרקטי שיעזור לכם לבנות כלי כזה בעצמכם, בקלות ומהירות עם ערך מיידי מובטח.
אז איך זה עובד?
לתיאור הארכיטקטורה אעבור לאנגלית למען הימנעות מתרגום קלוקל .
The system reads data received from the user through a google sheets file, uploads it to BigQuery, runs logic, outputs alerts to Slack and monitors it on a BI report.
- Google sheets file: Contains the alert configuration metadata, accessible by users to add/modify tests.
- BigQuery external table: BigQuery replication of the google sheets configuration file
- AirFlow DAG - the DAG generates 3 tasks:Queries the BQ external table, looks for tests that should be triggered on the next interval and pushes it to a table in BigQuery.Triggers a Python script which executes the tests logic as received by the user and sends alert to Slack if necessary.Save run statistics data to an audit table in BigQuery
- Reportsto monitor alerts and track usage
אז איך זה נראה?
הרי התראה לדוגמא היישר מהסלאק והשיח המיידי בין בעלי העניין:
עוד כמה טיפים:
- תערבו בתהליך את המשתמשים, אנליטסים ויוזרים עסקיים. אצלנו מי שהובילה את היוזמה הייתה האנליסטית של הקבוצה שהגדירה את הצרכים של הכלי והתבססה על כאבים יומיומיים
- אספו פידבק ממשתמשים לאורך כל הדרך שיסייע לדייק את התוצר
- לא לוותר על ערוצים שונים בסלאק לפי קבוצות עניין. כשמשתמשים מקבלים יותר מידי הודעות לא רלוונטיות הם לא נשארים דרוכים להתראות אמת
- תבדקו התראות חדשות על דטה היסטורי, תראו שבחרתם לוגיקות מדוייקות או ערך סף נכון שיציפו רק את התוצאות הממוקדות שקוראות לפעולה
לסיכום
עם הרבה יוזמה וקצת קוד מערכת ההתראות שבנינו מביאה ערך חדש וגדול למשתמשים שלנו. הוספת התראה חדשה היא קלה ומהירה מתבצעת על ידי האנליסטים שלנו ללא עזרה של מפתחים.
הזדמנויות ובעיות חדשות שמתעוררות הופכות במהרה להתראות מניבות.
הצלחנו להוריד את הזמן לאיתור שינוי מממוצע של 28 שעות ל 35 דקות. מספק לראות את התקשורת המיידית בין בעלי העניין בסלאק על התראה שנשלחת והמהירות של הטיפול.
בהמשך נרצה לשפר את הויזואליזציה של התוצאות ואנחנו מתכננים למדוד את שביעות הרצון של המשתמשים שלנו בסקר וגם לשמוע מהם הצעות לשיפור.
בהמשך יש פירוט של מבנה קובץ ה metadata ושיתוף של הקוד מקווה שעזרנו לכל מי שירצה לפתח כלי כזה, מוזמנים גם לפנות ולהתייעץ.
ועכשיו נרד לפרטים:
שדות הקונפיגורציה בקובץ הגדרת ההתראות:
Values
Description
Column Name
test indicator
test_id
slack user name to allow personal tagging
test_owner_name
slack user id
test_owner_id
SQL test code - the output (if exists) will be pushed to slack
query
{0,1}
Indicator for incremental type alerts
increment_test
{day,hour}
Frequency interval value for alerts scheduling
frequency_interval
integer
Units of time for frequency interval
frequency_units_of_time
TIMESTAMP_ADD(TIMESTAMP, INTERVAL history_time_value day, day)
The time parameter value for increment alerts
history_time_value
TIMESTAMP_ADD(TIMESTAMP, INTERVAL 1 history_units_of_time)
The time units value for increment alerts
history_units_of_time
alert active status
test_status
Optional, customize slack message
slack_message
בניית טבלת stage לריצה בזמן אמת:
שליפה מטבלת ה meatadata של ההתראות ויצירת טבלת הטסטים להרצה בהתאם לנקודת זמן הריצה
פייתון סקריפט להרצת הטסטים:
הרצת כל טסט מטבלת הקונפיגורציות ושליחת ההתראה במידה וקיימת לערוץ הסלאק הרלוונטי. הסטטיסטיקות כמו משך זמן הריצה, שגיאות וכו׳ נרשמות לטבלת audit נפרדת.
לשם כך ניצור מחלקה בשם DataAlertsHandler:
במחלקה זו הפונקציה run_data_alertsתנהל את הפעולות השונות לצורך טעינת קונפיגורציות ההתראות, הרצתן ושליחת התראה במידת הצורך:
ראשית נטען את הקונפיגורציה המתאימה באמצעות הפונקציה load_test_configuration:
כחלק מהטעינת הקונפיגורציה, נפנה ל DWH שלנו בbigQuery לשם משיכת הקונפיגורציה באמצעות
נריץ את הבדיקות ובמידה ואותרה במהלך הרצת הבדיקה אנומליה, נוציא התראה מתאימה דרך ערוץ הסלאק הרלוונטי באמצעות קריאה לפונקציה הבאה:
לבסוף נכתוב לטבלת audit את תוצאות ההרצה (גם במידה ולא אותרו אנומליות):
