L'ingénierie de la fiabilité des sites (SRE) utilise l'ingénierie logicielle pour automatiser les tâches des opérations informatiques, par exemple, la gestion des systèmes de production, la gestion des changements, la réponse aux incidents, voire la réponse aux situations d'urgence, qui seraient autrement exécutées manuellement par les administrateurs des systèmes (sysadmins). 

Le principe qui sous-tend le SRE est que l'utilisation de code logiciel pour automatiser la surveillance de grands  systèmes logiciels est une stratégie plus évolutive et durable que l'intervention manuelle, en particulier lorsque ces systèmes s'étendent au cloud ou migrent vers le cloud.

SRE peut également réduire ou supprimer une grande partie des frictions naturelles entre les équipes de développement qui veulent continuellement mettre en production des logiciels nouveaux ou mis à jour, et les équipes des opérations qui ne veulent pas publier de mises à jour ou de nouveaux logiciels sans être absolument sûres qu'ils ne provoqueront pas d'indisponibilités ou d'autres problèmes sur les opérations. Par conséquent, bien qu'il ne soit pas strictement nécessaire pour  DevOps, SRE s'aligne étroitement sur les principes DevOps et peut jouer un rôle important  dans la réussite de DevOps.

Le concept SRE est attribué à Ben Treynor Sloss, vice-président de l'ingénierie chez Google, qui a écrit que « SRE est ce qui se passe lorsque vous demandez à un ingénieur logiciel de concevoir une équipe chargée des opérations ».

Un ingénieur en fiabilité de site est un développeur de logiciels ayant une expérience des opérations informatiques, quelqu'un qui sait coder et qui comprend aussi comment assurer le fonctionnement continu dans un environnement informatique à grande échelle. 

Les ingénieurs chargés de la fiabilité des sites ne passent pas plus de la moitié de leur temps à effectuer des opérations informatiques manuelles et des tâches d'administration système (analyse des journaux, optimisation des performances, application de correctifs, test des environnements de production, réponse aux incidents, réalisation de post-mortem) et passent le reste de leur temps à développer du code qui automatise ces tâches. Leur objectif est de passer beaucoup moins de temps dans le premier cas et beaucoup plus de temps dans le second au fil du temps.

À un niveau plus élevé, l'équipe SRE sert de passerelle entre les équipes de développement et les équipes des opérations, permettant à l'équipe de développement de mettre en production de nouveaux logiciels ou de nouvelles fonctionnalités aussi rapidement que possible, tout en garantissant un niveau acceptable convenu de performance des opérations informatiques et de risque d'erreur, conformément aux accords sur les niveaux de service (SLA) que l'organisation a mis en place avec ses clients. Sur la base de son expérience et de la richesse des données des opérations, l'équipe SRE aide les équipes de développement et d'exploitation à établir ce qui suit :

• Indicateurs de niveau de service (SLI) : mesures du niveau de service fourni par les systèmes, mesures telles que la disponibilité (temps de fonctionnement) ou le temps d'attente
• Objectifs de niveau de service (SLO) : moyens convenus pour mesurer les indicateurs de niveau de service
• Budgets d'erreurs : durée maximale pendant laquelle un système peut tomber en panne ou ne pas fonctionner correctement sans violer les conditions contractuelles de l'accord sur les niveaux de service. Plus qu'une mesure, le budget d'erreurs est l'outil que  l'équipe d'ingénierie de la fiabilité des sites utilise pour concilier automatiquement le rythme d'innovation d'une entreprise et la fiabilité de ses services. 

Le budget d'erreurs est l'outil qu'une équipe SRE utilise pour concilier automatiquement la fiabilité des services d'une entreprise avec son rythme de développement et d'innovation logiciels. 

Supposons qu'un accord sur les niveaux de service d'une entreprise promette une disponibilité de 99,99 % (un objectif de disponibilité courant) par an. Cela signifie que le budget mensuel d'erreurs, la durée totale de temps d'arrêt autorisée sans conséquence contractuelle pour un mois donné, est d'environ 4 minutes et 23 secondes.

Imaginons maintenant que l'équipe de développement souhaite déployer de nouvelles fonctions ou des améliorations du système. Si le système fonctionne en respectant le budget d'erreurs, l'équipe peut distribuer les nouvelles fonctions. Dans le cas contraire, l'équipe ne peut pas les distribuer tant qu'elle n'a pas travaillé avec l'équipe des opérations pour ramener ces erreurs ou pannes à un niveau acceptable.

De cette façon, les budgets d'erreurs aident les équipes du développement et les équipes des opérations à :

• Améliorer la stabilité et la performance des services
• Prendre des décisions basées sur les données concernant le déploiement de nouvelles fonctions ou applications.
• Maximiser l'innovation en prenant des risques dans des limites acceptables

