Esimene väljaanne uues põhiharus

Hädaolukord (tuntud ka kui IPKVM), mis võimaldab VPS-iga ühenduda ilma RDP-ta hüperviisoritasandilt, säästab 15–20 minutit nädalas.

Esiteks ja kõige tähtsam — ära äkki inimesi. Kogu maailmas jaguneb tugi tasandite kaupa, ning esimese taseme töötaja peab proovima tüüpilisi lahendusviise. Kui probleem ületab nende võimeid — tuleb see edastada teisele tasemele. Noh, administraatorite seas on VDS-is piisavalt sageli inimesi, kes oskavad mõelda. Erinevalt paljusid teistest tugiteenustest. Noh, vähemalt oluliselt sagedamini. Ja nad struktureerivad kutset hästi, kirjeldades kohe kõike, mis vajalik. Kui esimese taseme töötaja

Probleem on väga lihtne: muuta meie VDS-hostingu tugi mõistlikuks minimaalsete kuludega. Sest me oleme kiiretoidukohtade maailmas hostinguteenuse pakkujatena: pole mingit erilist „kihutamist”, madalad hinnad, normaalne kvaliteet. Varem Juba oli juttu sellest, et Instagrami nunnude ilmumisega, kes üritavad kontode haldamist automatiseerida koos väikeettevõtete omanike kaug- raamatupidamise ja teiste tehnoloogiate osas mitte liiga arenenud inimestega, ei toimi suhtlemine „nagu administraator administraatoriga” enam. Pidi suhtlemiskeelt muutma.

Nüüd räägin protsessidest veidi rohkem — ja vältimatutest vigadest nendega seoses.

Ära äkki inimesi № 1

Iga tugi on nagu masstootmine. Tulekutsed jõuavad ja esimese taseme töötaja proovib kohe tuvastada tüüpilise olukorra, mis on olnud tuhandeid kordi ja juhtub veel tuhandet korda. 90% tõenäosus, et taotlus on tüüpiline, ja sellele saab vastata kas paar nuppu vajutades, et sisestada mall. Malli tuleb tavaliselt täita paar sõna — ja valmis. Või minna haldustarkvarasse ja vajutada seal mõned nupud. Komplitseeritud juhtudel (nt tsoonide vahetused) tuleb toimingud teostada vastavalt algoritmile.

Kõige rohkem ärritab inimesi sõltumata muudest tugiteenuse omadustest — see on tüüpiline reaktsioon atüüpilise taotluse suhtes. Kutse tuleb, kus on kõik üksikasjalikult kirjeldatud, on hulgaliselt vajalikke andmeid kolme küsimuse jaoks ette, klient ennustab dialooge… Ja juba esimesest lausest hakkab tugiteenuse töötaja automaatselt sisestama šablooni „proovige taas käivitada, peaks aitama”.

Just this directly reveals people's minds, and precisely after such situations, there are the most negative reviews and angry comments left. It's clear that we were mistaken, that's where we know the statistics from. We made mistakes in various ways, but these cases are always simply insane. Including for us. We would certainly like such things to never happen at all. But that's not very possible in practice: once every few weeks, a tired employee from the monotony might press cheerful buttons.

Don't annoy people № 2

The second thing that equally reveals the mind is when no one responds to a ticket for a long time. In Europe, such support behavior is normal: three days before an incident is accepted for work is more than the norm. Even if it's very urgent and something is on fire — no social media, no phone, no messenger, just email and wait your turn. In Russia, this is much less common, but still, some tickets get 'forgotten.' At the very beginning of our work, we set an SLA for first response of 15 minutes. And this is with 24/7 honesty. It's clear that when VDS hosting becomes large, this appears. But dubious service providers don't have this. When we started, we were just dubious and only later became somewhat larger. Okay, somewhat medium.

The first line — operators who were given scripts and trained to respond to typical situations. They quickly sort problems and try, within 15 minutes, either to respond with a typical action or to inform that the ticket is being processed, and forward it to the second line.

The second line — these are already the hosting administrators who can do almost everything by hand. There too is the support manager, who can do everything and a bit more. The third line — these are the developers; tickets like 'please fix this in the interface' or 'the parameter is counted incorrectly here' go to them.

Reduce the number of requests

