Cześć, Habr! Od dziesięciu lat zajmuję się systemami IT o wysokim obciążeniu. Nie będę w tym artykule pisał o problemach związanych z konfiguracją nginx do obsługi więcej niż 1000 RPS ani o innych kwestiach technicznych. Podzielę się obserwacjami na temat problemów w procesach, które występują w utrzymaniu i eksploatacji takich systemów.
Monitoring
Wsparcie techniczne nie czeka, aż wpłynie zgłoszenie o treści „Dlaczego… strona znów nie działa?”. Wsparcie już minutę po awarii strony powinno zauważyć problem i rozpocząć jego rozwiązanie. Jednak strona to tylko wierzchołek góry lodowej.. Jej dostępność jest monitorowana jako jedna z pierwszych.
Co zrobić w sytuacji, gdy zapasy towarów w sklepie internetowym przestały napływać z systemu ERP? Albo system CRM, który oblicza zniżki dla klientów, przestał odpowiadać? Strona wygląda na działającą. Umowny Zabbix otrzymuje swój 200 odpowiedź. Dyżurna zmiana nie otrzymała żadnych powiadomień od monitoringu i z radością kończy oglądanie pierwszego odcinka nowego sezonu «Gry o Tron».
Często monitoring ogranicza się tylko do pomiaru stanu pamięci, RAM-u i obciążenia procesora. serwerów. Jednak dla biznesu znacznie ważniejsze jest zapewnienie dostępności towaru na stronie. Umowny spadek jednej wirtualnej maszyny w klastrze spowoduje, że ruch przestanie do niej docierać, a obciążenie na innych serwerach wzrośnie. Firma nie straci pieniędzy.
Dlatego oprócz monitorowania parametrów technicznych systemów operacyjnych na serwerach, należy skonfigurować metryki biznesowe. Metryki, które bezpośrednio wpływają na finanse. Różne interakcje z systemami zewnętrznymi (CRM, ERP i inne). Liczba zamówień w określonym czasie. Udane lub nieudane autoryzacje klientów i inne metryki.
Interakcje z systemami zewnętrznymi
Każda strona internetowa lub aplikacja mobilna z rocznym obrotem przekraczającym miliard rubli wchodzi w interakcje z systemami zewnętrznymi. Począwszy od wspomnianych CRM i ERP, a kończąc na przesyłaniu danych o sprzedaży do zewnętrznego systemu Big Data do analizy zakupów i propozycji klientowi towaru, który na pewno kupi (w rzeczywistości nie). Każdy z tych systemów ma swoje wsparcie. I często komunikacja z tymi systemami powoduje ból. Szczególnie gdy problem jest globalny i trzeba go analizować w różnych systemach.
Niektóre systemy podają telefon lub Telegram swoich administratorów. Gdzie indziej trzeba pisać maile do menedżerów lub korzystać z systemów zgłaszania błędów tych zewnętrznych systemów. Nawet w ramach jednej dużej firmy różne systemy często działają w różnych systemach rejestracji zgłoszeń. Śledzenie statusu zgłoszenia czasami staje się niemożliwe. Otrzymujesz zgłoszenie w jednym z dalekich Jira. Następnie w komentarzu tego pierwszego Jira wstawiasz link do zadania w innym Jira. W drugim Jira ktoś już pisze komentarz, że należy zadzwonić do rzekomego administratora Andrzeja, aby rozwiązać problem. I tak dalej.
Optymalnym rozwiązaniem tego problemu byłoby stworzenie wspólnej przestrzeni do komunikacji, na przykład w Slacku. Zaproszenie do niej wszystkich uczestników procesu zarządzania zewnętrznymi systemami. A także jednego systemu śledzenia, aby nie dublować zgłoszeń. Zgłoszenia powinny być śledzone w jednym miejscu, począwszy od powiadomienia monitoringu aż do wdrożenia rozwiązań błędów. Powiesz, że to niemożliwe, i że historycznie tak się ułożyło, że pracujemy w jednym systemie, a oni w innym. Pojawiały się różne systemy, miały swoje autonomiczne zespoły IT. Zgadzam się i dlatego problem należy rozwiązać na poziomie CIO lub właściciela produktu.
Każdy system, z którym masz do czynienia, powinien świadczyć wsparcie jako usługę z wyraźnym SLA na rozwiązanie problemów według priorytetów. A nie wtedy, kiedy rzekomy administrator Andrzej znajdzie dla ciebie chwilę czasu.
Człowiek jako wąskie gardło
Czy każdy z projektu (lub produktu) ma taką osobę, której urlop wywołuje skurcze u kierownictwa? Może to być inżynier devops, analityk lub programista. Tylko inżynier devops wie, na których serwerach zainstalowane są jakie kontenery, jak zrestartować kontener w przypadku problemu, a każda skomplikowana kwestia nie zostanie rozwiązana bez niego. Analityk jest jedyną osobą, która wie, jak działa twój złożony mechanizm. Jakie strumienie danych dokąd idą. Przy jakich parametrach zapytań do jakich usług, jakie będziemy otrzymywać odpowiedzi.
Kto szybko zrozumie, dlaczego w logach są błędy i szybko naprawi krytyczny błąd w środowisku produkcyjnym? Oczywiście ten programista. Są inni, ale jakoś tylko on rozumie, jak zorganizowane są różne moduły systemu.
Korzeniem tego problemu jest brak dokumentacji.Bo gdyby wszystkie usługi twojego systemu były opisane, można by sobie z problemem poradzić i bez analityka. Gdyby devops poświęcił kilka dni ze swojego napiętego harmonogramu, aby opisać wszystkie serwery, usługi i instrukcje dotyczące rozwiązywania typowych problemów, problem w jego nieobecności można by rozwiązać i bez niego. Nie trzeba podczas urlopu szybko dopijać swojego piwa na plaży i szukać Wi-Fi, aby rozwiązać problem.
Kompetencje i odpowiedzialność pracowników wsparcia
W dużych projektach firmy nie szczędzą pieniędzy na wynagrodzenia dla programistów. Rekrutują drogie mid-level lub seniorów z podobnych projektów. Sytuacja z wsparciem wygląda nieco inaczej. Te wydatki są wszelkimi sposobami ograniczane. Firmy zatrudniają niedrogich wczorajszych help-deskerów i śmiało idą do boju. Taka strategia jest możliwa, gdy mowa o stronie wizytówkowej jakiegoś zakładu w Zielenogradzie.
Jeśli mowa o dużym sklepie internetowym, to każda godzina przestoju kosztuje więcej niż miesięczna pensja admina-help-deslera. Weźmy jako punkt wyjścia 1 miliard rubli rocznego obrotu. To minimalny obrót każdego sklepu internetowego z rankingu . Podzielmy tę kwotę przez liczbę godzin w roku i otrzymamy ponad 100 000 rubli czystych strat. A jeśli nie będziemy liczyć godzin nocnych, to można śmiało podwoić tę kwotę.
Ale pieniądze nie są najważniejsze, prawda? (nie, oczywiście że są ważne) Są też straty reputacyjne. Godzina awarii znanego sklepu internetowego może spowodować zarówno falę recenzji w mediach społecznościowych, jak i publikacje w branżowych mediach. A rozmowy przyjacół w stylu „Nie kupuj tam nic, ich strona ciągle nie działa” w ogóle nie podlegają mierzeniu.
Teraz przechodzimy do odpowiedzialności. W mojej praktyce był przypadek, kiedy dyżurny administrator nie zareagował na czas na powiadomienie systemu monitorowania o niedostępności strony. W przyjemny letni piątkowy wieczór strona znanego sklepu internetowego w Moskwie cicho leżała. W sobotę rano produkt tego sklepu nie rozumiał, dlaczego strona się nie otwiera, a na czatach wsparcia i pilnych powiadomieniach w Slacku cisza. Taki błąd kosztował nas sześciocyfrową kwotę, a temu dyżurnemu pracy.
Odpowiedzialność to umiejętność, która jest trudna do wykształcenia. Albo to jest u człowieka, albo nie. Dlatego na rozmowach kwalifikacyjnych staram się wyłonić to poprzez różne pytania, które pośrednio pokazują, czy dana osoba nauczyła się brać odpowiedzialność na siebie. Jeśli ktoś odpowiada, że wybrał uczelnię, bo tak powiedzieli rodzice, lub zmienia pracę, bo żona powiedziała, że mało zarabia, to lepiej unikać takich ludzi.
Interakcja z zespołem deweloperskim
Gdy w trakcie użytkowania na produkcji u użytkowników występują proste problemy, wsparcie rozwiązuje je samodzielnie. Próbują odtworzyć problem, analizują logi i tak dalej. Ale co robić, gdy na produkcji pojawia się błąd? W takiej sytuacji wsparcie uruchamia zadanie dla deweloperów i wtedy zaczyna się najciekawsze.
Deweloperzy są ciągle obciążeni. Zajmują się tworzeniem nowych funkcji. Naprawienie błędów na produkcie to powiedzmy, mało interesujące zajęcie. Terminy na zakończenie kolejnego sprintu są napięte. A tu przychodzą nieprzyjemni ludzie z wsparcia i mówią: „Natychmiast przestań wszystko robić, mamy problem”. Priorytet takich zadań jest minimalny. Szczególnie gdy problem nie jest krytyczny, główna funkcjonalność strony działa, a kierownik wydania nie biega z wytrzeszczonymi oczami i nie pisze: „Natychmiast wprowadź to zadanie do najbliższego wydania lub hotfixa”.
Zadania o zwykłym lub niskim priorytecie przechodzą z wydania do wydania. Na pytanie „Kiedy zadanie zostanie wykonane?” można otrzymać odpowiedzi w stylu: „Przepraszam, teraz jest wiele zadań, zapytaj liderów zespołów lub menedżera wydania”.
Problemy na produkcji mają wyższy priorytet niż tworzenie nowych funkcji. Negatywne opinie nie każą na siebie długo czekać, jeśli użytkownicy będą stale napotykać błędy. Utrata reputacji jest trudna do odbudowania.
Kwestie interakcji pomiędzy rozwojem a wsparciem rozwiązują DevOps. Ten skrót często używany jest w formie konkretnej osoby, która pomaga w tworzeniu środowisk testowych dla rozwoju, buduje pipeline'y CICD i szybko wprowadza przetestowany kod na produkcję. DevOps to podejście do rozwoju oprogramowania, w którym wszyscy uczestnicy procesu ściśle współpracują ze sobą i pomagają szybciej tworzyć i aktualizować produkty i usługi. Mam na myśli analityków, deweloperów, testerów i wsparcie.
Wsparcie i rozwój to w tym podejściu nie różne działy z własnymi celami i zadaniami. Rozwój jest zaangażowany w eksploatację i vice versa. Słynna fraza z rozproszonych zespołów: „Problem nie leży po mojej stronie” już rzadziej pojawia się na czatach, a końcowi użytkownicy stają się nieco szczęśliwsi.
Źródło: habr.com
