Trois faits concrets
Premièrement, la complexité de vos systèmes logiciels est à son comble et vous avez plus de dépendances externes que jamais auparavant. 51 % des professionnels de l’informatique interrogés par SolarWinds en 2021 ont désigné la complexité informatique comme le principal problème auquel leur organisation est confrontée.
Deuxièmement, vous devez livrer plus vite que la concurrence, ce qui est de plus en plus difficile car des outils plus open source et réutilisables permettent aux petites équipes d’agir extrêmement rapidement. Sur les 950 professionnels de l’informatique interrogés par RedHat, seulement 1 % ont indiqué que les logiciels open source n’étaient « pas du tout importants ».
Et troisièmement, la fiabilité vous ralentit.
Le compromis fiabilité/rapidité
Dans les temps anciens du logiciel, nous pouvions simplement tester le logiciel avant une version pour nous assurer qu’il était bon. Nous avons effectué des tests unitaires, nous nous sommes assurés que l’équipe d’assurance qualité y jetait un coup d’œil, puis nous poussions soigneusement une mise à jour logicielle pendant une fenêtre de maintenance planifiée, la testions à nouveau et, espérons-le, revenions profiter de notre week-end. Selon les normes de 2023, c’est un rythme paresseux ! Nous nous attendons à ce que les équipes proposent constamment de nouvelles mises à jour (même le vendredi) avec un minimum de tests manuels dédiés. Ils doivent suivre les correctifs de sécurité, publier les dernières fonctionnalités et s’assurer que les correctifs de bogues sont transmis à la production.
Le défi est que pousser le logiciel plus rapidement augmente le risque que quelque chose tourne mal. Si vous preniez l’ancienne approche de livraison de logiciels et que vous l’accélériez, vous auriez sans aucun doute toujours des versions cassées. Pour résoudre ce problème, des outils modernes et une infrastructure cloud native rendent la livraison de logiciels plus fiable et plus sûre, tout en réduisant le travail manuel des versions.
Selon le rapport State of DevOps 2021, plus de 74 % des organisations interrogées ont un taux d’échec du changement (CFR) supérieur à 16 %. Pour les organisations cherchant à accélérer les modifications logicielles (voir les métriques DORA), bon nombre de ces mises à jour ont causé des problèmes nécessitant des mesures correctives supplémentaires comme un correctif ou une restauration.
Si votre équipe n’a pas investi dans l’amélioration de la fiabilité des outils de livraison de logiciels, vous ne pourrez pas obtenir rapidement des versions fiables. Dans le monde d’aujourd’hui, toute votre infrastructure, y compris l’infrastructure de développement/test, fait partie de l’environnement de production.
Pour aller vite, il faut aussi aller prudemment. Des modifications incrémentielles plus mineures, des procédures de publication et de restauration automatisées, des métriques de haute qualité et des objectifs de fiabilité clairement définis permettent des versions logicielles rapides et fiables.
Définir la fiabilité
Avec des objectifs clairement définis, vous saurez si votre système est suffisamment fiable pour répondre aux attentes. Qu’est-ce que cela signifie d’être en haut ou en bas ? Vous avez des centaines de milliers de services déployés dans des nuages dans le monde entier en flux constant. Les développeurs ne coordonnent plus les versions et ne poussent plus les logiciels. Les dépendances se cassent pour des raisons inattendues. Les correctifs de sécurité obligent les équipes à précipiter les mises à jour en production pour éviter les violations de données coûteuses et les menaces de cybersécurité.
Vous avez besoin d’un langage structuré et interprété pour encoder vos attentes et les limites de vos systèmes et actions correctives automatisées. Aujourd’hui, les définitions sont dans le code. Rien de moins est indéfini. L’alternative est l’intervention manuelle, qui vous ralentira.
Vous ne pouvez pas travailler sur la livraison de nouvelles fonctionnalités si vous essayez constamment de comprendre ce qui est cassé et de corriger les versions qui ont déjà été publiées. La ressource la plus précieuse de votre organisation est l’attention, et la seule façon d’en créer davantage est de réduire les distractions.
Accélération fiable
Les objectifs de niveau de service (SLO) sont des cibles de fiabilité définies avec précision. Les SLO incluent un pointeur vers une source de données, généralement une requête sur un système de surveillance ou d’observabilité. Ils ont également un seuil défini et des cibles qui définissent clairement la réussite ou l’échec à un moment donné. Les SLO incluent une fenêtre de temps (roulante ou alignée sur le calendrier) pour comptabiliser les erreurs par rapport à un budget. OpenSLO est la norme de facto moderne pour déclarer vos objectifs de fiabilité.
Une fois que vous avez des SLO pour décrire vos objectifs de fiabilité pour tous les services, quelque chose change. Bien que les SLO n’améliorent pas directement la fiabilité, ils mettent en lumière le décalage entre les attentes et la réalité. Il y a beaucoup de pouvoir à simplement clarifier et publier vos objectifs. Ce qui était autrefois une compréhension partagée grossière devient explicitement défini. Nous pouvons débattre du SLO et décider de l’augmenter, de l’abaisser, de le redéfinir, de le diviser, de le combiner et de le modifier avec une trace écrite dans l’historique des commits. Nous pouvons apprendre des échecs comme des succès.
Quels que soient les autres investissements que vous faites, les SLO vous aident à mesurer et à améliorer votre service. La fiabilité est machinée ; vous ne pouvez pas concevoir un système sans comprendre ses exigences et ses limites. Les SLO en tant que code définissent une fiabilité cohérente entre les équipes, les entreprises, les implémentations, les clouds, les langues, etc.