L’ingénierie de la fiabilité des sites (SRE) utilise le génie logiciel pour automatiser les tâches d’exploitation informatique telles que la gestion des systèmes de production, la gestion des changements, la réponse aux incidents, voire la réponse aux urgences, qui seraient autrement exécutées manuellement par les administrateurs de systèmes (sysadmins). 

Le principe sur lequel repose la SRE est que l'utilisation d'un code logiciel pour automatiser la supervision de grands systèmes logiciels est une stratégie plus évolutive et plus durable que l'intervention manuelle - en particulier lorsque ces systèmes s'étendent ou migrent vers le cloud.

La 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 mettre en production une mise à jour ou un nouveau logiciel sans être absolument sûres qu'il n'entraînera pas de pannes ou d'autres problèmes d'exploitation. Par conséquent, même si elle n'est pas strictement nécessaire pour le DevOps, la SRE s'aligne étroitement sur les principes du DevOps et peut jouer un rôle important dans la réussite du DevOps.

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

Un ingénieur en fiabilité des sites est un développeur de logiciels ayant une expérience des opérations informatiques, qui sait coder et qui comprend comment maintenir le fonctionnement des systèmes dans un environnement informatique à grande échelle. 

Les ingénieurs en fiabilité des sites passent la moitié de leur temps à effectuer des opérations informatiques manuelles et des tâches d’administration des systèmes : analyse des journaux, réglage des performances, application de correctifs, test des environnements de production, réponse aux incidents, réalisation d’analyses rétrospectives. Le reste de leur temps, ils développent du code qui automatise ces tâches. Leur objectif est de consacrer moins de temps aux premières et plus de temps aux secondes.

À un niveau plus élevé, l'équipe SRE sert de pont 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. Elles le font tout en garantissant un niveau acceptable de performance des opérations informatiques et de risque d'erreur, conformément aux accords de niveau de service (SLA) que l'organisation a mis en place avec ses clients. En s’appuyant sur son expérience et sur la richesse de ses données opérationnelles, l’équipe SRE aide les équipes de développement et des opérations à établir

• Indicateurs de niveau de service (ISL) : mesures du niveau de service fourni par les systèmes - mesures telles que la disponibilité (temps de fonctionnement) ou la latence..
  
  
• Objectifs de niveau de service (SLO) : moyens convenus entre les parties intéressées de mesurer les indicateurs de niveau de service.
  
  
• Budgets d’erreurs : la durée maximale pendant laquelle un système peut tomber en panne ou ne pas fonctionner sans enfreindre les conditions contractuelles de l’accord de niveau de service (SLA). Plus qu’un indicateur, le budget d’erreurs est l’outil qu’utilise une équipe d’ingénierie de la fiabilité des sites pour réconcilier automatiquement le rythme d’innovation d’une entreprise avec la fiabilité de ses services. 

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

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

Supposons maintenant que l’équipe de développement veuille mettre en place de nouvelles fonctionnalités ou améliorations du système. Si le système fonctionne dans les limites du budget d’erreurs, l’équipe peut déployer les nouvelles fonctionnalités. Dans le cas contraire, l’équipe ne peut pas les déployer tant qu’elle n’a pas travaillé avec l’équipe d’exploitation pour ramener ces erreurs ou ces pannes à un niveau acceptable.

De cette manière, les budgets d’erreurs aident les équipes de développement et d’exploitation à :

• améliorer la stabilité et les performances des services ;
  
  
• prendre des décisions fondées sur les données concernant le déploiement de nouvelles fonctionnalités ou applications ;
  
  
• maximiser l’innovation en prenant des risques dans des limites acceptables.

Le 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 de développement et d’exploitation plus de responsabilités partagées et davantage de contributions à leur travail respectif. 

Comme la SRE, DevOps rend une entreprise plus agile en équilibrant la nécessité de fournir plus d'applications et de changements plus rapidement avec la nécessité d'éviter de « casser » l'environnement de production. Et comme la SRE, DevOps vise à atteindre cet équilibre en établissant un risque d'erreurs acceptable. En fait, SRE et DevOps semblent tellement similaires que certains experts affirment 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, tirer parti des outils et de 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 : accepter les défaillances comme étant normales, mettre en œuvre des changements progressifs.

Pratique SRE : utiliser des budgets d’erreurs pour déployer continuellement de nouvelles fonctions et fonctionnalités dans des limites acceptables.

Principe DevOps : tout mesurer.

Pratique SRE (ingénierie de fiabilité des sites) : basez les décisions relatives à la publication de nouveaux logiciels sur les indicateurs SLA.

En plus de contribuer au succès des DevOps, l’ingénierie de la fiabilité des sites peut aider les entreprises

• à bénéficier d’une meilleure visibilité sur la santé des services en suivant les indicateurs, les journaux et les traces dans tous les services de l’organisation et en fournissant un contexte pour identifier les causes profondes en cas d’incident ;
  
  
• à quantifier le coût des temps d’arrêt en aidant les équipes de développement et d’exploitation à comprendre le coût des violations des accords de niveau de service et en aidant la direction à mesurer l’impact de la fiabilité du système sur la production, les ventes, le marketing, le service client et d’autres activités de l’entreprise ;
  
  
• à optimiser la réponse aux incidents en élaborant des processus d’astreinte efficaces et en rationalisant les workflows d’alerte ;
  
  
• à créer un centre d’opérations réseau moderne en alliant une compréhension intime des opérations informatiques au machine learning et à l’automatisation, afin d’envoyer des alertes directement à la personne chargée de résoudre le problème.

La migration des centres de données informatiques traditionnels et des centres de données sur site vers les 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 opérationnelles chaque année. De plus en plus, la SRE est considérée comme essentielle pour exploiter ces données afin d'automatiser l'administration des systèmes, les opérations et la réponse aux incidents, et pour améliorer la fiabilité de l'entreprise alors même que l'environnement informatique devient plus complexe.

Une approche de développement cloud natif, à savoir 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 dispersé qui complique l’administration, les opérations et la gestion. Une équipe SRE peut soutenir le rythme rapide de l’innovation permis par une approche cloud native et garantir ou améliorer la fiabilité du système, sans pour autant accroître la pression des opérations sur les équipes DevOps.