CheckOps en action
Les équipes peuvent exécuter CheckOps directement dans Compass. Compass offre aux équipes un espace unique où elles peuvent facilement consulter les métriques et les objectifs, et noter les mesures qu'elles prévoient de prendre.
Un exemple de rapport CheckOps hebdomadaire contenant des métriques, des alertes et des actions planifiées.
Vous pouvez également exécuter un rapport CheckOps hebdomadaire dans Trello.
Ce dont vous aurez besoin
À distance
Vidéoconférence avec partage d'écran
Outil de collaboration digitale
En personne
Modèle de rapport CheckOps dans Compass
Tableau blanc
Marqueurs
Post-its
Chronomètre
Modèles facultatifs
Modèles Atlassian
Ce scénario est idéal avec la fonctionnalité CheckOps dans Compass (découvrez comment aider votre équipe à se lancer avec CheckOps). Si vous n'avez pas encore commencé à utiliser Compass, vous pouvez toujours suivre la santé de votre équipe sans plus attendre dans Trello.
Instructions pour exécuter ce scénario
Ce scénario est conçu pour les équipes qui développent, livrent et exécutent des logiciels.
1. Préparez votre pratique 30 min
Définissez les objectifs de votre équipe DevOps
Toute l'équipe fixera des objectifs ensemble.
- Connectez-vous à Compass et accédez à la fonctionnalité CheckOps, ou préparez un autre moyen de suivre vos objectifs.
- Identifiez ce que vous souhaitez modifier ou améliorer dans vos pratiques de développement ou opérationnelles.
Les exigences métier peuvent orienter vos objectifs opérationnels :
- Avez-vous besoin de fournir le service le plus rapide possible à vos clients ou devez-vous être disponible 24 h/24, 7 j/7, 365 jours par an ? Définissez des objectifs DevOps en termes de latence, de débit ou de disponibilité.
Les objectifs opérationnels peuvent également venir de l'équipe :
- Votre équipe en a-t-elle assez d'être réveillée à des heures indues en pleine nuit par des alertes et des incidents sur lesquels elle n'a aucune prise ? Définissez un objectif pour limiter le nombre d'incidents et d'alertes non exploitables.
- Trouvez-vous que les délais d'examen des pull requests sont trop longs ? Définissez un objectif opérationnel pour déterminer combien de temps vos pull requests resteront ouvertes.
Commencez par un petit nombre d'objectifs DevOps. Optez pour la simplicité et veillez à recueillir les bonnes informations pour suivre votre avancement. Si possible, commencez par le ou les mêmes objectifs dans tous vos services. Cela devrait permettre de mieux cibler les données que votre équipe examinera à chaque réunion.
Veillez à ce que vos objectifs DevOps soient mesurables
Définissez vos objectifs de manière mesurable afin de savoir avec certitude si vous les avez atteints ou non.
- Les métriques opérationnelles de vos services constituent la solution : utilisez un outil d'observabilité (par exemple, Splunk Observability, DataDog, Grafana, et plus encore) et décrivez explicitement la métrique concernée.
- Les métriques de développement de vos dépôts sont également importantes. Vous pouvez utiliser Jira Software ou Compass pour les suivre au mieux.
Au fil de cet exercice, vous vous rendrez peut-être compte que vous ne mesurez pas ce que vous souhaitez réellement améliorer. Pas de problème ! L'un des éléments d'action pour votre première réunion CheckOps peut être d'ajouter la métrique DevOps pertinente. Une fois cela fait, vous pourrez l'aborder lors de prochaines réunions.
Notez vos objectifs DevOps
Une fois que l'équipe est d'accord avec les objectifs définis, notez-les et partagez-les avec tout le monde. Ce sont vos objectifs opérationnels déclarés. Ensuite, créez un document Confluence de base facilement accessible et très visible et indiquez-y vos objectifs DevOps. Si vous travaillez dans Compass, vous pouvez définir vos objectifs dans des cartes de performance.
Vos objectifs DevOps peuvent (et doivent) évoluer au fil du temps. Au fur et à mesure que vous collectez plus d'informations, vous pourrez prendre des décisions plus éclairées concernant vos objectifs, ou vous constaterez peut-être que vos objectifs métier ou opérationnels évoluent. Cependant, évitez d'ajouter trop d'objectifs et de métriques DevOps à la fois, car vous risquez d'affecter la concentration de votre équipe et de ne pas atteindre les résultats souhaités. Nous recommandons un maximum de trois objectifs sur une période de trois à six mois.
Voici quelques exemples d'objectifs pour votre équipe :
- Augmenter votre pull request ou votre durée de cycle totale : utile si votre équipe ne respecte souvent pas les délais.
- Réduire le nombre d'alertes ou d'incidents que votre équipe reçoit chaque semaine : utile si le travail de votre équipe est trop souvent perturbé.
- Ralentir la fréquence de vos déploiements : utile si votre équipe reçoit trop d'incidents.
Au fur et à mesure que les performances de votre équipe s'améliorent, la phase de préparation peut se raccourcir.
CONSEIL : MÉTRIQUES DEVOPS CLÉS
Nous recommandons aux équipes de toujours mesurer les métriques suivantes :
- Délai d'exécution des changements
- Taux d'échec des changements
- Fréquence de déploiement
- Temps moyen jusqu'à la remise en route
2. Recueillez des données 15 MIN
Une fois que l'équipe aura fixé des objectifs, le présentateur devra collecter des données. N'oubliez pas que même si vous n'avez pas besoin de faire la première étape chaque semaine, vous devrez recueillir des données chaque semaine.
Tenez un journal
D'une réunion CheckOps à l'autre, vos outils ne pourront pas capturer tous les événements marquants qui se produiront. Étant donné la faillibilité de la mémoire humaine, cela vaut la peine de noter ces informations afin que vous puissiez en parler lors de la prochaine réunion.
Si vous faites partie d'une équipe distante, créez un nouveau rapport CheckOps pour chaque semaine dans lequel vous pourrez ajouter des événements marquants, puis partagez-le avec les membres de l'équipe concernés. Si vous utilisez la plateforme d'expérience de développement d'Atlassian, Compass, vous pouvez lancer votre pratique CheckOps rapidement et facilement depuis la page des informations sur la santé.
- La personne d'astreinte a-t-elle été appelée et s'est-elle rendu compte qu'il s'agissait d'une fausse alerte ? Cela a certainement un impact sur l'expérience des développeurs de votre équipe, alors notez cet événement et partagez-le avec le groupe afin de pouvoir apporter des améliorations à l'avenir.
- Un incident s'est-il produit, un déploiement a-t-il échoué ou le merge d'une pull request a-t-il été trop long ? Prenez des notes rapides tout au long de la semaine pour que l'équipe n'ait pas à reconstituer les événements de mémoire plus tard.
Préparez l'examen
À la fin de la rotation d'astreinte (ou juste après celle-ci), le présentateur doit préparer le rapport CheckOps pour cette rotation. Dans sa forme la plus simple, le rapport devrait inclure :
- La liste des services/composants pour lesquels vous souhaitez exécuter CheckOps.
- La mesure (par rapport à votre objectif) de chacun de ces composants.
- Une coche ou une croix indiquant si l'objectif a été atteint ou non.
- Un plan d'atténuation pour tout objectif non atteint, ainsi que des notes du présentateur sur les raisons pour lesquelles l'objectif n'a pas été atteint.
- Une section permettant de capturer les actions de suivi.
- Un résumé de tout autre événement ou anomalie.
Il est essentiel que les actions de suivi soient capturées dans le rapport CheckOps. À défaut, vous obtiendrez un rapport d'état à la place d'une boucle de feedback qui favorise l'amélioration.
3. Organisez une réunion de revue CheckOps 30 min
Tout le monde joue un rôle
Maintenez l'interactivité ! Tous les membres de votre équipe DevOps qui sont d'astreinte à tour de rôle devraient assister à cette réunion, et chacun devrait avoir une tâche :
- Présentateur : la personne qui vient de terminer sa rotation d'astreinte doit présenter le rapport CheckOps et ses conclusions. Si aucun membre de votre équipe n'est d'astreinte, désignez une personne qui prendra des notes sur les événements qui se déroulent au cours de la semaine et qui pourra présenter ses conclusions au cours du scénario.
- Astreinte suivante : cette personne doit porter une attention particulière aux observations du présentateur, y compris aux tickets qu'il a constatés ou aux éventuelles zones de risques qui pourraient se reproduire lors de la rotation d'astreinte suivante.
- Leader : le leader est la personne (ou les personnes) qui peut (ou peuvent) aider l'équipe à hiérarchiser les actions et en assurer le suivi. Lorsqu'une action nécessitant un suivi se présente, le leader doit s'assurer que la (ou les) bonne(s) personne(s) est (sont) en charge de l'action et qu'elle(s) est (sont) capable(s) de la mener à bon terme.
- Autres membres de l'équipe d'astreinte et propriétaires de composant : il s'agit des personnes qui font également partie de la rotation d'astreinte et/ou qui connaissent parfaitement les services ou les composants exploités.
Partagez les résultats avec l'équipe et discutez-en
Le présentateur expliquera à l'équipe chaque service/composant et indiquera si les objectifs ont été atteints ou non, et pourquoi. Il discutera de tout événement ou anomalie opérationnels survenus pour le service concerné et partagera ses observations et analyses avec l'équipe. Le travail de cette dernière consiste à poser des questions et à faire des suggestions pour les actions de suivi.
Travaillez ensemble pour trouver des moyens de garantir que tous les services/composants de l'équipe DevOps atteignent leurs objectifs respectifs. Il s'agit d'un exercice pour toute l'équipe.
Notez les actions que chaque membre de l'équipe entreprendra et créez des tickets dans votre backlog pendant la réunion.
ASTUCE : AGISSEZ, NE RÉAGISSEZ PAS
Lorsque votre équipe est chargée d'atteindre des objectifs opérationnels ou des objectifs de développement, il peut être facile de tomber dans le piège de la réactivité. Qu'il s'agisse de fiabilité, de rapidité de livraison ou de qualité du code, l'approche axée sur les données promue par CheckOps devrait permettre à votre équipe d'atteindre vos objectifs DevOps, d'améliorer l'expérience des développeurs et de se perfectionner en continu.
Suivi
Itération
Nous suggérons d'exécuter le scénario CheckOps chaque semaine et de l'aligner sur le planning d'astreinte de votre équipe. Les étapes 2 et 3 se répètent chaque semaine, mais vous n'avez peut-être pas besoin de suivre la première étape chaque semaine. Au fur et à mesure que vous répéterez le scénario, les étapes 1 et 2 deviendront plus courtes. Une fois que votre équipe aura exécuté le scénario CheckOps pendant plusieurs semaines, vous aurez peut-être l'occasion d'élargir et de faire évoluer vos bonnes pratiques pour y inclure d'autres domaines prioritaires. Par exemple, vous pourrez mesurer des métriques de qualité telles que la couverture de code, des métriques métier telles que le nombre d'utilisateurs actifs hebdomadaires pour une fonctionnalité donnée, ou toute autre métrique susceptible de rendre votre équipe plus saine.
Réévaluez vos objectifs opérationnels
Au fil du temps, les objectifs initiaux du DevOps que vous avez fixés peuvent ne plus répondre aux besoins de votre équipe. Peut-être que les besoins de l'entreprise ont changé ou que les cibles sont devenues plus ou moins dynamiques. Si tel est le cas, passez à la première étape, mettez vos objectifs opérationnels à jour et continuez votre activité. Vous pouvez également élargir le périmètre de votre activité CheckOps si cela est nécessaire afin de couvrir davantage de services, de composants ou d'autres aspects de vos activités opérationnelles.
Automatisez les rapports
Au fur et à mesure que votre périmètre s'élargit, vous constaterez que vous aurez envie de consacrer plus de temps à l'analyse et moins de temps aux rapports. Trouvez des moyens d'automatiser la collecte de métriques clés et la génération de vos rapports CheckOps. Cela améliorera à la fois la productivité et l'expérience des développeurs au sein de votre équipe à mesure que de plus en plus de rapports seront automatisés.
Si vous ajoutez de l'automatisation, veillez à prendre le temps d'analyser les données que vous collectez et de préparer la réunion CheckOps. Les équipes Atlassian utilisent les métriques de Compass pour y parvenir, et nous avons intégré notre expérience CheckOps au produit pour vous aider à y parvenir également.
Exemples d'objectifs opérationnels
Réflexions
Voici quelques exemples d'objectifs opérationnels autour desquels votre équipe peut structurer vos bonnes pratiques CheckOps, en fonction de vos responsabilités :
Delivery types | Possible objectives |
|---|---|
Microservice |
|
On-call team |
|
Software delivery |
|
Mobile application |
|
Scénarios connexes
De notre équipe, pour la vôtre
Tenez-vous informé des derniers scénarios, ainsi que des trucs et astuces grâce à notre newsletter.
