Ho appena parlato con un ragazzo DevOps che ha sollevato alcuni punti davvero positivi sulle lotte di essere un ingegnere DevOps e sentirsi un esercito individuale a volte, anche se fa parte di una squadra di 16 ingegneri.

Indossa molti cappelli diversi, ma fa parte del team di sviluppo che fa il lavoro di infrastruttura. Ama la fantastica tecnologia con cui riesce a lavorare - un sacco di automazione, cloud, containerizzazione ecc. Ma si sforza di essere l'unica persona che fa ops, in una devsquadra. Riferisce al responsabile dello sviluppo, ma lavora più da vicino con il gestore dell'infrastruttura.

Questo sembra essere il caso di molti professionisti DevOps con cui parlo. Cosa si potrebbe fare per aiutare gli ingegneri DevOps a sentirsi meno come un lupo solitario?

Il mio primo pensiero è "perché è lui l'unica persona che fa operazioni operative, in un team di sviluppo, specialmente quando riesce a lavorare con un sacco di automazione?". Penso che ci sia un'opportunità lì per affrontare la sindrome del lupo solitario; in particolare in un ambiente di sviluppo, l'infrastruttura come codice fornisce un ottimo framework per la condivisione del carico. Le persone operative dovrebbero essere esperti nel determinare e definire le esigenze di infrastruttura per l'applicazione, ma dovrebbero anche essere in grado di costruire una piattaforma per consentire ai ruoli di sviluppo di fare il più possibile indipendentemente.

Sembra un silo all'interno di una squadra; le vecchie abitudini sono dure a morire. Un programmatore potrebbe non sentirsi a proprio agio nel girare e indurire un server, ma in un modello devops puro, dovrebbero avere gli strumenti per farlo. Una persona operatrice in un team devops non dovrebbe essere responsabile della fornitura dell'infrastruttura per l'app stessa, ma dovrebbe fornire alcune informazioni su ciò che è necessario e alcune indicazioni su come gli sviluppatori di app possono farlo da soli. È quasi un modello di meta-infrastruttura; gli ingegneri operativi costruiscono infrastrutture che possono costruire infrastrutture su richiesta quando richiesto dal team di sviluppo.

La consultazione, la comunicazione e la fusione delle responsabilità sono tutti elementi cruciali per il successo di un team devops.

Penso che il primo difetto sia in questa frase:

Riferisce al responsabile dello sviluppo, ma lavora più da vicino con il gestore dell'infrastruttura.

DevOps è un cambiamento culturale che mira a rimuovere i silos. Se i silos rimangono, allora questo ingegnere è come vuoi chiamarlo; un ingegnere che fa sviluppo operativo, un esperto di automazione, uno sviluppatore che automatizza l'infrastruttura, ma questo ingegnere non è un ingegnere DevOps.
In effetti, "DevOps Engineer" non è un ruolo reale , è più un "chapeau" in quanto può comprendere sviluppatori, amministratori di sistema, tester QA e architetti che lavorano in un team comune.

Un problema che vedo spesso è che le persone cadono nell'uso delle parole d'ordine di DevOps, vedendolo come un titolo di lavoro, ma non capiscono davvero cosa sia DevOps. Osservando DevOps in questo modo, spesso finiscono isolati e si sentono soli, incolpando fallimenti e carenze nell'essere un "lupo solitario" senza buy-in manageriali e organizzativi.

Come lo descrivi, questo ingegnere è l'unico a fare operazioni in un team Dev. Ciò non lo rende un "ingegnere DevOps". (Qualunque cosa significhi nella sua organizzazione) Lavora in isolamento perché il lavoro è presentato come "Ingegnere DevOps" ma sembra che le altre persone nella sua squadra non desiderino lavorare sulle operazioni.

Siamo onesti, ci saranno sempre operazioni e sviluppatori, l'idea principale dietro devops è condividere le responsabilità in modo tale che non vi sia alcun passaggio di consegne da un prodotto all'altro o semplicemente fornire una piattaforma tramite operazioni per gli sviluppatori. L'obiettivo primario è portare più collaborazione in una squadra. Chiamare questo ruolo un "Ingegnere DevOps" significa infrangere questa idea suggerendo nel nome che puoi fare entrambe allo stesso livello di competenza, cosa che raramente è vera.

