Gli sviluppatori vengono da Marte, gli amministratori da Venere

Le coincidenze sono casuali, e in effetti era su un altro pianeta...

Vorrei condividere tre storie di successo e fallimento su come uno sviluppatore backend lavora in un team con gli amministratori.

La prima storia
Studio web, i dipendenti si contano con una mano. Oggi sei un progettista di layout, domani sei un backender, dopodomani sei un amministratore. Da un lato, puoi acquisire un'enorme esperienza. D’altro canto, vi è una mancanza di competenza in tutti i settori. Ricordo ancora il primo giorno di lavoro, sono ancora verde, il capo dice: "Apri stucco", ma non so cosa sia. La comunicazione con gli amministratori è esclusa, perché sei tu stesso un amministratore. Consideriamo i pro e i contro di questa situazione.

+ Tutto il potere è nelle tue mani.
+ Non è necessario chiedere a nessuno l'accesso al server.
+ Tempi di reazione rapidi in tutte le direzioni.
+ Migliora bene le abilità.
+ Avere una comprensione completa dell'architettura del prodotto.

— Alta responsabilità.
— Rischio di interruzione della produzione.
— È difficile essere un buon specialista in tutti i settori.

Non interessato, andiamo avanti

La seconda storia
Grande azienda, grande progetto. C'è un dipartimento amministrativo con 5-7 dipendenti e diversi gruppi di sviluppo. Quando arrivi a lavorare in un'azienda del genere, ogni amministratore pensa che tu non sia venuto qui per lavorare su un prodotto, ma per rompere qualcosa. Né la NDA firmata né la selezione al colloquio indicano diversamente. No, quest'uomo è venuto qui con le sue manine sporche per rovinare la nostra produzione di baci. Pertanto, con una persona del genere è necessario un minimo di comunicazione, almeno puoi lanciare un adesivo in risposta. Non rispondere a domande sull'architettura del progetto. Si consiglia di non concedere l'accesso finché il responsabile del team non lo chiede. E quando lo chiederà, lo restituirà con ancora meno privilegi di quelli richiesti. Quasi tutta la comunicazione con tali amministratori viene assorbita dal buco nero tra il dipartimento di sviluppo e quello amministrativo. È impossibile risolvere i problemi tempestivamente. Ma non puoi venire di persona: gli amministratori sono troppo occupati 24 ore su 7, XNUMX giorni su XNUMX. (Cosa fai tutto il tempo?) Alcune caratteristiche prestazionali:

• Il tempo medio di distribuzione per la produzione è di 4-5 ore
• Tempo massimo di distribuzione in produzione 9 ore
• Per uno sviluppatore, un'applicazione in produzione è una scatola nera, proprio come il server di produzione stesso. Quanti sono in totale?
• Bassa qualità delle versioni, errori frequenti
• Lo sviluppatore non partecipa al processo di rilascio

Bene, cosa mi aspettavo, ovviamente, nuove persone non sono ammesse alla produzione. Bene, va bene, avendo acquisito pazienza, iniziamo a guadagnare la fiducia degli altri. Ma per qualche motivo le cose non sono così semplici con gli amministratori.

Atto 1. L'amministratore è invisibile.
Il giorno del rilascio, lo sviluppatore e l'amministratore non comunicano. L'amministratore non ha domande. Ma capirai perché dopo. L'amministratore è una persona di principio, non ha messenger, non dà a nessuno il suo numero di telefono e non ha un profilo sui social network. Non c'è nemmeno una sua foto da nessuna parte, che aspetto hai amico? Rimaniamo seduti con il manager responsabile per circa 15 minuti, sconcertati, cercando di stabilire una comunicazione con questo Voyager 1, poi nell'e-mail aziendale appare un messaggio che ha finito. Ci corrisponderemo via mail? Perché no? Comodo, no? Bene, okay, calmiamoci. Il processo è già avviato, non si può tornare indietro. Leggi di nuovo il messaggio. "Ho finito". Cosa hai finito? Dove? Dove dovrei cercarti? Qui capisci perché 4 ore per il rilascio sono normali. Otteniamo uno shock nello sviluppo, ma finiamo il rilascio. Non c'è più alcun desiderio di rilasciare.

