Vészhelyzeti üzemmód (más néven IPKVM), amely lehetővé teszi a VPS-hez való hozzáférést RDP nélkül, közvetlenül a hypervisor szintjéről, heti 15–20 percet spórol meg.
Az első és legfontosabb — ne idegesítsük az embereket. Az egész világon a támogatás vonalakra oszlik, és az első vonal munkatársának meg kell próbálnia a tipikus megoldásokat. Ha a feladat túllép ezen, át kell adni a második vonalnak. Szóval elég gyakori, hogy a VDS adminisztrátorai között vannak olyanok, akik tudnak gondolkodni. Más támogatásokkal ellentétben. Legalábbis lényegesen gyakrabban. És jól strukturálják a jegyeket, azonnal leírva minden szükségeset. Ha az első vonal „szeme megfárad”, és véletlenül arra kér, hogy kapcsolja be és ki — ez kudarcnak számít.
A feladat nagyon egyszerű: a VDS hostingunk támogatásának megfelelővé tétele a lehető legkevesebb költséggel. Mert mi vagyunk a világ gyorséttermei a hosting szolgáltatók között: semmi különös „kényeztetés”, alacsony árak, normális minőség. már volt szó arról, hogy az Instagram-felhasználók, akik próbálnak automatizálni egy fiók kezelését, és a kisvállalkozások tulajdonosai távoli könyveléssel, valamint a technológiákban nem túl jártas emberek kommunikációja „mint adminisztrátor adminisztrátorral” már nem működik. Meg kellett változtatni a kommunikáció nyelvét.
Most egy kicsit többet mesélek a folyamatokról — és a velük járó elkerülhetetlen hibákról.
Ne idegesítsük az embereket № 1
Bármilyen támogatás egy tömegtermeléshez hasonló. Beérkezik egy kérelem, az első vonal munkatársa azonnal megpróbálja azonosítani a tipikus helyzetet, ami ezerszer már megtörtént, és ezerszer még meg fog. 90% eséllyel a kérelem tipikus, és a válasz megadásához elég egy pár gombot megnyomni, hogy a sablon beillesztődjön. A sablonba általában pár szót kell beírni — és kész. Vagy belépni a kezelőfelületre, és ott megnyomni pár gombot. Bonyolultabb esetekben (például területről területre történő áthelyezések) algoritmus szerint kell eljárni.
Ami a legjobban idegesíti az embereket, függetlenül a támogatás más minőségétől, az a tipikus reakció egy nem tipikus kérelemre. Beérkezik egy jegy, ahol minden részletesen le van írva, van egy rakás szükséges adat három kérdéshez előre, az ügyfél előre látja a párbeszédet… És a támogatás munkatársa az első szavak alapján automatikusan beírja a sablon „próbálja meg újraindítani, segíteni fog” kódot.
Ez pontosan az, ami sok embernek fejtörést okoz, és pont ezekből a helyzetekből marad a legnagyobb negatív vélemény és dühös kommentár. Nyilvánvaló, hogy sok hibát követtünk el, ezért is tudjuk a statisztikákat. Tényleg sokféleképpen tévedtünk, de ezek az esetek mindig elképesztőek. Számunkra is. Persze, szeretnénk, ha ez soha nem történne meg. De a gyakorlatban ez nem túl lehetséges: néhány hetente az egyhangúságtól fáradt munkatárs esetleg megnyom egy-egy
Ne idegesítsd az embereket #2
A második dolog, ami szintén fejtörést okoz, az az, amikor egy kérdésre senki nem válaszol elég sokáig. Európában az ilyen típusú ügyfélszolgálati magatartás normális: három nap a kérdés feldolgozásába vételére - ez több mint elfogadható. Még akkor is, ha nagyon sürgős, és valami égő, csak e-mail és várj a sorodra, se közösségi média, se telefon, se üzenetküldő. Oroszországban ez sokkal kevésbé elterjedt, de mégis, egyes kérdések „elfeledkeznek” róla. Már a munka elején 15 percre állítottuk be az SLA-t az első reakcióra. És ez egy 24/7-es, megbízható ügyeleté. Nyilvánvaló, hogy amikor a VDS szolgáltatás nagyobbá válik, akkor ez jelentkezik. De a kétes szolgáltatóknál ilyen nincs. Mi kezdetben éppen kétes szolgáltatók voltunk, és csak később váltunk viszonylag nagyobbá. Oké, viszonylag átlagos.
Az első vonal - olyan operátorok, akik kaptak szkripteket, és megtanították őket reagálni a tipikus helyzetekre. Gyorsan sort kerítenek a problémákra, és próbálnak 15 percen belül vagy egy tipikus cselekedettel válaszolni, vagy közölni, hogy a kérdés folyamatban van, és átadják a második vonalnak.
A második vonal - már a hosztolás adminisztrátorai, akik szinte mindent tudnak elvégezni manuálisan. Ott van a támogatás vezetője is, aki mindent tud, és egy kicsit többet is. A harmadik vonal - a fejlesztők, ahová olyan kérdések kerülnek, hogy „javítsák ezt meg a felületen” vagy „helytelenül számítják a X paramétert itt-ott”.
Csökkenteni a kérdések számát
Nyilvánvaló okokból, ha olcsón akar támogatást nyújtani, nem a bázist kellene növelni, hogy az emberek gyorsabban megoldják a problémákat a szkriptek használatával, hanem az automatizálást kellene fokozni. Így a valódi szkriptek helyettesíthetnék az embereket. Ezért az első dolgok egyike, amit tettünk, az volt, hogy automatizáltuk a virtuális gépek emelésének, a források skálázásának (beleértve a lemezek felfelé és lefelé történő skálázását, de nem a CPU frekvenciáját) és hasonlóknak a folyamatait. Minél több dolgot tud a felhasználó a felületen, annál egyszerűbb élni az első vonalon, és annál kisebb lehet az. Amikor a felhasználó olyan dologgal fordul hozzánk, ami megtalálható a személyes fiókjában, azt kell tennünk, hogy megmutatjuk, hogyan végezheti el önállóan.
Ha nincs szükséged támogatásra, az azt jelenti, hogy minden jól működik.
A második jellemző, amely nagyban megkönnyíti az időgazdálkodást, a tudásbázis hosszú távú kitöltése. Ha a felhasználónak olyan problémája van, amely nem szerepel a támogatott eljárások listájában (gyakran ezek a 'hogyan állítják be a Minecraft szervert' vagy 'Hol állítható be a VPS a Windows Serveren' típusú kérdések), akkor cikket írunk a tudásbázisban. Ugyanilyen részletes cikket írunk minden furcsa kérdésre is. Például, ha egy felhasználó azt kéri, hogy a támogatás távolítsa el a beépített Windows Server tűzfalat, akkor elmondjuk neki, mit jelentene, ha tényleg kikapcsolná, és hogyan adhatna hozzá engedélyeket csak a kiválasztott szoftver számára. Mert a probléma általában az, hogy valami nem tud kapcsolódni a beállítások miatt, nem a tűzfallal van gond. De ezt minden alkalommal elmagyarázni a párbeszédben nagyon nehéz. Ráadásul a tűzfalat lekapcsolni nem nagyon szeretnénk, mert elég hamar elveszíthetjük vagy a virtuális gépet, vagy az ügyfelet.
Ha valami a tudásbázisban nagyon népszerűvé válik, akkor érdemes bevinni a disztribúciót a piactérre, hogy megjelenhessen a 'szervert emeljünk fel már telepítve ezzel'. Ilyen lett a Docker, és ilyenné vált a Minecraft szerver is. Megintcsak, egy gombnyomás a felületen akár évi száz jegyet is megtakarít.
Vészhelyzeti üzemmód
Ezek után a legkomolyabb meghibásodások, amelyek kézi beavatkozást igényelnek, általában abból adódnak, hogy a felhasználó valamilyen okból elvesztette a távoli hozzáférését a vendég operációs rendszerhez a hipervizorban. A leggyakoribb eset a tűzfal helytelen beállítása, a második leggyakoribb pedig valamilyen hiba, amely megakadályozza a Windows normál indítását, így biztonságos módban kell újraindítani. Biztonságos módban az RDP alapértelmezés szerint nem elérhető.
Erre az esetre létrehoztunk egy vészhelyzeti módot. Általában a VDS-géphez való hozzáféréshez szükség van valamilyen távoli munkaügyfélre. Leggyakrabban konzolos hozzáférésről, RDP-ről, VNC-ről vagy hasonlóról van szó. Ezen módszerek hátránya, hogy nem működnek operációs rendszer nélkül. De a hipervizor szintjén képesek vagyunk megjeleníteni a képet a képernyőn és továbbítani a billentyűleütéseket! Igaz, ez jelentősen megterheli a processzort (a tényleges videó továbbítás miatt), de lehetővé teszi a kívánt eredmény elérését.
Ezért hozzáférést adtunk a vészhelyzeti módhoz minden felhasználónak, de a folyamatos használat időtartama korlátozott. Szerencsére a gyakorlat azt mutatja, hogy ez az időtartam elegendő ahhoz, hogy újraindítsuk és valamit kijavítsunk.
Az eredmény — még kevesebb támogatási jegy. Ott, ahol az adminisztrátor saját magának javíthat egy jegyet, a támogatásnak nem kell beavatkoznia és foglalkoznia vele.
A fennmaradó problémák
A felhasználók nagyon gyakran úgy érzik, hogy a támogatás valamilyen módon próbálja őket átverni. Sajnos nem tudunk ezzel mit kezdeni (vagy nem találtunk rá megoldást). A két leggyakoribb példa — ez a forráskorlátok és a DDoS-védelem.
Minden virtuális gépen korlátok vannak a lemez, a memória és a megengedett forgalom terhelésére. A korlátok bevezetésének lehetősége benne van az ajánlatban, a korlátokat pedig úgy állítják be, hogy a felhasználók többsége úgy tudjon dolgozni, hogy még csak tudomásuk sem legyen róluk. De ha hirtelen elkezdenél erősen terhelni a sávszélességet és a lemezt, akkor az algoritmusok automatikusan figyelmeztetik a felhasználót. Tavaly április óta eltávolítottuk az automatikus blokkokat. Ehelyett — puha korlátokat állítunk be változó időtartamra.
Régen így volt: figyelmeztetés, majd ha a felhasználó nem reagált, automatikus blokkolás. És ekkor az emberek megsértődtek: „Hát mit csináltok, a rendszeretek hibás, semmi nem volt!” — és innentől kezdve vagy megpróbálhatsz a szoftver problémáival foglalkozni, vagy javasolhatod a tarifacsomag emelését. A szoftver működését nem tudjuk ellenőrizni, mert az a támogatás határain kívül van. Bár az első néhány esetet közösen vizsgáltuk meg a felhasználókkal. Különösen emlékezetes volt az a helyzet, ahol egy YouTube-nézettség növelőnek beépített trójai vírusa volt, és ennek a trójainak elfolyt a memóriája. Végül arra a következtetésre jutottunk, hogy ezek nem gejzenbugok, hanem a felhasználók problémái, különben ugyanis több hasonló panasz érkezett volna. De még senki nem ismerte be, hogy ő maga túlléphette a tarifákat.
Hasonló történet a DDoS esetében: írjuk, hogy Ön, Tisztelt Felhasználó, támadás alatt áll. Kérjük, aktiválja a védelmet. És a felhasználó: „De hát ti támadtok engem!” Természetesen míg egy felhasználóra terhelnénk a DDoS-t, hogy 300 rubelt kicsaljunk tőle. Jól jövedelmező üzlet. Igen, tudom, hogy sok nagyobb hosting szolgáltató, akik drágább kategóriába tartoznak, beépítik ezt a védelmet a tarifákba, de mi ezt nem tehetjük: a gyorséttermek gazdasága más minimális árakat diktál.
Nem kevésbé gyakori, hogy azok elégedetlenek a támogatással, akinek az adatait eltávolítottuk. Abban az értelemben, hogy a jogszerűtlenét eltávolítottuk a lejárt időszak után. Ha valaki nem hosszabbítja meg a VDS bérlését, akkor több értesítést kap azzal a magyarázattal, hogy mi fog történni. A fizetési időszak végén a virtuális gép leáll, de a képe mentve marad. Érkezik egy újabb értesítés, majd még néhány. A kép hét további napig tárolódik, és csak ezután törlik véglegesen. Nos, van egy olyan kategória, akik emiatt nagyon elégedetlenek. Kezdve attól, hogy „az adminisztrátor elment, az ő e-mail címére érkeztek az értesítések, állítsátok vissza” és befejezve a csalás vádjával és fizikai megtorlás fenyegetésével. Az ok — ugyanazok az árak minden egyéb felhasználónak. Ha egy hónapig tárolnánk, akkor több tárolóra lenne szükség. Ez pedig magasabb árakat jelentene minden egyes ügyfél számára. A gyorséttermek gazdasága... Nos, érted. És ennek eredményeként a fórumokon olyan véleményeket kapunk, hogy „régi pénzt kértek, eltávolították az adatokat, csalók.”
Megjegyzem, hogy prémium tarifáink vannak. Ott természetesen más a helyzet, mivel figyelembe vesszük az ügyfél kívánságait, és rugalmasan állítjuk be a limiteket, valamint a nemfizetés esetén történő letiltást (toleráljuk a mínuszt, csak azért, hogy ne blokkoljunk). Ott már gazdaságilag indokolt, mert tényleg bármi megtörténhet, és egy állandó fontos ügyfél megőrzése sokba kerül.
Néha a felhasználók rosszindulatúak. Többször is voltak rendszerhibáink, amikor száz virtuális gép blokkolására került sor egyértelműen illegitim ügyféltevékenységek miatt. Valójában éppen ezek a helyzetek indokolták saját hálózati meghajtóink kifejlesztését, hogy figyelni tudjuk a hálózati aktivitást, és láthassuk, hogy a felhasználó nem indít támadást a saját szerveréről. Az ilyen típusú monitorozás fontos, hogy a szomszédos virtuális gépek határait a zabolátlan srácok ne sértsék meg.
Vannak, akik egyszerűen spamelnek, bányásznak, vagy más módon megsértik az ajánlatot. Aztán írnak a támogatásnak, és megkérdezik, hogy miért nem működik a rendszer, és miért blokkolták a gépet. Ha a jegyen a képernyőképen a folyamat neve „spamküldő.exe”, akkor valószínűleg valami nem stimmel. Két hetente kapunk panaszokat a Sony vagy a Lucasfilmtől (most már Disney), hogy valaki a virtuális gépünkről a mi IP-cím tartományunkból illegális filmet terjeszt. Ezért azonnali blokkolás és a számlán maradt pénz visszatérítése az ajánlat alapján (emlékeztetek: a kvantálás másodpercenként történik, tehát a fennmaradó összeg mindig pontosan meglesz). Ahhoz pedig, hogy a pénzt visszakapják, a törvény szerint be kell mutatniuk az igazolványt: ez a pénzmosás elleni védekezés. A kalózok valamiért a személyi igazolvány bemutatása helyett azt írják, hogy elvettük tőlük a pénzt, elfeledkezve a körülmények bizonyos részleteiről.
Ja, igen. Az év legjobb kérdése nálunk így hangzik: „Lehet pár napig tesztelni egy virtuális gépet a havi 30 forintos tarifán a vásárlás előtt?”
Result
Az első szint osztályozza a tiketeket és tipikus válaszokat ad. A legnagyobb elégedetlenség itt jelentkezik. Ezt helyrehozni már nem lehet, mivel a javítás alapja a hosting automatizálása, azaz egy hatalmas backlog. Igen, nekünk több van, mint sok versenytársunknak a piacon, de így is kevés. Ezért a legjobb, amit tehetünk, hogy fejlesztjük az első szint monitorozását. A támogatási szolgálat monitorozása — az első szint KPI-jának teljesítése. Valós időben láthatók az SLA-kból eredő késések: ki hibázik, gyakran — miért. A kérések ezeknek az értesítéseknek köszönhetően soha nem vesznek el. Igen, egy tiketre témához nem illő sablonnal is válaszolhatnak, de ezt már a visszajelzés alapján tudjuk meg.
Ha a kliens nagyon kéri, akkor a második szint szakembere beléphet a szerverre, és elvégezheti a szükséges feladatokat (a belépési adatok írásbeli megerősítése szükséges).
Ezt nagyon ritkán tesszük, és az ilyen munkát csak a legjobbakra bízzuk, mert szeretnénk biztosítani, hogy a felhasználói adatok ne sérüljenek. A legjobbak pedig a második szintű támogatás.
Az első szint tudásbázissal rendelkezik, ahol a bonyolultabb kérdéseket lehet megtekinteni.
A funkciókban gazdag ügyfélkapu plusz tudásbázis — és így sikerült csökkenteni az éves átlagos megkeresések számát 1-1,5-re ügyfelenként.
A második szint általában a kézi munkát igénylő bonyolult kéréseket kezeli. Ami jellemző: minél drágább a tarifacsomag, annál kevesebb ilyen kérés érkezik virtuális gépenként. Általában azért, mert aki megengedheti magának a drága csomagot, annak vagy van szakembere az állományában, vagy egyszerűen a konfigurációk mindent kielégítenek. Még mindig emlékszem arra a hősre, aki nem a legöregebb Windows Servert telepítette egy 256 MB RAM-os konfigra.
A második szint disztribúciós készlettel és automatizáló szkriptek készletével rendelkezik. Ezeket szükség szerint frissíteni lehet.
A második szint és a VIP tarifák személyes menedzserei képesek megjegyzéseket hozzáadni az ügyfélprofilhoz. Ha linux adminisztrátor — úgy is rögzítjük. Ez az első szint számára jelzés lesz: a felhasználó pontosan tudja, hogy ez nem öncsonkítás lesz, hanem kontrollált destrukció.
A harmadik vonal a legfurcsább dolgot szabályozza. Például volt egy bugunk, hogy nem lehetett elérni a személyes fiók egyik funkcióját Firefoxban. A felhasználó közvetlenül zsarolt: "Ha 12 órán belül nem javítják, akkor írok minden hosztértékelésbe." Kiderült, hogy a probléma a felhasználó saját egyedi reklámblokkolójában volt. Furcsa módon a felhasználó oldalán. Gyakran érkeznek bonyolult hibák részletek nélkül, és már nem tudják megismételni. Van, aki detektívkedik a képernyőfelvétellel: "Miért javítják hónapok óta?" — "Csak a bugját keressük azóta", "Aha, pedig ma is előfordult, de megint nem tudtam megismételni..."
Egyébként sosem tudod, hol landol egy képernyőfelvétel a támogatással folytatott párbeszédről, és ha valaki a támogatáshoz fordul, akkor problémája van. Lehet javítani a kapcsolatot. Legalább megpróbálni.
Igen, tudjuk, hogy a támogatásunk nem tökéletes, de szeretném hinni, hogy elég gyors és megfelelő minőségű. És nem emeli meg a tarifák árát azoknak, akik meg tudják úszni nélküle.
Forrás: habr.com