Selgelt tõenäoliselt, kui soovid pakkuda tuge odavalt, ei saa sa esmaste kõneliinide arvu suurendada, et inimesed skriptidega kiiremini toime tuleksid, vaid pead suurendama automatiseerimist. Et inimeste asemel, kes skripte kasutavad, oleksid tõelised skriptid. Seetõttu automatiseerisime esimesena protsessid virtuaalmasina käivitamiseks, ressursside järgi skaleerimiseks (sealhulgas ketta suurendamiseks ja vähendamiseks, kuid mitte protsessori sageduse osas) ja muude sarnaste toimingute jaoks. Mida rohkem saab kasutaja oma liidese kaudu teha, seda lihtsam on esimesel kõneliinil ning seda vähem inimesi on vaja. Kui kasutaja pöördub millegi poole, mis on tema kasutajakontol olemas, peab olema võimalus näidata ja seletada, kuidas seda iseseisvalt teha.

Kui sul ei ole tuge vaja, siis tähendab see, et nad saavad hakkama.

Teine aspekt, mis säästab aega, on ulatuslik teadmusbaasi täitmine. Kui kasutajal on probleem, mis ei kuulu toetatavate tegevuste loendisse (enamasti filosoofilised küsimused nagu «kuidas paigaldada Minecrafti server» või «Kus Windows Serveris seadistada VPS»), kirjutatakse teadmusbaasi artikkel. Samuti koostatakse põhjalik artikkel kõigi kummaliste päringute kohta. Näiteks, kui kasutaja küsib tuge Windows Serveri sisseehitatud tulemüüri eemaldamiseks, saadame me lugema, mis juhtub, kui see tõeliselt keelata, ja kuidas lubada ainult valitud tarkvara jaoks õigusi. Sest probleem on tavaliselt selles, et midagi ei saa seada tänu seadistustele, mitte tulemüüri enda tõttu. Kuid selle selgitamine igas vestluses on väga keeruline. Ja tulemüüri keelamine ei räägi, sest üsna varsti võime kaotada kas virtuaalmasina või kliendi.

Kui mingisugune rakendustarkvara teadmusbaasis muutub väga külastatavaks, saab ärimudeleid turule tuua, et luua teenus «alusta serverit juba installitud selle programmiga». Nii juhtus ka Dockeriga ja nii juhtus ka Minecrafti serveriga. Jälle üks nupp «tehke mulle hästi» liideses säästab kuni sada piletit aastas.

Hädaolukord

Pärast neid toiminguid jääb kõige tõsisemaid rikkeid, mis vajavad käsitsi sekkumist, seoses sellega, et kasutaja on mingil põhjusel kaotanud kaugjuurdepääsu külg-OS-le hüperviisis. Kõige sagedasem juhtum on banaalne vale tulemüüri seadistus, teine sageduselt on mingid vead, mis takistavad Windowsil korralikult käivitumist ja sunnivad ta vähemalt turvarežiimi taaskäivitama. Ja turvarežiimis on RDP vaikimisi kättesaamatud.

Oleme sel juhul loonud hädaabirežiimi. Üldiselt on VDS-masinale ligipääsuks vajalik mingi kaugjoondamisrakendus. Enamasti on tegemist konsooli ligipääsuga, RDP, VNC või millegi sarnasega. Nende meetodite puuduseks on see, et nad ei tööta ilma operatsioonisüsteemita. Kuid meie hüperviisi tasemel saame me saada ekraanipilti ja edastada sinna klaviatuuri vajutusi! Tõsi, see koormab protsessorit kõvasti (tänu videote ülekandele), kuid võimaldab saavutada soovitud tulemuse.

Seetõttu andsime hädaabirežiimile juurdepääsu kõigile kasutajatele, kuid see on piiratud pideva kasutamise kestusega. Õnneks näitab praktika, et see aeg on täiesti piisav taaskäivitamiseks ja vajadusel muudatuste tegemiseks.

Tulemus – veelgi vähem toetuse piletitest. Ja seal, kus administraator saab piletis ise parandada, pole toele vaja sekkuda ja asju korda ajada.

Jäänud probleemid

Väga tihti arvavad kasutajad, et tugi püüab neile midagi müüa. Kahjuks ei saa selle vastu midagi teha (noh, või me ei ole leidnud lahendust). Kaks kõige sagedasemat näidet on ressursside piirangud ja DDoS-kaitse.

Igal virtuaalsel masinal on piirangud ketta, mälu ja lubatud liikluse koormuse osas. Piirangute kehtestamise võimalus on kirjas pakkumises, kuid piirangud ise on seatud nii, et suurem osa kasutajatest saaks rahulikult töötada, isegi teadmata neist. Kuid kui te äkki hakkate kanalit ja ketast väga tugevalt raputama, siis algoritmid teavitavad automaatselt kasutajat. Eelmise aasta aprillist oleme eemaldanud automaatblokeeringud. Selle asemel - pehmete piirangute seadmine muutuvale perioodile.

