Cześć!
Nazywam się Michaił, jestem wicedyrektorem ds. IT w firmie «Sportmaster». Chcę podzielić się historią o tym, jak poradziliśmy sobie z trudnościami, które pojawiły się podczas pandemii.
W pierwszych dniach nowych realiów tradycyjny format sprzedaży stacjonarnej «Sportmastera» zamarł, a obciążenie naszego kanału online, w szczególności w zakresie dostawy do klienta, wzrosło dziesięciokrotnie. W ciągu kilku tygodni przekształciliśmy ogromny, tradycyjny biznes w działalność online, dostosowując usługi do potrzeb naszych klientów.
W zasadzie to, co było naszą drugorzędną operacją, stało się głównym biznesem. Znaczenie każdego zamówienia internetowego wzrosło ekstremalnie. Musieliśmy zachować każdy rubel, który klient przynosił do firmy.
Aby szybko reagować na prośby klientów, otworzyliśmy dodatkowe centrum kontaktowe w głównym biurze firmy, dzięki czemu teraz możemy przyjmować około 285 tysięcy połączeń tygodniowo. Jednocześnie przekształciliśmy 270 sklepów w nowy format bezkontaktowej i bezpiecznej pracy, co pozwoliło klientom odbierać zamówienia, a pracownikom zachować miejsca pracy.
W procesie transformacji napotkaliśmy dwa główne problemy. Po pierwsze, znacznie wzrosło obciążenie naszych zasobów online (jak sobie z tym radziliśmy, opowie Siergiej). Po drugie, napływ rzadkich operacji (do COVID) wzrósł wielokrotnie, co z kolei wymagało dużego stopnia szybkiej automatyzacji. Aby rozwiązać ten problem, musieliśmy szybko przekierować zasoby z obszarów, które wcześniej były główne. Jak sobie z tym poradziliśmy — opowie Jelena.
Eksploatacja usług online
Siergiej Koliesnikow, odpowiedzialny za eksploatację sklepu internetowego i mikrousług
Od momentu, gdy nasze sklepy detaliczne zaczęły być zamykane dla odwiedzających, zaczęliśmy rejestrować wzrost takich wskaźników, jak liczba użytkowników, liczba zamówień składanych w naszej aplikacji, liczba zapytań do aplikacji.
Liczba zamówień od 18 do 31 marca
Liczba zapytań do mikrousług płatności online
Liczba zamówień złożonych na stronie
Na pierwszym wykresie widzimy, że wzrost wyniósł około 14 razy, na drugim — 4 razy. Uważamy, że najbardziej wymownym wskaźnikiem jest czas odpowiedzi naszych aplikacji.
Na tym wykresie widzimy odpowiedzi frontów i aplikacji, a także określiliśmy, że nie zauważyliśmy szczególnego wzrostu.
W pierwszej kolejności jest to związane z tym, że rozpoczęliśmy prace przygotowawcze pod koniec 2019 roku. Obecnie nasze usługi są zarezerwowane, zapewniona jest odporność na awarie na poziomie fizycznych serwerów, systemów wirtualizacji, kontenerów i usług w nich. Nasze moce serwerowe pozwalają na przetrwanie wielokrotnego obciążenia.
Podstawowym narzędziem, które pomogło nam w tej sytuacji, był nasz system monitorowania. Jeszcze niedawno nie mieliśmy jednego systemu, który pozwalałby zbierać metryki na wszystkich poziomach, od sprzętu fizycznego po metryki biznesowe.
Formalnie monitoring w firmie istniał, ale zazwyczaj był rozproszony i leżał w gestii konkretnych działów. W praktyce, gdy wydarzył się jakiś incydent, rzadko mieliśmy jednolite zrozumienie, co właściwie się wydarzyło; brakowało informacji, co często prowadziło do krążenia w poszukiwaniu i lokalizacji problemu do późniejszego usunięcia.
W pewnym momencie pomyśleliśmy i zdecydowaliśmy, że dość tego! Potrzebujemy jednego systemu, aby zobaczyć całość. Główne technologie, które wchodzą w nasz stos, to Zabbix jako centrum alertowania i magazynowania metryk, Prometheus do zbierania i przechowywania metryk aplikacji, Stack ELK do logowania i przechowywania danych całego systemu monitorowania oraz Grafana do wizualizacji, Swagger, Docker i inne użyteczne rzeczy, które są Wam znane.
Jednocześnie korzystamy nie tylko z dostępnych na rynku technologii, ale także opracowujemy coś samodzielnie. Na przykład tworzymy usługi do integracji systemów, czyli pewne API do zbierania metryk. Pracujemy również nad naszymi własnymi systemami monitorowania — na poziomie metryk biznesowych wykorzystujemy testy UI. A także bot w Telegramie do powiadamiania zespołów.
Staramy się również uczynić system monitorowania dostępnym dla zespołów, aby mogły samodzielnie przechowywać swoje metryki i pracować z nimi, a także konfigurować alerting w specyficznych metrykach, które mają zastosowanie o węższym znaczeniu.
W ramach całego systemu dążymy do proaktywności i jak najszybszej lokalizacji incydentów. Co więcej, liczba naszych mikrousług i systemów znacznie wzrosła w ostatnim czasie, a co za tym idzie, rośnie również liczba integracji. W ramach optymalizacji procesu diagnozowania incydentów na poziomie integracji opracowujemy system, który umożliwia przeprowadzanie testów między systemami i przedstawianie wyników, co pozwala na identyfikację głównych problemów związanych z importami i interakcją między systemami.
Oczywiście mamy jeszcze wiele do zrobienia i rozwoju w zakresie eksploatacji systemów i aktywnie nad tym pracujemy. Szczegóły dotyczące naszego systemu monitorowania można przeczytać .
Testy techniczne
Siergiej Orłow, kieruje centrum kompetencji w zakresie rozwoju aplikacji webowych i mobilnych
Od momentu zamknięcia fizycznych sklepów musieliśmy stawić czoła różnym wyzwaniom w zakresie rozwoju. Przede wszystkim przeskok obciążenia jako takiego. Jasne jest, że jeśli nie zostaną podjęte odpowiednie środki, przy wysokim obciążeniu system może z smutnym hukiem przemienić się w dynię, całkowicie degradując wydajność lub całkowicie tracąc swoją funkcjonalność.
Drugi aspekt, nieco mniej oczywisty, polega na tym, że system przy wysokim obciążeniu musiał być szybko zmieniany, dostosowując się do zmian w procesach biznesowych. Czasami kilka razy dziennie. W wielu firmach istnieje zasada, że przy intensywnych działaniach marketingowych nie należy wprowadzać żadnych zmian do systemu. W ogóle żadnych, niech działa, skoro działa.
A w naszym przypadku mieliśmy zasadniczo nieskończony czarny piątek, w trakcie którego jednak musieliśmy zmieniać system. Każdy błąd, problem czy awaria w systemie bardzo drogo kosztowałyby biznes.
Wyprzedzając fakty, powiem, że udało nam się poradzić sobie z tymi wyzwaniami, wszystkie systemy wytrzymały obciążenie, łatwo się skalowały i nie mieliśmy żadnych globalnych awarii technicznych.
Istnieją cztery filary, na których opiera się zdolność systemu do wytrzymywania wysokich, skokowych obciążeń. Pierwszym z nich jest monitorowanie, o którym wspomniałeś wcześniej. Bez dobrze zorganizowanego systemu monitorowania praktycznie niemożliwe jest zidentyfikowanie wąskich gardeł w systemie. Dobry system monitorowania to jak domowy strój — powinien być wygodny i dostosowany do Ciebie.
Drugim aspektem jest testowanie. Do tego podchodzimy bardzo poważnie: piszemy zarówno klasyczne testy jednostkowe, testy integracyjne, testy obciążeniowe oraz wiele innych dla każdego systemu. Pisujemy również strategię testowania, starając się doprowadzić poziom testowania do takiego, aby ręczne kontrole nie były nam już potrzebne.
Trzeci filar to CI/CD Pipeline. Procesy budowy, testowania i wdrażania aplikacji muszą być maksymalnie zautomatyzowane, nie powinno być ręcznych interwencji. Temat CI/CD Pipeline jest dość głęboki, więc wspomnę o nim tylko pobieżnie. Warto dodać, że posiadamy listę kontrolną CI/CD Pipeline, według której każda zespół produktowy współpracuje z centrami kompetencyjnymi.
Oto lista kontrolna
W ten sposób osiąga się wiele celów. Jest to wersjonowanie API, feature toggle, aby uniknąć nadmiaru wydania oraz osiągnięcie poziomu pokrycia różnych testów, tak aby testowanie było całkowicie zautomatyzowane, a wdrożenia były bezproblemowe i inne.
Czwarty filar to zasady architektoniczne i rozwiązania techniczne. O architekturze można mówić dużo i długo, ale chciałbym podkreślić kilka zasad, na których chciałbym skupić uwagę.
Po pierwsze, trzeba wybierać specjalistyczne narzędzia do konkretnych zadań. Tak, brzmi to oczywiście, i wiadomo, że gwoździe wbijamy młotkiem, a zegarki rozbieramy specjalnymi wkrętakami. Jednak w naszej epoce wiele narzędzi dąży do uniwersalizacji, aby objąć jak największy segment użytkowników: bazy danych, cache, frameworki i inne. Na przykład, jeśli weźmiemy bazę danych MongoDB, działa ona z wielodokumentowymi transakcjami, a baza danych Oracle obsługuje json-y. Wydawałoby się, że wszystko można wykorzystać do wszystkiego. Ale jeśli postulat wydajności jest dla nas kluczowy, musimy jasno rozumieć mocne i słabe strony każdego narzędzia i korzystać z tych, które są nam potrzebne dla naszego rodzaju zadań.
Po drugie, przy projektowaniu systemów każde zwiększenie złożoności powinno być uzasadnione. Musimy to stale mieć na uwadze, zasada low coupling jest powszechnie znana. Uważam, że powinno się ją stosować zarówno na poziomie konkretnej usługi, jak i całego systemu oraz architektonicznego krajobrazu. Również ważna jest zdolność do poziomego skalowania każdego komponentu systemu w trakcie obciążenia. Posiadając tę zdolność, skalowanie nie będzie żadnym problemem.
Jeśli chodzi o rozwiązania techniczne, poprosiliśmy zespoły produktowe o przygotowanie świeżego zestawu rekomendacji, pomysłów i rozwiązań, które wdrożyli w trakcie przygotowań do kolejnej fali obciążenia.
Cache
Należy świadomie podchodzić do wyboru lokalnych i rozproszonych cache. Czasami warto wykorzystać zarówno jedne, jak i drugie w ramach jednego systemu. Na przykład mamy systemy, w których część danych de facto jest witrynowym cache, to znaczy, że źródło aktualizacji znajduje się za samym systemem, a systemy tych danych nie zmieniają. Dla takiego podejścia używamy lokalnego cache Caffeine.
Są też dane, które system aktywnie zmienia w trakcie działania, i tu wykorzystujemy rozproszony cache z Hazelcast. Takie podejście pozwala nam korzystać z zalet rozproszonego cache tam, gdzie jest to naprawdę potrzebne, i minimalizować koszty serwisowe związane z cyrkulacją danych w klastrze Hazelcast tam, gdzie możemy się bez tego obejść. O cache pisaliśmy dużo. i .
Ponadto zmiana serializatora na Kryo w Hazelcast dała nam dobrą wydajność. A przejście z ReplicatedMap na IMap + Near Cache w Hazelcast pozwoliło nam zminimalizować ruch danych w klastrze.
Mała rada: przy masowej inwalidacji cache'a czasami można zastosować strategię podgrzewania drugiego cache'a przed przełączeniem na niego. Wydaje się, że w takim podejściu powinniśmy uzyskać podwójne zużycie pamięci, ale w praktyce w systemach, gdzie praktykowano takie rozwiązania, zużycie pamięci się zmniejszało.
Stos rekatywny
Używamy stosu reaktywnego w już dość dużej liczbie systemów. W naszym przypadku to Webflux lub Kotlin z korutynami. Szczególnie dobrze działa stos reaktywny tam, gdzie oczekujemy wolnych operacji wejścia-wyjścia. Na przykład, wywołania wolnych usług, praca z systemem plików lub systemami pamięci.
Najważniejszą zasadą jest unikanie blokujących wywołań. Pod maską reaktywnych frameworków działa niewielka liczba aktywnych wątków serwisowych. Jeśli nieostrożnie pozwolimy sobie na bezpośrednie blokujące wywołanie, takie jak wywołanie sterownika JDBC, system po prostu stanie.
Staraj się przekształcać błędy w własne wyjątkowe wyjątki czasowe. Rzeczywisty strumień wykonania programu odchodzi do reaktywnych frameworków, a wykonanie kodu staje się nieliniowe. W konsekwencji, bardzo trudno jest diagnozować problemy na podstawie stack trace'ów. Rozwiązaniem będzie stworzenie jasnych, obiektywnych wyjątków czasowych dla każdego błędu.
Elasticsearch
Podczas korzystania z Elasticsearch nie wybierać nieużywanych danych. To w zasadzie bardzo prosta rada, ale najczęściej właśnie o tym się zapomina. Jeśli trzeba wybrać więcej niż 10 tysięcy rekordów za jednym razem, należy użyć Scroll. Można to porównać do kursora w relacyjnej bazie danych.
Nie używaj postfilter bez potrzeby. Przy dużych danych w głównym zbiorze ta operacja bardzo obciąża bazę danych.
Używaj operacji hurtowych tam, gdzie to możliwe.
API
Projektując API, uwzględnij wymagania dotyczące minimalizacji przesyłanych danych. Jest to szczególnie istotne w połączeniu z frontem: to właśnie w tym miejscu wychodzimy poza kanały naszych centrów danych i już pracujemy na kanale, który łączy nas z klientem. Jeśli na nim wystąpią jakiekolwiek problemy, zbyt duży ruch powoduje negatywne doświadczenia użytkownika.
I w końcu, nie wypuszczaj całej masy danych, starannie podchodź do umowy między konsumentami a dostawcami.
Transformacja organizacyjna
Elena Eroshkina, zastępca dyrektora ds. IT
W momencie, gdy miała miejsce kwarantanna i pojawiła się potrzeba szybkiego zwiększenia tempa rozwoju online oraz wdrażania usług omnichannel, byliśmy już w trakcie transformacji organizacyjnej.
Część naszej struktury została przekształcona w pracę według zasad i praktyk podejścia produktowego. Utworzyły się zespoły, które teraz odpowiadają za działanie i rozwój każdego produktu. Pracownicy w takich zespołach są zaangażowani w 100% i organizują swoją pracę w metodologii Scrum lub Kanban, w zależności od tego, co jest dla nich bardziej komfortowe, konfigurują proces wdrażania, wdrażają praktyki techniczne, praktyki zapewnienia jakości i wiele innych.
Na szczęście większość takich zespołów produktowych znajdowała się w obszarze usług online i omnichannel. Pozwoliło nam to w krótkim czasie (serio, dosłownie w ciągu dwóch dni) przejść na tryb pracy zdalnej bez utraty efektywności. Ustalony proces pozwolił szybko dostosować się do nowych warunków pracy i utrzymać wystarczająco wysoki tempo dostarczania nowych funkcji.
Ponadto pojawiła się potrzeba wzmocnienia tych zespołów, które pracują w obszarze online biznesu. Wtedy stało się jasne, że możemy to zrobić jedynie z wykorzystaniem zasobów wewnętrznych. Około 50 osób w ciągu dwóch tygodni zmieniło obszar, w którym pracowały wcześniej, i włączyło się w pracę nad nowym dla nich produktem.
Nie było potrzeby podejmowania żadnych specjalnych wysiłków zarządzających, ponieważ obok organizacji własnego procesu, technicznego doskonalenia produktu oraz praktyki zapewnienia jakości, uczymy nasze zespoły samoorganizacji — zarządzania własnym procesem produkcyjnym bez zaangażowania zasobów administracyjnych.
Zasoby zarządzające skupiliśmy dokładnie tam, gdzie to było w danym momencie najbardziej potrzebne — na koordynacji z biznesem: Co jest teraz ważne dla naszego klienta, jaka funkcjonalność powinna być zrealizowana w pierwszej kolejności, co należy zrobić, aby zwiększyć naszą przepustowość w dostarczaniu i przetwarzaniu zamówień. Wszystko to oraz jasny model ról pozwoliły nam w tym okresie obciążyć nasze procesy produkcyjne tworzenia wartości tym, co naprawdę jest ważne i potrzebne.
Oczywiście, że przy pracy zdalnej i szybkim tempie zmian, kiedy od udziału każdego zależą wyniki biznesowe, nie można polegać tylko na wewnętrznych odczuciach, jak «Czy wszystko u nas idzie dobrze? Wydaje się, że nieźle». Potrzebne są obiektywne metryki procesu produkcyjnego. Takie mamy, są dostępne dla każdego, kto interesuje się metrykami zespołów produktowych. Przede wszystkim samego zespołu, biznesu, współpracowników i kierownictwa.
Co dwa tygodnie z każdym zespołem przeprowadzane są statusy, podczas których w ciągu 10 minut analizowane są metryki, identyfikowane są wąskie gardła procesu produkcyjnego i wypracowywane jest wspólne rozwiązanie: co można zrobić, aby te wąskie gardła usunąć. Można również natychmiast poprosić o pomoc kierownictwo w przypadku, gdy jakaś zidentyfikowana problematyka leży poza zasięgiem wpływu zespołów lub zwrócić się do kolegów z ekspertyzą, którzy być może już napotkali podobny problem.
Jednak rozumiemy, że aby znacznie przyspieszyć (a to jest cel, który sobie stawiamy), musimy jeszcze wiele się nauczyć i wdrożyć to w codzienną pracę. W tej chwili kontynuujemy skalowanie podejścia produktowego na inne zespoły i nowe produkty. W tym celu musieliśmy opanować nowy dla nas format szkoły online dla metodologów.
Metodolodzy, osoby które pomagają zespołom w budowaniu procesów, usprawnianiu komunikacji i zwiększaniu efektywności pracy, w istocie są agentami zmian. W tej chwili absolwenci naszego pierwszego kursu pracują z zespołami i pomagają im stać się skutecznymi.
Uważam, że obecna sytuacja otwiera przed nami możliwości i perspektywy, których być może jeszcze do końca nie dostrzegamy. Jednak doświadczenie i praktyka, które zdobywamy teraz, potwierdzają, że wybraliśmy właściwą drogę rozwoju, nie zmarnujemy tych nowych możliwości w przyszłości i będziemy w stanie skutecznie odpowiadać na wyzwania, które staną przed „Sportmasterem”.
Wnioski
W tym trudnym czasie sformułowaliśmy główne zasady, na których opiera się rozwój oprogramowania, które myślę, będą istotne dla każdej firmy, która się tym zajmuje.
Ludzie. To jest fundament. Pracownicy powinni czerpać przyjemność z pracy, rozumieć cele firmy oraz cele produktów, którymi się zajmują. I oczywiście powinni mieć możliwość profesjonalnego rozwoju.
Technologia. Konieczne jest, aby firma dojrzała w swoim podejściu do pracy z technologicznym stosem i rozwijała kompetencje tam, gdzie jest to rzeczywiście konieczne. Brzmi to bardzo prosto i oczywiście. I jest często ignorowane.
Procesy. Ważne jest, aby właściwie zorganizować pracę zespołów produktowych i centrów kompetencji oraz nawiązać współpracę z biznesem, aby traktować go jak partnera.
W skrócie, mniej więcej tak przetrwaliśmy. Główna teza współczesności potwierdziła się jeszcze raz, głośno uderzając w czoło.
Nawet jeśli jesteś ogromnym offline'owym biznesem z wieloma sklepami w wielu miastach, rozwijaj swoją obecność online. To nie jest tylko dodatkowy kanał sprzedaży czy ładna aplikacja, przez którą można coś kupić (a także dlatego, że konkurencja też ma ładna). To nie jest zapasowy plan na wypadek, który pomoże przetrwać burzę.
To rzeczywiście konieczność. Na którą muszą być gotowe nie tylko Twoje zasoby techniczne i infrastruktura, ale także ludzie i procesy. Szybkie dokupienie pamięci, miejsca, uruchomienie nowych instancji i innych rzeczy można zrealizować w ciągu kilku godzin. Ale ludzi i procesów należy przygotować na to wcześniej.
Źródło: habr.com
