Z pewnością zastanawiałeś się, ile kosztuje infrastruktura twojego projektu. Co ciekawe, wzrost wydatków nie jest liniowy w odniesieniu do obciążeń. Wielu właścicieli firm, CTO i deweloperów nieświadomie zdaje sobie sprawę, że przepłacają. Ale za co konkretnie?
Zazwyczaj redukcja kosztów sprowadza się do poszukiwania najtańszego rozwiązania, taryfy AWS lub, w przypadku fizycznych stojaków, optymalizacji konfiguracji sprzętu. Co więcej, tym zajmuje się każdy, kto ma wenę: jeśli mówimy o startupie, to prawdopodobnie lider deweloperów, który ma wystarczająco dużo zmartwień. W większych firmach zajmuje się tym CMO/CTO, czasami sam dyrektor generalny wspólnie z głównym księgowym. W końcu ci ludzie mają wystarczająco dużo „profilowych” zmartwień. I okazuje się, że rachunki za infrastrukturę rosną, ale zajmują się tym... ci, którzy nie mają czasu się tym zajmować.
Jeśli w biurze trzeba kupić papier toaletowy, zajmie się tym zarządca lub odpowiednia osoba z firmy sprzątającej. W przypadku rozwoju — liderzy i CTO. Sprzedaż — również jest jasna. Ale jeszcze od „starożytnych” czasów, kiedy „serwerownią” nazywano szafę, w której stał zwykły komputer tower z nieco większą ilością pamięci RAM i kilkoma dyskami w RAID, wszyscy (albo przynajmniej wielu) ignorują fakt, że zakupem mocy powinien zajmować się również wyspecjalizowany człowiek.
Niestety, pamięć historyczna i doświadczenie mówią, że to zadanie od dziesięcioleci było przekazywane przypadkowym ludziom: kto był bliżej, ten też podjął się zadania. Dopiero niedawno na rynku zaczęła kształtować się i przyjmować konkretne formy profesja FinOps. To ten wyspecjalizowany człowiek, którego zadaniem jest kontrola zakupu i wykorzystania mocy. A w końcu, zmniejszenie wydatków firmy w tym zakresie.
Nie namawiamy do rezygnacji z drogich i skutecznych rozwiązań: każdy biznes powinien sam decydować, co potrzebuje, aby komfortowo funkcjonować w zakresie sprzętu i tarifów chmurowych. Nie można jednak zignorować faktu, że bezmyślne zakupy „z listy” bez późniejszej kontroli i analizy wykorzystania dla wielu firm kończą się bardzo poważnymi stratami z powodu nieefektywnego zarządzania „aktywami” swojego backendu.
Kim jest FinOps
Załóżmy, że macie solidne przedsiębiorstwo, o którym sprzedawcy z zachwytem mówią „enterprise”. Prawdopodobnie „z listy” kupiliście kilkanaście serwerów, AWS i jeszcze coś „drobnego”. Co jest logiczne: w dużej firmie ciągle zachodzą jakieś ruchy – jedne zespoły rosną, inne się rozpadają, a trzecie są przenoszone do sąsiednich projektów. I oto połączenie tych ruchów w zestawieniu z mechanizmem zakupów „z listy” prowadzi do nowych siwych włosów podczas przeglądania kolejnego miesięcznego rachunku za infrastrukturę.
Co więc zrobić – cierpliwie siwieć dalej, zamalowywać czy zająć się przyczynami pojawiania się tych licznych przerażających zer na rachunku?
Co tu dużo mówić: zatwierdzenie, akceptacja i same płatności za wniosek wewnątrz firmy na ten sam tarif AWS – to nie zawsze (w rzeczywistości – prawie nigdy) szybki proces. I właśnie z powodu ciągłego ruchu korporacyjnego część tychże zakupów może gdzieś „zaginąć”. I zwyczajnie stawać bezczynnie. Jeśli uważny admin zauważy porzuconą szafę w swoim serwerowni, to w przypadku taryf chmurowych sytuacja jest znacznie smutniejsza. Mogą stać „niedostępne” przez miesiące – opłacone, ale w tym samym czasie już nikomu niepotrzebne w dziale, dla którego je zakupiono. Przy tym koledzy z sąsiedniego biura zaczynają rwać swoje jeszcze nieposiwiałe włosy, nie tylko na głowie, ale również w innych miejscach – już od tygodnia nie mogą opłacić podobnej taryfy AWS, która jest im nagle bardzo potrzebna.
Jakie jest najbardziej oczywiste rozwiązanie? Dokładnie, przekazać dowodzenie potrzebującym, a wszyscy będą zadowoleni. Tyle tylko, że komunikacja pozioma nie zawsze jest dobrze uregulowana. I drugi dział może po prostu nie wiedzieć o bogactwie pierwszego, które z kolei jakoś nie okazało się mu szczególnie potrzebne.
Kto za to odpowiada? — Ogólnie mówiąc, nikt. Tak właśnie wygląda sytuacja.
Kto na tym cierpi? — Wszyscy, cała firma.
Kto może poprawić sytuację? — Tak, tak, to FinOps.
FinOps to nie tylko pomost między programistami a potrzebnym im sprzętem, ale osoba lub zespół, którzy będą wiedzieć, gdzie, co i jak dobrze „leży” pod względem tych samych chmurowych taryf, zakupionych przez firmę. W rzeczywistości, ci ludzie powinni pracować w jednej drużynie z DevOps z jednej strony i działem finansowym z drugiej, pełniąc rolę efektywnego pośrednika i, co najważniejsze — analityka.
Kilka słów o optymalizacji
Chmury. Stosunkowo tanie i bardzo wygodne. Ale to rozwiązanie przestaje być tanie, gdy liczba serwerów staje się dwucyfrowa lub trzycyfrowa. Ponadto, chmury dają możliwość korzystania z coraz większej liczby usług, które wcześniej były niedostępne: to i bazy danych jako usługa (Amazon AWS, Azure Database), aplikacje bezserwerowe (AWS Lambda, Azure Functions) i wiele innych. Są one świetne, bo łatwe w użyciu — kupujesz i działasz, bez problemów. Jednak im głębiej firma i jej projekty zanurzają się w chmurze, tym gorzej śpi dyrektor finansowy. I tym szybciej siwieje prezes.
Chodzi o to, że rachunki za różne usługi chmurowe są zawsze niezwykle skomplikowane: za jedną pozycję możesz otrzymać trzystronicowe wyjaśnienie, za co, gdzie i jak wydano twoje pieniądze. To, oczywiście, miłe, ale zrozumienie tego jest praktycznie niemożliwe. I nasza opinia w tej kwestii nie jest jedyna: aby tłumaczyć rachunki chmurowe na język ludzki, istnieją całe usługi, na przykład lub . Jeśli ktoś zabrał się za stworzenie oddzielnej usługi do rozliczania rachunków, to skala problemu przewyższyła koszt farby do włosów.
Tak więc, co w tej sytuacji robi FinOps:
- czujnie rozumie, kiedy i w jakich ilościach zakupiono rozwiązania chmurowe.
- wie, jak te moce są wykorzystywane.
- przekłada je w zależności od potrzeb danego działu.
- nie kupuje „żeby było”.
- i w rezultacie — oszczędza twoje pieniądze.
Świetny przykład — chmurowe przechowywanie zimnej kopii bazy danych. Na przykład archiwizujesz ją, aby zmniejszyć zużycie przestrzeni i transferu podczas aktualizacji przechowalni? Tak, wydaje się to drobną sprawą — w jednym konkretnym przypadku, ale suma takich drobnych spraw potem prowadzi do nieprzyzwoitych wydatków na usługi chmurowe.
Lub inna sytuacja: wykupiłeś moc na zapas w AWS lub Azure, aby nie obniżyć wydajności podczas szczytowego obciążenia. Czy można być pewnym, że to optymalne rozwiązanie? Jeśli te instancje są bezczynne przez 80%, to po prostu marnujesz pieniądze na Amazonie. Tym bardziej, że dla takich przypadków AWS i Azure mają instancje burstable — po co ci marnujące zasoby serwery, jeśli możesz skorzystać z narzędzi do rozwiązywania problemów w okresach szczytowego obciążenia? Może zamiast instancji On Premise warto zainteresować się Reserved — są znacznie tańsze i można na nie uzyskać dodatkowe rabaty.
A propos rabatów
Jak wspominaliśmy na początku, zakupy często realizowane są przez kogoś przypadkowego — znaleziono kogoś, a potem czy będzie on jakoś postępować. Najczęściej „przypadkowymi” stają się osoby już obciążone obowiązkami, a w efekcie uzyskujemy sytuację, w której osoba szybko i kompetentnie, ale całkowicie samodzielnie decyduje, co i w jakich ilościach kupić.
A jednak w kontakcie z przedstawicielem handlowym chmurowej usługi można uzyskać korzystniejsze warunki, gdy mowa o zakupach hurtowych. Oczywiście, że nie uda się uzyskać takich rabatów przy cichym i jednostronnym zamówieniu — ale rozmawiając z prawdziwym menedżerem sprzedaży, może się udać. Lub ci ludzie mogą podpowiedzieć, na co teraz mają rabaty. To również bywa przydatne.
Należy pamiętać, że AWS i Azure nie są jedynymi rozwiązaniami na rynku. Oczywiście nie mamy na myśli organizacji własnego centrum danych — ale istnieją alternatywy dla tych dwóch klasycznych rozwiązań od gigantów.
Na przykład, Google wprowadził dla firm platformę Firebase, na której można „pod klucz” zrealizować ten sam projekt mobilny, który może wymagać szybkiego skalowania. Magazyny, real-time DB, hosting oraz chmurowa synchronizacja danych w ramach tego rozwiązania są dostępne w jednym miejscu.
Z drugiej strony, jeśli nie mówimy o monolitycznym projekcie, ale o ich zbiorze, to scentralizowane rozwiązanie nie zawsze jest opłacalne. Jeśli projekt jest długoterminowy, ma swoją historię rozwoju i odpowiednią ilość danych do przechowania, warto pomyśleć o bardziej fragmentarycznym podejściu do umieszczania danych.
Przy optymalizacji wydatków na usługi chmurowe nagle możesz uświadomić sobie, że dla krytycznych aplikacji biznesowych możesz zakupić mocniejsze plany, które zapewnią firmie nieprzerwaną działalność. Przy tym przechowywanie "dziedzictwa" rozwoju, starych archiwów, baz danych i innych rzeczy w drogich chmurach to niekoniecznie najlepsze rozwiązanie. Dla takich danych wystarczą standardowe centra danych z zwykłymi dyskami HDD i średniej wydajności sprzętem, bez żadnych "cudów".
Znowu można pomyśleć, że "ta zawracanie głowy nie jest tego warte", ale całe zagadnienie tej publikacji opiera się na tym, że na różnych etapach odpowiedzialne osoby ignorują drobiazgi i robią tak, jak jest wygodniej i szybciej. Co w rezultacie, po kilku latach, prowadzi do tych strasznych rachunków.
Co z tego wynika?
Ogólnie chmury to świetne rozwiązanie, rozwiązują wiele problemów dla firm każdej wielkości. Jednak nowość tego zjawiska prowadzi do tego, że wciąż brakuje nam kultury konsumpcji i zarządzania. FinOps to organizacyjny dźwignia, który pomaga skuteczniej korzystać z mocy chmurowych. Najważniejsze jest, aby nie przemieniać tej roli w analogię do grupy egzekucyjnej, której celem będzie przyłapanie niedbałych programistów na gorącym uczynku i "zbesztanie" ich za przestoje mocy.
Programiści powinni programować, a nie liczyć pieniądze firmy. I właśnie FinOps powinno sprawić, aby zarówno proces zakupu, jak i proces rezygnacji lub przekazywania mocy chmurowych innym zespołom były prostymi i przyjemnymi wydarzeniami dla wszystkich stron.
Źródło: habr.com
