I sviluppatori sò di Marte, l'amministratori sò di Venus

E coincidenze sò casuali, è veramente era in un altru pianeta...

Mi piacerebbe sparte trè storie di successu è fallimentu nantu à cumu travaglia un sviluppatore backend in una squadra cù amministratori.

Una storia.
Web studio, u numeru di l'impiegati pò esse cuntatu cù una manu. Oghje sì un disegnatore di layout, dumane sì un backender, dopu dumani sì un amministratore. Da una banda, pudete acquistà una sperienza tremenda. Per d 'altra banda, ci hè una mancanza di cumpetenza in tutti i duminii. Mi ricordu sempre di u primu ghjornu di travagliu, sò sempre verde, u patronu dice: "Apertura putty", ma ùn sò micca ciò chì hè. A cumunicazione cù l'amministratori hè esclusa, perchè sì un amministratore stessu. Cunsideremu i pro è i contra di sta situazione.

+ Tuttu u putere hè in e vostre mani.
+ Ùn ci hè bisognu di dumandà à nimu per accessu à u servitore.
+ Tempu di reazione veloce in tutte e direzzione.
+ Migliura bè e cumpetenze.
+ Avè una cunniscenza cumpleta di l'architettura di u produttu.

- Alta rispunsabilità.
- Rischiu di rupture di a pruduzzione.
- Hè difficiuli di esse un bon specialista in tutti i campi.

Ùn interessa micca, andemu avanti

A seconda storia.
Grande cumpagnia, grande prughjettu. Ci hè un dipartimentu di amministrazione cù 5-7 impiegati è parechji gruppi di sviluppu. Quandu vene à travaglià in una tale cumpagnia, ogni amministratore pensa chì ùn avete micca vinutu quì per travaglià nantu à un pruduttu, ma per rompe qualcosa. Nè u NDA firmatu nè a selezzione à l'entrevista ùn indicanu altrimenti. Innò, st'omu hè ghjuntu quì cù e so mani sporche per arruvinà a nostra pruduzzione di basgi. Per quessa, cù una tale persona avete bisognu di un minimu di cumunicazione; almenu, pudete lancià un sticker in risposta. Ùn risponde micca à e dumande nantu à l'architettura di u prugettu. Hè cunsigliatu di ùn dà accessu finu à chì u capu di a squadra dumanda. È quandu ellu dumanda, li restituverà cù ancu menu privilegii ch'elli anu dumandatu. Quasi tutta a cumunicazione cù tali amministratori hè assorbita da u pirtusu neru trà u dipartimentu di sviluppu è u dipartimentu di amministrazione. Hè impussibile di risolve i prublemi prestu. Ma ùn pudete micca vene in persona - l'amministratori sò troppu occupati 24/7. (Chì fate tuttu u tempu?) Alcune caratteristiche di rendiment:

• U tempu mediu di implementazione à a produzzione hè di 4-5 ore
• Tempu massimu di implementazione in a produzzione 9 ore
• Per un sviluppatore, una applicazione in produzzione hè una scatula negra, cum'è u servitore di produzzione stessu. Quantu ci sò in totale ?
• Low quality of releases, errori frequenti
• U sviluppatore ùn participa micca à u prucessu di liberazione

Ebbè, ciò chì m'aspittava, sicuru, e persone novi ùn sò micca permessi di produzzione. Ebbè, va bè, dopu avè acquistatu pacienza, cuminciamu à guadagnà a fiducia di l'altri. Ma per una certa ragione, e cose ùn sò micca cusì simplici cù l'amministratori.

