🌅

Comment définir et mettre en place des SLA / SLI / SLO pour son application

Do not index

Primary Keyword

Lié à Analyse sémantique (Articles liés) 1

Lié à Analyse sémantique (Articles liés)

Statut rédaction

A améliorer

Lié à Analyse sémantique (Articles liés) 2

Introduction Vocabulaire Service-Level Objective (SLO)Service-Level Agreement (SLA)Service-Level Indicator (SLI)Comment définir les SLA / SLI / SLO d’une application d’entreprise ?Conclusion

Introduction

La principale mission d’un système d’information est de répondre à un besoin métier. En effet, chaque application déployée doit pouvoir répondre aux besoins des utilisateurs de l’entreprise ou d’utilisateurs externes. L’objectif de ces applications est d’être disponible et opérationnelle lorsque l’utilisateur en a besoin. Souvent, on voudra que ces applications soit disponibles 24h/24 et 7J/7. Mais comment définir cette disponibilité ? Comment définir contractuellement qu’une application sera disponible ou non.

Toutes ces problématiques sont définis dans les études SRE (Site Reliability Engineering) . Dans cet article nous définirons les mots SLA, SLI et SLO avant d’expliquer comment les définir pour son entreprise.

Vocabulaire

Service-Level Objective (SLO)

Une des principales caractéristique d’un service délivré par une application est sa disponibilitié. Par disponibilité, on définiera la capacité de ce service à répondre au besoin métier. Par conséquent :

Une application indisponible ne pourra pas répondre au besoin métier.

Une application défaillante ne pourra pas répondre au besoin métier.

Le monitoring de la disponibilité d’une application doit être utilisé comme indicateur historique du bon fonctionnement d’une application et permet une estimation du bon fonctionnement futur de cette même application.

Le SLO est l’implementation numérique et quantitative de l’objectif de disponibilité d’un service. Ainsi toute discussion sur l’amélioration de la disponibilité d’un service doit pour avoir but d’atteintre le SLO.

Il faut noter que plus le SLO est restrictif , plus il sera couteux.

Prenons un exemple. Imaginons que nous définissons le SLO d’une application de comptabilité accessible depuis une centaine d’employés internes à l’entreprise situé sur plusieurs continents (et donc des fuseaux horaires différents). Cette application est critique pour l’entreprise. Il est estimé que la non disponibilité de cette application coûte à l’entreprise 1000$/minute.

Dans le contexte ci-dessus, nous allons définir un SLO restrictif afin d’éviter que l’application soit non disponible (et ainsi éviter les pertes). Nous définierons que le SLO de l’application est :

Indisponibilité accepté : 30 minutes / An

Un tel niveau de disponibilité exige une infrastructure informatique importante. On peut imaginer des équilibreurs de charges, des bases de données performantes, des restaurations de backup rapides lors d’incident etc …

Avec un tel exemple, on peut bien comprendre, que le SLO d’un service doit être aligné à la stratégie d’entreprise.

Service-Level Agreement (SLA)

Comme son nom l’indique, le SLA est un engagement entre deux parties. Cela peut être entre deux entreprises (un provider et un client) ou bien entre départements dans une grande entreprise. Le SLA va définir votre engagement sur la disponibilité du service. Cet engagement est très souvent contractualisé entre les deux parties et peut inclure des pénalités dans le cas où le SLA n’est pas respecté. Ces pénalités sont souvent financières et peuvent se matérialiser par des réductions du prix de l’abonnement au service pour les prochains mois.

Le SLA se définit souvent en pourcentage. Ainsi, on peut définir la disponibilité d’un service à 99.95% (ce qui donne une durée d’indisponibilité de 4h 22m 58s par an).

Bien sur, vos clients peuvent vous demander vos rapports de disponibilité sur des périodes précises (par exemple pour des audits) pour vérifier que vous respectez vos engagements. Il est donc primordial d’avoir un système de monitoring qui mesure votre taux de disponibilité.

En tant que provider de service, il est primordial de définir des SLA plus “souple” que les SLO définit en interne. Le SLO étant un objectif, il ne mesure pas votre taux de disponibilité actuel. Définir un SLO et un SLA similaire vous expose à des pénalités.

Service-Level Indicator (SLI)

Les SLI sont les indicateurs factuels de la disponibilité de votre service. Ils représentent l’état de votre service à un moment donné. Ce sont ces indicateurs que l’on mesurera avec le système de monitoring pour prouver le taux de disponibilité d’un service donné. La définition des SLI sont des points clés dans la définition d’une stratégie SRE. Ceux-ci doivent pouvoir représenter l’ensemble des aspects du service qu’il mesure.

Comment définir les SLA / SLI / SLO d’une application d’entreprise ?

Comme définis plus tôt dans cet article, les SLO , SLA, SLI sont des résultantes d’une stratégie d’entreprise.

Une stratégie d’entreprise va définir la position actuelle et les enjeux de l’entreprise pour les années futures. Ces enjeux définis vont définir des objectifs. Enfin ces objectifs définiront les SLO de vos services informatiques.

Prenons un exemple : Imaginons que vous possédez une entreprise de plus de 3000 personnes et qu’une des stratégies d’entreprise clés définies pour cette année est de permettre une meilleure communication au sein de l’entreprise en centralisant cette communication à travers un portail d’entreprise (une application web) que l’entreprise a crée dans le passé.

Vous savez que ce portail a eu un taux de disponibilité de 78.8% au sein de la dernière année. Vous définissez que ce portail va devenir l’outil clé de votre future communication et qu’il doit atteindre un taux de disponibilité (SLO) de 97.0% pour cette année.

Bien que certains SLI étaient déja définis , vous décidez de les redéfinir incluant des métriques techniques et métiers. Ainsi vous définissez ces SLI :

L’url de la page de communication est accessible par l’ensemble de l’entreprise

Les posts de communication apparaissent sur la page

Le temps de réponse de 95% des requêtes doit être en dessous de 700 ms

Vous définissez que le service informatique en charge du développement et de l’hébergement de ce portail s’engage sur une disponibilité (SLA) de 93% (d’ici 3 mois) contractualisé avec le service de communication.

Pour répondre à cette nouvelle demande, vous demandez un budget permettant de mettre en place les nouvelles fonctionnalités ou infrastructure qui permettront d’atteindre ces nouveaux objectifs (optimization de code, ajout de cache statique pour les posts etc …). Il ne reste plus qu’à implémenter et atteindre ces objectifs qui seront revus dans le future lors de l’élaboration d’une nouvelle stratégie d’entreprise (annuelle, bi-annuelle etc ..)

Conclusion

Les systèmes d’information répondent à des besoins métiers, ainsi les applications et services qui les composent doivent répondre à ces besoins. Selon votre stratégie d’entreprise, vous devez définir les disponibilités de vos services en accordance avec vos besoins. Une augmentation des disponibilités de vos services engendreront des coûts qui doivent être mesuré et réfléchis.