Date: Saturday, 16 July 2022, 8:00 AM

Site Reliability Engineering,(SRE),
Comment ça marche ?

Les parcs informatiques des entreprises ne cessent de s’élargir, avec l'accroissement des utilisateurs...

En particulier dans le Cloud, les entreprises globales, gèrent de gigantesques productions informatiques dont les tailles se chiffrent en dizaines voire en centaines de milliers de serveurs informatiques.

Pourquoi SRE (Site Reliability Engineering)?
Qu’est-ce que la SRE (Site Reliability Engineering)?
Quel sont les éléments clés de SRE ?
Quels sont les bénéfices de SRE ?
Quelles sont pratiques d'automatisation de SRE ?
Quelle est la différence entre DevOps et SRE ?
Quels sont les indicateurs propres à SRE ?
L'antifragilité au coeur de SRE
Comment devenir ingénieur SRE ?

Pourquoi SRE (Site Reliability Engineering) ?

En 2011, on estimait que Google disposait d'un peu plus de 900 000 de serveurs. Aujourd'hui, Netflix affiche 18 000 serveurs répartis dans toutes ses zones de présence dans le monde.

Le quantité d'applications, hébergées sur ces serveurs atteint un niveau considérable: pléthore de machines virtuelles, de conteneurs, de micro services, de logiciels, etc.

D'autre part, la distribution géographique des centre de données sur plusieurs continents couplée aux réseaux qui les relient rajoutent une complexité sans précédent.

Pour mieux servir les masses d'utilisateurs au niveau mondial, les applications doivent être disponibles en permanence au risque de perdre en réputation ou en clients.

Dans le contexte de très larges infrastructures IT dans le cloud, plusieurs problèmes se posent désormais:

1) il devient humainement impossible de se représenter les architectures, d'en prédire le fonctionnement, ou de les faire évoluer de manière sûre

2) il n'existe plus de pannes à cause unique. Les très larges infrastructures du Cloud sont caractérisées par des pannes systémiques dues aux combinaisons aléatoires des défauts se propageant plus largement à toute l'infrastructure

3) la traditionnelle organisation réactive ITIL ienne, se trouve dépassée en ce qui concerne la prise en charge de problèmes systémiques des très larges productions du Cloud.

Le 05/10/2021, une panne mondiale a touché l'ensemble des services fournis par Facebook. Le réseau social lui-même, whastapp, instagram, messenger soit près de de 3 milliards d'utilisateurs, ont été privés de service durant 7 heures. Le départ d'incident, un banal changement de configuration sur un équipement de routage réseau, a provoqué ce désastre mondial.

SRE est une pratique DevOps, qui concerne les très larges productions du Cloud Computing. Il apporte des solutions concrètes permettant de fiabiliser des services à très grande échelle.

Qu’est-ce que la SRE (Site Reliability Engineering) ?

SRE est une discipline créée en 2003 par Google, qui applique les principes d'ingénierie logicielle aux opérations du cloud computing.

L’appellation « Site Reliability Engineering » (ingénierie de la fiabilité de site) est venue en 2003 du vice-président de l’ingénierie de Google, Ben Sloss. Comme il a dit (en anglais), « Si Google cesse de fonctionner, c’est ma faute ». Google définit la SRE comme étant « ce que vous obtenez lorsque vous traitez les opérations comme un problème logiciel ». SRE s'est depuis développé au delà de Google. Il regroupe un ensemble de pratiques, normalisées, permettant d'apporter plus de fiabilité à des services informatiques très largement distribués.

L’ingénierie de la fiabilité de site (en anglais, « Site Reliability Engineering » or SRE) automatise des tâches qui jusqu’ici étaient effectuées manuellement par des ops. SRE se base sur « les opérations en tant que code ». Ainsi, les productions cloud de grande envergure deviennent plus faciles, plus sûres et moins chères à gérer. De même, ces larges productions conservent, évolutivité et stabilité malgré leurs très grandes taille.

