Tilfeldigheter er tilfeldige, og det var faktisk på en annen planet...
Jeg vil gjerne dele tre suksess- og fiaskohistorier om hvordan en backend-utvikler jobber i et team med administratorer.
Historie en.
Webstudio, antall ansatte kan telles med én hånd. I dag er du layoutdesigner, i morgen er du backender, i overmorgen er du admin. På den ene siden kan du få enorm erfaring. På den annen side er det mangel på kompetanse på alle områder. Jeg husker fortsatt den første arbeidsdagen, jeg er fortsatt grønn, sjefen sier: "Åpen sparkel," men jeg vet ikke hva det er. Kommunikasjon med administratorer er utelukket, fordi du er selv administrator. La oss vurdere fordeler og ulemper med denne situasjonen.
+ All makt er i dine hender.
+ Det er ikke nødvendig å trygle noen om tilgang til serveren.
+ Rask reaksjonstid i alle retninger.
+ Forbedrer ferdighetene godt.
+ Ha en fullstendig forståelse av produktarkitekturen.
– Høyt ansvar.
— Fare for å bryte produksjonen.
— Det er vanskelig å være en god spesialist på alle områder.
Ikke interessert, la oss gå videre
Den andre historien.
Stort selskap, stort prosjekt. Det er en administrasjonsavdeling med 5-7 ansatte og flere utviklingsgrupper. Når du kommer for å jobbe i et slikt selskap, tror hver admin at du ikke kom hit for å jobbe med et produkt, men for å ødelegge noe. Verken den undertegnede NDA eller utvalget ved intervjuet indikerer noe annet. Nei, denne mannen kom hit med sine skitne små hender for å ødelegge kysseproduksjonen vår. Derfor, med en slik person trenger du et minimum av kommunikasjon; i det minste kan du kaste et klistremerke som svar. Ikke svar på spørsmål om prosjektarkitekturen. Det anbefales ikke å gi tilgang før teamlederen spør. Og når han spør, vil han gi det tilbake med enda færre privilegier enn de ba om. Nesten all kommunikasjon med slike administratorer absorberes av det sorte hullet mellom utviklingsavdelingen og administrasjonsavdelingen. Det er umulig å løse problemer raskt. Men du kan ikke komme personlig - administratorene er for opptatt 24/7. (Hva gjør du hele tiden?) Noen ytelsesegenskaper:
- Gjennomsnittlig utrullingstid i produksjon er 4-5 timer
- Maksimal utplasseringstid i produksjon 9 timer
- For en utvikler er en applikasjon i produksjon en svart boks, akkurat som selve produksjonsserveren. Hvor mange er det totalt?
- Lav kvalitet på utgivelser, hyppige feil
- Utvikleren deltar ikke i utgivelsesprosessen
Vel, hva hadde jeg forventet, selvfølgelig, nye folk får ikke komme inn i produksjonen. Vel, ok, etter å ha fått tålmodighet, begynner vi å få tillit fra andre. Men av en eller annen grunn er ting ikke så enkelt med administratorer.
Akt 1. Administratoren er usynlig.
Utgivelsesdag, utvikler og admin kommuniserer ikke. Administratoren har ingen spørsmål. Men du forstår hvorfor senere. Administratoren er en prinsipiell person, har ikke budbringere, gir ikke ut telefonnummeret sitt til noen og har ingen profil på sosiale nettverk. Det er ikke engang et bilde av ham noe sted, hvordan ser du ut? Vi sitter med ansvarlig leder i ca. 15 minutter i rådvillhet og prøver å etablere kommunikasjon med denne Voyager 1, så dukker det opp en melding i bedriftens e-post om at han er ferdig. Skal vi korrespondere per post? Hvorfor ikke? Praktisk, ikke sant? Vel, ok, la oss kjøle oss ned. Prosessen er allerede i gang, det er ingen vei tilbake. Les meldingen på nytt. "Jeg er ferdig". Hva ble du ferdig med? Hvor? Hvor skal jeg lete etter deg? Her forstår du hvorfor 4 timer for utgivelse er normalt. Vi får et utviklingssjokk, men vi fullfører utgivelsen. Det er ikke lenger noe ønske om å løslate.
Akt 2. Ikke den versjonen.
Neste utgivelse. Etter å ha fått erfaring, begynner vi å lage lister over nødvendig programvare og biblioteker for serveren for administratorer, som indikerer versjonene for noen. Som alltid får vi et svakt radiosignal om at admin har fullført noe der. Regresjonstesten starter, som i seg selv tar omtrent en time. Alt ser ut til å fungere, men det er en kritisk feil. Viktig funksjonalitet fungerer ikke. De neste timene var dans med tamburiner, spådom på kaffegrut og en detaljert gjennomgang av hver kodebit. Administratoren sier han har gjort alt. Applikasjonen skrevet av skjeve utviklere fungerer ikke, men serveren fungerer. Noen spørsmål til ham? På slutten av en time får vi administratoren til å sende versjonen av biblioteket på produksjonsserveren til chat og bingo - det er ikke den vi trenger. Vi ber administratoren om å installere den nødvendige versjonen, men som svar får vi at han ikke kan gjøre dette på grunn av fraværet av denne versjonen i OS-pakkebehandlingen. Her, fra fordypningene i hukommelsen hans, husker lederen at en annen administrator allerede hadde løst dette problemet ved ganske enkelt å sette sammen den nødvendige versjonen for hånd. Men nei, vårt vil ikke gjøre dette. Forskriften forbyr. Karl, vi har sittet her i flere timer, hva er tidsbegrensningen?! Vi får et nytt sjokk og fullfører på en eller annen måte utgivelsen.
Akt 3, kort
Haster billett, nøkkelfunksjonalitet fungerer ikke for en av brukerne i produksjon. Vi bruker et par timer på å stikke og sjekke. I et utviklingsmiljø fungerer alt. Det er en klar forståelse av at det ville være en god idé å se på php-fpm-loggene. Det var ingen loggsystemer som ELK eller Prometheus på prosjektet på den tiden. Vi åpner en billett til administrasjonsavdelingen slik at de gir tilgang til php-fpm-loggene på serveren. Her må du forstå at vi ber om tilgang av en grunn, husker du ikke om det sorte hullet og at administratorer er opptatt 24/7? Hvis du ber dem om å se på loggene selv, så er dette en oppgave med en "ikke i dette livet"-prioritet. Billetten ble opprettet, vi fikk et øyeblikkelig svar fra sjefen for administrasjonsavdelingen: "Du bør ikke trenge tilgang til produksjonslogger, skriv uten feil." En gardin.
Akt 4 og utover
Vi samler fortsatt dusinvis av problemer i produksjonen, på grunn av forskjellige versjoner av biblioteker, ukonfigurert programvare, uforberedte serverbelastninger og andre problemer. Selvfølgelig er det også kodefeil, vi vil ikke klandre administratorene for alle syndene, vi vil bare nevne en mer typisk operasjon for det prosjektet. Vi hadde ganske mange bakgrunnsarbeidere som ble lansert gjennom veilederen, og noen skript måtte legges til cron. Noen ganger sluttet de samme arbeiderne å jobbe. Belastningen på køserveren vokste med lynets hastighet, og triste brukere så på den snurrende lasteren. For raskt å fikse slike arbeidere var det nok å starte dem på nytt, men igjen, bare en administrator kunne gjøre dette. Mens en slik grunnleggende operasjon ble utført, kunne det gå en hel dag. Her er det selvfølgelig verdt å merke seg at skjeve programmerere bør skrive arbeidere slik at de ikke krasjer, men når de faller, ville det være greit å forstå hvorfor, noe som noen ganger er umulig på grunn av manglende tilgang til produksjon, av selvfølgelig, og som en konsekvens, mangelen på logger fra utvikleren.
Transfigurasjon.
Etter å ha holdt ut alt dette ganske lenge, begynte vi sammen med teamet å styre i en retning som var mer vellykket for oss. For å oppsummere, hvilke problemer møtte vi?
- Mangel på kvalitetskommunikasjon mellom utviklere og administrasjonsavdeling
- Administratorer, viser det seg(!), forstår ikke i det hele tatt hvordan applikasjonen er bygget opp, hvilke avhengigheter den har og hvordan den fungerer.
- Utviklere forstår ikke hvordan produksjonsmiljøet fungerer og kan som et resultat ikke svare effektivt på problemer.
- Implementeringsprosessen tar for lang tid.
- Ustabile utgivelser.
Hva har vi gjort?
For hver utgivelse ble det generert en liste med utgivelsesnotater, som inkluderte en liste over arbeid som må gjøres på serveren for at neste utgivelse skal fungere. Listen inneholdt flere seksjoner, arbeid som skulle utføres av administrator, ansvarlig for utgivelsen og utvikler. Utviklere fikk ikke-root-tilgang til alle produksjonsservere, noe som satte fart på utvikling generelt og problemløsning spesielt. Utviklere har også forståelse for hvordan produksjonen fungerer, hvilke tjenester den er delt inn i, hvor og hvor mye kopier koster. Noen av kampbelastningene har blitt tydeligere, noe som utvilsomt påvirker kvaliteten på koden. Kommunikasjon under utgivelsesprosessen fant sted i chatten til en av direktemeldingstjenestene. For det første hadde vi en logg over alle handlinger, og for det andre skjedde kommunikasjonen i et tettere miljø. Å ha en historie med handlinger har mer enn en gang gjort det mulig for nye ansatte å løse problemer raskere. Det er et paradoks, men dette hjalp ofte administratorene selv. Jeg vil ikke påta meg å si det sikkert, men det virker for meg som administratorer har begynt å forstå mer hvordan prosjektet fungerer og hvordan det er skrevet. Noen ganger delte vi til og med noen detaljer med hverandre. Gjennomsnittlig utgivelsestid er redusert til en time. Noen ganger var vi ferdige på 30-40 minutter. Antall bugs har redusert betydelig, om ikke tidoblet. Selvfølgelig påvirket også andre faktorer reduksjonen i utgivelsestid, for eksempel autotester. Etter hver utgivelse begynte vi å gjennomføre retrospektiver. Slik at hele teamet har en ide om hva som er nytt, hva som er endret og hva som er fjernet. Dessverre kom det ikke alltid admins til dem, vel, admins har det travelt... Arbeidsgleden min som utvikler har uten tvil økt. Når du raskt kan løse nesten ethvert problem som er innenfor ditt kompetanseområde, føler du deg på topp. Senere vil jeg forstå at vi til en viss grad introduserte en devops-kultur, ikke helt, selvfølgelig, men selv den begynnelsen av transformasjonen var imponerende.
Historie tre
Oppstart. En admin, liten utviklingsavdeling. Ved ankomst er jeg et fullstendig null, fordi... Jeg har ingen tilgang andre steder enn fra posten. Vi skriver til admin og ber om tilgang. I tillegg kommer informasjon om at han er klar over den nyansatte og behovet for å utstede pålogginger/passord. De gir tilgang fra depotet og VPN. Hvorfor gi tilgang til wiki, teamcity, rundesk? Ubrukelige ting for en person som ble kalt til å skrive hele backend-delen. Først over tid får vi tilgang til noen verktøy. Ankomsten ble selvfølgelig møtt med mistillit. Jeg prøver sakte å få en følelse av hvordan prosjektets infrastruktur fungerer gjennom chatter og ledende spørsmål. Jeg kjenner meg i grunnen ikke igjen. Produksjonen er den samme sorte boksen som før. Men mer enn det, selv sceneserverne som brukes til testing er en svart boks. Vi kan ikke gjøre noe annet enn å distribuere en gren fra Git der. Vi kan heller ikke konfigurere applikasjonen vår som .env-filer. Tilgang for slike operasjoner gis ikke. Du må tigge for å få endret en linje i konfigurasjonen til applikasjonen din på testserveren. (Det er en teori om at det er viktig for administratorer å føle seg viktige i prosjektet; hvis de ikke blir bedt om å endre linjer i konfigurasjonene, vil de rett og slett ikke være nødvendige). Vel, som alltid, er det ikke praktisk? Dette blir fort kjedelig, etter en direkte samtale med admin finner vi ut at utviklerne ble født til å skrive dårlig kode, er av natur inkompetente individer og det er bedre å holde dem unna produksjon. Men her også fra testservere, for sikkerhets skyld. Konflikten eskalerer raskt. Det er ingen kommunikasjon med admin. Situasjonen forverres av at han er alene. Følgende er et typisk bilde. Utgivelse. Visse funksjoner fungerer ikke. Det tar oss lang tid å finne ut hva som skjer, ulike ideer fra utviklere blir kastet inn i chatten, men administratoren i en slik situasjon antar vanligvis at utviklerne har skylden. Så skriver han i chatten, vent, jeg korrigerte ham. Når vi blir bedt om å legge igjen en historie med informasjon om hva problemet var, får vi giftige unnskyldninger. Som, ikke stikk nesen der den ikke hører hjemme. Utviklere må skrive kode. Situasjonen når mange kroppsbevegelser i et prosjekt går gjennom én enkelt person og bare han har tilgang til å utføre operasjonene alle trenger er ekstremt trist. En slik person er en forferdelig flaskehals. Hvis Devops-ideer streber etter å redusere time-to-market, er slike mennesker den verste fienden til Devops-ideene. Dessverre lukkes gardinen her.
PS Etter å ha snakket litt om utviklere vs administratorer i chatter med folk, møtte jeg folk som delte smerten min. Men det var også de som sa at de aldri hadde vært borti noe lignende. På en devops-konferanse spurte jeg Anton Isanin (Alfa Bank) hvordan de taklet problemet med flaskehalsen i form av administratorer, som han sa til: "Vi erstattet dem med knapper." Forresten med hans deltakelse. Jeg vil tro at det er mange flere gode admins enn fiender. Og ja, bildet i begynnelsen er en ekte korrespondanse.
Kilde: www.habr.com