Niveau 2 – Niveaux de service et utilisation des ressources applicatives

un département, un groupe d’utilisateurs,
un ensemble de clients à  distance,
ou autres destinataires des services.
Les figures 6, 7 et 8 contiennent
la liste des questions classiques auxquelles
le niveau 2 répond, les données
de mesures à  collecter et les rapports
classiques.
Les actions de niveau 2 sont plus
efficaces quand on établit des SLA
(service level agreement) entre IT et
les business units. Un SLA formalise la
performance, la disponibilité et autres
caractéristiques d’un système, d’une
application ou de tout autre service
qu’IT procure à  une business unit. La
figure 9 montre quelques-unes des
mesures que spécifie un SLA classique.
En établissant des SLA puis en
mesurant la performance correspondante,
on ne décide plus subjectivement
si un système ou une application
est « trop lent » : si les mesures de performances
égalent ou dépassent
constamment ce que stipule un SLA,
on sait que tout va bien.
Pour comprendre les causes des
performances système globales (telles
qu’analysées au niveau 1), il faut dans
l’idéal récapituler des mesures
comme l’utilisation de la CPU et des
disques via des applications ou des
tâches applicatives. Malheureusement,
l’iSeries n’a aucun moyen intégré
d’effectuer cela et donc vous devrez
développer vos propres requêtes
SQL, programmes ou stratégies alternatives
pour y parvenir. L’analyse doit
être hebdomadaire ou mensuelle.
De telles analyses peuvent montrer
quelles applications ou tâches génèrent
la plus forte proportion de
charge système et donc on peut
concentrer son attention sur les applications
qui présentent les gains potentiels
les plus importants. Cette information
peut aussi être corrélée dans
le temps avec celle du niveau de service collectée, pour analyser plus profondément
les causes de niveaux de
services insuffisants. Ainsi, si vous déterminez
que la réponse est trop élevée
pour certains intervalles de temps,
vous pouvez utiliser votre analyse des
applications pour détecter les principales
responsables.
Enfin, vous pouvez définir des
seuils d’utilisation de ressources pour
les applications et instaurer des alertes
(figure 10) pour identifier automatiquement
les applications qui dépassent
leurs seuils trop fréquemment.
Les alertes de niveau 2 peuvent simplement
journaliser des informations
d’événements dans un fichier pour
analyse ultérieure, plutôt que d’envoyer
un message à  un opérateur ou à 
un administrateur système pour attention immédiate. Muni de l’historique
des alertes, vous pourrez repérer
les applications justiciables de diagnostics
plus poussés, comme décrit au
niveau 2.