Na pewno zastanawiałeś się, ile kosztuje infrastruktura Twojego projektu. Jednocześnie zaskakuje: wzrost kosztów nie jest liniowy w zależności od ładunków. Wielu właścicieli firm, stacji paliw i deweloperów skrycie rozumie, że przepłacają. Ale po co dokładnie?
Zazwyczaj cięcie kosztów sprowadza się po prostu do znalezienia najtańszego rozwiązania, planu AWS lub, w przypadku szaf fizycznych, optymalizacji konfiguracji sprzętowej. Mało tego: tak naprawdę każdy robi to, co Bogu się podoba: jeśli mówimy o startupie, to prawdopodobnie jest to czołowy deweloper, którego głowa boli. W większych urzędach zajmuje się tym CMO/CTO, a czasem w sprawę angażuje się osobiście dyrektor generalny wspólnie z głównym księgowym. Ogólnie rzecz biorąc, ci ludzie, którzy mają wystarczająco dużo „podstawowych” obaw. I okazuje się, że rachunki za infrastrukturę rosną, ale radzą sobie z tym ci, którzy nie mają czasu się tym zająć.
Jeśli zajdzie potrzeba zakupu papieru toaletowego do biura, zrobi to kierownik ds. zaopatrzenia lub osoba odpowiedzialna z firmy sprzątającej. Jeśli mówimy o rozwoju - leady i CTO. Sprzedaż - wszystko też jasne. Ale od dawnych czasów, kiedy „serwerownia” była nazwą szafy, w której znajdował się zwykły system typu tower z nieco większą ilością pamięci RAM i kilkoma dyskami twardymi w raporcie, wszyscy (a przynajmniej wielu) ignorują to faktem, że zakupem mocy powinna zajmować się także specjalnie przeszkolona osoba.
Niestety, pamięć historyczna i doświadczenie wskazują, że przez dziesięciolecia zadanie to zrzucano na „przypadkowe” osoby: ten, kto był najbliżej, podchwytywał pytanie. I dopiero niedawno zawód FinOps zaczął nabierać kształtu na rynku i nabierać konkretnych kształtów. Jest to ta sama specjalnie przeszkolona osoba, której zadaniem jest kontrola zakupu i wykorzystania mocy produkcyjnych. I docelowo w obniżeniu kosztów firmy w tym obszarze.
Nie zalecamy rezygnowania z drogich i skutecznych rozwiązań: każdy biznes musi sam zdecydować, czego potrzebuje do wygodnej egzystencji w zakresie taryf sprzętowych i chmurowych. Nie można jednak nie zwrócić uwagi na fakt, że bezmyślne zakupy „według listy” bez późniejszego monitorowania i analizy zastosowań dla wielu firm ostatecznie skutkują bardzo, bardzo dużymi stratami w wyniku nieefektywnego zarządzania „aktywami” ich backendu.
Kim jest FinOps
Załóżmy, że masz renomowaną firmę, o której sprzedawcy mówią „przedsięwzięcie” zdyszanym tonem. Prawdopodobnie „według listy” kupiłeś kilkanaście serwerów, AWS i jakieś inne „drobiazgi”. Co jest logiczne: w dużej firmie nieustannie dzieje się jakiś ruch – niektóre zespoły rosną, inne się rozpadają, jeszcze inne są przenoszone do sąsiednich projektów. Połączenie tych posunięć wraz z mechanizmem zamówień „opartym na listach” ostatecznie prowadzi do pojawienia się nowych siwych włosów, gdy spojrzymy na kolejny miesięczny rachunek za infrastrukturę.
Co więc robić - cierpliwie kontynuować szarość, zamalować ją lub dowiedzieć się, dlaczego w płatności pojawiają się te liczne okropne zera?
Powiedzmy sobie szczerze: zatwierdzenie, zatwierdzenie i bezpośrednie opłacenie wniosku wewnątrz firmy na tę samą taryfę AWS nie zawsze (w rzeczywistości prawie nigdy) nie przebiega szybko. I właśnie z powodu ciągłego ruchu korporacyjnego niektóre z tych samych przejęć mogą gdzieś zostać „zagubione”. A bezczynność jest banalna. Jeśli uważny administrator zauważy w swojej serwerowni szafę bez właściciela, to w przypadku taryf chmurowych wszystko jest znacznie smutniejsze. Można je odkładać na miesiące - opłacone, ale jednocześnie niepotrzebne już nikomu w dziale, dla którego zostały zakupione. W tym samym czasie koledzy z sąsiedniego biura zaczynają wyrywać jeszcze nie siwe włosy nie tylko na głowie, ale także w innych miejscach - nie byli już w stanie zapłacić za n-ty tydzień mniej więcej tej samej taryfy AWS, co jest pilnie potrzebne.
Jakie jest najbardziej oczywiste rozwiązanie? Zgadza się, oddaj stery potrzebującym i wszyscy będą szczęśliwi. Jednak komunikacja horyzontalna nie zawsze jest dobrze ugruntowana. A drugi dział może po prostu nie wiedzieć o bogactwie pierwszego, który jakoś okazał się, że tak naprawdę nie potrzebuje tego bogactwa.
Kto jest temu winien? - Właściwie nikt. Tak na razie wszystko jest ustawione.
Kto na to cierpi? - To tyle, cała firma.
Kto może naprawić sytuację? - Tak, tak, FinOps.
FinOps to nie tylko warstwa pomiędzy programistami a potrzebnym im sprzętem, ale osoba lub zespół, który będzie wiedział gdzie, co i jak dobrze „leży” w kontekście tych samych taryf chmurowych zakupionych przez firmę. Tak naprawdę osoby te muszą współpracować z DevOps z jednej strony i działem finansowym z drugiej, pełniąc rolę skutecznego pośrednika i, co najważniejsze, analityka.
Trochę o optymalizacji
Chmury. Stosunkowo tani i bardzo wygodny. Jednak to rozwiązanie przestaje być tanie, gdy liczba serwerów osiąga dwu- lub trzycyfrową liczbę. Ponadto chmury umożliwiają korzystanie z coraz większej liczby usług, które wcześniej były niedostępne: są to bazy danych jako usługa (Amazon AWS, Azure Database), aplikacje bezserwerowe (AWS Lambda, Azure Functions) i wiele innych. Wszystkie są bardzo fajne, ponieważ są łatwe w użyciu – kup i używaj, nie ma żadnych problemów. Ale im głębiej firma i jej projekty zanurzają się w chmurach, tym gorzej śpi dyrektor finansowy. A im szybciej generał siwieje.
Faktem jest, że faktury za różne usługi w chmurze są zawsze niezwykle zagmatwane: w przypadku jednej pozycji możesz otrzymać trzystronicowe wyjaśnienie, na co, gdzie i jak poszły Twoje pieniądze. To oczywiście jest przyjemne, ale prawie niemożliwe jest to zrozumieć. Co więcej, nasza opinia w tej kwestii nie jest jedyna: aby przenieść konta w chmurze na ludzkie, istnieją na przykład całe usługi lub . Jeśli ktoś zadał sobie trud stworzenia osobnej usługi rozszyfrowywania rachunków, to skala problemu przerosła koszt farby do włosów.
Co więc robi FinOps w tej sytuacji:
- doskonale rozumie, kiedy i w jakich ilościach zakupiono rozwiązania chmurowe.
- wie, w jaki sposób te zdolności są wykorzystywane.
- redystrybuuje je w zależności od potrzeb konkretnej jednostki.
- nie kupuje „aby tak było”.
- i ostatecznie pozwala zaoszczędzić pieniądze.
Świetnym przykładem jest przechowywanie zimnej kopii bazy danych w chmurze. Czy na przykład archiwizujesz go, aby zmniejszyć ilość miejsca i ruchu zużywanego podczas aktualizacji pamięci? Tak, wydawałoby się, że sytuacja jest tania – w jednym konkretnym przypadku, ale całość takich tanich sytuacji później skutkuje wygórowanymi kosztami usług w chmurze.
Lub inna sytuacja: kupiłeś rezerwową moc obliczeniową na AWS lub Azure, aby nie wpaść w szczytowe obciążenie. Czy możesz mieć pewność, że jest to optymalne rozwiązanie? W końcu, jeśli te instancje są bezczynne w 80%, oznacza to po prostu przekazanie pieniędzy Amazonowi. Co więcej, w takich przypadkach te same AWS i Azure mają instancje z możliwością przerywania - po co Ci serwery bezczynne, skoro możesz użyć narzędzia do rozwiązywania problemów szczytowych obciążeń? Ewentualnie zamiast instancji On Premise warto zwrócić uwagę na Reserved – są znacznie tańsze i oferują także zniżki.
Przy okazji, o rabatach
Jak powiedzieliśmy na początku, zakupów często dokonuje każdy – ten ostatni znalazł, a potem jakoś sam to robi. Najczęściej osoby, które są już zajęte, stają się „ekstremalne”, w efekcie czego dostajemy sytuację, w której osoba szybko i umiejętnie, ale całkowicie samodzielnie decyduje, co i w jakich ilościach kupić.
Natomiast wchodząc w interakcję ze sprzedawcą usługi chmurowej można uzyskać korzystniejsze warunki w przypadku hurtowego zakupu pojemności. Oczywiste jest, że nie będziesz w stanie uzyskać takich rabatów od samochodu z cichą i jednostronną rejestracją - ale po rozmowie z prawdziwym menedżerem sprzedaży możesz się wypalić. Albo ci goście mogą powiedzieć Ci, na co obecnie mają zniżki. Może się również przydać.
Jednocześnie trzeba pamiętać, że światło nie zbiegało się jak klin na AWS czy Azure. Nie ma oczywiście mowy o organizacji własnej serwerowni – istnieją jednak alternatywy dla tych dwóch klasycznych rozwiązań gigantów.
Na przykład Google udostępnił firmom platformę Firebase, na której mogą hostować ten sam projekt mobilny pod klucz, co może wymagać szybkiego skalowania. Magazynowanie, baza danych czasu rzeczywistego, hosting i synchronizacja danych w chmurze na przykładzie tego rozwiązania są dostępne w jednym miejscu.
Z drugiej strony, jeśli nie mówimy o projekcie monolitycznym, ale o ich całości, wówczas scentralizowane rozwiązanie nie zawsze jest korzystne. Jeśli projekt jest długotrwały, ma własną historię rozwoju i odpowiednią ilość danych wymaganych do przechowywania, wówczas warto pomyśleć o bardziej rozdrobnionym rozmieszczeniu.
Optymalizując koszty usług chmurowych, możesz nagle zdać sobie sprawę, że dla aplikacji krytycznych dla biznesu możesz kupić potężniejsze taryfy, które zapewnią firmie nieprzerwane zyski. Jednocześnie rozwiązaniem jest przechowywanie „dziedzictwa” rozwoju, starych archiwów, baz danych itp. w drogich chmurach. Przecież w przypadku takich danych całkiem odpowiednie jest standardowe centrum danych ze zwykłymi dyskami twardymi i sprzętem średniej mocy bez żadnych bajerów i gwizdków.
I tutaj znowu można by pomyśleć, że „to zamieszanie nie jest tego warte”, ale cały problem tej publikacji polega na tym, że na różnych etapach odpowiedzialni ludzie zaniedbują drobnostki i robią to, co jest wygodniejsze i szybsze. Co ostatecznie, po kilku latach, daje w rezultacie te same horrory.
Wynik?
Ogólnie chmury są fajne, rozwiązują wiele problemów dla firm dowolnej wielkości. Nowość tego zjawiska powoduje jednak, że wciąż nie mamy kultury konsumpcji i zarządzania. FinOps to dźwignia organizacyjna, która pomaga efektywniej wykorzystywać moc chmury. Najważniejsze, żeby nie zamienić tego stanowiska w odpowiednik plutonu egzekucyjnego, którego zadaniem będzie złapanie za rękę nieuważnych programistów i „zbesztanie” ich za przestoje.
Deweloperzy powinni się rozwijać, a nie liczyć firmowe pieniądze. Dlatego też FinOps powinno sprawić, że zarówno proces zakupu, jak i proces wycofywania lub przenoszenia pojemności chmury do innych zespołów będzie wydarzeniem prostym i przyjemnym dla wszystkich stron.
Źródło: www.habr.com