Summary

Ten symulator wdrożenia kodu z AI pokazuje, jaką część 30-dniowego budżetu błędów zjada zła zmiana napisana przez AI, zanim zostanie cofnięta. Wpisz ruch, SLO, drabinkę wdrożenia, czas obserwacji i szybkość wykrycia. Porównuje jednorazowe wdrożenie na 100%, etapowe wdrożenie obserwowane przez człowieka oraz zautomatyzowaną bramkę SLO, na prostej arytmetyce, którą można sprawdzić ręcznie.

Bezpłatny planer wdrożeń

Symulator wdrożenia kodu z AI: jak daleko rozejdzie się zła zmiana przed cofnięciem

Wklej ruch, SLO i drabinkę wdrożenia. Narzędzie pokazuje, ile budżetu błędów zjada zła zmiana wygenerowana przez AI przy jednorazowym wdrożeniu, przy wykryciu przez człowieka na dashboardzie i przy zautomatyzowanej bramce.

Symulator wdrożenia kodu z AI

Każde pole zmienia wynik na żywo. Wartości domyślne opisują usługę obsługującą 200 żądań na sekundę, z SLO 99,9% i zmianę, która psuje 20% żądań.

Plan wdrożenia
EtapRuchStartŻądania obsłużone przez nowy kod
Jak to działa

Trzy działania arytmetyczne, bez ukrytego modelu

Budżet błędów

Budżet = (1 − SLO) razy średnia liczba żądań na sekundę razy 2,592,000 sekund w 30 dniach. Przy 200 żądaniach na sekundę i SLO 99.9% to 518,400 nieudanych żądań dopuszczalnych w miesiącu.

Ekspozycja w czasie

Drabinka określa udział ruchu obsługiwanego przez nowy kod w każdej minucie. Narzędzie całkuje ten udział od pierwszego żądania do chwili wykrycia plus czas cofnięcia, więc wolne wykrycie przepycha zmianę do późniejszych, większych etapów.

Nieudane żądania

Nieudane żądania = żądania na sekundę razy udział błędów razy całka ekspozycji. Podzielenie przez budżet daje procent miesiąca, który kosztuje jedna zła zmiana. Trzy tryby wykrywania są porównywane na tej samej drabince.

Użyj na prawdziwej zmianie

Od diffa wygenerowanego przez AI do planu wdrożenia

  1. 1

    Wybierz pesymistyczne dane wejściowe

    Dla zmiany napisanej przez generator kodu AI i pobieżnie przejrzanej przyjmij wysoki udział błędów, jeśli zmiana jest zła, oraz czas wykrycia przez człowieka odpowiadający najwolniejszemu ostatniemu incydentowi, a nie najlepszemu.

  2. 2

    Porównaj trzy scenariusze

    Jednorazowe wdrożenie pokazuje najgorszy przypadek. Etapowe wdrożenie z człowiekiem pokazuje, co drabinka daje dziś. Bramka SLO pokazuje, co zmieniłaby automatyczna bramka na metryce SLO.

  3. 3

    Skopiuj plan do runbooka

    Przycisk kopiowania eksportuje etapy i najgorsze zużycie budżetu jako zwykły tekst, gotowy do wklejenia w zgłoszenie zmiany lub opis pull requesta.

Dlaczego drabinka ma znaczenie

Pierwszy etap oszczędza większość budżetu

Zmiana, która psuje 20% żądań przy 1% ruchu, generuje błędy na 0,2% żądań. Ta sama zmiana przy 100% psuje co piąte żądanie. Różnica między tymi liczbami to cały argument za progresywnym wdrożeniem. Gdy kod pochodzi z generatora, który potrafi wyprodukować setki linii w kilka sekund, czas przeglądu na linię spada, a pierwszy etap staje się miejscem, w którym dowiadujesz się, że coś jest nie tak.

  • Pierwszy etap 1% ogranicza zasięg szkody o 99% zanim cokolwiek zostanie zmierzone.
  • Czas obserwacji pomaga tylko wtedy, gdy sygnał potrafi pokazać regresję w tym oknie.
  • Szybsze cofnięcie jest tyle samo warte co szybsze wykrycie: oba dokładają się do całki ekspozycji.
