Utvecklare är från Mars, administratörer är från Venus

Tillfälligheter är slumpmässiga, och det var faktiskt på en annan planet...

Jag skulle vilja dela tre framgångs- och misslyckandehistorier om hur en backend-utvecklare arbetar i ett team med administratörer.

Historia först.
Webstudio, antalet anställda kan räknas med en hand. Idag är du layoutdesigner, imorgon är du backender, i övermorgon är du admin. Å ena sidan kan du få enorm erfarenhet. Däremot saknas kompetens inom alla områden. Jag minns fortfarande den första arbetsdagen, jag är fortfarande grön, chefen säger: "Öppna kitt", men jag vet inte vad det är. Kommunikation med administratörer är utesluten, eftersom du är själv administratör. Låt oss överväga fördelarna och nackdelarna med denna situation.

+ All makt ligger i dina händer.
+ Det finns ingen anledning att tigga någon om åtkomst till servern.
+ Snabb reaktionstid i alla riktningar.
+ Förbättrar färdigheter väl.
+ Ha en fullständig förståelse för produktarkitekturen.

– Högt ansvar.
— Risk för produktionsavbrott.
– Det är svårt att vara en bra specialist på alla områden.

Inte intresserad, låt oss gå vidare

Den andra historien.
Stort företag, stort projekt. Det finns en förvaltningsavdelning med 5-7 anställda och flera utvecklingsgrupper. När du kommer för att arbeta i ett sådant företag, tror varje administratör att du inte kom hit för att arbeta med en produkt, utan för att bryta något. Varken den undertecknade NDA eller urvalet vid intervjun tyder på något annat. Nej, den här mannen kom hit med sina smutsiga små händer för att förstöra vår kyssproduktion. Därför, med en sådan person behöver du ett minimum av kommunikation; åtminstone kan du kasta ett klistermärke som svar. Svara inte på frågor om projektarkitekturen. Det är tillrådligt att inte bevilja åtkomst förrän gruppledaren frågar. Och när han frågar kommer han att ge tillbaka det med ännu färre privilegier än de bad om. Nästan all kommunikation med sådana administratörer absorberas av det svarta hålet mellan utvecklingsavdelningen och administrationsavdelningen. Det är omöjligt att lösa problem snabbt. Men du kan inte komma personligen - administratörerna är för upptagna 24/7. (Vad gör du hela tiden?) Några prestandaegenskaper:

• Genomsnittlig driftsättningstid i produktionen är 4-5 timmar
• Maximal driftsättningstid i produktion 9 timmar
• För en utvecklare är en applikation i produktion en svart låda, precis som själva produktionsservern. Hur många är det totalt?
• Låg kvalitet på utgåvor, frekventa fel
• Utvecklaren deltar inte i releaseprocessen

Nåväl, vad hade jag förväntat mig, förstås, nya personer släpps inte in i produktionen. Nåväl, okej, efter att ha fått tålamod börjar vi få andras förtroende. Men av någon anledning är det inte så enkelt med administratörer.

Akt 1. Administratören är osynlig.
Releasedag, utvecklare och administratör kommunicerar inte. Administratören har inga frågor. Men du förstår varför senare. Administratören är en principfast person, har inga budbärare, ger inte ut sitt telefonnummer till någon och har ingen profil på sociala nätverk. Det finns inte ens ett foto på honom någonstans, hur ser du ut? Vi sitter med ansvarig chef i cirka 15 minuter i förvirring och försöker etablera kommunikation med denna Voyager 1, sedan dyker det upp ett meddelande i företagets mejl att han är klar. Kommer vi att korrespondera via post? Varför inte? Bekvämt, eller hur? Okej, låt oss svalka oss. Processen är redan igång, det finns ingen återvändo. Läs meddelandet igen. "Jag slutade". Vad gjorde du färdigt? Var? Var ska jag leta efter dig? Här förstår du varför 4 timmar för release är normalt. Vi får en utvecklingschock, men vi avslutar releasen. Det finns inte längre någon önskan att släppa.

