Quali sono i segni e i segnali tipici di un team DevOps a corto di personale? Come giustificheresti / spiegheresti una richiesta per una nuova aggiunta a una squadra?

Mi piacerebbe mantenere la domanda generica, ma ecco alcune informazioni aggiuntive:

Al momento abbiamo 2 specialisti DevOps che lavorano insieme come una squadra, ma le richieste, la quantità e la complessità dei prodotti sono in crescita. Stiamo pensando di richiedere una nuova aggiunta al team, ma abbiamo delle difficoltà a spiegare e dimostrare perché sarebbe una buona idea.

Ci sono quattro ragioni principali per cui puoi sentire che la tua squadra è a corto di personale:

1. Cattiva organizzazione e pianificazione del lavoro
2. Fare lavoro dovrebbe essere qualcun altro
3. Fare un lavoro che non dovrebbe assolutamente essere fatto
4. Essere a corto di personale

Inizia con una revisione dei primi tre punti. Leggi il Progetto Phoenix sulle idee su come fare per primo. Chiediti ogni compito con cui aiuti chiunque, se deve essere svolto e se sei tu che dovresti svolgere il compito o se dovresti semplicemente consentire a chiunque ne abbia bisogno di farlo da solo. Questo ti darà una documentazione sul perché tutto il lavoro che fai è necessario.

Prossima recensione dei quattro tipi di lavoro menzionati nel progetto Phoenix:

1. Progetti aziendali : cosa fai per gli altri team dell'organizzazione
2. Progetti interni : cosa fai per semplificare il tuo lavoro in futuro
3. Manutenzione programmata : cosa fare per tenere accese le luci
4. Interruzioni non pianificate : cosa fai perché qualcosa è andato storto

Se il lavoro del tuo team è sostenibile, trascorrerai all'incirca la stessa quantità di tempo su ciascuno dei quattro. Se il lavoro non pianificato inizia a insinuarsi vicino al 50% del tempo, è un segno che sei decisamente a corto di personale.

Dovresti essere in grado di assumere per rimanere circa una persona davanti al lavoro non pianificato raggiungendo il 25% del tuo tempo, altrimenti una persona in partenza invierà l'intera squadra in una contropunta dalla quale potresti non recuperare mai. Il provisioning eccessivo di persone e tecnologia ha gli stessi motivi e benefici.

Background: Oltre a fornire supporto alla nostra infrastruttura attuale e ai nostri sviluppatori, facciamo una pianificazione mensile come team DevOps per ciò che vogliamo realizzare oltre ad aiutare i team di sviluppo all'interno di sprint e nuovi progetti che vengono lanciati. Tuttavia, durante il mese notiamo spesso cose extra che devono essere fatte e migliorate, che poi aggiungiamo al nostro backlog. Siamo anche responsabili e assistiamo con varie altre cose che esulano dal nostro campo di applicazione, ma assistiamo il business dove possiamo :)

Risposta : Non appena noti che non ti stai preparando o rimandando molte attività, in particolare la manutenzione, penso che sia un buon indicatore (da quello che ho sperimentato). Inoltre, più nuovi progetti e team di sviluppo entrano nel sottile gruppo di DevOps, più persone saranno necessarie.

È semplicissimo farsi coinvolgere quotidianamente completando le attività, ma credo sia estremamente importante (anche una volta al mese) fare un passo indietro e valutarlo.

In realtà prendo una pagina dal Manuale SRE su questo, che penso sia molto rilevante. Le specialità DevOps non sono pensate per crescere orizzontalmente con un'organizzazione. Piuttosto, se vedi che le cose non vengono fatte, è un segnale che non stai abilitando correttamente gli sviluppatori al self-service.

Valuta i tuoi processi e vedi come si allineano ai Principi DevOps comunemente accettati e quanto bene stai seguendo le migliori pratiche del settore.

Suppongo che questo team di due persone stia passando da un progetto all'altro e stabilendo lì cose DevOps (creando pipeline CI / CD, supportando gli altri sviluppatori che creano Dockerfile o qualunque tecnologia tu stia usando). In altre parole, digitare 3, 4, 5 o 6 come in http://web.devopstopologies.com/ .

In questo caso, un segno di carenza è semplicemente troppo carico di lavoro per quei due; troppi progetti che richiedono i loro servizi; troppi biglietti; col tempo; stress, esaurimento. Questi fattori dovrebbero essere sufficienti per consentire a una leadership responsabile di aggiungere più capacità. Non vedo un segno specifico DevOps in questo, è solo una funzione che è a corto di personale.

