פלטפורמת White-Label AI: ריבוי דיירים והתאמה אישית

פלטפורמת White-label AI: איפה נשבר ריבוי הדיירים

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

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

עם חמישה לקוחות זה נסבל; עם העשרים, כל טעות בשאילתה חושפת הקשר של דייר אחר, הסרת דייר הופכת לניקוי ידני של טבלאות משותפות, והגיבוי נשאר משותף — החזרה לאחור משפיעה על כולם.

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

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

מה נותן מתאר ריבוי דיירים: מדדים מדידים לאחר ההשקה

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

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

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

אפשרויות בידוד דיירים: משותף, סגמנטי, ייעודי

בידוד נתוני דיירים הוא прежде всего про те, что физически разделено: סכימת מסד הנתונים, מתחם רשת, מפתחות הצפנה וענף עדכונים. מרמת הבידוד תלוי אם מזמין אחד יוכל לעבור ללוגיקה וממשק משלו בלי לשבור את מחזור השחרורים של האחרים.

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

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

שלבי הטמעה: מניתוח נתונים ועד מסירת הפלטפורמה

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

1. ביקורת נתונים. מפרקים מקורות, ישויות ומה שכרגע מסומן כבעלים באופן מרומז. בפלט — מפת נתונים: מה אפשר לאחד ומה אסור לערבב בשום תנאי.
2. תכנון סכימת דיירים. בוחרים הפרדה — מסד נתונים נפרד, סכימה נפרדת או מתאר משותף עם מפתח דייר מחייב. את ההחלטה מקבעים בסכימה, לא בקוד האפליקציה: אפשר לשנות מדיניות בלי לכתוב מחדש את הלוגיקה.
3. תפקידים ומגבלות. מפרידים בין גישת מנהל, מפעיל ומשתמש קצה, קובעים מכסות לבקשות, נפח אחסון ומספר דיירים. המגבלות חיות ברמת הפלטפורמה — לקוח אחד לא משפיע על האחרים.
4. בדיקת בידוד. מריצים תרחישים שבהם דייר מנסה להשיג נתונים של אחרים דרך בקשות, דוחות, ייצוא וחיפוש. בנפרד בודקים משימות רקע, מאגרי ביניים וייצוא — שם הדליפות שכיחות במיוחד.
5. הפעלה ניסיונית. מחברים לקוח אחד-שניים למשימות אמיתיות ואוספים מדדים: זמן תגובה, שיעור כשלים, התנהגות הפלטפורמה עם גידול במספר הדיירים.
6. מסירת הפלטפורמה. מוסרים קונפיגורציות, סכימת דיירים, מדיניות גישה, סדר חיבור לקוח חדש והוצאת עדכונים, ומכשירים את הצוות שלכם על המתאר שלכם.

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

חבילת מסירה: קונפיגורציות, סכימות, מדיניות גישה, תקנונים

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

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

מוסרים הכל בפורמט עריך ועם ניהול גרסאות: שינויים מבוצעים בלעדינו ולא שוברים תאימות.

מקרה בוחן: איך שירות הסיר הקצאת גישות ידנית לדיירים

מה היה לפני המעבר

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

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

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

מה שינו ומה הראו המדידות

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

מדדים לפני ואחרי בהפעלה ניסיונית: מתוך 40+ מתארים הועברו 15, זמן הקצאת הגישה הצטמצם מיומיים ל-5–7 דקות, שיעור הבקשות שנסגרו בשירות עצמי — 92%, זרימת הפניות לתמיכה ירדה מ-40 ל-7–9 בשבוע, גישות עם הרשאות עודפות — מ-12% ל-0.8%, חיבור דייר חדש — 15 דקות במקום יום-יומיים.

המדידות נלקחו בחתכים שבועיים לפי יומני גישה ומערכת הפניות: השוו את אותם מדדים על אותם מתארים בתקופה שלפני המעבר ואחרי חודשיים של עבודה.

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

במה ריבוי דיירים שונה מעותקי פריסה?

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

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

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

עלות הבעלות גדלה לינארית עם מספר העותקים — פי שניים לקוחות, פי שניים עדכונים, בדיקות ומקומות שבהם הקונפיגורציות יכולות להתפצל. התאמה אישית בסכמת ריבוי דיירים נעשית דרך הגדרות הדייר: הרשאות, מגבלות, מערכי מודלים, עיצוב הממשק. עותק מאפשר לערוך קוד ישירות, אבל שינויים כאלה بعد כך חוסמים עדכונים משותפים.

הסכמה העובדת לפלטפורמת white-label — מתאר אחיד עם הפרדה כבסיס, ופריסה ייעודית רק ללקוחות עם דרישות מחמירות לבידוד נתונים.

ספקות טכניים: בידוד נתונים, חיוב, עדכונים

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

איך מוגדרות מגבלות וחיוב דיירים?

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

האם התאמה אישית שוברת עדכונים משותפים?

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

נדבר על המשימה: נבנה סכימת דיירים למוצר שלכם

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

עם הסט הזה, בשיחה אחת נסיר אי-ודאויות ונחזור עם סכימת דיירים, תוכנית שלבים והערכת עבודה — בלי שלבי ביניים של «נבהיר אחר כך».

מה כדאי להכין לשיחה:

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

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