In che modo DevOps sta assumendo l'ottimizzazione del processo attraverso il paradigma CALMS?

Gran parte del reclutamento di DevOps segue le linee di corrispondenza delle parole chiave, il che porta a mio avviso al solo interesse tecnologico.

Ora, DevOps è molto più di una semplice tecnologia e DevOps Engineer non è solo un amministratore di sistema migliore con alcune capacità di programmazione.

Il ruolo / profilo senior di DevOps significa per me offrire anche anzianità in molte altre basi e pratiche oltre alle capacità di ingegneria di infrastruttura e software come Lean, Measurement ed essere aperto e comunicativo (chi chiede alle assunzioni di DevOps le loro capacità comunicative, onestamente ?!)

Quindi, un annuncio di lavoro / colloquio può essere più efficiente in qualche modo, ad esempio applicando anche le categorie CALMS ? - Portare a domande come "ora, come si applicano i principi lean? Come sono stati affrontati gli aspetti culturali nei recenti progetti DevOps?"

Ulteriore elaborazione:

• C ulture (es. Strategie per la gestione dei conflitti e attitudine ai fallimenti, proprie e altrui)
• Un utomazione (qui si interroghi su Puppet / Docker ecc competenze)
• L ean (fondamenti di Lean? Tipi di rifiuti?)
• M semplificazione (chiedi strumenti come JMeter ma vai anche a cose come campionamento, modellizzazione dei dati ..)
• S haring (ovviamente gestione della conoscenza e strumenti adeguati)

AGGIORNAMENTO - quindi perché i datori di lavoro / i recruiter non strutturano l'intervista di CALMS come mostrato di seguito (inoltre, la sezione "automazione" potrebbe essere formulata lungo il modello di toolchain DevOps ( collegamento del documento, di sola lettura )?

Nota a margine: quindi la cultura, ad esempio, in realtà non è più solo una soft skill, per DevOps è una delle competenze chiave, come tutte le altre in questo dominio.

Questa è un'idea geniale, anche a causa di Daniel Kahneman che ha dimostrato che se si divide un singolo punteggio in 5 punteggi pesati e si aggiungono criteri numerici e limiti a quelli, si ridurrà significativamente la distorsione . Puoi progettare non solo il punteggio del curriculum, ma l'intero processo di assunzione, con schermi del telefono, interviste in loco, tutto in questo modo. Ridurrebbe significativamente la propensione intrinseca degli intervistatori. In realtà abbiamo iniziato a fare qualcosa di simile per tutte le assunzioni.

Ovviamente, all'interno di ogni area, dovresti aggiungere peso a ciò che è importante per l'azienda per la posizione, ma stai assumendo un ingegnere a tutto tondo e vuoi qualcuno che proporrà importanti cambiamenti al modo in cui opera la tua organizzazione, non stai semplicemente assumendo qualcuno con competenze specifiche per lavorare in un'area limitata. Molte persone vedono semplicemente questo ruolo come un ingegnere del rilascio e della costruzione più pagato e, se è così, è quello che dovresti assumere e pubblicizzare.

Per un noleggio DevOps, suggerirei di sostituire il Lean con l'apprendimento. È originariamente CAMS e anche se alcuni lo estendono a CALMS per includere Lean, questo è un po 'restrittivo in quanto DevOps si basa su molto più di un semplice Lean. Sono anche le idee di Deming sulla variazione della causa speciale e comune e il pensiero del sistema, l'equilibrio di Nash (se ciascuno si ottimizza per se stesso, il risultato potrebbe essere non ottimale, rispetto a quando tutti includono l'interesse del gruppo), Shewhart's Statistical Process Control , Goldratt's Teoria dei vincoli , Anti-Fragilità di Taleb e molti altri.

Ciò consentirebbe anche di includere la partecipazione a conferenze in Apprendimento e presentazioni a conferenze o Meetup come condivisione. In una posizione in cui non fai sempre parte di un team o la tua azienda potrebbe non essere abbastanza grande da avere i tuoi colleghi come tuoi colleghi, è ancora più importante stabilire e mantenere relazioni fuori dal posto di lavoro e opportunità di apprendimento. Generalmente li abbiamo raggruppati sotto Cultura.

Personalmente metterei sotto Cultura le competenze trasversali necessarie per essere efficaci nel migliorare i processi della tua organizzazione. CMMI , Kanban , limiti Work in Progress , pratiche Agili, ecc.

JIRA sembra più uno strumento di condivisione e Git è più strettamente legato all'automazione.

MODIFICARE

Credo che ciò dipenda da un'organizzazione all'altra e da cosa dovrebbe fare un DevOps / Senior DevOps, quindi la tua prima frase è accurata al 100%. Perché, un DevOps dovrebbe essere in grado di utilizzare un set di strumenti che l'azienda utilizza e anche di migliorare o apportare un nuovo set di strumenti che consente all'azienda e ai suoi sviluppatori di lavorare più velocemente e di sprecare di meno.

A mio avviso, un DevOps dovrebbe avere forti abilità SysAdmin e ovviamente capacità di codifica come Puppet, Chef, Python, Bash sarà ampiamente utilizzato così come una certa conoscenza del codice che va sui server almeno per essere in grado di eseguire debug minori sul perché l'applicazione non si comporta come previsto da un ambiente all'altro.

Ora, come Senior DevOps, è possibile applicare CALM, tuttavia, i principi Lean e Measurement potrebbero / potrebbero non essere applicabili. Ad esempio, stiamo sviluppando applicazioni usando Chef / Puppet / Ansible per automatizzare le cose banali e mantenere tutto sincronizzato che ovviamente fa risparmiare tempo e produce meno sprechi .

Per quanto riguarda la misurazione, non sono sicuro che sia applicabile nella maggior parte dei casi. Tuttavia, gli altri principi CALM fanno parte di una posizione DevOps.

Avere buone capacità comunicative è importante anche come DevOps, ma più importante come DevOps senior perché dovrai non solo trattare con il tuo team e condividere conoscenze e con gli sviluppatori poiché sei lì per supportarli, ma potresti anche dover creare report e mantenere le presentazioni di fronte alla direzione.

Mi piace il foglio di calcolo che hai aggiunto ed è bello avere un sistema a punti, tuttavia alcune aziende stanno anche aggiungendo più competenze / tecnologie in un annuncio di lavoro di quanto richiesto.

Inoltre, dopo un'intervista telefonica (se ce n'è una) trovo utile che in un'intervista ti vengano dati alcuni problemi per risolvere o almeno mostrare il tuo processo di debug e come ti comporterai in determinate situazioni. Personalmente, non mi piacciono i test scritti in quanto credo che ci siano "n" modi per risolvere un problema, e inoltre, a volte Google è tuo amico, poiché non ti aspetti che tu sappia tutto a memoria.

Come DevOps / DevOps senior credo che ci sia una linea tra le applicazioni utilizzate e la conoscenza. Potresti essere fantastico nell'utilizzare questi nuovi / vecchi strumenti o scrivere codice, ma quando si tratta di debug o semplicemente di capire quale sia il problema con un server, il lavoro di Jenkins potrebbe non essere in grado di farlo.

Infine, il foglio di calcolo presentato penso che sia un modo per valutare una conoscenza DevOps anche per una posizione senior che potrei aggiungere lì alcune abilità interpersonali e gestionali per completarlo.

E quando si tratta del processo di selezione, puoi dare un'occhiata al foglio di calcolo e scegliere la persona con un punteggio che ritieni sia quello giusto per la tua organizzazione, oltre a tenere presente il suo comportamento durante l'intervista e il modo in cui ha presentato / risposto a tali domande.