Un altro segno per cambiare qualcosa è se guardi bene e se noti che stai creando un "silo DevOps", in cui tutto il know-how DevOps è concentrato in quei due ragazzi / ragazze, e tutti gli altri si appoggiano semplicemente perché quei due stanno "facendo DevOps". Non è questo il punto di DevOps. In questo caso, pensa all'aspetto culturale e modificalo in modo che diventino più evangelisti / insegnanti / allenatori per le altre squadre.

In entrambi i casi, la ragione più profonda del perché avere DevOps in primo luogo è una buona cosa (la roba buona in generale) dovrebbe essere chiara alla direzione superiore. Se non riesci a trasmettere quel messaggio, riduci il lavoro del tuo team, spostandolo sui normali Dev / Ops (come dovrebbe essere il caso, comunque).

Avevo l'impressione che DevSecOps fosse una mentalità, non una squadra - se hai una "squadra" di Dev (Sec) Ops, stai sbagliando ... Sto cercando di avvolgere la testa mettendo due "ingegneri DevOps" insieme e chiamandoli "DevOps Team".

Abbiamo team di sviluppo, SCM, Ingegneri per la sicurezza delle applicazioni e dei sistemi che lavorano tutti insieme per un modello di distribuzione / rilascio rapido per spingere il codice e le modifiche di configurazione / sistema fino a un determinato punto finale - stadiazione o produzione

Questo non ha nulla a che fare con alcun ingegnere "devOps", in quanto tale.

Raggruppamento di compiti

Un approccio che abbiamo usato in passato in situazioni simili è quello di organizzare il lavoro di una squadra in 4 gruppi principali di attività e allocare l'equivalente di 2 ETP (equivalenti a tempo pieno) per (provare a) completare quelle attività. Nel nostro caso era correlato all'esecuzione di un helpdesk SCM in un ambiente mainframe, con circa 300 sviluppatori che chiedevano ogni tipo di aiuto / intervento da quei 2 ETP. I gruppi di compiti sono organizzati in 4 possibili priorità:

• Compiti delle priorità 1 e 2 devono essere completati (non sono possibili scuse / negoziazioni)
• Le attività di priorità 3 devono essere completate " non appena il tempo lo consente".
• Le attività prioritarie 4 devono essere completate " se il tempo lo consente".

Continua a leggere per maggiori dettagli sul tipo di attività in ciascuno di quei 4 gruppi ...

Descrizioni delle attività

Priorità 1: utilizzare l'helpdesk

• Da esperti facilmente accessibili e sempre disponibili.
• Tramite telefono, e-mail o sistema di biglietteria durante l'orario di lavoro.
• Conforme agli SLA predefiniti.
• Registrazione basata su ITIL di tutte le chiamate dell'helpdesk con report periodici di tutte le chiamate.
• Applica personalizzazioni di emergenza (soluzioni alternative) per problemi critici.

Priorità 2: servizi di sorveglianza

• Disponibilità su richiesta 24 ore su 24, 7 giorni su 7.
• Conforme agli SLA predefiniti.
• Segnalazione di tutte le chiamate di guardia.
• Escalation gestionale dove necessario.

Priorità 3 - Manutenzione ordinaria

• Amministrazione.
• Imbarco dell'applicazione.
• Faccende domestiche.
• Miglioramenti delle prestazioni.
• Gestione dello spazio.
• Ottimizzazione del consumo di risorse.
• Suggerisci miglioramenti per le personalizzazioni per ridurre il numero di chiamate all'helpdesk e / o guardare gli interventi di servizio.

Priorità 4 - Correzioni e miglioramenti

• Creare e gestire la documentazione per l'utente.
• Test QA di nuove personalizzazioni.
• Sviluppare e implementare richieste di miglioramento.
• Partecipa al test DRP.

Valutazione

Se stai usando un approccio come descritto sopra, possono accadere varie cose (che succederanno!):

• Se il team è a corto di personale, probabilmente la maggior parte del tempo passerà alle attività di priorità 1 e 2, mentre potrebbe richiedere del tempo per ottenere le attività di priorità 3 ... e le attività di priorità 4 potrebbero soffrire la fame (sembra che non ci sia mai tempo per quei compiti).
• Più c'è (diventa) il tempo disponibile per " investire " in attività prioritarie 4, più tempo sarà necessario per le attività prioritarie 1 e 2, in modo da poter "investire ancora più tempo (del budget disponibile di 2 ETP) "nelle attività prioritarie 4.
• Sarai sorpreso di vedere come, dopo un po ', il numero di attività prioritarie 1 e 2 diminuirà. E se fai un reporting adeguato su tali compiti, è qualcosa che la direzione ama ascoltare. Nel nostro caso quel numero è sceso da circa 300 al mese a meno di 100 al mese ...
• Se tuttavia i 2 ETP sembrano non avere mai (o quasi) il tempo per le attività prioritarie 4, allora hai una spiegazione e una prova perfette per la tua gestione ... che sei a corto di personale.