Ontwikkelaars is van Mars, admins is van Venus

Toevallighede is lukraak, en dit was inderdaad op 'n ander planeet ...

Ek wil graag drie sukses- en mislukkingsverhale deel oor hoe 'n backend-ontwikkelaar in 'n span met admins werk.

Storie een.
Webateljee, die aantal werknemers kan met een hand getel word. Vandag is jy 'n uitlegontwerper, môre is jy 'n backender, oormôre is jy 'n admin. Aan die een kant kan jy geweldige ervaring opdoen. Aan die ander kant is daar 'n gebrek aan bevoegdheid op alle terreine. Ek onthou nog die eerste dag van werk, ek is nog groen, die baas sê: "Open stopverf," maar ek weet nie wat dit is nie. Kommunikasie met admins is uitgesluit, want jy is self 'n admin. Kom ons kyk na die voor- en nadele van hierdie situasie.

+ Alle mag is in jou hande.
+ Dit is nie nodig om iemand te smeek vir toegang tot die bediener nie.
+ Vinnige reaksietyd in alle rigtings.
+ Verbeter vaardighede goed.
+ Het 'n volledige begrip van die produkargitektuur.

- Hoë verantwoordelikheid.
— Risiko om produksie te breek.
— Dit is moeilik om 'n goeie spesialis op alle gebiede te wees.

Stel nie belang nie, kom ons gaan aan

Die tweede storie.
Groot maatskappy, groot projek. Daar is 'n administrasie-afdeling met 5-7 werknemers en verskeie ontwikkelingsgroepe. Wanneer jy in so 'n maatskappy kom werk, dink elke admin dat jy nie hierheen gekom het om aan 'n produk te werk nie, maar om iets te breek. Nie die getekende NDA of die keuring by die onderhoud dui anders nie. Nee, hierdie man het met sy vuil handjies hierheen gekom om ons soenproduksie te verwoes. Daarom, met so 'n persoon het jy 'n minimum van kommunikasie nodig; ten minste kan jy 'n plakker gooi in reaksie. Moenie vrae oor die projekargitektuur beantwoord nie. Dit is raadsaam om nie toegang te verleen totdat die spanleier dit vra nie. En wanneer hy vra, sal hy dit teruggee met nog minder voorregte as waarvoor hulle gevra het. Byna alle kommunikasie met sulke admins word geabsorbeer deur die swart gat tussen die ontwikkelingsdepartement en die administrasieafdeling. Dit is onmoontlik om probleme dadelik op te los. Maar jy kan nie persoonlik kom nie - die admins is 24/7 te besig. (Wat doen jy heeltyd?) Enkele prestasie-eienskappe:

• Gemiddelde ontplooiingstyd in produksie is 4-5 uur
• Maksimum ontplooiingstyd in produksie 9 uur
• Vir 'n ontwikkelaar is 'n toepassing in produksie 'n swart boks, net soos die produksiebediener self. Hoeveel is daar in totaal?
• Lae kwaliteit van vrystellings, gereelde foute
• Die ontwikkelaar neem nie deel aan die vrystellingsproses nie

Wel, wat het ek verwag, natuurlik word nuwe mense nie in produksie toegelaat nie. Wel, goed, nadat ons geduld opgedoen het, begin ons die vertroue van ander kry. Maar om een ​​of ander rede is dinge nie so eenvoudig met admins nie.

