A támogatást olcsóbbá tesszük, igyekszünk nem veszíteni a minőségből

A támogatást olcsóbbá tesszük, igyekszünk nem veszíteni a minőségbőlA tartalék mód (más néven IPKVM), amely lehetővé teszi, hogy közvetlenül a hypervisor rétegből csatlakozzon RDP nélküli VPS-hez, így heti 15-20 percet takarít meg.

Az első és legfontosabb dolog, hogy ne idegesítsd fel az embereket. Világszerte sorokra oszlik a támogatás, a tipikus megoldásokat elsőként próbálja ki a munkavállaló. Ha a feladat túllép a korlátokon, vigye át a második sorba. Tehát a VDS-rendszergazdák között gyakran vannak olyan emberek, akik tudják, hogyan kell gondolkodni. Sok más támogatással ellentétben. Nos, legalábbis lényegesen gyakrabban. És jól megszerkesztik a jegyet, azonnal leírnak mindent, ami kell. Ha az első sor „elmosódik”, és véletlenül arra kéri, hogy kapcsolja be és ki, ez egy kudarc.

A feladat nagyon egyszerű: minimális költséggel megfelelő támogatást nyújtani VDS-tárhelyünkhöz. Mert mi vagyunk a tárhelyszolgáltatók világának gyorsétterme: nincs különösebb „nyalás”, alacsony árak, normál minőség. Korábban Volt már egy sztori arról, hogy a fiókkezelést automatizálni próbáló Instagram-kedvencek, valamint a távoli könyveléssel működő kisvállalkozók és más, a technológiában nem túl fejlett emberek megjelenésével megszűnt a kommunikáció, „mint adminisztrátor az adminnak”. Változtatnom kellett a kommunikáció nyelvén.

Most egy kicsit többet mesélek a folyamatokról - és a velük kapcsolatos elkerülhetetlen problémákról.

Ne idegesítsd fel az embereket #1

Minden támogatás összeszerelősoros gyártás. Jelentkezés érkezik, az első vonalbeli alkalmazott azonnal megpróbál felismerni egy tipikus helyzetet, ami már ezerszer megtörtént és még ezerszer meg fog ismétlődni. 90%-os esély van arra, hogy az alkalmazás tipikus, és megválaszolhatja, ha szó szerint megnyom néhány gombot, így a sablon kicserélődik. Általában csak néhány szót kell írnia a sablonba, és kész. Vagy lépjen a kezelőfelületre, és nyomjon meg néhány gombot ott. Bonyolultabb esetekben (például zónáról zónára történő átvitel) az algoritmust kell követnie.

Ami a legjobban irritálja az embereket, függetlenül a támogatás egyéb tulajdonságaitól, az az atipikus kérésre adott tipikus reakció. Érkezik egy jegy, ahol minden részletesen le van írva, három kérdéshez sok szükséges adat van, a kliens párbeszédet vár... És az első szavak szerint az autopilóta support munkatársa gépel egy akkordot, hogy helyettesítse a sablont "Próbáld meg újraindítani, segíteni fog."

Ez nyitja meg igazán az emberek elméjét, és az ilyen helyzetek után maradnak a legtöbb negatív kritika és dühös megjegyzések. Nyilvánvaló, hogy nagyot tévedtünk, innen ismerjük a statisztikákat. Általában sokféle módon hibáztunk, de az ilyen esetek mindig csak vad. Beleértve magunkat is. Természetesen szeretnénk, ha ez egyáltalán nem történne meg. De ez a gyakorlatban nem nagyon lehetséges: néhány hetente egyszer megnyomja a vicces gombokat a monotóniába belefáradt alkalmazott.

Ne idegesítsd fel az embereket #2

