Dans l’article Qu’est-ce que la SRE (Site Reliability Engineering), nous avons brièvement décrit le rôle d’un professionnel qui occupe ce poste. Mais que serait une journée type dans la peau d’un ingénieur de la fiabilité des sites ? Regardons ses activités courantes de plus près.

La journée type du SRE commence avec les urgences liées au décalage de fuseau horaire de la « dev team » dans laquelle vous êtes inséré. L’équipe de développement est composée de développeurs responsables d’un service ou d’un produit spécifique. Les responsabilités et charges varient selon les décisions managériales de votre organisation, mais – généralement – vous travaillez : soit au sein d’une équipe produit avec un véritable « effectif » prêté au rôle de SRE ; ou embauchés en appui aux développeurs, sur des objectifs précis. Dans tous les cas, même les équipes de développement qui n’ont pas de SRE de référence, dans les grandes installations, disposent souvent d’un support basique, qui a aussi des missions de feuille de route stratégique, propose des services centralisés, forme les équipes, assiste les nouvelles releases ou les incidents graves. Et pas forcément en journée, étant donné que souvent, dans le cas des multinationales par exemple, les utilisateurs et les équipes sont dispersés aux quatre coins du globe – et donc sur des fuseaux horaires différents. Faire partie intégrante du poste peut aussi signifier être « de garde », c’est-à-dire disponible en cas d’accidents survenant dans les services en dehors des horaires normaux.

Ensuite le SRE examine les systèmes de suivi du travail de l’équipe, les moniteurs, qui peuvent être des tableaux de bord, des systèmes de télémétrie et d’alarme. Les alarmes se déclenchent lorsqu’une partie de l’infrastructure entre dans un état inattendu, et nécessite une maintenance : manque d’espace, ancien logiciel, bug, activités de sécurité, pannes d’équipements… Toutes les alarmes ne sont pas prioritaires mais cela dépend des impacts engendrés : la gestion et la priorisation sont des compétences cruciales pour un SRE. Si les problèmes concernent la production, une procédure peut être déclenchée, par conséquent une notification et un appel téléphonique automatique arrivent sur le téléphone portable du professionnel de garde, générant un « accident ». Suit ensuite une phase de triage et d’atténuation des impacts.

L’ingénieur de la fiabilité des sites n’est cependant pas un professionnel qui travaille uniquement par téléphone. C’est un métier à part entière : certes, des tâches d’administrateur système sont réalisées, mais dans le but d’apprendre et de rendre le système meilleur, plus automatique et simple.

Stand-up meeting

Une pratique courante consiste à commencer les journées par des réunions debout, c’est-à-dire de courts moments de 15/30′ dans lesquels l’équipe fait le point sur l’avancement du travail effectué, le travail prévu, et apporte à l’attention de tous, les blocages, alarmes ou éléments pouvant faire changer les plans. S’il y en a, les discussions se poursuivent à la fin de la réunion : le but est de rechercher des solutions rapides et d’intégrer toute nouvelle information.

Pour en savoir plus, consultez notre article Les 5 règles pour un stand-up meeting (ou réunion debout) agile impeccable

Fiabilité et vélocité

En tant que partie intégrante d’un produit logiciel, la tâche du SRE est de rechercher la meilleure stratégie entre fiabilité et vélocité. D’une part, la fiabilité : il faut poursuivre des objectifs utiles à l’utilisateur. La disponibilité à 100 % est une valeur presque théorique, utile uniquement dans de très rares cas critiques et qui entraîne des coûts élevés en machines, en personnes et en systèmes. Le plus souvent, les systèmes raisonnent sur des niveaux de service appelés « neufs » suivis d’un certain nombre. Par exemple, un accord de niveau de service (SLA) à 99,99 % est appelé « quatre-neuf » et correspond à environ 53 minutes de pannes par an, ce qui est acceptable pour un grand nombre d’applications non critiques. Il existe un SLA pour chaque service, qui correspond à l’accord entre le fournisseur de service et le client et qui définit le montant de « fiabilité », par exemple pour la disponibilité ou la latence. La fiabilité a un impact important sur les dépenses, car une haute disponibilité est synonyme de coûts élevés.

La vélocité, d’autre part, remet en question la vitesse à laquelle l’équipe de développement travaille et livre : il s’agit de maximiser la version sur le long terme et de s’assurer que le système est facile à entretenir, en plus d’être simple à utiliser.

Plus le SLA est bas, moins les fonctions offertes par le produit doivent être critiques ; pensez par exemple au SLA d’un logiciel de premiers secours versus une plateforme de facturation. Avec un plus grand nombre de minutes pendant lesquelles le service peut être « indisponible », la marge d’erreur d’une équipe lors d’activités à risque est plus grande (on parle de budgets d’erreur). Il est donc moins coûteux d’utiliser ces infimes quantités de perturbations que l’utilisateur peut supporter, dans les retours d’informations sur les versions de fonctionnalités et les lancements de nouveaux services, car elles pourraient générer des problèmes jamais vus auparavant. Une instabilité sous-jacente du système, d’autre part, génère une série d’inefficacités et de problèmes déjà vus précédemment, et dont il est difficile de tirer des leçons.

