🥇Obniżamy koszty wsparcia, starając się nie tracić na jakości

Tryb awaryjny (znany również jako IPKVM), pozwalający na podłączenie się do VPS-a bez RDP bezpośrednio z poziomu hypervisor, oszczędza 15–20 minut tygodniowo.

Pierwsza i najważniejsza zasada — nie denerwować ludzi. Na całym świecie wsparcie dzieli się na linie, a pracownik pierwszej linii powinien spróbować typowych sposobów rozwiązania. Jeśli zadanie wykracza poza ich możliwości, należy je przekazać drugiej linii. Wśród administratorów VDS często zdarzają się osoby, które potrafią myśleć. W przeciwieństwie do wielu innych działów wsparcia. Przynajmniej znacznie częściej. Dobrze strukturyzują zgłoszenia, od razu opisując wszystko, co potrzebne. Jeśli pierwsza linia „przegapi” coś i przypadkowo poprosi o włączenie i wyłączenie, to jest klęska.

Zadanie jest bardzo proste: uczynić wsparcie naszego hostingu VDS odpowiednim przy minimalnych kosztach. Ponieważ jesteśmy fast foodem w świecie dostawców hostingu: brak zbędnych „upiększeń”, niskie ceny, dobra jakość. Wcześniej była już mowa o tym, że wraz z pojawieniem się Instagramowych słodkości, które próbują zautomatyzować prowadzenie konta, i właścicieli małych firm zdalnej księgowości, oraz innych osób niezbyt obeznanych w technologii, komunikacja „jak admin z adminem” przestała działać. Konieczne było zmienienie języka komunikacji.

Teraz opowiem nieco więcej o procesach — i o nieuchronnych błędach z nimi związanych.

Nie denerwować ludzi nr 1

Każde wsparcie to produkcja taśmowa. Przybywa zgłoszenie, pracownik pierwszej linii natychmiast stara się rozpoznać typową sytuację, która zdarzyła się tysiąc razy i zdarzy się tysiąc razy jeszcze. Szansa 90%, że zgłoszenie jest typowe i można na nie odpowiedzieć klikając dosłownie kilka przycisków, aby załadował się szablon. W szablonie zazwyczaj trzeba wpisać kilka słów — i gotowe. Lub wejść do interfejsu zarządzania i nacisnąć tam kilka przycisków. W bardziej skomplikowanych przypadkach (np. przenosin z strefy do strefy) należy wykonać działania zgodnie z algorytmem.

Najbardziej irytujące dla ludzi, niezależnie od innych cech wsparcia, jest typowa reakcja na nietypowe zgłoszenie. Przyjdzie zgłoszenie, w którym wszystko jest szczegółowo opisane, są wszystkie niezbędne dane na trzy pytania do przodu, klient przewiduje dialog... A na pierwsze słowa pracownik wsparcia na autopilocie wpisuje frazę z szablonu „spróbuj zrestartować, powinno pomóc”.

To właśnie to wyraźnie frustruje ludzi i po takich sytuacjach pozostaje najwięcej negatywnych recenzji i gniewnych komentarzy. Jasne, że popełnialiśmy błędy, stąd znamy statystyki. Ogólnie to my różnie się myliliśmy, ale takie przypadki to zawsze po prostu skandal. W tym również dla nas samych. Oczywiście chcielibyśmy, aby takie sytuacje w ogóle się nie zdarzały. Ale na praktykę nie jest to zbyt możliwe: co kilka tygodni zmęczony monotonnością pracownik raz na jakiś czas naciśnie śmieszne przyciski.

Nie denerwować ludzi № 2

