FinOps w praktyce: gdzie naprawdę uciekają koszty chmury

Tagi, czyli kto za to płaci

Pierwsze pytanie w każdym przeglądzie kosztów brzmi: do kogo należy ten zasób? Jeśli odpowiedź wymaga przeszukania wiadomości sprzed roku albo zapytania trzech zespołów, optymalizacja utknie, zanim się zacznie. Nikt nie wyłączy maszyny, której właściciela nie zna, bo ryzyko zatrzymania czyjegoś procesu wydaje się większe niż oszczędność.

Dlatego porządek w tagach traktujemy jako warunek wstępny, a nie kosmetykę. Wystarczy krótki, obowiązkowy zestaw, który da się egzekwować automatycznie:

• właściciel - osoba lub zespół, który podejmuje decyzje o zasobie, a nie tylko go utrzymuje,
• centrum kosztów albo projekt, na który trafia rozliczenie wewnętrzne,
• środowisko - produkcja, test, rozwój, szkolenie,
• data przeglądu lub wygaśnięcia dla zasobów tworzonych na czas projektu.

W Azure tagi można wymuszać przez Azure Policy, na przykład odmawiając utworzenia grupy zasobów bez wymaganych etykiet. W Cost Management warto z kolei włączyć dziedziczenie tagów z grupy zasobów lub subskrypcji, dzięki czemu koszty da się rozliczyć także wtedy, gdy pojedynczy zasób etykiety nie ma. Polityka nie naprawi jednak historii, więc pierwszy przegląd zwykle kończy się listą zasobów „bez właściciela”, którą trzeba przejść ręcznie razem z zespołami.

Osobną decyzję trzeba podjąć dla zasobów wspólnych: sieci centralnej, zapory, monitoringu czy kopii zapasowych. Nie należą do jednego projektu, więc w raportach lądują w pozycji „inne” i z czasem stają się największą nierozliczoną częścią rachunku. Wystarczy prosty klucz podziału, na przykład proporcjonalnie do kosztów bezpośrednich poszczególnych zespołów, żeby właściciele usług widzieli pełny koszt tego, czego używają.

Środowiska zostawione na noc

Środowiska testowe, deweloperskie i szkoleniowe są używane zwykle kilka godzin dziennie przez pięć dni w tygodniu, a rozliczane za każdą godzinę doby. Tydzień ma 168 godzin, z których zespół korzysta w praktyce przez kilkadziesiąt. Reszta to koszt postoju, którego nikt nie widzi, bo maszyna po prostu jest i odpowiada, gdy ktoś jej potrzebuje.

Najprostsze narzędzia są wbudowane w platformę: automatyczne wyłączanie maszyn wirtualnych o ustalonej godzinie, harmonogramy uruchamiania w Azure Automation albo w potokach wdrożeniowych, które budują środowisko na czas testów i usuwają je po zakończeniu. Dla baz danych warto sprawdzić, czy środowisko nieprodukcyjne mogłoby działać w warstwie bezserwerowej Azure SQL Database, w której obliczenia mogą być automatycznie wstrzymywane przy braku aktywności.

Trzeba przy tym pamiętać o zasobach, które po zatrzymaniu nadal kosztują. Zatrzymana maszyna wirtualna przestaje być rozliczana za moc obliczeniową dopiero po zwolnieniu przydziału (stan „zatrzymana, cofnięto przydział”), a jej dyski są naliczane dalej. Plan App Service kosztuje także wtedy, gdy wszystkie aplikacje w nim są wyłączone, bo opłata dotyczy planu, a nie aplikacji.

Dyski i zasoby, które przeżyły projekt

Po zakończeniu projektu zespół usuwa maszyny wirtualne, bo to one są widoczne na liście. Zostaje to, co było z nimi powiązane: dyski zarządzane, migawki, publiczne adresy IP, karty sieciowe, konta magazynu z kopiami testowymi i stare punkty odzyskiwania w magazynie Recovery Services. Każdy z tych elementów kosztuje niewiele, ale razem potrafią tworzyć wyraźną pozycję w rachunku, która rośnie z każdym kolejnym projektem.

W przeglądach sprawdzamy przede wszystkim:

• dyski zarządzane niepodłączone do żadnej maszyny oraz migawki, których nikt nie potrzebuje od miesięcy,
• statyczne publiczne adresy IP, które nie są powiązane z żadnym zasobem,
• bramy, równoważniki obciążenia i usługi sieciowe po środowiskach, których już nie ma,
• konta magazynu w warstwie gorącej z danymi, do których nikt nie sięga - kandydatów do warstwy chłodnej lub archiwalnej,
• obszary robocze Log Analytics, do których trafiają pełne logi diagnostyczne, choć nikt ich nie analizuje.