DevOps est un moyen moderne de fournir plus rapidement des applications de meilleure qualité, en automatisant le cycle de de distribution des logiciels et en donnant aux équipes du développement et des opérations plus de responsabilités partagées et plus d'informations sur le travail de chacun. 

À l'instar de SRE, DevOps améliore l'agilité de l'entreprise en établissant un équilibre entre la nécessité de fournir plus d'applications et de changements plus rapidement et la nécessité d'éviter de « casser » l'environnement de production. Et comme SRE, DevOps vise à atteindre cet équilibre en établissant un risque d'erreurs acceptables. En fait, SRE et DevOps semblent tellement similaires que certains experts disent qu'il s'agit de la même chose, mais la plupart considèrent les pratiques SRE comme d'excellents moyens de mettre en œuvre les principes DevOps. Par exemple :

Principes DevOps Réduire les silos organisationnels, optimiser les outils et l'automatisation

Pratique SRE : utiliser les mêmes outils pour automatiser et améliorer les opérations que ceux utilisés par les développeurs pour développer et améliorer les logiciels

Principes DevOps : considérer l'échec comme normal, mettre en œuvre des changements progressifs

Pratique SRE :utiliser les budgets d'erreurs pour déployer continuellement de nouvelles fonctions et fonctionnalités dans des niveaux acceptables

Principe DevOps :tout mesurer

Pratique SRE :baser les décisions de lancement de nouveaux logiciels sur les  mesures

Pour en savoir plus sur DevOps, visionnez cette vidéo (5:58) :

En plus de contribuer au succès de DevOps, l'ingénierie de la fiabilité des sites peut aider une entreprise à :

• Gagner en visibilité  sur l'intégrité des services  en suivant les mesures, les journaux et les traces de tous les services de l'organisation, et en fournissant un contexte pour identifier les causes premières en cas d'incident.
• Quantifier le coût de la durée d'indisponibilité en permettant aux équipes du développement et des opérations à comprendre le coût du non-respect des SLA, et en aidant la direction à quantifier l'impact de la fiabilité du système sur la production, les ventes, le marketing, le centre de support et d'autres fonctions métier.
• Optimiser la réponse aux incidents en créant des processus d'astreinte efficaces et en rationalisant les flux d'alerte.
• Créer un centre d'opérations réseau moderne en combinant une compréhension approfondie des opérations informatiques avec l'apprentissage automatique et l'automatisation, afin d'envoyer des alertes directement à la personne chargée de traiter le problème.

La migration  de l'informatique traditionnelle et des centres de données sur site vers des environnements de  cloud hybride est l'une des principales raisons pour lesquelles l'entreprise moyenne génère  deux à trois fois plus de données d'opérations chaque année. De plus en plus, SRE est considéré comme essentiel pour exploiter ces données, afin d'automatiser l'administration des systèmes, les opérations et la réponse aux incidents, et d'améliorer la fiabilité de l'entreprise, alors même que l'environnement informatique devient plus complexe.

Une approche du développement cloud native , plus précisément, la création d'applications sous forme de  microservices  et leur déploiement dans des  conteneurs , peut simplifier le développement, le déploiement et l'évolutivité des applications. Mais le développement cloud natif crée également un environnement de plus en plus distribué qui complique l'administration, les opérations et la gestion. Une équipe SRE peut soutenir le rythme rapide d'innovation permis par une approche cloud-natif et garantir ou améliorer la fiabilité du système, sans exercer une pression opérationnelle supplémentaire sur les équipes DevOps.

IBM Cloud Pak for Watson AIOps rassemble les données des opérations dans des piles et des outils informatiques cloisonnés, pour donner à votre  équipe SRE une vue globale de l'ensemble de votre environnement informatique. Il fournit également une intelligence artificielle (IA) puissante pour prédire et résoudre de manière proactive les problèmes avant qu'ils ne deviennent des incidents. Avec IBM Cloud Pak for Watson AIOps, vous pouvez mieux comprendre les mesures et les événements, anticiper et calculer les risques, et automatiser vos opérations informatiques pour réduire les risques et les coûts. 

Découvrez-en plus sur  IBM Cloud Pak for Watson AIOps.

Découvrez comment l'application de l'IA et de l'automatisation aux opérations informatiques peut aider SRE à garantir la résilience et la robustesse des applications d'entreprise et à libérer du temps et des talents précieux pour soutenir l'innovation. Lire « Transition SRE vers AIOps »

Grâce au programme de formation IBM Cloud Professional Site Reliability Engineer (SRE) , développez des compétences et découvrez comment un SRE IBM Cloud rend les systèmes fiables, applique des modèles de conception Cloud modernes au code et crée des solutions durables pour répondre aux exigences des clients et aux problèmes de service.

Inscrivez-vous à un IBMid et créez votre  compte IBM Cloud.