Procesy i narzędzia DevOps na przykładzie retail

Dla wielu z nas pojęcie retail jest dość ogólnym hasłem. W świecie biznesu jest to dział gospodarki zajmujący się wszystkimi procesami, które wspierają i umożliwiają prowadzenie handlu detalicznego. Ale o co dokładniej chodzi?

Czym jest retail

Aby lepiej przybliżyć sedno tematu, wyobraźmy sobie następującą sytuację. Wchodzimy do dużego centrum handlowego, kierujemy się do naszego ulubionego sklepu, wybieramy upatrzone produkty i podchodzimy z nimi do kasy. Obsługa sklepowa skanuje produkt, używając czytnika kodów kreskowych, zostają nam naliczone różne rabaty na podstawie naszej karty lojalnościowej, dokonujemy płatności, drukowane są dla nas paragony, towar jest pakowany do torby i szczęśliwi wychodzimy z naszymi zakupami ze sklepu. Spora część z nas nie zdaje sobie sprawy, jak wiele procesów, mniej lub bardziej skomplikowanych, ma miejsce w trakcie realizacji takiej transakcji sprzedażowej i jakie systemy IT biorą w niej udział.

Modne ostatnio hasło DevOps często przedstawiane jest w bardzo technicznych szczegółach i nie zawsze mamy możliwość zrozumienia, czym tak naprawdę jest i za co odpowiada. W poniższym artykule postaram się odpowiedzieć na to pytanie, wykorzystując przykład branży retail.

Provisioning

Wróćmy na chwilę do naszego sklepu. Musiał istnieć proces, który umożliwił dokonanie takiej sprzedaży. Otóż w każdym sklepie znajduje się szereg stanowisk kasowych, składających się z komputera podobnego do naszych PC, wyposażonego w ekran dotykowy, skaner kodów kreskowych, drukarkę paragonów, czasami nawet czytnik paszportów i wagę. W zależności od rodzaju sklepu zestaw peryferiów może być mniej lub bardziej złożony.

Do tego zestawu dochodzą terminale płatnicze, umożliwiające finalizację sprzedaży. Wiedząc, że przeciętna większa sieć sprzedaży może mieć ok. 500 sklepów na całym świecie, a średniej wielkości sklep ok. 5 kas, w przybliżeniu daje nam to ok. 2500 urządzeń kasowych. Ponadto po kilka sztuk peryferiów kasowych, systemy spinające komunikację w sklepie, systemy centralne itd. Wszystkie te systemy ktoś kiedyś musiał zainstalować. Ktoś musi je także na bieżąco utrzymywać.

Otóż proces, który umożliwił wdrożenie tak dużej ilości urządzeń plus oprogramowania na nim działającego, nazywa się provisioningiem. Jest to podstawowy proces DevOps, który umożliwia początkową instalację systemu w danym sklepie na konkretnej maszynie. Przy takiej ilości kas w sieciach handlowych, ręczny provisioning (przygotowanie kas) nie wchodzi w grę. Zajęłoby to zbyt dużo czasu, a prawdopodobieństwo wystąpienia błędów podczas takiego procesu jest zbyt wysokie.

Zatem korzystamy z narzędzi DevOps, które automatyzują ten proces. Nie ma znaczenia, czy wykorzystamy narzędzia takie jak Ansible, Chef, Puppet, Docker, Rundeck, czy też skrypty itd. To jedynie narzędzia, a wszystko zależy od konkretnego przypadku. Ważne jest, abyśmy byli świadomi, że to właśnie proces provisioningu jest odpowiedzialny za instalację całej infrastruktury potrzebnej do dokonania sprzedaży. W naszych wdrożeniach wykorzystaliśmy Jenkins, Ansible, Docker i skrypty shellowe. Po wprowadzeniu automatyzacji czas instalacji jednej maszyny z dwóch godzin ręcznej pracy został zoptymalizowany do 20 minut w pełni automatycznego procesu.

Continuous Integration and Delivery

