Dostałem dziś, ewidentnie testowy, komunikat w swoim telefonie „MBank pozdrawia :)”. Internet zawrzał. MBank testuje na produkcji! Dlaczego tak się dzieje?

Przeanalizujmy konkretne scenariusze.

Scenariusz 1. To oprogramowanie tworzą studenci bez pojęcia

Pierwsza koncepcja jest taka, że to oprogramowanie jest tworzone przez niewykwalifikowany zespół, prawdopodobnie studentów. Nie było, by w tym nic dziwnego, gdyby nie kilka argumentów przeciw tej tezie.

  • Intuicyjna aplikacja – Jako użytkownik aplikacji MBanku muszę stwierdzić, że jest ona bardzo intuicyjna. Czy grupa studentów, byłaby w stanie wytworzyć tak dobrze skonstruowaną aplikację pod względem UX? Wątpię.
  • Duża skala – Jeżeli już spotkałeś się z dużą ilością użytkowników, wiesz, że to nigdy nie jest prosta sprawa do ogarnięcia. Owszem z czasem zdobywamy doświadczenie, aby móc przewidywać, gdzie i co może się wysypać, ale czy grupa studentów ma to doświadczenie? Raczej nie.
  • Ta prezentacja – Kiedyś byłem na spotkaniu Grupy WrocNet, gdzie występował Piotr Stapp. Opowiadał o tym co w MBanku siedzi. To nie są przypadkowe technologie, które utrzymują studenci. To jest kawał przemyślanego softu. Czyli, również nie studenci, a ja zapraszam do oglądnięcia.

Scenariusz 2. Testują na produkcji


Dziwne? Niestety, ale przy pewnej skali nie ma innego wyboru. Dlaczego? Zanim do tego przejdziemy, musimy przejść kilka kroków.

Przykład 1. Aplikacja hostowana na jednym serwerze

Wtedy sytuacja jest prosta. Chociażby z tego powodu, że prawdopodobnie używa jej mało osób. Nie o to chodzi. Aplikację działającą na jednym serwerze, jesteśmy w stanie szybko i małym nakładem pracy wdrożyć na środowisko, identycznie, lub prawie identyczne z produkcją.

Na takim środowisku odpalimy testy, integracyjne, e2e, wydajnościowe. Mamy więc czas, aby spokojnie przetestować tę aplikację ręcznie. Jeżeli stwierdzimy, że wszystko jest ok, świadomie awansujemy tę konkretną wersję na środowisko produkcyjne.

Niestety nie możemy zrobić tak zawsze.

Przykład 2. Aplikacja składająca się z kilku serwisów

W tym przykładzie mamy inną sytuację. Mianowicie aplikacja działa na kilku serwerach, ale z pewnymi ograniczeniami. Serwisów jest stosunkowo mało, więc możemy dość szybko odtworzyć działające środowisko zgodne z produkcją. Będzie to wymagać trochę zabawy, ale pomoże nam w tym między innymi podejście Infrastructure as a Code.

Taki zestaw serwisów, z czystym sumieniem, potraktujemy jak aplikację z przykładu pierwszego. Odpalimy testy automatyczne, jeżeli wszystko jest ok, to sprawdzamy manualne, a potem awansujemy aplikację. Wciąż wszystko wydaje się być stosunkowo proste i stabilne.

Przykład 3. System składa się z niezależnie rozwijanych serwisów

Mało tego! Są one nie tylko rozwijane niezależnie, ale również wdrażane niezależnie. Takie rozwiązanie ma wiele zalet i jest koniecznością przy dużej skali, jaką MBank już posiada. 

Takie rozwiązanie ma natomiast pewną wadę, bo praktycznie niemożliwe, jest odtworzenie aktualnego środowiska produkcyjnego. Dlaczego? 

  • bo różne serwisy mogą być w różnej skali
  • bo poszczególne serwisy mają różne konfiguracje zarządzane niezależnie
  • bo kod zmienia się bardzo często i niezależnie, więc synchronizacja jest ekstremalnie trudna

Co za tym idzie, praktycznie niemożliwe jest, gruntowne przetestowanie tego co za chwilę będzie na produkcji. 

Niestabilne i nietestowane?

Czy to znaczy, że aplikacje tego typu są niestabilne i nietestowane?

Niekoniecznie! Istnieje wiele mechanizmów zwiększających stabilność takiej struktury. Są to między innymi:

  • Testy automatyczne poszczególnych serwisów, aby się upewnić, że pojedyncze serwisy działają ok
  • Testy kontraktowe, aby upewnić się, że spełniamy kontrakty
  • Monitoring, jak poszczególne komponenty działają
  • Automatyczne rollbacki na podstawie monitoringu

Oczywiście błąd ludzi może wkraść się wszędzie i prawdopodobnie z nim mamy do czynienia w tej sytuacji. 

A Ty co o Tym myślisz? Daj mi znać w komentarzu

Kategorie: DevOps

2 Komentarze

Kuba · 5 sierpnia, 2020 o 18:20

A może komuś po prostu pomyliły się projekty na firebase czy czymś podobnym hmm? Od razu że ‚grupa studentów’, profesjonalny rekonesans 👌

    Jerzy Wickowski · 6 sierpnia, 2020 o 08:44

    Cześć @Kuba,

    Pewnie, że tak. Grupa studentów to najpopularniejsza przyczyna, o jakiej możemy przeczytać w internecie.
    Natomiast podejrzewam, że podłoże tego jest związane ze scenariuszem numer dwa, ale przyczyna to ewidentnie błąd ludzki.
    Bywa. Facebook i Google też mają takie wpadki, że coś nie tak pójdzie na produkcji. Również z tego samego powodu 🙂

Możliwość dodawania komentarzy nie jest dostępna.