Discussion :

[jeff_!]

Bonjour

je dois définir un SLA aux niveau applicatif pour des applis web, mais je ne sais pas ce que doit contenir ce document.
Si quelqu'un pouvait me donner des idées pour en définir un , car apart categoriser les bugs, donner un temps d'intervention et limite le scope du sla je ne voit pas top.


je pense pas que ce forum est soit le plus indiqué pour ce poste mais je sais pas trop ou le mettre.

merci

[tipiak]

Bonjour

je dois définir un SLA aux niveau applicatif pour des applis web, mais je ne sais pas ce que doit contenir ce document.
Si quelqu'un pouvait me donner des idées pour en définir un , car apart categoriser les bugs, donner un temps d'intervention et limite le scope du sla je ne voit pas top.


je pense pas que ce forum est soit le plus indiqué pour ce poste mais je sais pas trop ou le mettre.

merci

Salut,
ma vision des SLA est la suivante:
un SLA est un contrat (entre DEUX services ou prestataires et fournisseurs) qui s'applique à un KPI (Key performance Indicator)
le SLA indique quelles valeurs, quelles évolutions et quelles contraintes ce KPI peut avoir.

ce qui implique tout d'abord d'identifier et de pouvoir mesurer ces KPI (ce que tu as appeler: temps d'intervention, catégories de bug etc).

les KPI ils doivent être déterminée entre tes besoins et ce que tu es capable de MESURER.
par exemple:
- domaine de la recette: (le plus souvent entre les prestataires: les developpeur et le service qui réalise la recette)
délai de quittance d'un bug, delai de correction d'un bug, delai pour valider et refermer le bug (le tout par nature de bug, criticité ou domaine fonctionnel)
- mais tu peux aussi definir des SLA pour l'exploitation (pour les bug en production) mais aussi les pannes (ie : un SAN qui tombe doit être réparé dans les 30 minutes)
- les incidents request ou les changes request

pour identifier les KPI je t'invite à te référer aux doc sur l'ITIL (dans une approche orienté SERVICE tu vas pouvoir mettre des KPI et des SLA pour la plupart des echanges entre deux services)



De plus concernant les SLAs tu dois souvent ajouter des tolérances (et donc un mode Dégradé de ton SLA).
par exemple: un SLA concernant le temps de résolution d'un Defect:
- un defect Critique doit être corrigé en moins de 1 jours avec une adhésion en mode dégradé à 50%
ce qui implique que si un defect est corrigé en 1,25 jour : le SLA est dégradé
si c'est en 2 jour, il est Hors SLA

tu peux ensuite rajouter une contrainte sur le nombre de SLA dégradé à un instant t (ie: pas plus de 10% des defects en cours de traitement doivent être en SLA dégradé)

le dernier point est qu'un SLA ne doit pas fonctionner de manière unidirectionnelle:
si ton service recette impose aux developpeur des SLA sur les temps de correction de BUG, en contrepartie, un SLA imposera à l'équipe de Recette un SLA sur le temps de validation du fix (temps pour RETESTER)

[Luc Orient]

Pour moi, le SLA (Service Level Agreement) est un contrat ou un accord entre un "client" (au sens large) et un service informatique.

C'est typiquement une notion ITIL
Il nécessite aussi la mise en place d'un Centre de Services et d'un certain nombre de processus de support et d'autres dits "tactiques".

L'accord entre un service informatique et un autre est un OLA (Operationnal Level Agreement) et celui entre un service informatique et un fournisseur externe est un UC (Uderpinning Contract)

Le processus majeur pour le SLA est le SLM (Service Level Management), i.e. la gestion des niveaux de service.

Question :
Avez vous suivi une formation ITIL ou à l'ISO 20000 ou même passé le premier niveau de certification ITIL (ITIL Foundation) ?

[jeff_!]

En fait je suis un développeur junior auquel on demander de participer à la rédaction d'un SLA voir un OLA suivant le cas. Donc non je n'ai aucune base sur ITIL ou les norme ISO.
Mais les deux postes me permettent de voir quelle orientation prendre.

Ou puis je trouver de la doc sur ITIL ou ISO à moindre frais

merci