Drugim, co równie skutecznie frustruje, jest to, gdy na zgłoszenie nikt nie odpowiada przez długi czas. W Europie takie zachowanie obsługi jest normalne: trzy dni na podjęcie działania to więcej niż norma. Nawet jeśli jest to dla Ciebie pilne i coś się pali - żadnych mediów społecznościowych, telefonu, komunikatora, tylko poczta i czekanie na swoją kolej. W Rosji jest to znacznie mniej powszechne, ale wciąż niektóre zgłoszenia są „zapominane”. Jeszcze na samym początku pracy ustaliliśmy SLA na pierwszą reakcję 15 minut. I to przy 24/7 uczciwie. Oczywiście, gdy VDS-hosting staje się duży, to się pojawia. Ale u wątpliwych dostawców usług tego nie ma. A my na początku byliśmy właśnie wątpliwi i dopiero później staliśmy się bardziej lub mniej dużym. Cóż, bardziej lub mniej średnim.

Pierwsza linia - operatorzy, którym dano skrypty i nauczyli się reagować na typowe sytuacje. Szybko sortują problemy i starają się w ciągu 15 minut albo odpowiedzieć standardową odpowiedzią, albo poinformować, że zgłoszenie jest w trakcie przetwarzania i przekazać do drugiej.

Druga linia - już administratorzy hostingu, potrafią prawie wszystko zrobić ręcznie. Tam też jest lider wsparcia, który umie zrobić wszystko i jeszcze trochę. Trzecia linia - już programiści, do nich trafiają zgłoszenia takie jak „poprawcie to w interfejsie” lub „nieprawidłowo uwzględniany jest taki parametr tamto”.

Zmniejszać liczbę zgłoszeń

Z oczywistych powodów, jeśli chcesz świadczyć wsparcie w przystępnej cenie, powinieneś nie skupiać się na zwiększaniu pierwszej linii wsparcia, aby ludzie z skryptami radzili sobie szybciej, ale na zwiększaniu automatyzacji. Zamiast ludzi ze skryptami, powinny być prawdziwe skrypty. Dlatego jedną z pierwszych rzeczy, które zrobiliśmy, było zautomatyzowanie procesów uruchamiania maszyny wirtualnej, skalowania zasobów (w tym zwiększania i zmniejszania dysku, ale nie częstotliwości procesora) i innych podobnych rzeczy. Im więcej użytkownik może zrobić z interfejsu, tym łatwiej jest pierwszej linii wsparcia, a tym mniejsza liczba osób jej potrzebuje. Gdy użytkownik zgłasza coś, co jest dostępne w jego panelu klienta, należy pokazać, jak to można zrobić samodzielnie.

Jeśli nie potrzebujesz wsparcia, to znaczy, że wszystko działa dobrze.

Drugą cechą, która bardzo oszczędza czas, jest długie uzupełnianie bazy wiedzy. Jeśli użytkownik ma problem, który nie mieści się w wykazie obsługiwanych działań (najczęściej są to pytania na poziomie „jak zainstalować serwer Minecraft” lub „Gdzie w Win Server skonfigurować VPS”), to pisana jest artykuł do bazy wiedzy. Dokładny artykuł pisany jest na wszystkie dziwne zapytania. Na przykład, jeśli użytkownik prosi wsparcie o usunięcie wbudowanej zapory systemu Windows Server, wysyłamy go do przeczytania o tym, co się wydarzy, gdy ją rzeczywiście wyłączysz, i jak skonfigurować uprawnienia tylko dla wybranego oprogramowania. Ponieważ problem zazwyczaj tkwi w tym, że coś nie może się połączyć z powodu ustawień, a nie z samej zapory. Ale wyjaśnianie tego za każdym razem w rozmowie jest bardzo trudne. A nie chce się wyłączać zapory, bo dość szybko możemy stracić albo maszynę wirtualną, albo klienta.

Jeśli coś dotyczącego aplikacji w bazie wiedzy staje się bardzo popularne, można dodać dystrybucję do rynku, aby została wprowadzona usługa „uruchom serwer z już zainstalowanym tym”. Właściwie tak było z Dockerem i tak było z serwerem Minecraft. Znowu jeden przycisk „zróbcie mi dobrze” w interfejsie oszczędza do stu zgłoszeń rocznie.

