Le SLA, ou «accord de niveau de service», est un accord de garantie entre le client et le fournisseur de services sur ce que le client recevra en termes de service. Il stipule également les compensations en cas de temps d'arrêt dû à la responsabilité du fournisseur, et ainsi de suite. En somme, le SLA est un document de confiance grâce auquel le data center ou le fournisseur d'hébergement convainc un client potentiel qu'il sera entièrement pris en charge. La question est que tout peut être écrit dans un SLA, et les événements mentionnés dans ce document n'arrivent pas fréquemment. Le SLA n'est certainement pas un indicateur fiable pour choisir un data center, et il ne sert clairement pas à cela.
Nous avons tous l'habitude de signer des contrats qui imposent certaines obligations. Le SLA n'échappe pas à la règle — généralement, c'est le document le plus déconnecté de la réalité que l'on puisse imaginer. À part le NDA dans les juridictions où la notion de «secret commercial» n'existe pas vraiment, rien n'est peut-être plus inutile. Tout le problème est que le SLA n'aide en rien le client à faire le bon choix de fournisseur, il ne fait que créer une illusion.
Que écrivent le plus souvent les hébergeurs dans la version publique du SLA qu'ils montrent au public ? Eh bien, la première ligne mentionne un terme tel que «fiabilité» de l'hébergeur — cela va généralement de 98 à 99,999 %. En réalité, ces chiffres ne sont qu'une belle invention des marketeurs. Autrefois, lorsque l'hébergement était jeune et cher, et que les nuages n'étaient qu'un rêve pour les spécialistes (tout comme l'accès à large bande pour tous), l'indice de disponibilité de l'hébergement était extrêmement important. Maintenant, lorsque tous les fournisseurs utilisent plus ou moins le même équipement, sont sur les mêmes réseaux principaux et offrent les mêmes forfaits, cet indice de disponibilité est totalement non révélateur.
Y a-t-il un «bon» SLA ?
Il existe bien sûr des versions idéales de SLA, mais toutes sont des documents atypiques rédigés et conclus manuellement entre le client et le fournisseur. Ce type de SLA concerne souvent des travaux spécifiques plutôt que des services.
Que doit contenir un bon SLA ? Pour résumer, un bon SLA est un document qui régule les relations entre deux parties, donnant au client le maximum de contrôle sur le processus. Concrètement, cela signifie qu'il existe un document qui décrit les processus globaux d'interaction et régule les relations entre les parties. Il établit des limites, des règles et devient lui-même un levier que les deux parties peuvent utiliser pleinement. Grâce à un SLA approprié, le client peut simplement contraindre le prestataire à travailler comme convenu, tandis que le prestataire peut se défendre contre les « désirs » injustifiés d'un client trop actif. Cela ressemble à ceci : « Notre SLA stipule cela et cela, éloignez-vous, nous faisons tout comme convenu ».
Ainsi, un « bon SLA » = « un contrat de service adéquat » qui donne le contrôle sur la situation. Cela n'est possible que lorsque les relations sont « équilibrées ».
Ce qui est écrit sur le site et ce que l'on attend réellement sont des choses différentes.
En fait, tout ce que nous allons discuter par la suite sont des astuces marketing typiques et un test de vigilance.
Prenons les hébergeurs nationaux populaires, chaque offre semble plus attrayante que l'autre : support 25/8, disponibilité des serveurs de 99,9999999 % du temps, une multitude de centres de données à travers la Russie. Veuillez noter le point sur les centres de données, nous y reviendrons un peu plus tard.. Pour l'instant, parlons de la statistique idéale de la résilience et des défis rencontrés par une personne lorsque son serveur entre dans le « 0,0000001 % des pannes ».
Avec des taux de disponibilité de 98 % et plus, toute panne est un événement à la limite de l'erreur statistique. Le matériel de travail et la connexion sont soit présents, soit absents. Vous pouvez utiliser un hébergeur avec un « taux de fiabilité » de 50 % (selon son propre SLA) pendant des années sans rencontrer de problème, ou « tomber » une fois par mois pendant quelques jours chez des prestataires affichant 99,99 %.
Lorsque la panne se produit (et rappelez-vous, tout le monde finit par tomber un jour), le client est alors confronté à la machine interne d'entreprise appelée « support », et le contrat de service ainsi que le SLA font surface. Qu'est-ce que cela signifie :
- Il est fort probable que vous ne puissiez rien réclamer pendant les quatre premières heures d'arrêt, même si certains hébergeurs commencent à recalculer les tarifs (versement des compensations) dès le moment de la panne.
- Si le serveur est inaccessible pendant une période prolongée, il se peut que vous puissiez déposer une demande de recalcul des tarifs.
- Et cela à condition que le problème soit dû à la responsabilité du fournisseur.
- Si votre problème découle d'une tierce partie (sur l'acheminement), il semblerait que « personne n'est responsable » et quand le problème sera résolu dépend de votre chance.
Il est important de comprendre que vous n'avez jamais accès à l'équipe d'ingénierie, la plupart du temps vous êtes stoppé par le support de première ligne, qui échange avec vous pendant que les véritables ingénieurs essaient de régler la situation. Un scénario familier ?
Beaucoup espèrent ici sur le SLA, qui, semble-t-il, est censé vous protéger de telles situations. Mais, en réalité, les entreprises sortent rarement des limites de leurs propres documents ou savent retourner la situation pour minimiser leurs propres coûts. La priorité du SLA est d'endormir la vigilance et de convaincre que même en cas de situation imprévue, « tout ira bien ». Le second objectif du SLA est de discuter des points critiques principaux et de donner au fournisseur de services une marge de manœuvre, c'est-à-dire la possibilité de faire porter la faute sur quelque chose dont le fournisseur « n'est pas responsable ».
Pourtant, pour les grands clients, en réalité, les compensations dans le cadre du SLA ne comptent pas vraiment. « Compensation au titre du SLA » se traduirait par un remboursement dans le cadre du tarif proportionnel à l'arrêt de l'équipement, qui ne couvrira jamais même 1 % des pertes financières et réputationnelles potentielles. Dans ce cas, il est bien plus important pour le client que les pannes soient réparées dans les plus brefs délais que de se préoccuper d'un quelconque « recalcul tarifaire ».
« De nombreux centres de données à travers le monde » — cela soulève des inquiétudes.
La situation avec un grand nombre de centres de données chez le fournisseur de services est déplacée dans une catégorie distincte, car au-delà des problèmes évidents de communication décrits ci-dessus, d'autres problèmes moins évidents émergent. Par exemple, votre fournisseur de services n'a pas accès à « ses » centres de données.
Dans notre précédent article , dontes l'essence réside dans la revente des ressources d'autres sous sa propre enseigne. La grande majorité des hébergeurs modernes qui prétendent disposer de « leurs propres centres de données » dans de nombreuses régions sont des revendeurs en mode White Label. C'est-à-dire qu'ils n'ont physiquement aucun lien avec le centre de données conditionnel en Suisse, en Allemagne ou aux Pays-Bas.
Cela soulève des collusions très intéressantes. Votre SLA (Service Level Agreement) avec le fournisseur de services est toujours en vigueur, mais il est incapable d'influencer radicalement la situation en cas d'accident. Il est lui-même dépendant de son propre fournisseur – le centre de données, auprès duquel il a acheté les racks-capacités pour revente.
Ainsi, si vous attendez des formulations élégantes dans le contrat et le SLA sur la fiabilité et le service, mais aussi la capacité du fournisseur à résoudre rapidement les problèmes, il vaut mieux travailler directement avec le propriétaire des ressources. Cela implique en réalité une interaction directe avec le centre de données.
Pourquoi n'étudions-nous pas les options où plusieurs centres de données peuvent en fait appartenir à une seule entreprise ? Parce que ces entreprises sont très peu nombreuses. Un, deux, trois petits centres de données ou un grand — c'est tout à fait possible. Mais une dizaine de centres, dont la moitié est en Russie et l'autre en Europe — cela est presque impossible. Cela signifie donc qu'il y a beaucoup plus de revendeurs que l'on peut imaginer. Voici un simple exemple :
Évaluez le nombre de centres de données du service Google Cloud. En Europe, ils ne sont que six : à Londres, Amsterdam, Bruxelles, Helsinki, Francfort et Zurich. C'est-à-dire sur tous les principaux points stratégiques. Parce qu'un centre de données est coûteux, complexe et représente un très grand projet. Maintenant, rappelez-vous des entreprises d'hébergement venant de Moscou avec « une dizaine de centres de données à travers la Russie et l'Europe ».
Non, il y a bien sûr suffisamment de bons fournisseurs ayant des partenaires dans le cadre du programme White Label, et ils offrent des services de premier ordre. Ils permettent de louer des ressources à la fois dans l'UE et en Russie via une seule et même fenêtre de navigateur, acceptent les paiements en roubles au lieu de devises étrangères, etc. Mais en cas d'événements décrits dans le SLA, ils deviennent, tout comme vous, des otages de la situation.
Cela nous rappelle encore une fois que le SLA est inutile si vous n'avez pas une idée de la structure de l'organisation et des capacités du fournisseur.
Qu'en est-il finalement
La chute des serveurs est toujours un événement désagréable, et cela peut arriver à n'importe qui, n'importe où. La question est de savoir quel degré de contrôle vous souhaitez sur la situation. Actuellement, il n'y a pas beaucoup de fournisseurs directs de capacités sur le marché, et s'il s'agit de grands acteurs, ils possèdent, en quelque sorte, seulement un DC quelque part à Moscou parmi une dizaine à travers l'Europe, auxquels vous pouvez accéder.
Chaque client doit décider par lui-même : je choisis le confort immédiat ou je dépense du temps et des efforts à rechercher un centre de données à un endroit acceptable en Russie ou en Europe, où je pourrai placer mon équipement ou acheter des capacités. Dans le premier cas, des solutions standard disponibles sur le marché conviendront. Dans le second, il faudra se donner du mal.
Tout d'abord, il est nécessaire de déterminer si le vendeur de services est le propriétaire direct des capacités / du centre de données. De nombreux revendeurs selon le modèle White Label masquent de toutes leurs forces leur statut, et dans ce cas, il faut se référer à certains signes indirects. Par exemple, si «leurs DC européens» ont des noms et des logos spécifiques, différents de ceux de l'entreprise fournisseuse. Ou si le mot «partenaires» apparaît quelque part. Partenaires = White Label dans 95 % des cas.
Ensuite, il est nécessaire de se familiariser avec la structure de l'entreprise elle-même, et mieux encore, de voir l'équipement en personne. Parmi les centres de données, il n'est pas nouveau de faire des visites ou au minimum d’avoir des articles de visite sur leur propre site ou blog (nous en avons écrit, et ), où ils racontent leur centre de données avec des photos et des descriptions détaillées.
Avec de nombreux centres de données, vous pouvez convenir d'une visite personnelle au bureau et d'une mini-visite du DC lui-même. Là, vous pouvez évaluer le degré d'ordre, et peut-être réussir à parler à l'un des ingénieurs. Bien sûr, personne ne vous fera une visite de production si vous avez besoin d'un seul serveur à 300 RUB / mois, mais si vous avez besoin de capacités sérieuses, le service commercial peut tout à fait vous accueillir. Nous, par exemple, organisons ce genre de visites.
Dans tous les cas, il est important de faire preuve de bon sens et de se baser sur les besoins de l'entreprise. Par exemple, si une infrastructure distribuée est nécessaire (une partie des serveurs en Russie, l'autre en Europe), il sera plus simple et plus avantageux de faire appel à des hébergeurs ayant des partenariats avec des centres de données européens en mode White Label. En revanche, si toute votre infrastructure est concentrée à un seul endroit, c'est-à-dire dans un seul centre de données, il vaut la peine de prendre un certain temps pour chercher un fournisseur.
Car un SLA standard ne vous sera probablement pas d'une grande aide. En revanche, travailler avec le propriétaire des infrastructures, et non avec un intermédiaire, accélérera considérablement la résolution des problèmes éventuels.
Source : habr.com
