אמזון הודיעה ב־2 בנובמבר על שינוי בדרך שבה מוצגות עלויות גיבויים מסוג תמונת מצב בשירות מסדי הנתונים Amazon RDS. במקום ייחוס מצטבר ברמת מופע מסד הנתונים, אפשר לראות עלות לכל תמונת מצב בנפרד. לפי החברה, האפשרות מופעלת כברירת מחדל ללא תשלום נוסף, בכל מנועי השירות ובכל אזורי הענן המסחריים ובאזורי הענן הממשלתי האמריקני. ההודעה עוסקת בפירוט החיוב, ולא בהפיכת אחסון הגיבויים עצמו לשירות חינמי.
לעסק שמשלם על שירותי ענן, ההבדל עשוי להיות חשוב דווקא מחוץ לצוות הפיתוח. כאשר הגיבויים משויכים לפרויקט, לסביבה או ליחידה עסקית, אפשר להבין טוב יותר מי משתמש בתקציב. עם זאת, שינוי מבנה הדוח יכול לשבש כללי בקרה שנבנו על המבנה הישן. בתיעוד הרשמי מופיעה אזהרה מפורשת: כללים שמזהים עלויות לפי המזהה של מופע מסד הנתונים לא יזהו עוד את אותן הוצאות גיבוי בדרך הקודמת.
מה השתנה בשורת החיוב
לפי התיעוד, כל תמונת מצב מופיעה כפריט משלה בכלי ניתוח העלויות ובדוח העלות והשימוש. שדה מזהה המשאב מכיל מעתה את המזהה של תמונת המצב, ולא את המזהה של מופע מסד הנתונים שאליו שויכו החיובים בעבר. גם תמונות מצב שמקורן במופע שכבר נמחק משויכות למשאב הגיבוי שמייצר את החיוב. אין בתיאור הזה הבטחה שההוצאה הכוללת קטנה.
החברה מציינת במפורש שהתמחור והחיובים הכוללים נשארים כפי שהיו, ורק הייחוס וההצגה משתנים. לכן מנהל כספים שרואה שינוי בחלוקה בין שורות לא צריך להסיק מיד שנוספו גיבויים או שספק הענן העלה מחיר. הצעד הראשון הוא לבדוק אם השתנה בסיס הסיווג. רק לאחר שמזהים אותו אפשר להשוות תקופות ולהפריד בין שינוי אמיתי בשימוש לבין שינוי בדרך שבה אותו שימוש מופיע בדוח.
למה תגיות הן חלק מהחשבון
תגית בשירות היא צמד של מפתח וערך שהארגון מגדיר למשאב. למשל, המפתח יכול לציין פרויקט והערך יכול להיות שם פנימי מוסכם. בתיעוד אמזון מוסבר שאפשר להשתמש בתגיות לקיבוץ הוצאות, לצד שימושים אחרים כמו ניהול משאבים והרשאות. לצורך חלוקת עלויות הגיבוי אפשר להוסיף תגיות ישירות לתמונות המצב, או להעתיק תגיות ממופע מסד הנתונים לתמונות חדשות.
הדוגמה העסקית פשוטה: אם שתי מחלקות משתמשות באותו חשבון ענן, תגית אחידה יכולה לעזור להציג את הוצאות הגיבוי של כל אחת. אבל השם לא נוצר מעצמו ואינו יודע מי אמור לשלם. צריך להחליט על שיטת שמות, מי מזין אותה ומי בודק אותה. תגית שנותרה מפרויקט ישן עלולה לייצר דוח מסודר למראה אך שגוי מבחינת האחריות התקציבית.
תגית חדשה אינה מתקנת את העבר
התיעוד קובע שתגיות להקצאת עלויות אינן מוחלות בדיעבד. שימוש באחסון גיבוי שהתרחש לפני הוספת התגית נותר ללא אותו שיוך בחיוב. זו מגבלה שצריך לזכור כאשר מתחילים מיפוי באמצע תקופה: דוח מסומן חלקית אינו בהכרח הוכחה שחלק מן המשאבים לא עלו כסף. ייתכן שפשוט לא הייתה להם תגית בזמן הרלוונטי.
לכן כדאי לתעד את תאריך תחילת השימוש בשיטה החדשה ולסמן אותו לצד ההשוואה החודשית. אם רוצים להציג עלות פרויקט לתקופה מוקדמת יותר, צריך להסביר על איזה מידע אחר מבוסס הייחוס, ולא להציג את התגית כאילו הייתה קיימת אז. אין כאן צורך להמציא אומדן כדי למלא כל משבצת. רישום של מגבלה ידועה מועיל יותר ממספר מדויק לכאורה שנשען על שיוך שלא התקיים.
העתקת תגיות פועלת מכאן והלאה
אמזון מאפשרת להפעיל אפשרות שמעתיקה תגיות ממופע מסד הנתונים לתמונות המצב שהוא יוצר. לפי התיעוד, האפשרות חלה רק על תמונות שנוצרות לאחר הפעלתה. תמונות קיימות צריך לתייג ישירות. בנוסף, העתקת תגיות בין חשבונות אינה נתמכת במסגרת המתוארת. יש גם חריגים מתועדים כאשר מוסיפים תגיות מפורשות בזמן יצירת תמונה, ולכן אין להניח שכל מסלול יצירה מעתיק בדיוק את אותו מידע.
המשמעות המעשית היא שבדיקת שינוי צריכה לכלול גם את המלאי הקיים וגם את דרך יצירת הגיבויים בעתיד. סימון אפשרות אחת אינו אישור שכל ההיסטוריה כבר מסווגת. אפשר לבקש מהצוות הטכני להציג דוגמה של תמונה ישנה, תמונה חדשה והעתק בחשבון אחר, ולבדוק מה מופיע בכל אחת. כך מוודאים את התוצאה בפועל במקום להסתפק בכך שהאפשרות מופיעה כמופעלת במסך ההגדרות.
המכסה ללא חיוב מחולקת באופן יחסי
בתיעוד הגיבויים מתואר נפח אחסון גיבוי ללא חיוב בגובה מלוא אחסון מסדי הנתונים שהוקצה בחשבון ובאזור הרלוונטי. המכסה מחולקת כהנחה באחוזים על פני תמונות המצב, ולא מנוכה כתשלום קבוע מתמונה אחת. לכן חלוקה לפי תגיות אינה חייבת להיראות כמו החלוקה הישנה ברמת מופע מסד הנתונים, אף שהסכום הכולל אינו משתנה בעקבות שינוי ההצגה.
הדוגמה הרשמית משתמשת ב־100 יחידות אחסון שהוקצו למסדי נתונים ובשתי תמונות מצב, בגודל 50 ו־75 יחידות. מתוך 125 יחידות גיבוי, המכסה מכסה 80%. אותה הנחה יחסית חלה על שתיהן, ולכן יתרת הנפח לחיוב היא 10 יחידות בתמונה הראשונה ו־15 בשנייה, בסך הכול 25. זו המחשה של חלוקת נפח לחיוב, לא הצעת מחיר בדולרים ולא אומדן לחשבון של עסק מסוים.
כללי תקציב ישנים עלולים להחמיץ שורות
אמזון מזהירה שכלל שמחפש מזהה של מופע מסד נתונים בשדה מזהה המשאב לא יתאים עוד לחיובי תמונות המצב. האזהרה כוללת קטגוריות עלות, מסנני תקציב ותהליכי חיוב פנימי שקוראים את שדה המזהה בדוח. החברה מפנה לעדכון הכללים כך שיתאימו למזהי תמונות המצב, או לשימוש בתגיות להקצאת עלויות.
זהו חלק חשוב יותר מהכותרת על פירוט חדש. אם ההוצאה נשארת קיימת אבל יוצאת מן המסנן, דוח מחלקתי עשוי להראות ירידה שאינה חיסכון. אפשר לבדוק זאת באמצעות התאמה בין הסכום הכולל לבין סך הקבוצות בדוח הפנימי. פער אינו מוכיח לבדו מה התקלקל, אבל הוא מסמן שצריך לבדוק את הכללים לפני שמודיעים שמחלקה עמדה ביעד ההוצאות או שהגיבויים שלה הוזלו.
מחיקת מסד נתונים אינה מוחקת כל גיבוי
לפי תיעוד השירות, תמונות מצב ידניות ותמונת מצב סופית אינן תלויות במחיקת המופע באותו אופן כמו גיבויים אוטומטיים. גיבויים אוטומטיים שנבחר לשמור בעת המחיקה נשמרים לתקופת השמירה שנקבעה. תמונות מצב ידניות אינן נמחקות רק מפני שמופע מסד הנתונים נמחק. גם בעלות על תמונה משותפת ממשיכה לקבוע למי מיוחס אחסונה.
מבחינה תקציבית, סיום פרויקט אינו אישור שכל העלויות שלו נעלמו. צריך להבחין בין סביבת עבודה פעילה לבין גיבוי שנשמר במכוון. אין להסיק מכך שכדאי למחוק את הגיבוי: ייתכן שהוא נדרש להתאוששות או לתהליך פנימי. השאלה הנכונה היא מי אחראי להחליט על השמירה ומתי בודקים אותה מחדש. בדיקת עלות אינה תחליף לאישור למחיקת מידע או לשינוי מדיניות התאוששות.
תגיות אינן מקום למידע רגיש
התיעוד מזהיר שלא לשמור בתגיות מידע אישי מזהה או מידע סודי ורגיש. הוא גם מציין ששמות מפתחות וערכים רגישים לאותיות גדולות וקטנות. לכן שיטת תיוג צריכה להיות גם עקבית וגם מוגבלת במידע שהיא כוללת. שם פרויקט פנימי מוסכם יכול למלא תפקיד תקציבי בלי להעתיק לתגית תוכן לקוח, פרטי חשבון או מידע אחר שלא נחוץ לסיווג ההוצאה.
לפני הטמעה רחבה כדאי להגדיר רשימה מצומצמת של מפתחות מותרים ודוגמאות לערכים. אחר כך בודקים אם הנתונים שמגיעים לדוח באמת משתמשים באותה שפה. כאשר צוות אחד כותב שם שונה מאחר, כלי העלויות עשוי להציג קבוצות נפרדות. זו אינה שגיאה חשבונית של הכלי, אלא תוצאה של הנתונים שהוזנו. ההכרעה מי משתייך לאיזו קבוצה נשארת החלטה ארגונית.
אחסון גיבוי אינו העתק מלא בכל פעם
בתיעוד השירות מוסבר שתמונת המצב הראשונה כוללת את מלוא נתוני מסד הנתונים, ואילו תמונות הבאות של אותו מסד שומרות את השינוי מאז התמונה האחרונה. לכן אין לחשב את נפח האחסון פשוט באמצעות הכפלת מספר התמונות בגודל המסד. גם כאן צריך לקרוא את מדידת השירות ולא להחליף אותה באומדן שנראה נוח.
ההבחנה חשובה בשיחה בין הנהלת החשבונות לצוות הטכני: מספר גדול יותר של נקודות גיבוי אינו לבדו תיאור מלא של מספר יחידות האחסון לחיוב. נדרשים נתוני שימוש והגדרות שמירה כדי להסביר את החשבון, ולא ספירת שמות בקובץ.
מה לבדוק לפני הדוח החודשי הבא
העדכון מוסיף פירוט שימושי, אך דורש תחזוקה של הדרך שבה העסק קורא את חשבון הענן. אפשר להתחיל ממיפוי הכללים הנשענים על מזהה מופע, להחליט אילו תגיות ישמשו לייחוס ולבדוק דוגמאות של תמונות מצב ישנות וחדשות. לאחר מכן משווים בין הסכום הכולל לבין הסכומים שמופיעים בכל קבוצה, תוך שמירה על גבולות חשבון ואזור עקביים.
המדד להצלחה אינו מספר התגיות שנוספו, אלא היכולת להסביר מי נושא בהוצאה ומה השתנה בין תקופות. חשוב לשמור בנפרד את עלות האחסון, את המכסה ללא חיוב ואת שינוי צורת ההצגה. אמזון מציעה דרך מדויקת יותר לראות את רכיבי החשבון; העסק עדיין צריך להחליט איך להשתמש במידע, בלי למחוק גיבויים נחוצים ובלי להציג שינוי סיווג כחיסכון שכבר הושג.
אולי יעניין אותך גם
הנתונים בענן שלכם. מי אחראי על השאר?כ-7 דקות קריאה · נפתלי כהן119 מיליארד דולר עברו בפלטפורמה. כמה נשאר לשופיפיי?כ-7 דקות קריאה · מוישי גנץהמזומן זינק. יום אחרי הרבעון הגיעה הרכישהכ-7 דקות קריאה · מוישי גנץהחשבון מפתיע בכל חודש? קודם בודקים שלא ספרתם הוצאה פעמייםכ-7 דקות קריאה · שלומי סגלאוהבים את התוכן? רוצים להתעדכן כשעולה תוכן חדש?
מצאתם טעות או תוכן לא ראוי? דווחו לנו >>
→ חזרה לעמוד הבית