Hei, Habr! Jeg har støttet Highload IT-systemer i ti år. Jeg vil ikke skrive i denne artikkelen om problemene med å sette opp nginx til å fungere i 1000+ RPS-modus eller andre tekniske ting. Jeg vil dele mine observasjoner om problemene i prosessene som oppstår i støtte og drift av slike systemer.
overvåking
Teknisk støtte venter ikke til en forespørsel kommer med innholdet "Hva hvorfor... fungerer ikke siden igjen?" Innen et minutt etter at nettstedet krasjer, skal støtte allerede se problemet og begynne å løse det. Men siden er toppen av isfjellet. Tilgjengeligheten er en av de første som blir overvåket.
Hva skal man gjøre med situasjonen når de gjenværende varene i en nettbutikk ikke lenger kommer fra ERP-systemet? Eller har CRM-systemet som beregner rabatter for kunder sluttet å svare? Siden ser ut til å fungere. Betinget Zabbix mottar sitt 200-svar. Vaktskiftet har ikke mottatt noen varsler fra overvåkingen og ser med glede på første episode av den nye sesongen av Game of Thrones.
Overvåking er ofte begrenset til kun å måle tilstanden til minne, RAM og serverprosessorbelastning. Men for bedrifter er det mye viktigere å få produkttilgjengelighet på nettsiden. Den betingede feilen til en virtuell maskin i klyngen vil føre til at trafikken slutter å gå til den og belastningen på andre servere vil øke. Selskapet vil ikke tape penger.
Derfor, i tillegg til å overvåke de tekniske parameterne til operativsystemer på servere, må du konfigurere forretningsberegninger. Beregninger som direkte påvirker penger. Ulike interaksjoner med eksterne systemer (CRM, ERP og andre). Antall bestillinger for en viss tidsperiode. Vellykkede eller mislykkede klientautorisasjoner og andre beregninger.
Samhandling med eksterne systemer
Enhver nettside eller mobilapplikasjon med en årlig omsetning på mer enn en milliard rubler samhandler med eksterne systemer. Starter fra ovennevnte CRM og ERP og slutter med overføring av salgsdata til et eksternt Big Data-system for å analysere kjøp og tilby kunden et produkt som han definitivt vil kjøpe (faktisk ikke). Hvert slikt system har sin egen støtte. Og ofte forårsaker kommunikasjon med disse systemene smerte. Spesielt når problemet er globalt og du må analysere det i forskjellige systemer.
Noen systemer gir et telefonnummer eller telegram til administratorene sine. Et sted må du skrive brev til ledere eller gå til feilsporerne til disse eksterne systemene. Selv i sammenheng med ett stort selskap opererer ofte forskjellige systemer i forskjellige applikasjonsregnskapssystemer. Noen ganger blir det umulig å spore statusen til en applikasjon. Du mottar en forespørsel i én betinget Jira. Så i kommentaren til denne første Jira legger du en lenke til problemet i en annen Jira. I den andre Jira i søknaden er det allerede noen som skriver en kommentar som du må ringe den betingede administratoren Andrey for å løse problemet. Og så videre.
Den beste løsningen på dette problemet ville være å skape et enkelt rom for kommunikasjon, for eksempel i Slack. Inviterer alle deltakere i prosessen med drift av eksterne systemer til å bli med. Og også en enkelt tracker for ikke å duplisere applikasjoner. Applikasjoner bør spores på ett sted, fra overvåkingsvarsler til utdata av feilløsninger i fremtiden. Du vil si at dette er urealistisk, og det har historisk sett skjedd at vi jobber i en tracker, og de jobber i en annen. Ulike systemer dukket opp, de hadde sine egne autonome IT-team. Jeg er enig, og derfor må problemet løses ovenfra på CIO- eller produkteiernivå.
Hvert system du samhandler med bør gi støtte som en tjeneste med en klar SLA for å løse problemer etter prioritet. Og ikke når den betingede administratoren Andrey har et minutt for deg.
Flaskehalsmann
Har alle på et prosjekt (eller et produkt) en person hvis reise på ferie forårsaker kramper blant deres overordnede? Dette kan være en devops-ingeniør, analytiker eller utvikler. Tross alt er det bare en devops-ingeniør som vet hvilke servere som har hvilke containere installert, hvordan man starter containeren på nytt i tilfelle et problem, og generelt kan ethvert komplekst problem ikke løses uten ham. Analytikeren er den eneste som vet hvordan den komplekse mekanismen din fungerer. Hvilke datastrømmer går hvor. Under hvilke parametere for forespørsler til hvilke tjenester, hvilke vil vi motta svar.
Hvem vil raskt forstå hvorfor det er feil i loggene og raskt fikse en kritisk feil i produktet? Selvfølgelig samme utvikler. Det finnes andre, men av en eller annen grunn er det bare han som forstår hvordan de forskjellige modulene i systemet fungerer.
Roten til dette problemet er mangelen på dokumentasjon. Tross alt, hvis alle tjenestene til systemet ditt ble beskrevet, ville det være mulig å håndtere problemet uten en analytiker. Hvis devops tok et par dager ut av sin travle timeplan og beskrev alle servere, tjenester og instruksjoner for å løse typiske problemer, så kunne problemet i hans fravær løses uten ham. Du trenger ikke raskt å fullføre ølet ditt på stranden mens du er på ferie og se etter wi-fi for å løse problemet.
Støttepersonells kompetanse og ansvar
På store prosjekter sparer ikke bedriftene på utbyggerlønninger. De leter etter dyre mellompersoner eller seniorer fra lignende prosjekter. Med støtte er situasjonen litt annerledes. De prøver å redusere disse kostnadene på alle mulige måter. Selskaper ansetter rimelige gårsdagens Enikey-arbeidere og går frimodig ut i kamp. Denne strategien er mulig hvis vi snakker om et visittkortnettsted for et anlegg i Zelenograd.
Hvis vi snakker om en stor nettbutikk, koster hver time med nedetid mer enn månedslønnen til en Enikey-administrator. La oss ta utgangspunkt i 1 milliard rubler årlig omsetning. Dette er minimumsomsetningen til enhver nettbutikk fra vurderingen . Del dette beløpet med antall timer per år og få mer enn 100 000 rubler netto tap. Og hvis du ikke teller nattetimene, kan du trygt doble beløpet.
Men penger er ikke hovedsaken, ikke sant? (nei, selvfølgelig hovedsaken) Det er også omdømmetap. Fallet til en kjent nettbutikk kan forårsake både en bølge av anmeldelser på sosiale nettverk og publikasjoner i tematiske medier. Og samtalene til venner på kjøkkenet i stil med "Ikke kjøp noe der, nettsiden deres er alltid nede" kan ikke måles i det hele tatt.
Nå til ansvar. I min praksis var det et tilfelle da vakthavende administrator ikke svarte i tide på en melding fra overvåkingssystemet om manglende tilgjengelighet av siden. En hyggelig sommerfredagskveld lå nettsiden til en kjent nettbutikk i Moskva stille. Lørdag morgen forsto ikke produktsjefen for denne siden hvorfor siden ikke åpnet, og det var stille i support- og hastevarslingschattene i Slack. En slik feil kostet oss et sekssifret beløp, og denne tjenestevakten jobben hans.
Ansvar er en vanskelig ferdighet å utvikle. Enten en person har det eller ikke. Derfor prøver jeg under intervjuer å identifisere dens tilstedeværelse med ulike spørsmål som indirekte viser om en person er vant til å ta ansvar. Hvis en person svarer at han valgte et universitet fordi foreldrene hans sa det eller skifter jobb fordi kona sa at han ikke tjener nok, så er det bedre å ikke bli involvert med slike mennesker.
Samhandling med utviklingsteamet
Når brukere støter på enkle problemer med et produkt under drift, løser support dem på egen hånd. Prøver å reprodusere problemet, analyserer loggene og så videre. Men hva skal jeg gjøre når en feil dukker opp i produktet? I dette tilfellet tildeler støtte oppgaven til utviklerne, og det er her moroa begynner.
Utviklere er konstant overbelastet. De lager nye funksjoner. Å fikse feil med salg er ikke den mest interessante aktiviteten. Det nærmer seg frister for å fullføre neste sprint. Og så kommer ubehagelige folk fra støtte og sier: «Slutt med alt umiddelbart, vi har problemer.» Prioriteten til slike oppgaver er minimal. Spesielt når problemet ikke er det mest kritiske og hovedfunksjonaliteten til nettstedet fungerer, og når utgivelsesbehandleren ikke løper rundt med svulmende øyne og skriver: "Legg til denne oppgaven snarest i neste utgivelse eller hurtigreparasjon."
Problemer med normal eller lav prioritet flyttes fra utgivelse til utgivelse. Til spørsmålet "Når vil oppgaven være fullført?" du vil motta svar i stil med: "Beklager, det er mange oppgaver akkurat nå, spør teamlederne dine eller release manager."
Produktivitetsproblemer har høyere prioritet enn å lage nye funksjoner. Dårlige anmeldelser vil ikke vente lenge på seg hvis brukere stadig snubler over feil. Et skadet rykte er vanskelig å gjenopprette.
Spørsmål om interaksjon mellom utvikling og støtte løses av DevOps. Denne forkortelsen brukes ofte i form av en spesifikk person som hjelper til med å lage testmiljøer for utvikling, bygger CICD-pipelines og raskt bringer testet kode i produksjon. DevOps er en tilnærming til programvareutvikling når alle deltakerne i prosessen samhandler tett med hverandre og hjelper til raskt å lage og oppdatere programvareprodukter og -tjenester. Jeg mener analytikere, utviklere, testere og support.
I denne tilnærmingen er støtte og utvikling ikke forskjellige avdelinger med egne mål og mål. Utvikling er involvert i drift og omvendt. Den berømte setningen til distribuerte team: "Problemet er ikke på min side" vises ikke lenger i chatter så ofte, og sluttbrukerne blir litt mer fornøyde.
Kilde: www.habr.com