מתכנני חירום בחברה ישראלית לחוסן תשתיות קריטיות יכולים היום לטעון קטלוג נכסים ארצי, להפעיל עליו תרחיש כשל ולראות איך ההשפעה מתפשטת ברשת בצעדים של 15 דקות. הם רואים אילו תחנות משנה, צנרת ולקוחות מאבדים אספקה, לכמה זמן, ולמה.
הלקוח ממדל איך אירוע חירום לאומי, למשל רעידת אדמה או פגיעה במתקן, מתפשט בתשתיות הקריטיות. חומרי הגלם היו גיליונות אקסל, אחד לכל סוג נכס ומגזר, וכל אחד עם עמודות משלו. הקואורדינטות הגיעו בשלושה פורמטים, הגאומטריה של המפה הגיעה בקובצי KMZ, ולא היה מודל של איזה נכס מזין את מי.
כדי לענות על שאלה כמו ”אם השנאי הזה מאבד 40% מהקיבולת ב־08:15, אילו לקוחות נשארים בלי חשמל ומתי הם חוזרים?” היה צריך לחשב ידנית מתוך קבצים מנותקים.
התרשים רחב מהמסך: החליקו הצידה לצפייה בכולו →
פלט ה־ETL נוחת קודם בבסיס נתונים נפרד של staging. שום נתון לא מגיע לקטלוג שהסימולציה קוראת לפני שעבר ולידציה וסנכרון טרנזקציוני. הסימולציה טוענת את גרף הנכסים לזיכרון פעם אחת, וכותבת תוצאות באצווה אחת לכל צעד.
זו רשת קטנה סינתטית שפועלת לפי הכללים של המנוע. אף שם, ערך או טופולוגיה לא לקוחים מהלקוח. בחרו צעד כדי לראות מה המנוע משנה ואילו אירועי המשך הוא מתזמן.
Talend כותב לבסיס נתונים נפרד משלו. פרוצדורה אחת מריצה 20 סנכרוני MERGE, אחד לכל סוג, בתוך טרנזקציה אחת. אם הרענון נכשל, הקטלוג נשאר בדיוק כמו שהיה. המחיר: עותק שני של 57 טבלאות הקטלוג, שצריך לשמור מתואם עם הסכמה הראשית.
לגנרטורים, שנאים, קווים, צרכנים ונכסי גז יש מחלקת אסטרטגיה משלהם מאחורי ממשק אחד, וברירת מחדל לסוגים שעוד לא מודלו. הוספת מגזר הגז דרשה אסטרטגיה חדשה, לא שינוי במנוע. המחיר: הצימוד בין המגזרים ממודל דרך קשרי תלות, ולא דרך פותר פיזיקלי משותף.
בכל צעד המנוע ממיין את גרף הנכסים טופולוגית. מעבר הפוך דוחף את הביקוש במעלה הרשת, ומעבר קדמי דוחף את האספקה במורד. זה מהיר וקל להסביר למתכננים. המחיר: זה קירוב של ההתנהגות החשמלית ולא פתרון מלא של זרימת עומסים.
כשל עם זמן תיקון מתזמן את ההתאוששות שלו. הפעלת גנרטור מתזמנת ”עלה לאוויר” לפי זמן ההנעה, וצרכן על סוללה מתזמן את ההתרוקנות שלה. המתכננים כותבים רק את האירוע הראשון. המנוע בונה את ציר הזמן ושומר כל אירוע שהוא מייצר.
הגאומטריה של נקודות וקווים, וה־GeoJSON שלהן, מחושבות בזמן הסנכרון או העריכה ונשמרות על הנכס. בקשת מפה היא חיתוך מרחבי עם המלבן הנראה, ואחריו שרשור של ה־GeoJSON השמור. המחיר: כל מסלול עריכה חייב לחשב מחדש את הגאומטריה, ולכן זה יושב במתודה אחת בשירות.
לכל סוג נכס היו עמודות, יחידות וערכי בחירה משלו. ייבוא ו־API נפרדים לכל אחד לא היו מחזיקים.
בניתי שכבת קטלוג גנרית: קונטרולר ו־storage בסיסיים, כלי אחד לייבוא וייצוא אקסל ופרופיל מיפוי אחד. סוג נכס חדש דרש ישות ומיפוי, בלי צנרת חדשה.
ג׳ובי Talend הם סקריפטים עצמאיים. בקשת ווב הייתה צריכה להפעיל אותם, לחכות להם, ולא להשאיר תהליכים יתומים כשמישהו מבטל.
ה־API מפעיל כל ג׳וב כתהליך בן עם סקריפט הפעלה לפי מערכת ההפעלה, ממתין באופן אסינכרוני, והורג את כל עץ התהליכים בביטול. כשל במגזר אחד נרשם ללוג, ושאר המגזרים ממשיכים לרוץ.
בגיליונות המקור הופיעו מעלות־דקות־שניות, מעלות עם דקות עשרוניות ומעלות עשרוניות, מעורבבים.
שגרות ה־ETL ממירות את שלושתם למעלות עשרוניות ומאמתות אותם. ממרץ 2025, שורות שנכשלות בולידציה נכתבות לטבלת שורות פגומות עם הסיבה, כך שהג׳וב לא נעצר וגם לא מפיל אותן בשקט.
המפה הראשונה קראה קובץ GeoJSON סטטי. קווי מתח וצנרת אמיתיים הם פוליליינים עם הרבה קודקודים, והעיצוב של הקווים מקובץ המפה היה צריך לשרוד את הייבוא.
המרתי נקודות ופוליליינים לגאומטריה של SQL Server, שמרתי GeoJSON על כל נכס, והגשתי את המפה דרך שאילתת חיתוך עם חלון התצוגה. ייבוא KMZ מתאים נכסים לפי מזהה חיצוני, עם שליפה מרוכזת אחת ועדכון מרוכז אחד.
שאילתות קריאה גדולות עם כמה Includes נטענו ל־change tracker של EF, למרות ששום דבר לא נשמר.
העברתי את מסלולי הקריאה האלה ל־no-tracking עם identity resolution. ישויות קשורות לא משוכפלות, וזה בלי עלות המעקב.
הקלט שהשנאי צריך תלוי במה שהצרכנים במורד הרשת צריכים, אבל הפלט שלו תלוי במה שהאספקה במעלה הרשת מספקת. חישוב הנכסים בסדר שרירותי נתן תוצאות שהיו תלויות בסדר הזה.
גרסה 2 של המנוע ממיינת את הגרף טופולוגית ומריצה שני מעברים בכל צעד: הפוך לביקוש, קדמי לאספקה. האירועים מקובצים לפי נכס ומטופלים לפני החישוב מחדש.
ברשימת הריצות הצעד הנוכחי אף פעם לא השתווה לסך הצעדים, כך שריצות שהסתיימו נראו תקועות.
יישרתי את נוסחת ספירת הצעדים בין השירות למנוע. מעכשיו כל צעד שומר גם CPU, זיכרון וזמן שחלף, כך שאפשר להסביר ריצות איטיות.
המתכננים החזיקו את אירועי הכשל ואת אילוצי הנכסים בקבצים נפרדים, ולכן היה קל להגדיר ריצה לא עקבית.
ייבוא של חוברת אחת שמשלבת תרחיש ואילוצים, API של תוצאות לפי צעד, ותצוגות שרשרת (עץ, Sankey וגרף כוחות) שמראות איך כשל עובר ברשת.
| תחום | לפני | אחרי |
|---|---|---|
| רענון נתונים | גיליון לכל סוג, ג׳וב אחרי ג׳וב | פעולה אחת מריצה 40 ג׳ובים, סנכרון טרנזקציוני, גאומטריה וקשרים |
| שורות מקור פגומות | נדחות בלי תיעוד | נשמרות בטבלת שורות פגומות עם הסיבה |
| מפה | קובץ GeoJSON סטטי שעובד מראש | שאילתה חיה לפי חלון התצוגה על גאומטריה ב־SQL, תמיד מעודכנת מול הקטלוג |
| ייבוא KMZ | בגישה של נכס־נכס: כ־2 פניות לבסיס הנתונים לכל נכס | 2 פניות לקובץ: שליפה מרוכזת אחת ועדכון מרוכז אחד |
| ניתוח ”מה אם” | חישוב ידני מתוך קבצים מנותקים | צעדים של 15 דקות, 24 שעות ב־כ־1.6 דקות, תוצאות לכל נכס, שרשראות תלות וייצוא לאקסל |
| מסך ריצה חי | משיכה כל שנייה הייתה 60 קריאות סטטוס בדקה | 3 קריאות בדקה (כל 20 שניות, בקשות ישנות מבוטלות) ושעון מקומי של שנייה |
שיחת אבחון חינם · 30 דקות · ללא התחייבות
כתבו בכמה שורות: איזה תהליך או מערכת, מה כואב היום (זמן, טעויות, עלויות או פיילוט AI שנתקע) ומי עובד עם זה. אחרי שיחה קצרה מקבלים תוך כ־3 ימים תוכנית כתובה והצעת מחיר סגורה.
נפתח מייל מוכן מראש · מענה תוך יום עסקים
ה־AI קורא. הקוד סופר.
כל הפרויקטים