Režim havarijního přístupu (také nazývaný IPKVM), který umožňuje připojení k VPS bez RDP přímo na úrovni hypervisoru, šetří 15–20 minut týdně.
První a nejdůležitější — nezlobit lidi. Na celém světě je technická podpora rozdělena do úrovní, a pracovník první úrovně by měl nejprve zkusit typické způsoby řešení. Pokud úkol překročuje jejich hranice, měl by být předán druhé úrovni. Mezi správci VDS se však často vyskytují lidé, kteří umí přemýšlet. Na rozdíl od mnoha jiných podpor. No, alespoň podstatně častěji. A dobře strukturovaný tiket už od začátku popisuje vše potřebné. Pokud první úroveň „přehlédne“ a náhodou na takový dotaz požádá o zapnutí a vypnutí — to je fiasko.
Úkol je velmi jednoduchý: udělat podporu našeho VDS hostingu adekvátní při minimálních nákladech. Protože jsme fastfood světa poskytovatelů hostingu: žádné zvláštní „vylepšování“, nízké ceny, normální kvalita. byl už řeč o tom, že s příchodem instagramových influencerů, kteří se snaží automatizovat správu účtů a majitelé malých podniků s externí účetní a ostatní méně technologicky zdatní lidé, komunikace „jako admin s adminem“ přestala fungovat. Bylo nutné změnit jazyk komunikace.
Nyní povím o procesech trochu více — a o nevyhnutelných chybách s nimi.
Nezlobit lidi číslo 1
Jakákoli podpora je masová výroba. Příjde žádost, pracovník první úrovně se hned snaží rozpoznat typickou situaci, která se již stokrát stala a stokrát ještě stane. Šance 90 %, že žádost je typická, a odpovědět na ni lze stisknutím doslova pár tlačítek, aby se použila šablona. Do šablony obvykle stačí napsat pár slov — a je hotovo. Nebo se přihlásit do ovládacího rozhraní a tam stisknout pár tlačítek. V složitějších případech (přesuny z oblasti do oblasti, například) je třeba provést akce podle algoritmu.
To, co lidi nejvíce naštve bez ohledu na ostatní kvality podpory, je typická reakce na netypickou žádost. Příjde tiket, kde je vše podrobně popsáno, je tam spousta potřebných dat na tři otázky dopředu, klient předpokládá dialog… A na základě prvních slov pracovník podpory na autopilota vypadá akord pro vložení šablony „zkuste restartovat, mělo by to pomoci“.
Tohle lidi opravdu šokuje a právě po takových situacích zůstává nejvíce negativních recenzí a rozhněvaných komentářů. Je jasné, že jsme se v tomhle mýlili, a odtud známe statistiku. Občas jsme chybovali různě, ale takové případy jsou vždy naprosto šílené. Včetně pro nás samotné. Samozřejmě bychom si přáli, aby se něco takového nestávalo vůbec. Ale v praxi to není moc možné: jednou za několik týdnů unavený zaměstnanec bez myšlení stiskne ty zábavné tlačítka.
Nehněvejte lidi č. 2
Druhá věc, která mi stejně tak leze na nervy, je, když na ticket nikdo dost dlouho neodpovídá. V Evropě je takové chování podpory běžné: tři dny na přijetí incidentu do práce — to je více než normální. I když je to pro vás velmi urgentní a něco hoří — žádné sociální sítě, žádný telefon, žádný messenger, jen e-mail a čekejte na svou řadu. V Rusku je to mnohem méně rozšířené, ale stejně se některé tickety „zapomínají“. Ještě na samém začátku jsme nastavili SLA na první reakci 15 minut. A to při 24/7 seriózní podpoře. Je jasné, že když se VDS hosting stává velkým, to se objevuje. Ale u pochybnějších poskytovatelů takové věci nejsou. A na začátku jsme byli právě takovým podezřelým a teprve později se stali více méně velkými. No, spíše průměrnými.
První linie — operátoři, kterým dali skripty a naučili je reagovat na typické situace. Rychle a efektivně třídí problémy a snaží se do 15 minut buď odpovědět typickým způsobem, nebo informovat, že ticket je v práci, a předat ho druhé linii.
Druhá linie — to jsou už administrátoři hostingu, kteří umí téměř všechno dělat ručně. Zde je také vedoucí podpory, který umí všechno a ještě trochu navíc. Třetí linie — to už jsou vývojáři, ke kterým přicházejí tickety jako „opravit tohle v rozhraní“ nebo „takový parametr se tam počítá špatně“.
Snížit počet žádostí
Z pochopitelných důvodů, pokud chcete poskytovat levnou podporu, musíte zvýšit automatizaci, nikoli první linii, aby lidé se scénáři mohli rychleji reagovat. Místo lidí se scénáři by měly být skutečné skripty. Proto jednou z prvních věcí, které jsme udělali, je automatizace procesů spuštění virtuálního stroje, škálování zdrojů (včetně disku nahoru a dolů, ale ne frekvence procesoru) a podobné úkoly. Čím více může uživatel udělat z rozhraní, tím jednodušší to je pro první linii, a tím méně může být. Když se uživatel obrátí s něčím, co je dostupné v jeho uživatelském rozhraní, je třeba udělat a vysvětlit, jak to lze provést samostatně.
Pokud nepotřebuješ podporu, znamená to, že si dobře poradí.
Druhá vlastnost, která šetří čas, je dlouhé vyplňování znalostní báze. Pokud má uživatel problém, který není na seznamu podporovaných akcí (nejčastěji jde o dotazy na úrovni „jak nastavit server Minecraftu“ nebo „kde v systému Windows Server nastavit VPS“), je napsán článek do znalostní báze. Stejně podrobný článek je napsán na všechny podivné dotazy. Například pokud uživatel požádá podporu o odstranění vestavěného firewallu Windows Server, pošleme mu odkazy na to, co se stane, pokud ho skutečně deaktivuje, a jak povolit přístup pouze pro vybraný software. Protože problém bývá obvykle s tím, že se něco nemůže připojit kvůli nastavením, a ne s vlastním firewallem. Ale vysvětlit to pokaždé v dialogu je velmi složité. A deaktivovat firewall se nechce, protože poměrně brzy můžeme ztratit buď virtuální stroj, nebo klienta.
Pokud něco v aplikacích v znalostní bázi získává velkou návštěvnost, je možné vytvořit distribuci na trhu, aby se objevila služba „spustit server s již nainstalovaným tímto“. Tak to začalo s Dockerem a tak to začalo se serverem Minecraftu. Opět jedna tlačítko „udělejte mi to dobře“ v rozhraní šetří až sto tiketů za rok.
Nouzový režim
Po těchto krocích zůstává nejvíce vážných poruch vyžadujících manuální zásah v tom, že uživatel z nějakého důvodu ztratil prostředek vzdáleného přístupu k hostitelskému OS v hypervizoru. Nejčastější situace — banálně nesprávně nastavená firewall, druhá nejčastější — nějaké chyby, které brání Windows v normálním spuštění a nutí jej restartovat v nouzovém režimu. A v nouzovém režimu je RDP ve výchozím nastavení nedostupné.
Pro tento případ jsme vytvořili havarijní režim. Obecně je obvykle pro přístup k VDS stroji potřeba mít nějakého klienta pro vzdálenou práci. Nejčastěji se jedná o přístup prostřednictvím konzole, RDP, VNC nebo něco podobného. Nevýhodou těchto metod je, že nefungují bez operačního systému. Ale my na úrovni hypervizoru můžeme získat obraz na obrazovce a přenášet tam stisky kláves! Pravda, to dost zatěžuje procesor (kvůli faktickému streamování videa), ale umožňuje získat požadovaný výsledek.
Proto jsme poskytli přístup k havarijnímu režimu všem uživatelům, ale je omezený co do doby nepřetržitého používání. Naštěstí, jak ukazuje praxe, tohoto času je dost na restartování a opravu něčeho.
Výsledek — ještě méně ticketů na podporu. A tam, kde může administrátor opravit ticket sám, není třeba, aby podpora zasahovala a zkoumala.
Zbylé problémy
Velmi často uživatelé myslí, že jim podpora něco vnucuje. S tím, bohužel, nelze nic dělat (no nebo jsme na to nepřišli). Dva nejčastější příklady — to jsou limity na zdroje a DDoS ochrana.
Na každém virtuálním stroji jsou limity zatížení na disk, paměť a povolený provoz. Možnost nastavení limitů je popsána v nabídce, samotné limity jsou nastaveny tak, aby většina uživatelů mohla bez problémů pracovat, aniž by o nich věděla. Ale pokud náhle začnete hodně vyčerpávat kanál a disk, algoritmy automaticky varují uživatele. Od dubna minulého roku jsme zrušili automatické blokace. Místo toho - nastavení měkkých limitů na proměnlivou dobu.
Dříve to bylo takhle: varování, a pokud uživatel nereagoval, následovala automatická blokace. A v tu chvíli byli lidé rozčílění: "Co si to dovolujete, vaše systémy nefungují, nic se nestalo!" A pak se dalo buď pokusit vyřešit problém se softwarovým nástrojem, nebo navrhnout zvýšení tarifu. Nemáme možnost zabývat se provozem aplikací, protože to překračuje rámec naší podpory. Prvních několik případů jsme však vyřešili společně s uživateli. Nejvíce mi utkvěl v paměti ten, kdy měl manipulační program na YouTube zabudovaný trojan, a ten trojan měl únik paměti. Nakonec jsme dospěli k závěru, že to nejsou žádné „heisenbugy“, ale problémy uživatelů, jinak bychom byli zahlceni podobnými žádostmi. Ale ještě se nikdy nikdo nepřiznal, že by sám překročil limit tarifu.
Podobná situace je s DDoS: píšeme, že jste, vážený uživateli, pod útokem. Prosím, zapněte ochranu. A uživatel říká: "To vy mě útočíte sami!" Samozřejmě, že cíleně útočíme na jednoho uživatele DDoS, abychom z něj vytáhli 300 korun. Je to přece výhodný obchod. Ano, vím, že mnoho velkých hostingových společností v kategorii dražších zahrnuje tuto ochranu v tarifu, ale my to dělat nemůžeme: ekonomika fast foodu diktuje jiné minimální ceny.
Nejčastěji si na podporu stěžují ti, jejichž data jsme odstranili. V tom smyslu, že jsme je legitimně odstranili po uplynutí placeného období. Pokud někdo neobnoví pronájem VDS, dostane několik upozornění s vysvětlením, co se bude dít dál. V okamžiku konce platby se virtuální stroj zastaví, ale jeho obraz se zachovává. Přijde ještě jedno upozornění, a pak – ještě několik. Obraz se uchovává dalších sedm dní a teprve poté je trvale odstraněn. Takže je tady skupina lidí, kteří jsou s tím velmi nespokojeni. Začínající od „admin byl propuštěn, na jeho e-mail chodila upozornění, obnovte to“ a konče obviněními z podvodu a hrozbami fyzické pomsty. Důvod – stále stejné ceny pro všechny ostatní uživatele. Pokud bychom uchovávali data měsíc, potřebovali bychom více úložišť. To by znamenalo vyšší ceny pro každého jednotlivého klienta. A ekonomika fast foodu... No, to už chápete. A nakonec dostáváme na fórech recenze ve stylu „vzali peníze, odstranili data, podvodníci“.
Rád bych poznamenal, že máme řadu prémiových tarifů. Situace je tam samozřejmě jiná, protože zohledňujeme přání zákazníka a flexibilně nastavujeme jak limity, tak odstranění při neplatnosti (přivedeme jej do mínusu, jen abychom nezablokovali). Tam je to již ekonomicky rozumné, protože se opravdu může stát cokoliv a udržení stálého velkého klienta je cenné.
Někdy jsou uživatelé úmyslně zlí. Několikrát jsme v systému měli problémy s blokováním stovek virtuálních strojů kvůli nějakým zjevně nelegitimním akcím zákazníků. Ve skutečnosti jsme právě kvůli takovým situacím potřebovali vlastní síťové ovladače, abychom sledovali síťovou aktivitu a viděli, že uživatel neprovádí útok ze svého serveru. Monitorování takového plánu je důležité, aby se hranice sousedních virtuálek nenarušovaly výtržníky.
Jsou takoví, kteří prostě spamují, těží nebo jinak porušují podmínky. Pak píší na podporu a ptají se, co se pokazilo a proč je stroj zablokován. Pokud je proces v tiketu na snímku obrazovky nazván „spamer.exe“, pravděpodobně se něco děje špatně. Ještě jednou za dva týdny k nám přicházejí stížnosti od společností Sony nebo Lucasfilm (nyní — Disney), že někdo z naší virtuálky z našeho rozsahu IP adresů distribuuje pirátský film. Za to okamžitě zablokujeme a vrátíme zbývající peníze na účtu podle nabídky (připomínám: kvantování máme po vteřinách, tedy zbytek bude vždy přesně). A abychom vrátili peníze, je podle zákona potřeba ukázat doklad: je to opatření proti praní peněz. Piráti nám nějak zapomínají říct, že jsme jim vzali peníze, když místo ukázání dokladu píší, že jsme je oloupili.
A ano. Nejlepší dotaz roku máme takový: „Lze na několik dní otestovat virtuální stroj za tarif 30 korun za měsíc před nákupem?“
Výsledek
První úroveň třídí tikety a odpovídá pomocí standardních akcí. Nejvíce nespokojenosti je právě zde. Opravit to stejně nebude možné, protože základ opravy spočívá v automatizaci hostingu, tedy v obrovském backlogu. Ano, máme více než mnozí na trhu, ale stále to není dost. Proto nejlepší, co můžeme udělat, je zlepšit monitoring první úrovně. Monitoring zákaznické podpory - plnění KPI první úrovně. V reálném čase jsou viditelné prodlení podle SLA: kdo chyboval a často - proč. Žádosti díky takovým alertům nikdy neztrácejí. Ano, na tiket může odpovědět šablonou, která nesouvisí s tématem, ale to se dozvíme až z zpětné vazby.
Pokud klient velmi žádá, může specialista druhé úrovně vstoupit na server a udělat to, co klient potřebuje (podmínkou je potvrzení e-mailem, ve kterém sdělí údaje pro přístup na server).
Děláme to velmi zřídka a tuto práci svěřujeme pouze nejlepším, protože chceme mít záruky, že uživatelská data nebudou poškozena. Nejlepší jsou specialisté druhé úrovně podpory.
První úroveň má znalostní bázi, kam lze posílat pro složité případy.
Bohaté funkce osobního účtu plus znalostní báze - a tak se nám podařilo snížit počet žádostí na průměr 1–1,5 ročně na klienta.
Druhá úroveň obvykle zpracovává složité žádosti, které vyžadují ruční práci. Co je charakteristické: čím dražší tarifní plán, tím méně takových žádostí na virtuální stroj. Obvykle proto, že ti, kdo si mohou dovolit drahý tarif, mají buď specialisty ve stavu, nebo prostě polovina problémů nevzniká, protože konfigurace na všechno stačí. Stále si pamatuji tu hrdinu, který instaloval nikoliv nejstarší Windows Server na konfiguraci s 256 MB pracovního paměti.
Druhá úroveň má sadu distribučních souborů a sadu automatizačních skriptů. Oba dva je možné aktualizovat podle potřeby.
Druhá úroveň a osobní manažeři VIP tarifů umějí přidávat poznámky do profilu klienta. Pokud je to Linux-administrátor — tak to zapíšeme. To bude vodítkem pro první úroveň: uživatel přesně ví, že to nebude zásah do nohy, ale kontrolované zničení.
Třetí linie vládne tomu nejpodivnějšímu. Například jsme měli chybu, kdy nebylo možné se dostat k jedné z funkcí osobního účtu ve Firefoxu. Uživatel přímo hrozil: „Pokud to do 12 hodin neopravíte, napíšu o tom na všechny hostitelské recenze.“ Jak se ukázalo, problém byl v jeho vlastním adblockeru. Na straně uživatele, jak podivné se to může zdát. Často přicházejí složité chyby bez detailů a nelze je znovu zopakovat. Jsou detektivové se screenshotem: „Proč to opravujete už měsíc?“ — „Ano, hledáme vaši chybu celý ten čas, prostě,“ „Aha, dnes se mi to zase stalo, ale znovu jsem to nemohl zopakovat…
Vůbec nikdy nevíte, kde se objeví screenshot rozhovoru s podporou, a pokud někdo kontaktuje podporu, má problém. Můžeme zlepšit vztahy. Minimálně se o to pokusit.
Ano, víme, že naše podpora není dokonalá, ale jak doufám, spojuje dostatečnou rychlost se dostatečnou kvalitou. A nezvyšuje ceny tarifů těm, kteří by se bez ní obešli.
Zdroj: habr.com
