Przejdź do treści

Popularne tematy
Według wyzwania
FinOps

Rachunek za chmurę maleje
nazwany zasób po nazwanym zasobie.

W CerteroX Cloud Management dwadzieścia sześć nazwanych kontroli działa na dwunastu platformach chmurowych i danych. Każde ustalenie to konkretny zasób, właściciel, który może zatwierdzić zmianę, i ustalony przez Państwa próg.

Warstwa nadzoru dba następnie o to, by marnotrawstwo nie odrosło.

Umów prezentację
Ukryj szczegóły techniczne

Przebieg optymalizacji

Poglądowe

Pula · inżynieria · ostatnie 24 godziny

Wykonano 26 z 26 kontroli

Instances in Stopped State for a Long Time zatrzymana ≥ 14 dni, nadal przydzielona
40
Obsolete Snapshot Chains obraz główny wyrejestrowany
7
Kubernetes Rightsizing żądania a obserwowane wykorzystanie
12 ns
Reserved Instances Opportunities stabilne użycie od 150 dni
18
Naruszenie korelacji tagów właściciel ustawiony, brak centrum kosztów
3

Każde ustalenie zawiera

próg · wykluczenia · pominięcia

W skrócie

Marnotrawstwo w chmurze to lista rzeczy, które ktoś może wyłączyć.

Rachunki za chmurę rosną, bo nikt nie widzi, które konkretnie serwery, bazy danych i zasoby pamięci masowej są bezczynne ani kto może je wyłączyć. Pulpity kosztów pokazują sumy według usług, więc uczestnicy spotkania zgadzają się, że marnotrawstwo istnieje, i rozchodzą się bez decyzji. CerteroX zamienia rachunek w imienną listę zasobów, każdy z właścicielem i zalecanym działaniem.

  • Koszt

    Koniec z wydatkami na rzeczy, z których nikt nie korzysta.

    Dwadzieścia sześć kontroli wyszukuje bezczynne, przewymiarowane i zapomniane zasoby na dwunastu platformach chmurowych i danych, a każde ustalenie mówi dokładnie, co zmienić.

  • Ryzyko

    Zmiany zatwierdza właściwa osoba.

    Każde ustalenie trafia do właściciela, który może je zatwierdzić, w granicach ustalonych przez Państwa limitów, więc oszczędności nigdy nie powstają kosztem czegoś, na czym opiera się działalność firmy.

  • Nakład pracy

    Porządków nie trzeba powtarzać.

    Polityki działają dalej po pierwszym przeglądzie, więc marnotrawstwo nie wraca po cichu po trzech miesiącach, a zespół nie zaczyna od zera co kwartał.

Problem

Każdy pulpit kosztów urywa się o jedno pytanie przed decyzją.

Działanie wymaga zasobu, właściciela i terminu. Koszty według usług nie dają żadnej z tych trzech rzeczy, więc spotkanie kończy się tam, gdzie się zaczęło.

29%

wydatków na chmurę to marnotrawstwo, po raz pierwszy od pięciu lat więcej niż rok wcześniej

Średnia branżowa, wyliczona na podstawie cudzego środowiska. W Państwa środowisku każdy jej punkt procentowy ma przypisaną nazwę zasobu.

  1. 01 brak właściciela, brak działania

    Wszyscy zgadzają się, że dopasowanie rozmiaru jest słuszne. Nikt nie ma prawa go zatwierdzić.

    Instancja należy do konta, które należy do zespołu zreorganizowanego w zeszłym roku. Bez właściciela ustalenie leży w backlogu, aż ktoś nazwie je długiem technicznym.

    Reguły przypisania z dziewięcioma typami warunków do automatycznego ustalania właściciela Cloud Management

  2. 02 projekt tagowania nigdy się nie kończy

    Standard tagowania to strona na wiki i czterdzieści procent zasobów.

    Alokacja czeka na program tagowania, który nigdy się nie zakończy, więc showback nigdy się nie zaczyna i nikt nie odczuwa kosztów tego, co uruchamia.

    Wirtualne tagowanie obliczane niezależnie od natywnych tagów chmury Cloud Management

  3. 03 rozmiar dobrany do żądań

    Kubernetes to jedna pozycja na fakturze i połowa klastra.

    Węzły są wymiarowane według żądań zadeklarowanych przez programistów. Klaster wykorzystuje jedną trzecią tego, co rezerwuje, a rachunek nie dzieli się według przestrzeni nazw.

    Koszt i wykorzystanie Kubernetes według przestrzeni nazw, węzła i usługi Cloud Management

  4. 04 oszczędność, która nie przetrwała

    Posprzątane w marcu. W czerwcu wróciło.

    Nic nie miało określonego czasu życia, nie ustawiono żadnego limitu i żadna polityka nie zadziałała, gdy ten sam typ zasobu pojawił się ponownie. Optymalizacja bez nadzoru to stały projekt powtarzany co kwartał.

    TTL zasobów z automatycznym egzekwowaniem cyklu życia Cloud Management

  5. Marnotrawstwo to lista, którą się przerabia, a potem polityka, która nie pozwala tej liście odbudować się.

