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