MVP שנבנה ב־Vibe Coding למיליון משתמשים? מתחילים במודל עומס.

מתרגמים את השאיפה לתעבורה

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

הנה חישוב להמחשה שמבוסס על הנחות, לא מבחן ביצועים ולא יחס מקובל: מיליון משתמשים רשומים, 5% פעילים ביום מסוים ו־20 בקשות לשרת לכל משתמש פעיל יוצרים מיליון בקשות ביום. חלוקה ב־86,400 שניות נותנת ממוצע של כ־11.6 בקשות בשנייה. הממוצע הזה אינו מלמד מה יקרה בשיא של קמפיין, במשימות מתוזמנות שמתחילות יחד או בבקשה יקרה במיוחד.

מגדירים עומס שמהנדסים יכולים לבדוק

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

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

• כמה תעבורה צפויה להגיע בזמן העמוס ביותר?
• אילו פעולות פונות ל־API חיצוני או למודל?
• איזה נפח נתונים ואיזו התפלגות חשבונות הבדיקה צריכה לייצג?
• אילו פעולות יכולות להמתין ואילו חייבות להגיב מיד?

בודקים את המסלול ומאתרים את צוואר הבקבוק

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

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

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

משנים את מה שהמדידה מצדיקה

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

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

השלב הבא בקיבולת הוא חלק מהמשך הפיתוח

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

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