Vous aimez DevOps ? Attendez de découvrir l'ingénierie de la fiabilité des sites ou SRE

Mais qu'est-ce que la SRE ?

Le génie de Google à l'origine de ce concept, Benjamin Treynor Sloss, n'a toujours pas publié de définition en une phrase, mais décrit la fiabilité des sites comme « ce qui se passe lorsqu'un ingénieur logiciel est chargé de ce qui était autrefois appelé les opérations ».

Le problème sous-jacent est le suivant : les équipes de développement veulent livrer de nombreuses nouvelles fonctionnalités, et les voir gagner en popularité de façon spectaculaire. Les équipes opérationnelles veulent s'assurer que ces fonctionnalités sont fiables. Historiquement, cela a donné lieu à une grande lutte pour le pouvoir, les équipes opérationnelles essayant de freiner autant de livraisons que possible, et les équipes de développement cherchant de nouvelles méthodes intelligentes pour contourner les processus qui les retiennent. (Cela vous dit quelque chose, j'en suis sûr.)

La SRE élimine les spéculations et le débat sur ce qui peut être lancé et à quel moment. Elle introduit une formule mathématique pour autoriser ou non les lancements, et dédie une équipe de personnes ayant des compétences opérationnelles (appelées à juste titre ingénieurs chargés de la fiabilité des sites, ou SRE) pour superviser en permanence la fiabilité du produit. Comme le décrit le propre SRE de Google, Andrew Widdowson : « Notre travail revient à faire partie de l'équipe de course la plus frénétique au monde. Nous changeons les pneus d'une voiture de course pendant qu'elle roule à 160 km/h. »

Ça ne semble pas encore révolutionnaire ? Une grande partie de la magie réside dans la façon dont elle opère. Voici quelques-uns des principes fondamentaux, qui incarnent également les plus grandes différences par rapport aux opérations informatiques traditionnelles.

Tout d'abord, les nouveaux lancements sont approuvés en fonction des performances actuelles du produit.

La plupart des apps n'atteignent pas 100 % de temps d'activité. Ainsi, pour chaque service, l'équipe SRE établit un accord de niveau de service (SLA) qui définit à quel point le système doit être fiable pour les utilisateurs finaux. Si l'équipe s'accorde sur un SLA à 99,9 %, cela lui donne un budget d'erreur de 0,1 %. Un budget d'erreur est, comme son nom l'indique, le seuil maximal autorisé pour les erreurs et les pannes.

Conseil de pro : vous pouvez facilement convertir les SLA en « minutes de temps d'arrêt » grâce à cette superbe fiche de révision sur le temps d'activité.

L'argument décisif est le suivant : l'équipe de développement peut en quelque sorte utiliser ce budget d'erreur comme elle le souhaite. Si le produit fonctionne actuellement sans problème, avec peu ou pas d'erreurs, elle peut lancer ce qu'elle veut, quand elle le souhaite. À l'inverse, si elle a atteint ou dépassé le budget d'erreur et respecte tout juste le SLA défini, tous les lancements sont gelés jusqu'à ce qu'elle réduise le nombre d'erreurs à un niveau permettant de procéder au lancement.

L'idée de génie ? Les SRE et les développeurs sont fortement incités à collaborer pour minimiser le nombre d'erreurs.

Les SRE peuvent également programmer

Dans l'ancien modèle, vous mettiez les personnes face à un problème de fiabilité et insistiez (parfois pendant une année ou plus) jusqu'à ce qu'il disparaisse ou ne vous rattrape.

Ce n'est pas le cas pour les SRE. Les équipes de développement et SRE partagent un même pool de personnel. Ainsi, pour chaque SRE embauché, un développeur de moins est disponible (et vice versa). Cela met fin à l'interminable bataille des effectifs entre les équipes de développement et opérationnelles, et crée un système d'auto-régulation dans lequel les développeurs sont récompensés par l'arrivée de nouveaux coéquipiers pour avoir écrit un code plus performant (c'est-à-dire un code qui nécessite moins de support de la part d'un nombre réduit de SRE).

Les développeurs mettent aussi les mains dans le cambouis

Chez Google, Benjamin Treynor Sloss a dû se battre pour cela, et il est heureux de l'avoir fait. En fait, dans son excellente keynote sur les SRE chez SREcon14, il a mis en avant qu'il devrait être obligatoire d'obtenir cet engagement de la part de votre direction avant d'initier la SRE.

Fondamentalement, l'équipe de développement gère 5 % de la charge de travail opérationnelle (elle gère les tickets, offre un support d'astreinte, etc.). Cela lui permet de rester étroitement liée à son produit, de voir ses performances et de prendre de meilleures décisions en matière de programmation et de livraison.

En outre, chaque fois que la charge opérationnelle dépasse la capacité de l'équipe SRE, le surplus est toujours assigné aux développeurs. Lorsque le système fonctionne correctement, les développeurs commencent à s'auto-réguler également, grâce à une programmation solide et à des livraisons soigneuses afin de prévenir les tickets futurs.

Les SRE sont des agents libres (vous pouvez faire appel à eux si nécessaire)

Pour assurer le bonheur et la bonne santé des équipes, Benjamin Treynor Sloss recommande de donner les moyens aux SRE de basculer sur d'autres projets à leur convenance, voire de les transférer vers une autre organisation. La SRE encourage un travail d'équipe très motivé, dévoué et efficace, de sorte qu'aucun membre de l'équipe ne devrait être freiné dans la poursuite de ses objectifs personnels.

Si toute une équipe de SRE et de développeurs n'arrive tout simplement pas à s'entendre et crée plus de problèmes que de code fiable, vous pouvez prendre une dernière mesure drastique, à savoir retirer l'ensemble de l'équipe SRE du projet et assigner toute la charge de travail opérationnelle à l'équipe de développement. Benjamin Treynor Sloss n'a pris cette mesure que quelques fois au cours de toute sa carrière. La menace est généralement suffisante pour amener les deux équipes à une relation professionnelle plus positive.

Il y a d'autres sujets relatifs à la SRE que je ne peux pas couvrir en un seul article. Par exemple, la manière dont les SRE préviennent les incidents de production, la manière dont les équipes de support d'astreinte sont constituées et les règles qu'elles suivent à chaque astreinte, etc.

Notre point de vue

L'informatique regorge de mots à la mode et de tendances, c'est certain. Un jour nous parlons du cloud, le lendemain de DevOps ou d'expérience client ou de « gamification ». La SRE est bien placée pour aller au-delà, notamment parce qu'il est bien plus question des personnes et des processus que de la technologie sous-jacente. Si la technologie peut certainement (et va probablement) s'adapter au concept à mesure qu'il se développe et que davantage d'équipes l'adoptent, vous n'avez pas besoin de nouveaux outils pour aligner vos organisations de développement et opérationnelles sur les principes des SRE.

Dans les prochains articles, nous aborderons les étapes pratiques pour avancer vers la SRE ainsi que le rôle que la technologie peut jouer.