Attu 1. L'amministratore hè invisibule.
U ghjornu di liberazione, u sviluppatore è l'amministratore ùn comunicanu micca. L'amministratore ùn hà micca dumande. Ma capisci perchè dopu. L'amministratore hè una persona principiata, ùn hà micca messageri, ùn dà micca u so numeru di telefunu à nimu, è ùn hà micca un prufilu nantu à e rete soziale. Ùn ci hè mancu una foto di ellu in ogni locu, chì pari omu ? Semu cun u manager rispunsevuli per circa 15 minuti in perplessità, circate di stabilisce a cumunicazione cù questu Voyager 1, dopu un messagiu appare in l'email corporativu chì hà finitu. Avemu da currisponde per mail ? Perchè nò? Conveniente, ùn hè micca? Va bè, rinfreschimu. U prucessu hè digià in corso, ùn ci hè micca vultà in daretu. Leghjite u missaghju di novu. "Aghju finitu". Chì avete finitu ? Induve ? Induve vi devu circà ? Quì capite perchè 4 ore per a liberazione hè normale. Avemu un scossa di sviluppu, ma finiscemu a liberazione. Ùn ci hè più voglia di liberà.

Act 2. Micca quella versione.
A prossima liberazione. Dopu avè acquistatu sperienza, cuminciamu à creà listi di u software è e biblioteche necessarii per u servitore per l'amministratori, indicà e versioni per alcuni. Cum'è sempre, ricevemu un signalu radiu debule chì l'amministratore hà finitu qualcosa quì. A prova di regressione principia, chì dura circa una ora. Tuttu pare chì funziona, ma ci hè un bug criticu. A funziunalità impurtante ùn funziona micca. L'ora dopu ballavanu cù tamburini, furtuna nantu à i cafè, è una rivista dettagliata di ogni pezzu di codice. L'amministratore dice chì hà fattu tuttu. L'applicazione scritta da i sviluppatori crooked ùn funziona micca, ma u servitore funziona. Qualchese dumande per ellu? À a fine di una ora, avemu l'amministratore per mandà a versione di a biblioteca nantu à u servitore di produzzione in u chat è u bingo - ùn hè micca quellu chì avemu bisognu. Avemu dumandatu à l'amministratore per installà a versione necessaria, ma in risposta avemu ricevutu chì ùn pò micca fà questu per l'absenza di sta versione in u gestore di pacchetti OS. Quì, da i recessi di a so memoria, u manager si ricorda chì un altru amministratore avia digià risoltu stu prublema solu assemblendu a versione necessaria à manu. Ma nò, u nostru ùn farà micca questu. I regulamenti pruibiscenu. Karl, simu stati à pusà quì per parechje ore, quale hè u limitu di tempu ?! Avemu un altru scossa è in qualchì manera finisci a liberazione.

Act 3, cortu
Bigliettu urgente, funziunalità chjave ùn funziona micca per unu di l'utilizatori in a produzzione. Passemu un paru d'ore à picchià è cuntrollà. In un ambiente di sviluppu, tuttu funziona. Ci hè un capiscenu chjaru chì saria una bona idea di guardà in i logs php-fpm. Ùn ci era micca sistemi di logu cum'è ELK o Prometheus nantu à u prugettu à quellu tempu. Avemu apertu un bigliettu à u dipartimentu di l'amministrazione in modu chì dà accessu à i logs php-fpm in u servitore. Eccu avete bisognu di capiscenu chì dumandemu l'accessu per una ragione, ùn vi ricordate micca di u pirtusu neru è di l'amministratori chì sò occupati 24/7? Se li dumandate à fighjà i ghjurnali stessi, allora questu hè un compitu cù una priorità "micca in questa vita". U bigliettu hè statu creatu, avemu ricevutu una risposta immediata da u capu di u dipartimentu di l'amministrazione: "Ùn avete micca bisognu di accessu à i logs di produzzione, scrive senza bug". Una cortina.

