Hej, Habr! I ti år har jeg støttet Highload IT-systemer. Jeg vil ikke skrive om problemerne med at konfigurere nginx til at arbejde i en tilstand med 1000+ RPS eller andre tekniske emner i denne artikel. Jeg vil dele nogle observationer om de problemer, der opstår i processerne, der kræves for at understøtte og drifte sådanne systemer.
Overvågning
Supporten venter ikke, indtil der kommer en forespørgsel med indholdet 'Hvad sker der?… hjemmesiden virker ikke igen?'. Supporten skal hurtigt efter, at hjemmesiden er faldet, se problemet og begynde at løse det. Men hjemmesiden er kun toppen af isbjerget.Dens tilgængelighed overvåges som en af de første.
Hvad skal man gøre i en situation, hvor lagrene i en online butik stopper med at komme fra ERP-systemet? Eller CRM-systemet, der beregner rabatter for kunderne, stopper med at svare? Hjemmesiden ser ud til at fungere. Den virtuelle overvågning får sit 200 svar. Det vagthold, der er på arbejde, modtager ingen underretninger fra overvågningen og ser glad den første episode af den nye sæson af 'Game of Thrones'.
Ofte er overvågningen kun begrænset til at måle tilstanden af hukommelse, RAM og belastningen på processorerne. servere. Men for erhvervslivet er det meget vigtigere at få information om tilgængeligheden af varer på hjemmesiden. Et hypotetisk fald af en virtuel maskine i klyngen vil føre til, at trafikken stopper med at gå til den, og belastningen på de andre servere vil stige. Virksomheden vil ikke miste penge.
Derfor skal man udover overvågning af tekniske parametre i operativsystemerne på serverne også indføre forretningsmetrikker. Metrikker, der direkte påvirker pengene. Forskellige interaktioner med eksterne systemer (CRM, ERP osv.). Antallet af ordrer i en bestemt tidsperiode. Succesfulde eller mislykkedes kunderettigheder og andre metrikker.
Interaktion med eksterne systemer
Enhver hjemmeside eller mobilapplikation med en årlig omsætning på over en milliard rubler interagerer med eksterne systemer. Fra de førnævnte CRM- og ERP-systemer til overførslen af data om salg til et eksternt Big Data-analyse system, der analyserer køb og foreslår varer til kunden, som de helt sikkert vil købe (det gør de faktisk ikke). Hver sådan system har sin egen support. Og ofte medfører kommunikation med disse systemer smerter. Især når problemet er globalt og skal analyseres på tværs af forskellige systemer.
Nogle systemer giver telefonnummer eller telegram til deres administratorer. Andre steder skal man skrive e-mails til managerne eller gå ind i bug trackere for disse eksterne systemer. Selv inden for en stor virksomhed arbejder forskellige systemer ofte i forskellige ticketing systemer. At følge status for en ticket kan nogle gange være umuligt. Du modtager en ticket i én hypotetisk Jira. Derefter sætter du et link til opgaven i en anden Jira i kommentaren til denne første Jira. I den anden Jira skriver nogen allerede en kommentar om, at man skal ringe til den hypotetiske administrator Andrey for at løse problemet. Og så videre.
Den optimale løsning på et sådant problem ville være at skabe et fælles rum for kommunikation, for eksempel i Slack. At invitere alle deltagere i driftsprocessen af de eksterne systemer. Og også et fælles tracker for ikke at duplikere tickets. Tickets bør følges i ét sted, fra overvågningsmeddelelser til løsning af bugs i produktion. Du vil måske sige, at dette er urealistisk, og I har historisk set arbejdet i én tracker, mens de arbejder i en anden. Der opstod forskellige systemer, og de havde deres egne autonome IT-teams. Jeg er enig, og derfor skal problemet løses fra top til bund, på niveau med CIO eller produkt ejer.
Hver system, som du interagerer med, bør yde support som en tjeneste med en klar SLA for løsning af problemer efter prioriteter. Og ikke kun når den hypotetiske administrator Andrey har et minut til dig.
Mennesket – flaskehalsen
Er der en person på projektet (eller produktet), hvis ferie får cheferne til at få anfald? Dette kan være en devops ingeniør, analytiker eller udvikler. For kun devops ingeniøren ved, hvilke servere der har hvilke containere installeret, hvordan man genstarter en container i tilfælde af problemer, og enhver kompleks problem uden ham løses ikke. Analytikeren er den eneste, der ved, hvordan dit komplekse system fungerer. Hvilke datastreams der går hvor. Under hvilke parametre der foretages anmodninger til hvilke tjenester, og hvilke svar vi vil modtage.
Hvem forstår hurtigt, hvorfor der er fejl i loggene og hurtigt kan fikse en kritisk bug i produktionen? Selvfølgelig, det samme udvikler. Der er andre, men af en eller anden grund er det kun ham, der forstår, hvordan forskellige moduler i systemet fungerer.
Kernen i dette problem er manglen på dokumentation.For hvis alle tjenester i dit system var beskrevet, kunne man løse problemet uden en analytiker. Hvis devops havde taget et par dage ud af sin tætte tidsplan og beskrevet alle servere, tjenester og instruktioner til løsning af typiske problemer, kunne vi også have løst problemet i hans fravær. Man behøver ikke at drikke sit øl hurtigt på stranden i ferien og lede efter wi-fi for at løse et problem.
Kompetence og ansvar for supportmedarbejdere
I store projekter spare virksomheder ikke på lønninger til udviklerne. De jagter dyre mid-levels eller seniors fra lignende projekter. Situationen er lidt anderledes med support. Disse omkostninger forsøges at blive reduceret. Virksomheder ansætter billige nyuddannede IT-supportere og går modigt ind i kampen. En sådan strategi er mulig, hvis vi taler om et visitkort-website for en fabrik i Zelenograd.
Hvis vi taler om en stor online butik, koster hver time med nedetid mere end en månedsløn for en IT-supporter. Lad os tage udgangspunkt i 1 milliard rubler i årlig omsætning. Dette er den minimale omsætning for enhver online butik fra ranglisten . Vi deler dette beløb med antallet af timer på et år og får over 100.000 rubler i netto tab. Og hvis vi ikke tæller nat timerne med, kan vi trygt fordoble beløbet.
Men penge er jo ikke det vigtigste, ikke? (nej, selvfølgelig er det vigtigt) Der er også omdømmetab. En time med nedbrud for en kendt online butik kan føre til både bølger af anmeldelser på sociale medier og publikationer i specialiserede medier. Og samtaler mellem venner i køkkenet som 'Køb ikke noget der, deres website virker konstant ikke' kan slet ikke måles.
Nu til ansvaret. I min erfaring har der været tilfælde, hvor den vagthavende administrator ikke reagerede rettidigt på meddelelser fra overvågningssystemet om, at hjemmesiden var utilgængelig. På en dejlig sommerfredag aften lå et velkendt online butikswebsite stille. Om lørdagen morgen forstod produktlederen ikke, hvorfor hjemmesiden ikke kunne åbnes, og der var stille i supportchattene og de hastige meddelelser i Slack. Denne fejl kostede os en sekscifret sum, og denne vagt mistede sit job.
Ansvar er en færdighed, der er svær at udvikle. Enten har en person det, eller så har de det ikke. Derfor prøver jeg ved jobsamtaler at afdække dets tilstedeværelse med forskellige spørgsmål, som indirekte viser, om personen er vant til at påtage sig ansvar. Hvis en person svarer, at de valgte universitetet, fordi forældrene sagde det, eller skifter job, fordi konen sagde, at de tjener for lidt, så er det bedst ikke at samarbejde med sådanne mennesker.
Interaktion med udviklingsteamet
Når der opstår enkle problemer for brugerne i produktionen, løser supporten dem selv. De prøver at genskabe problemet, analyserer logfiler osv. Men hvad skal man gøre, når der dukker en fejl op i produktionen? I så fald opretter supporten en opgave til udviklerne, og det er her, det bliver virkelig interessant.
Udviklerne er konstant overbelastede. De arbejder på at skabe nye funktioner. At fikse fejl i produktionen er ikke ligefrem den mest spændende opgave. Fristerne for at afslutte den næste sprint nærmer sig. Og så kommer ubehagelige mennesker fra supporten og siger: "Skal vi straks droppe alt, vi har problemer". Prioriteten for sådanne opgaver er minimal. Især når problemet ikke er kritisk, og den grundlæggende funktionalitet på hjemmesiden fungerer, og når udgivelseslederen ikke løber rundt med store øjne og skriver: "Skal denne opgave straks tilføjes til den nærmeste udgivelse eller hotfix".
Opgaver med almindelig eller lav prioritet flytter fra udgivelse til udgivelse. Når man spørger: "Hvornår bliver opgaven udført?" vil man få svar i stil med: "Beklager, der er mange opgaver lige nu, spørg teamlederne eller udgivelseslederen".
Problemer i produktionen har højere prioritet end at skabe nye funktioner. Dårlige anmeldelser lader ikke vente på sig, hvis brugerne konstant støder på fejl. Det er svært at genoprette et ødelagt omdømme.
Spørgsmål om interaktionen mellem udvikling og support løses af DevOps. Denne forkortelse bruges ofte til at betegne en konkret person, der hjælper med at oprette testmiljøer til udvikling, bygger CICD-pipelines og hurtigt bringer testet kode til produktion. DevOps er en tilgang til softwareudvikling, hvor alle deltagere i processen arbejder tæt sammen og hjælper med at skabe og opdatere softwareprodukter og tjenester hurtigere. Jeg mener analytikere, udviklere, testere og support.
Support and development in this approach are not separate departments with their own goals and tasks. Development is involved in operations and vice versa. The famous phrase from distributed teams, "The problem is not on my side," is not so frequently seen in chats anymore, and end users are becoming a little happier.
Kilde: habr.com