Tryb awaryjny

Po tych działaniach najwięcej poważnych awarii, wymagających ręcznej interwencji, zostaje z tym, że użytkownik z jakiegoś powodu stracił środek zdalnego dostępu do gościnnego systemu operacyjnego w hyperwizorze. Najczęstszym przypadkiem jest po prostu błędna konfiguracja zapory, a drugim co do częstotliwości – jakieś błędy, które uniemożliwiają normalne uruchomienie systemu Windows i zmuszają do ponownego uruchomienia w trybie awaryjnym. A w trybie awaryjnym RDP domyślnie nie jest dostępne.

Na tę okoliczność przygotowaliśmy tryb awaryjny. Generalnie, aby uzyskać dostęp do maszyny VDS, trzeba mieć jakiegoś klienta do pracy zdalnej. Najczęściej chodzi o dostęp konsolowy, RDP, VNC lub coś podobnego. Wadą tych metod jest to, że nie działają bez systemu operacyjnego. Ale na poziomie hyperwizora możemy uzyskać zarówno obraz na ekranie, jak i przesyłać naciśnięcia na klawiaturze! Prawda, że to mocno obciąża procesor (ze względu na faktyczną transmisję wideo), ale pozwala uzyskać pożądany wynik.

Dlatego daliśmy dostęp do trybu awaryjnego wszystkim użytkownikom, ale jest on ograniczony pod względem czasu nieprzerwanego używania. Na szczęście, jak pokazuje praktyka, ten czas jest wystarczający, aby się zrestartować i coś naprawić.

Rezultat – jeszcze mniej zgłoszeń do wsparcia. A tam, gdzie administrator może samodzielnie naprawić zgłoszenie, wsparcie nie musi wnikać rękami i się z tym borykać.

Pozostałe problemy

Bardzo często użytkownicy myślą, że wsparcie coś im wtrąca. Nic z tym, niestety, nie można zrobić (cóż, nie wymyśliliśmy). Dwa najczęstsze przykłady to limity zasobów i ochrona przed DDoS.

Na każdej maszynie wirtualnej istnieją limity obciążenia na dysk, pamięć i dozwolony ruch. Możliwość ustalania limitów jest zapisana w ofercie, same limity są dobierane tak, aby większość użytkowników mogła spokojnie pracować, nawet nie wiedząc o nich. Ale jeśli nagle zaczynasz bardzo mocno obciążać kanał i dysk, algorytmy automatycznie ostrzegają użytkownika. Od kwietnia zeszłego roku usunęliśmy automatyczne blokady. Zamiast tego wprowadziliśmy miękkie limity na czas określony.

Kiedyś to wyglądało tak: ostrzeżenie, a potem, jeśli użytkownik nie zareagował, automatyczna blokada. W tym momencie ludzie się obrażali: „Co wy, wasz system szwankuje, nic nie było!” — a potem można było albo spróbować zgłębić aplikacje, albo zaproponować podwyżkę planu taryfowego. Nie mamy możliwości rozstrzygania kwestii związanych z oprogramowaniem, bo to poza zakresem wsparcia. Choć w pierwszych kilku przypadkach rozwiązywaliśmy to wspólnie z użytkownikami. Szczególnie zapisał mi się w pamięci ten przypadek, gdzie w programie do podbijania wyświetleń na YouTube był wbudowany trojan, a ten trojan miał wycieki pamięci. W końcu doszliśmy do wniosku, że to nie były gejzenbugi, lecz problemy użytkowników, w przeciwnym razie zasypaliby nas podobnymi zgłoszeniami. Ale jeszcze nikt nie przyznał, że mógł sam przekroczyć limity.

