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

למה מערכת המתנות במשחק מובייל נשברת בעומסי שיא

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

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

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

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

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

האפקט של הנפקה מנוהלת: מה משתנה במספרים

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

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

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

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

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

אפשרויות הנפקה: מארז, העברה ישירה, החלפה

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

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

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

שלבי הטמעה: מביקורת ועד מסירה לתמיכה

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

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

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

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

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

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

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

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

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

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

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

מה הראו המדדים

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

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

במה מתנה שונה ממטבע בתוך המשחק?

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

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

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

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

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

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

המתנה תאבד אם הקליטה תתנתק?

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

איך נספרות המגבלות היומיות על שליחה?

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

איך נסגרת מניפולציה מחשבונות חדשים?

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

מה עם התראות ופעולות שנויות במחלוקת?

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

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

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

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

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