Hej, Habr! Jeg har understøttet Highload IT-systemer i ti år. Jeg vil ikke skrive i denne artikel om problemerne med at sætte nginx op til at fungere i 1000+ RPS-tilstand eller andre tekniske ting. Jeg vil dele mine observationer om problemerne i de processer, der opstår i support og drift af sådanne systemer.
overvågning
Teknisk support venter ikke, indtil der kommer en anmodning med indholdet "Hvad hvorfor... fungerer siden ikke igen?" Inden for et minut efter at webstedet går ned, skulle support allerede kunne se problemet og begynde at løse det. Men stedet er toppen af isbjerget. Dets tilgængelighed er en af de første, der bliver overvåget.
Hvad skal man gøre med situationen, når de resterende varer i en netbutik ikke længere kommer fra ERP-systemet? Eller er CRM-systemet, der beregner rabatter til kunder, holdt op med at svare? Siden ser ud til at virke. Betinget Zabbix modtager sit 200-svar. Vagtskiftet har ikke modtaget nogen notifikationer fra overvågningen og ser med glæde det første afsnit af den nye sæson af Game of Thrones.
Overvågning er ofte begrænset til kun at måle tilstanden af hukommelse, RAM og serverprocessorbelastning. Men for erhvervslivet er det meget vigtigere at få produkttilgængelighed på hjemmesiden. Den betingede fejl på en virtuel maskine i klyngen vil føre til, at trafikken stopper med at gå til den, og belastningen på andre servere vil stige. Virksomheden vil ikke tabe penge.
Derfor skal du ud over at overvåge de tekniske parametre for operativsystemer på servere konfigurere forretningsmålinger. Målinger, der direkte påvirker penge. Forskellige interaktioner med eksterne systemer (CRM, ERP og andre). Antallet af ordrer for en bestemt periode. Vellykkede eller mislykkede klientautorisationer og andre metrics.
Interaktion med eksterne systemer
Enhver hjemmeside eller mobilapplikation med en årlig omsætning på mere end en milliard rubler interagerer med eksterne systemer. Startende fra ovennævnte CRM og ERP og slutter med overførsel af salgsdata til et eksternt Big Data-system for at analysere indkøb og tilbyde kunden et produkt, som han helt sikkert vil købe (faktisk ikke). Hvert sådant system har sin egen støtte. Og ofte forårsager kommunikation med disse systemer smerte. Især når problemet er globalt, og du skal analysere det i forskellige systemer.
Nogle systemer leverer et telefonnummer eller telegram til deres administratorer. Et eller andet sted skal du skrive breve til ledere eller gå til disse eksterne systemers fejlsporere. Selv inden for rammerne af en stor virksomhed opererer forskellige systemer ofte i forskellige applikationsregnskabssystemer. Nogle gange bliver det umuligt at spore status for en applikation. Du modtager en anmodning i én betinget Jira. Så i kommentaren til denne første Jira sætter du et link til problemet i en anden Jira. I den anden Jira i applikationen er der allerede nogen, der skriver en kommentar, der du skal ringe til den betingede administrator Andrey for at løse problemet. Og så videre.
Den bedste løsning på dette problem ville være at skabe et enkelt rum til kommunikation, for eksempel i Slack. Invitation af alle deltagere i processen med at drive eksterne systemer til at deltage. Og også en enkelt tracker for ikke at duplikere applikationer. Applikationer bør spores ét sted, fra overvågningsmeddelelser til output af fejlløsninger i fremtiden. Du vil sige, at dette er urealistisk, og det er historisk set sket, at vi arbejder i en tracker, og de arbejder i en anden. Forskellige systemer dukkede op, de havde deres egne autonome it-teams. Jeg er enig, og derfor skal problemet løses oppefra på CIO- eller produktejer-niveau.
Ethvert system, du interagerer med, bør give support som en service med en klar SLA for at løse problemer efter prioritet. Og ikke når den betingede admin Andrey har et minut til dig.
Flaskehalsmand
Har alle på et projekt (eller et produkt) en person, hvis rejse på ferie forårsager kramper blandt deres overordnede? Dette kan være en devops-ingeniør, analytiker eller udvikler. Det er trods alt kun en devops-ingeniør, der ved, hvilke servere der har hvilke containere installeret, hvordan man genstarter containeren i tilfælde af et problem, og generelt kan ethvert komplekst problem ikke løses uden ham. Analytikeren er den eneste, der ved, hvordan din komplekse mekanisme fungerer. Hvilke datastrømme går hvor hen. Under hvilke parametre for anmodninger til hvilke tjenester, hvilke vil vi modtage svar.
Hvem vil hurtigt forstå, hvorfor der er fejl i logfilerne og straks rette en kritisk fejl i produktet? Selvfølgelig samme udvikler. Der er andre, men af en eller anden grund forstår kun han, hvordan systemets forskellige moduler fungerer.
Roden til dette problem er manglen på dokumentation. Når alt kommer til alt, hvis alle tjenesterne i dit system blev beskrevet, ville det være muligt at håndtere problemet uden en analytiker. Hvis devops tog et par dage ud af sin travle tidsplan og beskrev alle servere, tjenester og instruktioner til at løse typiske problemer, så kunne problemet i hans fravær løses uden ham. Du behøver ikke hurtigt at færdiggøre din øl på stranden, mens du er på ferie og lede efter wi-fi for at løse problemet.
Støttepersonalets kompetence og ansvar
På store projekter sparer virksomhederne ikke på udviklerlønninger. De leder efter dyre mellempersoner eller seniorer fra lignende projekter. Med støtte er situationen lidt anderledes. De forsøger at reducere disse omkostninger på enhver mulig måde. Virksomheder ansætter billige gårsdagens Enikey-arbejdere og går dristigt i kamp. Denne strategi er mulig, hvis vi taler om et visitkortwebsted for en plante i Zelenograd.
Hvis vi taler om en stor netbutik, så koster hver time med nedetid mere end den månedlige løn for en Enikey-administrator. Lad os tage udgangspunkt i 1 milliard rubler årlig omsætning. Dette er minimumsomsætningen for enhver netbutik fra vurderingen . Divider dette beløb med antallet af timer om året og få mere end 100 rubler i nettotab. Og tæller du ikke nattetimerne med, kan du roligt fordoble mængden.
Men penge er ikke det vigtigste, vel? (nej, selvfølgelig det vigtigste) Der er også tab af omdømme. En velkendt netbutiks undergang kan forårsage både en bølge af anmeldelser på sociale netværk og publikationer i tematiske medier. Og vennernes samtaler i køkkenet i stil med "Køb ikke noget der, deres hjemmeside er altid nede" kan slet ikke måles.
Nu til ansvar. I min praksis var der et tilfælde, hvor vagthavende administrator ikke reagerede i tide på en meddelelse fra overvågningssystemet om sidens manglende tilgængelighed. En hyggelig sommerfredag aften lå hjemmesiden for en kendt netbutik i Moskva stille. Lørdag morgen forstod produktchefen på dette websted ikke, hvorfor siden ikke åbnede, og der var tavshed i support- og hastemeddelelses-chattene i Slack. Sådan en fejl kostede os et sekscifret beløb og denne vagthavende sit job.
Ansvar er en svær færdighed at udvikle. Enten har en person det eller ej. Derfor forsøger jeg under interviews at identificere dets tilstedeværelse med forskellige spørgsmål, der indirekte viser, om en person er vant til at tage ansvar. Hvis en person svarer, at han valgte et universitet, fordi hans forældre sagde det eller skifter job, fordi hans kone sagde, at han ikke tjener nok, så er det bedre ikke at blive involveret med sådanne mennesker.
Interaktion med udviklingsteamet
Når brugere støder på simple problemer med et produkt under drift, løser support dem på egen hånd. Forsøger at reproducere problemet, analyserer logfilerne og så videre. Men hvad skal man gøre, når der opstår en fejl i produktet? I dette tilfælde tildeler support opgaven til udviklerne, og det er her det sjove begynder.
Udviklere er konstant overbelastet. De skaber nye funktioner. At rette fejl med salg er ikke den mest interessante aktivitet. Deadlines nærmer sig for at gennemføre næste sprint. Og så kommer ubehagelige mennesker fra support og siger: "Slut med det samme, vi har problemer." Prioriteten af sådanne opgaver er minimal. Især når problemet ikke er det mest kritiske, og sidens hovedfunktionalitet fungerer, og når releasemanageren ikke render rundt med svulmende øjne og skriver: "Føj haste denne opgave til næste udgivelse eller hotfix."
Problemer med normal eller lav prioritet flyttes fra udgivelse til udgivelse. Til spørgsmålet "Hvornår vil opgaven være færdig?" du vil modtage svar i stil med: "Beklager, der er mange opgaver lige nu, spørg dine teamledere eller release manager."
Produktivitetsproblemer har højere prioritet end at skabe nye funktioner. Dårlige anmeldelser vil ikke være længe om at komme, hvis brugere konstant falder over fejl. Et skadet omdømme er svært at genoprette.
Spørgsmål om interaktion mellem udvikling og support løses af DevOps. Denne forkortelse bruges ofte i form af en specifik person, der hjælper med at skabe testmiljøer til udvikling, bygger CICD pipelines og hurtigt bringer testet kode i produktion. DevOps er en tilgang til softwareudvikling, når alle deltagere i processen interagerer tæt med hinanden og hjælper med hurtigt at skabe og opdatere softwareprodukter og -tjenester. Jeg mener analytikere, udviklere, testere og support.
I denne tilgang er støtte og udvikling ikke forskellige afdelinger med deres egne mål og målsætninger. Udvikling er involveret i drift og omvendt. Den berømte sætning af distribuerede teams: "Problemet er ikke på min side" dukker ikke længere op i chats så ofte, og slutbrugerne bliver lidt gladere.
Kilde: www.habr.com