BÂTIR SON CATALOGUE DE
SERVICES
22 conseils pour ne pas se tromper
Que veut-on mettre dans le Cloud. Qu’est ce qui ne
doit pas être dans le Cloud ?
Identifier le portefeuille de
services
1
Créer un catalogue de services pertinent pour une
population d’utilisateurs (le service juridique, la R&D, la
logistique, le marketing, la filiale, le pays..)
Pour les services « transverses » les publier dans un
catalogue public (visible par tous les utilisateurs
accédant au portail)
Créer des Catalogues Privés
et Publics
2
Identifier par population les services dont ils ont
besoin, isoler du cloud les services qui ne sont
demandés que par trop peu d’utilisateurs
Faire une étude de marché
préalable
3
Mettre le « bon » prix devant le bon service : un
service trop cher pour la valeur délivrée ne sera
pas consommé, un service 3 fois plus cher que le
même service disponible sur le cloud public ne
sera pas utilisé
Tarifer ses services
4
Limiter les offres
Ne pas confondre « catalogue de services » et
« inventaire des Galeries Lafayette », et limiter le
nombre de services disponibles
5
Lisibilité des services
Etre explicite sur le contenu du service proposé
dans le catalogue, ce qu’il fait, le niveau de service
proposé
6
Lier le catalogue de
services à la gestion des
demandes et des incidents
Pouvoir identifier et gérer rapidement un utilisateur
se perdant dans le catalogue, souhaitant exprimer
un besoin particulier, et tracer les éventuels
incidents de procédure
7
Limiter la consommation
pour éviter les excès voulus
ou non
Eviter d’accepter la création d’un volume
« inhabituel » de services par un utilisateur (mal
intentionné, ou faisant une simple erreur de saisie)
pour éviter les conflits au moment de la facturation.
Penser à poser une validation manuelle au-delà
d’une quantité convenue de services
8
Penser à la journalisation
des actions
Pouvoir tracer la liste des demandes posées sur le
portail, de façon à mieux piloter le fonctionnement
du portail, et présenter un justificatif auditable en
cas de litige
9
Mesurer la qualité du SLA
fourni
Eviter l’insatisfaction des clients en cas de sous-
qualité du service rendu. Mais également éviter la
sur-qualité conduisant à réduire la marge
opérationnelle du fournisseur de services
10
Penser au cycle de vie
Une fois le catalogue de services publié, penser
qu’il faudra le faire vivre : ajouter de nouveaux
services, éteindre des services obsolètes ou non
consommés
11
Sécuriser les droits d’accès
administrateur
Eviter un accès frauduleux aux outils
d’administration pour créer des services
fantômes, hacker les outils de facturation….
12
Ne pas se limiter à la gestion
des ressources virtuelles
Certaines applications/certains services peuvent
justifier l’utilisation complète ou partielle de
ressources physiques (un serveur physique, une
baie de stockage physique…)
13
Disposer de processus
clairs et documentés
Le provisioning des services consiste à
automatiser des processus. Si on veut créer ex-
nihilo un service alors qu’aucun processus
n’existe pour le constituer invalidera sa
publication dans le catalogue de services
14
S’ouvrir vers le sourcing de
services hybrides
Prévoir les situations d’atteinte des limites de
capacités internes pour aller consommer la
ressource à l’extérieur du cloud, le temps de
l’absorption des pics de charge
15
S’ouvrir vers le sourcing de
services hybrides
Prévoir les situations d’atteinte des limites de
capacités internes pour aller consommer la
ressource à l’extérieur du cloud, le temps de
l’absorption des pics de charge
16
Penser à l’évolutivité horizontale
et verticale des services
Un utilisateur doit pouvoir faire évoluer sa
demande de service horizontalement (passer
d’une VM type Small à une VM Large ou XL) et
verticalement (passer d’un service peu sécurisé
à un niveau de criticité plus important)
17
Quelle réactivité apporter
aux clients
Quel est le temps « raisonnable » pour créer un
nouveau service ? Comment le mesurer, et le
respecter ?
18
Associer le pool de
ressources adaptées aux
SLAs proposés
Avoir des mécanismes de redondance permettant
la tenue d’objectifs de disponibilité pour les
besoins critiques, et à l’inverse, ne s’appuyer
que sur les mécanismes nécessaires pour les
niveaux de criticité moindre
19
Assurer la conformité
réglementaire
Lors de la demande de création d’un service
composite, valider avant de délivrer le service à
l’utilisateur que tous ses composants (serveur,
stockage, Operating System, applicatifs, niveaux
de correctifs…) sont conformes aux politiques de
sécurité du fournisseur et/ou du demandeur
20
Prévoir des mécanismes
d’audit
Pouvoir à tout moment d’auditer le niveau de
conformité des environnements en usage et
notifier l’utilisateur de son écart par rapport aux
règles, voire couper le service en cas de risque
de sécurité majeur
21
Identifier les ressources
orphelines
S’assurer que toutes les ressources
commisionnées ont bien un propriétaire que l’on
pourra facturer, éliminer les VM orphelines
20
S’assurer de la qualité de
support aux utilisateurs
Prévoir les compétences, et les contrats du
support back to back avec les composants
matériels et logiciels des services proposés
22
Top Related