Akt 2. Inte den versionen.
Nästa release. Efter att ha fått erfarenhet börjar vi skapa listor över nödvändig programvara och bibliotek för servern för administratörer, och anger versionerna för vissa. Som alltid får vi en svag radiosignal om att admin har gjort klart något där. Regressionstestet börjar, vilket i sig tar ungefär en timme. Allt verkar fungera, men det finns en kritisk bugg. Viktig funktion fungerar inte. De närmaste timmarna var dans med tamburiner, spådomar på kaffesump och en detaljerad genomgång av varje kod. Administratören säger att han har gjort allt. Applikationen skriven av sneda utvecklare fungerar inte, men servern fungerar. Några frågor till honom? I slutet av en timme får vi administratören att skicka versionen av biblioteket på produktionsservern till chatten och bingon - det är inte den vi behöver. Vi ber administratören att installera den version som krävs, men som svar får vi att han inte kan göra detta på grund av frånvaron av denna version i OS-pakethanteraren. Här, från fördjupningarna i sitt minne, minns chefen att en annan administratör redan hade löst detta problem genom att helt enkelt montera den nödvändiga versionen för hand. Men nej, vår kommer inte att göra detta. Reglerna förbjuder. Karl, vi har suttit här i flera timmar, vad är tidsgränsen?! Vi får ytterligare en chock och avslutar på något sätt släppet.

Akt 3, kort
Brådskande biljett, nyckelfunktioner fungerar inte för en av användarna i produktionen. Vi ägnar ett par timmar åt att peta och kolla. I en utvecklingsmiljö fungerar allt. Det finns en klar förståelse för att det skulle vara en bra idé att titta i php-fpm-loggarna. Det fanns inga loggsystem som ELK eller Prometheus i projektet vid den tiden. Vi öppnar en biljett till administrationsavdelningen så att de ger tillgång till php-fpm-loggarna på servern. Här måste du förstå att vi ber om tillgång av en anledning, minns du inte om det svarta hålet och att administratörer är upptagna 24/7? Om du ber dem att titta på själva loggarna är detta en uppgift med en "inte i det här livet" prioritet. Biljetten skapades, vi fick ett omedelbart svar från chefen för administrationsavdelningen: "Du ska inte behöva tillgång till produktionsloggar, skriv utan buggar." En gardin.

Akt 4 och därefter
Vi samlar fortfarande in dussintals problem i produktionen, på grund av olika versioner av bibliotek, okonfigurerad programvara, oförberedda serverladdningar och andra problem. Naturligtvis finns det också kodbuggar, vi kommer inte att skylla på administratörerna för alla synder, vi kommer bara att nämna en mer typisk operation för det projektet. Vi hade ganska många bakgrundsarbetare som lanserades genom handledaren, och några skript måste läggas till cron. Ibland slutade samma arbetare att arbeta. Belastningen på köservern växte blixtsnabbt och ledsna användare tittade på den snurrande lastaren. För att snabbt fixa sådana arbetare räckte det med att helt enkelt starta om dem, men återigen, bara en administratör kunde göra detta. Medan en sådan grundläggande operation utfördes kunde en hel dag gå. Här är det förstås värt att notera att sneda programmerare bör skriva arbetare så att de inte kraschar, men när de väl faller skulle det vara skönt att förstå varför, vilket ibland är omöjligt på grund av bristen på tillgång till produktion, av naturligtvis, och som en konsekvens, bristen på loggar från utvecklaren.

Transfiguration.
Efter att ha uthärdat allt detta ganska länge började vi tillsammans med teamet styra i en riktning som var mer framgångsrik för oss. För att sammanfatta, vilka problem stod vi inför?

• Brist på kvalitetskommunikation mellan utvecklare och administrationsavdelning
• Administratörer, visar det sig(!), förstår inte alls hur applikationen är uppbyggd, vilka beroenden den har och hur den fungerar.
• Utvecklare förstår inte hur produktionsmiljön fungerar och kan som ett resultat inte svara på problem effektivt.
• Implementeringsprocessen tar för lång tid.
• Instabila utgåvor.

