מקור: EMC

מידע זה שם המשחק: הצצה לצוות ה-Data Science as a Service של EMC

את חברת EMC אין צורך באמת להציג. מדובר על אחת החברות הגדולות ביותר בעולם המתמחה באספקת מוצרים, שירותים ופתרונות בתחום אחסון וניהול מידע. החברה, שהייתה מחלוצות פארק ההייטק בבאר שבע, הקימה במרכז המחקר והפיתוח הדרומי שלה צוות Data Science as a Service העמל על מגוון רחב של פיתוחים. צוות זה מיישם טכניקות רבות בתחום ה-Machine learning ואף רותם אותן בכדי לפתח מוצרים מסקרנים במיוחד. קיימתי ראיון עם אושרי בן הרוש, Senior Manager ו-Data Scientist בחברת EMC, שהסביר לי על הצוות כולו ועל האתגרים עמם הם מתמודדים.

"הקבוצה שלנו נקראת Data Science as a Service וכשמה כן היא. אנחנו בעצם מספקים שירותי Data Science ליחידות עסקיות שונות ב-EMC וגם ללקוחות חיצוניים. הקבוצה הוקמה לפני 4.5 שנים כסטארטאפ פנימי בתוך EMC עצמה. הרעיון היה ש-EMC כארגון, הדומה לכל הארגונים האחרים, מתמודד עם בעיות שהן Data driven שכדאי לשם עליהן דגש ולנסות לתת להן מענה." הסביר בן הרוש. "לכן, החלטנו להקים צוות שיספק את השירותים האלה תחילה פנימה: כלומר הצוות יתחיל לפתור את הבעיות העסקיות של EMC תחת ההבנה שבעיות עסקיות של EMC יעניינו מאוד את הלקוחות של EMC. לאחר מכן נוכל לשלב את הפתרונות האלה במסגרת המוצרים שאנחנו יכולים להציע ללקוחות."

האתגר הראשון

הצוות שהוקם, אשר כלל בזמנו שני Data Scientists בלבד, החל לחפש את האתגרים המתאימים ביותר עבורו ופנה למספר חטיבות בתוך EMC בניסיון להבין את הקשיים שיש להם. לאחר לא מעט חיפושים מצא הצוות את המשימה המתאימה לו ביותר. "אחד הפרויקטים הראשונים שנתקלנו בהם הגיע דווקא מעולם ה-IT. המנהל האחראי על ה-Global Command Center ב-EMC, גוף האמון על ניטור ואופרציה של כל האפליקציות החיוניות לפעולה היומיומית ב EMC: מייילים, אקסציינג נטוורק ועוד, ביקש את עזרתנו. גוף זה כמובן מנטר בזמן אמת המון אפליקציות ושרתים ואחד האתגרים שלו היה לספק התראה מספיק מוקדמת לכישלונות במערכות ה-IT." פירט בן הרוש והוסיף: "הבקשה שלו הייתה מאוד ספציפית: לפתח מערכת שתאפשר לו יכולות ניטור טובות יותר מאשר המערכות המתקדמות הקיימות בחברה." סוגיה זו היא קלאסית לצוות חוקרים בעלי יכולות גבוהות של ניתוח מידע והם החליטו לקחת את הפרויקטים בשתי ידיים.

חשוב להדגיש כי הצוות לא היה מעוניין לבנות מערכת הפועלת באותן טכניקות הקיימות כיום, הכוללות הגדרת חוקים ומקרים יבשים מראש, אלא רצו לתקוף את הסוגיה מכיוון שונה. "בתהליך הלמידה התחלנו להביט ב-Data שמולנו והבנו שאפשר לפתח כאן משהו שהוא יותר מותאם לצרכים של מערכת ה-Exchange הספציפית שלנו. בנינו מודל סטטיסטי שמשתמש בניתוח של Time series modeling יחד עם Multidimensional statistics כי ניסינו לבנות פתרון שיכול לספק ללקוח שלושה יתרונות על פני מוצרים קיימים: 1. הבנה מעמיקה של ה-KPI-ים שאותם נצטרך לנטר. 2 מערכת אוטומטית לחלוטין בלי קונפיגורציה או חוקים שצריך לתחזק. 3 אלמנט שיעניק איזון לבין כמות האנשים שיכולים להגיב להתראות לכמות התראות שאנחנו מייצרים, זאת כדי שהמערכת תהייה אפקטיבית. היום איש ה-IT שם את הרף ההתראה ממש נמוך כדי לכסות את עצמו, אך האנשים שאמורים לטפל בבעיות פשוט לא עומדים בעומס אז כל דבר שלא קריטי מתעלמים ממנו." ציין בן הרוש.