Ostatni punkt bywa niedoceniany. Koszt monitoringu zależy głównie od ilości przyjmowanych danych, więc włączenie wszystkich kategorii diagnostyki „na wszelki wypadek” w kilkudziesięciu zasobach potrafi kosztować więcej niż niejedna z monitorowanych usług. Warto ustalić, które logi są potrzebne do działania i bezpieczeństwa, ile dni przechowywania naprawdę wymaga zespół i co można przenieść do tańszego planu tabel albo do archiwum.

Rozmiar dobrany na zapas

Maszyny i bazy dobiera się zwykle na etapie projektu, przy niepełnej wiedzy o obciążeniu i z naturalną skłonnością do zapasu. Po kilku miesiącach produkcji są już dane, które pozwalają tę decyzję zweryfikować, ale rzadko ktoś do niej wraca, skoro wszystko działa.

Azure Advisor wskazuje maszyny o niskim wykorzystaniu, a metryki w Azure Monitor pozwalają sprawdzić, czy obciążenie procesora, pamięci i operacji dyskowych uzasadnia obecny rozmiar. Przy bazach Azure SQL warto zestawić wykorzystanie rdzeni wirtualnych lub jednostek DTU z rzeczywistymi szczytami, a przy pulach elastycznych sprawdzić, czy pula nie została kiedyś powiększona pod jedną bazę, która dawno przestała być problemem.

Zmniejszanie rozmiaru wymaga jednak ostrożności. Patrzymy na szczyty, a nie na średnią z miesiąca, bo baza, która przez większość dni pracuje na kilkunastu procentach mocy, w dniu zamknięcia miesiąca może potrzebować całego zapasu. Dlatego rekomendacje zmniejszenia łączymy z kalendarzem biznesowym i z prostym planem powrotu do poprzedniej konfiguracji, gdyby wydajność okazała się niewystarczająca.

Średnie wykorzystanie pokazuje, ile płacisz za bezczynność. Szczyt pokazuje, ile możesz bezpiecznie zaoszczędzić.

Zobowiązania i licencje

Gdy zasoby mają już właścicieli i właściwy rozmiar, można zająć się ceną jednostkową. Kolejność ma tu znaczenie, bo kupowanie rezerwacji na przewymiarowane maszyny utrwala marnotrawstwo na rok albo na trzy lata.

• Rezerwacje sprawdzają się przy stabilnych obciążeniach o przewidywalnym typie zasobu, na przykład przy bazach produkcyjnych czy maszynach pracujących całą dobę.
• Plan oszczędnościowy dla obliczeń (Azure savings plan for compute) pasuje tam, gdzie wydatek na moc obliczeniową jest stały, ale typ lub region maszyn może się zmieniać.
• Azure Hybrid Benefit pozwala wykorzystać w chmurze posiadane licencje Windows Server lub SQL Server objęte Software Assurance albo subskrypcją.
• Ceny Dev/Test mogą obniżyć koszt subskrypcji nieprodukcyjnych, jeśli pozwala na to umowa.

Dwa ostatnie punkty dają często najszybsze oszczędności, bo nie wymagają zmian technicznych, tylko porządku w licencjach i w umowie. Warunki zależą od rodzaju umowy z Microsoftem i od posiadanych licencji, dlatego przed decyzją warto je potwierdzić z partnerem licencyjnym i zapisać, które zasoby z nich korzystają.

Jak utrzymać efekt

Jednorazowe sprzątanie daje szybki wynik, ale bez stałego rytmu koszty wracają w ciągu kilku miesięcy, bo nowe projekty powtarzają te same nawyki. FinOps w praktyce oznacza przede wszystkim powtarzalny przegląd i jasny podział odpowiedzialności między IT, finanse i właścicieli biznesowych.

• Budżety i alerty w Cost Management na poziomie subskrypcji lub grup zasobów, z powiadomieniem do właściciela, a nie tylko do administratora
• Miesięczny przegląd rekomendacji Azure Advisor i listy zasobów bez wymaganych tagów
• Kwartalny przegląd wykorzystania rezerwacji i planów oszczędnościowych
• Raport kosztów według właściciela i środowiska, który trafia do osób decydujących o budżecie
• Zasada usuwania lub archiwizacji zasobów po dacie wygaśnięcia zapisanej w tagu

Taki proces nie wymaga dużego zespołu. Wystarczy jedna osoba, która pilnuje terminów, i zgoda kierownictwa, że koszt chmury jest odpowiedzialnością właściciela usługi, a nie wyłącznie działu IT. Wtedy rozmowa o kosztach przestaje być coroczną akcją ratunkową i staje się zwykłą częścią zarządzania usługami.

Chcecie wiedzieć, gdzie uciekają wasze koszty chmury?

Przejrzymy subskrypcje, tagi i zobowiązania, a potem wskażemy zmiany, które dają oszczędność bez przebudowy architektury.

Porozmawiaj z ekspertem