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

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

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

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

מה באמת נשבר כשהתעבורה מזנקת

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

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

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

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

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

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

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

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

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

אל תגרמו לאנשים לחכות לדברים שיכולים לקרות מאוחר יותר

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

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

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

תכינו תוכנית ל”יותר מדי אנשים”

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

כמה גרסאות פשוטות של זה:

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

חזרה גנרלית של שלושים דקות

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

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

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

המטרה האמיתית

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

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

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