Act 4 è dopu
Semu sempre cullighjendu decine di prublemi in a produzzione, per via di diverse versioni di biblioteche, software micca cunfiguratu, carichi di servitore micca preparatu è altri prublemi. Di sicuru, ci sò ancu bug di codice, ùn culperemu micca l'amministratori per tutti i peccati, avemu da esse solu una operazione tipica per quellu prughjettu. Avemu avutu assai travagliadori di fondo chì sò stati lanciati attraversu u supervisore, è alcuni script anu da esse aghjuntu à cron. Calchì volta sti stessi travagliadori smettenu di travaglià. A carica nantu à u servitore di fila hè cresciutu à a velocità di u lampu, è l'utilizatori tristi anu vistu u caricatore spinning. Per riparà rapidamente tali travagliadori, bastava solu per riavvia, ma dinò, solu un amministratore puderia fà questu. Mentre era realizata una operazione cusì basica, puderia passà un ghjornu sanu. Quì, sicuru, vale a pena nutà chì i programatori storti duveranu scrive i travagliadori per ch'elli ùn sguassate micca, ma quandu si cascanu, saria bellu di capisce perchè, chì hè qualchì volta impussibile per via di a mancanza d'accessu à a produzzione, di sicuru, è in cunseguenza, a mancanza di logs da u sviluppatore.

Trasfigurazione.
Dopu avè suppurtatu tuttu questu per un bellu pezzu, inseme cù a squadra avemu cuminciatu à guidà in una direzzione chì era più successu per noi. Per riassume, chì prublemi avemu affruntatu?

• Mancanza di cumunicazione di qualità trà i sviluppatori è u dipartimentu di amministrazione
• L'amministratori, risulta (!), ùn capiscenu micca cumu hè strutturata l'applicazione, chì dipendenze hà è cumu si travaglia.
• I sviluppatori ùn capiscenu micca cumu funziona l'ambiente di produzzione è, in u risultatu, ùn ponu micca risponde in modu efficace à i prublemi.
• U prucessu di implementazione dura troppu longu.
• Versioni instabili.

Chì avemu fattu ?
Per ogni versione, hè stata generata una lista di Note di Liberazione, chì includeva una lista di u travagliu chì deve esse fattu nantu à u servitore per a prossima versione per travaglià. A lista cuntene parechje sezzioni, u travagliu chì deve esse realizatu da l'amministratore, a persona rispunsevuli di a liberazione è u sviluppatore. I sviluppatori anu ricivutu accessu senza root à tutti i servitori di produzzione, chì acceleranu u sviluppu in generale è a risoluzione di prublemi in particulare. I sviluppatori anu ancu una cunniscenza di cumu funziona a produzzione, in quali servizii hè divisu, induve è quantu costanu e repliche. Certi di i carichi di cummattimentu sò diventati più chjaru, chì senza dubbitu affetta a qualità di u codice. A cumunicazione durante u prucessu di liberazione hè stata fatta in u chat di unu di i messageri instantani. Prima, avemu avutu un logu di tutte l'azzioni, è in segundu, a cumunicazione hà fattu in un ambiente più vicinu. Avè una storia di l'azzioni hà più di una volta hà permessu à i novi impiegati di risolve i prublemi più veloce. Hè un paradossu, ma questu spessu aiutava l'amministratori stessi. Ùn aghju micca impegnatu à dì di sicuru, ma mi pare chì l'amministratori anu cuminciatu à capiscenu più cumu u prughjettu funziona è cumu hè scrittu. Calchì volta avemu ancu sparte qualchi dettagli cun l'altri. U tempu mediu di liberazione hè stata ridutta à una ora. Calchì volta avemu fattu in 30-40 minuti. U numaru di bug hè diminuitu significativamente, se micca deci volte. Di sicuru, altri fattori anu influinzatu ancu a riduzione di u tempu di liberazione, cum'è l'autotest. Dopu ogni liberazione, avemu cuminciatu à fà retrospettivi. Cusì chì tutta a squadra hà una idea di ciò chì hè novu, ciò chì hè cambiatu, è ciò chì hè statu eliminatu. Sfurtunatamente, l'amministratori ùn sò micca sempre venuti à elli, bè, l'amministratori sò occupati... A mo satisfaczione di u travagliu cum'è sviluppatore hà senza dubbitu aumentatu. Quandu pudete risolve rapidamente quasi ogni prublema chì hè in a vostra zona di cumpetenza, vi sentite in cima. In seguitu, capiraghju chì in una certa misura avemu introduttu una cultura devops, micca cumpletamente, sicuru, ma ancu quellu principiu di a trasfurmazioni era impressiunanti.