No dobrze, nasza sieć sprzedażowa jest zainstalowana w sposób automatyczny. Wykorzystaliśmy do tego nasze ulubione narzędzia automatyzujące DevOps. Problem jednak pojawia się, gdy w naszym środowisku sklepowym trzeba wdrożyć jakąś zmianę.

Czym jest zmiana?

Jest wszystkim, co modyfikuje  stan naszego zainstalowanego software’u. Może to być implementacja nowego procesu np. obsługi zwrotów, ale może to być także zwykłe dostarczenie poprawki błędu, który został wykryty w procesie developmentu. Jak zatem dostarczyć taką zmianę na produkcję (w naszym przypadku na ponad 2000 urządzeń sklepowych)? Każde przekształcenie  wprowadza ryzyko regresji. Może się okazać, że poprawiliśmy błąd, wprowadzając jednocześnie dwa kolejne. Aby temu zapobiec, powinniśmy ograniczyć ryzyko wprowadzania błędów do systemu. W tym celu wykorzystujemy drugi z procesów DevOps, a mianowicie Continuous Integration and Delivery.

Za pomocą narzędzi takich, jak SCM (Source Code Management), build serwera, narzędzi do statycznej analizy kodu, ponownie narzędzi automatyzujących typu Ansible, dostarczamy nowy build/release na szereg środowisk tzw. stagingowych, tak, aby w końcowym procesie zmiana znalazła się na produkcji (w naszym przypadku, aby została wgrana do systemów sklepowych). Ponownie dobór narzędzi zależy od konkretnego wdrożenia i osobistych preferencji, zatem sami zdecydujcie, które narzędzia DevOps są dla Was najlepsze.

Continuous Testing

Wyobraźmy sobie sytuację, w której przy użyciu naszych ulubionych narzędzi DevOps potrafimy już dokonywać provisioningu naszych maszyn sklepowych oraz sprawnie generować nowe wersje buildów, a także jesteśmy w stanie dostarczać je na wybrane środowiska stagingowe, a docelowo na produkcję.

Pominęliśmy jednak istotny aspekt - dostarczanie zmian, bez posiadania narzędzi do mierzenia jakości, jest bezcelowe. Nic nam po tym, że potrafimy w sposób automatyczny dostarczyć kilka buildów dziennie, jeśli wszystkie one są nie najlepszej jakości, a nasz system wciąż posiada krytyczne błędy. Czasami szybciej, nie znaczy lepiej.

Jednak nie po to budowaliśmy zautomatyzowane procesy DevOps, aby teraz manualnie testować każdy build. Ponownie ryzykowalibyśmy, że w procesie testowania pojawia się czynnik ludzki, który w konsekwencji zwiększa prawdopodobieństwo powstania kolejnych błędów. Dodatkowo pamiętajmy, że bardzo często do przetestowania mamy wiele różnych konfiguracji systemowych, zatem manualne testowanie jest dość kłopotliwe.

Kolejny proces DevOps, a mianowicie Continuous Testing zaprzęga narzędzia do automatycznych testów, tak aby dostarczyć jak najszybciej feedback mierzący jakość dostaw. To właśnie częste pozyskanie feedbacku w sposób zautomatyzowany jest celem procesu. Dobór narzędzi także i w tym obszarze będzie zależał od konkretnego wdrożenia. Celem jednak jest feedback, czyli jak najwcześniejsze wykrycie i usunięcie błędów i możliwość weryfikacji biznesowej dostarczonych zmian.

Configuration Management

Życie bywa skomplikowane... W momencie, gdy mamy do dostarczenia system składający się z kilku tysięcy maszyn i chcemy wdrożyć go w różnych regionach świata, może okazać się, że w niektórych krajach istnieje realna potrzeba dostosowania konfiguracji odpowiedniej  instancji systemu dla konkretnego kraju. Co gorsza, w przypadku retail może istnieć nawet potrzeba dostosowania konfiguracji na poziomie pojedynczego sklepu, a często samej kasy. Jak  więc zapewnić, aby nasz release/build był jak najbardziej generyczny, a jednocześnie jak najbardziej elastyczny i konfigurowalny? Musimy wykorzystać kolejny obszar DevOps - Configuration Management.