A második dolog, ami ugyanúgy megnyitja az elmét, az az, amikor senki sem reagál elég sokáig egy jegyre. Európában ez a támogató magatartás normális: az incidens munkába állása előtt három nappal több, mint a szokásos. Még akkor is, ha nagyon sürgős, és valami ég – nincs közösségi oldal, nincs telefon, nincs üzenetküldő, csak írjon e-mailt, és várja meg a sorát. Oroszországban ez sokkal ritkábban fordul elő, de néhány jegyet még mindig „elfelejtettek”. A munka legelején beállítottunk egy SLA-t az első 15 perces válaszra. És ez 24/7 őszinte. Nyilvánvaló, hogy amikor a VDS-tárhely nagy lesz, ez megjelenik. De a kétes szolgáltatóknak ez nincs meg. És csak az elején kételkedtünk, és csak aztán lettünk többé-kevésbé nagyok. Oké, többé-kevésbé átlagos.

Az első sor az operátorok, akik parancsfájlokat kaptak és megtanítottak reagálni a tipikus helyzetekre. Gyorsan megoldják a problémákat, és 15 percen belül megpróbálnak válaszolni egy tipikus művelettel, vagy jelenteni, hogy a jegy folyamatban van, és átadják a másodiknak.

A második vonal az adminisztrátorok fogadása; ők tudják, hogyan kell szinte mindent kézzel csinálni. Van egy támogatási menedzser is, aki mindent meg tud csinálni, és egy kicsit többet is. A harmadik sor a fejlesztők, olyan jegyeket kapnak, mint „javítsd ezt a felületen” vagy „ilyen és egy ilyen paramétert rosszul veszik figyelembe”.

Csökkentse az alkalmazások számát

Nyilvánvaló okokból, ha olcsón akarunk támogatást nyújtani, akkor ne az első sort növeljük, hogy gyorsabban tudják kezelni a szkripteket, hanem növeljük az automatizálást. Hogy a szkriptekkel rendelkező emberek helyett valódi szkriptek legyenek. Ezért az egyik első dolog, amit megtettünk, az volt, hogy automatizáljuk a virtuális gépek létrehozásának folyamatait, az erőforrások szerinti skálázást (beleértve a lemezt felfelé és lefelé, de nem a processzor frekvenciáját) és más hasonló dolgokat. Minél többet tud a felhasználó megtenni a felületről, annál könnyebben éli meg az első sort, és annál kisebb is lehet. Amikor egy felhasználó hozzáfér valamihez, ami a személyes fiókjában van, meg kell tennie, és meg kell mondania neki, hogyan teheti meg ezt saját maga.

Ha nincs szüksége támogatásra, akkor jó munkát végez.

A második jellemző, amely sok időt takarít meg, a tudásbázis kitöltéséhez szükséges hosszú idő. Ha a felhasználónak olyan problémája van, amely nem szerepel a támogatott műveletek listáján (leggyakrabban ezek a kérdések a „Minecraft szerver telepítése” vagy „Hol kell beállítani a VPS-t a Win Server-ben”) szintjén, akkor egy cikk van írva a tudásbázisban. Ugyanaz a részletes cikk íródott minden furcsa kérésre. Például, ha egy felhasználó a beépített Windows Server tűzfal eltávolítását kéri a támogatástól, akkor elküldjük neki, hogy olvassa el, mi történik, ha valóban letiltják, és hogyan módosíthatja csak a kiválasztott szoftverek engedélyeit. Mert a probléma általában azzal van, hogy valami nem tud csatlakozni a beállítások miatt, és nem magával a tűzfallal. De ezt nagyon nehéz minden alkalommal párbeszédben megmagyarázni. De valahogy nem akarom letiltani a tűzfalat, mert hamarosan elveszítjük vagy a virtuális gépet, vagy a klienst.

Ha valami nagyon népszerűvé válik a tudásbázisban az alkalmazásszoftverekkel kapcsolatban, akkor felveheti a disztribúciót a piactérre, így megjelenik a „szerver beállítása ezzel már telepítve” szolgáltatás. Valójában ez történt a Dockerrel, és ez történt a Minecraft szerverrel is. Ismét egy „tegyél jót” gomb a felületen évente akár több száz jegyet takarít meg.

