La fiabilité est la propriété la plus importante d’un logiciel. C’est ce que comprennent aussi bien le directeur que l’équipe logiciel de FinEasy AG, quand certains clients se plaignent soudain de temps de réaction longs, voire même de pannes, de l’app . Il faut alors agir ou réagir vite pour éviter des pertes de ventes, des clients insatisfaits et des préjudices irréparables en termes d’image.
Disclaimer: il s’agit ici d’un exemple fictif, les noms, personnes et organismes sont inventés.
La société de Suisse centrale FinEasy AG est un nouvel acteur dans le marché suisse des FinTech – avec des objectifs ambitieux: elle souhaite non seulement devenir le premier fournisseur de services de paiement en Suisse mais aussi soutenir les clients privés avec des services utiles sur le thème de la gestion de fortune, de l’investissement et du conseil en épargne. Dans le cadre de ses efforts, FinEasy a développé l’app Saving Agent dans laquelle les utilisateurs documentent leurs recettes et dépenses et reçoivent un catalogue de mesures personnalisé pour leur stratégie d’épargne personnelle.
Le service est vite devenu un succès. Mais depuis peu, l’application développée et exploitée dans le cloud ne fonctionne plus de manière fiable, de premiers utilisateurs se sont déjà plaint de temps de réaction longs et de pannes isolées. Le directeur est inquiet. Il fait venir Martin, ingénieur logiciel de la marque et Product Owner de Saving Agent, dans son bureau: il doit résoudre ce problème et trouver un moyen de garantir la fiabilité de l’application aussi sur le long terme. Ce n’est pas une tâche facile: si l’application ne refonctionne pas correctement très vite, la société FinEasy AG risque d’enregistrer des pertes de ventes, un grand nombre de clients insatisfaits et des dommages quasi irréparables à son image. La vitesse de développement ultérieure de Saving Agent serait aussi réduite – au vu de la longue feuille de route que prévoit FinEasy AG pour l’application, et du grand backlog prévu sur les fonctions, c’est le scénario d’horreur absolu. Martin se rend compte de la grande pression qu’il subit maintenant. Mais comment peut-il surmonter seul tous ces obstacles?
SRE améliore la fiabilité des logiciels
Martin décide de faire appel à un expert extérieur et pense alors aux spécialistes de Swisscom. Car ceux-ci connaissent parfaitement le Site Reliability Engineering – en abrégé SRE. SRE est un modèle de gestion de service développé par Google et comprend différentes méthodes et pratiques basées sur les logiciels qui servent à créer des systèmes logiciels extrêmement évolutifs et fiables. C’est justement dans les environnements natifs cloud que le SRE contribue à trouver un équilibre entre la publication de nouvelles fonctions et sa fiabilité pour les utilisateurs. Ainsi, SRE est directement lié à l’approche DevOps et décrit des procédures très spécifiques pour convertir le concept théorique DevOps en un workflow concret. Avec un portefeuille de services complet, les Customer Reliability Engineers (en abrégé: CRE) de Swisscom soutiennent les entreprises dans la mise en œuvre du SRE et les aident à améliorer durablement la fiabilité de leurs applications.
C’est clair dès le début: la fiabilité de Saving Agent, et de toutes les autres applications que FinEasy développera à l’avenir, ne peut être assurée que par un travail en commun. Swisscom mais aussi Martin et ses collaborateurs doivent donc tous y contribuer. C’est pourquoi des objectifs d’engagement sont formulés au préalable, qui sont contraignants pour les deux parties: Que font Swisscom et la société FinEasy AG pour que les applications fonctionnent de manière fiable? Où sont les responsabilités?
Le CRE se procure une vue d’ensemble de l’application, et ceci à partir de différents points de vue: en commun avec Martin, il évalue non seulement quels objectifs FinEasy poursuit avec l’application mais il s’occupe aussi de manière approfondie de l’ensemble de l’architecture d’application et de ses interactions. Pour rendre le système opérationnel, il procède en outre à une évaluation des risques et élabore des mesures qui permettent de répondre aux exigences métier sur le plan de la disponibilité et de la fiabilité.
Développement de logiciels selon des règles claires
Tous ces points sont consignés dans un rapport appelé Application Reliability Review. Celui-ci sert de base à Martin et à son CRE pour définir ensemble des Service Level Objectives (SLO) et des Service Level Indicators (SLI). Tandis que les SLO décrivent les objectifs de fiabilité souhaités d’un logiciel, les SLI représentent des métriques pour déterminer la disponibilité effective du système, par exemple le taux d’interrogations logicielles réussies et échouées.
Les SLI et les SLO jouent un rôle élémentaire dans le Site Reliability Engineering. Ainsi, les indicateurs SLI doivent être vus comme des métriques de la satisfaction des utilisateurs: ils déterminent, suivent et mesurent le succès de l’expérience utilisateur et montrent si les objectifs SLO peuvent être effectivement tenus, ou s’il existe un risque de rendre les utilisateurs de sa propre application insatisfaits.
A partir de là, les SLI et les SLO déterminent aussi le budget d’erreurs qui est à la disposition des ingénieurs logiciels pour continuer à développer une application: de nouveaux services ou fonctions logicielles ne doivent être déployés que s’ils atteignent ou dépassent la valeur SLO définie. Mais s’ils présentent encore trop d’erreurs ou tombent plus longtemps en panne que ce que le budget d’erreurs autorise, il ne doit plus y avoir d’autres déploiements jusqu’à ce que l’application revienne dans le cadre des SLO.
Site Reliability Engineering avec Swisscom
- Swisscom possède une longue expérience dans l’exploitation de plateformes et d’applications cloud propres et externes.
- Les clients ont via leur Customer Reliability Engineer de Swisscom accès à une large base de collaborateurs ayant une expertise approfondie de la technologie et beaucoup de Best Practices.
- Le service SRE Swisscom inclut la surveillance de bout en bout de l’application. Le CRE reçoit ainsi toutes les informations nécessaires pour repérer tôt les problèmes ou mener des analyses des causes.Le modèle SRE/CRE de Swisscom est hybride. Ce qui veut dire que Swisscom agit quelle que soit la plateforme.
L’offre en détail: factsheets (PDF)
Soutien de l’extérieur
Une fois clarifiés les SLO suivis et les SLI utilisés, Swisscom peut soutenir Martin professionnellement dans l’exploitation de Saving Agent: Swisscom intègre le monitoring de FinEasy dans son système de Reliability Management et configure une alarme. Lors de futurs incidents, Martin aura à ses côtés un Customer Reliability Engineer de Swisscom pour le conseiller. Il est immédiatement notifié dès que les objectifs de service convenus de Saving Agent ne sont plus respectés, il identifie la cause de base de l’événement et informe les équipes opérationnelles compétentes sur les incidents.
Chaque incident est suivi pour finir de ce qu’on appelle un «postmortem»: y sont consignés non seulement l’incident, ses conséquences et les mesures pour le résoudre, mais aussi les mesures suivantes qui doivent empêcher que l’incident ne se reproduise. Ainsi, des approches de solutions préventives sont aussi élaborées avec SRE et contribuent à une meilleure fiabilité du logiciel. Et les reportings mensuels sur les non-respects des SLO ainsi que des rapports trimestriels complets aident Martin à continuer à améliorer en commun avec Swisscom la fiabilité de Saving Agent et à garder les durées de réparation les plus courtes possibles.