Wet 1. Die admin is onsigbaar.
Vrystellingsdag, ontwikkelaar en admin kommunikeer nie. Die admin het geen vrae nie. Maar jy verstaan ​​later hoekom. Die admin is 'n beginselvaste persoon, het nie boodskappers nie, gee nie sy telefoonnommer aan iemand uit nie en het nie 'n profiel op sosiale netwerke nie. Daar is nie eers 'n foto van hom iewers nie, hoe lyk jy ou? Ons sit met die verantwoordelike bestuurder vir so 15 minute in verbystering en probeer kommunikasie met hierdie Voyager 1 bewerkstellig, dan verskyn 'n boodskap in die korporatiewe e-pos dat hy klaar is. Gaan ons per pos korrespondeer? Hoekom nie? Gerieflik, is dit nie? Wel, goed, kom ons koel af. Die proses is reeds aan die gang, daar is geen omdraaikans nie. Lees die boodskap weer. "Ek het klaar gemaak". Wat het jy klaargemaak? Waar? Waar moet ek jou soek? Hier verstaan ​​jy hoekom 4 uur vir vrylating normaal is. Ons kry 'n ontwikkelingskok, maar ons voltooi die vrystelling. Daar is nie meer enige begeerte om vry te laat nie.

Wet 2. Nie daardie weergawe nie.
Die volgende vrystelling. Nadat ons ondervinding opgedoen het, begin ons om lyste van die nodige sagteware en biblioteke vir die bediener vir administrateurs te skep, wat die weergawes vir sommige aandui. Soos altyd ontvang ons 'n swak radiosein dat die admin iets daar klaargemaak het. Die regressietoets begin, wat self ongeveer 'n uur neem. Dit lyk of alles werk, maar daar is een kritieke fout. Belangrike funksionaliteit werk nie. Die volgende paar ure was dans met tamboeryne, waarsêery op koffiegronde, en 'n gedetailleerde oorsig van elke stukkie kode. Die admin sê hy het alles gedoen. Die toepassing wat deur krom ontwikkelaars geskryf is, werk nie, maar die bediener werk. Enige vrae vir hom? Aan die einde van 'n uur kry ons die admin om die weergawe van die biblioteek op die produksiebediener na die klets en bingo te stuur - dit is nie die een wat ons nodig het nie. Ons vra die administrateur om die vereiste weergawe te installeer, maar in reaksie ontvang ons dat hy dit nie kan doen nie weens die afwesigheid van hierdie weergawe in die OS-pakketbestuurder. Hier, uit die spasies van sy geheue, onthou die bestuurder dat 'n ander admin reeds hierdie probleem opgelos het deur bloot die vereiste weergawe met die hand saam te stel. Maar nee, ons s'n sal dit nie doen nie. Die regulasies verbied. Karl, ons sit al etlike ure hier, wat is die tydsbeperking?! Ons kry nog 'n skok en maak op een of ander manier die vrystelling klaar.

Wet 3, kort
Dringende kaartjie, sleutelfunksies werk nie vir een van die gebruikers in produksie nie. Ons spandeer 'n paar uur om te steek en na te gaan. In 'n ontwikkelingsomgewing werk alles. Daar is 'n duidelike begrip dat dit 'n goeie idee sal wees om na die php-fpm logs te kyk. Daar was op daardie stadium geen logstelsels soos ELK of Prometheus op die projek nie. Ons maak 'n kaartjie oop na die administrasie afdeling sodat hulle toegang gee tot die php-fpm logs op die bediener. Hier moet jy verstaan ​​dat ons vir 'n rede om toegang vra, onthou jy nie van die swart gat en admins wat 24/7 besig is nie? As jy hulle vra om self na die logs te kyk, dan is dit 'n taak met 'n "nie in hierdie lewe"-prioriteit. Die kaartjie is geskep, ons het 'n onmiddellike reaksie van die hoof van die administrasieafdeling ontvang: "Jy hoef nie toegang tot produksielogboeke nodig te hê nie, skryf sonder foute." ’n Gordyn.