Atto 2. Non quella versione.
La prossima uscita. Avendo acquisito esperienza, iniziamo a creare elenchi dei software e delle librerie necessarie per il server per gli amministratori, indicando per alcuni le versioni. Come sempre, riceviamo un segnale radio debole che l'amministratore ha finito qualcosa lì. Inizia il test di regressione, che a sua volta dura circa un'ora. Sembra che tutto funzioni, ma c'è un bug critico. La funzionalità importante non funziona. Le ore successive furono dedicate a danze con tamburelli, predizione del futuro sui fondi di caffè e una revisione dettagliata di ogni pezzo di codice. L'amministratore dice di aver fatto tutto. L'applicazione scritta da sviluppatori disonesti non funziona, ma il server funziona. Qualche domanda per lui? Dopo un'ora, chiediamo all'amministratore di inviare alla chat e al bingo la versione della libreria sul server di produzione: non è quella di cui abbiamo bisogno. Chiediamo all'amministratore di installare la versione richiesta, ma in risposta riceviamo che non può farlo a causa dell'assenza di questa versione nel gestore pacchetti del sistema operativo. Ecco che, dai recessi della memoria, il manager ricorda che un altro amministratore aveva già risolto questo problema semplicemente assemblando a mano la versione richiesta. Ma no, il nostro non lo farà. La normativa lo vieta. Karl, siamo seduti qui da diverse ore, qual è il limite di tempo?! Otteniamo un altro shock e in qualche modo finiamo il rilascio.

Atto 3, breve
Ticket urgente, la funzionalità chiave non funziona per uno degli utenti in produzione. Passiamo un paio d'ore a frugare e controllare. In un ambiente di sviluppo, tutto funziona. È chiaro che sarebbe una buona idea esaminare i registri php-fpm. A quel tempo non c'erano sistemi di log come ELK o Prometheus nel progetto. Apriamo un ticket al dipartimento amministrativo in modo che diano accesso ai log php-fpm sul server. Qui devi capire che stiamo chiedendo l'accesso per un motivo, non ricordi del buco nero e degli amministratori impegnati 24 ore su 7, XNUMX giorni su XNUMX? Se chiedi loro di guardare i registri da soli, allora questo è un compito con una priorità "non in questa vita". Il ticket è stato creato, abbiamo ricevuto una risposta immediata dal capo del dipartimento amministrativo: "Non dovresti aver bisogno dell'accesso ai registri di produzione, scrivi senza bug". Una tenda.

Atto 4 e oltre
Stiamo ancora raccogliendo decine di problemi in produzione, dovuti a diverse versioni di librerie, software non configurato, carichi del server impreparati e altri problemi. Naturalmente ci sono anche dei bug nel codice, non daremo la colpa di tutti i peccati agli amministratori, menzioneremo solo un’altra operazione tipica per quel progetto. Avevamo molti lavoratori in background lanciati tramite il supervisore e alcuni script dovevano essere aggiunti a cron. A volte questi stessi lavoratori smettevano di lavorare. Il carico sul server di coda è cresciuto alla velocità della luce e gli utenti tristi hanno guardato il caricatore che girava. Per riparare rapidamente tali lavoratori, era sufficiente riavviarli, ma ancora una volta solo l'amministratore poteva farlo. Mentre veniva eseguita un'operazione così elementare, poteva passare un'intera giornata. Qui, ovviamente, vale la pena notare che i programmatori disonesti dovrebbero scrivere i lavoratori in modo che non crollino, ma quando cadono, sarebbe bello capire perché, cosa a volte impossibile a causa della mancanza di accesso alla produzione, di ovviamente, e di conseguenza, la mancanza di log da parte dello sviluppatore.

Trasfigurazione.
Dopo aver sopportato tutto questo per molto tempo, insieme al team abbiamo iniziato a prendere la direzione che per noi ha avuto più successo. Riassumendo, quali problemi abbiamo dovuto affrontare?

• Mancanza di comunicazione di qualità tra gli sviluppatori e il dipartimento amministrativo
• Si scopre che gli amministratori(!) non capiscono affatto come è strutturata l'applicazione, quali dipendenze ha e come funziona.
• Gli sviluppatori non capiscono come funziona l'ambiente di produzione e, di conseguenza, non possono rispondere efficacemente ai problemi.
• Il processo di distribuzione richiede troppo tempo.
• Rilasci instabili.