CerteroX Cloud Management może pomóc

Umów prezentację
Co wykonuje pracę

Trzy z pięciu dyscyplin.

Każdy z nich działa samodzielnie i korzysta ze wspólnego modelu zasobów, więc elementy obejmujące kilka produktów nie wymagają prac integracyjnych.

Wyświetlane są pełne szczegóły techniczne. Można je wyłączyć, aby zobaczyć wersję skróconą.

Ukryj szczegóły techniczne
Jak to się faktycznie robi

Cztery kroki, a tylko jeden z nich to znalezienie marnotrawstwa.

Większość narzędzi realizuje drugi krok. Od pierwszego zależy, czy cokolwiek zostanie zrobione, a od czwartego, czy efekt się utrzyma.

  1. Przypisać każdy pounddollareuro

    Najpierw przypisanie właściciela, potem optymalizacja, bo ustalenie bez właściciela to tylko ciekawostka.

    • Pule kosztów typu budżet, jednostka biznesowa, zespół, projekt, CI/CD lub zasób Cloud Management
    • Reguły przypisania z dziewięcioma typami warunków do automatycznego ustalania właściciela Cloud Management
    • Wirtualne tagowanie obliczane niezależnie od natywnych tagów chmury Cloud Management
    • Natywna obsługa FOCUS, otwartej specyfikacji FinOps dotyczącej kosztów i użycia Cloud Management
    • Showback i chargeback oparte na pulach, ze stanami przekroczenia uwzględniającymi prognozę Cloud Management

  2. Znaleźć marnotrawstwo z nazwy

    Każde ustalenie to nazwana kontrola na nazwanym zasobie, wraz z progiem, który ją uruchomił. Nic nie jest raportowane jako „zidentyfikowane potencjalne oszczędności”.

    • Porzucone instancje, obrazy, load balancery, zasobniki S3 i strumienie Kinesis Cloud Management
    • Przestarzałe obrazy, adresy IP, migawki i łańcuchy migawek Cloud Management
    • Instancje zatrzymane, ale niezwolnione, oraz woluminy od dawna niepodłączone Cloud Management
    • Dopasowanie rozmiaru instancji i wykrywanie niedostatecznie wykorzystanych RDS Cloud Management
    • Dopasowanie rozmiaru w Kubernetes i wyszukiwarka duplikatów w magazynie obiektów Cloud Management
    • Progi dla poszczególnych kontroli, wykluczenia pul i pomijanie kont Cloud Management

  3. Zobowiązywać się we właściwym momencie

    Rabaty za zobowiązania to największa pojedyncza dźwignia i najłatwiej kupić je z sześciomiesięcznym opóźnieniem.

    • Analiza pokrycia przez Reserved Instances i Savings Plans Cloud Management
    • Możliwości zakupu Reserved Instances i Savings Plans Cloud Management
    • Możliwości przejścia na nowszą generację instancji i migracji między regionami Cloud Management
    • Krótko żyjące instancje oznaczane jako kandydaci do instancji spot i preemptible Cloud Management
    • Harmonogramy zasilania maszyn wirtualnych do automatycznego uruchamiania i zatrzymywania Cloud Management

  4. Utrzymać efekty

    To ta połowa FinOps, którą większość narzędzi pomija: polityka, która działa, zanim przyjdzie faktura.

    • TTL zasobów z automatycznym egzekwowaniem cyklu życia Cloud Management
    • Całkowite i dzienne limity wydatków na zasób lub pulę Cloud Management
    • Wykrywanie anomalii wydatków względem kroczącej średniej dziennej Cloud Management
    • Zgodność tagów: tagi wymagane, tagi zakazane i reguły korelacji Cloud Management
    • Wykrywanie anomalii liczby zasobów i polityki limitów zasobów Cloud Management
    • Historia naruszeń ograniczeń i śledzenie wykrytych ograniczeń Cloud Management

Można poprosić o pokazanie dowolnej z tych funkcji w działaniu w samym produkcie, na ekranie, na którym to się dzieje.

Stan docelowy

Jak wygląda dobry stan.