Vad har vi gjort?
För varje release genererades en lista med Release Notes, som innehöll en lista över arbete som måste göras på servern för att nästa release ska fungera. Listan innehöll flera avsnitt, arbete som bör utföras av administratören, den som ansvarar för releasen och utvecklaren. Utvecklare fick icke-root-åtkomst till alla produktionsservrar, vilket påskyndade utvecklingen i allmänhet och problemlösningen i synnerhet. Utvecklare har också en förståelse för hur produktionen fungerar, vilka tjänster den är uppdelad i, var och hur mycket kopior kostar. En del av stridsbelastningarna har blivit tydligare, vilket utan tvekan påverkar kodens kvalitet. Kommunikation under släppprocessen skedde i chatten hos en av snabbmeddelandena. För det första hade vi en logg över alla handlingar, och för det andra skedde kommunikationen i en närmare miljö. Att ha en historia av handlingar har mer än en gång gjort det möjligt för nya medarbetare att lösa problem snabbare. Det är en paradox, men det här hjälpte ofta administratörerna själva. Jag kommer inte att åta mig att säga det säkert, men det verkar för mig som administratörer har börjat förstå mer hur projektet fungerar och hur det är skrivet. Ibland delade vi till och med några detaljer med varandra. Den genomsnittliga utgivningstiden har reducerats till en timme. Ibland var vi klara på 30-40 minuter. Antalet buggar har minskat avsevärt, om inte tiodubblats. Naturligtvis påverkade även andra faktorer minskningen av releasetiden, såsom autotester. Efter varje release började vi genomföra retrospektiv. Så att hela teamet har en uppfattning om vad som är nytt, vad som har ändrats och vad som har tagits bort. Tyvärr kom det inte alltid admins till dem, ja, admins är upptagna... Min arbetsglädje som utvecklare har utan tvekan ökat. När du snabbt kan lösa nästan alla problem som ligger inom ditt kompetensområde känner du dig på topp. Senare kommer jag att förstå att vi i viss mån införde en devops-kultur, inte helt förstås, men även den början av förvandlingen var imponerande.

Berättelse tre
Börja. En admin, liten utvecklingsavdelning. Vid ankomsten är jag helt noll, för... Jag har ingen tillgång någonstans förutom från posten. Vi skriver till admin och ber om åtkomst. Dessutom finns information om att han känner till den nyanställde och behovet av att utfärda inloggningar/lösenord. De ger åtkomst från förvaret och VPN. Varför ge tillgång till wiki, teamcity, rundesk? Värdelösa saker för en person som kallades att skriva hela backend-delen. Först med tiden får vi tillgång till vissa verktyg. Ankomsten möttes förstås av misstro. Jag försöker sakta få en känsla för hur projektets infrastruktur fungerar genom chattar och ledande frågor. Jag känner i princip ingenting. Tillverkningen är samma svarta låda som tidigare. Men mer än det, även scenservrarna som används för testning är en svart låda. Vi kan inte göra något annat än att distribuera en filial från Git där. Vi kan inte heller konfigurera vår applikation som .env-filer. Tillträde för sådan verksamhet beviljas inte. Du måste tigga för att få en rad ändrad i konfigurationen av din applikation på testservern. (Det finns en teori om att det är viktigt för administratörer att känna sig viktiga i projektet; om de inte ombeds att ändra rader i konfigurationerna kommer de helt enkelt inte att behövas). Tja, som alltid, är det inte bekvämt? Detta blir snabbt tråkigt, efter ett direkt samtal med admin får vi reda på att utvecklarna föddes för att skriva dålig kod, är till sin natur inkompetenta individer och det är bättre att hålla dem borta från produktionen. Men här också från testservrar, för säkerhets skull. Konflikten eskalerar snabbt. Det finns ingen kommunikation med administratören. Situationen förvärras av att han är ensam. Följande är en typisk bild. Släpp. Viss funktionalitet fungerar inte. Det tar oss lång tid att ta reda på vad som händer, olika idéer från utvecklare slängs in i chatten, men administratören i en sådan situation antar vanligtvis att utvecklarna är skyldiga. Sedan skriver han i chatten, vänta, jag rättade honom. När vi uppmanas att lämna en historia bakom oss med information om vad problemet var, får vi giftiga ursäkter. Som, stick inte näsan där den inte hör hemma. Utvecklare måste skriva kod. Situationen när många kroppsrörelser i ett projekt går igenom en enda person och bara han har tillgång att utföra de operationer alla behöver är extremt sorglig. En sådan person är en fruktansvärd flaskhals. Om Devops idéer strävar efter att minska tiden till marknad, då är sådana människor den värsta fienden till Devops idéer. Tyvärr stängs ridån här.

PS Efter att ha pratat lite om utvecklare vs administratörer i chattar med människor, träffade jag människor som delade min smärta. Men det fanns också de som sa att de aldrig varit med om något liknande. På en devops-konferens frågade jag Anton Isanin (Alfa Bank) hur de hanterade problemet med flaskhalsen i form av administratörer, till vilka han sa: "Vi ersatte dem med knappar." Förresten podcast med hans medverkan. Jag skulle vilja tro att det finns många fler bra administratörer än fiender. Och ja, bilden i början är en riktig korrespondens.

Källa: www.habr.com