Hi!
Nazywam się Michaił, jestem zastępcą dyrektora IT w firmie Sportmaster. Chcę podzielić się historią tego, jak poradziliśmy sobie z wyzwaniami, które pojawiły się podczas pandemii.
W pierwszych dniach nowej rzeczywistości zamarł dotychczasowy format handlu offline firmy Sportmaster, a obciążenie naszego kanału online, przede wszystkim w zakresie dostawy na adres klienta, wzrosło 10-krotnie. W ciągu zaledwie kilku tygodni przekształciliśmy gigantyczny biznes offline w internetowy i dostosowaliśmy usługę do potrzeb naszych klientów.
Zasadniczo to, co w zasadzie było naszą działalnością poboczną, stało się naszą podstawową działalnością. Znaczenie każdego zamówienia online ogromnie wzrosło. Trzeba było oszczędzać każdego rubla, który klient przyniósł do firmy.
Aby szybko reagować na prośby klientów, w siedzibie firmy otworzyliśmy dodatkowy contact center, w którym możemy obecnie odbierać około 285 tys. połączeń tygodniowo. Jednocześnie przenieśliśmy 270 sklepów do nowego, bezdotykowego i bezpiecznego formatu działania, który umożliwił klientom otrzymywanie zamówień, a pracownikom utrzymanie miejsc pracy.
Podczas procesu transformacji napotkaliśmy dwa główne problemy. Po pierwsze, znacznie wzrosło obciążenie naszych zasobów internetowych (Siergiej opowie, jak sobie z tym poradziliśmy). Po drugie, przepływ rzadkich (przed pandemią) operacji 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 ci, jak sobie z tym poradziliśmy.
Działanie usług on-line
Kolesnikov Sergey, odpowiedzialny za obsługę sklepu internetowego i mikroserwisów
Od momentu, w którym nasze sklepy detaliczne zaczęły zamykać się dla zwiedzających, zaczęliśmy odnotowywać wzrost wskaźników takich jak liczba użytkowników, liczba zamówień złożonych w naszej aplikacji, liczba zapytań do aplikacji.
Liczba zamówień od 18 marca do 31 marcaLiczba żądań do mikrousług płatności onlineLiczba zamówień złożonych na stronie
Na pierwszym wykresie widzimy, że wzrost wyniósł około 14 razy, na drugim - 4 razy. Za najbardziej orientacyjny uważamy czas reakcji naszych aplikacji.
Na tym wykresie widzimy reakcję frontów i wniosków, a sami ustaliliśmy, że wzrostu jako takiego nie zaobserwowaliśmy.
Wynika to przede wszystkim z faktu, że prace przygotowawcze rozpoczęliśmy pod koniec 2019 roku. Teraz nasze usługi są zarezerwowane, zapewniona jest odporność na awarie na poziomie serwerów fizycznych, systemów wirtualizacji, dokerów i usług w nich zawartych. Jednocześnie pojemność zasobów naszego serwera pozwala nam wytrzymać wielokrotne obciążenia.
Głównym narzędziem, które pomogło nam w tej całej historii, był nasz system monitoringu. To prawda, że do niedawna nie mieliśmy jednego systemu, który pozwalałby zbierać metryki na wszystkich warstwach, od poziomu sprzętu fizycznego i sprzętu komputerowego po poziom metryk biznesowych.
Formalnie w firmie istniał monitoring, jednak z reguły był on rozproszony i znajdował się w obszarze odpowiedzialności konkretnych działów. Tak naprawdę, gdy miał miejsce jakiś incydent, prawie nigdy nie osiągnęliśmy wspólnego zrozumienia tego, co dokładnie się wydarzyło, nie było komunikacji, co często prowadziło do biegania w kółko w celu znalezienia i wyizolowania problemu, aby można go było naprawić.
W pewnym momencie pomyśleliśmy i uznaliśmy, że mamy już dość tego znoszenia – potrzebny jest ujednolicony system, aby zobaczyć cały obraz w całości. Główne technologie, które wchodzą w skład naszego stosu to Zabbix jako centrum alertów i przechowywania metryk, Prometheus do zbierania i przechowywania metryk aplikacji, Stack ELK do logowania i przechowywania danych z całego systemu monitorowania, a także Grafana do wizualizacji, Swagger, Docker i inne przydatne i rzeczy, które są Ci znane.
Jednocześnie wykorzystujemy nie tylko technologie dostępne na rynku, ale także rozwijamy własne. Wykonujemy na przykład usługi integracji systemów ze sobą, czyli swego rodzaju API do zbierania metryk. Dodatkowo pracujemy nad własnymi systemami monitoringu - na poziomie metryk biznesowych wykorzystujemy testy UI. A także bot w Telegramie do powiadamiania drużyn.
Staramy się także udostępnić system monitorowania zespołom, aby mogły niezależnie przechowywać i pracować ze swoimi metrykami, w tym konfigurować alerty dla niektórych wąskich metryk, które nie są powszechnie używane.
W całym systemie dążymy do proaktywności i możliwie najszybszej lokalizacji incydentów. Ponadto w ostatnim czasie znacząco wzrosła liczba naszych mikroserwisów i systemów, a co za tym idzie, wzrosła również liczba integracji. Natomiast w ramach optymalizacji procesu diagnozowania incydentów na poziomie integracji rozwijamy system pozwalający na przeprowadzenie kontroli międzysystemowych i wyświetlenie wyniku, co pozwala znaleźć główne problemy związane z importami i interakcją systemów z nawzajem.
Oczywiście nadal mamy przestrzeń do wzrostu i rozwoju w zakresie systemów operacyjnych i aktywnie nad tym pracujemy. Możesz przeczytać więcej o naszym systemie monitoringu .
Testy techniczne
Orłow Sergey, kieruje centrum kompetencyjnym ds. rozwoju sieci i urządzeń mobilnych
Odkąd rozpoczęły się zamknięcia sklepów stacjonarnych, stawiamy czoła różnym wyzwaniom z punktu widzenia rozwoju. Przede wszystkim wzrost obciążenia jako taki. Oczywiste jest, że jeśli nie zostaną podjęte odpowiednie środki, wówczas przy dużym obciążeniu systemu może on zamienić się w dynię ze smutnym hukiem lub całkowicie pogorszyć wydajność, a nawet stracić funkcjonalność.
Drugi aspekt, nieco mniej oczywisty, polega na tym, że system pod dużym obciążeniem musiał zostać bardzo szybko zmieniony, dostosowując się do zmian w procesach biznesowych. Czasami kilka razy dziennie. W wielu firmach obowiązuje zasada, że jeśli jest dużo działań marketingowych, to nie ma potrzeby wprowadzania żadnych zmian w systemie. Żadnego, niech działa tak długo, jak działa.
I w zasadzie mieliśmy niekończący się Czarny Piątek, podczas którego konieczna była zmiana systemu. Każdy błąd, problem lub awaria systemu byłaby bardzo kosztowna dla firmy.
Patrząc w przyszłość powiem, że poradziliśmy sobie z tymi testami, wszystkie systemy wytrzymały obciążenie, były łatwo skalowalne i nie odnotowaliśmy żadnych globalnych awarii technicznych.
Istnieją cztery filary, na których opiera się zdolność systemu do wytrzymywania dużych obciążeń udarowych. Pierwszym z nich jest monitoring, o którym przeczytacie tuż powyżej. Bez wbudowanego systemu monitorowania znalezienie wąskich gardeł systemu jest prawie niemożliwe. Dobry system monitoringu jest jak domowe ubranie – powinien być wygodny i dopasowany do Ciebie.
Drugi aspekt to testowanie. Traktujemy ten punkt bardzo poważnie: piszemy klasyczne jednostki, testy integracyjne, testy obciążeniowe i wiele innych dla każdego systemu. Piszemy także strategię testowania, jednocześnie staramy się zwiększyć poziom testów do tego stopnia, że ręczne kontrole nie są już nam potrzebne.
Trzeci filar to rurociąg CI/CD. Procesy budowania, testowania i wdrażania aplikacji powinny być w jak największym stopniu zautomatyzowane i nie powinno być żadnej interwencji ręcznej. Temat CI/CD Pipeline jest dość głęboki i poruszę go tylko pokrótce. Warto tylko wspomnieć, że posiadamy listę kontrolną CI/CD Pipeline, przez którą każdy zespół produktowy przechodzi przy pomocy centrów kompetencyjnych.
A oto lista kontrolna
W ten sposób osiąga się wiele celów. Jest to wersjonowanie interfejsu API i przełączanie funkcji w celu uniknięcia serii wydań i osiągnięcia zasięgu różnych testów na takim poziomie, że testowanie jest w pełni zautomatyzowane, wdrożenia przebiegają bezproblemowo i tak dalej.
Czwarty filar to zasady architektoniczne i rozwiązania techniczne. O architekturze można by długo mówić, jednak chcę podkreślić kilka zasad, na których chciałbym się skupić.
Najpierw należy wybrać specjalistyczne narzędzia do konkretnych zadań. Tak, to brzmi oczywisto i jasne jest, że gwoździe należy wbijać młotkiem, a zegarki na rękę demontować specjalnymi śrubokrętami. Ale w naszych czasach wiele narzędzi dąży do uniwersalizacji, aby objąć maksymalny segment użytkowników: bazy danych, pamięci podręczne, frameworki i resztę. Na przykład, jeśli weźmiesz bazę danych MongoDB, działa ona z transakcjami wielodokumentowymi, a baza danych Oracle działa z json. I wydawałoby się, że wszystko można wykorzystać do wszystkiego. Ale jeśli opowiadamy się za produktywnością, musimy jasno zrozumieć mocne i słabe strony każdego narzędzia i wykorzystać te, których potrzebujemy do naszej klasy 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 go stosować na poziomie konkretnej usługi, a także 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 masz tę umiejętność, skalowanie nie będzie trudne.
Skoro już mowa o rozwiązaniach technicznych, poprosiliśmy zespoły produktowe o przygotowanie świeżego zestawu rekomendacji, pomysłów i rozwiązań, które wdrożyły przygotowując się na kolejną falę obciążeń.
Keshi
Konieczne jest świadome podejście do wyboru pamięci podręcznych lokalnych i rozproszonych. Czasami sensowne jest użycie obu w ramach tego samego systemu.Na przykład mamy systemy, w których część danych jest w zasadzie wizytówką pamięci podręcznej, czyli źródło aktualizacji znajduje się za samym systemem, a systemy się nie zmieniają te dane. W tym podejściu używamy lokalnego Caffeine Cache.
Są też dane, które system aktywnie zmienia podczas pracy, a tutaj już korzystamy z rozproszonej pamięci podręcznej z Hazelcast. Takie podejście pozwala nam wykorzystać zalety rozproszonej pamięci podręcznej tam, gdzie są naprawdę potrzebne i zminimalizować koszty usługi związane z rozpowszechnianiem danych klastra Hazelcast tam, gdzie możemy się bez nich obejść. O skrytkach pisaliśmy już sporo. и .
Ponadto zmiana serializatora na Kryo w Hazelcast dała nam dobry impuls. A przejście z ReplicatedMap do IMap + Near Cache w Hazelcast pozwoliło nam zminimalizować przepływ danych w klastrze.
Mała rada: w przypadku unieważnienia masowej pamięci podręcznej czasami można zastosować taktykę rozgrzania drugiej pamięci podręcznej, a następnie przełączenia na nią. Wydawałoby się, że przy takim podejściu powinniśmy uzyskać podwójne zużycie pamięci, ale w praktyce w tych systemach, w których to było praktykowane, zużycie pamięci spadło.
Stos reaktywny
Stosu reaktywnego używamy w dość dużej liczbie systemów. W naszym przypadku jest to Webflux lub Kotlin z współprogramami. Stos reaktywny jest szczególnie dobry tam, gdzie spodziewamy się powolnych operacji wejścia-wyjścia. Na przykład wywołania powolnych usług, praca z systemem plików lub systemami pamięci masowej.
Najważniejszą zasadą jest unikanie blokowania połączeń. Struktury reaktywne mają niewielką liczbę aktywnych wątków usług działających pod maską. Jeśli nieostrożnie pozwolimy sobie na wykonanie bezpośredniego połączenia blokującego, takiego jak wywołanie sterownika JDBC, system po prostu się zatrzyma.
Spróbuj zamienić błędy we własny wyjątek środowiska wykonawczego. Rzeczywisty przebieg wykonywania programu przesuwa się do struktur reaktywnych, a wykonywanie kodu staje się nieliniowe. W rezultacie bardzo trudno jest zdiagnozować problemy za pomocą śladów stosu. Rozwiązaniem byłoby utworzenie jasnych, obiektywnych wyjątków w czasie wykonywania dla każdego błędu.
Elasticsearch
Korzystając z Elasticsearch, nie zaznaczaj nieużywanych danych. To w zasadzie także bardzo prosta rada, jednak najczęściej o tym się zapomina. Jeśli chcesz zaznaczyć jednocześnie więcej niż 10 tysięcy rekordów, musisz skorzystać z funkcji Scroll. Używając analogii, przypomina to trochę kursor w relacyjnej bazie danych.
Nie używaj filtra końcowego, jeśli nie jest to konieczne. W przypadku dużych danych w próbce głównej ta operacja znacznie ładuje bazę danych.
W stosownych przypadkach użyj operacji zbiorczych.
API
Projektując interfejs API, uwzględnij wymagania dotyczące minimalizacji przesyłanych danych. Szczególnie dotyczy to frontu: to właśnie na tym skrzyżowaniu wychodzimy poza kanały naszych data center i już pracujemy nad kanałem łączącym nas z klientem. Jeśli ma najmniejszy problem, zbyt duży ruch powoduje negatywne doświadczenia użytkownika.
I na koniec, nie wyrzucaj całej masy danych, jasno określ umowę między konsumentami a dostawcami.
Transformacja organizacyjna
Eroshkina Elena, zastępca dyrektora ds. IT
W momencie, gdy nastała kwarantanna i pojawiła się potrzeba gwałtownego zwiększenia tempa rozwoju online i wprowadzenia usług omnichannel, byliśmy już w trakcie transformacji organizacyjnej.
Część naszej struktury została przeniesiona do pracy zgodnie z zasadami i praktykami podejścia produktowego. Powstały zespoły, które odpowiadają teraz za działanie i rozwój każdego produktu. Pracownicy takich zespołów są w 100% zaangażowani i organizują swoją pracę za pomocą Scruma lub Kanbana, w zależności od tego, co jest dla nich preferowane, tworząc rurociąg wdrożeniowy, wdrażając praktyki techniczne, praktyki zapewniania jakości i wiele więcej.
Na szczęście większość naszych zespołów produktowych pracowała w obszarze usług online i omnichannel. Dzięki temu mogliśmy przejść na tryb pracy zdalnej w możliwie najkrótszym czasie (a tak na serio, dosłownie w dwa dni) bez utraty wydajności. Zindywidualizowany proces pozwolił nam szybko dostosować się do nowych warunków pracy i utrzymać dość wysokie tempo dostarczania nowych funkcjonalności.
Ponadto musimy wzmocnić te zespoły, które przodują w biznesie internetowym. W tym momencie stało się jasne, że możemy tego dokonać jedynie przy użyciu zasobów wewnętrznych. A około 50 osób w ciągu dwóch tygodni zmieniło obszar, w którym wcześniej pracowały i zaangażowało się w pracę nad nowym dla nich produktem.
Nie wymagało to żadnych specjalnych wysiłków zarządczych, ponieważ oprócz organizowania własnego procesu, doskonalenia technicznego produktu i praktyk zapewniania 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 menadżerskie dokładnie tam, gdzie było to potrzebne w danym momencie – na koordynacji z biznesem: Co jest teraz ważne dla naszego Klienta, jaką funkcjonalność należy wdrożyć w pierwszej kolejności, co należy zrobić, aby zwiększyć naszą przepustowość w celu dostarczania i przetwarzania zamówień. To wszystko i jasny wzór do naśladowania pozwoliły w tym okresie naładować nasze produkcyjne strumienie wartości tym, co naprawdę ważne i konieczne.
Wiadomo, że przy pracy zdalnej i dużym tempie zmian, gdy wskaźniki biznesowe zależą od zaangażowania wszystkich, nie można polegać wyłącznie na wewnętrznych przeczuciach z cyklu „Czy u nas wszystko idzie dobrze? Tak, wydaje się dobre. Potrzebne są obiektywne wskaźniki procesu produkcyjnego. Mamy je, są dostępne dla każdego, kogo interesują metryki zespołów produktowych. Przede wszystkim sam zespół, biznes, podwykonawcy i zarząd.
Raz na dwa tygodnie z każdym zespołem odbywa się narada, podczas której przez 10 minut analizowane są wskaźniki, identyfikowane są wąskie gardła w procesie produkcyjnym i opracowywane jest 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 jakikolwiek zidentyfikowany problem leży poza strefą wpływu zespołów lub wiedzy współpracowników, którzy mogli już napotkać podobny problem.
Rozumiemy jednak, że aby przyspieszyć wielokrotnie (a właśnie taki cel sobie stawiamy) musimy się jeszcze wiele nauczyć i wdrożyć to w swoją codzienną pracę. W tej chwili kontynuujemy skalowanie naszego podejścia do produktów na inne zespoły i nowe produkty. Aby tego dokonać musieliśmy opanować dla nas nowy format – internetową szkołę metodyków.
Metodolodzy, czyli ludzie, którzy pomagają zespołom budować proces, nawiązywać komunikację i poprawiać wydajność pracy, są w istocie agentami zmian. W tej chwili absolwenci naszej pierwszej kohorty pracują z zespołami i pomagają im odnieść sukces.
Myślę, że obecna sytuacja otwiera przed nami możliwości i perspektywy, z których być może sami jeszcze nie do końca zdajemy sobie sprawę. Jednak doświadczenie i praktyka, które obecnie zdobywamy, potwierdzają, że wybraliśmy właściwą drogę rozwoju, nie przegapimy tych nowych możliwości w przyszłości i będziemy mogli równie skutecznie reagować na wyzwania, jakie staną przed Sportmasterem.
odkrycia
W tym trudnym czasie sformułowaliśmy główne zasady, na których opiera się tworzenie oprogramowania, które, jak sądzę, będą istotne dla każdej firmy, która się tym zajmie.
ludzie. Na tym wszystko się opiera. Pracownicy muszą lubić swoją pracę i rozumieć cele firmy oraz cele produktów, nad którymi pracują. I oczywiście mogli rozwijać się zawodowo.
Технология. Konieczne jest, aby firma dojrzała podeszła do pracy ze swoim stosem technologii i budował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 kompetencyjnych, nawiązać interakcję z biznesem, aby móc z nim współpracować po partnersku.
Ogólnie rzecz biorąc, mniej więcej tak przetrwaliśmy. Główna teza naszych czasów została po raz kolejny potwierdzona donośnym kliknięciem w czoło
Nawet jeśli prowadzisz ogromną firmę offline z wieloma sklepami i kilkoma miastami, w których prowadzisz działalność, rozwijaj swój biznes online. To nie tylko dodatkowy kanał sprzedaży czy piękna aplikacja, dzięki której też można coś kupić (i to też dlatego, że konkurenci też mają piękne). To nie jest koło zapasowe, które pomoże Ci przetrwać burzę.
Jest to absolutna konieczność. Na co muszą być przygotowane nie tylko Twoje możliwości techniczne i infrastruktura, ale także Twoi ludzie i procesy. Przecież możesz szybko kupić dodatkową pamięć, miejsce, wdrożyć nowe instancje itp. w ciągu kilku godzin. Jednak ludzie i procesy muszą być na to przygotowani z wyprzedzeniem.
Źródło: www.habr.com