Wet 4 en verder
Ons is steeds besig om tientalle probleme in produksie in te samel, as gevolg van verskillende weergawes van biblioteke, ongekonfigureerde sagteware, onvoorbereide bedienerladings en ander probleme. Natuurlik is daar ook kodefoute, ons sal nie die admins blameer vir al die sondes nie, ons sal net nog een tipiese operasie vir daardie projek noem. Ons het nogal baie agtergrondwerkers gehad wat deur die toesighouer bekendgestel is, en sommige skrifte moes by cron gevoeg word. Soms het hierdie selfde werkers opgehou werk. Die las op die toubediener het blitsvinnig gegroei, en hartseer gebruikers het na die draaiende laaier gekyk. Om sulke werkers vinnig reg te maak, was dit genoeg om hulle eenvoudig weer te begin, maar weereens kon net 'n administrateur dit doen. Terwyl so 'n basiese operasie uitgevoer word, kon 'n hele dag verbygaan. Hier is dit natuurlik opmerklik dat skewe programmeerders werkers moet skryf sodat hulle nie verongeluk nie, maar wanneer hulle wel val, sal dit lekker wees om te verstaan ​​hoekom, wat soms onmoontlik is weens die gebrek aan toegang tot produksie, van natuurlik, en as gevolg daarvan, die gebrek aan logs van die ontwikkelaar.

Transfigurasie.
Nadat ons dit alles vir 'n lang tyd verduur het, het ons saam met die span in 'n rigting begin stuur wat vir ons meer suksesvol was. Om op te som, watter probleme het ons in die gesig gestaar?

• Gebrek aan kwaliteit kommunikasie tussen ontwikkelaars en administrasie afdeling
• Administrateurs, blyk dit(!), verstaan ​​glad nie hoe die toepassing gestruktureer is, watter afhanklikhede dit het en hoe dit werk nie.
• Ontwikkelaars verstaan ​​nie hoe die produksie-omgewing werk nie en kan gevolglik nie effektief op probleme reageer nie.
• Die ontplooiingsproses neem te lank.
• Onstabiele vrystellings.

Wat het ons gedoen?
Vir elke vrystelling is 'n lys vrystellingsnotas gegenereer, wat 'n lys van werk ingesluit het wat op die bediener gedoen moet word vir die volgende vrystelling om te werk. Die lys het verskeie afdelings bevat, werk wat deur die administrateur, die persoon verantwoordelik vir die vrystelling en die ontwikkelaar uitgevoer moet word. Ontwikkelaars het nie-worteltoegang tot alle produksiebedieners gekry, wat ontwikkeling in die algemeen en probleemoplossing in die besonder bespoedig het. Ontwikkelaars het ook 'n begrip van hoe produksie werk, in watter dienste dit verdeel is, waar en hoeveel replikas kos. Sommige van die gevegsladings het duideliker geword, wat ongetwyfeld die kwaliteit van die kode beïnvloed. Kommunikasie tydens die vrystellingsproses het plaasgevind in die klets van een van die kitsboodskappers. Eerstens het ons 'n log van alle aksies gehad, en tweedens het kommunikasie in 'n nader omgewing plaasgevind. Om 'n geskiedenis van aksies te hê, het meer as een keer nuwe werknemers toegelaat om probleme vinniger op te los. Dit is 'n paradoks, maar dit het dikwels die admins self gehelp. Ek sal nie onderneem om seker te sê nie, maar dit lyk vir my of admins meer begin verstaan ​​het hoe die projek werk en hoe dit geskryf is. Soms het ons selfs 'n paar besonderhede met mekaar gedeel. Die gemiddelde vrystellingstyd is tot 'n uur verminder. Soms was ons binne 30-40 minute klaar. Die aantal goggas het aansienlik afgeneem, indien nie tienvoudig nie. Natuurlik het ander faktore ook die vermindering in vrystellingstyd beïnvloed, soos outotoetse. Na elke vrystelling het ons terugskouings begin doen. Sodat die hele span 'n idee het van wat nuut is, wat verander is en wat verwyder is. Ongelukkig het admins nie altyd na hulle toe gekom nie, wel, admins is besig... My werksbevrediging as ontwikkelaar het ongetwyfeld toegeneem. Wanneer jy byna enige probleem wat in jou bevoegdheidsgebied is vinnig kan oplos, voel jy bo. Later sal ek verstaan ​​dat ons in 'n mate 'n devops-kultuur ingebring het, natuurlik nie heeltemal nie, maar selfs daardie begin van die transformasie was indrukwekkend.