Bref, si vous devez vraiment faire une erreur, essayez d’en faire une que vous n’avez jamais rencontrée, ainsi vous aurez toujours quelque chose de nouveau à  apprendre !

Les piliers du métier, rendus populaires par Ben Treynor Sloss, vice-président principal supervisant les opérations techniques chez Google – et à l’origine du terme « Site Reliability Engineering », sont :

• Réduire les « silos » : les compétences nécessaires pour produire et assurer la maintenance du logiciel doivent être toutes présentes dans une même équipe de travail, ou collaborer entre différentes structures organisationnelles – le monde réel ne prévoit pas de distinctions théoriques, la complexité des systèmes requiert de nombreuses compétences différentes.
• Accepter l’échec : encore en raison de la complexité, le monde des systèmes informatiques est intrinsèquement peu fiable. L’erreur involontaire, catalysée par le facteur humain reste une possibilité et un facteur à gérer. La complexité accidentelle est une grosse dette technique.
• Effectuer des changements progressifs : les petits changements garantissent de faibles risques grâce à la possibilité de les doser. Se concentrer sur des aspects et des services spécifiques, avoir des objectifs précis et savoir ce qu’il faut réparer ou non, permet de faire des progrès modestes et réguliers, qui doivent avoir un effet sur l’utilisateur en termes de fonctionnalités, de fiabilité et d’économie.
• Tirer parti des outils et de l’automatisation : toute solution manuelle peut être automatisée, mais vous devez comprendre quoi et comment utiliser son avantage. Les objectifs sont fixés par l’équipe de développement selon une feuille de route. Le SRE facilite son exécution. Lorsque la même équipe travaille sur les mêmes systèmes pendant des années, ils ont tendance à devenir extrêmement élaborés et inextricablement liés à la même équipe, mais cela n’a pas à se produire. Les pipelines et plates-formes d’automatisation sont d’excellentes armes à la fois pour garder la dette technique sous contrôle et pour étendre les connaissances des processus au sein de l’équipe.
• Mesurer : sans données, il est impossible de dire objectivement s’il y a eu une amélioration, c’est pourquoi l’observabilité des systèmes est essentielle pour corriger le cap avec un retour d’information en temps opportun. Tout doit être suivi, des métriques des actions que le logiciel effectue aux erreurs de l’utilisateur. Le service doit être amélioré pour l’utilisateur, avant l’équipe de développement. Si notre cloud est stable mais qu’un produit génère des erreurs, l’utilisateur en souffre quand même.

Ces indications générales conduisent ensuite à des principes et tactiques opératoires ainsi qu’à des pratiques plus précises. Des outils tels que Continuous Delivery, suppression pragmatique de la dette technique, complexité, rétrospectives, simulations d’accidents, post-mortem, sessions d’ateliers de formation, organisation du travail de type Lean, suppression pragmatique des goulots d’étranglement, etc. Gérer l’information de manière précise et opportune, avec toute cette concentration, est une nécessité qui découle toujours de la complexité. Si par chance vous gérez actuellement quelques dizaines de services, il se peut que tôt ou tard vous devriez peut-être faire face à des centaines de nouveaux services qui tombent en panne au milieu de la nuit, conçus quelques années auparavant avec la technologie disponible à cette époque, par des programmeurs qui ne sont plus dans l’entreprise. C’est ce qu’on appelle communément l’héritage.

Le risque d’asymétrie de l’information

Les SRE ne connaissent pas en détail tout ce qui est en ligne, parfois l’asymétrie d’information est extrême, on ne connaît pas la base de code ni même ce qui se passe. La capacité à donner un sens général aux composants d’un système (ses parties) et aux événements qui le déclenchent est cruciale, surtout en phase d’urgence. Si vous perdez la connaissance et le contrôle du système, des opérations manuelles non documentées et répétitives peuvent apparaître. Garantir un bon niveau de service sera alors éprouvant et très difficile.
Il existe deux manières d’atteindre l’objectif plus abstrait de « faire fonctionner les systèmes de production ». La première est de construire des systèmes robustes, faciles à modifier, étendre et programmer. La seconde consiste à constituer une énorme équipe d’assistance capable de redémarrer les systèmes, d’observer des graphiques, de noter des listes interminables de tâches, de répéter des procédures et d’éteindre des incendies lorsque les choses prennent feu.

Pour approfondir le sujet, consultez également l’article Site Reliability Engineer – le concept de fiabilité (coming soon)