Perché non dovrei provare a assumere un 'ingegnere DevOps'?

L'idea di avere un ingegnere DevOps è diventata molto popolare di recente e sembra interessante avere solo una persona che può inserirsi e fornire molti dei vantaggi di DevOps, come descritto nel blog Puppet :

Le organizzazioni che utilizzano le pratiche DevOps hanno un funzionamento straordinariamente elevato: implementano il codice fino a 30 volte più frequentemente rispetto ai loro concorrenti e il 50 percento in meno delle loro implementazioni fallisce, secondo il nostro rapporto 2015 sullo stato di DevOps.

Tuttavia, ho notato molta opposizione vocale all'idea di un ingegnere DevOps per cercare di apportare questi miglioramenti:

Anche con un ampio consenso sugli attributi principali di DevOps, la controversia circonda il termine "ingegnere DevOps". Alcuni sostengono che il termine stesso contraddica i valori DevOps. Jez Humble, il coautore di Continuous Delivery, sottolinea che solo chiamare qualcuno un ingegnere DevOps può creare un terzo silo in aggiunta a dev e ops - "... chiaramente un modo scarso (e ironico) di provare a risolvere questi problemi ".

Perché potrebbe non essere una grande idea per un'azienda assumere un Ingegnere DevOps per provare a "implementare DevOps", al contrario del cambiamento organizzativo sostenuto da blog come questo ? I benefici verranno annullati solo con un ruolo DevOps isolato?

TL; DR : non dovresti mai provare ad assumere un team DevOps

Esistono essenzialmente tre ruoli più comuni da assumere:

1. DevOps Architect / Evangelist
2. Ingegnere DevOps
3. Ingegnere CI / CD

Questi ruoli sono distinti dai 6 ruoli di sviluppo software essenziali che tradizionalmente compongono l'organizzazione di ingegneria del software:

1. Gestione del prodotto
2. Sviluppo software
3. Sviluppo di strumenti
4. Sicurezza e conformità
5. Qualità e test
6. Operazioni di sistema (SRE)

Passiamo attraverso i tre ruoli uno per uno e vediamo come si adattano

DevOps Architect o Evangelist

• Perché : se sei perso, lento, rotto e non sai cosa fare.
• Quando : all'inizio del processo nelle fasi di pianificazione.
• Cosa : ruolo a livello di gestione per guidare tutti i manager e i lead dell'intera organizzazione di ingegneria del software. Questa persona pianificherà l'intera trasformazione della tua organizzazione ingegneristica in uno stato altamente funzionante.
• Chi : membro della consulenza esperto in teoria, pratiche di gestione, argomenti di cultura e operazioni che riporta direttamente al VP di Ingegneria del Software.

In alcuni casi e per le aziende di piccole e medie dimensioni è possibile avviare il processo invece assumendo un'organizzazione di consulenza, come DORA.

Ingegnere DevOps

• Perché :
  1. Colmare le lacune tra i team se sono organizzati lungo i ruoli funzionali sopra menzionati per garantire una cooperazione a livello interfunzionale.
  2. Incorporare con team orientati al prodotto, che hanno ciascuno dei 6 ruoli tradizionali inclusi nel team, per aiutare a colmare le lacune di conoscenza e per aiutare con l'implementazione e l'adozione delle nuove pratiche e strumenti.
• Quando : una volta che hai definito i tuoi piani e inizia la trasformazione organizzativa e l'intero team di gestione è a bordo.
• Che cosa : abilitare la cooperazione tra funzioni, assicurarsi che i confini dei team vengano suddivisi, che le ottimizzazioni locali all'interno dei team non creino un ostacolo all'elevato throughput di lavoro attraverso le catene del valore, dai desideri dei clienti alle consegne ai clienti.
• Chi : ingegnere esperto con competenze sia nello sviluppo di software che nelle operazioni di sistema. Dovrebbe essere esperto nelle migliori pratiche, nei processi e nei cambiamenti culturali legati alla trasformazione di DevOps.

Ingegnere CI / CD

• Perché : per aiutare a implementare pipeline CI / CD, integrare la catena di strumenti, introdurre gli strumenti che consentiranno un migliore funzionamento dell'azienda.
• Quando : durante la transizione in un'organizzazione più grande, mentre i ruoli sopra indicati sono già stati ricoperti.
• Che cosa : Ingegnere, che è essenzialmente parte del team di strumenti che sarà in grado di impostare pipeline CI / CD e iniziare a integrare i sistemi interni in modo da rimuovere l'attrito dal rendimento del lavoro.
• Chi : ingegnere esperto con strumenti, processo di integrazione, gestione delle versioni e pratiche DevOps. Qualcuno che capisce che stanno sostituendo il gate umano nel processo di rilascio da parte dell'automazione.

