Udviklere er fra Mars, administratorer er fra Venus

Tilfældigheder er tilfældige, og det var faktisk på en anden planet...

Jeg vil gerne dele tre succes- og fiaskohistorier om, hvordan en backend-udvikler arbejder i et team med administratorer.

Historie en.
Webstudie, antallet af medarbejdere kan tælles med én hånd. I dag er du layoutdesigner, i morgen er du backender, i overmorgen er du admin. På den ene side kan du få en enorm erfaring. Til gengæld mangler der kompetencer på alle områder. Jeg husker stadig den første arbejdsdag, jeg er stadig grøn, chefen siger: "Åben kit," men jeg ved ikke, hvad det er. Kommunikation med administratorer er udelukket, pga du er selv admin. Lad os overveje fordele og ulemper ved denne situation.

+ Al magt er i dine hænder.
+ Der er ingen grund til at bede nogen om adgang til serveren.
+ Hurtig reaktionstid i alle retninger.
+ Forbedrer færdigheder godt.
+ Har en fuldstændig forståelse af produktarkitekturen.

- Stort ansvar.
— Risiko for at bryde produktionen.
- Det er svært at være en god specialist på alle områder.

Ikke interesseret, lad os komme videre

Den anden historie.
Stor virksomhed, stort projekt. Der er en administrationsafdeling med 5-7 medarbejdere og flere udviklingsgrupper. Når du kommer for at arbejde i sådan en virksomhed, tænker enhver administrator, at du ikke kom her for at arbejde på et produkt, men for at bryde noget. Hverken den underskrevne NDA eller udvælgelsen ved interviewet indikerer andet. Nej, denne mand kom her med sine små beskidte hænder for at ødelægge vores kysseproduktion. Derfor har du med sådan en person brug for et minimum af kommunikation; i det mindste kan du smide et klistermærke som svar. Svar ikke på spørgsmål om projektarkitekturen. Det er tilrådeligt ikke at give adgang, før teamlederen spørger. Og når han spørger, vil han give det tilbage med endnu færre privilegier, end de bad om. Næsten al kommunikation med sådanne administratorer absorberes af det sorte hul mellem udviklingsafdelingen og administrationsafdelingen. Det er umuligt at løse problemer hurtigt. Men du kan ikke komme personligt - administratorerne har for travlt 24/7. (Hvad laver du hele tiden?) Nogle præstationskarakteristika:

• Gennemsnitlig implementeringstid til produktion er 4-5 timer
• Maksimal implementeringstid i produktion 9 timer
• For en udvikler er en applikation i produktion en sort boks, ligesom selve produktionsserveren. Hvor mange er der i alt?
• Lav kvalitet af udgivelser, hyppige fejl
• Udvikleren deltager ikke i udgivelsesprocessen

Nå, hvad havde jeg forventet, selvfølgelig, nye mennesker er ikke tilladt i produktionen. Nå, okay, efter at have fået tålmodighed, begynder vi at vinde andres tillid. Men af ​​en eller anden grund er tingene ikke så enkle med administratorer.

Akt 1. Admin er usynlig.
Udgivelsesdag, udvikler og administrator kommunikerer ikke. Administratoren har ingen spørgsmål. Men du forstår hvorfor senere. Administratoren er en principfast person, har ikke budbringere, giver ikke sit telefonnummer til nogen og har ikke en profil på sociale netværk. Der er ikke engang et billede af ham nogen steder, hvordan ser du ud fyr? Vi sidder med den ansvarlige leder i cirka 15 minutter i forvirring og forsøger at etablere kommunikation med denne Voyager 1, så kommer der en besked i virksomhedens e-mail om, at han er færdig. Skal vi korrespondere via mail? Hvorfor ikke? Praktisk, ikke? Nå, okay, lad os køle af. Processen er allerede i gang, der er ingen vej tilbage. Læs beskeden igen. "Jeg er færdig". Hvad blev du færdig med? Hvor? Hvor skal jeg lede efter dig? Her forstår du, hvorfor 4 timer til frigivelse er normalt. Vi får et udviklingschok, men vi afslutter udgivelsen. Der er ikke længere lyst til at frigive.