Podobna historia — z DDoS: piszemy, że panie użytkowniku, jest pan pod atakiem. Proszę włączyć ochronę. A użytkownik: „To wy sami mnie atakujecie!” Oczywiście, że zwalamy jednego użytkownika DDoS-em, aby wyciągnąć 300 rubli. To opłacalna sprawa. Tak, wiem, że wiele dużych hostingów z wyższej półki włącza tę ochronę w planie, ale my tak nie możemy: ekonomika fast foodu narzuca inne minimalne ceny.

Nie rzadziej niezadowoleni są ci, których dane usunęliśmy. W sensie, że legalnie usunęliśmy je po upłynięciu opłaconego okresu. Jeśli ktoś nie odnawia wynajmu VDS, to przychodzi kilka powiadomień z wyjaśnieniem, co się stanie dalej. W momencie zakończenia opłaty maszyna wirtualna zostaje zatrzymana, ale jej obraz jest zapisywany. Przyjdzie jeszcze jedno powiadomienie, a potem — kolejne parę. Obraz jest przechowywany przez dodatkowe siedem dni i dopiero potem usuwany na zawsze. Jest jednak kategoria ludzi, którzy są tym bardzo niezadowoleni. Od „administrator odszedł, na jego pocztę przychodziły powiadomienia, odzyskajcie” po oskarżenia o oszustwo i groźby przemocy fizycznej. Powód — te same ceny dla wszystkich pozostałych użytkowników. Jeśli będziemy przechowywać przez miesiąc, potrzebne będą większe zasoby. Spowoduje to wyższe ceny dla każdego konkretnego klienta. A ekonomika fast foodu… No, rozumiecie. W rezultacie na forach otrzymujemy opinie w stylu „wzięli pieniądze, usunęli dane, oszuści”.

Zaznaczam, że mamy linię taryf premium. Sytuacja jest tam inna, ponieważ uwzględniamy życzenia klienta i elastycznie dostosowujemy zarówno limity, jak i usuwanie w przypadku braku płatności (prowadzimy go na minus, byle nie blokować). Tam jest to już ekonomicznie uzasadnione, ponieważ zdarza się naprawdę różnie, a utrzymanie stałego dużego klienta kosztuje.

Czasami użytkownicy są złośliwi. Kilka razy mieliśmy w systemie awarie związane z blokowaniem setek maszyn wirtualnych z powodu ewidentnie nielegalnych działań klientów. Właśnie z takich sytuacji potrzebowaliśmy własnych sterowników sieciowych, aby prowadzić monitoring aktywności sieciowej i widzieć, że użytkownik nie przeprowadza ataku ze swojego serwera. Tego rodzaju monitoring jest ważny, aby granice sąsiednich maszyn wirtualnych nie były naruszane przez niegrzecznych chłopaków.

Są tacy, którzy po prostu spamują, kopią lub w inny sposób naruszają ofertę. Następnie piszą do wsparcia i pytają, co poszło nie tak i dlaczego maszyna została zablokowana. Jeśli proces w zgłoszeniu na zrzucie ekranu nazywa się «spamer.exe», to prawdopodobnie coś poszło nie tak. Co dwa tygodnie dostajemy skargi od firm Sony lub Lucasfilm (teraz — Disney), że ktoś z naszej maszyny wirtualnej z naszego zakresu adresów IP rozprowadza piracki film. Za to natychmiast blokada i zwrot pozostałych pieniędzy na koncie według oferty (przypominam: kwantyzacja jest u nas co sekundę, więc reszta zawsze będzie dokładnie). A żeby zwrócić pieniądze, według prawa trzeba pokazać dowód tożsamości: to przeciwdziałanie praniu pieniędzy. Piraci zamiast pokazać dowód piszą, że odebraliśmy im pieniądze, zapominając doprecyzować pewne okoliczności.

A, tak. Najlepsze zapytanie roku to dla nas: «Czy można kilka dni przetestować maszynę wirtualną według taryfy 30 rubli miesięcznie przed zakupem?».

Podsumowanie