Les ingénieurs SRE normalisent, automatisent, et fiabilisent les opérations de service pour assurer une bonne qualité de service. Dans l’ingénierie de la fiabilité de site, on se sert de logiciels spécifiques pour gérer les systèmes de production, dès le déploiement, mais aussi pour corriger des problèmes, de manière automatisée.

Quel sont les éléments clés de SRE ?

SRE s’inscrit dans une stratégie de satisfaction des clients. De même, site reliability engineering assure l''introduction de nouveaux services dans les très larges productions du Cloud, de manière maîtrisée. Pour cela, l'équipe de sre s'appuie sur 6 principes clés:

1) traiter les opérations comme un problème d'ingénierie logicielle, dont les solutions se se trouvent du côté design. A l'inverse des pratiques classiques d'ITSM, dans lesquelles seules les techniques d'exploitation et de maintenance font foi

2) le slo: service level objectives, définit l'objectif client à atteindre par chaque service. Le slo est le driver central du pilotage des services par les équipes sre. Il mesure l'objectif minimal (de disponibilité en général) à atteindre de manière à garantir le business ainsi que le niveau de satisfaction client. Dans sre, rater le slo d'un service doit avoir des conséquences déterminées par l’organisation tant au niveau du métier, du business, que de la productivité des employés

3) l'élimination des toil: les toil représentent les tâches manuelles réalisées de manière répétées par les ops en production. les toil ont la particularité d'avoir un coût qui augmente exponentiellement avec la croissance de la production informatique. SRE sanctuarise l'élimination systématique du toil. Les erreurs humaines s'en trouvent réduites, et avec, les risques sur la disponibilité des services

4) l'automatisation systématique de toutes les tâches manuelles en production est une règle fondamentale dans les équipes sre. Exception faite aux tâches aux mauvais effets par essence, qui elles, doivent être éliminées

5) la réduction continuelle du coût de l'échec, qui elle, repose sur des principes devops: privilégier les petits changements, disposer d'une boucle de feedbacks continue, définir à l'avance les stratégies de réduction de la durée de réparation des services (MTTR ou Mean Time To Repair).

6) la responsabilité de la disponibilité des services est partagée à tous les niveaux de l’organisation ou de l'entreprise. Notamment au niveau des équipes de développeurs qui doivent connaître les performances des services qui portent leurs applications en production.

Quels sont les bénéfices de SRE ?

Dans chaque entreprise il faut un équilibre entre la mise à disposition de nouveaux services et la certitude qu’elles seront fiables et disponibles. La SRE aide en préparant une mise à l’échelle robuste de la production des logiciels.

Elle renforce ainsi le lien entre le développement, les déploiements, et la vie des services. Plus spécifiquement :

SRE réduit les taux d’échec des déploiements, les temps d’arrêt de service, et procure une meilleure stabilité à l'échelle des très grands systèmes
SRE prévient des pannes globales, prépare les ingénieurs à y faire face, mesure continuellement la fiabilité des process et des services
SRE apporte une assurance aux équipes ops par la connaissance plus approfondie du comportement des larges systèmes
SRE réduit considérablement les coûts d'opérations des très grandes infrastructures dans le Cloud par l'automatisation massive des actes de production

Quelles sont pratiques d'automatisation de SRE ?

L'automatisation des opérations de production est l'un des objectifs fondamentaux de sre. Dans sre l'automatisation vise toutes les tâches d'opérations qu'elles se situent au niveau build ou run.

Build

Dans beaucoup d'équipes DevOps, l'automatisation se concentre sur l'accélération du flux code, build, test, deploy et néglige tout le reste. Avec sre la création des environnements de tests, pré production et production est prise en compte et automatisée. Ces trois environnements sont créés consistants dans leurs configuration, avec l'environnement de déploiement des services en production. Cette consistance est assurée par la programmation des infrastructures ainsi que leurs configurations "as code" (IaaC et CaaC). En outre, l'automatisation de la création des environnements, renseigne les ingénieurs de développement, sur les comportements de leurs logiciels dans le système cible.