Szükségállapot

Ezek után a lépések után a legsúlyosabb, kézi munkát igénylő meghibásodások maradnak abban, hogy a felhasználó valamilyen oknál fogva elvesztette a vendég operációs rendszer távoli elérésének lehetőségét a hypervisorban. A leggyakoribb eset az egyszerűen hibás tűzfalbeállítás, a második leggyakoribb olyan hiba, amely megakadályozza a Win normál indulását, és csökkentett módba kényszeríti az újraindítást. És csökkentett módban az RDP alapértelmezés szerint nem érhető el.

Erre az esetre létrehoztunk egy vészhelyzeti módot. Valójában általában egy VDS-gép eléréséhez szükség van valamilyen kliensre a távoli munkához. Leggyakrabban konzol hozzáférésről, RDP-ről, VNC-ről vagy valami hasonlóról beszélünk. Ezeknek a módszereknek az a hátránya, hogy operációs rendszer nélkül nem működnek. De hypervisor szinten tudjuk fogadni a képet a képernyőn és oda továbbítani a billentyűzet lenyomásait! Igaz, ez elég sokat terheli a processzort (a tényleges videó adás miatt), de lehetővé teszi a kívánt eredmény elérését.

Ezért minden felhasználónak megadtuk a vészhelyzeti módhoz való hozzáférést, de ez a folyamatos használat időtartamát tekintve korlátozott. Szerencsére, amint azt a gyakorlat mutatja, ez az idő elég ahhoz, hogy újraindítson és javítson valamit.

Az eredmény még kevesebb támogatási jegy. És ahol az admin maga is megjavíthatja a jegyet, ott a supportnak nem kell bemennie és kitalálnia.

Fennmaradó problémák

Nagyon gyakran a felhasználók úgy gondolják, hogy a támogatás rájuk szorít valamit. Sajnos ez ellen nem lehet mit tenni (vagy nem jutottunk semmire). A két leggyakoribb példa az erőforráskorlátozás és a DDoS-védelem.

Minden virtuális gépnek korlátai vannak a lemezterhelésre, a memóriára és a megengedett forgalomra vonatkozóan. A limitek beállításának lehetőségét az ajánlat tartalmazza, de magukat a limiteket úgy választják ki, hogy a legtöbb felhasználó nyugodtan dolgozhasson anélkül, hogy tudna róluk. De ha hirtelen túl sokat babrál a csatornával és a lemezzel, akkor az algoritmusok automatikusan figyelmeztetik a felhasználót. Tavaly április óta eltávolítottuk az automata zárakat. Ehelyett lágy korlátok beállítása változó időszakra.

Korábban ez így volt: figyelmeztetés, majd, ha a felhasználó nem vette figyelembe, automatikus blokkolás. És abban a pillanatban az emberek megsértődtek: "Mit beszélsz, a rendszered hibás, nem történt semmi!" -, majd megpróbálhatja megérteni az alkalmazásszoftvert, vagy felajánlhatja a díjcsomag emelését. Nincs lehetőségünk megérteni az alkalmazásszoftverek működését, mert ez meghaladja a támogatás kereteit. Bár az első néhány ügyet a felhasználókkal közösen rendezték. Különösen emlékszem arra, ahol a YouTube megtekintési csalójának volt egy beépített trójai, és ennek a trójainak volt a memóriája. Végül arra a következtetésre jutottunk, hogy nem Heisenbugokról van szó, hanem a felhasználókkal kapcsolatos problémákról, különben elárasztanak minket hasonló kérések. De még senki sem ismerte be, hogy ő maga is túllépheti a tarifákat.

