Kokkusattumused on juhuslikud ja see oli tõepoolest teisel planeedil...
Tahaksin jagada kolme edu ja ebaõnnestumise lugu sellest, kuidas taustaarendaja töötab meeskonnas koos administraatoritega.
Lugu üks.
Veebistuudio, töötajate arvu saab ühe käega kokku lugeda. Täna oled küljendaja, homme backender, ülehomme admin. Ühest küljest võite saada tohutuid kogemusi. Teisalt napib kompetentsust kõikides valdkondades. Mäletan siiani esimest tööpäeva, olen endiselt roheline, ülemus ütleb: "Ava pahtel", aga ma ei tea, mis see on. Suhtlemine administraatoritega on välistatud, kuna sa oled ise admin. Mõelgem selle olukorra plusse ja miinuseid.
+ Kogu jõud on teie kätes.
+ Serverile juurdepääsu saamiseks pole vaja kedagi paluda.
+ Kiire reaktsiooniaeg igas suunas.
+ Parandab hästi oskusi.
+ Teil on täielik arusaam toote arhitektuurist.
— Suur vastutus.
— Tootmise purunemise oht.
— Raske on olla hea spetsialist kõigil aladel.
Pole huvitatud, lähme edasi
Teine lugu.
Suur firma, suur projekt. Seal on haldusosakond 5-7 töötajaga ja mitmed arendusgrupid. Sellisesse ettevõttesse tööle tulles arvab iga administraator, et sa ei tulnud siia toote kallal töötama, vaid selleks, et midagi lõhkuda. Ei allkirjastatud NDA ega intervjuul tehtud valik ei näita teisiti. Ei, see mees tuli siia oma väikeste räpaste kätega, et rikkuda meie suudlemisproduktsiooni. Seetõttu vajate sellise inimesega minimaalselt suhtlemist; vähemalt võite vastuseks visata kleebise. Ärge vastake küsimustele projekti arhitektuuri kohta. Soovitatav on mitte lubada juurdepääsu enne, kui meeskonna juht seda küsib. Ja kui ta küsib, annab ta selle tagasi veelgi vähemate privileegidega, kui nad küsisid. Peaaegu kogu suhtlus selliste administraatoritega neelab arendusosakonna ja haldusosakonna vahelise musta augu. Probleeme on võimatu kiiresti lahendada. Kuid te ei saa isiklikult tulla – administraatorid on ööpäevaringselt liiga hõivatud. (Mida sa kogu aeg teed?) Mõned jõudlusnäitajad:
- Keskmine kasutuselevõtu aeg tootmises on 4-5 tundi
- Maksimaalne kasutuselevõtu aeg tootmises 9 tundi
- Arendaja jaoks on tootmisrakendus must kast, nagu ka tootmisserver ise. Kui palju neid kokku on?
- Väljaannete madal kvaliteet, sagedased vead
- Arendaja ei osale väljalaskeprotsessis
No mis ma ootasin, uusi inimesi tootmisse ei lasta. Olgu, pärast kannatust hakkame võitma teiste usaldust. Kuid millegipärast pole administraatoritega asjad nii lihtsad.
Tegu 1. Administraator on nähtamatu.
Väljalaskepäev, arendaja ja administraator ei suhtle. Administraatoril pole küsimusi. Aga hiljem saate aru, miks. Administraator on põhimõttekindel inimene, tal pole sõnumitoojaid, ta ei anna kellelegi oma telefoninumbrit ja tal pole sotsiaalvõrgustikes profiili. Temast pole kuskil isegi fotot, milline sa välja näed, kutt? Istume koos vastutava juhiga umbes 15 minutit hämmeldunult ja proovime selle Voyager 1-ga sidet luua, seejärel ilmub ettevõtte meilisõnumisse teade, et ta on lõpetanud. Kas hakkame kirja teel kirjavahetust pidama? Miks mitte? Mugav, kas pole? No okei, jahutame maha. Protsess juba käib, tagasiteed pole. Lugege sõnum uuesti läbi. "Ma lõpetasin". Mida sa lõpetasid? Kuhu? Kust ma peaksin sind otsima? Siin saate aru, miks 4 tundi vabastamiseks on normaalne. Saame arendusšoki, kuid lõpetame väljalaske. Vabaneda pole enam tahtmist.
Seadus 2. Mitte see versioon.
Järgmine väljalase. Olles omandanud kogemusi, hakkame koostama administraatorite jaoks serveri jaoks vajaliku tarkvara ja raamatukogude loendeid, märkides mõne versiooni. Nagu ikka, saame nõrga raadiosignaali, et admin on seal midagi lõpetanud. Algab regressioonitest, mis ise võtab aega umbes tund. Tundub, et kõik töötab, kuid on üks kriitiline viga. Oluline funktsioon ei tööta. Järgmised paar tundi oli tantsimine parmupillidega, ennustamine kohvipaksu peal ja iga kooditüki üksikasjalik ülevaade. Administraator ütleb, et on kõik ära teinud. Vildakate arendajate kirjutatud rakendus ei tööta, aga server töötab. Kas on talle küsimusi? Tunni lõpus paneme administraatoril vestlusesse ja bingosse saatma tootmisserveris oleva teegi versiooni – see pole see, mida me vajame. Palume administraatoril installida vajalik versioon, kuid vastuseks saame, et ta ei saa seda teha, kuna see versioon puudub OS-i paketihalduris. Siinkohal meenub juhile oma mälusoppidest, et teine administraator oli selle probleemi juba lahendanud, monteerides vajaliku versiooni lihtsalt käsitsi kokku. Aga ei, meie oma seda ei tee. Määrused keelavad. Karl, me oleme siin juba mitu tundi istunud, mis ajalimiit on?! Saame järjekordse šoki ja lõpetame väljalaske kuidagi.
3. vaatus, lühike
Kiireloomuline pilet, võtmefunktsioonid ei tööta ühe tootmises oleva kasutaja puhul. Veedame paar tundi torkides ja kontrollides. Arenduskeskkonnas kõik toimib. On selge arusaam, et hea oleks uurida php-fpm logisid. Sel ajal ei olnud projektis palgisüsteeme nagu ELK või Prometheus. Avame pileti haldusosakonda, et nad annaksid juurdepääsu serveri php-fpm logidele. Siin peate mõistma, et me küsime juurdepääsu põhjusel, kas te ei mäleta musta augu ja administraatorite ööpäevaringset hõivatust? Kui palute neil palke ise vaadata, on see ülesanne, mille prioriteet on "mitte selles elus". Pilet oli loodud, saime haldusosakonna juhatajalt kohe vastuse: "Te ei tohiks vajada juurdepääsu tootmislogidele, kirjutage ilma vigadeta." Kardin.
4. tegu ja edasi
Tootmises kogume endiselt kümneid probleeme, mis on tingitud teekide erinevatest versioonidest, konfigureerimata tarkvarast, serverite ettevalmistamata laadimisest ja muudest probleemidest. Muidugi on ka koodivigu, me ei süüdista kõigis pattudes administraatoreid, vaid mainime lihtsalt üht tüüpilisemat selle projekti toimingut. Meil oli päris palju taustatöölisi, kes käivitati supervisori kaudu ja mõned skriptid tuli lisada cronile. Mõnikord lakkasid samad töötajad töötamast. Järjekorraserveri koormus kasvas välkkiirelt ja kurvad kasutajad vaatasid pöörlevat laadurit. Selliste töötajate kiireks parandamiseks piisas nende lihtsalt taaskäivitamisest, kuid jällegi sai seda teha ainult administraator. Sel ajal kui sellist põhioperatsiooni tehti, võis terve päev mööda minna. Siinkohal tasub muidugi märkida, et kõverad programmeerijad peaksid kirjutama töötajaid, et nad kokku ei jookseks, kuid kui nad kukuvad, oleks tore mõista, miks, mis mõnikord on tootmisele juurdepääsu puudumise tõttu võimatu, muidugi ja sellest tulenevalt arendaja logide puudumine.
Muutmine.
Olles seda kõike päris pikalt vastu pidanud, hakkasime koos meeskonnaga tüürima meile edukamas suunas. Kokkuvõtteks, milliste probleemidega me kokku puutusime?
- Kvaliteetse suhtluse puudumine arendajate ja haldusosakonna vahel
- Administraatorid, selgub(!), ei saa üldse aru, kuidas rakendus on üles ehitatud, millised sõltuvused sellel on ja kuidas see töötab.
- Arendajad ei saa aru, kuidas tootmiskeskkond töötab ja seetõttu ei suuda ka probleemidele tõhusalt reageerida.
- Juurutamisprotsess võtab liiga kaua aega.
- Ebastabiilsed väljaanded.
Mida me oleme teinud?
Iga väljalase jaoks koostati väljalaskemärkmete loend, mis sisaldas loendit töödest, mida tuleb serveris teha, et järgmine väljaanne töötaks. Loend sisaldas mitut jaotist, tööd, mida peaksid tegema administraator, väljalaske eest vastutav isik ja arendaja. Arendajad said mitte-juurjuurdepääsu kõikidele tootmisserveritele, mis kiirendas üldiselt arendust ja eelkõige probleemide lahendamist. Samuti on arendajatel arusaam sellest, kuidas tootmine toimib, millisteks teenusteks see jaguneb, kus ja kui palju koopiad maksavad. Osa lahingukoormustest on muutunud selgemaks, mis kahtlemata mõjutab koodi kvaliteeti. Suhtlemine vabastamisprotsessi ajal toimus ühe kiirsõnumitooja vestluses. Esiteks oli meil kõigi toimingute logi ja teiseks toimus suhtlus lähemas keskkonnas. Tegevusajalugu on rohkem kui üks kord võimaldanud uutel töötajatel probleeme kiiremini lahendada. See on paradoks, kuid see aitas sageli administraatoreid endid. Ma ei hakka seda kindlalt väitma, kuid mulle tundub, et administraatorid on hakanud rohkem aru saama, kuidas projekt töötab ja kuidas see on kirjutatud. Vahel jagasime isegi omavahel mingeid detaile. Keskmine vabastamise aeg on lühenenud ühele tunnile. Mõnikord saime 30-40 minutiga valmis. Vigade arv on oluliselt, kui mitte kümnekordistunud, vähenenud. Loomulikult mõjutasid vabastamisaja lühenemist ka muud tegurid, näiteks automaattestid. Pärast iga väljalaset hakkasime läbi viima tagasivaateid. Et kogu meeskond saaks aimu, mis on uut, mis on muutunud ja mis on eemaldatud. Kahjuks ei tulnud adminnid alati nende juurde, noh, administraatorid on hõivatud... Minu töörahulolu arendajana on kahtlemata tõusnud. Kui suudate kiiresti lahendada peaaegu kõik teie pädevusvaldkonnas olevad probleemid, tunnete end üleval. Hiljem saan aru, et mingil määral juurutasime devops-kultuuri, muidugi mitte täielikult, aga isegi see transformatsiooni algus oli muljetavaldav.
Kolmas lugu
Käivitamine. Üks admin, väike arendusosakond. Kohale jõudes olen täielik null, sest... Mul pole juurdepääsu kuhugi peale posti. Kirjutame administraatorile ja palume juurdepääsu. Lisaks on info, et ta on teadlik uuest töötajast ja sisselogimiste/paroolide väljastamise vajadusest. Need annavad juurdepääsu hoidlast ja VPN-ist. Miks anda juurdepääs wikile, teamcityle, rundeskile? Kasutud asjad inimesele, kes kutsuti kogu taustaosa kirjutama. Alles aja jooksul saame juurdepääsu mõnele tööriistale. Saabumisele suhtuti muidugi umbusaldusega. Üritan vestluste ja suunavate küsimuste kaudu aeglaselt mõista, kuidas projekti infrastruktuur töötab. Põhimõtteliselt ei tunne ma midagi ära. Tootmine on sama must kast nagu varem. Kuid veelgi enam, isegi testimiseks kasutatavad lavaserverid on must kast. Me ei saa teha muud, kui juurutada sinna Giti filiaal. Samuti ei saa me oma rakendust nagu env-faile konfigureerida. Juurdepääsu sellistele toimingutele ei anta. Peate anuma, et saaksite testserveris oma rakenduse konfiguratsioonis rea muuta. (On teooria, et administraatoritel on ülioluline tunda end projektis tähtsana; kui neil ei paluta konfiguratsioonides ridu muuta, pole neid lihtsalt vaja). Noh, nagu alati, kas pole mugav? See läheb kiiresti igavaks, peale otsest vestlust adminniga saame teada, et arendajad on sündinud halba koodi kirjutama, on oma olemuselt saamatud isiksused ja parem on neid tootmisest eemal hoida. Aga siin igaks juhuks ka testserveritest. Konflikt süveneb kiiresti. Administraatoriga suhtlemine puudub. Olukorda raskendab asjaolu, et ta on üksi. Järgnev on tüüpiline pilt. Vabasta. Teatud funktsioonid ei tööta. Meil kulub palju aega, et aru saada, mis toimub, vestlusesse visatakse arendajatelt erinevaid ideid, kuid tavaliselt eeldab administraator sellises olukorras, et arendajad on süüdi. Siis ta kirjutab chatis, et oota, ma parandasin ta ära. Kui meil palutakse jätta lugu, mis sisaldab teavet probleemi kohta, saame mürgiseid vabandusi. Nagu, ära topi oma nina sinna, kuhu see ei kuulu. Arendajad peavad kirjutama koodi. Olukord, kus projektis käivad paljud kehaliigutused läbi ühe inimese ja ainult temal on ligipääs kõigile vajalike operatsioonide sooritamiseks, on äärmiselt kurb. Selline inimene on kohutav pudelikael. Kui Devopsi ideede eesmärk on vähendada turule jõudmise aega, siis sellised inimesed on Devopsi ideede halvim vaenlane. Kahjuks läheb eesriie siin kinni.
PS Pärast seda, kui rääkisin inimestega vestlustes veidi arendajatest ja administraatoritest, kohtasin inimesi, kes jagasid minu valu. Kuid oli ka neid, kes ütlesid, et pole kunagi millegi sellisega kokku puutunud. Küsisin ühel devopsi konverentsil Anton Isaninilt (Alfa Bank), kuidas nad lahendasid kitsaskoha probleemi administraatorite näol, mille peale ta vastas: "Asendasime need nuppudega." Muideks tema osalusel. Tahaks uskuda, et häid administraatoreid on palju rohkem kui vaenlasi. Ja jah, alguses olev pilt on tõeline kirjavahetus.
Allikas: www.habr.com