Broken bottles, broken plates,
Broken switches, broken gates,
Broken dishes, broken parts,
Streets are filled with broken hearts
Broken words never meant to be spoken,
Everything is broken

Seem like every time you stop and turn around
Something else just hit the ground

Tak śpiewał Bob Dylan. Czasami mam wrażenie, że opisuje stan niektórych produktów, które szczycą się pracą w trybie continuous deployment. Czy zwiększanie prędkości dostarczania kosztem czasu przeznaczonego na testowanie wiąże się z ciągle zepsutą produkcją?

Coraz odważniej wykorzystujemy produkcję i użytkowników naszych produktów, aby zrozumieć jak reagują na zmiany w systemie. Liczba testów A/B czy wykorzystywanych feature flag zwiększa się w szybkim tempie. Nie tylko wyciągamy wnioski na podstawie niezamierzonych błędów, ale też celowo eksperymentujemy z potencjalnie problematycznymi scenariuszami w ramach chaos engineeringu.

Dopóki nasz produkt nie znajdzie się na produkcji, nie jesteśmy w stanie z określić, jak jakościowo dobry jest. Muszą z niego zacząć korzystać prawdziwi ludzie, a nie nasze wyimaginowane persony, na podstawie których stworzyliśmy oczekiwane przypadki użycia. Chociaż staramy się przewidzieć rzeczywistość, często nasza wyobraźnia nie nadąża. Nasze oczekiwania mogą być zbyt optymistyczne, przez co nasz produkt ma np. problemy z udźwignięciem ruchu w godzinach szczytu. Czy też zbyt pesymistyczne, i nie jesteśmy w stanie potwierdzić wartości biznesowej przed zaadresowanym wszystkich potencjalnych ryzyk.

Eksperymentujemy, aby potwierdzić lub odrzucić nasze hipotezy. Eksperymentujemy często. Czy ze wzrostem liczby eksperymentów, nie kopiemy pod sobą coraz to większego doła? Czy czasami nie zniechęcamy użytkowników do produktu metodą tysiąca małych cięć?

Chcę opowiedzieć Wam o tym, jak dostosować formę eksperymentów do wymagań użytkowników. Dlaczego powinniśmy normalizować naukę na błędach i w jaki sposób może nam to pomóc w ograniczeniu powtarzalnych incydentów. Opowiem również o tym, jak reakcja organizacji na incydenty może wpłynąć na przyszłości produktu.

O ciągłej awarii opowiem z perspektywy osoby, która pełni funkcję moderatora incydentów oraz osoby współtworzącej narzędzie do monitorowania aplikacji na produkcji.

Chcę opowiedzieć Wam o tym, jak dostosować formę eksperymentów do wymagań użytkowników. Dlaczego powinniśmy normalizować naukę na błędach i w jaki sposób może nam to pomóc w ograniczeniu powtarzalnych incydentów.

Porozmawiamy o tym, jak reakcja organizacji na incydenty może wpłynąć na przyszłości produktu. Jak planować i zarządzać eksperymentami, mając na uwadze dobro użytkowników. A także dlaczego warto normalizować naukę na błędach i w jaki sposób może nam to pomóc w ograniczeniu powtarzalnych incydentów.

Powrót do agendy