Run

C'est lorsque les applications entrent en exploitation, que l'automatisation participe le plus à garantir les objectifs de services (les service level objectives). D'abord, les ingénieurs sre automatisent les tests fonctionnels et non-fonctionnels des services en production. Également, ils réalisent l'observabilité des services offerts (grâce au SLI ou Service Level Indicator) de manière automatisée, via des instrumentations installées sur tous les neouds de service. Ensuite, toutes les sources de code, systèmes compris, sont versionnées, signées, distribuées, et contrôlées automatiquement dans les environnements de build, test, déploiement. Enfin, les sre pratiquent activement l'antifragilité. C'est une activité fondamentale qui consiste à expérimenter des désastres en production de manière régulière. L'objectif est de tirer le maximum d'enseignements, à partir de l'exécution de scénarii de pannes majeures directement sur des machines de production. On peut citer parmi les exemples les plus populaires de techniques d'antifragilité le Chaos Monkey. Il a été mis en œuvre par Netflix dans les années 2008. Ce dernier a contribué à en faire l'une des rares entreprises à avoir résisté au black-out national du cloud aws survenu en avril 2011 aux usa.

Quelle est la différence entre DevOps et SRE ?

À certains égards, SRE est semblable à DevOps. SRE doit être vu comme une extension. Pour comparer, voici quelques repères simples. DevOps allie à la culture du blameless, l'automatisation massive des livraisons logicielles en production. De même, la qualité et sécurité du code sont améliorés, grâce à DevOps. En comparaison, SRE tire parti des mêmes principes pour obtenir une plus grande fiabilité des services dans des environnements très étendus en production (Cloud principalement).

Mais encore, SRE se différencie de DevOps sur d'autres aspects :