Cosa abbiamo fatto?
Per ogni rilascio, è stato generato un elenco di note di rilascio, che includeva un elenco di lavoro che è necessario eseguire sul server affinché il rilascio successivo funzioni. L'elenco conteneva diverse sezioni, lavoro che avrebbe dovuto essere svolto dall'amministratore, dalla persona responsabile del rilascio e dallo sviluppatore. Gli sviluppatori hanno ricevuto accesso non root a tutti i server di produzione, il che ha accelerato lo sviluppo in generale e la risoluzione dei problemi in particolare. Gli sviluppatori sanno anche come funziona la produzione, in quali servizi è suddivisa, dove e quanto costano le repliche. Alcuni carichi di combattimento sono diventati più chiari, il che indubbiamente influisce sulla qualità del codice. La comunicazione durante il processo di rilascio è avvenuta nella chat di uno dei servizi di messaggistica istantanea. In primo luogo, avevamo un registro di tutte le azioni e, in secondo luogo, la comunicazione è avvenuta in un ambiente più vicino. Avere una storia di azioni ha permesso più di una volta ai nuovi dipendenti di risolvere i problemi più velocemente. È un paradosso, ma questo spesso ha aiutato gli stessi amministratori. Non mi impegno a dirlo con certezza, ma mi sembra che gli amministratori abbiano iniziato a capire di più come funziona il progetto e come è scritto. A volte condividevamo anche alcuni dettagli. Il tempo medio di rilascio è stato ridotto a un'ora. A volte finivamo in 30-40 minuti. Il numero di bug è diminuito in modo significativo, se non dieci volte. Naturalmente anche altri fattori hanno influenzato la riduzione dei tempi di rilascio, come gli autotest. Dopo ogni uscita, abbiamo iniziato a condurre retrospettive. In modo che tutto il team abbia un’idea di cosa c’è di nuovo, cosa è cambiato e cosa è stato rimosso. Sfortunatamente, non sempre gli amministratori si sono rivolti a loro, beh, gli amministratori sono occupati... La mia soddisfazione lavorativa come sviluppatore è senza dubbio aumentata. Quando riesci a risolvere rapidamente quasi tutti i problemi che rientrano nella tua area di competenza, ti senti al top. Più tardi capirò che in una certa misura abbiamo introdotto una cultura devops, non del tutto, ovviamente, ma anche quell'inizio della trasformazione è stato impressionante.

Terza storia
Avviare. Un amministratore, piccolo dipartimento di sviluppo. All'arrivo sono un completo zero, perché... Non ho accesso da nessuna parte tranne che dalla posta. Scriviamo all'amministratore e chiediamo l'accesso. Inoltre, ci sono informazioni che egli è a conoscenza del nuovo dipendente e della necessità di fornire login/password. Consentono l'accesso dal repository e dalla VPN. Perché dare accesso a wiki, teamcity, rundesk? Cose inutili per una persona chiamata a scrivere tutta la parte backend. Solo col tempo otteniamo l’accesso ad alcuni strumenti. L'arrivo, ovviamente, è stato accolto con diffidenza. Sto cercando di farmi lentamente un'idea di come funziona l'infrastruttura del progetto attraverso chat e domande importanti. Fondamentalmente non riconosco nulla. La produzione è la stessa scatola nera di prima. Ma soprattutto, anche gli stage server utilizzati per i test sono una scatola nera. Non possiamo fare altro che distribuire un ramo da Git lì. Inoltre, non possiamo configurare la nostra applicazione come file .env. L'accesso per tali operazioni non è concesso. Devi chiedere di modificare una riga nella configurazione della tua applicazione sul server di test. (C'è una teoria secondo cui è vitale che gli amministratori si sentano importanti nel progetto; se non viene chiesto loro di modificare le righe nelle configurazioni, semplicemente non saranno necessarie). Beh, come sempre, non è conveniente? La cosa diventa presto noiosa, dopo una conversazione diretta con l'amministratore scopriamo che gli sviluppatori sono nati per scrivere codice pessimo, sono per natura individui incompetenti ed è meglio tenerli lontani dalla produzione. Ma qui anche dai server di test, per ogni evenienza. Il conflitto si sta rapidamente intensificando. Non c'è comunicazione con l'amministratore. La situazione è aggravata dal fatto che è solo. Quella che segue è un'immagine tipica. Pubblicazione. Alcune funzionalità non funzionano. Ci vuole molto tempo per capire cosa sta succedendo, varie idee degli sviluppatori vengono lanciate nella chat, ma l'amministratore in una situazione del genere di solito presume che la colpa sia degli sviluppatori. Poi scrive in chat, aspetta, l'ho corretto. Quando ci viene chiesto di lasciare una storia con informazioni su quale fosse il problema, riceviamo scuse tossiche. Ad esempio, non ficcare il naso dove non dovrebbe. Gli sviluppatori devono scrivere il codice. La situazione in cui molti movimenti del corpo in un progetto passano attraverso una sola persona e solo lui ha accesso per eseguire le operazioni di cui tutti hanno bisogno è estremamente triste. Una persona del genere rappresenta un terribile collo di bottiglia. Se le idee Devops si sforzano di ridurre il time-to-market, allora queste persone sono il peggior nemico delle idee Devops. Purtroppo qui il sipario si chiude.

PS Dopo aver parlato un po' di sviluppatori e amministratori nelle chat con le persone, ho incontrato persone che condividevano il mio dolore. Ma c'era anche chi diceva di non aver mai visto nulla di simile. In una conferenza dei devops ho chiesto ad Anton Isanin (Alfa Bank) come hanno affrontato il problema del collo di bottiglia sotto forma di amministratori, al quale ha risposto: "Li abbiamo sostituiti con pulsanti". A proposito Podcast con la sua partecipazione. Mi piacerebbe credere che ci siano molti più buoni amministratori che nemici. E sì, la foto all'inizio è una vera corrispondenza.

Fonte: www.habr.com