Szafa serwerowa z jedną bursztynową diodą wśród zielonych
Jak czytać wynik

Co zrobić z trzema liczbami

Jednorazowe wdrożenie

Jeśli ta liczba przekracza 5% miesięcznego budżetu dla wiarygodnej awarii, jednorazowe wdrożenie to decyzja o wydaniu budżetu na jedną zmianę. Niewiele zespołów podejmuje ją świadomie.

Etapowo, człowiek

Tak wygląda obecna rzeczywistość, jeśli dyżur patrzy na wykresy. Jeśli szczytowa ekspozycja pokazuje 100%, drabinka jest kosmetyczna: zła zmiana trafia do wszystkich, zanim ktokolwiek zareaguje.

Etapowo, bramka automatyczna

To argument za bramką, która czyta metrykę SLO i cofa zmianę bez pytania. Wartość jest realna tylko wtedy, gdy bramka reaguje na ten sam sygnał, na którym opiera się SLO, więc przetestuj ją celowo złą zmianą.

Częste pytania

Czy symulator wdrożenia kodu z AI jest darmowy?
Tak. Działa w całości w przeglądarce, nie wymaga rejestracji i nie wysyła nic na serwer poza anonimowym sygnałem użycia. Nie jest generatorem kodu AI: symuluje, jak daleko rozchodzi się zła zmiana, gdy kod z generatora trafi do potoku wdrożeniowego.
Skąd biorą się liczby?
Z arytmetyki, którą można sprawdzić ręcznie. Budżet błędów to (1 − SLO) razy liczba żądań w 30 dniach. Nieudane żądania to ruch razy udział błędów razy udział ruchu, który dostaje nowy kod, scałkowane do chwili zakończenia cofania. Żaden benchmark nie jest wpisany na stałe; każde założenie jest danym wejściowym.
Dlaczego kod z AI modelować inaczej niż kod napisany przez człowieka?
Matematyka jest identyczna. Zmienia się punkt wyjścia: duży diff wyprodukowany w kilka minut dostał mniej ludzkiego przeglądu na linię, więc udział błędów i czas wykrycia zasługują na pesymistyczne wartości. Ustaw je na podstawie własnej historii incydentów, a nie tej strony.
Co symulator zakłada, a czego prawdziwy ruch nie robi?
Zakłada stały ruch, regresję, która psuje ten sam udział żądań od pierwszego żądania, oraz cofnięcie, które natychmiast kończy szkodę po zakończeniu. Prawdziwe incydenty mają narastanie, częściowe awarie i wolne wycofywanie, więc traktuj wynik jako dolną granicę szkody, a nie prognozę.
Jaki czas wykrycia jest dobry dla zautomatyzowanej bramki SLO?
Zależy od rozdzielczości metryki i okna alertów. Bramka, która porównuje współczynnik błędów z jednej minuty z progiem, może zadziałać po dwóch do pięciu minutach. Jeśli alerty wysyłane są dopiero po 30-minutowym oknie burn-rate, wpisz tę wartość, a symulator pokaże, ile kosztuje.
Czy dłuższy czas obserwacji zawsze pomaga?
Nie. Dłuższa obserwacja daje bramce więcej danych na etap, ale też dłużej utrzymuje złą zmianę na danym udziale ruchu. Jeśli bramka reaguje w ciągu dwóch minut, dziesięciominutowa obserwacja głównie dodaje czekania. Jeśli potrzebuje piętnastu, pięciominutowa obserwacja pozwala zmianie najpierw dojść do 25% lub więcej.
Czy to narzędzie działa też dla flag funkcji, a nie tylko dla wdrożeń?
Tak. Procentowe wdrożenie flagi zachowuje się w tym rachunku tak samo jak wdrożenie kanarkowe: udział ruchu, czas obserwacji, opóźnienie wykrycia i czas cofnięcia. Zamiast czasu cofnięcia wpisz opóźnienie przełącznika awaryjnego flagi.

Chcesz, żeby bramka cofała zmiany za Ciebie?

upstreamapi prowadzi progresywne wdrożenia z bramkami SLO i automatycznym cofaniem, więc trzecia kolumna to ta, z którą wysyłasz kod.