Witaj, Habro! Od dziesięciu lat wspieram systemy IT Highload. Nie będę w tym artykule pisać o problemach z konfiguracją nginxa do pracy w trybie 1000+ RPS ani o innych kwestiach technicznych. Podzielę się swoimi spostrzeżeniami na temat problemów w procesach jakie powstają przy wsparciu i eksploatacji takich systemów.
Monitorowanie
Pomoc techniczna nie czeka, aż nadejdzie żądanie o treści „Co dlaczego… strona znów nie działa?” W ciągu minuty po awarii witryny wsparcie powinno już zauważyć problem i zacząć go rozwiązywać. Ale strona to wierzchołek góry lodowej. Jego dostępność jest jedną z pierwszych monitorowanych.
Co zrobić w sytuacji, gdy pozostałe towary sklepu internetowego nie docierają już z systemu ERP? A może system CRM wyliczający rabaty dla klientów przestał reagować? Wygląda na to, że strona działa. Warunkowy Zabbix otrzymuje odpowiedź 200. Dyżurny nie otrzymał żadnych powiadomień z monitoringu i z radością ogląda pierwszy odcinek nowego sezonu Gry o Tron.
Monitoring często ogranicza się jedynie do pomiaru stanu pamięci, pamięci RAM i obciążenia procesora serwera. Jednak dla biznesu znacznie ważniejsze jest uzyskanie dostępności produktu na stronie internetowej. Warunkowa awaria jednej maszyny wirtualnej w klastrze spowoduje, że ruch do niej przestanie płynąć, a obciążenie pozostałych serwerów wzrośnie. Firma nie straci pieniędzy.
Dlatego oprócz monitorowania parametrów technicznych systemów operacyjnych na serwerach należy skonfigurować metryki biznesowe. Wskaźniki, które bezpośrednio wpływają na pieniądze. Różnorodne interakcje z systemami zewnętrznymi (CRM, ERP i inne). Liczba zamówień na określony okres czasu. Pomyślne lub nieudane autoryzacje klientów i inne wskaźniki.
Interakcja z systemami zewnętrznymi
Każda witryna internetowa lub aplikacja mobilna o rocznym obrocie przekraczającym miliard rubli współdziała z systemami zewnętrznymi. Zaczynając od wspomnianego CRM i ERP, a kończąc na przeniesieniu danych sprzedażowych do zewnętrznego systemu Big Data w celu analizy zakupów i zaoferowania klientowi produktu, który na pewno kupi (a właściwie nie). Każdy taki system ma swoje własne wsparcie. I często komunikacja z tymi systemami powoduje ból. Zwłaszcza, gdy problem jest globalny i trzeba go analizować w różnych systemach.
Niektóre systemy udostępniają administratorom numer telefonu lub telegram. Gdzieś trzeba pisać listy do menedżerów lub udać się do trackerów błędów tych zewnętrznych systemów. Nawet w kontekście jednej dużej firmy różne systemy często działają w różnych systemach księgowych. Czasami śledzenie statusu aplikacji staje się niemożliwe. Zapytanie otrzymujesz w jednym warunkowym Jira. Następnie w komentarzu tej pierwszej Jiry umieszczasz link do problemu w innej Jirze. W drugiej Jirze w aplikacji ktoś już pisze komentarz, że musisz zadzwonić do administratora warunkowego Andreya, aby rozwiązać problem. I tak dalej.
Najlepszym rozwiązaniem tego problemu byłoby stworzenie jednej przestrzeni do komunikacji, np. w Slacku. Zaproszenie do włączenia się wszystkich uczestników procesu obsługi systemów zewnętrznych. A także pojedynczy tracker, aby nie duplikować aplikacji. Aplikacje należy śledzić w jednym miejscu, od powiadomień monitorujących po wyniki rozwiązań błędów w przyszłości. Powiesz, że to nierealne i historycznie zdarzało się, że my pracowaliśmy w jednym trackerze, a oni w innym. Pojawiły się różne systemy, miały własne, autonomiczne zespoły IT. Zgadzam się i dlatego problem należy rozwiązać odgórnie na poziomie CIO lub właściciela produktu.
Każdy system, z którym współpracujesz, powinien zapewniać wsparcie jako usługę z jasną umową SLA w celu rozwiązywania problemów według priorytetów. I nie wtedy, gdy administrator warunkowy Andrey ma dla ciebie minutę.
Człowiek z wąskim gardłem
Czy każdy przy projekcie (lub produkcie) ma osobę, której wyjazd na wakacje wywołuje u przełożonych konwulsje? Może to być inżynier devops, analityk lub programista. Przecież tylko inżynier devops wie, które serwery mają zainstalowane jakie kontenery, jak zrestartować kontener w przypadku problemu i w ogóle bez niego żadnego złożonego problemu nie da się rozwiązać. Analityk jest jedyną osobą, która wie, jak działa Twój złożony mechanizm. Które strumienie danych trafiają dokąd. Pod jakimi parametrami żądań do jakich usług i na jakie otrzymamy odpowiedzi.
Kto szybko zrozumie, dlaczego w logach są błędy i szybko naprawi krytyczny błąd w produkcie? Oczywiście ten sam deweloper. Są inne, ale z jakiegoś powodu tylko on rozumie, jak działają różne moduły systemu.
Źródłem tego problemu jest brak dokumentacji. W końcu gdyby opisano wszystkie usługi Twojego systemu, możliwe byłoby uporanie się z problemem bez analityka. Gdyby Devops znalazł kilka dni w swoim napiętym harmonogramie i opisał wszystkie serwery, usługi i instrukcje dotyczące rozwiązywania typowych problemów, wówczas problem pod jego nieobecność mógłby zostać rozwiązany bez niego. Nie musisz szybko dopijać piwa na plaży będąc na wakacjach i szukać Wi-Fi, aby rozwiązać problem.
Kompetencje i odpowiedzialność personelu pomocniczego
Przy dużych projektach firmy nie skąpią na pensjach deweloperów. Poszukują drogich średniaków lub seniorów z podobnych projektów. W przypadku wsparcia sytuacja jest nieco inna. Próbują te koszty obniżyć na wszelkie możliwe sposoby. Firmy zatrudniają niedrogich, wczorajszych pracowników Enike i odważnie idą do bitwy. Ta strategia jest możliwa, jeśli mówimy o stronie wizytówkowej zakładu w Zelenogradzie.
Jeśli mówimy o dużym sklepie internetowym, to każda godzina przestoju kosztuje więcej niż miesięczna pensja administratora Enike. Za punkt wyjścia przyjmijmy 1 miliard rubli rocznego obrotu. Jest to minimalny obrót dowolnego sklepu internetowego z rankingu . Podziel tę kwotę przez liczbę godzin rocznie i uzyskaj ponad 100 000 rubli strat netto. A jeśli nie liczysz godzin nocnych, możesz bezpiecznie podwoić tę kwotę.
Ale pieniądze nie są najważniejsze, prawda? (nie, oczywiście najważniejsze) Istnieją również straty w reputacji. Upadek znanego sklepu internetowego może spowodować zarówno falę recenzji na portalach społecznościowych, jak i publikacje w mediach tematycznych. A rozmów znajomych w kuchni w stylu „Tam nic nie kupuj, ich strona internetowa ciągle nie działa” w ogóle nie da się zmierzyć.
Teraz o odpowiedzialności. W mojej praktyce zdarzył się przypadek, gdy dyżurujący administrator nie zareagował w terminie na powiadomienie z systemu monitorującego o niedostępności serwisu. W przyjemny letni piątkowy wieczór strona znanego sklepu internetowego w Moskwie leżała spokojnie. W sobotę rano menedżer produktu tej witryny nie rozumiał, dlaczego witryna się nie otworzyła, a na czacie pomocy technicznej i pilnych powiadomień na Slacku panowała cisza. Taki błąd kosztował nas sześciocyfrową sumę, a ten oficer dyżurny posadę.
Odpowiedzialność to umiejętność trudna do rozwinięcia. Albo ktoś to ma, albo nie. Dlatego podczas rozmów staram się utożsamiać jej obecność z różnymi pytaniami, które pośrednio pokazują, czy dana osoba jest przyzwyczajona do brania na siebie odpowiedzialności. Jeśli ktoś odpowiada, że wybrał studia, bo tak powiedzieli rodzice, albo zmienia pracę, bo żona stwierdziła, że zarabia za mało, to lepiej nie zadawać się z takimi osobami.
Interakcja z zespołem deweloperskim
Gdy użytkownicy napotykają proste problemy z produktem podczas pracy, wsparcie rozwiązuje je samodzielnie. Próbuje odtworzyć problem, analizuje dzienniki i tak dalej. Co jednak zrobić, gdy w produkcie pojawi się błąd? W tym przypadku support przydziela zadanie programistom i tu zaczyna się zabawa.
Programiści są stale przeciążeni. Tworzą nowe funkcje. Naprawianie błędów w sprzedaży nie jest najciekawszym zajęciem. Zbliża się termin ukończenia kolejnego sprintu. A potem przychodzą nieprzyjemni ludzie z supportu i mówią: „Natychmiast rzuć wszystko, mamy problemy”. Priorytet takich zadań jest minimalny. Zwłaszcza, gdy problem nie jest najbardziej krytyczny i główna funkcjonalność witryny działa, a menedżer wersji nie biega z wyłupiastymi oczami i nie pisze: „Pilnie dodaj to zadanie do następnej wersji lub poprawki”.
Problemy o normalnym lub niskim priorytecie są przenoszone z wydania do wydania. Na pytanie „Kiedy zadanie zostanie ukończone?” otrzymasz odpowiedzi w stylu: „Przepraszam, ale teraz jest dużo zadań, zapytaj liderów zespołu lub menedżera ds. wersji”.
Problemy z produktywnością mają wyższy priorytet niż tworzenie nowych funkcji. Złe recenzje nie będą długo czekać, jeśli użytkownicy będą stale natrafiać na błędy. Zniszczoną reputację trudno jest przywrócić.
Kwestie interakcji pomiędzy rozwojem i wsparciem rozwiązuje DevOps. Skrót ten jest często używany w formie konkretnej osoby, która pomaga tworzyć środowiska testowe do celów programistycznych, buduje potoki CICD i szybko wprowadza przetestowany kod do produkcji. DevOps to podejście do tworzenia oprogramowania, w którym wszyscy uczestnicy procesu ściśle ze sobą współdziałają i pomagają szybko tworzyć i aktualizować produkty i usługi programistyczne. Mam na myśli analityków, programistów, testerów i wsparcie.
W tym podejściu wsparcie i rozwój nie są odrębnymi działami posiadającymi własne cele i zadania. Rozwój wiąże się z działaniem i odwrotnie. Słynne zdanie rozproszonych zespołów: „Problem nie leży po mojej stronie” nie pojawia się już tak często na czatach, a użytkownicy końcowi stają się nieco szczęśliwsi.
Źródło: www.habr.com