Direi che Devops Engineer, come descritto nel link alla tua domanda, è principalmente un ruolo di amministratore di sistema. Citando le abilità qui per lo sfondo di questa risposta:

La tua attrezzatura da arrampicata.

• Esperienza consolidata nell'esperienza di amministrazione Linux / Unix nell'automazione / gestione della configurazione usando Puppet, Chef o un equivalente
• Capacità di utilizzare una vasta gamma di tecnologie open source e servizi cloud (è richiesta esperienza con AWS)
• Forte esperienza con SQL e MySQL (anche l'esperienza NoSQL è un vantaggio, poiché utilizziamo anche Redis)
• Una comprensione pratica di codice e script (PHP, Python, Perl e / o Ruby)
• Conoscenza delle migliori pratiche e operazioni IT in un servizio sempre attivo e sempre disponibile

In questa descrizione del lavoro di esempio DevOps Engineer è solo una parola d'ordine per un amministratore di sistema a suo agio con l'infrastruttura basata su cloud, l'automazione, in grado di leggere il codice per aiutare nella diagnostica e consapevole delle pratiche e delle soluzioni ad alta disponibilità.

Ciò è vagamente correlato alle pratiche DevOps e alla cultura di rottura dei sili tra sviluppo e operazioni, come si vede in questa domanda Qual è la differenza tra Sysadmin e DevOps Engineer?

Non sarà una buona idea perché un amministratore di sistema, quanto a suo agio con la pratica e la cultura di Devops, non sia la persona giusta per guidare una trasformazione aziendale. Non assumerai questa persona con un cambiamento di cultura in mente ma con una vista di configurazione dello strumento, che non aiuterà davvero a rompere i processi. Questo potrebbe anche essere ricevuto male dai suoi colleghi e porterai resistenza al cambiamento se non ci sono cambiamenti di cultura pianificati in anticipo

Per un modello di successo verso i guadagni dei devops, la risposta di @ Jiri Klouda offre una grande panoramica su un ruolo accettabile dell'Ingegnere DevOps insieme al passo nel cambiamento che porterebbe valore e aiuto per il successo.

Capisco che questa risposta potrebbe non essere perfetta per te, ma ecco cosa ho fatto

Sono stato il primo sviluppatore a lavorare in una startup di e-commerce molto impegnata, con un traffico incredibilmente alto. Mi rendo conto che la compagnia era ancora giovane e che, per un po ', sarei stata l'unica risorsa tecnica interna.

Sapendo questo, ho deciso di strutturare la mia infrastruttura in modo tale che avrei dovuto fare l'amministrazione dei sistemi ZERO.

Ho deciso di ospitare nel cloud, perché così facendo mi sono sollevato dalla manutenzione dei sistemi. Ho cercato un ingegnere AWS, con esperienza fantoccio. Insieme, abbiamo progettato un'infrastruttura scalabile, scritta come codice in cloudformation. Tutti i file di configurazione erano versionati all'interno di Puppet.

Questo mi ha permesso, come sviluppatore, di assumere questo ruolo devops. Ho creato strumenti di rilascio del codice, in Python, Fabric. Ho usato lo stesso script per avviare la mia applicazione su nuovi server con scalabilità automatica.

Funzionava molto bene e oggi, 3 anni dopo, non eseguo ancora alcuna manutenzione del sistema. Abbiamo un amministratore di sistema (lo stesso ingegnere AWS) per 10 ore al mese e provo a strutturare i suoi sprint in modo tale da non infastidirmi. In questo modo rispetto il suo tempo e gestisco i suoi sprint nel miglior modo possibile.

Se un sistema ha prestazioni degradate, semplicemente lo interrompo, e un altro gira al suo posto.

Spero che questa risposta possa in qualche modo avvantaggiarti

Non dovresti assumere un ingegnere DevOps perché DevOps comprende una così ampia varietà di discipline che un individuo non può essere un esperto in tutti gli aspetti di queste discipline. Assumendo un tuttofare, assumeresti un maestro di nessuno.

DevOps è necessariamente uno sforzo basato sul team e non ci si può aspettare che un individuo sostenga le aspettative di un intero team. Considera l'ambito di DevOps. Una persona non può possibilmente:

• Diventa uno sviluppatore rockstar in [lingua]
• Essere un guru della rete, conoscendo tutti gli RFC richiesti
• Sii un amministratore di sistemi esperto
• Sii un esperto tester di QA
• Diventa un amministratore del database
• Specializzato in archiviazione e backup
• Conoscere l'ingegneria dell'affidabilità del sito
• Potenzialmente anche altre discipline

Alcuni dei precedenti hanno anche delle discipline secondarie , come l'amministratore di sistema di Windows o l'amministratore di sistema Linux / Unix o forse usi più di un linguaggio di codifica nel tuo.

Nessuno può essere un esperto in tutto ciò, il che significa che se stai pubblicizzando un ingegnere DevOps, quando l'area più debole del tuo team DevOps è Networking, non stai facendo un ottimo lavoro di pubblicità delle tue necessità di uno specialista in rete per il tuo team DevOps . Mentre nessun individuo dovrebbe essere incastrato in un ruolo specifico nel team DevOps, faresti un disservizio al tuo team fingendo che non ci siano specialisti o esperti in materia (PMI) nell'ambito di DevOps. Spostare il pendolo da un estremo all'altro - dal silos al fingere come ogni ruolo nella tua squadra DevOps sia lo stesso - può causare altrettanti problemi.

Mentre avere membri del team si allena in più di una disciplina, in particolare nelle aree sovrapposte, è positivo, aspettarsi che siano in grado di essere competenti in un così ampio volume di conoscenze semplicemente non è pratica.

Ciò significa che chiunque ti dica di conoscere tutti gli aspetti di DevOps probabilmente ti sta mentendo. Assumi uno specialista nell'area in cui sei più debole che ha lavorato in un team DevOps, non un "Ingegnere DevOps".

Ho avuto questa sfida esatta durante l'implementazione in ASOS. L'obiettivo per noi è avere team autosufficienti e quindi avere un ruolo dedicato può essere un anti-modello, tuttavia viviamo nel mondo reale e per molti sviluppatori pensare a buone pratiche DevOps non è la loro cosa principale, quindi hanno bisogno di aiuto arrivarci.

Quello che abbiamo fatto è stato:

• perdere il termine degli ingegneri DevOps, DevOps è qualcosa che dovremmo fare tutti, non il nostro titolo professionale, quindi li abbiamo chiamati in modo diverso.

• li ha distribuiti ai team, ma solo 1 su 3, questo significava che non potevano fare qualcosa, ma dovevano essere visti come una competenza per aiutare i team a migliorarsi e risolvere i propri problemi (con la guida)

• manteneva anche una funzione centrale per fungere da centro di competenza e gestire le considerazioni aziendali, tutto ciò che riguarda tutti i team

Mentre ci evolviamo, rivediamo questo modello, ma per noi sta funzionando efficacemente finora

Non credo che sarai in grado di ottenere una risposta definitiva per questo perché sembra che ci siano molte cose da considerare.

• Com'è a bordo la compagnia con la pratica DevOps
• Che tipo di applicazione o servizio fornisce l'azienda
• La struttura della tua azienda

Ho appena finito di intervistare posizioni e ho finito con il titolo di ingegnere DevOps, ma parte di ciò che sto facendo è il lavoro di amministratore di sistema. Questo è solo per necessità a causa delle dimensioni dell'azienda e della natura di ciò che viene gestito dal punto di vista dell'applicazione. Alcune posizioni per le quali ho intervistato avevano un titolo simile e stavano cercando di più qualcuno dal lato dello sviluppo delle cose saggio. Si aspettavano una maggiore scrittura di codice e non un amministratore di sistema che eseguisse l'automazione. SRE sembra essere un titolo che sta guadagnando popolarità, quindi potrebbe essere la strada da percorrere. Ho avuto come amministratore di sistema e ingegnere di automazione il mio ultimo lavoro perché stavo scrivendo responsible e lo chef impila parte del tempo. La compagnia stava seguendo un modello devops abbastanza buono in cui tutti erano a bordo e gli sviluppatori lavoravano a fianco delle operazioni, ma penso che il loro futuro non lo abbia fatto

Ora che mi trovo in questa posizione, sto provando a suonare il clacson in un po 'di automazione e abbiamo alcuni problemi di persone che dovremo risolvere. Le persone vanno e vengono e alcuni dei flussi di lavoro sono stati progettati perché qualcun altro lo ha progettato in questo modo e non perché si adatta al modo in cui le persone lavorano.

Quindi in sostanza penso che dovresti capire la descrizione del lavoro e non preoccuparti così tanto del titolo a meno che non sia legato al pagamento in qualche modo o pensi che l'uno o l'altro attiri il giusto tipo di persone.

Se sei interessato al significato di DevOps e segui un "percorso vero". Non dovresti assumere un ingegnere DevOps. Dovresti assumere un ingegnere dell'automazione, un ingegnere della distribuzione, un architetto della piattaforma o una serie di altri ruoli che svolgono ciò di cui hai bisogno.

Se essere un vero praticante DevOps non è importante per te, puoi chiamarlo come vuoi.