"עשינו עבודה עם הגדרת ה-KPI באופן אוטומטי, אפשרנו לאלגוריתמי Machine Learning לזהות קורלציות ב-Multivariate statistics כדי לבנות הבנה עמוקה של מה הם ה-KPI-ים התואמים להתנהגות של המערכת." אמר בן הרוש. עם זאת, הצוות נתקל בראשית דרכו בבעיה משמעותית למדי: לא היה ברשותם מידע מקוטלג. "בהתחלה נסינו לבנות משהו שהוא Supervised אך מהר מאוד הבנו שהמערכות מאוד אמינות, אחרת לא היו רוכשים אותן (ומספר האירועים בהם אבד השירות היו נמוכים). מה שעשינו היה בעצם להחליף גישה, כאשר בגישה החדשה השתמשנו ב-Anomaly detection. מכיוון שהמערכות תקינות ב-99.9 אחוז מהפעמים, אז אפשר להשתמש בהחלקה הסטטיסטית הזו כדי ללמוד מהעבר מהי בעצם התנהגות תקינה. אז השאלה היא איך עושים את זה בצורה שלוקחת בחשבון הרבה מאוד פרמטרים ובנוסף מתחשבת גם בחריגות שמקורן בהתנהגות שונה ברמה יומית, שבועית, רבעונית ועוד. היינו צריכים לבנות מנגנון שלוקח בחשבון Time series behavior וגם משלב הרבה התנהגויות שונות של המערכת שיכולות להיות בקורלציה מאוד גבוהה אחת לשנייה – וזה מה שבניניו הלכה למעשה."

מקור: EMC
מקור: EMC

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

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

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

חיזוי כישלונות בדיסקים

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

בן הרוש ממשיך: "התמקדנו בתחום ב-EMC שבו קיימת הרבה טלמטריה. כל דיסק מספק מידע אודות תקינותו במגוון רחב של פרמטרים ולכך הוספנו גם את המידע המתקבל ממערכת ההפעלה עצמה. לקחנו את הנתונים האלה מ-EMC ואליהם צרפנו מידע שחברות חיצוניות שחררו כ-Open source וזאת כדי לוודא שאנחנו עובדים עם מידע שרלוונטי לתעשייה. הצלחנו, באמצעות שימוש במידע של חברה בשם BACKBLAZE, לחזות ברמת דיוק של 83 אחוזים, 14 יום מראש, כי דיסק עומד להיכשל. גם כאן מתעורר קושי בהיבטי Machine Learning, הרי שברוב הזמן הדיסקים תקינים. אם אחוז התראות השווא יעמוד על אחוז אחד, אז אם יש מיליון דיסקים, אז זה אומר שצריך להחליף עשר אלף דיסקים לחינם. זו נקודה קריטית שיש להעניק לה דגש: הגענו לרמת דיוק סביב מאית האחוז בכל הקשור להתראות שווא."

EMC
מקור: EMC

גם כאן, כפי שבוודאי אפשר לנחש, למידה חישובית היא חלק מאוד משמעותי מהפתרון הכולל: "תהליך ה-Machine Learning בא לידי ביטוי באמצעות Feature engineering – השאלה הגדולה היא אם אתה מצליח ליצור את המאפיינים האינפורמטיביים, מאחר ולמדנו שהפיצ'רים בפני עצמם לא בהכרח מאוד מעניינים. דוגמא: נניח שאנחנו נתבונן על פיצ'ר הסופר את כמות השגיאות. אם נתסכל בצורה יבשה על המספר, לשם ההנחה 300 אלף שגיאות, הפיצ'ר הזה בפני עצמו לא מאוד אינפורמטיבי מאחר וישנה אפשרות שה-300 אלף שגיאות גדלו באופן הדרגתי במהלך השבוע האחרון. החכמה היא לזהות שיש כאן טרנד, ה-Off set מאוד חשוב, ה-Difference מאוד חשוב – יש כאן המון עבודה על Feature engineering." ציין בן הרוש.

EMC DS

הצוות כולל כיום תשעה Data Scientist המתמחים בתחומי פעילות רבים ושונים. בן הרוש סיפר כי הם מחפשים בדרך קבע עוד אנשים מוכשרים שיוכלו להצטרף לצוות כדי לסייע להם לפצח אתגרים נוספים. "Data Scientist עם הבנה טובה מאוד של החומר התיאורטי, עם יכולת קידוד ברמה גבוהה וכישורי תקשורת טובים מאוד הנדרשים לעיתים לשם הסבר של מושגים או פתרונות מורכבים בצורה ברורה ומובנת בסיטואציות עסקיות מורכבות, הוא מצרך נדיר. האתגר הגדול ביותר של קבוצת ה Data Science הוא לאתר ולפתח את ההון האנושי. ההבנה הזו הובילה לכמה קווים מנחים קריטיים בבניית הקבוצה. לאחר שכבר יש קבוצה, אחד האתגרים המורכבים הם למצוא את מודל העבודה, השותפים והלקוחות המתאימים – מודל של נותני שירות בתשלום לעומת קבוצת פיתוח עסקי המזהה נקודות קריטיות בארגון שבהן יש להתמקד ייצרו אופן עבודה וחזון שונה שיוביל לבחירת שותפים ומיקוד בבעיות שונות בתכלית."