Przy użyciu gotowych rozwiązań lub przy wykorzystaniu rozwiązań typu custom, budujemy bazę konfiguracji. Ponownie, stosując automatykę, narzędzia typu Ansible, Chef, Puppet itp., dostarczamy poprawną konfigurację do naszych sklepów, a docelowo kas. Kolejny raz DevOps przyszedł nam z pomocą i pozwolił na dostarczenie zmian, tym razem konfiguracyjnych, do naszego środowiska produkcyjnego.

Monitoring

Wiemy z rachunku prawdopodobieństwa, że im większa ilość ruchomych części, tym większe szanse wystąpienia awarii. Zatem w przypadku naszych 2000 maszyn sklepowych prawdopodobieństwo wystąpienia różnego rodzaju defektu jest bardzo wysokie. Nic nam po częstych, automatycznych, dobrze przetestowanych buildach, jeśli nie będziemy ich mogli wgrać na nasze automatycznie zainstalowane środowisko w sytuacji, gdy komputery kasowe odmówią posłuszeństwa. Niektórzy pewnie pomyślą: jak to możliwe? Przecież dobrze zainstalowany system nie ma prawa ulec awarii, to jest przecież jak matematyka 2 + 2,  musi działać. Tak jak już wcześniej wspomniałem, życie lubi zaskakiwać.

Systemy retail są dość złożone. Zachodzą w nich całkiem skomplikowane procesy obliczeniowe, wymagające operowania na dużych ilościach danych. Często nie jesteśmy w stanie dokładnie przewidzieć, w którym momencie przepełni nam się np. dysk twardy, pojawi się wyciek pamięci, polityki bezpieczeństwa przyblokują nam kluczowy plik systemowy, ktoś omyłkowo lub celowo wyłączy kluczowy komponent systemu itd. Ponownie z pomocą przychodzą nam narzędzia DevOps.

Musimy sobie uświadomić, że jeśli środowisko nie jest należycie monitorowane, to wszystkie poprzednie procesy nie mają sensu, ponieważ nie mamy gdzie wgrać zmian, a tym samym nie jesteśmy w stanie osiągnąć naszego kluczowego celu – dostarczyć zmiany w jak najkrótszym czasie, przy zachowaniu jak najlepszej jakości. Ponownie w celu monitorowania środowisk możemy użyć różnych narzędzi. Jednym z lepszych darmowych rozwiązań jest np. Zabbix oraz Kibana lub Graylog. Wybór jak zwykle pozostawiam Wam.

Nowe trendy

Wszystkie wymienione w artykule procesy DevOps stosowane są praktycznie na co dzień. Występują one także w innych rodzajach systemów na mniejszą lub większą skalę. Zastanawiające jest jednak to, czy obecna architektura systemów retail oprze się nowoczesnym trendom typu PWA (Progressive Web Apps). Instalacja i utrzymanie środowisk składających się z kilku tysięcy maszyn jest podyktowana głównie wymogiem możliwości pracy offline, gdy jakość połączenia internetowego będzie niewystarczająca lub połączenie to ulegnie awarii.

Duzi retailerzy nie mogą sobie pozwolić na utratę wizerunku, gdy sklep przestanie funkcjonować tylko dlatego, że łącze internetowe uległo uszkodzeniu. Nowoczesne trendy typu Cloud czy PWA mogłyby zaadresować te wymagania. Sieć sklepowa może być zainstalowana w chmurze, natomiast pojedyncze kasy mają szansę działać jako aplikacje typu Progressive Web Apps. Moim zdaniem będzie to dominujący trend w projektowaniu nowoczesnych systemów typu retail. Wiele procesów DevOps zostanie dzięki temu podejściu znacznie uproszczone, powinny także spaść koszty utrzymania samej infrastruktury sklepowej.