Toevalligheden zijn willekeurig, en het was inderdaad op een andere planeet...
Ik wil graag drie succes- en faalverhalen delen over hoe een backend-ontwikkelaar in een team met beheerders werkt.
Geschiedenis eerst.
Webstudio, het aantal medewerkers is met één hand te tellen. Vandaag ben je lay-outontwerper, morgen backender, overmorgen admin. Aan de ene kant kun je een enorme ervaring opdoen. Aan de andere kant is er op alle gebieden een gebrek aan competentie. Ik herinner me nog de eerste werkdag, ik ben nog groen, de baas zegt: "Open stopverf", maar ik weet niet wat het is. Communicatie met beheerders is uitgesloten, omdat je bent zelf beheerder. Laten we de voor- en nadelen van deze situatie eens bekijken.
+ Alle macht ligt in jouw handen.
+ Het is niet nodig om iemand om toegang tot de server te smeken.
+ Snelle reactietijd in alle richtingen.
+ Verbetert vaardigheden goed.
+ Een volledig begrip hebben van de productarchitectuur.
– Hoge verantwoordelijkheid.
— Risico op productieonderbreking.
— Het is moeilijk om op alle gebieden een goede specialist te zijn.
Geen interesse, laten we verder gaan
Het tweede verhaal.
Groot bedrijf, groot project. Er is een afdeling administratie met 5-7 medewerkers en meerdere ontwikkelgroepen. Als je bij zo’n bedrijf komt werken, denkt iedere beheerder dat je hier niet bent gekomen om aan een product te werken, maar om iets kapot te maken. Noch uit de ondertekende geheimhoudingsverklaring, noch uit de selectie bij het interview blijkt iets anders. Nee, deze man kwam hier met zijn vieze handjes om onze zoenproductie te verpesten. Daarom heb je met zo iemand een minimum aan communicatie nodig, je kunt op zijn minst een sticker als reactie erop gooien. Beantwoord geen vragen over de projectarchitectuur. Het is raadzaam om pas toegang te verlenen als de teamleider erom vraagt. En als hij erom vraagt, zal hij het teruggeven met nog minder privileges dan waar ze om vroegen. Bijna alle communicatie met dergelijke beheerders wordt geabsorbeerd door het zwarte gat tussen de ontwikkelingsafdeling en de beheerafdeling. Het is onmogelijk om problemen snel op te lossen. Maar je kunt niet persoonlijk komen - de beheerders hebben het 24/7 te druk. (Wat ben je de hele tijd aan het doen?) Enkele prestatiekenmerken:
- De gemiddelde implementatietijd in productie is 4-5 uur
- Maximale inzettijd in productie 9 uur
- Voor een ontwikkelaar is een applicatie in productie een black box, net als de productieserver zelf. Hoeveel zijn het er in totaal?
- Lage kwaliteit van releases, frequente fouten
- De ontwikkelaar neemt niet deel aan het releaseproces
Nou, wat had ik natuurlijk verwacht, nieuwe mensen mogen niet in de productie. Nou, oké, nadat we geduld hebben gekregen, beginnen we het vertrouwen van anderen te winnen. Maar om de een of andere reden is het bij beheerders niet zo eenvoudig.
Akte 1. De beheerder is onzichtbaar.
Releasedag, ontwikkelaar en beheerder communiceren niet. De beheerder heeft geen vragen. Maar waarom begrijp je later. De beheerder is een principieel persoon, heeft geen boodschappers, geeft zijn telefoonnummer aan niemand door en heeft geen profiel op sociale netwerken. Er is nergens een foto van hem, hoe zie jij eruit kerel? We zitten verbijsterd ongeveer 15 minuten bij de verantwoordelijke manager en proberen communicatie tot stand te brengen met deze Voyager 1, waarna er een bericht verschijnt in de zakelijke e-mail dat hij klaar is. Gaan we per post corresponderen? Waarom niet? Handig, nietwaar? Nou, oké, laten we afkoelen. Het proces is al aan de gang, er is geen weg meer terug. Lees het bericht nog eens. "Ik ben klaar". Wat heb je klaar? Waar? Waar moet ik je zoeken? Hier begrijp je waarom 4 uur voor vrijgave normaal is. We krijgen een ontwikkelingsschok, maar we maken de release af. Er is geen verlangen meer om los te laten.
Akte 2. Niet die versie.
De volgende uitgave. Nadat we ervaring hebben opgedaan, beginnen we lijsten te maken van de benodigde software en bibliotheken voor de server voor beheerders, met vermelding van de versies voor sommigen. Zoals altijd krijgen we een zwak radiosignaal dat de beheerder daar iets heeft afgerond. De regressietest begint, die op zichzelf ongeveer een uur duurt. Alles lijkt te werken, maar er is één kritieke bug. Belangrijke functionaliteit werkt niet. De volgende uren waren dansen met tamboerijnen, waarzeggerij op koffiedik en een gedetailleerd overzicht van elk stukje code. De beheerder zegt dat hij alles heeft gedaan. De applicatie geschreven door corrupte ontwikkelaars werkt niet, maar de server werkt. Heeft u vragen voor hem? Na een uur laten we de beheerder de versie van de bibliotheek op de productieserver naar de chat en bingo sturen - dit is niet degene die we nodig hebben. We vragen de beheerder om de benodigde versie te installeren, maar als reactie krijgen we dat hij dit niet kan doen vanwege het ontbreken van deze versie in de OS-pakketbeheerder. Hier herinnert de manager zich vanuit de diepten van zijn geheugen dat een andere beheerder dit probleem al had opgelost door simpelweg de vereiste versie met de hand in elkaar te zetten. Maar nee, de onze zal dit niet doen. De regelgeving verbiedt. Karl, we zitten hier al een paar uur, wat is de tijdslimiet?! We krijgen nog een schok en maken op de een of andere manier de release af.
Akte 3, kort
Dringend ticket, sleutelfunctionaliteit werkt niet voor een van de gebruikers in productie. We zijn een paar uur bezig met porren en controleren. In een ontwikkelomgeving werkt alles. Er bestaat een duidelijk inzicht dat het een goed idee zou zijn om in de php-fpm-logboeken te kijken. Er waren op dat moment geen logsystemen zoals ELK of Prometheus in het project. We openen een ticket naar de administratieafdeling zodat zij toegang geven tot de php-fpm-logs op de server. Hier moet je begrijpen dat we om een reden om toegang vragen. Kun je je het zwarte gat niet herinneren en dat beheerders 24/7 bezig zijn? Als je ze vraagt om zelf naar de logs te kijken, dan is dit een taak met de prioriteit ‘niet in dit leven’. Het ticket is aangemaakt, we kregen onmiddellijk een reactie van het hoofd van de administratieafdeling: "Je zou geen toegang nodig moeten hebben tot productielogboeken, schrijf zonder bugs." Een gordijn.
Akte 4 en verder
We verzamelen nog steeds tientallen problemen in de productie, als gevolg van verschillende versies van bibliotheken, niet-geconfigureerde software, onvoorbereide serverbelastingen en andere problemen. Natuurlijk zijn er ook codefouten, we zullen de beheerders niet de schuld geven van alle zonden, we zullen alleen nog een typische bewerking voor dat project noemen. We hadden nogal wat achtergrondwerkers die via de supervisor werden gelanceerd, en sommige scripts moesten aan cron worden toegevoegd. Soms stopten dezelfde werknemers met werken. De belasting van de wachtrijserver groeide razendsnel en verdrietige gebruikers keken naar de draaiende lader. Om dergelijke werkers snel te repareren, was het voldoende om ze eenvoudigweg opnieuw op te starten, maar nogmaals, alleen een beheerder kon dit doen. Terwijl zo’n basisoperatie werd uitgevoerd, kon er een hele dag voorbijgaan. Hier is het natuurlijk de moeite waard om op te merken dat corrupte programmeurs werkers zo moeten schrijven dat ze niet crashen, maar als ze toch vallen, zou het leuk zijn om te begrijpen waarom, wat soms onmogelijk is vanwege het gebrek aan toegang tot de productie, van natuurlijk, en als gevolg daarvan het gebrek aan logbestanden van de ontwikkelaar.
Transfiguratie.
Nadat we dit allemaal een hele tijd hadden volgehouden, begonnen we samen met het team een richting in te slaan die voor ons succesvoller was. Kortom, met welke problemen werden we geconfronteerd?
- Gebrek aan kwaliteitscommunicatie tussen ontwikkelaars en beheerafdeling
- Beheerders, zo blijkt(!), begrijpen helemaal niet hoe de applicatie is opgebouwd, welke afhankelijkheden deze heeft en hoe deze werkt.
- Ontwikkelaars begrijpen niet hoe de productieomgeving werkt en kunnen daardoor niet effectief reageren op problemen.
- Het implementatieproces duurt te lang.
- Onstabiele releases.
Wat hebben we gedaan?
Voor elke release werd een lijst met Release Notes gegenereerd, met daarin een lijst met werk dat op de server moet worden gedaan om de volgende release te laten werken. De lijst bevatte verschillende secties, werk dat moest worden uitgevoerd door de beheerder, de persoon die verantwoordelijk was voor de release en de ontwikkelaar. Ontwikkelaars kregen niet-roottoegang tot alle productieservers, wat de ontwikkeling in het algemeen en het oplossen van problemen in het bijzonder versnelde. Ontwikkelaars hebben ook inzicht in hoe de productie werkt, in welke services deze is onderverdeeld, waar en hoeveel replica's kosten. Sommige gevechtsladingen zijn duidelijker geworden, wat ongetwijfeld de kwaliteit van de code beïnvloedt. De communicatie tijdens het releaseproces vond plaats in de chat van een van de instant messengers. Ten eerste hadden we een logboek van alle acties, en ten tweede vond de communicatie plaats in een nauwere omgeving. Het hebben van een geschiedenis van acties heeft nieuwe medewerkers meer dan eens in staat gesteld problemen sneller op te lossen. Het is een paradox, maar dit heeft de beheerders zelf vaak geholpen. Ik durf het niet met zekerheid te zeggen, maar het lijkt mij dat beheerders beter zijn gaan begrijpen hoe het project werkt en hoe het is geschreven. Soms deelden we zelfs enkele details met elkaar. De gemiddelde releasetijd is teruggebracht tot een uur. Soms waren we binnen 30-40 minuten klaar. Het aantal bugs is aanzienlijk afgenomen, zo niet vertienvoudigd. Uiteraard hebben ook andere factoren de verkorting van de releasetijd beïnvloed, zoals autotests. Na elke release begonnen we retrospectieven te houden. Zodat het hele team een idee heeft van wat er nieuw is, wat er veranderd is en wat er verwijderd is. Helaas kwamen er niet altijd beheerders langs, nou ja, beheerders hebben het druk... Mijn werkplezier als ontwikkelaar is ongetwijfeld toegenomen. Wanneer je vrijwel elk probleem dat binnen jouw competentiegebied ligt snel kunt oplossen, voel je je er bovenop. Later zal ik begrijpen dat we tot op zekere hoogte een devops-cultuur hebben geïntroduceerd, niet helemaal natuurlijk, maar zelfs dat begin van de transformatie was indrukwekkend.
Verhaal drie
Beginnen. Eén beheerder, kleine ontwikkelingsafdeling. Bij aankomst ben ik een complete nul, want... Ik heb nergens anders toegang dan via de mail. We schrijven naar de beheerder en vragen om toegang. Daarnaast is er informatie dat hij op de hoogte is van de nieuwe medewerker en de noodzaak om logins/wachtwoorden af te geven. Ze geven toegang vanuit de repository en VPN. Waarom toegang geven tot wiki, teamcity, rundesk? Nutteloze zaken voor iemand die werd geroepen om het hele backend-gedeelte te schrijven. Pas na verloop van tijd krijgen we toegang tot sommige tools. De komst werd uiteraard met wantrouwen ontvangen. Via chats en suggestieve vragen probeer ik langzaam een idee te krijgen van hoe de infrastructuur van het project werkt. Eigenlijk herken ik niets. De productie is dezelfde zwarte doos als voorheen. Maar meer dan dat: zelfs de stageservers die voor het testen worden gebruikt, zijn een zwarte doos. We kunnen niets anders doen dan daar een branch van Git inzetten. We kunnen onze applicatie ook niet configureren zoals .env-bestanden. Toegang voor dergelijke bewerkingen wordt niet verleend. U moet smeken om een regel gewijzigd te krijgen in de configuratie van uw applicatie op de testserver. (Er is een theorie dat het van vitaal belang is dat beheerders zich belangrijk voelen bij het project; als hen niet wordt gevraagd om regels in de configuraties te wijzigen, zullen ze eenvoudigweg niet nodig zijn). Nou, zoals altijd, is het niet handig? Dit wordt snel saai, na een direct gesprek met de beheerder komen we erachter dat de ontwikkelaars geboren zijn om slechte code te schrijven, van nature incompetente individuen zijn en dat het beter is om ze weg te houden van de productie. Maar hier ook van testservers, voor het geval dat. Het conflict escaleert snel. Er is geen communicatie met de beheerder. De situatie wordt verergerd door het feit dat hij alleen is. Het volgende is een typisch beeld. Uitgave. Bepaalde functionaliteit werkt niet. Het duurt lang voordat we erachter komen wat er aan de hand is, er worden verschillende ideeën van ontwikkelaars in de chat gegooid, maar de beheerder gaat er in zo'n situatie meestal van uit dat de ontwikkelaars de schuldige zijn. Dan schrijft hij in de chat: wacht, ik heb hem gecorrigeerd. Wanneer ons wordt gevraagd een verhaal achter te laten met informatie over wat het probleem was, krijgen we giftige excuses. Steek bijvoorbeeld je neus niet op plekken waar hij niet hoort. Ontwikkelaars moeten code schrijven. De situatie waarin veel lichaamsbewegingen in een project door één persoon gaan en alleen hij toegang heeft om de handelingen uit te voeren die iedereen nodig heeft, is buitengewoon triest. Zo iemand is een verschrikkelijk knelpunt. Als Devops-ideeën ernaar streven de time-to-market te verkorten, dan zijn zulke mensen de grootste vijand van Devops-ideeën. Helaas gaat hier het doek dicht.
PS Nadat ik in chats met mensen wat had gesproken over ontwikkelaars versus beheerders, ontmoette ik mensen die mijn pijn deelden. Maar er waren ook mensen die zeiden dat ze nog nooit zoiets hadden meegemaakt. Op een devops-conferentie vroeg ik Anton Isanin (Alfa Bank) hoe ze omgingen met het probleem van de bottleneck in de vorm van admins, waarop hij zei: “We hebben ze vervangen door knoppen.” Trouwens met zijn deelname. Ik zou graag willen geloven dat er veel meer goede beheerders zijn dan vijanden. En ja, de foto aan het begin is een echte correspondentie.
Bron: www.habr.com