Akt 2. Ikke den version.
Næste udgivelse. Efter at have fået erfaring begynder vi at oprette lister over den nødvendige software og biblioteker til serveren for administratorer, hvilket angiver versionerne for nogle. Som altid modtager vi et svagt radiosignal om, at admin har afsluttet noget der. Regressionstesten begynder, som i sig selv tager cirka en time. Alt ser ud til at virke, men der er en kritisk fejl. Vigtig funktionalitet virker ikke. De næste par timer var dans med tamburiner, spådom på kaffegrums og en detaljeret gennemgang af hvert stykke kode. Administratoren siger, at han har gjort alt. Applikationen skrevet af skæve udviklere virker ikke, men serveren virker. Har du spørgsmål til ham? Efter en time får vi administratoren til at sende versionen af ​​biblioteket på produktionsserveren ind i chatten og bingoen - det er ikke den, vi har brug for. Vi beder administratoren om at installere den påkrævede version, men som svar får vi, at han ikke kan gøre dette på grund af fraværet af denne version i OS-pakkehåndteringen. Her, fra fordybningerne i sin hukommelse, husker lederen, at en anden administrator allerede havde løst dette problem ved blot at samle den nødvendige version i hånden. Men nej, vores vil ikke gøre dette. Reglerne forbyder. Karl, vi har siddet her i flere timer, hvad er tidsgrænsen?! Vi får endnu et chok og afslutter udgivelsen på en eller anden måde.

3. akt, kort
Haster billet, nøglefunktionalitet virker ikke for en af ​​brugerne i produktionen. Vi bruger et par timer på at stikke og tjekke. I et udviklingsmiljø fungerer alt. Der er en klar forståelse af, at det ville være en god ide at kigge i php-fpm-loggene. Der var ingen logsystemer som ELK eller Prometheus på projektet på det tidspunkt. Vi åbner en billet til administrationsafdelingen, så de giver adgang til php-fpm logs på serveren. Her skal du forstå, at vi beder om adgang af en grund, husker du ikke om det sorte hul og administratorer, der har travlt 24/7? Hvis du beder dem om at se på loggene selv, så er dette en opgave med en "ikke i dette liv"-prioritet. Billetten blev oprettet, vi modtog et øjeblikkeligt svar fra lederen af ​​administrationsafdelingen: "Du skal ikke have adgang til produktionslogfiler, skriv uden fejl." Et gardin.

4. lov og senere
Vi indsamler stadig snesevis af problemer i produktionen på grund af forskellige versioner af biblioteker, ukonfigureret software, uforberedte serverbelastninger og andre problemer. Selvfølgelig er der også kodefejl, vi vil ikke bebrejde administratorerne for alle synderne, vi vil blot nævne en mere typisk operation for det projekt. Vi havde en del baggrundsarbejdere, der blev lanceret gennem supervisoren, og nogle scripts skulle tilføjes til cron. Nogle gange holdt de samme arbejdere op med at arbejde. Belastningen på køserveren voksede med lynets hast, og triste brugere kiggede på den snurrende læsser. For hurtigt at reparere sådanne arbejdere var det nok blot at genstarte dem, men igen kunne kun en administrator gøre dette. Mens sådan en grundlæggende operation blev udført, kunne der gå en hel dag. Her er det selvfølgelig værd at bemærke, at skæve programmører bør skrive arbejdere, så de ikke styrter, men når de falder, ville det være rart at forstå, hvorfor, hvilket nogle gange er umuligt på grund af den manglende adgang til produktion, af selvfølgelig, og som en konsekvens, manglen på logfiler fra udvikleren.

Transfiguration.
Efter at have udholdt alt dette i ret lang tid, begyndte vi sammen med holdet at styre i en retning, der var mere succesfuld for os. For at opsummere, hvilke problemer stod vi over for?

• Manglende kvalitetskommunikation mellem udviklere og administrationsafdeling
• Administratorer, viser det sig(!), forstår slet ikke, hvordan applikationen er opbygget, hvilke afhængigheder den har, og hvordan den fungerer.
• Udviklere forstår ikke, hvordan produktionsmiljøet fungerer og kan som et resultat ikke reagere effektivt på problemer.
• Implementeringsprocessen tager for lang tid.
• Ustabile udgivelser.

