Nødtilstand (også omtalt som IPKVM), der giver mulighed for at oprette forbindelse til VPS uden RDP direkte fra hypervisor-niveauet, sparer 15–20 minutter om ugen.
Det første og vigtigste — irritér ikke folk. Over hele verden er support opdelt i niveauer, og medarbejderen på første niveau skal forsøge de typiske løsninger. Hvis opgaven går udover deres muligheder — skal den videregives til andet niveau. Sådan er det, at blandt VDS-administratorer er der ofte personer, der kan tænke. I modsætning til mange andre supportere. Nå, i det mindste betydeligt oftere. Og de strukturerer billetten godt, og beskriver straks alt, hvad der er nødvendigt. Hvis første niveau får 'sløret blik' og ved et uheld beder om at tænde og slukke — så er det fiasko.
Opgaven er meget enkel: at gøre supporten af vores VDS-hosting adekvat med minimale omkostninger. Fordi vi er fastfood-verdenen af hostingudbydere: intet særligt 'polering', lave priser, normal kvalitet. Der har allerede været en fortælling om, at med fremkomsten af Instagram-selvoptagede, der forsøger at automatisere driften af konti og ejere af små virksomheder med fjernregnskab og andre, der ikke er så teknologisk indstillede, er kommunikationen 'som admin med admin' holdt op med at fungere. Man måtte ændre sprogformen.
Nu vil jeg tale mere om processerne — og om de uundgåelige fejl der er forbundet med dem.
Irriter ikke folk nr. 1
Enhver support er en samlebåndsproduktion. Der kommer en anmodning, og medarbejderen på første niveau forsøger straks at genkende en typisk situation, der er sket tusind gange før og vil ske tusind gange igen. Der er 90 % chance for, at anmodningen er typisk, og at man kan svare på den ved at trykke på et par knapper, så skabelonen bliver indsat. I skabelonen skal man sædvanligvis skrive et par ord — og det er klart. Eller gå ind i kontrolgrænsefladen og trykke på et par knapper der. I mere komplekse tilfælde (f.eks. flytninger fra zone til zone) skal man følge en bestemt procedure.
Det, der irriterer mennesker mest, uanset andre kvaliteter af supporten, er den typiske reaktion på en atypisk anmodning. Der kommer en ticket, hvor alt er detaljeret beskrevet, der er en masse nødvendige data til tre spørgsmål fremad, kunden forudser dialogen… Og ved de første ord begynder supportmedarbejderen automatisk at skrive akorden til skabelonen 'prøv at genstarte, det burde hjælpe'.
Dette er præcis det, der frustrerer folk, og det er efter sådanne situationer, at der ofte kommer flest negative anmeldelser og vrede kommentarer. Det er tydeligt, at vi har begået fejl, og derfor kender vi statistikken. Vi har på forskellige måder fejlet, men sådanne tilfælde er altid bare vilde. Også for os selv. Vi ville selvfølgelig ønske, at det ikke skete overhovedet. Men det er ikke særlig muligt i praksis: en træt medarbejder trykker af og til bare på de sjove knapper en gang hver anden uge.
Undgå at irritere folk № 2
Det andet, der lige så effektivt frustrerer, er, når der ikke bliver svaret på en ticket i lang tid. I Europa er sådan opførsel fra supporten normalt: tre dage til accept af en hændelse er mere end normalt. Selvom det er meget presserende, og noget brænder, er der ingen sociale medier, telefon eller messenger – kun mail, og vent på din tur. I Rusland er dette langt mindre udbredt, men nogle tickets "glemmes" stadig. I starten satte vi SLA på første respons til 15 minutter. Og dette i en 24/7 ærlig service. Det er klart, at når VDS-hosting bliver stort, så opstår dette. Men hos tvivlsomme udbydere findes det ikke. Og vi var i starten netop et tvivlsomt udbyder og blev først senere mere eller mindre stor. Nå, mere eller mindre gennemsnitlig.
Første niveau – operatører, der har fået scripts og er blevet lært op til at reagere på typiske situationer. De sorterer hurtigt problemer og prøver at svare med en typisk handling inden for 15 minutter, eller informere om, at ticketen er under behandling og videregive den til det næste niveau.
Andet niveau – allerede hostingadministratorer, de kan næsten gøre alt manuelt. Her er også supportlederen, der kan gøre alt, og så lidt mere. Tredje niveau – allerede udviklerne, som modtager tickets som "ret dette i grænsefladen" eller "parameteren tages forkert i betragtning der".
Reducer antallet af anmodninger
Af forståelige grunde, hvis du ønsker at yde support til en lav pris, skal du ikke øge den første linje, så folk med scripts kan klare sig hurtigere, men øge automatiseringen. Så i stedet for folk med scripts skal der være rigtige scripts. Derfor var en af de første ting, vi gjorde, at automatisere processerne for oprettelse af virtuelle maskiner, skalering af ressourcer (inklusive diskopgradering og nedgradering, men ikke CPU-frekvens) og andre lignende opgaver. Jo mere brugeren kan gøre fra grænsefladen, desto lettere er det for den første linje, og desto mindre kan den være. Når en bruger henvender sig med noget, der er i deres personlige konto, skal der gøres og fortælles, hvordan de kan udføre det selv.
Hvis du ikke har brug for support, fungerer det åbenbart godt.
Den anden funktion, der sparer meget tid, er den langsomme udfyldning af vidensbasen. Hvis brugeren har et problem, der ikke er på listen over understøttede handlinger (oftest spørgsmål som "hvordan man opretter en Minecraft-server" eller "Hvor indstiller man VPS i Win Server"), skrives der en artikel til vidensbasen. En lige så detaljeret artikel skrives til alle mærkelige forespørgsler. For eksempel, hvis en bruger beder support om at fjerne den indbyggede firewall i Windows Server, sender vi dem til at læse om, hvad der vil ske, hvis det faktisk slås fra, og hvordan man kan tillade forbindelser kun for visse softwareprogrammer. Problemet ligger ofte i, at noget ikke kan oprette forbindelse på grund af indstillingerne, og ikke med selve firewallen. Men det er meget svært at forklare det hver gang i dialogen. Og man ønsker ikke at deaktivere firewallen, fordi vi snart kan miste enten den virtuelle maskine eller kunden.
Hvis noget om applikationssoftware i vidensbasen bliver meget besøgt, kan man oprette en distribution i markedspladsen, så der opstår en tjeneste "opret en server med dette allerede installeret". Sådan blev det med Docker, og sådan blev det med Minecraft-serveren. Igen sparer en enkelt knap "lav mig noget godt" i grænsefladen op til hundrede tickets om året.
Nødsituationstilstand
Efter disse handlinger er det mest alvorlige problem, der kræver manuel indgriben, det, at brugeren af en eller anden grund har mistet fjernadgang til gæste-OS i hypervisoren. Den hyppigste årsag er simpelthen en forkert firewall-konfiguration, den næsthyppigste er nogle fejl, der gør, at Windows ikke kan starte korrekt og tvinger en genstart i sikker tilstand. Og i sikker tilstand er RDP som standard ikke tilgængelig.
Vi har lavet en nødsituation til dette tilfælde. Normalt er det nødvendigt at have en eller anden klient til fjernarbejde for at få adgang til VDS-maskinen. Det drejer sig oftest om konsoladgang, RDP, VNC eller noget lignende. Ulempen ved disse metoder er, at de ikke fungerer uden et OS. Men på hypervisorniveau kan vi ikke bare få skærmbilledet, men også overføre tastetryk til det! Det belaster dog CPU'en ret meget (på grund af den faktiske videotransmission), men tillader os at få det ønskede resultat.
Derfor har vi givet adgang til nødsituationen til alle brugere, men den er begrænset med hensyn til kontinuerlig brug. Heldigvis viser erfaringen, at denne tid er mere end tilstrækkelig til at genstarte og rette op på tingene.
Resultatet er endnu færre supportbilletter. Og der, hvor administratoren selv kan rette i en billet, er der ikke behov for support til at blande sig.
De resterende problemer
Meget ofte tror brugerne, at supporten forsøger at pådutte dem noget. Desværre kan vi ikke rigtig gøre noget ved dette (eller vi har ikke fundet på noget). De to mest almindelige eksempler er ressourcelimits og DDoS-beskyttelse.
På hver virtuel maskine er der grænser for belastningen på disken, hukommelsen og tilladt trafik. Muligheden for at indføre grænser er angivet i tilbudet, mens selve grænserne er sat, så størstedelen af brugerne kan arbejde roligt uden at vide om dem. Men hvis du pludselig begynder at belaste kanalen og disken meget, vil algoritmerne automatisk advare brugeren. Siden april sidste år har vi fjernet autoblokeringsfunktionerne. I stedet indfører vi bløde begrænsninger over en varieret periode.
Tidligere var det sådan: først en advarsel, og hvis brugeren ikke reagerede, blev der automatisk blokering. I det øjeblik blev folk fornærmede: "Hvad laver I, det er jeres system, der fejler, der var ikke noget!" – og så kunne man enten prøve at finde ud af det med den applikationssoftware eller foreslå en opgradering af abonnementet. Vi har ikke mulighed for at undersøge funktionaliteten af applikationssoftware, fordi det ligger uden for supportens rammer. Selvom vi i de første par tilfælde undersøgte problemerne sammen med brugerne. Især husker jeg et tilfælde, hvor en views manipulator på YouTube havde en indbygget trojaner, og denne trojaner lækkede hukommelse. Vi kom frem til, at det ikke bare var gejserfejl, men brugernes problemer, ellers ville vi være blevet overvæltet af lignende anmodninger. Men ikke én person har indrømmet, at de kunne have overskredet deres abonnement selv.
En lignende historie gælder DDoS: vi skriver, at du, kære bruger, er under angreb. Vær venlig at aktivere beskyttelse. Og brugeren: "Det er jer, der attacker mig selv!" Selvfølgelig lægger vi DDoS på én bruger for at få dem til at betale 300 rubler. Det er en rentabel forretning. Ja, jeg ved, at mange større hostingfirmaer i den dyrere kategori inkluderer denne beskyttelse i abonnementet, men vi kan ikke gøre det: fastfoodøkonomien dikterer andre minimumspriser.
Der er ikke mindre ofte utilfredshed med supporten fra dem, hvis data vi har slettet. I den forstand, at vi legitimt har slettet dem efter udløbet af den betalte periode. Hvis nogen ikke fornyer lejen af VDS, sender vi flere varsler med forklaring på, hvad der vil ske fremad. På tidspunktet for udløbet stopper den virtuelle maskine, men dens billede gemmes. Der kommer endnu et varsel, og så yderligere et par stykker. Billedet opbevares i syv ekstra dage og slettes først derefter permanent. Så er der en kategori af mennesker, der er meget utilfredse med dette. Fra "administratoren blev fyret, varslerne kom til hans e-mail, genopret det" til anklager om svindel og trusler om fysisk vold. Årsagen er de samme priser for alle andre brugere. Hvis vi gemmer i en måned, kræver vi mere lagerplads. Det vil betyde højere priser for hver enkelt kunde. Og fastfoodøkonomien... Nå, I forstår. Og i sidste ende får vi anmeldelser på fora, der lyder sådan: "De tog pengene, slettede dataene, svindlere."
Jeg vil bemærke, at vi har en række premium-planer. Her er situationen selvfølgelig anderledes, da vi tager hensyn til kundens behov og fleksibelt tilpasser både grænser og nedtagning ved manglende betaling (vi bringer det i minus for at undgå blokering). Det er økonomisk bæredygtigt, fordi der virkelig kan ske alt, og det koster dyrt at bevare en konstant stor kunde.
Nogle gange er brugerne illoyale. Flere gange har vi haft problemer i vores system med blokering af hundrede virtuelle maskiner på grund af åbenlyst illegitime handlinger fra kunder. Faktisk er det netop på grund af sådanne situationer, at vi har brug for vores egne netværksdrivere for at overvåge netværksaktiviteten og se, at brugeren ikke udfører angreb fra sin server. En sådan overvågning er vigtig for at sikre, at grænserne mellem nabovirtuelle maskiner ikke bliver krænket af urolige personer.
Der er dem, der blot spammer, miner eller ellers overtræder betingelserne. Så henvender de sig til supporten og spørger, hvad der er gået galt, og hvorfor maskinen er blevet blokeret. Hvis processen i ticketen på skærmbilledet hedder "spamafsender.exe", så er der sikkert noget, der ikke går rigtigt. Endda engang hver anden uge modtager vi klager fra Sony eller Lucasfilm (nu Disney), om at nogen fra vores virtuelle maskine i vores IP-adresseområde deler ulovlige film. For sådanne handlinger blokeres der straks, og der gives refundering af de penge, der er tilbage på kontoen i henhold til aftalen (jeg minder om: kvantificeringen er sekundær, så saldoen vil altid være præcis). Og for at få pengene tilbage skal man ifølge lovgivningen vise identifikation: det er en modforanstaltning mod hvidvaskning af penge. Pirater skriver af en eller anden grund i stedet for at fremvise identifikation, at vi har taget deres penge, og glemmer at præcisere dele af omstændighederne.
Åh ja. Den bedste forespørgsel i året er: "Kan jeg teste en virtuel maskine med planen til 30 rubler om måneden i et par dage før køb?".
Resultat
Første linje sorterer billetter og svarer med typiske handlinger. Her er der flest utilfredsheder. At rette dette vil ikke være muligt, fordi fundamentet for rettelsen ligger i automatisering af hosting, det vil sige i et stort backlog. Ja, vi har mere end mange på markedet, men det er stadig ikke nok. Derfor er det bedste, vi kan gøre, at etablere overvågning af første linje. Overvågning af supporttjenesten — udførelsen af KPI for første linje. I realtid kan man se SLA-overskridelser: hvem der fejler, ofte hvorfor. Anmodninger går aldrig tabt takket være sådanne alarmer. Ja, der kan svares med en skabelon, der ikke er relevant for emnet, men det finder vi først ud af gennem feedback.
Hvis en kunde virkelig beder om det, kan specialisten fra anden linje logge ind på serveren og gøre det, som kunden har brug for (betingelsen er en bekræftelse via e-mail, hvor han oplyser loginoplysningerne til serveren).
Vi gør dette meget sjældent, og sådant arbejde stoler vi kun på de bedste, fordi vi ønsker at sikre, at brugerdata ikke bliver beskadiget. De bedste er anden linje support.
Første linje har en vidensbase, hvor man kan sende til at se det komplekse.
En funktionel kundeportal plus vidensbasen — og så har vi formået at reducere antallet af henvendelser til 1–1,5 om året per kunde i gennemsnit.
Anden linje behandler normalt komplekse anmodninger, som kræver manuel indsats. Interessant nok: jo dyrere prisplan, desto færre sådanne anmodninger pr. virtuel maskine. Normalt fordi dem, der har råd til en dyr plan, enten har specialister ansat, eller simpelthen fordi halvdelen af problemerne ikke opstår, da konfigurationerne er tilstrækkelige. Jeg husker stadig den helt, der installerede en ikke så gammel Windows Server på en konfiguration med 256 MB RAM.
Anden linje har et sæt distributionsfiler og et sæt automationsscripts. Begge dele kan opdateres efter behov.
Anden linje og personlige managere for VIP-planer kan tilføje noter til kundens profil. Hvis han er Linux-administrator — så skriver vi det ned. Det vil være en indikator for første linje: brugeren ved helt sikkert, at dette ikke bliver en selvdestruktiv handling, men en kontrolleret nedbrydning.
Den tredje linje viser det mest besynderlige. For eksempel havde vi en bug, hvor det ikke var muligt at få adgang til en af funktionerne i brugerens kontrolpanel i Firefox. Brugeren truede direkte: "Hvis I ikke retter det inden for 12 timer, så skriver jeg på alle hostinganmeldelser". Som det viste sig, var problemet i en brugerdefineret adblocker. På brugerens side, mærkeligt nok. Der kommer ofte komplekse fejl uden detaljer, og de kan ikke gentage dem. Nogle gange er der detektiver med skærmbilleder: "Hvorfor går I og retter det i en måned?" - "Vi søger bare jeres bug i hele denne tid", "Åh, jeg har også oplevet det i dag, men jeg kunne ikke gentage det igen..."
Generelt ved man aldrig, hvor et skærmbillede af dialogen med supporten vil ende, og hvis folk henvender sig til supporten, så har de et problem. Det er muligt at forbedre forholdet. I det mindste prøve.
Ja, vi ved, at vores support ikke er perfekt, men som jeg håber, så kombinerer den tilstrækkelig hastighed med tilstrækkelig kvalitet. Og den hæver ikke priserne på abonnementer for dem, der kan klare sig uden den.
Kilde: habr.com
