چقدر برای زیرساخت ها هزینه می کنید؟ و چگونه می توان در این مورد پس انداز کرد؟

قطعاً از خود پرسیده اید که هزینه زیرساخت پروژه شما چقدر است. در عین حال، تعجب آور است: رشد هزینه ها با توجه به بارها خطی نیست. بسیاری از صاحبان مشاغل، ایستگاه های خدمات و توسعه دهندگان مخفیانه متوجه می شوند که بیش از حد پرداخت می کنند. اما دقیقا برای چه؟

به طور معمول، کاهش هزینه‌ها صرفاً به یافتن ارزان‌ترین راه‌حل، یک طرح AWS، یا در مورد رک‌های فیزیکی، بهینه‌سازی پیکربندی سخت‌افزار خلاصه می‌شود. نه تنها این: در واقع، هر کسی به خواست خدا این کار را انجام می دهد: اگر در مورد یک استارتاپ صحبت می کنیم، احتمالاً این یک توسعه دهنده پیشرو است که سردردهای زیادی دارد. در دفاتر بزرگتر، CMO/CTO به این موضوع رسیدگی می کند و گاهی اوقات مدیر کل شخصاً همراه با حسابدار اصلی درگیر موضوع می شود. به طور کلی، آن دسته از افرادی که به اندازه کافی نگرانی های "هسته ای" دارند. و معلوم است که صورت‌حساب‌های زیرساختی در حال افزایش است، اما کسانی که زمان لازم برای رسیدگی به آن را ندارند، با آن سروکار دارند.

در صورت نیاز به خرید دستمال توالت برای دفتر، این کار توسط مدیر تامین یا یک مسئول از شرکت نظافت انجام می شود. اگر ما در مورد توسعه صحبت می کنیم - منجر و CTO. فروش - همه چیز نیز روشن است. اما از زمان‌های قدیم، زمانی که «اتاق سرور» نام کابینتی بود که در آن یک سیستم برج معمولی با کمی رم بیشتر و چند هارد دیسک در حمله وجود داشت، همه (یا حداقل بسیاری از آنها) این را نادیده می‌گرفتند. واقعیت این است که خرید ظرفیت نیز باید توسط یک فرد آموزش دیده خاص انجام شود.

افسوس، حافظه و تجربه تاریخی نشان می دهد که برای چندین دهه این وظیفه به افراد "تصادفی" منتقل شده است: هر کسی که نزدیکتر بود این سوال را انتخاب کرد. و اخیراً حرفه FinOps در بازار شکل گرفته و شکل خاصی به خود گرفته است. این همان فرد آموزش دیده ویژه ای است که وظیفه اش کنترل خرید و استفاده از ظرفیت است. و در نهایت کاهش هزینه های شرکت در این زمینه.

ما طرفدار کنار گذاشتن راه‌حل‌های گران قیمت و مؤثر نیستیم: هر کسب‌وکاری باید خودش تصمیم بگیرد که برای زندگی راحت از نظر تعرفه‌های سخت‌افزاری و ابری به چه چیزی نیاز دارد. اما نمی توان به این واقعیت توجه نکرد که خرید بدون فکر "طبق فهرست" بدون نظارت و تجزیه و تحلیل بعدی استفاده برای بسیاری از شرکت ها در نهایت منجر به زیان های بسیار بسیار قابل توجهی به دلیل مدیریت ناکارآمد "دارایی" باطن آنها می شود.

FinOps کیست

فرض کنید یک شرکت معتبر دارید که فروشندگان با لحنی نفسگیر درباره آن صحبت می کنند. احتمالاً "طبق لیست" شما یک دوجین یا دو سرور ، AWS و برخی "چیزهای کوچک" دیگر خریداری کرده اید. منطقی است: در یک شرکت بزرگ نوعی حرکت به طور مداوم اتفاق می افتد - برخی از تیم ها رشد می کنند، برخی دیگر از هم می پاشند، برخی دیگر به پروژه های همسایه منتقل می شوند. و ترکیب این حرکات، همراه با مکانیسم تدارکات «مبتنی بر فهرست»، در نهایت منجر به ایجاد موهای خاکستری جدید هنگام بررسی صورت‌حساب زیرساخت ماهانه بعدی می‌شود.

بنابراین چه باید کرد - با صبر و حوصله به خاکستری ادامه دهید، روی آن رنگ کنید یا دلایل ظاهر شدن این صفرهای وحشتناک متعدد را در پرداخت پی ببرید؟

