ההנדסה, מוקד השירות, הכספים והדוברות בחברת דיור ציבורי ארצית עובדים היום מתוך אפליקציית ווב אחת בעברית. פייפליין יומי הופך את נתוני ה־ERP לחריגות מדורגות, לדוחות נכס שנכתבים ב־AI ולתורי בדיקה. כל החלטה של המשתמשים נשמרת בבטחה בין רפליקות, מאחורי הזדהות ארגונית.
החברה מתחזקת תיק גדול מאוד של דירות ובניינים. קריאות שירות, פרויקטים של קבלנים, ביקורי מפקחים, מחירונים, היסטוריית שירות לדיירים וחשבונות חשמל יושבים כולם בטבלאות ERP שונות. כדי לזהות קבלן שתמיד מאחר, בניין עם תקלות חוזרות, פרויקט שהכמויות בו לא מסתדרות או דירה ריקה שעדיין צורכת חשמל, אנליסטים היו צריכים למשוך דוחות ולעבור עליהם ידנית. לכל מחלקה היו הרגלי אקסל משלה, ולא היה תיעוד משותף של מה כבר נבדק.
התרשים רחב מהמסך: החליקו הצידה לצפייה בכולו →
ל־backend אסור לייבא טוענים של נתונים גולמיים או לקרוא snapshots של ה־ERP, וטסט אוכף את זה. כך כל בקשה נשארת בתוך קונטיינר של 2 GiB, וזמן התגובה לא תלוי בגודל ה־ERP. האחסון מחולק לפי בעלות: הפייפליין הוא הבעלים של מה שהוא מחשב, והאפליקציה היא הבעלים של מה שאנשים מחליטים. הרצה חוזרת של הפייפליין אף פעם לא מוחקת בדיקה.
כל ה־joins, הפיצ׳רים והדירוג רצים ב־job הלילי, עם 4 ליבות ו־28 GiB זיכרון. ה־API קורא קובצי parquet שמחולקים ל־300 דליים לפי hash, עם cache של 5 דקות ותקרה של 32 דליים. המחיר: הנתונים טריים רק כמו ההרצה האחרונה, ולכן כל הרצה כותבת manifest שמראה כמה הם עדכניים.
מצב הבדיקה הוא כמה מסמכי JSON קטנים. במקום להוסיף בסיס נתונים, כל כתיבה משותפת עוברת דרך helper אחד: קורא עם ETag, מחיל את השינוי, כותב רק אם אף אחד לא שינה בינתיים, ומנסה עד 3 פעמים. המחיר: בעומס כבד מתקבל 503 נקי במקום תור.
באפליקציה אין קוד התחברות. הזדהות Entra ID מסוג Easy Auth מגינה על ה־frontend, הדפדפן מדבר רק עם proxy באותו origin, וה־backend סומך על כותרות הזהות רק כי אין לו ingress ציבורי. המחיר: הרשאות לפי משתמש מנוהלות בקבוצות Entra ולא באפליקציה.
קריאות ה־LLM מחזירות פלט מובנה, מאומת ובעל גרסה. הדירוגים והערכות ה־AI מוצגים כעדיפות לבדיקה ולא כהוכחה לאשמה. תשובות לפניות תקשורת עוברות טיוטה ואז אישור לפי תפקידים. המחיר: איטי יותר מפרסום אוטומטי, אבל לכל תוצאה יש בעלים.
ה־images מתויגים ב־SHA של הקומיט. prod רץ רק מ־master ואחרי אישור, וכל פריסה מחכה עד שהגרסה החדשה מדווחת שהיא תקינה (עד 40 בדיקות בהפרש של 15 שניות). המחיר: כמה דקות נוספות לכל פריסה, ובתמורה rollback בצעד אחד.
שינוי סטטוס של שורה קרא את קובץ הבדיקות של התרחיש, שינה מפתח אחד ושמר. אם הקריאה נכשלה מכל סיבה שהיא, הקוד הניח שעדיין אין בדיקות ושמר קובץ כמעט ריק מעל כולן.
רק 404 אמיתי מתחיל מקובץ ריק. כל שגיאת קריאה אחרת עוצרת את הפעולה ושום דבר לא נכתב. הכתיבה מותנית בגרסה שנקראה, והממשק מציג את הבודק שהשרת שמר בפועל.
ב־prod רצות לפחות 2 רפליקות של ה־backend. עדכוני מדרג השיפוץ, מנויי ההתראות ואישורי המחירון נכתבו בשיטת read-modify-write בלי בדיקת גרסה, כך ששתי שמירות כמעט בו־זמניות השאירו רק את המאוחרת.
helper משותף אחד מבצע כתיבה מותנית ETag ומחיל את השינוי מחדש על הנתונים העדכניים. טסט גבול מכשיל את ה־build אם קוד חדש כותב JSON משותף בדרך אחרת.
הדפדפן פנה ישירות לכתובת הציבורית של ה־backend. הזדהות שמגינה רק על ה־frontend הייתה משאירה את ה־API פתוח.
קריאות ה־API עוברות עכשיו ל־rewrite באותו origin (/backend-api) שנאפה לתוך ה־build. ה־ingress של ה־backend הפך לפנימי, וכותרות הזהות נאמנות רק מאחורי הגבול הזה. שם המשתמש בכותרת מגיע עכשיו מה־backend, ולא מקריאה של הדפדפן שנכשלה מאחורי ה־proxy.
ה־builds הראשונים ב־Azure DevOps נכשלו על נתיב Dockerfile שגוי ועל agent שלא היה מקובע לגרסה. בנוסף, קונטיינר תקין יכול היה להסתיר frontend שנבנה עם חיווט API שגוי.
קיבעתי את ה־agent ל־Ubuntu 24.04, איחדתי סקריפט build-and-deploy אחד לכל הרכיבים, נתתי לכל revision סיומת ייחודית, הוספתי המתנה לתקינות ובדיקה של הגדרות ה־API בתוך ה־build הארוז.
הסביבות הקיימות נוהלו ממחשב של מפתח, בלי plan שעבר בדיקה.
הרצות plan בלבד מפרסמות artifact עם סיכום. ה־apply דורש אישור סביבה ורץ רק מ־master. הרשאת admin ל־Key Vault קובעה, כדי שה־plans יפסיקו להציג drift מדומה.
ההרצה היומית בוחרת את 20 הנכסים ו־13 הבניינים המובילים לדוחות AI, בקצב של בקשה אחת לדקה כדי לעמוד במכסה.
לכל דוח יש טביעת אצבע של כל הראיות שלו: קריאות, ממצאים, הערות וכספים. אם הראיות לא השתנו, הדוח השמור משמש שוב. יצירה מחדש בהיקף גדול נעצרת אם אין לה אישור מפורש, וכל ה־workers חולקים את זמני ההמתנה של Retry-After.
רפליקה A ורפליקה B מטפלות שתיהן בשמירה לאותו קובץ בדיקות.
המחשה של פרוטוקול הכתיבה. בלי נתוני לקוח.
מודול החשמל עולה כבוי עד שה־worker של המפעיל ונתוני הפרודקשן יהיו מוכנים. טעינה חוזרת שלו נמדדה ב־41.8 שניות, עם שיא של 696 MiB, בתוך מגבלת ה־2 GiB של ה־backend.
שיחת אבחון חינם · 30 דקות · ללא התחייבות
כתבו בכמה שורות: איזה תהליך או מערכת, מה כואב היום (זמן, טעויות, עלויות או פיילוט AI שנתקע) ומי עובד עם זה. אחרי שיחה קצרה מקבלים תוך כ־3 ימים תוכנית כתובה והצעת מחיר סגורה.
נפתח מייל מוכן מראש · מענה תוך יום עסקים
ה־AI קורא. הקוד סופר.
כל הפרויקטים