Comme pour la plupart des choses en affaires, le diable réside dans les détails.
Bien que tous les fournisseurs de services infonuagiques (CSP) offrent une certaine disponibilité opérationnelle, il est important de comprendre ce que le fournisseur mesure réellement.
Les directeurs des systèmes d’information (DSI) expérimentés comprennent ce point.
Ils savent qu’il existe deux types d’ententes de niveau de service opérationnel (SLA) :
- Disponibilité des infrastructures
- Disponibilité des applications
Ce qui distingue un DSI expérimenté de ses pairs, c’est la capacité de comprendre lequel il choisit.
Souvent, les fournisseurs de services infonuagiques offrent un chiffre de disponibilité élevé, comme 99,99%. Cependant, quand on creuse là-dessus, ils ne parlent vraiment que de l’infrastructure.
En tant que DSI, il est important de vous poser cette question :
« Est-ce que ça a vraiment de l’importance que l’hôte ESX ou le stockage soit opérationnel? »
Bien sûr, l’application dépend de l’infrastructure sous-jacente pour fonctionner, mais à quoi ça sert si les serveurs sont en ligne alors que l’application ne l’est pas?
Sachant cela, vous voudrez vous assurer que votre CSP offre un SLA pour la disponibilité des applications.
Pourquoi?
Parce que ça leur assure qu’ils ont un peu d’intérêt quand il s’agit de ce qui est important pour votre entreprise.
Quel est un bon SLA opérationnel pour vos candidatures?
Eh bien, ça dépend vraiment de l’application. Les applications de logiciel en tant que service (SaaS) comme Salesforce.com, Microsoft Office 365 et SAP Concur peuvent atteindre des niveaux de disponibilité très élevés grâce à leur architecture à l’échelle du web.
Dans bien des cas, les niveaux peuvent atteindre 99,999%.
En revanche, les applications d’affaires traditionnelles comme la planification des ressources d’entreprise (ERP) et l’entrepôt d’entreprise SAP (BW) n’ont pas le même luxe que ces applications SaaS.
En conséquence, il est très difficile/coûteux d’architecturer un SLA de 99,999% ou même 99,99%.
Oui, il existe de nombreux déploiements où l’ERP n’a jamais été hors service, mais c’est principalement grâce à de bonnes pratiques opérationnelles et de gestion du changement plutôt qu’à l’architecture technique sous-jacente.
Supposons que vous ressembliez à beaucoup de DSI : SAP ERP est une application métier centrale et vous ne pouvez tout simplement pas la laisser tomber. Après tout, si c’est plus tard, ta chaîne de production s’arrête, tu ne peux pas expédier le produit ni traiter les commandes.
En tant que DSI, que faites-vous?
Il y a de fortes chances que vous insistiez pour que votre fournisseur vous offre une disponibilité de 99,99%, car vos processus d’affaires peuvent probablement tolérer quatre minutes d’interruption imprévue par mois.
C’est un peu gênant, mais on peut vivre avec.
Fais attention à ce que tu demandes
Ainsi, le fournisseur de services fait exactement ce que vous demandez. Ils doublent tout et mettent toutes les fonctionnalités nécessaires pour architecturer votre application et atteindre une disponibilité de 99,99%.
Cela vous coûte bien sûr plus cher. Beaucoup plus d’argent.
Puisque la plupart des CSP offrent soit une disponibilité de 99,5% (ou, dans le meilleur des cas, 99,9%) pour le SAP, cela devient un déploiement ponctuel. Ce qui rend cela beaucoup plus difficile à gérer.
Pourquoi?
Parce qu’au lieu d’avoir 30 personnes en opérations pour le réparer quand ça tombe en panne, il ne vous reste probablement qu’un ou deux professionnels en technologies de l’information (TI) qui savent vraiment comment c’est configuré.
Et en informatique, ce qui peut mal tourner arrive généralement, mais jamais, jamais, de la façon dont cela a été testé pour échouer. (Hé, si rien d’autre, le vieux Murphy a de l’humour!)
Donc maintenant, avec cette architecture « super-duper » à 99,9%, quand quelque chose est brisé, il faut trouver l’un des deux gars qui l’ont configuré pour le réparer. Au lieu de faire face à un problème qui aurait dû prendre 30 minutes à résoudre, ça s’est transformé en huit heures d’escalade et de maux de tête.
Avez-vous plus de disponibilité ou plus de complexité?
Évidemment, on peut dépenser beaucoup d’argent pour concevoir des applications traditionnelles afin de promettre une grande disponibilité, mais cela comporte un coût supplémentaire – c’est-à-dire le risque d’ajouter beaucoup de complexité opérationnelle.
Le plus souvent, c’est le gros doigt qui est en tort plutôt que l’architecture.
Lorsque vous travaillez avec votre CSP, votre meilleure option est de vous assurer qu’ils vous fournissent un SLA de disponibilité des applications qui correspond à leurs standards. Vous voulez aussi qu’ils établissent un plan de continuité des activités pour vous au cas où de mauvaises choses arriveraient.
Un DSI expérimenté verra la situation sous cet angle :
« Mes applications d’affaires sont importantes, et nous mettrons tous les composants en place pour qu’ils soient opérationnels, mais s’ils sont hors service, nous avons un plan pour remédier à la situation. »
La morale de l’histoire?
Un DSI expérimenté sait que gérer ses affaires uniquement sur la promesse du SLA d’un fournisseur de services infonuagiques est une recette pour le désastre.