Hvad har vi gjort?
For hver udgivelse blev der genereret en liste over udgivelsesbemærkninger, som inkluderede en liste over arbejde, der skal udføres på serveren, for at den næste udgivelse virker. Listen indeholdt flere sektioner, arbejde der skulle udføres af administratoren, den ansvarlige for udgivelsen og udvikleren. Udviklere fik ikke-root-adgang til alle produktionsservere, hvilket fremskyndede udvikling generelt og problemløsning i særdeleshed. Udviklere har også en forståelse for, hvordan produktionen fungerer, hvilke tjenester den er opdelt i, hvor og hvor meget replikaer koster. Nogle af kampbelastningerne er blevet tydeligere, hvilket uden tvivl påvirker kodens kvalitet. Kommunikation under udgivelsesprocessen fandt sted i chatten til en af ​​instant messengers. For det første havde vi en log over alle handlinger, og for det andet foregik kommunikationen i et tættere miljø. At have en historie med handlinger har mere end én gang gjort det muligt for nye medarbejdere at løse problemer hurtigere. Det er et paradoks, men dette hjalp ofte administratorerne selv. Jeg vil ikke påtage mig at sige det med sikkerhed, men det forekommer mig, at administratorer er begyndt at forstå mere, hvordan projektet fungerer, og hvordan det er skrevet. Nogle gange delte vi endda nogle detaljer med hinanden. Den gennemsnitlige frigivelsestid er reduceret til en time. Nogle gange var vi færdige på 30-40 minutter. Antallet af fejl er faldet markant, hvis ikke tidoblet. Naturligvis har andre faktorer også påvirket reduktionen af ​​udgivelsestiden, såsom autotests. Efter hver udgivelse begyndte vi at lave retrospektiver. Så hele teamet har en idé om, hvad der er nyt, hvad der er ændret, og hvad der er blevet fjernet. Desværre kom admins ikke altid til dem, ja, admins har travlt... Min arbejdsglæde som udvikler er uden tvivl steget. Når du hurtigt kan løse næsten ethvert problem inden for dit kompetenceområde, føler du dig på toppen. Senere vil jeg forstå, at vi til en vis grad introducerede en devops-kultur, selvfølgelig ikke helt, men selv den begyndelse på transformationen var imponerende.

Historie tre
Start op. Én admin, lille udviklingsafdeling. Ved ankomst er jeg et komplet nul, fordi... Jeg har ingen adgang andre steder end fra posten. Vi skriver til administratoren og beder om adgang. Derudover er der information om, at han er opmærksom på den nye medarbejder og behovet for at udstede logins/adgangskoder. De giver adgang fra lageret og VPN. Hvorfor give adgang til wiki, teamcity, rundesk? Ubrugelige ting for en person, der blev kaldt til at skrive hele backend-delen. Først med tiden får vi adgang til nogle værktøjer. Ankomsten blev naturligvis mødt med mistillid. Jeg forsøger langsomt at få en fornemmelse af, hvordan projektets infrastruktur fungerer gennem chats og ledende spørgsmål. Som udgangspunkt genkender jeg intet. Produktionen er den samme sorte boks som før. Men mere end det, selv de sceneservere, der bruges til test, er en sort boks. Vi kan ikke gøre andet end at installere en filial fra Git der. Vi kan heller ikke konfigurere vores applikation som .env-filer. Adgang til sådanne operationer gives ikke. Du skal tigge for at få ændret en linje i din applikations konfiguration på testserveren. (Der er en teori om, at det er vigtigt for administratorer at føle sig vigtige i projektet; hvis de ikke bliver bedt om at ændre linjer i konfigurationerne, vil de simpelthen ikke være nødvendige). Nå, som altid, er det ikke praktisk? Dette bliver hurtigt kedeligt, efter en direkte samtale med admin finder vi ud af, at udviklerne er født til at skrive dårlig kode, er af natur inkompetente individer, og det er bedre at holde dem væk fra produktionen. Men her også fra testservere, for en sikkerheds skyld. Konflikten eskalerer hurtigt. Der er ingen kommunikation med administratoren. Situationen forværres af, at han er alene. Det følgende er et typisk billede. Frigøre. Visse funktioner virker ikke. Det tager os lang tid at finde ud af, hvad der foregår, forskellige ideer fra udviklere bliver smidt ind i chatten, men administratoren i en sådan situation antager som regel, at udviklerne har skylden. Så skriver han i chatten, vent, jeg rettede ham. Når vi bliver bedt om at efterlade en historie med information om, hvad problemet var, modtager vi giftige undskyldninger. Lad være med at stikke næsen der, hvor den ikke hører hjemme. Udviklere skal skrive kode. Situationen, hvor mange kropsbevægelser i et projekt går igennem én enkelt person, og kun han har adgang til at udføre de operationer, alle har brug for, er ekstremt trist. Sådan en person er en frygtelig flaskehals. Hvis Devops-ideer stræber efter at reducere time-to-market, så er sådanne mennesker Devops-ideernes værste fjende. Desværre lukker gardinet her.

P.S. Efter at have talt lidt om udviklere vs administratorer i chats med folk, mødte jeg folk, der delte min smerte. Men der var også dem, der sagde, at de aldrig var stødt på noget lignende. På en devops-konference spurgte jeg Anton Isanin (Alfa Bank), hvordan de håndterede problemet med flaskehalsen i form af administratorer, hvortil han sagde: "Vi erstattede dem med knapper." I øvrigt podcast med hans deltagelse. Jeg vil gerne tro, at der er mange flere gode administratorer end fjender. Og ja, billedet i begyndelsen er en rigtig korrespondance.

Kilde: www.habr.com