Hi!
Nazywam się Michaił i jestem zastępcą dyrektora ds. IT w firmie Sportmaster. Chcę się podzielić historią o tym, jak poradziliśmy sobie z wyzwaniami, które pojawiły się podczas pandemii.
W pierwszych dniach nowej rzeczywistości dotychczasowy format handlu offline w Sportmasterze zamarł, a obciążenie naszego kanału online, przede wszystkim w zakresie dostaw na adres klienta, wzrosło dziesięciokrotnie. W ciągu zaledwie kilku tygodni przekształciliśmy gigantyczny biznes offline w biznes online i dostosowaliśmy usługę do potrzeb naszych klientów.
W zasadzie to, co było w zasadzie naszą działalnością poboczną, stało się naszym głównym biznesem. Znaczenie każdego zamówienia online dramatycznie wzrosło. Trzeba było oszczędzać każdą rubelkę, którą klient przynosił do firmy.
Aby móc szybko reagować na zapytania klientów, otworzyliśmy dodatkowe centrum kontaktowe w siedzibie głównej firmy. Obecnie możemy odbierać około 285 tysięcy połączeń tygodniowo. Jednocześnie przeszliśmy na nowy, bezkontaktowy i bezpieczny format działania 270 sklepów, co pozwoliło klientom na przyjmowanie zamówień, a pracownikom na zachowanie miejsc pracy.
W trakcie procesu transformacji napotkaliśmy dwa główne problemy. Po pierwsze, obciążenie naszych zasobów internetowych wyraźnie wzrosło (Siergiej opowie, jak sobie z tym poradziliśmy). Po drugie, przepływ rzadkich operacji (sprzed COVID-19) wzrósł wielokrotnie, co z kolei wymagało dużej ilości szybkiej automatyzacji. Aby rozwiązać ten problem musieliśmy szybko przenieść zasoby z obszarów, które wcześniej były główne. Elena opowie nam, jak sobie z tym poradziliśmy.
Działanie usług online
Kolesnikov Sergey, odpowiedzialny za działanie sklepu internetowego i mikrousług
Od kiedy nasze sklepy detaliczne zaczęły być zamykane dla klientów, zaobserwowaliśmy wzrost takich wskaźników, jak liczba użytkowników, liczba zamówień złożonych w naszej aplikacji i liczba żądań aplikacji.
Liczba zamówień od 18 do 31 marca
Liczba żądań do mikrousług płatności online
Liczba zamówień złożonych na stronie internetowej
Na pierwszym wykresie widzimy, że wzrost wyniósł około 14 razy, na drugim – 4 razy. Uważamy, że wskaźnik czasu reakcji naszych aplikacji jest najbardziej orientacyjny.
Na tym wykresie widzimy reakcję frontów i aplikacji, a w naszym przypadku stwierdziliśmy, że nie zaobserwowaliśmy żadnego wzrostu jako takiego.
Wynika to przede wszystkim z faktu, że prace przygotowawcze rozpoczęliśmy pod koniec 2019 roku. Teraz nasze usługi są zabezpieczone, odporność na błędy jest zapewniona na poziomie serwerów fizycznych, systemów wirtualizacji, dokerów i usług w nich zawartych. Jednocześnie zasoby naszych serwerów pozwalają nam wytrzymać wielokrotne obciążenia.
Głównym narzędziem, które nam w tym pomogło, był nasz system monitorowania. Prawdą jest, że do niedawna nie mieliśmy ani jednego systemu, który pozwalałby nam zbierać dane na wszystkich poziomach – od poziomu sprzętu fizycznego i sprzętowego po poziom danych biznesowych.
Formalnie w firmie istniał monitoring, ale z reguły był on rozproszony i mieścił się w zakresie odpowiedzialności poszczególnych działów. W rzeczywistości, gdy dochodziło do jakiegoś incydentu, prawie nigdy nie mieliśmy wspólnego zrozumienia, co dokładnie się stało, nie było komunikacji, a często prowadziło to do biegania w kółko, próbowania znalezienia i zlokalizowania problemu, aby można go było rozwiązać.
W pewnym momencie pomyśleliśmy i stwierdziliśmy, że mamy już tego dość – potrzebujemy jednego systemu, który pozwoli nam zobaczyć cały obraz. Główne technologie wchodzące w skład naszego stosu to Zabbix jako centrum powiadamiania i przechowywania metryk, Prometheus do zbierania i przechowywania metryk aplikacji, Stack ELK do rejestrowania i przechowywania danych dla całego systemu monitorowania, a także Grafana do wizualizacji, Swagger, Docker i inne przydatne i znane rzeczy.
Wykorzystujemy przy tym nie tylko technologie dostępne na rynku, ale także sami opracowujemy niektóre rozwiązania. Tworzymy na przykład usługi integrujące systemy ze sobą, czyli pewnego rodzaju API do zbierania metryk. Ponadto pracujemy nad własnymi systemami monitorowania — na poziomie wskaźników biznesowych korzystamy z testów interfejsu użytkownika. Oraz bot Telegram do powiadomień zespołowych.
Staramy się również udostępnić zespołom system monitorowania, aby mogły niezależnie przechowywać swoje metryki i pracować z nimi, w tym konfigurować alerty dotyczące wąskich metryk, które nie mają najszerszego zastosowania.
W ramach całego systemu staramy się działać proaktywnie i lokalizować incydenty tak szybko, jak to możliwe. Ponadto liczba naszych mikrousług i systemów znacząco wzrosła w ostatnich latach, a wraz z nią wzrosła również liczba integracji. A w ramach optymalizacji procesu diagnozowania incydentów na poziomie integracji opracowujemy system umożliwiający przeprowadzanie kontroli międzysystemowych i wyświetlanie wyników, co pozwala na znalezienie głównych problemów związanych z importami i interakcjami między systemami.
Oczywiście, nadal mamy pole do rozwoju i rozwoju pod względem systemów operacyjnych i aktywnie nad tym pracujemy. Więcej o naszym systemie monitoringu możesz przeczytać tutaj .
Testy techniczne
Orlov Sergey, szef Centrum Kompetencji Rozwoju Sieci i Mobilności
Od czasu zamknięcia sklepów stacjonarnych stanęliśmy w obliczu różnych wyzwań związanych z rozwojem. Po pierwsze, sam wzrost obciążenia. Oczywiste jest, że jeśli nie zostaną podjęte odpowiednie środki, to przy dużym obciążeniu systemu może on albo zamienić się w smutną dynię z hukiem, albo całkowicie pogorszyć swoją wydajność, a nawet stracić funkcjonalność.
Drugim aspektem, nieco mniej oczywistym, jest konieczność bardzo szybkiej zmiany systemu pod dużym obciążeniem w celu dostosowania go do zmian w procesach biznesowych. Czasami kilka razy dziennie. Wiele firm kieruje się zasadą, że w przypadku dużych działań marketingowych nie należy wprowadzać żadnych zmian w systemie. Żadnego. Niech działa, jeśli działa.
I tak naprawdę mieliśmy niekończący się Czarny Piątek, podczas którego musieliśmy zmienić system. A każdy błąd, problem lub awaria w systemie będzie bardzo kosztowna dla firmy.
Patrząc w przyszłość, mogę powiedzieć, że poradziliśmy sobie z tymi testami, wszystkie systemy wytrzymały obciążenie, łatwo dało się je skalować i nie mieliśmy żadnych globalnych awarii technicznych.
Istnieją cztery filary, na których opiera się zdolność systemu do wytrzymywania dużych, okresowych obciążeń. Pierwszym z nich jest monitoring, o którym przeczytałeś powyżej. Bez dobrze funkcjonującego systemu monitorowania praktycznie niemożliwe jest znalezienie wąskich gardeł w systemie. Dobry system monitorujący jest jak domowe ubranie: powinien być wygodny i dopasowany do Ciebie.
Drugim aspektem jest testowanie. Podchodzimy do tego punktu bardzo poważnie: piszemy klasyczne jednostki, testy integracyjne, testy obciążeniowe i wiele innych dla każdego systemu. Opracowujemy również strategię testowania i jednocześnie staramy się doprowadzić testowanie do takiego poziomu, aby ręczne sprawdzanie nie było już konieczne.
Trzecim filarem jest proces CI/CD. Procesy montażu, testowania i wdrażania aplikacji powinny być jak najbardziej zautomatyzowane; nie powinno być żadnej ręcznej interwencji. Temat CI/CD jest dość obszerny, więc wspomnę tylko o nim krótko. Warto wspomnieć, że mamy listę kontrolną procesu CI/CD, którą każdy zespół produktowy przegląda przy pomocy centrów kompetencji.
A oto lista kontrolna
W ten sposób osiąga się wiele celów. Chodzi o wersjonowanie interfejsu API i przełączanie funkcji, które pozwalają uniknąć kolejkowania wydań i osiągnąć taki poziom pokrycia różnych testów, że testowanie jest w pełni zautomatyzowane, wdrożenia przebiegają bezproblemowo itd.
Czwartym filarem są zasady architektoniczne i rozwiązania techniczne. O architekturze można by mówić długo, ale chciałbym podkreślić kilka zasad, na których chciałbym się skupić.
Po pierwsze, należy wybrać specjalistyczne narzędzia do konkretnych zadań. Tak, brzmi to oczywiste i jasne jest, że gwoździe należy wbijać młotkiem, a zegarki rozbierać specjalnymi śrubokrętami. Jednak w dzisiejszych czasach wiele narzędzi dąży do uniwersalności, aby objąć swoim zasięgiem jak najszerszą grupę użytkowników: bazy danych, pamięci podręczne, frameworki i resztę. Na przykład, jeśli weźmiemy bazę danych MongoDB, obsługuje ona transakcje obejmujące wiele dokumentów, a baza danych Oracle obsługuje format json. Wydawałoby się, że wszystko można wykorzystać do wszystkiego. Jeśli jednak zależy nam na produktywności, musimy dokładnie zrozumieć mocne i słabe strony każdego narzędzia i wykorzystywać te, które są nam potrzebne do danego rodzaju zadań.
Po drugie, przy projektowaniu systemów każdy wzrost złożoności musi być uzasadniony. Musimy o tym stale pamiętać, zasada niskiego sprzężenia jest znana każdemu. Uważam, że należy je stosować na poziomie konkretnej usługi, na poziomie całego systemu i na poziomie krajobrazu architektonicznego. Ważna jest również możliwość poziomego skalowania każdego komponentu systemu wzdłuż ścieżki obciążenia. Jeśli posiadasz taką umiejętność, skalowanie będzie dziecinnie proste.
Od strony technicznej zwróciliśmy się do zespołów produktowych z prośbą o przedstawienie nowego zestawu rekomendacji, pomysłów i rozwiązań, które zostaną wdrożone w ramach przygotowań do kolejnej fali obciążenia.
Keshi
Należy świadomie wybierać pamięci podręczne lokalne i rozproszone. Czasami ma sens używanie obu w tym samym systemie. Mamy na przykład systemy, w których część danych stanowi w zasadzie pamięć podręczną sklepu, co oznacza, że źródło aktualizacji znajduje się poza samym systemem, a systemy nie zmieniają tych danych. W tym podejściu wykorzystujemy lokalną pamięć podręczną kofeiny.
Istnieją jednak dane, które system aktywnie zmienia w trakcie działania, i tutaj wykorzystujemy już rozproszoną pamięć podręczną z Hazelcast. Dzięki takiemu podejściu możemy skorzystać z rozproszonej pamięci podręcznej tam, gdzie jej naprawdę potrzebujemy, i zminimalizować koszty obsługi związanej z rozpowszechnianiem danych klastra Hazelcast tam, gdzie możemy się bez niej obejść. Dużo pisaliśmy o skrytkach и .
Ponadto zmiana serializatora na Kryo w Hazelcast dała nam niezłego kopa. Przejście z ReplicatedMap na IMap + Near Cache w Hazelcast pozwoliło nam zminimalizować przepływ danych w obrębie klastra.
Mała wskazówka: w przypadku masowego unieważniania pamięci podręcznej, czasami można zastosować taktykę polegającą na rozgrzaniu drugiej pamięci podręcznej, a następnie przełączeniu się na nią. Wydawałoby się, że przy takim podejściu powinniśmy uzyskać dwukrotnie większe zużycie pamięci, ale w praktyce w systemach, w których stosowano tę metodę, zużycie pamięci spadało.
Stos reaktywny
Stos reaktywny wykorzystujemy już w całkiem sporej liczbie systemów. W naszym przypadku jest to Webflux lub Kotlin z współprogramami. Stos reaktywny sprawdza się szczególnie wtedy, gdy spodziewamy się powolnych operacji wejścia-wyjścia. Na przykład połączenia z wolnymi usługami pracującymi z systemem plików lub systemami pamięci masowej.
Najważniejszą zasadą jest unikanie blokowania połączeń. W tle reaktywnych frameworków działa niewielka liczba wątków usług na żywo. Jeśli nieumyślnie pozwolimy sobie na wykonanie bezpośredniego wywołania blokującego, np. wywołania sterownika JDBC, system po prostu się zatrzyma.
Spróbuj przekształcić błędy w osobne wyjątki czasu wykonania. Rzeczywisty przebieg wykonywania programu przenosi się do reaktywnych struktur, wykonywanie kodu staje się nieliniowe. W rezultacie diagnozowanie problemów na podstawie śladów stosu jest bardzo trudne. Rozwiązaniem w tym przypadku będzie utworzenie jasnych, obiektywnych wyjątków czasu wykonania dla każdego błędu.
Elasticsearch
Podczas korzystania z Elasticsearch nie wybieraj nieużywanych danych. To jest w zasadzie bardzo prosta rada, ale najczęściej ludzie o niej zapominają. Jeśli chcesz zaznaczyć więcej niż 10 tysięcy rekordów na raz, musisz użyć funkcji Przewijanie. Jeśli posłużyć się analogią, można to porównać do kursora w relacyjnej bazie danych.
Nie używaj postfiltra, jeżeli nie jest to konieczne. Ze względu na dużą ilość danych w próbce głównej operacja ta znacznie obciąża bazę danych.
W miarę możliwości należy stosować operacje zbiorcze.
API
Projektując API, należy uwzględnić wymagania dotyczące minimalizacji ilości przesyłanych danych. Jest to szczególnie istotne w kontekście frontu: to właśnie na tym skrzyżowaniu wychodzimy poza kanały naszych centrów danych i pracujemy już nad kanałem, który łączy nas z klientem. Jeśli pojawią się choćby najmniejsze problemy, zbyt duży ruch będzie negatywnie wpływał na doświadczenia użytkowników.
I na koniec: nie podawaj zbyt wielu danych i jasno określ umowę między konsumentem a dostawcą.
Transformacja organizacyjna
Eroshkina Elena, zastępca dyrektora ds. IT
Kiedy nadeszła kwarantanna i pojawiła się potrzeba gwałtownego przyspieszenia rozwoju sprzedaży online oraz wprowadzenia usług wielokanałowych, byliśmy już w trakcie transformacji organizacyjnej.
Część naszej struktury została przeniesiona do pracy według zasad i praktyk podejścia produktowego. Utworzono zespoły, które odpowiadają za funkcjonowanie i rozwój każdego produktu. Pracownicy w takich zespołach są w 100% zaangażowani i pracują zgodnie ze Scrum lub Kanban, w zależności od tego, co jest dla nich wygodniejsze, ustalają proces wdrażania, wdrażają praktyki techniczne, praktyki zapewniania jakości i wiele więcej.
Szczęśliwym zbiegiem okoliczności większość takich zespołów produktowych zlokalizowana była w obszarze usług online i omnichannel. Dzięki temu mogliśmy przejść na pracę zdalną w najkrótszym możliwym czasie (naprawdę, dosłownie w dwa dni) bez utraty efektywności. Skonfigurowany proces pozwolił nam na szybkie dostosowanie się do nowych warunków pracy i utrzymanie dość wysokiego tempa dostarczania nowych funkcjonalności.
Ponadto poczuliśmy potrzebę wzmocnienia zespołów, które są na pierwszej linii biznesu online. W tym momencie stało się jasne, że możemy tego dokonać tylko przy wykorzystaniu zasobów wewnętrznych. W ciągu dwóch tygodni około 50 osób zmieniło obszar, w którym wcześniej pracowało, i zaangażowało się w pracę nad produktem, który był dla nich nowością.
Nie wymagało to żadnych szczególnych wysiłków zarządczych, ponieważ oprócz organizowania własnych procesów, technicznego udoskonalania produktu i praktyk zapewnienia jakości, uczymy nasze zespoły samoorganizacji - zarządzania własnym procesem produkcyjnym bez angażowania zasobów administracyjnych.
Udało nam się skoncentrować nasze zasoby zarządcze dokładnie tam, gdzie były potrzebne w danym momencie - na koordynacji z biznesem: co dokładnie jest teraz ważne dla naszego klienta, jakie funkcjonalności należy wdrożyć w pierwszej kolejności, co należy zrobić, aby zwiększyć nasze możliwości w zakresie dostaw i przetwarzania zamówień. Wszystko to, jak również wyraźny wzór do naśladowania, pozwoliły nam w tym okresie napełnić nasze przepływy tworzenia wartości produkcyjnej tym, co jest naprawdę ważne i konieczne.
Jasne jest, że przy pracy zdalnej i szybkim tempie zmian, gdy wskaźniki biznesowe zależą od udziału wszystkich, nie można polegać wyłącznie na wewnętrznych odczuciach, takich jak „Czy wszystko idzie nam dobrze?” „Tak, wydaje się całkiem nieźle”. Potrzebne są obiektywne wskaźniki procesu produkcyjnego. Mamy je, są dostępne dla każdego zainteresowanego wskaźnikami zespołu produktowego. Przede wszystkim dla samego zespołu, biznesu, partnerów i kierownictwa.
Co dwa tygodnie odbywa się spotkanie statusowe z każdym zespołem, podczas którego przez 10 minut analizuje się wskaźniki, identyfikuje wąskie gardła w procesie produkcyjnym i opracowuje wspólne rozwiązanie: co można zrobić, aby wyeliminować te wąskie gardła. Tutaj możesz natychmiast zwrócić się o pomoc do kierownictwa, jeśli jakiś zidentyfikowany problem wykracza poza zakres wpływu zespołu, lub o wiedzę specjalistyczną współpracowników, którzy być może już zetknęli się z podobnym problemem.
Rozumiemy jednak, że aby osiągnąć wielokrotne przyspieszenie (a taki cel sobie postawiliśmy), musimy się jeszcze wiele nauczyć i wdrożyć to w naszą codzienną pracę. Aktualnie kontynuujemy rozszerzanie podejścia produktowego na inne zespoły i nowe produkty. Aby to zrobić, musieliśmy opanować nowy format: internetową szkołę metodyków.
Metodycy, czyli osoby pomagające zespołom budować procesy, nawiązywać komunikację i zwiększać wydajność pracy, są w zasadzie agentami zmian. Absolwenci naszego pierwszego rocznika pracują obecnie w zespołach i pomagają im odnieść sukces.
Myślę, że obecna sytuacja otwiera przed nami szanse i perspektywy, których być może sami jeszcze do końca nie jesteśmy świadomi. Jednak doświadczenie i praktyka, które zdobywamy już teraz, potwierdzają, że wybraliśmy właściwą drogę rozwoju, nie zmarnujemy tych nowych szans w przyszłości i będziemy w stanie równie skutecznie odpowiedzieć na wyzwania, przed którymi stanie Sportmaster.
odkrycia
W tych trudnych czasach sformułowaliśmy główne zasady, na których opiera się tworzenie oprogramowania. Myślę, że będą one istotne dla każdej firmy zajmującej się tym tematem.
ludzie. Na tym wszystko się opiera. Pracownicy powinni lubić swoją pracę, rozumieć cele firmy i cele produktów, nad którymi pracują. I oczywiście mogli rozwijać się zawodowo.
Технология. Ważne jest, aby firma podchodziła do pracy w oparciu o posiadany zestaw technologii w dojrzały sposób i rozwijała kompetencje tam, gdzie są one naprawdę potrzebne. Brzmi to bardzo prosto i oczywisto. I bardzo często ignorowane.
Procesy. Ważne jest, aby odpowiednio zorganizować pracę zespołów produktowych i centrów kompetencji, a także nawiązać interakcje z przedsiębiorstwami, aby móc z nimi współpracować na zasadzie partnerstwa.
Generalnie rzecz biorąc, w ten sposób udało nam się przetrwać. Główna teza nowoczesności została potwierdzona po raz kolejny głośnym kliknięciem w czoło
Nawet jeśli prowadzisz ogromny biznes offline, posiadający wiele sklepów i działający w wielu miastach, rozwijaj swoją działalność online. Nie jest to po prostu dodatkowy kanał sprzedaży lub piękna aplikacja, za pomocą której można coś kupić (również dlatego, że konkurencja też ma piękne aplikacje). To nie jest koło zapasowe, które można założyć na wszelki wypadek i które pomoże przeczekać burzę.
To jest absolutna konieczność. Na co muszą być przygotowane nie tylko Twoje możliwości techniczne i infrastruktura, ale także Twoi ludzie i procesy. W końcu możesz szybko dokupić dodatkową pamięć, przestrzeń, wdrożyć nowe instancje itd. w ciągu zaledwie kilku godzin. Ale ludzie i procesy muszą być na to wcześniej przygotowane.
Źródło: www.habr.com