Hasonló a történet a DDoS-szal is: azt írjuk, hogy Ön kedves felhasználó, támadás alatt áll. Csatlakoztassa a védelmet, kérem. És a felhasználó: "Igen, te magad támadsz rám!" Természetesen csak egy felhasználót DDoS-zunk, hogy 300 rubelt csaljunk ki nekik. Ez egy jövedelmező üzlet. Igen, tudom, hogy sok nagy tárhely a drágább kategóriában tartalmazza ezt a védelmet a tarifában, de ezt nem tehetjük meg: a gyorséttermi gazdaság más minimálárakat diktál.

Ugyanilyen gyakran azok, akiknek az adatait töröltük, elégedetlenek a támogatással. Abban az értelemben, hogy a fizetett időszak lejárta után jogszerűen törölték. Ha valaki nem hosszabbítja meg a VDS-kölcsönzést, akkor több értesítést küldenek, amelyek ismertetik, mi fog történni. A fizetés befejeztével a virtuális gép leáll, de a kép mentésre kerül. Újabb értesítés érkezik, majd még egy pár. A kép további hét napig tárolódik, mielőtt véglegesen törli. Tehát van egy kategória, akik nagyon elégedetlenek ezzel. Kezdve „az adminisztrátor kilépett, értesítéseket küldtek az e-mailjére, visszaállítás” és a csalás vádjával és testi sérelmekkel való fenyegetésig. Ennek oka az, hogy az összes többi felhasználó számára ugyanazok az árak. Ha egy hónapig tároljuk, akkor több tárhelyre lesz szükségünk. Ez magasabb árakat jelent minden egyes ügyfél számára. És a gyorsétterem gazdaságossága... Nos, értitek. Ennek eredményeként a fórumokon a „pénzt vittek el, adatokat töröltek, csalók” szellemében kapunk értékeléseket.

Szeretném megjegyezni, hogy van egy sor prémium tarifánk. Ott persze más a helyzet, hiszen figyelembe vesszük az ügyfél kívánságait és rugalmasan beállítjuk a limitet és a törlést is nemfizetés esetén (mínuszba írjuk, nehogy letiltsuk). Ott ez már gazdaságilag megvalósítható, mert tényleg bármi megtörténhet, és egy állandó nagy ügyfél megtartása drága.

Néha a felhasználók rosszindulatúak. Rendszerünk többször tapasztalt meghibásodásokat, amikor több száz virtuális gépet blokkoltak az ügyfelek néhány egyértelműen jogellenes tevékenysége miatt. Valójában pontosan az ilyen helyzetek miatt volt szükségünk saját hálózati illesztőprogramokra, hogy figyeljük a hálózati tevékenységet, és lássuk, hogy a felhasználó nem hajt végre támadást a szerveréről. Egy ilyen terv figyelemmel kísérése azért fontos, hogy a szomszédos virtuális gépek határait ne sértsék meg a garázda srácok.

Vannak, akik egyszerűen spammelnek, bányásznak, vagy más módon megszegik az ajánlatot. Aztán bekopogtat támogatásért, és megkérdezi, mi történt, és miért van blokkolva az autó. Ha a képernyőképen a jegyben szereplő folyamat neve „spam sender.exe”, akkor valószínűleg valami nem stimmel. Körülbelül kéthetente kapunk panaszt a Sony-tól vagy a Lucasfilmtől (jelenleg Disney), hogy valaki a virtuális gépünkről az IP-címeink tartományából terjeszt egy égetett filmet. Erre azonnal zárolja és visszautalja a számlán maradt pénzt az ajánlatnak megfelelően (hadd emlékeztesselek: a kvantálásunk másodpercenkénti, vagyis mindig lesz egyenleg). A pénz visszaszerzéséhez pedig a törvény szerint fel kell mutatnia az útlevelét: ez pénzmosás ellenes. A kalózok valamiért útlevél felmutatása helyett azt írják, hogy pénzt csikartunk ki belőlük, néhány körülményt elfelejtve tisztázni.

Ó, igen. Az év legjobb kérése a következő: „Tesztelhetek egy virtuális gépet néhány napig havi 30 rubel áron a vásárlás előtt?”