La prima cosa da fare a mio parere sarebbe quella di presentare gli strumenti operativi al team e fornire a tutti una conoscenza di base degli strumenti, quindi trasferire la responsabilità di configurare / codificare gli strumenti operativi a tutto il team. L'idea principale alla base di ciò si sta spostando da "quello che fa tutte le cose operative" a "quello che supporta e fornisce riferimenti alla squadra".

Ciò integra le altre risposte fornendo qualcosa di attuabile in un modo più semplice come primo passo rispetto a una riorganizzazione del management.

La cosa più importante per gli ingegneri DevOps in questo tipo di situazioni è ottenere (a) l' impegno di gestione e (b) i budget richiesti . Continua a leggere per ulteriori dettagli su entrambi ...

Ottieni impegno di gestione

Una volta che questo è a posto, le cose diventano facili per tali ingegneri DevOps. Soprattutto ogni volta che entra in gioco la resistenza (di ogni tipo di partito). Fidati di me, ci sarà una tale resistenza, che sfide come:

• Perché dobbiamo cambiare? Voglio continuare a fare quello che ho già fatto per X anni!
• Non voglio perdere il potere (tecnico) che ho, e completare ogni sorta di procedure del flusso di lavoro, per ottenere una sciocca correzione nella produzione che dovrebbe richiedere 5 minuti invece di 5 ore (o giorni ...).
• ... (Potrei aggiungere un'altra dozzina di proiettili qui ...).

Ogni volta che sorgono queste sfide, tutto un ingegnere DevOps dovrebbe dire è come:

Mi dispiace, sto solo facendo il mio lavoro ... in base alle istruzioni dell'alta direzione.

Ottieni budget richiesti

Un modo efficace per ottenere i budget richiesti è creare / inviare un caso aziendale appropriato che spieghi i benefici tangibili e intangibili delle varie pratiche DevOps applicandoli ad alcuni casi reali che si applicano alla società stessa.

Di seguito sono riportati alcuni casi del mondo reale che ho vissuto, come consulente SCM assunto da alcune aziende in cui erano successe queste cose. Lo so, SCM è solo una parte di DevOps, ma è l'area in cui ho una certa esperienza ...

1. Vantaggi dell'automazione

A causa dello sciopero di solo 2 (!!!) operatori di computer (che non digitavano più i comandi della console che dovevano digitare), i treni dovevano essere fermati da qualche parte a metà strada tra 2 fabbriche (dal momento che il sistema in fabbrica dove il treno stava per scendere, non erano disponibili dati cruciali sulla gestione del treno).

Implementando un sistema SCM, molti comandi dell'operatore sono stati automatizzati.

2. Ridurre i costi di licenza del software

Alcuni produttori di software avevano deciso di aumentare alcune tasse annuali per il software SCM (obsoleto), che la direzione non aveva accettato. Pertanto hanno creato un progetto speciale per sostituirlo con un software SCM alternativo.

Il budget del progetto era pari al canone annuale che non volevano continuare a pagare. Ciò includeva il volo in ingegneri di altri continenti (come me) per far sì che il progetto avesse successo.

3. Ridurre i costi operativi

Una grande compagnia assicurativa stava usando alcuni software FTP per trasferire le correzioni del software a circa 13.000 computer di fascia media (AS / 400) in tutto il paese, e questo ogni volta che "una" correzione era disponibile. Il costo di 1 di tale trasferimento era di circa 4 USD (13.000 x 4 = 52.000 USD per un singolo trasferimento ...). Il software era composto da 120.000 componenti, sviluppati / gestiti da circa 150 sviluppatori. Fai i calcoli sulla probabilità che 1 sviluppatore abbia commesso 1 (minuscolo) errore in uno di questi 120.000 componenti, che ha portato alla produzione e ha richiesto una correzione urgente, che sarebbe costata altri 52.000 USD (solo per il trasferimento!).

Con l'implementazione di un sistema SCM adeguato (con ambienti di test gestiti, approvazioni, ecc.), Questa società ha ottenuto un'importante riduzione dei costi. Pensaci, se il sistema SCM potesse impedire la necessità di soli 20 trasferimenti di correzioni urgenti, si tradurrebbe in una riduzione dei costi di 52.000 x 20 = 1.040.000 USD (abbastanza un budget per implementare un sistema SCM, avevano solo bisogno di una frazione di tale importo per portare a termine il lavoro).

4. Ridurre i costi di indisponibilità

Se i casi di cui sopra non sono abbastanza convincenti, pensa che i sistemi di una delle principali società di carte di credito non siano disponibili in tutto il mondo. Mi è stato detto che 1 secondo di indisponibilità costa loro 1.000.000 di dollari.

Questo è probabilmente anche il motivo per cui, per molto tempo, tali aziende hanno messo a punto sofisticati strumenti DevOps, già da molti decenni. Perché ogni secondo non sono in affari costa loro una fortuna.

TL; DR: Dal momento che la gestione superiore è solitamente instabile e soggetta a rabbia, suggerirei di provare a piegare un po 'la sua mente per avere una prospettiva diversa, cambiando le cose in meglio, gradualmente.

(Io parto dal presupposto che il suo problema è soprattutto con i riluttanti sviluppatori , non i suoi altri ops colleghi che sembrano fare operazioni classiche, soprattutto.)

IMO, anche se hai DevOps in corso, ciò non significa necessariamente che ogni sviluppatore debba essere un vero guru DevOps. Trovo piuttosto normale che ci siano uno o due veri esperti in un determinato gruppo di persone, e il resto più o meno segua. Finché il carico di lavoro non è troppo grande per quel ragazzo, e fintanto che riesce a incapsulare le sue conoscenze in script ecc. Invece di costruire il proprio silo, per me va bene.

L'unica cosa che non dovrebbe accadere è che il ragazzo DevOps faccia la sua automazione, e tutti gli altri si sforzano al massimo per evitare detta automazione (cioè, passare oltre la pipeline CI / CD e fare le cose manualmente in uno degli ambienti). Questo, l'IMO è la cosa principale che deve finire. Una soluzione per questo sarebbe quella di spingere molto duramente per l'approccio bestiame-non-animale, vale a dire abbattere incessantemente macchine virtuali o container a destra e sinistra appena possibile e farne girare di nuovo continuamente.

In secondo luogo, ovviamente, tutti devono essere consapevoli di ciò che sta facendo l'automazione, e almeno in teoria, con qualche ricerca in giro forse, essere in grado di avviare il macchinario di automazione (cioè, se tutto parte da un commit / push, quindi gli sviluppatori è necessario essere consapevoli e molto aggiornati sul fatto che ci saranno cose in background quando commettono). La pipeline CI (/ CD) deve essere abbastanza visibile e dovrebbe essere una cosa di cui tutti sono costantemente consapevoli (cioè quando uno sviluppatore lo rompe).

In terzo luogo, l '"uomo unico" deve ovviamente fare attenzione a non svolgere attività quotidiane e umili per i suoi colleghi (ad esempio, creando Dockerfile dopo Dockerfile per i loro artefatti ...).

In quarto luogo, le soluzioni che il ragazzo DevOps crea naturalmente devono essere effettivamente superiori agli approcci manuali del passato in qualche modo misurabile. In tal caso, dovrebbe essere possibile per lui dimostrare i suoi miglioramenti; ad esempio, dimostrare come le cose diventano più facili per tutti, o come sembra impossibile introdurre bug nelle fasi successive della pipa ecc. Se ciò non sembra possibile, allora il ragazzo DevOps deve dare una buona occhiata a cosa lui sta facendo. Se è possibile, ciò richiede sessioni brownbag e molta evangelizzazione nella sua squadra.

Ovviamente, in un ambiente così riluttante, probabilmente non arriverete a una soluzione CD completamente automatizzata o allo sviluppo basato su trunk in qualsiasi momento presto. Ma non mi preoccuperei troppo di essere individuato. Lui è l'esperto e se sta facendo bene il suo lavoro, l'intera squadra migliorerà molto gradualmente.

E infine, se dopo anni e anni di duro lavoro non c'è stato alcun miglioramento visibile con i suoi colleghi, è sempre possibile cercare altre strade (sia all'interno che all'esterno dell'azienda). Avere tutta l'esperienza DevOps al suo attivo è un'ottima base per cercare lavoro, in questi giorni ...