Storia trè
Abbrivu. Un amministratore, un picculu dipartimentu di sviluppu. À l'arrivu sò un zero cumpletu, perchè ... Ùn aghju micca accessu in ogni locu eccettu da u mail. Scrivemu à l'amministratore è dumandemu l'accessu. Inoltre, ci hè infurmazione chì ellu hè cunnisciutu di u novu impiigatu è a necessità di issuà logins / password. Danu accessu da u repository è VPN. Perchè dà accessu à wiki, teamcity, rundesk? Cose inutili per una persona chì hè stata chjamata per scrive tutta a parte backend. Solu cù u tempu avemu accessu à certi arnesi. L'arrivu, di sicuru, hè stata accolta cun sfiducia. Pruvate di capisce lentamente cumu funziona l'infrastruttura di u prugettu attraversu chats è dumande guida. In fondu ùn ricunnoscu nunda. A pruduzzione hè a stessa scatula negra cum'è prima. Ma più di questu, ancu i servitori di scena utilizati per a prova sò una scatula negra. Ùn pudemu micca fà nunda altru ch'è implementà una filiera da Git quì. Ùn pudemu ancu cunfigurà a nostra applicazione cum'è i schedari .env. L'accessu per tali operazioni ùn hè micca cuncessu. Avete da dumandà per avè una linea cambiata in a cunfigurazione di a vostra applicazione in u servitore di teste. (Ci hè una teoria chì hè vitale per l'amministratori per sentenu impurtanti nantu à u prugettu; s'ellu ùn sò micca dumandatu à cambià e linee in i cunfigurazioni, simpricimenti ùn saranu micca necessariu). Ebbè, cum'è sempre, ùn hè micca cunvene? Questu diventa rapidamente annoiatu, dopu à una conversazione diretta cù l'admin, truvamu chì i sviluppatori sò nati per scrive u codice cattivu, sò per natura individui incompetenti è hè megliu per mantene l'alluntanu da a produzzione. Ma quì ancu da i servitori di teste, solu in casu. U cunflittu cresce rapidamente. Ùn ci hè micca cumunicazione cù l'amministratore. A situazione hè aggravata da u fattu chì ellu hè solu. A seguita hè una stampa tipica. Libera. Certi funziunalità ùn funziona micca. Ci vole assai tempu per capisce ciò chì succede, diverse idee da i sviluppatori sò ghjittati in u chat, ma l'amministratore in una tale situazione generalmente assume chì i sviluppatori sò culpèvuli. Allora scrive in u chat, aspetta, aghju currettu. Quandu ci hè dumandatu di lascià una storia cù infurmazioni nantu à quale era u prublema, ricevemu scuse tossiche. Cum'è, ùn mette micca u nasu induve ùn hè micca. I sviluppatori devenu scrive codice. A situazione quandu parechji muvimenti di u corpu in un prughjettu passanu per una sola persona è solu ellu hà accessu à eseguisce l'operazioni chì tutti necessitanu hè estremamente triste. Una tale persona hè un terribili collu di buttiglia. Se l'idee Devops s'impegnanu à riduce u tempu di vendita, allora tali persone sò u peghju nemicu di l'idee Devops. Sfurtunatamente, a cortina chjude quì.

PS Dopu avè parlatu un pocu di sviluppatori vs admins in chats with people, aghju scontru persone chì sparte u mo dolore. Ma ci era ancu quelli chì dicianu ch'elli ùn avianu mai scontru nunda cusì. In una cunferenza di devops, aghju dumandatu à Anton Isanin (Alfa Bank) cumu si trattavanu di u prublema di u collu di bottiglia in forma di amministratori, à quale ellu disse: "Avemu rimpiazzati cù i buttoni". A propositu podcast cù a so participazione. Vogliu crede chì ci sò assai più boni amministratori chì nemici. È iè, a stampa à u principiu hè una vera currispundenza.

Fonte: www.habr.com