Teljes

Az első sor a jegyeket rendezi, és tipikus műveletekkel válaszol. Itt van a legnagyobb elégedetlenség. Ezt továbbra sem lehet majd kijavítani, mert a javítás alapja a hosting automatizálásban van, vagyis a hatalmas lemaradásban. Igen, több van a piacon, de még mindig nem elég. Ezért a legjobb dolog, amit tehetünk, az első vonalbeli felügyelet létrehozása. Help Desk Monitoring – Első vonalbeli KPI implementáció. Az SLA késések valós időben láthatók: ki ront, gyakran - miért. Az ilyen figyelmeztetéseknek köszönhetően az alkalmazások soha nem vesznek el. Igen, lehet, hogy a jegyet nem témához tartozó sablonnal válaszolják meg, de ezt már a visszajelzésekből megtudjuk.

Ha a kliens valóban kérdez, akkor a másodvonalbeli szakember elmehet a szerverre, és ott megteheti, amit a kliensnek kell (feltétel a levélben történő visszaigazolás, amelyben megadja a bejelentkezési adatokat a szervernek).

Ezt nagyon ritkán tesszük, és csak a legjobbakra bízzuk ezt a munkát, mert szeretnénk garanciát vállalni arra, hogy a felhasználói adatok nem sérülnek meg. A legjobbak a második támogatási vonal.

Az első sorban van egy tudásbázis, ahová küldhet összetett dolgok után kutatva.

Funkciókban gazdag személyes fiók plusz tudásbázis - és most átlagosan ügyfelenként évi 1-1,5-re tudtuk csökkenteni a kérések számát.

A második sor általában összetett, kézi munkát igénylő alkalmazásokat dolgoz fel. 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 tarifát, annak vagy szakemberei vannak, vagy egyszerűen a problémák fele azért nem merül fel, mert mindenre van elegendő konfiguráció. Még mindig emlékszem a hősre, aki a nem legrégebbi Windows Servert telepítette egy 256 MB RAM-mal rendelkező konfigurációra.

A második sor egy terjesztési készletet és egy automatizálási szkriptet tartalmaz. Mindkettő szükség szerint frissíthető.

A VIP tarifák második vonala és személyes menedzsere megjegyzéseket fűzhet az ügyfél profiljához. Ha ő Linux rendszergazda, akkor felírjuk. Ez lesz az első sor tipp: a felhasználó pontosan tudja, hogy ez nem egy lábon lövés lesz, hanem irányított pusztítás.

A harmadik sor uralja a legfurcsábbat. Például volt egy hiba, amely lehetetlenné tette személyes fiókja egyik funkciójának elérését a Firefoxban. A felhasználó egyenesen zsarolta: "Ha nem javítja ki 12 órán belül, akkor minden házigazdáról írok véleményt." Mint kiderült, a probléma az egyéni hirdetésblokkban volt. A felhasználói oldalon furcsa módon. Az összetett hibák gyakran részletek nélkül fordulnak elő, és többé nem ismételhetők meg. Vannak olyan nyomozók, akiknek képernyőképe: „Miért javítod egy hónapig?” - „Igen, egész idő alatt a te hibádat kerestük”, „Ó, hát ma megint ráakadtam, de nem tudtam megismételni”...

Általánosságban elmondható, hogy soha nem tudhatod, hová kerül a támogatással folytatott párbeszéd képernyőképe, és ha valaki támogatásért kopogtat, akkor baja van. Javíthatod a hozzáállásodat. Legalább próbáld meg.

Igen, tudjuk, hogy a támogatásunk nem tökéletes, de szeretném hinni, hogy a kellő sebességet megfelelő minőséggel ötvözi. És nem emeli a tarifaárakat azoknak, akik nélkülözhetik.

A támogatást olcsóbbá tesszük, igyekszünk nem veszíteni a minőségből

Forrás: will.com

Hozzászólás