חשבונות ענן כמעט אף פעם לא מתנפחים מהחלטה גרועה אחת. הם זוחלים - instance גדול מדי כאן, סביבה מיותמת שם, snapshot נשכח מפרויקט ששוחרר לפני שנה. החדשות הטובות: אותה שגרתיות משעממת אומרת שגם התיקונים משעממים, והם נשארים.
תמצאו את הכסף לפני שאתם מייעלים
אל תתחילו מכיוונון. תתחילו מלהסתכל. תדליקו cost allocation tags ותענו על שאלה אחת: אילו חמישה דברים עולים הכי הרבה? מאמץ הייעול צריך ללכת אחרי החשבון, לא אחרי האינטואיציה. כמעט תמיד, שלושת הסעיפים הגדולים הם המקום שבו כל החיסכון נמצא.
החשודים הרגילים
לפי סדר התדירות שבה הם משתלמים:
- Compute גדול מדי. instances שנבחרו לשיא שלא מגיע. תתאימו לגודל השימוש האמיתי, לא למספר שהרגיש בטוח.
- Non-production בטל. dev ו-staging רצים 24/7 לצוות שעובד 8 שעות. תכבו אותם בלילות ובסופי שבוע - לרוב חיסכון של 60%+ על הסביבות האלה.
- אחסון מיותם. volumes לא מחוברים, snapshots ישנים, לוגים בלי מדיניות שמירה. זול בבודד, יקר בצבירה, בלתי נראה לנצח.
- הפתעות egress. דאטה שיוצא מהענן, או חוצה אזורים, מתומחר לפי גיגה. בדרך כלל ריח של ארכיטקטורה ששווה לתקן ממילא.
תתחייבו רק למה שאתם מבינים
Reserved instances ו-savings plans הם הנחות אמיתיות, אבל הם הימור על שימוש עתידי. תקנו אותם לבסיס היציב שאתם בטוחים בו, ותשאירו את החלק המשתנה on demand. התחייבות שאתם גדלים מעבר לה או מנצלים בחסר מבטלת בשקט את החיסכון של עצמה.
תהפכו את זה להרגל, לא לגבורה
המעבר שחוסך 30% פעם אחת שווה פחות מהצצה חודשית של עשר דקות בעלויות הגדולות, ותג שמסמן כל דבר לא מתויג. עלות היא תכונה של אמינות: חשבון בלתי צפוי הוא מערכת לא מנוטרת. תתייחסו אליו כמו ל-uptime - תסתכלו קצת, כל הזמן, במקום הרבה, פעם אחת.