Là où DevOps se focalise sur la vélocité le long du cycle de vie logiciel, SRE se focalise sur le meilleur compromis entre la fiabilité et le lancement de nouvelles fonctionnalités en production
SRE automatise la fiabilité là où DevOps automatise la vitesse (pour faire allusion à la boîte automatique d'une voiture)
Les activités DevOps progressent de gauche à droite le long du cycle de vie logiciel, quant la progression de SRE se fait dans le sens opposé, en remontant des besoins de production aux développeurs
DevOps s'intéresse à des métriques comme la fréquence de déploiement et les délais de modifications tandis que SRE se focalise sur le taux d’échecs des services et leur temps de rétablissement
Dans DevOps on test des situations attendues, tandis que SRE explore les comportements inattendus des services grâce à l'antifragilité

Quels sont les indicateurs propres à SRE ?

Parmi les différents indicateurs utilisés par les ingénieurs sre, certains sont plus essentiels:

Les Service Level Objectives, définissent un but à atteindre au niveau du service pour satisfaire les clients. Tout objectif de service contribuant à une meilleure expérience client peut être retenu comme slo. Selon un rapport 2019 de Catchpoint, les slo les plus populaires étaient: la disponibilité, le temps de réponse et latence des services. Par exemple l'expression d'un slo pourrait être "95% des clients doivent pouvoir s'authentifier"

Les Service Level Indicators (SLI), fournissent quand à eux, la mesure actuelle de la performance du service: par exemple "99% des clients ont réalisé une authentification au mois de Juillet"
L'observabilité, renseigne sur l'état de fonctionnement normal d'un service. Elle alerte sur les déviations de comportement, par rapport à des critères prédéfinis. Pour les besoins du service d'authentification, le critère pourrait être par exemple "30 secondes est la durée normale d'authentification d'un client"

L'antifragilité au coeur de SRE

Au coeur de SRE se trouve une nouvelle discipline d'ingénierie de production, l'antifragilité. C'est le fer de lance de la fiabilisation des grands environnements informatiques. C'est une technique qui permet l'apprentissage par l'expérimentation des modes de pannes impossibles à prédire. L'antifragilité est l'art de provoquer volontairement des pannes graves, tout en contenant le rayon d'impact dans les proportions du slo. C'est ainsi que l'erreur peut être expérimentée. Grâce à cela, l'organisation établit une meilleure connaissance de l’interaction entre les noeuds. Au delà, c'est les mesures préventives aux pannes systémiques qui sont préparées, tant au niveau des process que de l'architecture.
Deux pratiques sont sous-jacentes à l'antifragilité: les "exercices incendie" ou "fire drills" et le Chaos Engineering.

Les "fire drills" sont des exercices agissant sur la continuité de service. il peuvent être réalisés suivants différents scénarii de pertes: un datacenter, une région, une technologie (par exemple une base de données), une ressource humaine clé, un sous-traitant clé.

Le Chaos Engineering est la discipline d'expérimentation des pannes sur les systèmes en production. Il consiste à introduire volontairement une erreur ou une panne dans un système clé. Puis à résoudre le problème afin d'améliorer les procédures de rétablissement de service ainsi que l'organisation des équipes opérationnelles. Évidemment, la prudence est de mise dans l'application de cette discipline dans les équipes. Il est fortement recommandé d'évoluer de manière contrôlée, d'abord en préproduction. Par la suite de bien cloisonner le rayon d'actions en terme d'impacts clients, mais aussi de postes de travail des ops concernés lors de l'application en production.

Dans tous les cas la réponse à incidents dans ces conditions, est d'un apport crucial dans sre.

Comment devenir ingénieur SRE ?

Devenir ingénieur sre est une évolution naturelle pour un DevOps. Les ingénieurs ops (Administrateurs systèmes, etc.), avec des compétences en développement peuvent prétendre aussi à assumer ce rôle. Dans tous les cas, le besoin de formation s'impose, tant sre introduit de nouvelles compétences. En général, pour devenir un profil sre les conditions suivantes sont indispensables:

Une formation d'ingénieur de niveau Bac+5 en informatique
Une certification ou une expérience significative en DevOps
Des connaissances et compétences de la CI/CD (l’intégration et la livraison continues)
Des capacités de communication pour mener un travail quotidien avec des ingénieurs de développement et pour signaler efficacement des incidents
De bonnes bases dans les langages de programmation d'infrastructures systèmes (terraform, python, perl, aws cloudformation, azure ressource manager, etc.)
Une pratique de quelques outils de monitoring, et d'observabilité
Une expérience des technologies cloud natives, en particulier les conteneurs (Docker, Kubernetes, ...)
Une maîtrise spécifique d'outils d'antifragilité comme Fire Drills, Chaos Monkey, PagerDuty

En poste en tant qu’ingénieur SRE, vous devrez :

• Assure le capacity planning des services à l'échelle

• Automatiser les processus de de rétablissement de service

• Définir et mettre en œuvre une stratégie d'antifragilité

• Diffuser à l'échelle de l'organisation les enseignements retenus des tests de
défaillance

Le métier d’ingénieur de la fiabilité de site est en plein essor aujourd’hui. les profils sont très recherchés.

Parmi les informations en rapport à ce sujet, citons quelques sources intéressantes sur Cooptalis ou Diplomeo pour les métiers qui recrutent. Le site l’Étudiant cite par ailleurs sre dans les métiers web les plus demandés.

Une formation SRE certifiante de la DevOps Institute avec accompagnement par des coachs experts peut aussi être un excellent point de départ pour une évolution de carrière en ingénierie de la fiabilité de site.

Liens utiles

https://diplomeo.com/actualite-metiers_qui_recrutent_france

https://www.letudiant.fr/metiers/les-10-metiers-du-web-les-plus-demandes-en-2020-selon-linkedin.html

https://blog.cooptalis.com/talent/gautier-lautodidacte-%C3%A0-la-pointe-du-sre