Tafallichheden binne willekeurich, en yndie wie it op in oare planeet ...
Ik wol trije súkses- en mislearringsferhalen diele oer hoe't in backend-ûntwikkelder wurket yn in team mei admins.
Ferhaal ien.
Webstudio, it oantal meiwurkers kin mei ien hân teld wurde. Hjoed binne jo in layoutûntwerper, moarn binne jo in backender, oermorgen binne jo in admin. Oan 'e iene kant kinne jo geweldige ûnderfining ophelje. Oan de oare kant is der in gebrek oan kompetinsje op alle mêden. Ik wit noch de earste wurkdei, ik bin noch grien, de baas seit: “Iepen putty,” mar ik wit net wat it is. Kommunikaasje mei admins is útsletten, omdat do bist sels in admin. Lit ús beskôgje de foar- en neidielen fan dizze situaasje.
+ Alle macht is yn jo hannen.
+ D'r is net nedich om immen te smeekjen om tagong ta de tsjinner.
+ Snelle reaksjetiid yn alle rjochtingen.
+ Ferbettert feardigens goed.
+ Ha in folslein begryp fan 'e produktarsjitektuer.
- Hege ferantwurdlikens.
- Risiko fan brek produksje.
- It is lestich om op alle mêden in goede spesjalist te wêzen.
Net ynteressearre, litte wy fierder
It twadde ferhaal.
Grut bedriuw, grut projekt. Der is in administraasjeôfdieling mei 5-7 meiwurkers en ferskate ûntwikkelingsgroepen. As jo yn sa'n bedriuw oan it wurk komme, tinkt elke admin dat jo hjir net kommen binne om oan in produkt te wurkjen, mar om wat te brekken. Noch de ûndertekene NDA noch de seleksje by it ynterview jouwe oars oan. Nee, dizze man kaam hjir mei syn smoarge lytse hannen om ús tútsjeproduksje te ferneatigjen. Dêrom, mei sa'n persoan hawwe jo in minimum fan kommunikaasje nedich; op syn minst kinne jo in sticker smite as antwurd. Beäntwurdzje gjin fragen oer de projektarsjitektuer. It is oan te rieden om gjin tagong te jaan oant de teamlieder freget. En as hy freget, sil hy it werom jaan mei noch minder privileezjes dan se fregen. Hast alle kommunikaasje mei sokke admins wurdt opnomd troch it swarte gat tusken de ûntwikkeling ôfdieling en de administraasje ôfdieling. It is ûnmooglik om problemen fuortendaliks op te lossen. Mar jo kinne net persoanlik komme - de admins binne 24/7 te drok. (Wat dogge jo hieltyd?) Guon prestaasjes skaaimerken:
- Gemiddelde ynset tiid yn produksje is 4-5 oeren
- Maksimum ynset tiid yn produksje 9 oeren
- Foar in ûntwikkelder is in applikaasje yn produksje in swarte doaze, krekt as de produksjetsjinner sels. Hoefolle binne der yn totaal?
- Lege kwaliteit fan releases, faak flaters
- De ûntwikkelder docht net mei oan it frijlittingsproses
No, wat hie ik ferwachte, fansels, nije minsken meie net yn produksje. No, goed, nei't wy geduld krigen hawwe, begjinne wy it fertrouwen fan oaren te winnen. Mar om ien of oare reden binne dingen net sa ienfâldich mei admins.
Act 1. De admin is ûnsichtber.
Release day, ûntwikkelder en admin kommunisearje net. De admin hat gjin fragen. Mar jo begripe letter wêrom. De behearder is in prinsipiële persoan, hat gjin boaden, jout syn telefoannûmer net oan elkenien, en hat gjin profyl op sosjale netwurken. D'r is nergens iens in foto fan him, hoe lykje jo dude? Wy sitte mei de ferantwurdlike manager sawat 15 minuten yn betizing, besykje kommunikaasje mei dizze Voyager 1 te meitsjen, dan ferskynt in berjocht yn 'e bedriuws-e-post dat hy klear is. Sille wy per post korrespondearje? Wêrom net? Handich, is it net? No, goed, litte wy ôfkuolje. It proses is al oan 'e gong, der is gjin wei werom. Lês it berjocht nochris. "Ik bin klear". Wat hast klear? Wêr? Wêr moat ik dy sykje? Hjir begripe jo wêrom 4 oeren foar frijlitting normaal is. Wy krije in ûntwikkelingshok, mar wy meitsje de frijlitting ôf. Der is gjin winsk mear om los te litten.
Act 2. Net dy ferzje.
De folgjende release. Nei't wy ûnderfining hawwe opdien, begjinne wy listen te meitsjen fan 'e nedige software en bibleteken foar de tsjinner foar behearders, dy't de ferzjes foar guon oanjaan. Lykas altyd krije wy in swak radiosinjaal dat de admin dêr wat ôfmakke hat. De regressionstest begjint, dy't sels sawat in oere duorret. Alles liket te wurkjen, mar d'r is ien krityske bug. Wichtige funksjonaliteit wurket net. De kommende pear oeren wiene dûnsjen mei tamboerinen, fortune-telling op kofjegrûnen, en in detaillearre resinsje fan elk stikje koade. De admin seit dat hy alles dien hat. De applikaasje skreaun troch kromme ûntwikkelders wurket net, mar de tsjinner wurket. Hawwe jo fragen foar him? Oan 'e ein fan in oere krije wy de admin om de ferzje fan' e bibleteek op 'e produksjetsjinner te stjoeren nei it petear en bingo - it is net dejinge dy't wy nedich binne. Wy freegje de behearder om de fereaske ferzje te ynstallearjen, mar as antwurd krije wy dat hy dit net kin dwaan fanwegen it ûntbrekken fan dizze ferzje yn 'e OS-pakketbehearder. Hjir, út 'e útsparrings fan syn ûnthâld, de manager ûnthâlde dat in oare admin hie al oplost dit probleem troch gewoan assemble de fereaske ferzje mei de hân. Mar nee, ús sil dit net dwaan. De regeljouwing ferbiedt. Karl, wy hawwe hjir ferskate oeren sitten, wat is de tiidlimyt?! Wy krije in oare skok en meitsje de frijlitting op ien of oare manier ôf.
Akte 3, koart
Urgent ticket, kaai funksjonaliteit wurket net foar ien fan de brûkers yn produksje. Wy besteegje in pear oeren oan it pokken en kontrolearjen. Yn in ûntwikkelingsomjouwing wurket alles. D'r is in dúdlik begryp dat it in goed idee wêze soe om de php-fpm-logs te besjen. D'r wiene doe gjin logsystemen lykas ELK of Prometheus op it projekt. Wy iepenje in kaartsje foar de administraasjeôfdieling sadat se tagong jouwe ta de php-fpm-logs op 'e tsjinner. Hjir moatte jo begripe dat wy om in reden freegje om tagong, ûnthâlde jo net oer it swarte gat en admins dy't 24/7 dwaande binne? As jo se freegje om sels nei de logs te sjen, dan is dit in taak mei in prioriteit "net yn dit libben". It kaartsje is makke, wy krigen in direkte antwurd fan it haad fan 'e administraasjeôfdieling: "Jo moatte gjin tagong hawwe ta produksjelogboeken, skriuwe sûnder bugs." In gerdyn.
Wet 4 en fierder
Wy sammelje noch tsientallen problemen yn produksje, fanwege ferskate ferzjes fan bibleteken, net-konfigureare software, net-prepare serverladingen en oare problemen. Fansels binne d'r ek koadebugs, wy sille de admins net skuldich meitsje foar alle sûnden, wy sille gewoan noch ien typyske operaasje foar dat projekt neame. Wy hienen nochal in protte eftergrûnwurkers dy't waarden lansearre fia de tafersjochhâlder, en guon skripts moasten wurde tafoege oan cron. Soms hâlde dyselde arbeiders op mei wurkjen. De lading op 'e wachtrige tsjinner groeide mei bliksem snelheid, en tryste brûkers seagen nei de draaiende loader. Om sa'n arbeiders fluch te reparearjen, wie it genôch om se gewoan opnij te begjinnen, mar wer, allinich in behearder koe dit dwaan. Wylst sa'n basisoperaasje dien waard, koe der in hiele dei foarby gean. Hjir, fansels, it is de muoite wurdich opskriuwen dat krom programmeurs moatte skriuwe arbeiders sadat se net crashe, mar as se falle, it soe moai wêze om te begripen wêrom, dat is soms ûnmooglik troch it gebrek oan tagong ta produksje, fan fansels, en as gefolch, it gebrek oan logs út de ûntwikkelder.
Transfiguraasje.
Nei't wy dit alles in hiele lange tiid hawwe trochmakke, begûnen wy tegearre mei it team yn in rjochting te stjoeren dy't ús suksesfol wie. Om gearfetsje, hokker problemen hawwe wy konfrontearre?
- Gebrek oan kwaliteitskommunikaasje tusken ûntwikkelders en administraasjeôfdieling
- Behearders, sa docht bliken(!), begripe hielendal net hoe't de applikaasje opboud is, hokker ôfhinklikens it hat en hoe't it wurket.
- Untwikkelders begripe net hoe't de produksjeomjouwing wurket en kinne as gefolch net effektyf reagearje op problemen.
- It ynsetproses duorret te lang.
- Ynstabile releases.
Wat hawwe wy dien?
Foar elke release waard in list mei Release Notes oanmakke, dy't in list mei wurk omfette dy't op 'e server dien wurde moat foar de folgjende release om te wurkjen. De list befette ferskate seksjes, wurk dat moat wurde útfierd troch de behearder, de persoan ferantwurdlik foar de frijlitting, en de ûntwikkelder. Untwikkelders krigen net-root tagong ta alle produksjeservers, wat de ûntwikkeling yn 't algemien en probleemoplossing yn it bysûnder fersnelle. Untwikkelders hawwe ek in begryp fan hoe't produksje wurket, hokker tsjinsten it is ferdield yn, wêr en hoefolle replika's kostje. Guon fan 'e fjochtsladingen binne dúdliker wurden, wat sûnder mis de kwaliteit fan' e koade beynfloedet. Kommunikaasje tidens it frijlittingsproses fûn plak yn it petear fan ien fan 'e instant messengers. As earste hiene wy in logboek fan alle aksjes, en twadde, kommunikaasje fûn plak yn in tichterby omjouwing. It hawwen fan in skiednis fan aksjes hat mear as ien kear tastien nije meiwurkers problemen op te lossen flugger. It is in paradoks, mar dit holp faak de admins sels. Ik sil net ûndernimme om wis te sizzen, mar it liket my ta dat admins mear begjinne te begripen hoe't it projekt wurket en hoe't it skreaun is. Soms hawwe wy sels wat details mei elkoar dield. De gemiddelde frijlittingstiid is fermindere nei in oere. Soms wiene wy klear yn 30-40 minuten. It oantal bugs is signifikant ôfnommen, as net tsienfâldich. Fansels hawwe oare faktoaren ek ynfloed op de fermindering fan frijlittingstiid, lykas autotests. Nei elke release begûnen wy retrospectives te fieren. Sadat it hiele team in idee hat fan wat nij is, wat feroare is en wat is fuorthelle. Spitigernôch kamen admins net altyd by harren, no, admins binne drok... Myn wurktefredenheid as ûntwikkelder is sûnder mis tanommen. As jo hast elk probleem fluch kinne oplosse dat yn jo gebiet fan kompetinsje is, fiele jo jo boppe. Letter sil ik begripe dat wy foar in part in devops-kultuer ynfierd hawwe, net folslein, fansels, mar sels dat begjin fan de transformaasje wie yndrukwekkend.
Tredde ferhaal
Opstarte. Ien admin, lytse ûntwikkeling ôfdieling. By oankomst bin ik in folslein nul, want... Ik haw gjin tagong oeral útsein fan de post. Wy skriuwe nei de admin en freegje om tagong. Dêrneist is der ynformaasje dat er bewust is fan de nije meiwurker en de needsaak om logins / wachtwurden út te jaan. Se jouwe tagong fan it repository en VPN. Wêrom jouwe tagong ta wiki, teamcity, rundesk? Nutteleaze dingen foar in persoan dy't oproppen waard om it hiele backend diel te skriuwen. Allinnich mei de tiid krije wy tagong ta guon ark. De komst waard fansels mei wantrouwen troffen. Ik besykje stadichoan in gefoel te krijen foar hoe't de ynfrastruktuer fan it projekt wurket troch petearen en liedende fragen. Yn prinsipe herken ik neat. Produksje is deselde swarte doaze as earder. Mar mear dan dat, sels de poadiumservers dy't brûkt wurde foar testen binne in swarte doaze. Wy kinne neat oars dwaan as in tûke fan Git dêr ynsette. Wy kinne ek ús applikaasje net konfigurearje lykas .env-bestannen. Tagong foar sokke operaasjes wurdt net ferliend. Jo moatte smeke om in rigel te feroarjen yn 'e konfiguraasje fan jo applikaasje op' e testtsjinner. (D'r is in teory dat it wichtich is foar admins om harsels wichtich te fielen foar it projekt; as se net frege wurde om rigels yn 'e konfiguraasjes te feroarjen, sille se gewoan net nedich wêze). No, lykas altyd, is it net handich? Dit wurdt gau saai, nei in direkte petear mei de admin fine wy út dat de ûntwikkelders berne binne om minne koade te skriuwen, binne fan natuere ynkompetinte yndividuen en it is better om se fuort te hâlden fan produksje. Mar hjir ek fan testservers, foar it gefal. It konflikt eskalearret fluch. Der is gjin kommunikaasje mei de admin. De situaasje wurdt fergrutte troch it feit dat hy allinnich is. It folgjende is in typysk byld. Release. Bepaalde funksjonaliteit wurket net. It duorret in lange tiid om út te finen wat der bart, ferskate ideeën fan ûntwikkelders wurde yn 'e petear smiten, mar de admin giet yn sa'n situaasje meastentiids der fan út dat de ûntwikkelders de skuld hawwe. Dan skriuwt er yn it petear, wachtsje, ik korrizjearre him. Wannear't frege wurdt om in ferhaal efter te litten mei ynformaasje oer wat it probleem wie, krije wy giftige ekskús. Lykas, stek jo noas net dêr't it net heart. Untwikkelders moatte koade skriuwe. De situaasje as in protte lichemsbewegingen yn in projekt troch ien inkelde persoan geane en allinich hy hat tagong om de operaasjes út te fieren dy't elkenien nedich is, is ekstreem tryst. Sa'n persoan is in ferskriklik knyppunt. As Devops-ideeën stribje om tiid-to-merk te ferminderjen, dan binne sokke minsken de slimste fijân fan Devops-ideeën. Spitigernôch giet it gerdyn hjir ticht.
PS Nei it praten fan in bytsje oer ûntwikkelders vs admins yn petearen mei minsken, Ik moete minsken dy't dielde myn pine. Mar der wiene ek dyjingen dy't seine dat se soks noait tsjinkommen wiene. Op ien devops-konferinsje frege ik Anton Isanin (Alfa Bank) hoe't se omgean mei it probleem fan 'e knelpunt yn' e foarm fan admins, wêrop hy sei: "Wy hawwe se ferfongen troch knoppen." Trouwens mei syn dielname. Ik soe graach leauwe dat d'r folle mear goede admins binne as fijannen. En ja, de foto oan it begjin is in echte korrespondinsje.
Boarne: www.habr.com