Kunagi oli nii: hoiatus, seejärel, kui kasutaja ei kuulnud, - automaatne blokeerimine. Sel hetkel olid inimesed pahased: "Kuidas nii, teie süsteem ju puterdab, midagi ei olnud!" - ja siis saab valida kas püüda arusaada rakendustarkvarast või pakkuda kõrgemat paketti. Meil pole võimalust süveneda rakendustarkvara toimimisse, sest see jääb toe piiridest välja. Kuigi esimesed paar juhtumit käsitlesime koos kasutajatega. Erakordselt meelde jäi see, kus YouTube'i vaatamiste suurendaja oli varustatud troojaniga, ja selle troojani mälu jooksis. Lõpuks jõudsime järeldusele, et need ei olnud geenisemäged, vaid probleemid kasutajates, vastasel juhul oleks meid üle ujutatud sarnaste kaebustega. Kuid keegi ei ole veel välja tunnistanud, et ta oleks ise tariife ületanud.

Sarnane lugu - DDoS-i osas: me kirjutame, et olete, auväärt kasutaja, rünnaku all. Palun aktiveerige kaitse. Ja kasutaja: "Teie ju ründate mind ise!" Loomulikult me ei ründa ühtegi kasutajat DDoS-iga, et temalt 300 rubla välja petta. See on ju tasuv tegevus. Jah, ma tean, et paljud suured hostimisteenused, mis on kallimad, sisaldavad seda kaitset oma pakettides, kuid me ei saa nii teha: kiirtoidu majandus diktseerib teisi madalaid hindu.

Vähemalt sama sageli on rahulolematud ka toetuse saajad, kelle andmeid oleme kustutanud. Selle mõte on see, et me kustutasime õiguspäraselt pärast makstud perioodi lõppu. Kui keegi ei pikenda VDS-i rendilepingut, siis saadab me mitu teavitust koos selgitustega, mis edasi saab. Maksmise lõppemise hetkel peatub virtuaalmasin, kuid selle pilt säilib. Saadab veel ühe teavituse, ja seejärel veel paar. Pilt hoitakse veel seitsme päeva jooksul ja alles siis kustutatakse täielikult. On olemas inimesed, kes on selle üle väga nördinud. Alustades "administreerija lahkus, tema meilile saadeti teavitusi, taastage" ja lõpetades süüdistustega pettuses ja füüsilise rünnaku ähvardustega. Põhjus - need samad hinnad kõigile teistele kasutajatele. Kui hoiame kuus, siis on vaja rohkem salvestust. See tähendaks suuremaid kulusid iga konkreetse kliendi jaoks. Ja kiirtoidu ökonoomika... Jah, te mõistate. Ja tulemusena saame foorumites tagasisidet stiilis "võtsite raha, kustutasite andmed, petised."

Toon, et meil on premium-plaanide rida. Seal on muidugi olukord teine, kuna me arvestame kliendi soovidega ja seame paindlikult nii limiidi kui ka kustutamise tehingu ebaõnnestumise korral (viime selle miinusesse, et mitte blokeerida). Seal on see juba majanduslikult mõistlik, sest tõepoolest juhtub igasuguseid asju ja pideva suure kliendi säilitamine on kallis.

Mõnikord on kasutajad pahatahtlikud. Mitu korda on meie süsteemis olnud tõrkeid, kus sadu virtuaalseid masinate blokeerimisi said alguse kõige silmatorkavatest klientide ebaseaduslikest tegevustest. Just nende olukordade tõttu vajasime oma võrgudraivereid, et jälgida võrguaktiivsust ja näha, et kasutaja ei ründa oma serverilt. Sellise jälgimise tegemine on oluline, et naabervirtuaalmasinate piire ei rikuks ulakad tüübid.

On neid, kes lihtsalt spämmivad, kaevandavad või rikuvad õiguslikke nõudeid. Siis saadavad nad toele ja küsivad, mis läks valesti ja miks masin on blokeeritud. Kui piletis on protsessi nimi "spamisaaja.exe", siis ilmselt midagi on valesti. Veel umbes iga kahe nädala tagant saame kaebusi Sony või Lucasfilmi (nüüd Disney) ettevõtetelt, et keegi meie virtuaalmasinast meie IP-aadresside vahemikus jagab piraatfilmi. Sellise asja korral toimub kohene blokeerimine ja tagasimakse, mis jääb kontole (meie jaoks on kvantimine sekundite kaupa, seega jääk on alati täpselt olemas). Ja seaduse kohaselt, et raha tagasi saada, on vaja esitada pass: see on meetmed rahapesu vastu. Piraadid kirjutavad kuidagi, et me võtame neilt raha ära, unustades selgitada osa asjaoludest.