Dojrzałą praktykę FinOps poznaje się po spotkaniach. Nikt nie spiera się o sumę.

  1. 01

    Każde ustalenie ma nazwę i właściciela.

    Abandoned Kinesis Streams, dokładnie pod tą nazwą. Zasób, pula, do której należy, i osoba, która może zatwierdzić zmianę, znajdują się w tym samym wierszu.

  2. 02

    Każda kontrola ma własny próg.

    Progi, wykluczenia pul i pominięcia kont ustawia się dla każdej kontroli osobno, więc zasoby odtwarzania po awarii przestają generować ustalenia, a nikt nie musi wyłączać kontroli, która chroni całą resztę.

  3. 03

    Alokacja nie czeka na tagowanie.

    Tagi wirtualne są wyliczane już dziś na podstawie konta, regionu, usługi, wzorca nazwy lub właściciela, a polityka tagowania stopniowo porządkuje rzeczywiste tagi.

  4. 04

    Sprzątania nie trzeba powtarzać.

    TTL kończy życie piaskownicy, limity wydatków ograniczają pulę, wykrywanie anomalii wychwytuje skok, a historia naruszeń pokazuje dokładnie, co zadziałało i kiedy.

  5. 05

    Model kosztów przetrwa zmianę dostawcy.

    Dane FOCUS są pobierane natywnie i można je odpytywać bezpośrednio, więc model kosztów to otwarty standard, który należy do Państwa.

Ograniczanie marnotrawstwa w chmurze: najczęstsze pytania

Najczęściej zadawane pytania

Chcą Państwo zadać inne pytanie?

Skontaktuj się
Korzystamy już z natywnych narzędzi kosztowych w każdej chmurze. Co to wnosi?

Narzędzia natywne świetnie działają w swoich granicach i nie widzą niczego poza nimi. Tu powstaje jeden model kosztów dla dwunastu platform chmurowych i danych, w tym Kubernetes, Databricks i Snowflake, z jednym schematem alokacji, jednym silnikiem polityk i jednym zestawem rekomendacji. Wykonywane są też kontrole, których nie prowadzą konsole rozliczeniowe: łańcuchy migawek, porzucone strumienie, instancje zatrzymane, ale nie zwolnione, krótko działające kandydatki do instancji spot.

Nasze tagowanie to chaos. Czy musimy je najpierw uporządkować?

Nie. Tagi wirtualne są wyliczane niezależnie od natywnych tagów chmurowych, więc alokacja od pierwszego dnia działa na podstawie konta, regionu, usługi, wzorca nazwy lub właściciela. Polityka zgodności tagów (tagi wymagane, tagi zabronione i reguły korelacji) porządkuje następnie bałagan w tle.

Jak sprawić, by programiści nie traktowali tego jako narzuconego im cięcia kosztów?

Wystarczy dać im pulę i budżet. Pule kosztów mają typy: budżet, jednostka biznesowa, zespół, projekt, CI/CD lub zasób, każdy z własnym budżetem, progami i alertami w Slack. Dzięki współdzielonym środowiskom z rezerwacjami, kluczami SSH i webhookami CI/CD ten sam system, który ich rozlicza, zapewnia im też środowisko testowe.

Czy to rzeczywiście obejmuje Kubernetes, czy tylko węzły pod nim?

Koszty i wykorzystanie są rozbijane według przestrzeni nazw, węzłów i usług, a dopasowanie rozmiaru w Kubernetes to jedna z dwudziestu sześciu nazwanych kontroli, bo klastry niemal zawsze są wymiarowane według zadeklarowanych żądań, znacznie powyżej tego, co pody faktycznie zużywają. Do przestrzeni nazw stosuje się te same pule, budżety i polityki co do subskrypcji.

A co z wydatkami na GPU? To nasza najszybciej rosnąca pozycja.

Executory ML to instancje chmurowe, więc wykrywanie porzuconych zasobów, dopasowanie rozmiaru, przejście na nowszą generację i migracja do instancji spot obejmują je automatycznie, a obciążenia ML/AI mogą mieć własne pule kosztów i budżety. To CerteroX AI Management na tym samym silniku.

Powiązane

Ten sam model zasobów, inne pytanie.

Zobacz platformę
Wszystkie dwadzieścia sześć kontroli w działaniu

Zobaczą Państwo kontrole w działaniu.
Wyjdą Państwo z listą nazw.

Wypełnione danymi środowisko chmurowe w rzeczywistej skali, omawiane ustalenie po ustaleniu: kontrola po kontroli, zasób po zasobie, właściciel po właścicielu. Prosimy powiedzieć, z jakich platform Państwo korzystają i z którą z dwudziestu sześciu kontroli chcieliby Państwo polemizować.

Umów sesję roboczą

Bez zobowiązań i bez PDF-a za formularzem. Wszystkie dwadzieścia sześć kontroli i osoba podczas rozmowy, która odpowie na pytania o każdą z nich.