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 SRE est que l'utilisation de code logiciel pour automatiser la surveillance des 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 sait aussi 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 supérieur, 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 d'une grande quantité de données des opérations, l'équipe SRE aide les équipes de développement et des opérations à établir les éléments suivants :

• 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 rester 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. Dans ce cas, 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 collaboré 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 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 l'impératif 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 employé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 des accords sur les niveaux de service

Pour en savoir plus sur DevOps, regardez 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 le machine learning 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. SRE occupe un rôle croissant 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 natif, 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 toujours 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.