שבעים ושניים אלף דולר. זו לא מקדמה על בית.
זו לא מכונית יוקרה.
זה החשבון שמפתח אחד
קיבל על...
טסט.
טעות קוד אחת, לולאה אינסופית שנשכחה,
שרצה רק כמה שעות וכמעט פירקה לו את החברה.
היום נצלול לתוך סיוט של כל מפתח:
חשבון ענן מפתיע, של חמש,
שש,
ואפילו שבע ספרות
שהופכות חלום של סטארטאפ מבטיח לקטסטרופה פיננסית.
איך זה קורה? והכי חשוב, מה אתם יכולים לעשות כדי שזה לא יקרה
לכם?
הסיפור הראשון הוא באמת קלאסיקה. דווקא בעולם ה-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:
שמנטר את החשבונות לאיתור פעילויות זדוניות עם
סימנים מובהקים, כמו כריית מטבעות.
אמזון
ב'דגט אקשן: שמאפשר להגדיר תגובה,
מגובה ב-
IAM Role,
שיכולה לסגור שרתי EC2 או RDS.
זו לא רק התראה, זה מפסק זרם,
זה הדבר הכי קרוב
למגבלה קשיחה על הוצאות בענן.
אגב, תעשו לי טובה, ולפני שאתם מגדירים את השירותים האלה,
תפעילו אימות רב-גורמי
(MFA),
ותקבעו הרשאות שהן Least privileged לכל המשתמשים.
ב-Google Cloud Platform יש את
ה-API
Quotas, שמאפשר להגביל הוצאות על בסיס שירות ספציפי
(כמו מספר בקשות ליום או דקה עבור
כל API שניתן לחייב עליו).
אפשר גם לסגור לגמרי API מסוימים.
יש גם התראות תקציב ופעולות פרוגרמטיות, כך שבנוסף למייל
יבש על חריגה אפשר להריץ
Cloud Function שיכבה מכונות וירטואליות
לא מוכרות.
סקיוריטי קומאנד סנטר: שעוזר לאתר פגיעויות ואיומים
פעילים כמו כריית קריפטו.
יש גם ביטוח
מפני
התקפות שלא הופסקו, אבל הוא זמין רק למשלמים על Premium Support.
ב-Azure של מיקרוסופט יש פחות או יותר אותם כלים, כולל Advisor שמספק המלצות על איפה לחסוך.
תראו, הענן מציע כוח מדהים,
אבל עם הכוח הזה מגיעה אחריות עצומה.
לא מספיק לבנות,
צריך לבנות באופן מאובטח
ומודע לעלויות.
השתמשו בכלים שהספק נותן לכם,
הגדירו תקציבים ופעולות אוטומטיות
ובאמא שלכם, לעולם,
לעולם,
אל תעלו מפתחות לגיטהאב.
עד הפעם הבאה,
תהיו טובים,
ותמשיכו להיות סקרנים.
יאללה ביי.