Halló, Habr! Ég hef stutt Highload upplýsingatæknikerfi í tíu ár. Ég mun ekki skrifa í þessari grein um vandamálin við að setja upp nginx til að virka í 1000+ RPS ham eða öðrum tæknilegum hlutum. Ég mun deila athugasemdum mínum um vandamálin í þeim ferlum sem koma upp við stuðning og rekstur slíkra kerfa.
Eftirlit
Tæknileg aðstoð bíður ekki þar til beiðni berst með innihaldinu „Hvað af hverju... síðan virkar ekki aftur?“ Innan mínútu eftir að vefsvæðið hrundi ætti stuðningur nú þegar að sjá vandamálið og byrja að leysa það. En síðan er toppurinn á ísjakanum. Aðgengi þess er eitt það fyrsta sem fylgst er með.
Hvað á að gera við ástandið þegar vörur sem eftir eru af netverslun koma ekki lengur frá ERP kerfinu? Eða hefur CRM kerfið sem reiknar út afslátt fyrir viðskiptavini hætt að svara? Síðan virðist vera að virka. Skilyrt Zabbix fær 200 svar sitt. Vaktvaktin hefur ekki fengið neinar tilkynningar frá eftirlitinu og horfir glöð á fyrsta þátt nýrrar þáttar Game of Thrones.
Vöktun er oft takmörkuð við aðeins að mæla stöðu minnis, vinnsluminni og álags á miðlara. En fyrir fyrirtæki er miklu mikilvægara að fá vöruframboð á vefsíðunni. Skilyrt bilun á einni sýndarvél í þyrpingunni mun leiða til þess að umferð hættir að fara á hana og álag á aðra netþjóna eykst. Félagið mun ekki tapa peningum.
Þess vegna, auk þess að fylgjast með tæknilegum breytum stýrikerfa á netþjónum, þarftu að stilla viðskiptamælingar. Mælingar sem hafa bein áhrif á peninga. Ýmis samskipti við ytri kerfi (CRM, ERP og fleiri). Fjöldi pantana fyrir ákveðinn tíma. Vel heppnaðar eða misheppnaðar heimildir viðskiptavina og aðrar mælikvarðar.
Samskipti við ytri kerfi
Sérhver vefsíða eða farsímaforrit með ársveltu meira en milljarð rúblur hefur samskipti við ytri kerfi. Byrjað er á ofangreindu CRM og ERP og endar með flutningi sölugagna yfir í ytra Big Data kerfi til að greina innkaup og bjóða viðskiptavinum vöru sem hann mun örugglega kaupa (í raun ekki). Hvert slíkt kerfi hefur sinn stuðning. Og oft valda samskipti við þessi kerfi sársauka. Sérstaklega þegar vandamálið er alþjóðlegt og þú þarft að greina það í mismunandi kerfum.
Sum kerfi gefa upp símanúmer eða símskeyti fyrir stjórnendur þeirra. Einhvers staðar þarf að skrifa bréf til stjórnenda eða fara í villuleitartæki þessara ytri kerfa. Jafnvel innan samhengis eins stórs fyrirtækis starfa mismunandi kerfi oft í mismunandi forritabókhaldskerfum. Stundum verður ómögulegt að fylgjast með stöðu umsóknar. Þú færð beiðni í einu skilyrtu Jira. Síðan í athugasemd þessa fyrsta Jira seturðu tengil á málið í öðru Jira. Í annarri Jira í umsókninni er einhver þegar að skrifa athugasemd um það þú þarft að hringja í skilyrtan stjórnanda Andrey til að leysa málið. Og svo framvegis.
Besta lausnin á þessu vandamáli væri að búa til eitt rými fyrir samskipti, til dæmis í Slack. Að bjóða öllum þátttakendum í rekstri ytri kerfa að vera með. Og líka einn rekja spor einhvers til að afrita ekki forrit. Fylgjast ætti með forritum á einum stað, allt frá því að fylgjast með tilkynningum til úttaks villulausna í framtíðinni. Þú munt segja að þetta sé óraunhæft og það hefur gerst í gegnum tíðina að við vinnum í einum rekjavél og þeir virka í öðrum. Mismunandi kerfi birtust, þau höfðu sín eigin sjálfstæða upplýsingatækniteymi. Ég er sammála og því þarf að leysa vandamálið að ofan á CIO eða vörueigandastigi.
Sérhvert kerfi sem þú hefur samskipti við ætti að veita stuðning sem þjónustu með skýrum SLA til að leysa mál eftir forgangi. Og ekki þegar skilyrti stjórnandinn Andrey hefur mínútu fyrir þig.
Flöskuháls maður
Eru allir í verkefni (eða vöru) með manneskju sem fer í frí veldur krampa hjá yfirmönnum sínum? Þetta gæti verið devops verkfræðingur, sérfræðingur eða verktaki. Þegar öllu er á botninn hvolft veit aðeins devops verkfræðingur hvaða netþjónar eru með hvaða gáma uppsettir, hvernig á að endurræsa gáminn ef vandamál koma upp og almennt er ekki hægt að leysa öll flókin vandamál án hans. Sérfræðingurinn er sá eini sem veit hvernig flókið vélbúnaður þinn virkar. Hvaða gagnastraumar fara hvert. Undir hvaða breytum beiðna við hvaða þjónustu, hverjar munum við fá svör.
Hver mun fljótt skilja hvers vegna það eru villur í annálunum og laga mikilvæga villu í vörunni tafarlaust? Auðvitað sami verktaki. Það eru aðrir, en af einhverjum ástæðum skilur aðeins hann hvernig mismunandi einingar kerfisins virka.
Rót þessa vandamáls er skortur á skjölum. Eftir allt saman, ef allri þjónustu kerfisins þíns væri lýst, þá væri hægt að takast á við vandamálið án sérfræðings. Ef devops tók nokkra daga úr annasamri dagskrá sinni og lýsti öllum netþjónum, þjónustu og leiðbeiningum til að leysa dæmigerð vandamál, þá væri hægt að leysa vandamálið í fjarveru hans án hans. Þú þarft ekki að klára bjórinn þinn fljótt á ströndinni á meðan þú ert í fríi og leita að Wi-Fi til að leysa vandamálið.
Hæfni og ábyrgð stuðningsfulltrúa
Í stórum verkefnum spara fyrirtæki ekki laun framkvæmdaaðila. Þeir eru að leita að dýrum miðjum eða eldri úr svipuðum verkefnum. Með stuðningi er ástandið aðeins öðruvísi. Þeir eru að reyna að draga úr þessum kostnaði á allan mögulegan hátt. Fyrirtæki ráða ódýra Enikey starfsmenn gærdagsins og fara djarflega í bardaga. Þessi stefna er möguleg ef við erum að tala um nafnspjaldasíðu álversins í Zelenograd.
Ef við erum að tala um stóra netverslun þá kostar hver klukkutími af niður í miðbæ meira en mánaðarlaun Enikey stjórnanda. Við skulum taka 1 milljarð rúblur af ársveltu sem útgangspunkt. Þetta er lágmarksvelta sérhverrar netverslunar frá einkunninni . Deildu þessari upphæð með fjölda klukkustunda á ári og fáðu meira en 100 rúblur af hreinu tapi. Og ef þú telur ekki næturtímana geturðu örugglega tvöfaldað magnið.
En peningar eru ekki aðalatriðið, ekki satt? (nei, auðvitað aðalatriðið) Það er líka mannorðstap. Fall þekktrar netverslunar getur valdið bæði öldu umsagna á samfélagsmiðlum og útgáfu í þemamiðlum. Og samtöl vina í eldhúsinu í stíl við „Ekki kaupa neitt þar, vefsíðan þeirra er alltaf niðri“ er alls ekki hægt að mæla.
Nú að ábyrgð. Í starfi mínu kom upp tilvik þegar vakthafandi stjórnandi svaraði ekki í tæka tíð við tilkynningu frá eftirlitskerfinu um að síðuna væri ekki tiltæk. Á ánægjulegu sumarföstudagskvöldi lá heimasíða þekktrar netverslunar í Moskvu hljóðlega. Á laugardagsmorgun skildi vörustjóri þessarar síðu ekki hvers vegna síðan var ekki opnuð og það var þögn í stuðnings- og brýnum tilkynningaspjallum í Slack. Slík mistök kostuðu okkur sex stafa upphæð og þennan varðstjóra starf sitt.
Ábyrgð er erfið færni til að þróa. Annað hvort hefur maður það eða ekki. Þess vegna reyni ég í viðtölum að greina nærveru þess með ýmsum spurningum sem sýna óbeint hvort maður sé vanur að axla ábyrgð. Ef einstaklingur svarar því að hann hafi valið háskóla vegna þess að foreldrar hans sögðu það eða skipti um vinnu vegna þess að konan hans sagði að hann þénaði ekki nóg, þá er betra að blanda sér ekki í slíkt fólk.
Samskipti við þróunarteymið
Þegar notendur lenda í einföldum vandamálum með vöru meðan á notkun stendur leysir stuðningur þau á eigin spýtur. Reynir að endurskapa vandamálið, greinir logs og svo framvegis. En hvað á að gera þegar galli birtist í vörunni? Í þessu tilviki úthlutar stuðningur verkefninu til þróunaraðila og það er þar sem gamanið byrjar.
Hönnuðir eru stöðugt ofhlaðnir. Þeir eru að búa til nýja eiginleika. Að laga villur með sölu er ekki áhugaverðasta verkefnið. Frestir nálgast til að klára næsta sprett. Og svo kemur óþægilegt fólk frá stuðningi og segir: „Hættu öllu strax, við eigum í vandræðum. Forgangur slíkra verkefna er í lágmarki. Sérstaklega þegar vandamálið er ekki það mikilvægasta og aðalvirkni síðunnar virkar, og þegar útgáfustjórinn hleypur ekki um með bólgandi augu og skrifar: „Bættu þessu verkefni bráðlega við næstu útgáfu eða flýtileiðréttingu.
Mál með eðlilegan eða lágan forgang eru færð frá útgáfu til útgáfu. Við spurningunni "Hvenær verður verkefninu lokið?" þú munt fá svör í stíl við: "Því miður, það eru mörg verkefni núna, spurðu liðsstjórana þína eða útgáfustjóra."
Framleiðnivandamál hafa meiri forgang en að búa til nýja eiginleika. Slæmar umsagnir munu ekki vera lengi að koma ef notendur rekast stöðugt á villur. Skemmt orðspor er erfitt að endurheimta.
Vandamál um samspil þróunar og stuðnings eru leyst af DevOps. Þessi skammstöfun er oft notuð í formi ákveðins einstaklings sem hjálpar til við að búa til prófunarumhverfi til þróunar, smíðar CICD leiðslur og kemur fljótt með prófaðan kóða í framleiðslu. DevOps er nálgun við hugbúnaðarþróun þegar allir þátttakendur í ferlinu hafa náin samskipti sín á milli og hjálpa til við að búa til og uppfæra hugbúnaðarvörur og þjónustu á fljótlegan hátt. Ég meina greiningaraðila, þróunaraðila, prófunaraðila og stuðning.
Í þessari nálgun eru stuðningur og þróun ekki ólíkar deildir með sín eigin markmið og markmið. Þróun fylgir rekstri og öfugt. Hin fræga setning um dreifða teymi: „Vandamálið er ekki hjá mér“ birtist ekki lengur í spjalli svo oft og endanotendur verða aðeins ánægðari.
Heimild: www.habr.com