Vedo molte grandi risposte qui che parlano di DevOps come cultura, suggerimenti su come lavorare con il management e aiuto nella definizione delle cose da fare e da fare di un team o ingegnere DevOps. Penso che ognuno di loro sia fantastico, e davvero illustrativo di molte risposte può essere giusto al 100%, e comunque essere molto diverso, o addirittura completamente ambiguo, l'uno dall'altro ... Questo è DevOps!

Questa risposta è solo la mia prospettiva unica per esperienza e potrebbe non essere indicativa di norme o buone pratiche ...

Ma ciò di cui si è lamentato il tuo collega DevOps è la natura stessa di ciò che rende DevOps stimolante e difficile , soprattutto quando viene nominato il ruolo dell'ingegnere DevOps e non è semplicemente una mentalità culturale.

Personalmente, mi piace essere un lupo solitario, perché continuo a dare preziosi contributi, ma riesco anche a stabilire i miei limiti, persuadendo gli altri ad aiutare se stessi, aiutandomi in tal modo, abbattendo i silos IT.

Alcuni silos rimangono intatti , e va bene, è missione DevOps aggirarli e cercare di rendere quei silos il più insignificanti o invisibili possibile.

È possibile che il tuo collega stia realizzando, o non abbia ancora capito, che non gli piace essere un ingegnere DevOps .