Pierwsza linia sortuje zgłoszenia i odpowiada typowymi działaniami. Najwięcej niezadowolenia pojawia się właśnie tutaj. Naprawa tego nie będzie możliwa, ponieważ podstawą poprawy jest automatyzacja hostingu, czyli ogromny backlog. Tak, mamy więcej niż wielu na rynku, ale to wciąż za mało. Dlatego najlepiej, co można zrobić, to ustawić monitoring pierwszej linii. Monitoring wsparcia — realizacja KPI pierwszej linii. Na bieżąco widoczne są opóźnienia w SLA: kto zawala, często — dlaczego. Zgłoszenia dzięki takim alertom nigdy się nie gubią. Tak, na zgłoszenie można odpowiedzieć szablonem niezwiązanym z tematem, ale dowiadujemy się o tym już na podstawie informacji zwrotnej.

Jeśli klient bardzo się prosi, specjalista drugiej linii może zalogować się na serwer i zrobić to, co jest potrzebne klientowi (warunkiem jest potwierdzenie w wiadomości e-mail, w której przekaże dane do logowania na serwer).

Takie działanie wykonujemy bardzo rzadko i powierzamy je tylko najlepszym, ponieważ chcemy mieć gwarancję, że dane użytkowników nie zostaną uszkodzone. Najlepsi to druga linia wsparcia.

Pierwsza linia ma bazę wiedzy, do której można wysyłać bardziej skomplikowane problemy.

Funkcjonalne konto użytkownika oraz baza wiedzy — udało nam się zmniejszyć liczbę zgłoszeń do średnio 1–1,5 rocznie na klienta.

Druga linia zazwyczaj obsługuje skomplikowane zgłoszenia, które wymagają ręcznego działania. Ciekawe, że im droższy plan taryfowy, tym mniej takich zgłoszeń na wirtualną maszynę. Zwykle dlatego, że ci, którzy mogą sobie pozwolić na drogi plan, albo mają specjalistów w zespole, albo połowa problemów nie występuje, ponieważ konfiguracje są wystarczające. Wciąż pamiętam tego bohatera, który instalował nie najnowszy Windows Server na konfiguracji z 256 MB pamięci RAM.

Druga linia ma zestaw dystrybucji oraz zestaw skryptów automatyzacji. Oba można aktualizować w razie potrzeby.

Druga linia i menedżerowie personalni VIP planów mogą dodawać adnotacje do profilu klienta. Jeśli jest administratorem Linux — tak to zapiszemy. To będzie wskazówką dla pierwszej linii: użytkownik dobrze wie, że to nie będzie strzał w nogę, lecz kontrolowane zniszczenie.

Trzecia linia rządzi najbardziej dziwacznie. Na przykład mieliśmy błąd, przez który nie można było uzyskać dostępu do jednej z funkcji panelu użytkownika w Firefoxie. Użytkownik dosłownie zaszantażował: „Jeśli nie naprawicie tego w ciągu 12 godzin, to napiszę na wszystkich recenzjach hostingu”. Okazało się, że problem był po stronie użytkownika, w jego własnym adblocku. Często pojawiają się złożone błędy bez szczegółów, a powtórzenie ich nie jest możliwe. Bywają detektywi ze zrzutem ekranu: „Dlaczego poprawiacie to od miesiąca?” — „Szukamy waszego błędu przez ten cały czas.” — „Aha, no to znowu mi się zdarzył dzisiaj, ale powtórzyć znowu nie mogłem...”

Właściwie nigdy nie wiadomo, gdzie pojawi się zrzut ekranu dialogu z pomocą techniczną, a jeśli ktoś kontaktuje się z pomocą, to ma problem. Można poprawić podejście. Przynajmniej spróbować.

Tak, wiemy, że nasza pomoc techniczna nie jest idealna, ale mam nadzieję, że łączy wystarczającą szybkość z odpowiednią jakością. I nie podnosi cen na plany dla tych, którzy mogą się bez niej obejść.