بیایید صادق باشیم: تأیید، تأیید و پرداخت مستقیم یک برنامه در داخل شرکت برای همان تعرفه AWS همیشه (در واقعیت، تقریباً هرگز) سریع نیست. و دقیقاً به دلیل حرکت مداوم شرکتی، برخی از همین خریدها ممکن است در جایی «از دست بروند». و بیکار ماندن امری بی اهمیت است. اگر یک مدیر دقیق متوجه یک رک بدون مالک در اتاق سرور خود شود، در مورد تعرفه های ابری همه چیز بسیار غم انگیزتر است. آنها را می توان برای ماه ها ذخیره کرد - برای آنها پرداخت شده است، اما در عین حال دیگر برای هیچکس در بخشی که برای آن خریداری شده اند مورد نیاز نیستند. در همان زمان، همکاران دفتر بعدی شروع به پاره کردن موهای هنوز خاکستری خود نه تنها روی سر خود، بلکه در جاهای دیگر می کنند - آنها نتوانسته اند تقریباً همان تعرفه AWS را برای هفته نهم بپردازند. به شدت مورد نیاز است.

واضح ترین راه حل چیست؟ درست است، افسار را به دست نیازمندان بسپارید و همه خوشحال شوند. اما ارتباطات افقی همیشه به خوبی برقرار نیست. و بخش دوم ممکن است به سادگی از ثروت اولی اطلاع نداشته باشد، که به نوعی معلوم شد که واقعاً به این ثروت نیاز ندارد.

چه کسی در این مورد مقصر است؟ - در واقع هیچ کس. فعلاً همه چیز اینگونه تنظیم شده است.
چه کسی از این رنج می برد؟ - همین، کل شرکت.
چه کسی می تواند وضعیت را درست کند؟ - بله، بله، 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 را برای شرکت‌ها آورده است، که بر اساس آن می‌توانند همان پروژه تلفن همراه را به صورت کلید در دست میزبانی کنند، که ممکن است به مقیاس‌بندی سریع نیاز داشته باشد. ذخیره سازی، پایگاه داده بلادرنگ، میزبانی و همگام سازی داده های ابری با استفاده از این راه حل به عنوان مثال در یک مکان در دسترس هستند.

از سوی دیگر، اگر ما در مورد یک پروژه یکپارچه صحبت نمی کنیم، بلکه در مورد کلیت آنها صحبت می کنیم، یک راه حل متمرکز همیشه سودمند نیست. اگر پروژه عمر طولانی داشته باشد، تاریخچه توسعه خاص خود را داشته باشد و مقدار مربوط به داده های مورد نیاز برای ذخیره سازی را داشته باشد، پس ارزش آن را دارد که در مورد قرار دادن تکه تکه تر فکر کنید.

هنگام بهینه‌سازی هزینه‌ها برای خدمات ابری، ممکن است ناگهان متوجه شوید که برای برنامه‌های کاربردی حیاتی تجاری می‌توانید تعرفه‌های قدرتمندتری خریداری کنید که درآمدهای بی‌وقفه‌ای را برای شرکت فراهم می‌کند. در عین حال، ذخیره "میراث" توسعه، آرشیوهای قدیمی، پایگاه داده ها و غیره در ابرهای گران قیمت یک راه حل است. از این گذشته ، برای چنین داده هایی ، یک مرکز داده استاندارد با هارد دیسک های معمولی و سخت افزار متوسط ​​​​بدون هیچ گونه زنگ و سوت کاملاً مناسب است.

در اینجا دوباره ممکن است فکر کنید که "این هیاهو ارزشش را ندارد" اما کل مشکل این نشریه بر این اساس است که در مراحل مختلف افراد مسئول از کارهای کوچک غافل می شوند و کاری را که راحت تر و سریع تر است انجام می دهند. که در نهایت، پس از چند سال منجر به آن حساب‌های وحشتناک می‌شود.

نتیجه؟

به طور کلی، ابرها جالب هستند، آنها مشکلات زیادی را برای مشاغل با هر اندازه ای حل می کنند. اما جدید بودن این پدیده یعنی هنوز فرهنگ مصرف و مدیریت نداریم. FinOps یک اهرم سازمانی است که به شما کمک می کند تا قدرت ابر را به طور موثرتری به کار بگیرید. نکته اصلی این است که این موقعیت را به آنالوگ یک جوخه شلیک تبدیل نکنید، که وظیفه آن گرفتن توسعه دهندگان بی توجه و "سرزنش" آنها برای خرابی است.

توسعه دهندگان باید توسعه دهند، نه اینکه پول شرکت را حساب کنند. بنابراین FinOps باید هم فرآیند خرید و هم فرآیند از کار انداختن یا انتقال ظرفیت ابر به تیم‌های دیگر را به یک رویداد ساده و لذت‌بخش برای همه طرف‌ها تبدیل کند.

منبع: www.habr.com