Ah, jah. Meie aasta parim päring on selline: "Kas on võimalik mitu päeva testida virtuaalmasinat plaanis 30 rubla kuus enne ostmist?".

Kokkuvõte

Esimene tase sorteerib piletid ja vastab tüüpilistele toimingutele. Peaaegu kõik rahulolematuse juhtumid toimuvad just siin. Seda ei õnnestu parandada, kuna vea parandamise aluseks on hostimise automatiseerimine, see tähendab suur tagasitõmbumine. Jah, meil on rohkem, kui paljudel teistel turul, kuid siiski ei piisa. Seetõttu on parim, mida teha, esimesel tasemel jälgimise kehtestamine. Toetusteenuse jälgimine - esimesel tasemel KPI täitmine. Reaasajas on nähtavad SLA viivitused: kes eksib, tihti - miks. Tänu sellistele häiretele ei lähe taotlused kunagi kaduma. Jah, piletile võib vastata ebaolulise malliga, kuid seda teame ainult tagasiside põhjal.

Kui klient väga palub, saab teise taseme spetsialist siseneda serverisse ja teha seal, mida klient vajab (tingimus on, et neid teavitatakse kinnituskirjaga, kus ta edastab sisselogimise andmed).

Me teeme seda väga harva ja usaldame sellist tööd vaid parimatele, sest tahame olla kindlad, et kasutajaandmed ei kahjustu. Parimad on teise taseme tugi.

Esimese taseme kätel on teadmiste baas, kuhu saab suunata keerukamaid küsimusi.

Funktsiooniderohke isiklik konto pluss teadmiste baas on aidanud meil vähendada pöördumiste arvu keskmiselt 1–1,5 korda aastas kliendi kohta.

Teine tase töötab tavaliselt keerukate taotlustega, mis nõuavad käsitsi tööd. Iseloomulik on: mida kallim on pakett, seda vähem on selliseid taotlusi virtuaalmasina kohta. Tavaliselt seetõttu, et kallist paketti endale lubavad inimesed kas on spetsialistid oma töötajate seas või lihtsalt pool probleemidest ei tõuse, kuna konfiguratsioonid on kõikidele piisavad. Ma mäletan endiselt seda kangelast, kes paigaldas mitte kõige vanema Windows Serveri masinasse, kus oli 256 megabaiti RAM-i.

Teisel tasemel on komplekt distributsioone ja komplekt automatiseerimise skripte. Mõlemat saab vajadusel ajakohastada.

Teisel tasemel ja VIP-plaani isiklikud juhid oskavad lisada märke kliendi profiilile. Kui ta on Linuxi administraator, siis paneme nii kirja. See on esimese taseme jaoks vihje: kasutaja teab täpselt, et see ei ole jalga tulistamine, vaid kontrollitud hävitamine.

Kolmas rida valitseb kõige kummalisemat. Näiteks oli meil probleem, et ühte funktsiooni isiklikus kabinetis ei saanud avada Firefoxis. Kasutaja ähvardas otse: „Kui te ei paranda 12 tunni jooksul, siis kirjutan kõikidesse hostinguülevaadetesse.” Selgus, et probleem oli külastaja isiklikus reklaamiblokeerijas. Kuidas iganes see ka ei tundu. Sageli tulevad keerulised vead ilma detailideta ja neid ei saa uuesti korrata. On ka detektiive koos ekraanipildiga: „Kuidas te seda kuu aega parandate?” - „Jah, me otsime kogu selle aja teie viga lihtsalt.”, „Aga, noh, see juhtus mul taas täna, aga ma ei suutnud jällegi korrata…

Tegelikult ei tea te kunagi, kus see vestluse ekraanipilt tugiteenusega ilmub, ja kui inimene kirjutab tugiteenusesse, siis tal on probleem. Suhtlemist saab parandada. Vähemalt proovige.

Jah, me teame, et meie tugi ei ole ideaalne, kuid nagu ma loodan, ühendab see piisava kiirusen piisava kvaliteedi. Ja see ei tõsta hindu neile, kes saavad ilma hakkama.

Allikas: habr.com