Chciałbym się oficjalnie odnieść (niestety trochę z opóźnieniem bo jest sporo innych palących spraw) co do sytuacji z ostatnimi restartami dla prawie wszystkich klientów:
https://lvlup.rok.ovh/t/awarie-2020/13151/#9?u=systemz
Przynajmniej kilka klientów było mocno zniesmaczonych cała sytuacją a zwłaszcza bardzo krótkim czasem pomiędzy powiadomieniem mailowym a przeprowadzonych restartach. Jest to uzasadnione bo takie restarty moim zdaniem powinny wiązać się z większym wyprzedzeniem maili które pozwalają się na to przygotować, powiedzmy tydzień przed byłby ok.
Ogólnie sporo rzeczy jednocześnie poszło nie tak.
Napotkane problemy
1. Brak czasu
Niestety nie mieliśmy możliwości poczekać aż tyle czasu co zwykle w przypadku masowych rebootów. Z godziny na godzinę coraz więcej klientów doświadczało błędu w skutek którego nie mogło włączyć swojej usługi którą przed chwilą wyłączyli. Włączenie swojej usługi jest sprawą kluczową gdyż to właśnie za włączony serwer płacą nasi klienci. To pierwszy problem na jaki napotkaliśmy - nie mieliśmy tej wygody poinformować klientów z dużym wyprzedzeniem.
2. Brak sprzętu
Przynajmniej jeden klient poruszył kwestię braku redundancji w przypadku naszej oferty. To prawda, nie mamy jej zbyt wiele ale w zasadzie tego wymaga nasza oferta. Na dobrą sprawą nie znajdziemy oferty serwerów dedykowanych która oferuje opcje klasy enterprise w tej cenie na dodatek z charakterystyką korzystną dla serwerów gier (ochrona DDoS, wysoka wydajność per rdzeń CPU, szybki RAM). Nie sądzę aby klienci byli zadowoleni gdyby musieli zapłacić więcej na dodatek za niżej taktowane CPU i gorszą ochroną antyDDoS.
Nasze "ubezpieczenie" to zamiast inwestować w drogi sprzęt w małej ilości, dużo taniego sprzętu który łatwo zastąpić. W takim przypadku jeśli coś jest nie tak, po prostu przenosimy klienta na inny sprzęt. Niestety w tym czasie pojawił się kolejny problem, nie mieliśmy wolnych zasobów sprzętowych na taką operację.
3. Poważny bug
Zakładając ze nawet mamy rezerwowe zasoby, błąd był na tyle poważny że uniemożliwiał 100% łagodne poprawne wyłączenie VPSów czy też uruchomienie nowych procesów w ramach systemd. Oznacza to że nawet gdybyśmy posiadali live migrację czyli spauzowanie VM, przeniesienie jej i odpauzowanie na innym sprzęcie to nie było to przez ten błąd możliwe lub było bardzo utrudnione. W momencie gdy mamy mało obsługi, mało czasu oraz skomplikowany problem do rozwiązania, sięgamy po proste rozwiązania aby jak najszybciej przywrócić dostęp do usługi z największą skutecznością.
4. Trudna szybka komunikacja
Nie mieliśmy skutecznego sposobu aby szybko poinformować tylko tych klientów których dotyczy restart. Całe szczęście udało mi się to rozwiązać trochę wcześniej https://lvlup.rok.ovh/t/dziennik-zmian-lvlup-pro-2020/13148/#38?u=systemz Po małych udoskonaleniach obecnie mamy już całkiem przyzwoite narzędzie które pozwala szybciej zająć się problemem zamiast ustalać do kogo wysyłać maile.
5. Niechęć klientów do regularnych restartów
Ta sytuacja jest też niestety wynikiem tego że większość klientów nie jest przygotowana na restarty i w sumie nie chce być przygotowana na nie. Wnioskuję tak po wypowiedziach w wątku który zakładałem w poprzednim roku a pytałem w sumie o to czy klienci wolą mieć więcej regularnych i zaplanowanych restartów czy może raz na jakiś czas awaryjne: https://lvlup.rok.ovh/t/jak-dobrze-znosicie-restarty-vpsow/11462?u=systemz
6. Nieskuteczność live patchów
Powiązane z punktem wyżej odnośnie dopłaty za mniej restartów. W zasadzie przyjęliśmy na siebie koszt licencji na live patch kernela czyli łatanie jądra systemu bez restartu systemu ale jak widać to też nie pomogło. Ta metoda ma swoje ograniczenia.
Wnioski
Generalnie nie unikniemy wcześniej zaplanowanych restartów. Teraz powstaje pytanie z jak dużym wyprzedzeniem potrzebujecie otrzymać powiadomienie że nastąpi restart oraz w jakiej godzinie i dniu tygodnia jest on przez Was preferowany?
