כמה אתה מוציא על תשתית? ואיך אפשר לחסוך על זה כסף?

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

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

במידה ואתם צריכים לקנות נייר טואלט למשרד, זה יעשה על ידי מנהל האספקה ​​או אחראי מחברת הניקיון. אם בפיתוח עסקינן – לידים ו-CTO. מכירות - גם הכל ברור. אבל מאז הימים ההם, כאשר "חדר שרתים" היה שם לארון שבו הייתה מערכת מגדלים רגילה עם קצת יותר זיכרון RAM וכמה כוננים קשיחים בפשיטה, כולם (או לפחות רבים) מתעלמים מה- עובדה שרכישת קיבולת צריכה להיות מטופלת גם באדם שעבר הכשרה מיוחדת.

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

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

מי זה FinOps

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

אז מה לעשות - להמשיך בסבלנות להאפיר, לצבוע מעליו, או להבין את הסיבות להופעת האפסים האיומים הרבים האלה בתשלום?

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

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

מי אשם בזה? - בעצם, אף אחד. ככה הכל מסודר בינתיים.
מי סובל מזה? - זהו, כל החברה.
מי יכול לתקן את המצב? - כן, כן, FinOps.

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

קצת על אופטימיזציה

עננים. זול יחסית ומאוד נוח. אבל הפתרון הזה מפסיק להיות זול כאשר מספר השרתים מגיע לספרות כפולות או משולשות. בנוסף, עננים מאפשרים להשתמש ביותר ויותר שירותים שלא היו זמינים בעבר: אלו הם מסדי נתונים כשירות (Amazon AWS, Azure Database), אפליקציות ללא שרת (AWS Lambda, Azure Functions) ועוד רבים אחרים. כולם מאוד מגניבים כי הם קלים לשימוש - קנו והלכו, בלי בעיות. אבל ככל שהחברה והפרויקטים שלה צוללים עמוק יותר לתוך העננים, כך סמנכ"ל הכספים ישן יותר גרוע. וככל שהגנרל הופך מהר יותר לאפור.

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

אז מה FinOps עושה במצב הזה:

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

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

או מצב אחר: רכשתם קיבולת מילואים ב-AWS או Azure כדי לא ליפול בעומס שיא. האם אתה יכול להיות בטוח שזהו הפתרון האופטימלי? אחרי הכל, אם המקרים האלה לא פעילים 80%, אז אתה פשוט נותן כסף לאמזון. יתרה מכך, עבור מקרים כאלה, לאותן AWS ו-Azure יש מופעים ניתנים להתפרצות - למה אתה צריך שרתים בטלה, אם אתה יכול להשתמש בכלי כדי לפתור בעיות של עומסי שיא? לחלופין, במקום מופעי On Premise, כדאי להסתכל לכיוון Reserved - הם הרבה יותר זולים והם גם מציעים הנחות.

אגב, לגבי הנחות

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

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

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

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

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

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

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

התוצאה?

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

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

מקור: www.habr.com