Le rôle d'Elastic dans le SRE du groupe Crédit Agricole

Site Reliability Engineering (SRE) réduit le Mean Time To Repair (MTTR) de 80%.

Une promesse que l’on peut retrouver dans les articles SRE de Google. Mais qu’en est-il dans la réalité professionnelle des organisations DevOps ? En particulier un acteur majeur du domaine bancaire le groupe Crédit Agricole.

Tout d’abord notre rôle de SRE nous sensibilise à la fiabilité, qui est un enjeu crucial dans les usages des squads produits. Nous produisons au travers d’un Cloud privé des plateformes d’observabilité et de moteur de recherche avec Elastic Cloud Entreprise. Nous avons des engagements de services (SLA) de nos plateformes Elastic à respecter pour l’ensemble des entités du groupe Crédit Agricole.

Le SRE cherche à mettre en place des bonnes pratiques pour surveiller la saturation, les erreurs, le trafic et la latence de son produit.

J’ai eu l’occasion de mentionner la saturation de nos plateformes Elastic avec le « Elastic Paris Meetup #63 : Au secours, mon cluster Elastic ne répond plus ! ». Aujourd’hui je souhaite vous proposer un retour d’expérience SRE sur la construction des Service-Level Indicator (SLI).

Nous suivrons les disponibilités des plateformes avec Elastic Uptime, nous utiliserons l’Elastic Machine Learning pour ne louper aucune anomalie et nous serons notifiés avec ce qu’il faut pour préparer la contre-attaque avec Kibana Alerting.