Pozdravljeni, Habr! Že deset let podpiram IT sisteme Highload. V tem članku ne bom pisal o težavah pri nastavljanju nginxa za delo v načinu 1000+ RPS ali drugih tehničnih stvareh. Delil bom svoja opažanja o težavah v procesih, ki se pojavljajo pri podpori in delovanju tovrstnih sistemov.
Spremljanje
Tehnična podpora ne čaka, dokler ne prispe zahtevek z vsebino "Kaj Zakaj ... stran spet ne deluje?" V minuti po tem, ko se spletno mesto zruši, bi morala podpora že videti težavo in jo začeti reševati. Toda spletno mesto je vrh ledene gore. Njegova razpoložljivost je med prvimi, ki jih spremljamo.
Kaj storiti v primeru, ko preostalo blago spletne trgovine ne prispe več iz ERP sistema? Ali pa se je sistem CRM, ki računa popuste za stranke, nehal odzivati? Videti je, da spletno mesto deluje. Pogojni Zabbix prejme odgovor 200. Dežurna izmena ni prejela nobenega obvestila nadzora in veselo spremlja prvo epizodo nove sezone Igre prestolov.
Spremljanje je pogosto omejeno le na merjenje stanja pomnilnika, RAM-a in obremenitve strežniškega procesorja. Toda za podjetja je veliko bolj pomembno, da je izdelek na voljo na spletni strani. Pogojna okvara enega virtualnega stroja v gruči bo privedla do dejstva, da bo promet prenehal iti nanj in obremenitev drugih strežnikov se bo povečala. Podjetje ne bo izgubilo denarja.
Zato morate poleg spremljanja tehničnih parametrov operacijskih sistemov na strežnikih konfigurirati poslovne metrike. Meritve, ki neposredno vplivajo na denar. Različne interakcije z zunanjimi sistemi (CRM, ERP in drugi). Število naročil za določeno časovno obdobje. Uspešne ali neuspešne avtorizacije strank in druge metrike.
Interakcija z zunanjimi sistemi
Vsako spletno mesto ali mobilna aplikacija z letnim prometom več kot milijardo rubljev sodeluje z zunanjimi sistemi. Začenši z zgoraj omenjenima CRM in ERP in konča s prenosom prodajnih podatkov v zunanji sistem Big Data za analizo nakupov in ponuditi stranki izdelek, ki ga bo zagotovo kupil (pravzaprav ne). Vsak tak sistem ima svojo podporo. In pogosto komunikacija s temi sistemi povzroča bolečino. Še posebej, če je problem globalen in ga morate analizirati v različnih sistemih.
Nekateri sistemi nudijo telefonsko številko ali telegram svojim skrbnikom. Nekje morate pisati pisma upraviteljem ali obiskati sledilnike hroščev teh zunanjih sistemov. Tudi v kontekstu enega velikega podjetja različni sistemi pogosto delujejo v različnih aplikacijskih računovodskih sistemih. Včasih postane nemogoče slediti statusu aplikacije. Zahtevo prejmete v enem pogojnem Jira. Nato v komentar tega prvega Jira postavite povezavo do težave v drugem Jiri. V drugem Jira v aplikaciji že nekdo piše komentar, ki za rešitev težave morate poklicati pogojnega skrbnika Andreja. In tako naprej.
Najboljša rešitev tega problema bi bila ustvariti enoten prostor za komunikacijo, na primer v Slacku. Vabilo k včlanitvi vseh udeležencev v procesu delovanja zunanjih sistemov. In tudi en sam sledilnik, da ne bi podvajali aplikacij. Aplikacijam je treba slediti na enem mestu, od spremljanja obvestil do rezultatov rešitev za napake v prihodnosti. Rekli boste, da je to nerealno in zgodovinsko se je dogajalo, da mi delamo v enem sledilniku, oni pa v drugem. Pojavili so se različni sistemi, imeli so svoje avtonomne IT ekipe. Strinjam se, zato je treba problem rešiti od zgoraj na ravni CIO ali lastnika izdelka.
Vsak sistem, s katerim sodelujete, bi moral zagotavljati podporo kot storitev z jasno SLA za reševanje težav po prioriteti. In ne takrat, ko ima pogojni skrbnik Andrey minuto za vas.
Bottleneck Man
Ali ima vsak na projektu (ali izdelku) osebo, katere odhod na dopust povzroči krče med nadrejenimi? To je lahko inženir devops, analitik ali razvijalec. Navsezadnje samo devops inženir ve, kateri strežniki imajo nameščene katere kontejnerje, kako ponovno zagnati kontejner v primeru težave in nasploh nobenega kompleksnega problema ni mogoče rešiti brez njega. Analitik je edini, ki ve, kako deluje vaš zapleten mehanizem. Kateri podatkovni tokovi gredo kam. Pod kakšnimi parametri zahtevkov, na katere storitve, na katere bomo prejeli odgovore.
Kdo bo hitro razumel, zakaj so v dnevnikih napake, in takoj odpravil kritično napako v izdelku? Seveda isti razvijalec. Obstajajo tudi drugi, vendar iz nekega razloga samo on razume, kako delujejo različni moduli sistema.
Osnova tega problema je pomanjkanje dokumentacije. Konec koncev, če bi bile opisane vse storitve vašega sistema, bi se bilo mogoče spoprijeti s težavo brez analitika. Če bi si devops vzel nekaj dni iz svojega natrpanega urnika in opisal vse strežnike, storitve in navodila za reševanje tipičnih problemov, potem bi lahko problem v njegovi odsotnosti rešili tudi brez njega. Ni vam treba hitro popiti piva na plaži med dopustom in iskati wi-fi za rešitev težave.
Usposobljenost in odgovornost pomožnega osebja
Pri velikih projektih podjetja ne varčujejo s plačami razvijalcev. Iščejo drage srednje ali starejše iz podobnih projektov. Pri podpori je situacija nekoliko drugačna. Te stroške poskušajo zmanjšati na vse možne načine. Podjetja najemajo poceni včerajšnje delavce Enikey in se pogumno podajo v boj. Ta strategija je možna, če govorimo o spletni strani vizitke obrata v Zelenogradu.
Če govorimo o veliki spletni trgovini, potem vsaka ura izpada stane več kot mesečna plača administratorja Enikey. Za izhodišče vzemimo 1 milijardo rubljev letnega prometa. To je najmanjši promet katere koli spletne trgovine iz ocene . Ta znesek razdelite na število ur na leto in dobite več kot 100 rubljev čiste izgube. In če nočnih ur ne štejete, lahko količino mirno podvojite.
Ampak denar ni glavna stvar, kajne? (ne, seveda glavno) Obstajajo tudi izgube ugleda. Propad znane spletne trgovine lahko povzroči tako val kritik na družbenih omrežjih kot objave v tematskih medijih. In pogovorov prijateljev v kuhinji v slogu "Ne kupujte ničesar tam, njihova spletna stran vedno ne deluje" se sploh ne da izmeriti.
Zdaj pa k odgovornosti. V moji praksi je bil primer, ko se dežurni skrbnik ni pravočasno odzval na obvestilo nadzornega sistema o nedosegljivosti spletnega mesta. Na prijeten poletni petkov večer je tiho ležala spletna stran znane spletne trgovine v Moskvi. V soboto zjutraj produktni vodja tega mesta ni razumel, zakaj se spletno mesto ni odprlo, v klepetih za podporo in nujna obvestila v Slacku pa je vladala tišina. Takšna napaka nas je stala šestmestno vsoto, tega dežurnega pa službo.
Odgovornost je spretnost, ki jo je težko razviti. Oseba jo ima ali pa ne. Zato njeno prisotnost pri intervjujih skušam prepoznati z različnimi vprašanji, ki posredno pokažejo, ali je človek navajen prevzemati odgovornost. Če oseba odgovori, da je izbrala univerzo, ker so tako rekli njegovi starši, ali zamenja službo, ker je žena rekla, da ne zasluži dovolj, potem je bolje, da se s takimi ljudmi ne zapletate.
Interakcija z razvojno ekipo
Ko uporabniki med delovanjem naletijo na preproste težave z izdelkom, jih podpora reši sama. Poskuša reproducirati težavo, analizira dnevnike itd. Toda kaj storiti, ko se v izdelku pojavi napaka? V tem primeru podpora dodeli nalogo razvijalcem in tu se začne zabava.
Razvijalci so nenehno preobremenjeni. Ustvarjajo nove funkcije. Odpravljanje napak pri prodaji ni najbolj zanimiva dejavnost. Bližajo se roki za dokončanje naslednjega sprinta. In potem pridejo neprijetni ljudje iz podpore in rečejo: "Takoj nehaj z vsem, imamo težave." Prioriteta takih nalog je minimalna. Še posebej, ko težava ni najbolj kritična in glavna funkcionalnost spletnega mesta deluje in ko upravitelj izdaje ne teka naokoli z izbuljenimi očmi in piše: "Nujno dodajte to nalogo v naslednjo izdajo ali hitri popravek."
Težave z običajno ali nizko prioriteto se premikajo iz izdaje v izdajo. Na vprašanje "Kdaj bo naloga končana?" boste prejeli odgovore v stilu: "Oprostite, trenutno je veliko nalog, vprašajte svoje vodje ekipe ali upravitelja izdaje."
Težave s produktivnostjo imajo večjo prednost kot ustvarjanje novih funkcij. Slabe ocene ne bodo dolgo čakale, če bodo uporabniki nenehno naleteli na napake. Poškodovan ugled je težko obnoviti.
Težave interakcije med razvojem in podporo rešuje DevOps. Ta okrajšava se pogosto uporablja v obliki določene osebe, ki pomaga ustvariti testna okolja za razvoj, gradi cevovode CICD in hitro prenese preizkušeno kodo v proizvodnjo. DevOps je pristop k razvoju programske opreme, pri katerem vsi udeleženci v procesu tesno sodelujejo drug z drugim in pomagajo pri hitrem ustvarjanju in posodabljanju programskih izdelkov in storitev. Mislim na analitike, razvijalce, testerje in podporo.
Pri tem pristopu podpora in razvoj nista različna oddelka s svojimi cilji in cilji. Razvoj je vključen v delovanje in obratno. Slavni stavek porazdeljenih timov: »Problem ni na moji strani« se v klepetih ne pojavlja več tako pogosto in končni uporabniki postanejo nekoliko srečnejši.
Vir: www.habr.com