Hädaolukord (tuntud ka kui IPKVM) võimaldab ühendada VPS-i RDP-st otse hüperviisori tasemel, säästes 15–20 minutit nädalas.
Esiteks ja kõige olulisem – ära tüütama inimesi. Mitte kusagil maailmas ei jagune tugi liinide vahel, ning esimese tasandi töötaja peab proovima tavalisi lahendusi. Kui ülesanne ületab nende piirid – edastada teisele tasandile. Noh, VDS administraatorite seas juhtub sageli inimesi, kes oskavad mõelda. Erinevalt paljusid teisi tugiteenuseid. Noh, vähemalt oluliselt sagedamini. Ja nad struktureerivad pileti hästi, kirjeldades kohe kõike vajalikku. Kui esimesel tasandil „silmi hägustub” ja nad juhuslikult paluvad sellise peale lülitada sisse ja välja – see on fiasko.
Ülesanne on väga lihtne: muuta meie VDS-hostingu tugi adekvaatseks minimaalsete kuludega. Sest me oleme hostimisteenuste maailma kiirtoit: ei mingit erilist „lihvimist”, madalad hinnad, normaalne kvaliteet. Juba on juttu sellest, kuidas Instagrami toredad inimesed, kes püüavad konto haldamist automatiseerida, ja väikeste ettevõtete omanikud koos kaugraamatupidajatega, ei olnud enam tehnoloogiliselt piisavalt arenenud, et suhtlemine "adminilt adminile" enam toimiks. Oli vaja suhtlemiskeelt muuta.
Nüüd räägin protsessidest natuke rohkem – ja vältimatutest vigadest nendega seoses.
Ära tüüta inimesi № 1
Iga tugi on konveieritootmine. Saade tuleb, esmaklassiline töötaja püüab kohe tuvastada tüüpilise olukorra, mis on juhtunud tuhat korda ja juhtub veel tuhat korda. On 90% tõenäosus, et teade on tüüpiline, ja sellele saab vastata vaid paar nuppu vajutades, et mall oleks õigesti sisestatud. Malli tuleb tavaliselt täita paar sõna – ja ongi valmis. Või minna juhtimisliidesesse ja vajutada seal paar nuppu. Enamasti keerukates olukordades (nt kaustade ülekandmine) tuleb järgida algoritmi toimingute sooritamiseks.
Inimesi häirib kõige rohkem see, et tugiteenuse tüüpiline reaktsioon ebatavalisetele piletitele on sama. Tuleb pilet, kus on kõik detailselt kirjas, on hunnik vajalikku teavet kolmel küsimusele ette antud, klient ootab dialooge… Ja esimestest sõnadest alates hakkab tugiteenuse töötaja autopiloodil kirjutama mallakorraldust "proovige taaskäivitada, see peaks aitama".
See ajab inimesi tõeliselt marru, ja just pärast selliseid olukordi jääb enamasti kõige rohkem negatiivseid kommentaare ja ärritavaid tähelepanekuid. On selge, et me oleme selliste vigade tõttu langenud, sealt ka teame statistikat. Oleme eksinud mitmeti, kuid sellised juhtumid on alati äärmiselt kergelt mõistetavad. Sealhulgas ka meie enda jaoks. Loomulikult sooviksime, et seda ei juhtuks üldse. Kuid see ei ole praktikas eriti võimalik: iga paar nädalat väsinud liigaotses töötaja võib juganaelake tegema.
Ärritab inimesi number 2
Teine asjaolu, mis sama hästi avab aju, on see, kui piletile ei vastata piisavalt kaua. Euroopas on selline tugikäitumine normaalne: kolme päeva jooksul enne juhtumi käsitlema asumist on täiesti tavaline. Isegi kui sul on väga kiire ja midagi on tulekahju – ei mingit sotsiaalmeediat, telefoni ega sõnumitoojaid, ainult e-kiri ja oota oma järjekorda. Venemaal on see palju vähem levinud, kuid siiski mõningaid pileteid "unustatakse". Juba töö alguses kehtestasime SLA esialgse reaktsiooni ajaks 15 minutit. Ja see on kogu ööpäeva/öösiti ja ausalt. Loomulikult, kui VDS-hosting muutub suureks, siis see tekib. Kuid kahtlaste teenusepakkujate seas seda ei ole. Ja me alustasime just kahtlase teenusena ja ainult hiljem muutusime enam-vähem suurteks. Olgu, enam-vähem keskmiseks.
Esimene joon on operaatorid, kellele on antud skriptid ja õpetatud reageerima tüüpilistele olukordadele. Nad sorteerivad probleeme kiiresti ja püüavad 15 minuti jooksul kas vastata tüüpilise tegevusega või teavitada, et pilet on töös ja edastada see teisele.
Teine tase — juba hosting'u administraatorid, kes oskavad peaaegu kõike käsitsi teha. Seal on ka tugijuht, kes oskab kõike ja veel natuke rohkem. Kolmas tase — juba arendajad, kelle juurde jõuavad pääsmed nagu „palun parandage see liideses” või „sellist parameetrit arvestatakse valesti seal”.
Vähendada piletite arvu
Mõistetavatel põhjustel, kui soovite pakkuda tuge odavalt, siis ei ole mõtet esimest taset suurendada, et inimesed skriptidega kiiremini hakkama saaksid, vaid tuleb suurendada automatiseerimist. Et inimeste asemel skriptide abil saaks kõik tehtud. Seetõttu automatiseerisime ühe esimesena protsesse nagu virtuaalmasina tõstmine, ressursi skaleerimine (sealhulgas ketta üles- ja allapoole skaleerimine, kuid mitte protsessori sageduse osas) ja muud sarnased asjad. Mida rohkem saab kasutaja hallata oma isiklikus kontoris, seda lihtsam on esimesel tasandil ja seda väiksem peab see olema. Kui kasutaja küsib midagi, mis on isiklikus kontoris olemas, siis tuleb tutvustada, kuidas seda ise teha.
Kui sul ei ole tuge vaja, siis see tähendab, et nad teevad oma tööd hästi.
Teine omadus, mis säästab palju aega, on pikaajaline teadmistebaasi täiendamine. Kui kasutajal on probleem, mis ei kuulu toetatavate toimingute loetellu (kõige sagedamini küsimused nagu "kuidas seadistada Minecrafti serverit" või "kuidas Windows Serveris VPS-i seadistada"), kirjutatakse teadmistebaasi artikkel. Samuti kirjutatakse samasugune põhjalik artikkel kõikide kummaliste päringute korral. Näiteks, kui kasutaja küsib, kuidas Windows Serveri sisseehitatud tulemüür eemaldada, saadame lugema, mis juhtub, kui see tõesti välja lülitatakse, ja kuidas avada lubatud juurdepääs ainult valitud tarkvarale. Probleem peitub tavaliselt selles, et midagi ei saa ühendust seadistuste tõttu, mitte tulemüüri enda tõttu. Kuid seda iga kord dialooge selgitada on väga keeruline. Ja tulemüüri väljalülitamine ei tundu just õige, kuna varsti võime kas kaotada virtuaalmasina või kliendi.
Kui mõni rakendusprogramm teave teadmistebaasis muutub väga populaarseks, on võimalik toodet turule tuua, et ilmuks teenus "seadke server üles juba selle eelnevalt installitud versiooniga". Just nii on juhtunud Dockeriga ja nii on juhtunud ka Minecrafti serveriga. Üks nupp "tehke mulle head" liideses säästab kuni sada piletit aastas.
Hädaolukord
Pärast neid toiminguid jääb kõige rohkem tõsiseid rikkeid, mis vajavad käsitsi sekkumist, olukordadesse, kus kasutaja on mingil põhjusel kaotanud kaugjuhtimise vahendi hüperviisori külaliste operatsioonisüsteemi. Kõige sagedasem juhtum on lihtsalt vale tulemüüriseade, teine sageduselt on probleemid, mis takistavad Windowsi normaalselt käivitumist ja sunnivad taaskäivituma Safe Mode'is. Ja Safe Mode'is on RDP vaikimisi mittekasutatav.
Oleme selle jaoks loonud hädaolukorra režiimi. Üldiselt peab VDS-masinale ligipääsemiseks olema mingi kaugjuhtimise klient. Kõige sagedamini on juttu konsooli ligipääsust, RDP-st, VNC-st või midagi sarnast. Nende meetodite puuduseks on see, et nad ei tööta ilma opsüsteemita. Ent meie hüperviisori tasemel saame me kätte nii ekraanipildi kui ka edastada klaviatuuri sisestusi! Tõsi, see koormab protsessorit kõvasti (tänu tegelikule videotelevioonile), kuid võimaldab saavutada soovitud tulemuse.
Seetõttu andsime kõigile kasutajatele juurdepääsu hädaolukorra režiimile, kuid see on piiratud pideva kasutusajaga. Õnneks näitab praktika, et see aeg on täiesti piisav, et taaskäivitada ja midagi parandada.
Tulemus — veel vähem toetustikettepanekuid. Ja seal, kus admin saab ise piletis probleemi lahendada, ei pea toetus enam vahele minema ja sekkuma.
Jäänud probleemid
Kasutajad arvavad tihti, et toetus müüb neile midagi. Sellega, kahjuks, ei saa midagi teha (või me ei ole välja mõelnud). Kaks kõige sagedasemat näidet on ressursipiirangud ja DDoS-kaitse.
Igal virtuaalmasinal on piirangud, mis puudutavad ketta, mälu ja lubatud liikluse koormust. Piirangute kehtestamise võimalus on toodud pakkumises, samas valitakse piirangud nii, et enamik kasutajatest saaks rahulikult töötada, teadmata nendest. Kuid kui te hakkate kanalit ja ketast intensiivselt kasutama, siis hoiavad algoritmid automaatselt kasutajat sellest teadlikuks. Eelmisel aprillil kaotasime automaatblokeeringud. Selle asemel kehtestame pehmeid piirmäärasid ajutiselt.
Varem oli nii: hoiatamine, seejärel, kui kasutaja ei olnud tähelepanelik, automaatne blokeerimine. Ja sel hetkel inimesed pahandasid: „Mis te teete, see teie süsteem on katki, midagi ei olnud!” — ja edasi oli võimalik kas proovida rakendusprogrammi läbi mõelda või pakkuda kõrgemat hinnaplaani. Meil ei ole võimalust rakenduskomplekti töö sisse süüvida, sest see jääb toetuse rikkausse. Kuigi esimesed paar juhtumit arutasime koos kasutajatega. Eriti meelde jäi see, kus Youtubes oli vaatamiste suurendaja, mille sees oli troojan ja selle troojani mälu voolas. Lõpuks jõudsime järeldusele, et need ei ole geizenbugid, vaid kasutajate probleemid, vastasel juhul oleksime saanud sarnaseid taotlusi üle. Kuid ükski inimene ei ole veel tunnistanud, et ta oleks ise hindu ületanud.
Sarnane lugu DDoS-idega: me ütleme, et te, auväärne kasutaja, olete rünnaku all. Palun aktiveerige kaitse. Ja kasutaja vastab: „Küll te mind ise ründate!” Loomulikult ründame me ühe kasutaja, et temalt 300 rubla välja pressida. Tõeliselt kasulik äri. Jah, ma tean, et paljud suured hostimisteenused, mille hinnad on kõrgemad, sisaldavad selle kaitse oma plaani, kuid meie ei saa seda teha: kiirtoidu majandus dikteerib teised miinimumhinnad.
Samuti on tihti rahulolematud need, kelle andmed me eemaldasime. See, et on tõeliselt seaduslik, et eemaldatakse pärast tasutud perioodi lõppu. Kui keegi ei pikenda VDS-i renti, saadetakse mitu teavitust koos selgitustega, mis edasi saab. Maksetähtaja saabumise hetkel peatatakse virtuaalmasin, kuid selle pilt salvestatakse. Saadetakse veel üks teavitus, seejärel mõned lisad. Pilt säilitatakse veel seitse päeva ja alles siis kustutatakse see igaveseks. On inimesi, kes on sellega väga rahulolematud. Alates "admin ei tööta enam, tema postkasti tulid teavitused, taastage" ja lõpetades süüdistustega petmises ning füüsilise vägivalla ähvardustega. Põhjuseks on endiselt samad hinnad kõigi teiste kasutajate jaoks. Kui hoiame seda kuu aega, vajame rohkem salvestusruumi. See tähendaks kõrgemaid hindasid iga konkreetse kliendi jaoks. Ja kiirtoidu majandus... No, te saite aru. Tulemusena saame foorumitest tagasisidet stiilis "võtsid raha, kustutasid andmed, petjad."
Tähtsustaksin, et meil on olemas premium-tariifide valik. Seal on muidugi olukord teistsugune, kuna me arvestame kliendi soovidega ning kohandame paindlikult nii limiiti kui ka eemaldamist maksmata jätmise korral (viime selle miinusesse, et mitte blokeerida). Seal see on juba majanduslikult mõistlik, kuna juhtub tõeliselt igasuguseid asju, ja püsikliendi säilitamine on kulukas.
Mõnikord on kasutajad pahatahtlikud. Korduvalt on meie süsteemis esinenud tõrkeid, kui sadu virtuaalmasinaid on blokeeritud mingi ilmselgelt ebaseadusliku tegevuse tõttu klientide poolt. Just nende olukordade tõttu vajasime omaenda võrgu draivereid, et jälgida võrguaktiivsust ja näha, et kasutaja ei ründa oma serverist. Selline jälgimine on oluline, et naabervirtuaalmasinate piire ei rikuks süüdistavad kutid.
On neid, kes lihtsalt spammivad, kaevandavad või rikuvad muul viisil lepingu tingimusi. Siis pöördutakse tuge ja küsitakse, mis valesti läks ja miks masin on blokeeritud. Kui piletis olev protsess kannab nime „spammer.exe”, siis tõenäoliselt on midagi valesti. Umbes iga kahe nädala tagant saame kaebusi ettevõtetelt nagu Sony või Lucasfilm (nüüd Disney), et keegi meie virtuaalmasinast jagab varastatud filme meie IP-aadresside vahemikus. Sellise teo puhul toimub kohene blokeerimine ja jäänud raha tagastamine lepingu tingimuste alusel (tuletan meelde: meie hindamine toimub sekundite kaupa, seega jääk on alati täpselt olemas). Raha tagastamiseks on seaduse kohaselt vajalik passi esitamine: see on omamoodi rahapesu vastane meetmed. Piraadid kirjutavad aga sageli, et me oleme nende raha käest ära võtnud, unustades selgitada teatud asjaolusid.
Ah, jah. Meie parim päring sellel aastal on selline: „Kas saaks mõneks päevaks testida virtuaalmasinat, mille hind on 30 rubla kuus, enne ostmist?”.
Kokkuvõte
Esimene tase filtreerib pileteid ja vastab tüüpilistele toimingutele. Siin on kõige rohkem rahulolematust. Seda ei õnnestu ikkagi parandada, sest parandamise aluseks on hostingu automatiseerimine, see tähendab tohutu tööde nimekiri. Jah, meil on rohkem, kui paljusid teisi turul, kuid sellest ei piisa. Seetõttu on parim, mida teha, esimesel tasemel jälgimise kehtestamine. Tugiteenuse jälgimine - esimesse tasemesse kuuluvate KPIde täitmine. Reaalajas on nähtavad SLA ületamised: kes eksib, sageli - miks. Tänu sellistele alert'idele ei lähe piletid kunagi kaduma. Jah, piletile võib vastata teemaväline malli kasutades, kuid sellest saame teada juba tagasiside põhjal.
Kui klient väga palub, võib teise taseme spetsialist serverisse siseneda ja teha seal vajalikud toimingud (tingimuseks on kinnituskiri, milles ta edastab sisenemise andmed serverisse).
Me teeme seda väga harva ja usaldame selliseid töid vaid parimatele, sest soovime olla kindlad, et kasutajaandmed ei kahjustu. Parimad on teise taseme tugi.
Esimese taseme töötajatel on teadmusbaas, kuhu saab suunata vaatama keerulisi küsimusi.
Funktsiooniderikkas isiklik kabinet koos teadmistebaasiga - oleme suutnud keskmiselt vähendada klientide pöördumiste arvu aastas 1–1,5 peale.
Teine tase töötleb tavaliselt keerulisi taotlusi, mis nõuavad käsitöö. Iseloomulik on, et kallima plaani puhul on selliseid taotlusi vähem virtuaalmasina kohta. Tüüpiliselt seetõttu, et neil, kes saavad endale lubada kallimat plaani, on kas spetsialistid omast käest või lihtsalt pooled probleemid ei ilmne, kuna konfiguratsioonid katab kõik ära. Ma mäletan ikka seda kangelast, kes installis vanema Windows Serveri 256 MB RAM-i konfiguratsioonile.
Teisel tasemel on komplekt jaotusi ja automaatika skripte. Mõlemat saab vajadusel ajakohastada.
Teisel tasemel ja VIP-plaanide isiklikud juhid saavad klientide profiilidesse märkmeid lisada. Kui ta on Linuxi administraator - siis märgimegi ära. See on esimese taseme jaoks vihje: kasutaja teab täpselt, et see ei ole jalaga löömine, vaid kontrollitud hävitamine.
Kolmas tase reguleerib kõige veidramat. Näiteks, meil oli probleem, et ühtegi funktsiooni isiklikus kontoris ei saanud avada Firefoxis. Kasutaja ähvardas otse: "Kui te ei paranda seda 12 tunni jooksul, siis kirjutan kõigile hostingu ülevaadetele." Nagu selgus, oli probleem kasutaja kohandatud reklaamiblokaatoris. Veider, eks? Tihti tulevad keerulised vead ilma detailideta, ja korrata ei suuda enam. On saatjaid, kellel on ekraanipildid: "Miks te seda kuu aega parandate?" — "Me lihtsalt otsime teie viga kogu selle aja," „Ah, jälle tabas mind täna, aga korrata ei saanud jälle..."
Üldiselt ei tea te kunagi, kus kasutaja toe dialooge jäädvustatakse ja kui inimene helistab, siis tal on probleem. Suhtlemist saab parandada. Vähemalt proovida.
Jah, me teame, et meie tugiteenus ei ole ideaalne, kuid ma loodan, et see pakub piisavat kiirusest koos piisava kvaliteediga. Ja see ei tõsta hindu plaanidel neile, kes saavad sellest ilma hakkama.
Allikas: habr.com
