הפודקאסט של מיכאל

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

איך זה קורה? והכי חשוב, מה אתם יכולים לעשות כדי שזה לא יקרה לכם?

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

אז כן, המתכנת במקרה הזה אשם, בעיקר כי השאיר את הגדרת ברירת המחדל של max instance על 1000, אבל הוא כן קבע התראת תקציב על $7 בגוגל קלאוד. הבעיה שגוגל, כמו ביטוח לאומי, עדכנה את מדדי השימוש רק אחרי 24 שעות. התוצאה: מ-5,000 ל-$25,000 תוך 20 דקות עד לחשבון סופי של $71,900.

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

ועוד סיפור ב-GCP. סטארטאפ שרגיל לחשבון חודשי של $1,500 חטף פתאום חשבונית על סך $450,000. הסיבה? מפתח API שדלף לאתר גיטהאב, בו גורמים עוינים מריצים בוטים ללא הרף בשביל טעויות כאלו ממש. וכשמוצאים מפתח כזה כמעט תמיד משתמשים בו לכרות קריפטו, ועושים את זה על המכונות היקרות ביותר בריג'נים המרוחקים ביותר. גם כדי למקסם את תפוקת הכרייה וגם להקשות על איתור וכיבוי הפעילות.

לפעמים, האסון הוא לא באג או פריצה, אלא פיצ'ר שלא הובן כהלכה. סמנכ"ל פיתוח בחברה אחרת החליט להריץ מבחן עומסים בסוף שבוע. ביום שני בבוקר, הוא ראה חשבון AWS של $120,000 וכמעט התעלף. העברת נתונים בין שירותי אמזון באותו ריג'ן אמורה להיות חינם, אבל זה רק אם התעבורה נשארת ברשת הפרטית של אמזון. המבחן בוצע מהאינטרנט הציבורי וגרר עמלת "עיבוד נתונים". כך הפכה פעולה חינמית ליקרה להפליא.

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

ועוד על עיבוד נתונים. חוקר ביצע כמה שאילתות מורכבות על Public Datasets, מידע שמונגש חינם ע"י ספקיות הענן. הוא התמכר לתובנות מהדאטה ששכח שמישהו צריך לשלם על השאילתה. $6 לטרה או $14,000 למחקר יקר במיוחד.

הסיפור האחרון הוא אולי המטריד ביותר. מפתח שהשתמש ב-Microsoft Azure חטף חשבון של $15,000 עבור שירות עיבוד וידאו שחשב שכיבה. רק כשחפר עמוק הוא מצא את הבעיה - השירות היה בלתי נראה לחלוטין בדאשבורד שלו. הוא לא יכל לראות אותו, לא יכל לגשת אליו, לא יכל לעצור אותו, אבל עדיין חויב עליו. זוהי הסכנה של "משאבי זומבי" – נכסים רדומים, נשכחים, או במקרה הזה, בלתי נראים, שממשיכים לצבור חיובים בשקט ברקע. זו יכול להיות סביבת בדיקה שמפתח שכח לפרק, נפח אחסון שלא מחובר לשרת, או גיבוי SQL שמעולם לא נמחק.

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

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

עם זאת, להגיד סליחה זה לא תמיד מספיק והתהליך יכול להיות איטי ואטום. המפתח הגנוב שעלה $450,000 זוכה רק ב-$50,000. נדרשו שבועות של פניות תמיכה ושיימינג ציבורי כדי להפעיל את הלחץ לזיכוי נוסף.

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

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

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

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

נתחיל ב-Amazon, שמציעה את AWS Budgets שמאפשר להגדיר תקציב ולקבל התראות כאשר העלויות בפועל (או החזויות) חורגות מההגדרות שלכם.

AWS Cost Anomaly Detection שמשתמש בלמידת מכונה כדי לנתח דפוסי הוצאה היסטוריים ומתריע על פעילות חריגה.

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

אמזון Budget Action: שמאפשר להגדיר תגובה, מגובה ב-IAM Role, שיכולה לסגור שרתי EC2 או RDS. זו לא רק התראה, זה מפסק זרם, והדבר הכי קרוב למקבלה קשיחה על הוצאות.

אגב תעשו לי טובה, ולפני שאתם מגדירים את השירותים האלה, תפעילו אימות רב-גורמי (MFA) ותקבעו הרשאות שהן Least Privileged לכל המשתמשים.

ב-Google Cloud Platform יש את ה-API Quotas, שמאפשר להגביל הוצאות על בסיס שירות ספציפי (כמו מספר בקשות ליום או דקה עבור כל API שניתן לחייב עליו).

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

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

ב-Azure של מיקרוסופט יש פחות או יותר אותם כלים, כולל Advisor שמספק המלצות על איפה לחסוך.

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

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