CheckOps in azione
I team possono eseguire CheckOps direttamente in Compass. Compass offre ai team un unico punto dove possono vedere facilmente le metriche e gli obiettivi e annotare le azioni che intendono intraprendere.
Report CheckOps settimanale di esempio con metriche, avvisi e azioni programmate.
Puoi eseguire un report CheckOps settimanale anche in Trello.
Cosa ti servirà
Remoto
Videoconferenza con condivisione dello schermo
Strumento di collaborazione digitale
In presenza
Modello di report CheckOps in Compass
Lavagna
Pennarelli
Note adesive
Timer
Modelli opzionali
Modelli Atlassian
Questa strategia funziona in modo ottimale con la funzione CheckOps di Compass (scopri in che modo il tuo team può iniziare a utilizzare CheckOps). Se non hai ancora iniziato a utilizzare Compass, puoi comunque iniziare a monitorare subito lo stato del tuo team in Trello.
Istruzioni per eseguire questa strategia
Questa strategia è progettata per i team che sviluppano, distribuiscono ed eseguono software.
1. Prepara la tua strategia 30 min
Stabilisci gli obiettivi del team DevOps
L'intero team definirà gli obiettivi insieme.
- Accedi a Compass e vai alla funzione CheckOps o prepara un modo alternativo per tenere traccia dei tuoi obiettivi.
- Identifica gli aspetti che vuoi cambiare o migliorare nelle tue pratiche operative o di sviluppo.
I requisiti aziendali possono guidare gli obiettivi operativi:
- Hai la necessità di fornire il servizio più veloce possibile ai clienti o di essere disponibile 24 ore su 24, 7 giorni su 7? Stabilisci obiettivi DevOps per la latenza, il throughput o la disponibilità.
Gli obiettivi operativi possono essere forniti anche dal team:
- I membri del team sono stanchi di essere svegliati nel cuore della notte a causa di avvisi e imprevisti che non possono gestire? Stabilisci un obiettivo per ridurre al minimo il numero di imprevisti e avvisi per i quali non è possibile intraprendere alcuna azione.
- Hai l'impressione che il tempo di attesa per la revisione delle richieste pull sia eccessivo? Stabilisci un obiettivo operativo relativo alla quantità di tempo durante il quale le richieste pull devono rimanere aperte.
Inizia con un numero limitato di obiettivi DevOps. Punta alla semplicità e assicurati di raccogliere le informazioni giuste per monitorare l'avanzamento. Se puoi, inizia con uno o più obiettivi uguali per tutti i tuoi servizi: in questo modo dovrebbe essere più facile individuare in modo mirato i dati che il tuo team esaminerà in ogni riunione.
Assicurati che gli obiettivi DevOps siano misurabili
Definisci obiettivi misurabili in modo da sapere con certezza se li hai raggiunti o meno.
- Le metriche operative dei servizi sono la strada da seguire: usa uno strumento di osservabilità (ad esempio, Splunk Observability, DataDog, Grafana, ecc.) e descrivi in modo esplicito la metrica che vuoi migliorare.
- Anche le metriche di sviluppo per i repository sono importanti. Puoi utilizzare Jira Software o Compass per monitorarle in modo ottimale.
Durante questo esercizio, potresti renderti conto che non stai misurando gli aspetti che in realtà desideri migliorare. Non c'è problema! Una degli elementi di azione per la tua prima riunione CheckOps può essere l'aggiunta della metrica DevOps pertinente. Potrai così utilizzarla nelle riunioni future.
Scrivi i tuoi obiettivi DevOps
Dopo aver concordato con il team gli obiettivi che hai definito, scrivili e condividili con tutti: saranno i tuoi obiettivi operativi dichiarati. Successivamente, crea un documento Confluence di base che sia facilmente accessibile e a elevata visibilità, e memorizza i tuoi obiettivi DevOps in quella posizione. Se lavori in Compass, puoi fissare gli obiettivi nelle scorecard.
Gli obiettivi DevOps possono (e devono) cambiare nel corso del tempo. Man mano che raccogli una maggiore quantità di informazioni, potrai prendere decisioni più informate sui tuoi obiettivi o potresti scoprire che i tuoi obiettivi aziendali o operativi si evolvono. Tuttavia, cerca di non aggiungere troppi obiettivi e metriche DevOps contemporaneamente, perché potrebbe essere dispersivo per il team e causare il mancato raggiungimento dei risultati desiderati. Ti consigliamo di aggiungere al massimo tre obiettivi in un periodo di tre-sei mesi.
Ecco alcuni esempi di obiettivi che il tuo team potrebbe scegliere:
- Aumentare la durata ciclo delle richieste pull o la durata ciclo totale: è utile se il tuo team non rispetta spesso le scadenze.
- Ridurre il numero di avvisi o imprevisti che il tuo team riceve ogni settimana: è utile se si verificano troppe interruzioni del lavoro del team.
- Rallentare la frequenza di distribuzione: è utile se il tuo team riceve troppi imprevisti.
Man mano che il tuo team si rafforza, potresti renderti conto che la fase di preparazione diventa più breve.
SUGGERIMENTO: METRICHE DEVOPS CHIAVE
Consigliamo ai team di misurare sempre le seguenti metriche:
- Lead time per le modifiche
- Tasso di errore delle modifiche
- Frequenza di distribuzione
- Tempo medio di ripristino
2. Raccogli i dati 15 minuti
Dopo che il team ha stabilito gli obiettivi, il relatore dovrà raccogliere i dati. Tieni presente che, anche se potrebbe non essere necessario eseguire la prima fase ogni settimana, i dati dovranno comunque essere raccolti settimanalmente.
Tieni un log
Tra una riunione di CheckOps e quella successiva accadranno eventi importanti che i tuoi strumenti non sono in grado di acquisire. Considerato che la memoria umana è fallibile, è opportuno annotarli in modo da poterne discutere durante la riunione successiva.
Se fai parte di un team remoto, crea un nuovo report CheckOps per ogni settimana in cui puoi aggiungere eventi importanti, quindi condividilo con i membri del team appropriati. Se utilizzi Compass, la piattaforma per l'esperienza di sviluppo di Atlassian, puoi avviare la pratica CheckOps in modo semplice e veloce dalla pagina Dettagli sullo stato.
- Il personale reperibile è stato chiamato e ha scoperto che l'avviso era un falso positivo? Questo influisce sicuramente sull'esperienza di sviluppo del team, quindi prendine nota e condividilo con il gruppo in modo da poter apportare miglioramenti in futuro.
- Si è verificato un imprevisto, un evento di distribuzione non riuscito o una richiesta pull per la cui unione è stato necessario troppo tempo? Prendine nota durante la settimana in modo che il team non debba in seguito ricostruire l'accaduto facendo affidamento solo sulla memoria.
Preparati per la revisione
As the on-call rotation ends (or right afterwards), the presenter should prepare the CheckOps report for that rotation. At its simplest, the report should include:
- Un elenco dei servizi/componenti per i quali desideri eseguire CheckOps.
- La misurazione (rispetto al tuo obiettivo) per ciascuno di questi componenti.
- Un segno di spunta o una X per sapere se l'obiettivo è stato raggiunto o meno.
- A mitigation plan for any unmet goals, as well as notes from the presenter about why the goal wasn't met.
- Una sezione per registrare le azioni di follow-up.
- Un riepilogo di eventuali altri eventi o anomalie.
È fondamentale che le azioni di follow-up vengano registrate nel report CheckOps. Diversamente, utilizza un report di stato quando desideri un ciclo di feedback che favorisca il miglioramento.
3. Esegui una riunione di revisione CheckOps 30 min
Ognuno ha un ruolo
Adotta un approccio interattivo. Tutti i membri del tuo team DevOps, che svolgono un turno in quanto reperibili, dovrebbero partecipare a questa riunione e ognuno dovrebbe avere un compito:
- Relatore: la persona che ha appena completato la rotazione dei servizi di reperibilità deve presentare il report CheckOps e i relativi risultati. Se nel team non sono presenti incarichi di reperibilità, nomina una persona che prenda appunti sugli eventi che accadono durante la settimana e che possa presentare i risultati durante l'esecuzione della strategia.
- Prossima reperibilità: questa persona deve prestare molta attenzione alle osservazioni del presentatore, inclusi i ticket che ha riscontrato o le possibili aree a rischio che potrebbero ripresentarsi nella prossima rotazione di reperibilità.
- Leader: The leader is the person (or people) who can help the team prioritize actions and ensure followup. When an action requiring follow up arises, the leader should help make sure the right person (or people) owns the action and will be able to see it through to resolution.
- Other on-call team members and component owners: These are the people who are also in the on-call rotation and/or are intimately familiar with the services or components that are being operated.
Condividere e discutere i risultati
Il presentatore illustrerà al gruppo ogni servizio/componente e spiegherà se gli obiettivi sono stati raggiunti o meno, oltre al motivo. Discuterà di eventuali anomalie o eventi operativi verificatisi per il determinato servizio e condividerà le sue osservazioni e analisi. Il compito del gruppo è quello di porre domande e contribuire a fornire suggerimenti per azioni successive.
Collaborare per trovare modi per garantire che tutti i servizi/componenti del gruppo DevOps raggiungano i rispettivi obiettivi: questo è un esercizio che coinvolge tutto il gruppo.
Annota le azioni che ogni membro del gruppo intraprenderà e crea richieste nel tuo backlog durante la riunione.
SUGGERIMENTO: AGIRE, NON REAGIRE
Quando il tuo gruppo è responsabile di raggiungere obiettivi operativi o di sviluppo, può essere facile cedere alla tentazione di reagire. Che si tratti di affidabilità, velocità di consegna o qualità del codice, l'approccio basato sui dati promosso da CheckOps dovrebbe consentire al tuo gruppo di raggiungere i tuoi obiettivi DevOps, migliorare l'esperienza degli sviluppatori e crescere continuamente.
Follow-up
Iterazione
Ti suggeriamo di eseguire ogni settimana CheckOps Play e di allinearlo al programma di reperibilità del gruppo. I passaggi 2 e 3 si ripetono ogni settimana, mentre il primo potrebbe non dover essere necessariamente eseguito con la stessa cadenza. Man mano che metti in pratica Play nel tempo, i tempi per passaggi 1 e 2 si accorceranno. Quando il gruppo eseguirà CheckOps Play da diverse settimane, potrebbero esserci opportunità per espandere e far crescere la tua attività in modo da includere altre aree di interesse. Ad esempio, potresti misurare metriche di qualità come la copertura del codice, metriche aziendali come gli utenti attivi ogni settimana per una determinata funzionalità o qualsiasi altra cosa che renderebbe più sano il tuo gruppo.
Rivalutare gli obiettivi operativi
Over time, the original DevOps goals you set may no longer meet your team's needs. Maybe the business needs changed, or the targets became more or less aggressive. If so, run step one, update your stated operational objectives, and continue your practice. You can also expand the scope of your CheckOps practice, if necessary, to cover more services or components or other aspects of your operations practice.
Automatizzare la segnalazione
Man mano che il tuo ambito si espanderà, scoprirai di voler dedicare più tempo all'analisi e meno alla rendicontazione. Trova modi per automatizzare la raccolta delle metriche chiave e la generazione dei tuoi report CheckOps. Questo migliorerà sia la produttività che l'esperienza degli sviluppatori del tuo gruppo man mano che il lavoro di segnalazione diventerà sempre più automatizzato.
Se aggiungi l'automazione, assicurati comunque di dedicare ancora del tempo ad analizzare i dati che stai raccogliendo e preparando per la riunione CheckOps. Gli Atlassiani utilizzano le metriche di Compass per aiutarti in questo senso e abbiamo integrato la nostra esperienza CheckOps all'interno del prodotto per aiutare anche te a fare lo stesso.
Esempi di obiettivi operativi
Riflessioni
Ecco alcuni esempi di obiettivi operativi in base ai quali il tuo gruppo può strutturare la tua pratica CheckOps, a seconda delle tue responsabilità:
Delivery types | Possible objectives |
|---|---|
Microservice |
|
On-call team |
|
Software delivery |
|
Mobile application |
|
Dal nostro team al tuo
Rimani aggiornato sulle strategie, i consigli e i trucchi più recenti con la nostra newsletter mensile.