Storie drie
Opstart. Een administrateur, klein ontwikkelingsafdeling. Met aankoms is ek heeltemal nul, want... Ek het nêrens toegang behalwe vanaf die pos nie. Ons skryf aan die admin en vra vir toegang. Daarbenewens is daar inligting dat hy bewus is van die nuwe werknemer en die behoefte om logins/wagwoorde uit te reik. Hulle gee toegang vanaf die bewaarplek en VPN. Hoekom toegang gee tot wiki, teamcity, rundesk? Nuttelose dinge vir 'n persoon wat geroep is om die hele agterkant deel te skryf. Eers met verloop van tyd kry ons toegang tot sommige gereedskap. Die aankoms is natuurlik met wantroue begroet. Ek probeer stadigaan 'n gevoel kry vir hoe die projek se infrastruktuur werk deur geselsies en leidende vrae. Ek herken basies niks. Produksie is dieselfde swart boks as voorheen. Maar meer as dit, selfs die verhoogbedieners wat vir toetsing gebruik word, is 'n swart boks. Ons kan niks anders doen as om 'n tak vanaf Git daar te ontplooi nie. Ons kan ook nie ons toepassing opstel soos .env-lêers nie. Toegang vir sulke operasies word nie verleen nie. Jy moet smeek om 'n reël in die konfigurasie van jou toepassing op die toetsbediener te verander. (Daar is 'n teorie dat dit noodsaaklik is vir admins om hulself belangrik te voel vir die projek; as hulle nie gevra word om lyne in die konfigurasies te verander nie, sal dit eenvoudig nie nodig wees nie). Wel, soos altyd, is dit nie gerieflik nie? Dit raak vinnig vervelig, na 'n direkte gesprek met die admin vind ons uit dat die ontwikkelaars gebore is om slegte kode te skryf, van nature onbekwame individue is en dit is beter om hulle weg te hou van produksie. Maar hier ook van toetsbedieners, net vir ingeval. Die konflik eskaleer vinnig. Daar is geen kommunikasie met die admin nie. Die situasie word vererger deur die feit dat hy alleen is. Die volgende is 'n tipiese prentjie. Vrylating. Sekere funksionaliteit werk nie. Dit neem ons lank om uit te vind wat aangaan, verskeie idees van ontwikkelaars word in die klets gegooi, maar die admin in so 'n situasie neem gewoonlik aan dat die ontwikkelaars die skuld kry. Dan skryf hy in die chat, wag, ek het hom reggemaak. Wanneer ons gevra word om 'n storie agter te laat met inligting oor wat die probleem was, ontvang ons giftige verskonings. Soos, moenie jou neus steek waar dit nie hoort nie. Ontwikkelaars moet kode skryf. Die situasie wanneer baie liggaamsbewegings in 'n projek deur een enkele persoon gaan en net hy toegang het om die operasies uit te voer wat almal nodig het, is uiters hartseer. So 'n persoon is 'n verskriklike bottelnek. As Devops-idees daarna streef om tyd-tot-mark te verminder, dan is sulke mense die ergste vyand van Devops-idees. Ongelukkig maak die gordyn hier toe.

NS Nadat ek 'n bietjie oor ontwikkelaars vs admins in geselsies met mense gepraat het, het ek mense ontmoet wat my pyn gedeel het. Maar daar was ook diegene wat gesê het dat hulle nog nooit so iets teëgekom het nie. Op een devops-konferensie het ek vir Anton Isanin (Alfa Bank) gevra hoe hulle die probleem van die bottelnek in die vorm van admins hanteer het, waarop hy gesê het: "Ons het hulle met knoppies vervang." Terloops podcast met sy deelname. Ek wil graag glo dat daar baie meer goeie admins as vyande is. En ja, die prentjie aan die begin is 'n ware korrespondensie.

Bron: www.habr.com