פיתוח פלטפורמת AI מרובת דיירים (SaaS) ללקוחות B2B

מדוע ריבוי דיירים ב-AI SaaS נשבר עם צמיחת בסיס הלקוחות

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

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

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

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

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

מה נותנת הפלטפורמה: בידוד, מהירות וצפיות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תוצרים שנשארים אצל הלקוח לאחר העבודה

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

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

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

מקרה בוחן: כיצד הסרנו הצטלבויות נתונים בין לקוחות

מה היה

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

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

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

מה שינו

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

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

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

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

במה נבדל בידוד נתונים בריבוי דיירים ממתחמים נפרדים?

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

איך לוודא שנתוני הלקוח אינם נגישים לאחרים?

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

מה יקרה עם גידול במספר הלקוחות?

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

מי אחראי לעדכונים לאחר המסירה?

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

נדון במשימה: מה להכין לשיחה

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

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

אין חובה לסגור את הרשימה במלואה — אם משהו אינו בהישג יד, תארו במילים, ונשחזר את התמונה במהלך הדיון במשימה.

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

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