Come posso assumere un buon DevOps adatto alla mia azienda?

20

I buoni sviluppatori dovrebbero adattarsi alla regola 11 del test Joel :

I nuovi candidati scrivono codice durante il loro colloquio?

Tuttavia, non so quasi nulla dei container Docker, di come configurare Jenkins o AWS, ecc. Quale sarebbe un buon modo per verificare se la persona che fa domanda può gestire tali compiti?

Sotto-domande: credo che un buon dipendente devops possa configurare la catena di build una volta e dovrebbe funzionare da allora in poi. Posso quindi aspettarmi che sia anche uno sviluppatore dell'azienda (DEVops)? Dato che DevOps è un lavoro relativamente "nuovo", forse è meglio per le piccole aziende condividere un dipendente devops o assumerlo come libero professionista ogni volta che ne hai bisogno?

La mia confusione sul termine deriva da offerte di lavoro come questa, anche qui su stackexchange (= link da cui è stata presa la serigrafia sopra).

Ho trovato questo utile, ma possibile articolo supponente che potresti voler leggere se inciampi su questa domanda: https://hackernoon.com/devoops-some-common-anti-patterns-1850ac2f5074

culture software-engineering

— Tommaso
fonte

3

Poiché DevOps non è un ruolo (è una parola d'ordine in quanto tale), stai assumendo un amministratore di sistema moderno secondo la tua descrizione.

— Tensibai,

5

Sto votando per chiudere questa domanda come fuori tema perché DevOps non è una posizione di ruolo / lavoro

— Tensibai

2

@Tensibal Sono d'accordo con te ma sono anche tentato di lasciare aperta questa domanda in quanto può aiutare a chiarire questo malinteso - e possiamo aspettarci di vedere questa domanda ancora e ancora e ancora e ancora.

— Michael Le Barbier Grünewald

2

@ MichaelGrünewald Aggiungi una risposta chiarendo questo. Se valutato, eviterà che la domanda scompaia, anche se chiusa. Il meglio dei due mondi: chiarisce il problema e rimane visibile come off-topic per il sito, contribuendo a prevenire future domande del genere (che potrebbero essere duplicate ad esso)

— Dan Cornilescu,

3

@Tensibai FWIW, non credo che dovremmo mai chiudere una domanda sulla base del fatto che "DevOps non è un ruolo". Ogni domanda in cui questa confusione è evidente è un'opportunità per chiarire. La risposta alla domanda dovrebbe includere un chiarimento in tal senso e un collegamento a tale domanda. Se chiudiamo le domande solo perché confondono il termine DevOps, alieneremo i nuovi utenti e perderemo l'opportunità di chiarire.

— Dave Swersky,

13

È un'incredulità comune che "DevOps" sia un ruolo in un'azienda. La parola indica semplicemente un cambiamento organizzativo nelle società di software, questo cambiamento può essere brevemente descritto dal “ Lo costruisci, lo esegui! "Coniato da Werner Vogels:

Non è necessario distinguere tra costruzione e gestione e, secondo Werner Vogels, è molto meglio di così:

Assegnare agli sviluppatori responsabilità operative ha notevolmente migliorato la qualità dei servizi, sia dal punto di vista del cliente che dal punto di vista tecnologico. Il modello tradizionale è che porti il tuo software al muro che separa lo sviluppo e le operazioni, lo butti e poi lo dimentichi. Non su Amazon. Lo costruisci, lo esegui. Questo mette gli sviluppatori in contatto con le operazioni quotidiane del loro software. Li mette inoltre in contatto quotidiano con il cliente. Questo circuito di feedback dei clienti è essenziale per migliorare la qualità del servizio.

Questa lezione è interessante, ma questo particolare cambiamento in un'organizzazione non è sempre facile da implementare.

Questo spostamento è in concomitanza con una crescente importanza dell'integrazione continua e dei metodi di consegna. Si noti che queste idee sono molto più antiche della formalizzazione di metodologie "agili", alcune sono già presenti nel rapporto del Comitato scientifico della NATO sull'ingegneria del software pubblicato nel ... 1968!

Mentre la formulazione può essere trascurata, la breve descrizione della proposta DevOps (questo sito) menziona "ingegneri del software":

Sito di domande e risposte Beta per gli ingegneri del software che lavorano su test automatizzati, consegna continua, integrazione e monitoraggio dei servizi e costruzione di infrastrutture SDLC.

Ora, se stai cercando un ingegnere del software che può aiutare il tuo team a iniziare con queste metodologie, coinvolgi questo argomento. Anche se non hai familiarità con questo argomento, segui il messaggio "Lo costruisci! Lo esegui! ”, Puoi iniziare da un problema di programmazione e condurre l'intervista verso domande sulla distribuzione e la manutenzione dell'applicazione.

— Michael Le Barbier Grünewald
fonte

3

La confusione si basa anche su offerte di lavoro come questa: stackoverflow.com/jobs/135988/…

— Thomas

2

Sì, ci sono molte persone o organizzazioni che usano "DevOps" come ruolo. Nessuno può essere incolpato di essere vittima di questo e la tua domanda è utile per chiarire questo, quindi grazie per averlo chiesto, anche probabilmente alla fine verrà chiusa. Spero che questa risposta ti sia utile e che avrai la possibilità di contribuire in altro modo a questo sito o utilizzarlo come fonte di informazioni!

— Michael Le Barbier Grünewald

@ThomasMoors: il tuo precedente (interessante!) Commento dovrebbe essere integrato nella tua vera domanda ... anche se fosse solo per documentare la tua confusione ...

— Pierre.Vriens

@ Pierre.Vriens fatto

— Thomas

1

Sinonimo / relativo "mangia il tuo cibo per cani", non fare qualcosa che non userai

— Tensibai

7

A rischio di ottenere voti bassi, off-topic o persino eresia, ti dirò "Non ascoltare i puristi che ti dicono che DevOps non è un ruolo".

Sei sulla strada giusta. Dovrebbe adattarsi alla tua azienda. Questo è ciò che conta durante l'assunzione.

Se hai bisogno di un DevOps, per funzionare come un DevOps, produrre risultati come DevOps, è un DevOps.

Non lasciare che nessuno ti dissuada altrimenti.
Fai pubblicità comunque.
Intervista comunque.
Noleggia comunque.

In questo caso, scopri di più su DevOps, su come il concetto può adattarsi alla tua azienda, su come si adatta la persona.

Informati meglio sul ruolo che devi svolgere. Cerca le domande che puoi porre. Ci sono molti esempi , anche se non sei un esperto in materia. Qualche buona pazienza e duro lavoro vecchio stile.

Hai bisogno di un dipendente? O libero professionista? Un tuttofare? Solo tu conosci bene la tua azienda.

Crea la tua cultura unica che è la tua interpretazione di DevOps.

— kenchew
fonte

+1 a questo. I puristi sono stati attaccati agli sviluppatori non è una risposta di ruolo da troppo tempo, ma l'industria, le commissioni di lavoro e i recruiter l'hanno già trasformata in una realtà, ed è tempo che la accettiamo per quello che è.

— Grumpyops,

6

"Assumere un DevOps" sarà difficile perché DevOps non è un ruolo. Se riesci a trovare un ingegnere con capacità di sviluppo software e ingegneria, sei sulla strada giusta ..

Tuttavia ,

Il processo di assunzione sarà complicato da alcuni fattori:

Gli ingegneri dell'affidabilità del sito (termine di Google per amministratori / ingegneri con competenze di programmazione) sono rari
Le abilità rare sono costose
Le abilità rare sono ... rare.

La buona notizia è che potrebbe non essere necessario un SRE completo.

Il tuo caso d'uso, per così dire, è assumere ingegneri per stabilire la tua infrastruttura (AWS) e automatizzare le implementazioni (Jenkins.) Queste abilità non sono poi così rare, ma potresti avere difficoltà a trovarle in una sola persona.

Dici anche che tu stesso non hai queste capacità. Questo è un ulteriore fattore complicante. Non hai le competenze necessarie per valutare le competenze dei tuoi candidati. Alla fine è necessario trovare un modo per sviluppare (o assumere, come in un responsabile tecnico) le competenze necessarie per gestire questo tipo di risorsa.

— Dave Swersky
fonte

1

È comune che le persone con risorse umane non abbiano le capacità delle persone che stanno assumendo. Di solito l'idea migliore è di intervistare persone qualificate per avere una valutazione dei candidati

— Tensibai

Volevo dire che sono un buon sviluppatore, ma voglio anche essere circondato da persone che eccellono in altre discipline all'interno dell'azienda, meglio della mia.

— Thomas

1

@ThomasMoors è un'ottima idea. Non preoccuparti troppo, sono sincero di ciò che penso di questo sito, ma sono solo uno in mezzo alla folla. Scusate se ho suonato maleducato a proposito

— Tensibai il

2

Vi sono due possibilità:

Hai bisogno di aiuto per capire quali sono i cambiamenti che la tua azienda deve affrontare nel tuo viaggio verso DevOps.
Sai di cosa hai bisogno e cerchi solo di assumere persone per attuare questa visione per te.

Se hai bisogno di qualcuno che ti aiuti a capire su quali questioni devi concentrarti, c'è davvero una buona compagnia chiamata DORA (DevOps Research and Assessment), che è co-fondata da Dr. Nicole Forsgren, Jez Humble e Gene Kim. Nicole ha condotto il sondaggio sullo stato di DevOps per anni e ha tenuto statistiche dettagliate del settore per anni. Jez Humble è un guru di Continuous Delivery e ha letteralmente scritto il libro su di esso. Gene Kim è l'autore di The Phoenix Project e gli ultimi due sono coautori di The DevOps Handbook . DORA fornisce una valutazione della tua azienda e ti aiuta a rispondere a queste domande.

Se hai una buona idea di dove devi andare e hai bisogno di qualcuno che ti aiuti ad arrivarci, probabilmente ottenere un'agenzia di reclutamento non è una buona idea a questo punto. Vorrei suggerire di andare alla DevOps Enterprise DOES Conference o alla DevOpsDays Conference locale e parlare con le persone nei corridoi. Cerca consigli e magari apri uno stand, crea un poster sull'assunzione.

La seconda opzione sarebbe quella di venire qui e iniziare a porre quelle domande in questo forum e cercare gli esperti che rispondono a loro e vengono votati. Molti di questi potrebbero effettivamente cercare un lavoro o una sfida. A volte anche porre domande sulla tua situazione attuale e sul caso d'uso qui potrebbe indicarti la giusta linea di azione.

— Jiri Klouda
fonte

2

Cerco un numero di cose nelle persone che ho assunto in questo spazio.

un livello minimo di 'ha' di agile (google shu, ha, ri per l'adozione agile se ne hai bisogno di più)
esperienza pratica tecnica - codifica, automazione, ecc., ma sono agnostico per strumenti e linguaggio
personalità dell'apprendimento: prendono l'iniziativa per apprendere costantemente
curiosi e non cercando di dare la colpa - possono accettare il fallimento come lezione di apprendimento
sono un giocatore di squadra di cui ci si può fidare ed avere fiducia poiché la sicurezza psicologica è il fattore di successo numero uno per le squadre ad alte prestazioni
possono allenare e mentore - condividono le loro conoscenze senza essere elitari - prima donnas non ha posto in squadre ad alte prestazioni
hanno abilità sociali "sufficienti" poiché devono essere membri del team e comunicare bene

Devo ancora trovare un candidato perfetto, quindi è sempre un qualche tipo di compromesso. Nel mondo di oggi, ho esaminato oltre 65 curriculum che erano "prequalificati" come candidati da agenzie e risorse umane, scartati 50 o più come non conformi ai miei requisiti minimi su carta, intervistati 15+ e assunti 3. Questo processo mi ha portato al parte migliore di 9 mesi.

— icewav
fonte

E per completare, ciò che mi manca nel tuo post è una descrizione di ciò che ritieni mancasse, dicendo che mancavano alcune indicazioni su come presentare le cose per coprire queste carenze non aiuta a ottenere una situazione migliore

— Tensibai

Se le persone non presentano un curriculum adeguato ai requisiti minimi di pubblicazione del lavoro, allora non soddisfano il mio requisito minimo per avanzare ulteriormente nel processo. Se una persona vuole davvero essere considerata per una posizione, allora deve mostrarla con un certo sforzo da parte sua. Come responsabile delle assunzioni è il mio punto di vista che conta perché so cosa sto cercando.

— icewav,

Sembra un buon consiglio aggiungere "pubblicare un curriculum adeguato al lavoro". È più facile da controllare che indovinare le tue esigenze sulla carta. se i tuoi requisiti sono i punti elenco sopra indicati, forse "i miei requisiti sopra riportati sul documento" potrebbero essere una formulazione migliore

— Tensibai

Purtroppo l'elenco puntato sopra è ciò di cui ho bisogno per discernere dall'intervista. I miei requisiti minimi e i miei requisiti preferiti sono chiaramente indicati nelle offerte di lavoro che faccio e cambiano in base alle competenze di cui ho bisogno per completare una squadra. Il richiedente di solito ottiene un colloquio se soddisfano i requisiti minimi e quasi sempre se soddisfano i requisiti minimi più alcuni dei requisiti preferiti. Anche se questo può sembrare vago, sono abbastanza specifico in ogni offerta di lavoro che faccio su ciò che sto cercando in un candidato di successo.

— icewav

Esiste una percentuale di candidati che dichiarano falsamente ciò che è nel loro curriculum che scopre che i semplici fatti vengono scoperti. Questi candidati non ricevono mai un'intervista con me. Esempio: pretendi di avere una certificazione Scrum Alliance, poiché ho alcune delle loro certificazioni, posso accedere e controllare la tua.

— icewav

1

A parte le altre domande, credo che la seguente risposta sia ancora mancante: voglio riassumere ciò che ho imparato finora in un tono per lo più umile:

Presentare le abilità DevOps alla tua squadra probabilmente non è abbastanza (vale a dire che non puoi assumere un DevOps)! (Come chiedere a un livello inferiore quali sono gli strumenti migliori per far funzionare le cose, qui sembra che la tua organizzazione funzioni).

La vera domanda è: qual è la tua strategia di trasformazione digitale delle organizzazioni e quanto bene DevOps ti aiuterà a creare più valore per i clienti e ridurre i costi , pur mantenendo un buon clima?

DevOps rivela la necessità di cambiamento e il cambiamento richiede assumersi la responsabilità.

Immagina che una situazione funzionasse. DevOps potrebbe introdurre pressioni su altri team. DevOps è talvolta il risultato dell'evoluzione dall'integrazione agile e continua: quali sono le tue risorse qui?

— Peter
fonte