Relativamente parlando, il concetto di devops è nuovo e continua a definirsi secondo me. Attualmente ricopro un ruolo di ingegnere devops. Per me, ciò significa che facilito e sviluppo gli strumenti e i processi utilizzati sia dai nostri team di sviluppo che operativi, liberandoli per concentrarsi sul prodotto che genera entrate per l'azienda. I team operativi e sviluppatori sviluppano i propri server e ciò di cui hanno bisogno. Ho semplicemente collegato l'IC per i nostri prodotti, assicurato che i nostri processi abbiano un senso e cerco quale processo può essere migliorato / automatizzato. Incontro tutti i nostri reparti, dalle vendite, al magazzino, agli sviluppatori e alle operazioni (QA e responsabili delle versioni) per vedere cosa stanno facendo e come posso migliorare il loro processo.

Per me, DevOps significa che lo sviluppo e il funzionamento di un sistema software diventa responsabilità di un team, anziché di team di sviluppo e operativi separati. Questa è una strada a doppio senso. I migliori team sono composti da persone a " T " che sono esperti in un campo e hanno familiarità con diversi campi correlati.

• I membri del team con esperienza in Ops sono tenuti a fare ciò che fanno meglio (ad es. Ops), a insegnare agli altri i fondamenti di ciò che fanno meglio (ad es. Ops) e ad apprendere e fare lavori in settori correlati (ad es. Compiti Dev).
• I membri del team con esperienza Dev devono fare ciò che fanno meglio (ad esempio Dev), insegnare agli altri i fondamenti di ciò che fanno meglio (ad esempio Dev) e apprendere e fare lavori in settori correlati (ad esempio compiti di Ops).

Quindi, per fare in modo che l'ingegnere DevOps si senta meno un lupo solitario, invitalo a insegnare agli sviluppatori come far funzionare i sistemi, riconoscendo che è l'esperto come progettare l'infrastruttura.

Fallo coinvolgere nell'architettura di alto livello fin dall'inizio, in modo che possa presentare le preoccupazioni della sua specialità. (Prima di avere DevOps, i nostri disegni di architettura passavano sempre alle "piccole cose" come i sistemi di bilanciamento del carico e i server ridondanti. Ora queste cose fanno parte dei primissimi schizzi.)

Aspettatevi che gli sviluppatori prendano alcune delle attività quotidiane di Ops, sia per creare ridondanza nel team sia per distribuire equamente i lavori di "drudge".

Aspettati che contribuisca allo sforzo del Dev se non ci sono compiti simili a Ops. Alcuni DevOps che conosco sembrano trovare il lavoro di database un'estensione naturale della loro area di competenza, non sono sicuro che possa essere generalizzato.

Cosa si potrebbe fare per aiutare gli ingegneri DevOps a sentirsi meno come un lupo solitario?

Per parafrasare - cosa può fare un ingegnere DevOps fare lui / lei stessa a sentirsi meno come un lupo solitario?

La mancanza di cultura e supporto gestionale è solo una parte dell'equazione. L'altra parte è secondo me che la conoscenza dettagliata di DevOps si riferisce spesso a contesti complessi ed è importante avere consigli e riferimenti a esempi di lavoro.

Pertanto - non sentirti come un lupo solitario; partecipare a comunità DevOps come questa qui o a gruppi specifici di strumenti e GitHub - la sensazione è almeno che non sei l'unico lupo solitario ;-)