Qu'est-ce que la haute disponibilité ? SLA pour IaaS : de vraies garanties pour la haute disponibilité de l'infrastructure informatique virtuelle en tant que service.

Les services d'infrastructure informatique en tant que service (IaaS) sont de plus en plus populaires auprès des clientèle, et ils sont déjà utiliséset pour les applications critiques. Il est temps de comprendrece que garantissent les fournisseurs de ces services et quelle responsabilité ils assument en cas de ralentissement ou d'indisponibilité totale de l'infrastructure informatique virtuelle.

Après avoir interrogé les principaux fournisseurs de services d'infrastructure IaaS de niveau entreprise, nous avons analysé leurs offres. Parallèlement, le « niveau entreprise » signifie : la plateforme cloud est déployée dans un data center répondant aux exigences du Tier III (la présence d'un certificat de l'Uptime Institute n'est pasrequis) et offre un haut niveau de résilience grâce à des mécanismes de haute disponibilité (HA) et à la relocalisation des machines virtuelles en cas de sinistre.

DISPONIBILITÉ ET TEMPS DE RÉPONSE

Les principaux paramètres du service IaaS, qui sont généralement indiqués dans le SLA, sont le niveau de sa disponibilité, le temps de réponse aux divers incidents et la durée de leur résolution, ainsi que le schéma et les paramètres de compensation en cas d'indisponibilité.

Si vous décidez d'utiliser une infrastructure informatique virtuelle, vous pouvez compter en toute sécurité sur une disponibilité de 99,5 % et plus. Au moins aucun des fournisseurs que nous avons interrogés n'a cité un chiffre inférieur. De plus, les représentants de nombreuses entreprises ont souligné que la valeur indiquée dans leurs réponses (voir tableau 1) est typique et, à la demande du client, le niveau de disponibilité peut être augmenté à l'aide de divers moyens techniques.

En règle générale, les plates-formes IaaS de niveau entreprise sont hébergées dans des centres de données (internes ou externes) qui répondent au niveau de tolérance aux pannes de niveau III, connu pour avoir une disponibilité de 99,98 %. Les valeurs de disponibilité des infrastructures IaaS virtuelles indiquées par les fournisseurs ne dépassent pas la caractéristique correspondante du site physique, ce qui est tout à fait naturel.

L'exception est la disponibilité de 99,99 % fournie par Dataline en mode cluster métropolitain. Cette option est résistante aux catastrophes le cloud couvre deux centres de données de l'entreprise - pour plus d'informations sur le cluster métropolitain, consultez le document "Cloud résistant aux catastrophes à un prix" non nuageux "", publié dans le numéro d'octobre du "Journal of Network Solutions / LAN » pour 2013 ().

En principe, le fournisseur peut indiquer dans le SLA une disponibilité arbitrairement élevée, au moins 100 %, mais il risque alors de perdre plus que de gagner, car tout acheteur sensé exigera un régime d'indemnisation rigide pour le non-respect des conditions convenues à inclure. Dans le contrat. Bien qu'aucun système standard n'ait encore été développé - chaque fournisseur propose quelque chose qui lui est propre, l'acheteur doit donc évaluer la compensation proposée en tenant compte des pertes financières éventuelles en cas d'arrêt des services informatiques.

De nombreuses entreprises offrent un certain remboursement d'un paiement mensuel (en pourcentage) pour chaque heure d'indisponibilité de service supplémentaire (au-delà du SLA spécifié). Par exemple, avec le niveau de disponibilité spécifié dans le SLA de 99,95 % (temps d'inactivité ne dépassant pas 1 heure par mois), Inoventica est prêt à rembourser 2 % du paiement mensuel pour chaque heure supplémentaire de déconnexion du service. Cloud4Y dans la version standard compense 1% pour 1 heure d'arrêt (dans les calculs, coût total des services complets mois du calendrier, précédant celle-ci), mais pas plus de 50 % du coût de la prestation.

Un certain nombre de prestataires ont fourni des calculs détaillés sur la façon dont le montant de l'indemnisation varie en fonction du niveau de disponibilité (voir tableau 2). En cas de baisse significative de ce niveau, une indemnisation très substantielle est proposée. Par exemple, si la valeur est inférieure à 95%, "Onlanta" (GC "Lanit") permet une diminution du niveau de paiement pour le service jusqu'à 40%. Et la société « IT-Grad », si le niveau de disponibilité descend en dessous de 96,71 %, promet une indemnisation de 50 %. Il est clair que les prestataires considèrent qu'une telle détérioration de la qualité des services est peu probable.

« Nous avons introduit deux principes de compensation indépendants : en cas de violation des indicateurs cibles des paramètres de service et des indicateurs cibles pour le traitement des demandes », déclare Vitaly Mzokov, responsable des services cloud et des solutions d'infrastructure de Servionica (I-Teco Group of Companies). - La violation des indicateurs cibles des paramètres de service est compensée sur une échelle progressive. En fonction du niveau de disponibilité réel, l'indicateur de rémunération est calculé, exprimé en pourcentage du montant de la facture pour l'utilisation du service. L'indemnisation du non-respect des indicateurs cibles de traitement des demandes est calculée en fonction du temps d'attente du client avec une précision à la minute près. »

Selon la pratique adoptée par Servionica, les types de demandes des clients, ainsi que les objectifs généraux de temps de réponse maximum aux demandes et de temps maximum de résolution d'un problème, sont décrits dans le règlement d'interaction de service. Et dans le SLA lui-même, ces indicateurs sont spécifiés pour un service spécifique.

« Selon le contrat, le client peut recevoir plusieurs services de notre part. C'est pourquoi la réglementation décrit indicateurs généraux avec une note : « Les objectifs spécifiés dans le SLA pour un service spécifique chevauchent les indicateurs spécifiés dans les règlements. » Ceci est fait pour que, si nécessaire, il soit possible de spécifier (étendre ou diminuer) le temps de réaction et le temps de solution, - explique Vitaly Mzokov. - Nous sommes tenus de répondre aux demandes de toute nature dans un délai de 15 minutes. Le délai maximum de résolution, selon le type et la priorité de la demande, va de 1 heure (pour les incidents de priorité n°1) à 48 heures (pour les demandes pour lesquelles une étude complète de la demande d'information du client est requise - par exemple, la fourniture d'informations sur les tarifs et autres services, diverses clarifications et instructions).

Le temps de réponse à une application dépend généralement de sa priorité. Par exemple, les niveaux de priorité des pratiques de Linxdatacenter sont :

• Critique - le service est complètement indisponible, il est nécessaire de prendre des mesures urgentes pour le restaurer, le temps de réaction est de 15 minutes, le temps de récupération ne dépasse pas 4 heures;
• Élevé - le service est partiellement indisponible, le temps de réaction peut aller jusqu'à 1 heure, la priorité augmentée ;
• Normal - clarification sur les paramètres du service, questions non urgentes actuelles, temps de réaction jusqu'à 1 heure, 24 heures sont données pour préparer la réponse.

Le tableau 3 montre un autre exemple - la catégorisation des requêtes utilisées par Cloud4Y ; temps de réaction - pas plus de 30 minutes.

Ils essaient de travailler rapidement chez T-Systems. Selon Vsevolod Egupov, directeur des ventes de la division ICT de T-Systems RUS, les spécialistes de cette société « répondent dans 80 % des cas dans les 30 secondes » (!). Mais, comme la plupart de nos répondants, il a noté que le temps de réaction dépend de la criticité de la situation.

OUTILS DE SUIVI

Il ne suffit pas d'indiquer dans le SLA un niveau d'accessibilité attractif et des régimes de rémunération rigides, il faut également fournir au client un outil efficace contrôler. Et c'est là que les approches des fournisseurs diffèrent considérablement.

Se référant à la pratique de la société Servionika, Vitaly Mzokov note que les clients sont plus intéressés à recevoir des rapports transparents et précis de la part de l'opérateur qu'à maîtriser certains outils spéciaux d'autosurveillance. En règle générale, Servionica fournit des rapports mensuels sur un ensemble de paramètres convenus, mais, à la demande du client, le contrat peut prévoir des rapports plus fréquents.

De nombreuses entreprises, par défaut, fournissent des rapports de santé de service une fois par mois, mais elles peuvent aussi le faire plus souvent - à la demande des clients. Un exemple de rapport proposé par Onlanta est illustré à la figure 1. Selon Mikhail Lyapin, responsable de son activité cloud, Onlanta est la seule entreprise en Russie qui fournit aux clients un rapport sur la disponibilité du cloud avec ce niveau de détail. Selon lui, la plupart des fournisseurs de services se contentent de statistiques sur le niveau de disponibilité des machines virtuelles.

Un certain nombre d'entreprises proposent à leurs clients une console en ligne en libre-service. Selon Ruslan Zaedinov, directeur général adjoint, responsable du centre de données et du cloud computing chez Krok, chaque consommateur du service IaaS a accès à une telle console avec une capacité intégrée de surveillance en ligne du fonctionnement de certains composants. Par exemple, dans le cas des machines virtuelles, les informaticiens du client peuvent surveiller combien le processeur est chargé, comment fonctionnent les E/S, combien de mémoire est occupée, etc. Ces données sont disponibles en temps réel, ainsi que - à la demande - sous forme de statistiques pour toute période.

AI-JE BESOIN DE GARANTIR LES PERFORMANCES

Il est évident qu'avec une augmentation de la charge sur la plateforme IaaS du fournisseur, la dégradation du niveau de performance de la machine virtuelle est possible. Les fournisseurs de services s'engagent à empêcher que cela ne se produise. Toutes les entreprises sont d'accord sur ce point. Cependant, certains incluent des mesures de performance dans le SLA, tandis que d'autres considèrent qu'une telle mesure n'est pas nécessaire.

Voici ce qu'en dit Vitaly Slizen, membre du conseil d'administration d'Inoventica : « Nous n'observons pas de dégradation [de la productivité] même avec une augmentation de la charge, puisque nous développons et modernisons à temps les capacités des centres de données. Séparément dans le SLA, ces paramètres (VM et performances de stockage) ne sont pas reflétés, car leur respect est notre responsabilité première, quelles que soient les demandes des clients. » Les spécialistes d'Inoventica surveillent en permanence tous les principaux paramètres des infrastructures louées, ce qui leur permet de recevoir rapidement des informations sur problèmes potentiels et les prévoir en temps opportun.

Igor Drozdov, directeur de soutien technique Sales Linxdatacenter : « Notre société fournit des ressources informatiques garanties à utiliser. Ils sont réservés dans le cloud et augmentent à mesure que le nombre de clients augmente, de sorte que les performances des machines virtuelles et des systèmes de stockage restent à un niveau constamment élevé. De plus, nous fournissons des mises à niveau de serveur en temps opportun et une surveillance des performances avec des produits VMware dédiés. »

Orange Business Services fait également partie des fournisseurs de services qui ne régulent pas les paramètres de performance dans le SLA standard. Parallèlement, selon Dmitry Dorodnykh, responsable du développement des communications unifiées et des produits informatiques chez Orange Business Services en Russie et dans la CEI, « si un client exige que certaines ressources informatiques soient garanties pour ses machines virtuelles, nous utilisons moyens standards des plates-formes de virtualisation modernes qui permettent de déplacer des machines virtuelles vers d'autres serveurs en cas de conflit de ressources. »

Vsevolod Egupov estime que l'ajout de caractéristiques de performance au SLA "n'a pas de sens, car la dégradation affecte le niveau de disponibilité du service réglementé par l'accord". Chez T-Systems, les performances des machines virtuelles et des systèmes de stockage sont contrôlées par le département de gestion des capacités, ses spécialistes sont chargés d'empêcher sa dégradation.

De nombreuses entreprises pensent également qu'il est conseillé d'ajouter des caractéristiques de performance au SLA. Le point le plus étroit Dans un environnement informatique virtualisé, les performances de stockage sont considérées par de nombreux experts comme des performances de stockage, c'est pourquoi la plupart des fournisseurs de stockage accordent une attention particulière aux caractéristiques de stockage telles que les opérations d'entrée/sortie par seconde (IOPS).et le temps d'accès au disque (latence).

Dataline fournit des métriques de performances pour le stockage et les machines virtuelles dans chaque SLA (voir Tableau 4). Dans le même temps, selon Dmitry Tishin, chef du département de développement des services de cette société, "en fonction des exigences imposées au paysage système par le client, les métriques peuvent être modifiées". Les valeurs IOPS sont mesurées par le système de surveillance NetApp DFM et le temps d'accès au disque est moyens réguliers Logiciel de virtualisation (vCenter). En cas de problème avec une machine virtuelle, l'astreinte et les ingénieurs de l'équipe de virtualisation sont alertés. De plus, Dataline assure la surveillance de divers paramètres au niveau du système d'exploitation et des services qui y sont exécutés. Si le client utilise les services d'administration de l'OS et des services de l'entreprise, cette surveillance est effectuée par défaut.

Pour éviter la dégradation des performances des machines virtuelles, les spécialistes Dataline appliquent un ensemble de mesures. Ainsi, pour le cluster, le mécanisme Distributed Resource Scheduler (DRS) est utilisé, qui surveille la charge des serveurs physiques en fonction des principaux paramètres - si une certaine charge sur le serveur est atteinte, certaines des machines virtuelles sont automatiquement déplacées vers une autre . La redondance des serveurs est maintenue dans le cluster afin que la charge sur l'ensemble du cluster ne dépasse pas 70 %. Dans le cadre des contrats de services conclus avec les fournisseurs d'équipements, les capacités de ressources des clusters peuvent être augmentées selon le calendrier.

Safedata régule également les caractéristiques de performances telles que les IOPS et les MIPS dans le SLA. "Nous ne pouvons pas réduire les performances en dessous des valeurs spécifiées dans le SLA", explique Anton Antonov, responsable des ventes chez Safedata. « Si une dégradation du service est observée avec une charge croissante sur les serveurs physiques, des hôtes EXSi de sauvegarde supplémentaires sont mis en service. »

Les caractéristiques de performance du système de disque de stockage réglementé dans le SLA Cloud4Y sont présentées dans le tableau 5. Selon Evgeny Bessonov, chef du département marketing Cloud4Y, en cas de violation des indicateurs de performance garantis de CPU, HDD, RAM, une indemnité est prévue, qui est négociée séparément ou payée selon des conditions standard : 1% du coût mensuel pour 1 heure.

« Nous garantissons les performances des machines virtuelles à la limite inférieure, sans les limiter par le haut », explique Ruslan Zaedinov. « Ainsi, si le serveur sur lequel se trouve la machine virtuelle dispose de ressources informatiques gratuites supérieures à celles garanties, elles seront disponibles pour le client. » En ce qui concerne les systèmes de stockage, à l'heure actuelle, tous les clients Croc utilisent un canal de communication commun avec les systèmes de stockage. Pendant longtemps, cela n'a pas été un problème, mais maintenant, afin de répondre aux besoins croissants des clients, l'entreprise migre le stockage cloud des disques Fibre Channel et SATA vers des disques flash avec un accès direct depuis des machines virtuelles sur Infiniband réseau. En parallèle, un logiciel est mis en œuvre pour garantir un débit garanti du système de stockage de données dans le cloud. Les modifications correspondantes au SLA seront apportées cet automne.

Comme convenu avec le client, Servionica fixe des indicateurs de performance des composants individuels de la plate-forme cloud dans le SLA de chaque projet. De plus, l'accord précise comment mesurer ces indicateurs et la fréquence des mesures. "Tout opérateur peut écrire" garanti 100 500 OP pour 1 Go d'espace disque ", mais tout le monde n'est pas en mesure de prouver que ce critère est rempli. Nous sommes pour la relation la plus transparente entre l'opérateur de la plateforme cloud et son consommateur », souligne Vitaly Mzokov. Les performances des machines virtuelles et des systèmes de stockage sont déterminées dans le SLA Servionica par les IOPS et la latence.

Comme l'a dit Maxim Zakharenko, directeur général fournisseur de services "Oblakoteka", dans les contrats qu'ils concluent, les indicateurs de performance de pointe sont réglementés de manière à ce que la charge de l'entrée-sortie et de la bande passante du réseau ne dépasse pas 80%. La surveillance est effectuée à l'aide du système Microsoft SCOM. Il note que pour différents systèmes différents indicateurs sont importants : pour les sites Web - temps de réponse, pour le placement des infrastructures informatiques - indicateurs de pic de processeur, de mémoire, de réseau virtuel, etc. "Adieu honnête").

SLA CROISÉ

Quelle que soit la fiabilité de la plate-forme IaaS elle-même, située dans un centre de données tolérant aux pannes, les canaux d'accès à cette plate-forme peuvent devenir un goulot d'étranglement pour le client. La bonne nouvelle est que bon nombre des fournisseurs que nous avons interrogés ont des SLA de bout en bout qui couvrent à la fois le service IaaS lui-même et les canaux d'accès. De plus, selon eux, à bonne organisation et la redondance des canaux, le niveau de disponibilité de la communication n'est pas inférieur à celui de la plate-forme SLA, et donc cette caractéristique importante ne diminue pas dans les SLA de bout en bout.

Cependant, comme le note Vsevolod Egupov, la réduction ou le maintien du niveau de disponibilité dépend de la manière dont les canaux de communication sont organisés - si le canal est réservé, la disponibilité ne se détériore pas. Sinon, le niveau de disponibilité dans le SLA de bout en bout est réduit au niveau de disponibilité du canal. T-Systems RUS possède son propre réseau de centres de données répartis dans le monde entier. Le service aux clients russes s'effectue principalement à partir de centres de données situés en Allemagne et en Autriche. La société a signé un SLA avec Rostelecom, Beeline et coopère avec d'autres opérateurs de télécommunications.

Les fournisseurs de services IaaS qui sont également des opérateurs profitent de cet avantage. Ainsi, en tant qu'opérateur télécom international, Orange Business Services pratique la conclusion de SLA de bout en bout couvrant l'IaaS et les services télécoms. Le niveau de disponibilité dans un tel SLA est de 99,95 %. Mais, comme l'explique Dmitry Dorodnykh, cette caractéristique dépend de la situation géographique du client - par exemple, dans la région centrale, ce niveau est plus élevé qu'au-delà de l'Oural et en Sibérie. Le dernier kilomètre peut avoir ses propres paramètres SLA. Les schémas et mécanismes de contrôle des SLA sur les canaux de communication étant déjà élaborés depuis des décennies, la question de la surveillance n'est donc pas un problème pour Orange Business Services.

Comme le note Vitaly Slizen, Inoventica dispose de ses propres canaux de communication backbone et d'un réseau de data centers répartis géographiquement, ce qui permet de mettre en place des géoclusters. Cela vous permet de maintenir les performances des données et du service même en cas de destruction physique de l'un des centres de données. Selon lui, Inoventica est « la seule entreprise sur marché russe fournir la chaîne complète de services "Data Center - Channel - Service - Client (AWS)" conformément au SLA, qui est le minimum pourdélai d'aller-retour inférieur à 10 ms et perte de paquets presque nulle. " Actuellement, la solution complète Inoventica est disponible pour les clients dans cinq districts fédéraux de la Fédération de Russie.

Les fournisseurs de services IaaS non-opérateurs coopèrent activement avec les opérateurs. Ainsi, Servionika a formé un SLA pour travailler avec les opérateurs télécoms desservant son centre de données (qui compte plus de 10 grands fournisseurs télécoms). La société traduit les termes de ces SLA dans des contrats avec les clients qui utilisent des services de communication. Et le contrôle du respect du SLA est assuré par les services techniques du centre de données TrustInfo. « Nous indiquons dans nos contrats les mêmes paramètres SLA que ceux des opérateurs, c'est-à-dire que nous assumons la responsabilité de la qualité de leur travail et de la fourniture ininterrompue de canaux de communication », note Vitaly Mzokov.

Pour fournir aux clients des canaux de communication, Dataline utilise les services d'opérateurs de télécommunications dans le cadre d'un schéma de sous-traitance. Avec ce schéma, l'entreprise contrôle la qualité dans le cadre de son contrat avec l'opérateur, tandis que le client bénéficie d'un service complet de sa part et ne traite qu'avec un seul entrepreneur. Le niveau d'accessibilité est service complet ne diminue pas. Dataline possède son propre réseau de transmission de données à Moscou, où les caractéristiques suivantes sont garanties : la part de paquets perdus ne dépasse pas 0,2%, le délai moyen du réseau ne dépasse pas 5 ms.

Selon Ruslan Zaedinov, Krok utilise des canaux larges, dont la bande passante est largement suffisante pour tous les clients du cloud. Des garanties techniquement valables sont fournies par la redondance inter-canaux entre les différents centres de données Krok utilisant son propre anneau optique. Pour les organisations pour lesquelles une bande passante fixe d'un canal de communication est critique, l'entreprise met en œuvre une connexion individuelle au cloud via des canaux séparés avec une garantie débit ou même des optiques "sombres". Une telle connexion est le plus souvent équipée d'outils de chiffrement individuels, y compris certifiés.

Ainsi, les services IaaS sont proposés en Russie par un nombre assez important d'entreprises, et selon des règles assez compréhensibles et documentées (en SLA). L'industrie doit encore se mettre d'accord sur la question de savoir si les caractéristiques de performance des infrastructures informatiques virtuelles doivent être réglementées dans les SLA, mais les indicateurs de disponibilité garantie semblent être tout à fait acceptables, même pour les clients d'entreprise les plus exigeants. De plus, les fournisseurs comprennent les besoins des clients en termes de SLA de bout en bout et s'efforcent de les améliorer.

Alexandre Barskov- Rédacteur en chef du "Journal of Network Solutions / LAN". Vous pouvez le contacter au :

, auteur Stewart Rens(Stuart Rance).

La disponibilité des services informatiques est d'une grande importance. Lorsque les services dont les clients ont besoin ne sont pas disponibles, ils seront insatisfaits. Pourquoi un client devrait-il payer pour un service qui n'existe pas dans la réalité alors qu'il en a besoin ? C'est pourquoi une métrique de disponibilité de service cohérente est souvent incluse dans un KPI.

Le personnel informatique se donne beaucoup de mal pour s'assurer que l'objectif déclaré est atteint et pour montrer les chiffres dans les rapports aux clients pour le prouver. Les entreprises informatiques utilisent généralement des pourcentages pour cela, par exemple 99,999 %. Malheureusement, cela signifie souvent qu'ils se concentrent uniquement sur le pourcentage et perdent de vue leur véritable objectif d'être utile au client.

Problème de pourcentage de disponibilité

L'un des moyens les plus simples de calculer la disponibilité est basé sur deux parties. Vous acceptez les intervalles de temps pendant lesquels le service doit être disponible en période de déclaration... Il s'agit du temps de service convenu (AST). Vous mesurez le temps d'arrêt (DT) pendant cette période. Soustrayez le temps d'arrêt de la disponibilité de service convenue et convertissez-le en pourcentage.

Si l'AST est de 100 heures et que le temps d'arrêt est de 2 heures, la disponibilité serait la suivante :

Le problème est que, bien que ce calcul soit assez simple, tout comme la collecte de données pour celui-ci, en fait, il n'est pas tout à fait clair quel indicateur reflète exactement le chiffre que vous avez reçu à la suite du calcul. J'en parlerai un peu plus tard.

Pire, du point de vue du client, vous pouvez communiquer que vous avez atteint les objectifs convenus tout en le laissant complètement insatisfait.

Un rapport de disponibilité significatif doit être basé sur des dimensions qui décrivent des éléments d'intérêt pour le client, tels que la capacité d'envoyer et de recevoir. e-mails ou retirer de l'argent aux guichets automatiques, et le pourcentage global ne semble pas pouvoir le faire.

Définir des cibles d'accessibilité

Si vous souhaitez mesurer, documenter et signaler la disponibilité d'une manière qui profite à votre organisation et à vos clients, vous devez faire deux choses. Tout d'abord, définissez le contexte et renforcez le sens de « l'accessibilité » pour vous et vos clients. Pour ce faire, vous devez leur parler.

Deuxièmement, vous devez réfléchir soigneusement à un certain nombre de questions pratiques : ce que vous mesurerez, comment vous collecterez les données, comment vous les documenterez et comment vous rapporterez vos résultats.

Communication avec les clients

Avant d'agir, vous devez comprendre ce qui est important pour vos clients et quel impact la perte de disponibilité a sur eux. Cela vous permet de définir des objectifs réalistes qui prennent en compte les contraintes de technologie, de budget et de personnel.

Mais que dire exactement à vos clients ? L'impact des temps d'arrêt peut être un excellent point de départ pour une conversation. Vous trouverez ci-dessous cinq questions à poser :

1. Quelles fonctions commerciales sont essentielles et prioritaires pour la protection contre les temps d'arrêt ?
2. Comment les temps d'arrêt affectent-ils l'entreprise?
3. Comment la fréquence des temps d'arrêt affecte-t-elle l'entreprise ?
4. Quel est l'impact des temps d'arrêt sur la performance organisationnelle ?
5. Comment les clients de l'organisation perçoivent-ils ces temps d'arrêt forcés ?

Fonctions critiques pour l'entreprise

La plupart des services informatiques prennent en charge plusieurs processus métier, dont certains sont critiques et d'autres moins importants. Par exemple, un guichet automatique peut prendre en charge la distribution d'espèces et l'impression de chèques. La possibilité de distribuer des espèces est essentielle, tandis que l'impossibilité d'imprimer un chèque a beaucoup moins d'impact.

Vous devez parler aux clients et déterminer l'importance des différentes fonctions pour l'entreprise. Vous pouvez créer une feuille de calcul qui met en évidence les implications commerciales des temps d'arrêt de chacune de ces fonctions. Exemple:

Tableau 1 - L'importance des services en pourcentage

NB: Les nombres ne doivent pas totaliser 100 %

Comme vous pouvez le voir dans ce tableau, ce service n'a aucune importance s'il n'y a aucun moyen d'envoyer et de recevoir des e-mails, et sa valeur est réduite de moitié par rapport au niveau normal si les dossiers publics ne peuvent pas être lus. Cela indique au service informatique de se concentrer sur la qualité du service postal.

Durée et fréquence des temps d'arrêt

Vous devez déterminer comment la fréquence et la durée des temps d'arrêt affectent l'activité du client.

J'ai déjà mentionné que le pourcentage de disponibilité peut ne pas être suffisant. Lorsqu'un service censé être disponible pendant 100 heures a une disponibilité de 98 %, cela indique qu'il y a eu deux heures d'indisponibilité. Mais cela peut signifier un incident de deux heures ou plusieurs incidents plus courts. L'impact relatif d'un seul incident soutenu ou d'une série d'incidents de courte durée variera en fonction de la nature de l'entreprise et des processus commerciaux.

Par exemple, une facturation qui dure deux jours et qui doit être redémarrée après toute panne sera gravement affectée par chaque courte panne, mais une panne forcée qui dure longtemps peut avoir beaucoup moins d'importance. D'un autre côté, une panne d'une minute peut ne pas affecter le fonctionnement de la boutique en ligne, mais après deux heures, elle peut entraîner une perte importante de clients. Une fois que vous avez compris l'impact commercial probable des temps d'arrêt, vous pouvez créer une infrastructure, des applications et des processus beaucoup plus efficaces qui aident vraiment votre client.

Voici un exemple de la façon dont la disponibilité peut être mesurée et documentée pour refléter le fait que l'impact des temps d'arrêt varie :

Tableau 2 - Durée de déclenchement et fréquence maximale

Si vous utilisez une feuille de calcul comme celle-ci lorsque vous discutez des taux et de la durée des temps d'arrêt avec les clients, ces chiffres seront probablement beaucoup plus utiles que le pourcentage de disponibilité, et ils le seront certainement. plus grande valeur pour vos clients.

Temps d'arrêt et productivité

J'ai mentionné que le pourcentage de disponibilité n'est pas très utile pour communiquer avec les clients sur la fréquence et la durée des temps d'arrêt. D'un autre côté, lorsque vous discutez de l'impact des temps d'arrêt sur les performances, les pourcentages peuvent s'avérer très utiles.

La plupart des incidents n'entraînent pas une perte totale de service pour tous les utilisateurs. Certains utilisateurs peuvent ne pas être affectés, tandis que d'autres sont complètement désactivés. Peut-être qu'il n'y a qu'un seul utilisateur avec un PC défectueux qui ne peut accéder à aucun des services. Vous pouvez même classer cela comme une perte de service à 100 %, mais ce serait un objectif totalement inaccessible pour le service informatique et ne peut pas être une mesure équitable de la disponibilité.

D'un autre côté, vous pouvez dire qu'un service est disponible alors que quelqu'un peut encore y accéder. Cependant, il ne faut pas beaucoup d'imagination pour comprendre comment les clients se sentiront si un service est répertorié comme abordable alors que de nombreuses personnes ne peuvent tout simplement pas l'utiliser.

Une façon de déterminer l'impact est de calculer le pourcentage de minutes d'utilisateur perdues. Pour faire ça:

• Calculez les Minutes utilisateur potentielles. Cette le total utilisateurs qui travaillent par unité de temps. Par exemple, si vous avez 10 employés travaillant pendant 8 heures, alors PotentielUserMinutes est 10 x 8 x 60 = 4800
• Calculez UserOutageMinutes. Il s'agit du nombre total d'utilisateurs qui n'ont pas pu travailler multiplié par le temps pendant lequel ils n'ont pas pu travailler. Par exemple, si un incident a empêché 5 employés de travailler pendant 10 minutes, alors UserOutageMinutes est de 50.
• Calculez le pourcentage de disponibilité en utilisant une formule très similaire à celle que nous avons vue plus tôt

Dans l'exemple donné, nous avons la disponibilité suivante :

Vous pouvez utiliser cette même technique pour calculer l'impact de la disponibilité de la téléphonie IP perdue dans un centre d'appels en termes de PotentialAgentPhoneMinutes et LostAgentPhoneMinutes ; pour les applications impliquant des transactions ou de la fabrication, vous pouvez utiliser une approche similaire pour quantifier l'impact commercial d'un incident. Vous comparez le nombre de transactions qui auraient été attendues sans temps d'arrêt par rapport au nombre de transactions réelles ou à la quantité de production attendue par rapport à la production réelle.

Mesure de la disponibilité et reporting

Une fois que vous avez convenu et documenté les objectifs d'accessibilité, vous devez réfléchir aux aspects pratiques de la façon dont vous pouvez mesurer et signaler l'accessibilité. Par exemple:

• Que vas-tu mesurer ?
• Comment allez-vous collecter les données ?
• Comment documenterez-vous et rapporterez-vous vos conclusions ?

Ce qui est mesuréJe suisêtre

Il est très important de mesurer et de signaler la disponibilité dans les mêmes termes qui définissent les objectifs convenus par le client et qui sont basés sur une compréhension commune de ce qu'est réellement l'accessibilité du client. Les objectifs doivent avoir du sens pour lui et garantir que les efforts informatiques sont concentrés sur l'assistance à son entreprise.

En règle générale, ces objectifs font partie d'un accord de niveau de service (SLA) entre le service informatique et le client, mais vous devez faire attention à ce que les chiffres du SLA ne deviennent pas votre objectif. Votre véritable objectif est de fournir des services qui répondent aux attentes de vos clients.

Comment collecter des données

Il existe de nombreuses façons de collecter des données sur la disponibilité des services informatiques. Certains d'entre eux sont simples, mais pas très précis, certains sont assez chers. Vous pouvez utiliser une seule approche ou combiner plusieurs d'entre elles pour créer vos propres rapports.

Collecte de données en support technique

L'assistance technique est une façon de collecter les données de disponibilité. En règle générale, le personnel de service détermine l'impact et la durée de chaque incident sur l'entreprise, car cela fait partie de la gestion des incidents. Ces données peuvent être utilisées pour déterminer la durée des incidents et le nombre d'utilisateurs touchés.

Cette approche est généralement assez peu coûteuse. Cependant, cela peut conduire à des litiges sur l'exactitude des données de disponibilité.

Mesure de la disponibilité de l'infrastructure et des applications

Cette approche comprend l'outillage de tous les composants nécessaires pour fournir un service et le calcul de la disponibilité sur la base d'une compréhension de la contribution de chaque composant.

Cela peut être très efficace, mais il peut manquer de petits problèmes. Par exemple, une corruption mineure de la base de données peut empêcher certains utilisateurs d'effectuer certains types de transactions. Cette méthode peut également manquer l'impact des composants partagés, par exemple, un de mes clients avait une messagerie régulière qui ne fonctionnait pas en raison de serveurs DHCP peu fiables à son siège, mais le service informatique n'a pas enregistré cela comme un temps d'arrêt de la messagerie.

Clients fictifs

Certaines entreprises utilisent des clients fictifs pour envoyer des transactions connues à partir de points spécifiques sur le réseau afin de vérifier la disponibilité.

En fait, il s'agit d'une mesure de la disponibilité de bout en bout. Selon la taille et la complexité du réseau, cette approche peut être coûteuse à mettre en œuvre et ne signale la disponibilité que de clients fictifs spécifiques. Cela signifie que de petits problèmes peuvent être manqués, par exemple, si un incident a provoqué le dysfonctionnement d'un certain navigateur Web alors que le faux client utilise un navigateur différent.

Les outils qui prennent en charge cette collecte de données signalent également fréquemment les performances et la disponibilité du service, ce qui peut être un complément utile.

Raffinement des applications

Certaines entreprises ajoutent du code personnalisé à leurs applications pour surveiller la disponibilité de bout en bout. Cela permettra de mesurer réellement la disponibilité de bout en bout des services, à condition que ce soit l'objectif au moment du développement de l'application. En règle générale, cette révision inclut du code à la fois dans l'application cliente et côté serveur.

S'il est bien mis en œuvre, il peut non seulement collecter des données de disponibilité, mais peut également aider à identifier exactement où la panne s'est produite, ce qui peut aider à augmenter la disponibilité en réduisant le temps de résolution des incidents.

Comment documenter et rapporter vos conclusions

Une fois que vous avez collecté vos données de disponibilité, vous devez réfléchir à la manière de communiquer les résultats à vos clients.

Planifier les temps d'arrêt

Un aspect de la mesure de la disponibilité et des rapports qui est souvent négligé est le temps d'arrêt. Si vous ne tenez pas compte des temps d'arrêt planifiés lors de la conception de vos rapports de disponibilité, vous courez le risque d'inclure des métriques qui ne sont pas vraies.

Il existe plusieurs façons de s'assurer que les temps d'arrêt planifiés ne gonflent pas les statistiques. L'une consiste à avoir des temps d'arrêt programmés pour une durée spécifique qui n'est pas incluse dans le calcul de la disponibilité. Une autre consiste à planifier un temps d'arrêt programmé. Par exemple, certaines organisations peuvent ne pas envisager les temps d'arrêt futurs un mois à l'avance.

Indépendamment de ce que vous décidez de faire, il est important que votre SLA définisse clairement comment les temps d'arrêt planifiés seront pris en compte.

Accord sur la période de rapport

Plus tôt, j'ai parlé des limitations que cache le pourcentage de disponibilité. Néanmoins, il est utilisé et continue d'être largement utilisé. Par conséquent, il est important de comprendre que vous devez spécifier la période pendant laquelle les calculs sont effectués et les rapports sont fournis, car cela peut être critique pour les chiffres qui figureront dans vos rapports.

Par exemple, considérons une société informatique qui a accepté un service 24 × 7 et une disponibilité de 99%. Supposons qu'il y ait une pause de huit heures :

• si nous signalons la disponibilité sur une base hebdomadaire, alors l'AST (Agreed Service Time) est de 24 x 7 heures = 168 heures
• AST mensuel (24 x 365) / 12 = 730 heures
• AST trimestriel (24 x 365) / 4 = 2190 heures

Mettre ces nombres dans l'équation d'accessibilité donne :

• Disponibilité hebdomadaire = 100 % x (168-8) / 168 = 95,2 %.
• Disponibilité mensuelle = 100 % x (730 - 8) / 730 = 98,9 %
• Disponibilité trimestrielle = 100 % x (2190-8) / 2190 = 99,6 %

Chacun est un indicateur valide de la disponibilité du service, mais un seul indique que l'objectif a été atteint.

En garde à vue

Presque toutes les entreprises informatiques avec lesquelles j'ai travaillé mesurent et rendent compte de la disponibilité de leurs services. Des services informatiques vraiment efficaces travaillent avec leurs clients pour optimiser propres investissements et offrent un excellent niveau de disponibilité. Malheureusement, de nombreuses sociétés informatiques se concentrent sur les chiffres SLA et ne parviennent pas à répondre aux besoins de leurs clients, même si elles finissent par afficher des chiffres cohérents dans les rapports.

Il s'agit d'un long article, voici les points clés qui y sont traités :

• Vous n'avez pas besoin de dire au client que vous avez fourni une disponibilité de 98 %, à moins que vous ne compreniez l'impact d'un temps d'arrêt de 2 %.
• Parlez à vos clients et assurez-vous de comprendre l'impact de tout temps d'arrêt sur eux et sur les clients finaux
• Réfléchissez aux moyens de protéger les processus métier critiques de vos clients
• Trouvez des moyens de mesurer la fréquence et la durée des temps d'arrêt, ainsi que l'impact des temps d'arrêt sur les performances qui répondent aux besoins de vos clients
• Acceptez, documentez et rapportez les métriques de disponibilité d'une manière qui a du sens pour vos clients et aide à planifier
• Utilisez les outils appropriés pour évaluer correctement la disponibilité et faire rapport.

Que pourriez-vous ajouter à mes conseils ? S'il vous plaît écrivez dans les commentaires.

« Accessibilité », « trois neuf après la virgule » : ces termes sont souvent utilisés lorsqu'on parle de nouvelles solutions informatiques. Les architectes informatiques proposent un projet au client nouveau système d'autant plus qu'il a une très haute disponibilité. Le contrat a été conclu, le système a été construit, les certificats de mise en service du complexe ont été signés, l'exploitation commence... C'est au stade de l'exploitation que l'on peut vérifier la « qualité » du système créé, et c'est alors que la déception peut venir. Qu'est-ce qui se cache derrière les « neuf » magiques ? Quelles sont les vraies promesses au stade de la conception ? Et qui est responsable de la disponibilité ?

Accessibilité : une introduction au sujet

La meilleure façon de comprendre ce qu'est l'accessibilité est de comprendre pourquoi elle est nécessaire. La disponibilité est une caractéristique de ce que l'entreprise attend du service informatique. Malheureusement, certains représentants d'entreprises, interrogés sur la disponibilité souhaitée des services informatiques, répondent quelque chose comme ceci : « Je veux que tout fonctionne toujours. Dans ce cas, il appartient au responsable informatique de rédiger les termes de référence du service, notamment en déterminant les paramètres de disponibilité. Ainsi, la disponibilité est une dimension d'un service informatique que l'entreprise consomme et que le service informatique fournit. La formule de calcul de la disponibilité est la suivante :

Disponibilité = (AST - DT) / AST × 100 = Disponibilité du service ou des composants (%)

où
AST (temps de service convenu)- le délai convenu pour la fourniture du service ;
DT (temps d'arrêt réel pendant le temps de service convenu)- la durée effective d'indisponibilité du service pendant la durée convenue de sa fourniture.

Les spécificités du calcul de la disponibilité sont plus faciles à comprendre avec un exemple précis. Essayons de déterminer la disponibilité du service informatique "boutique en ligne" pour la société AAA située à Moscou, qui vend des livres. Dans le même temps, les livres et leur livraison dans n'importe quelle ville peuvent être payés, par exemple avec une carte de crédit. Évidemment, les commandes d'expédition ne seront traitées que les jours de semaine de 9h à 18h.

Mais quel sera l'AST - le délai de prestation de service convenu ? Pour répondre à cette question, vous devez considérer que les gens peuvent passer des commandes dans heures non travaillées, et assurez-vous de prendre en compte le fait qu'il y a 11 fuseaux horaires en Russie. Par conséquent, le service doit être fourni 24 heures sur 24, 7 jours sur 7.

Vous devez maintenant faire face à DT - le moment où le service peut être indisponible. Ici, on ne peut pas se passer de négociations avec les entreprises. Il est possible que quatre heures d'indisponibilité de service une fois par mois soient un choix adéquat pour cet exemple. Cependant, une nuance doit être prise en compte - la période de temps pendant laquelle le paramètre DT est évalué, c'est-à-dire le temps réel de prestation de service convenu (AST). Le choix de la période AST est une affaire privée des contractants : entreprise et service informatique. Il est préférable de prendre une semaine ou plusieurs semaines comme telle période, car un mois ou une année ne sont pas des valeurs constantes (elles incluent un nombre de jours différent). Cependant, vous devez faire attention à la psychologie : des périodes plus courtes peuvent être perçues négativement par l'entreprise. Dans notre exemple, la même valeur de disponibilité correspond à environ une heure d'indisponibilité par semaine. Cependant, les entreprises pourraient ne pas aimer le fait que la boutique en ligne ne soit pas disponible pendant une heure chaque semaine, bien qu'elles puissent accepter quatre heures d'arrêt par mois. En revanche, il est parfois impossible de faire fonctionner un système informatique sans l'arrêter quelques heures pour une maintenance de routine. Ces temps d'arrêt planifiés doivent également être pris en compte lors du choix d'un DT, ce qui, à son tour, peut conduire à une révision du paramètre AST.

Sur la base de ce qui précède, nous choisissons 4 heures d'indisponibilité du service une fois toutes les quatre semaines. C'est-à-dire AST = 4 semaines, DT = 4 heures. Ensuite, la disponibilité est la suivante :

Disponibilité = (24 × 7 × 4-4) / (24 × 7 × 4) × 100 % = 99,40 %

Il est possible que l'entreprise ne soit pas d'accord. Dans ce cas, vous devez savoir quelle option il acceptera. À l'avenir, vous pouvez calculer deux options pour les systèmes matériels et logiciels avec une disponibilité différente et négocier avec l'entreprise sur la base d'une comparaison du coût des deux options. En général, les négociations avec l'entreprise et la budgétisation du service informatique sont un sujet distinct, qui nécessitera peut-être plus d'un livre à divulguer. Par conséquent, disons que dans notre exemple, la disponibilité est calculée et convenue et nous pouvons procéder à la création du système.

Notez que nous avons identifié la disponibilité requise avant de commencer à travailler sur la solution qui la fournit, et non l'inverse - nous avons d'abord choisi la solution et examiné sa disponibilité. La tâche technique est primordiale, et la disponibilité requise est l'un des paramètres qui y sont fixés. Lors de la mise en service du système, la disponibilité doit atteindre la valeur requise. Par conséquent, nous conseillons dans l'accord avec l'entreprise (SLA - Service Level Agreement) de déchiffrer en détail ce que l'on entend par le nombre de disponibilité (dans notre exemple, comme suit : " 4 heures d'indisponibilité de service une (1) fois dans les quatre (4) semaines"), afin que toutes les parties aient bien compris ce qui se cachait vraiment derrière les chiffres.

Trois dimensions de l'accessibilité

La toute première chose à comprendre lors du choix d'une solution est en quoi consiste la disponibilité d'un service informatique. De nombreuses frustrations opérationnelles découlent du fait que la disponibilité du service souhaité par une entreprise est directement liée à la disponibilité des équipements. Cependant, la disponibilité d'un service informatique est une combinaison de trois éléments :
1) Fiabilité - généralement traduite par fiabilité ;
2) Maintenabilité - traduit par "maintenabilité" ;
3) Facilité d'entretien - maintenabilité.
Examinons chacun de ces points.

Fiabilité

La fiabilité est la disponibilité de l'infrastructure ou du complexe matériel et logiciel dans son ensemble, y compris les communications. Par exemple, pour une boutique en ligne, nous avons besoin d'un serveur Web, d'un serveur d'applications, d'un SGBD, d'un stockage sur disque et d'un accès Internet. Par souci de simplicité, nous supposerons que le logiciel du serveur d'applications comprend un serveur Web et sera installé sur un serveur matériel, le SGBD sur le second, et le stockage sur disque est une matrice de disques externe.

Nous commençons à créer - nous construisons un projet d'infrastructure. Sous chaque composant, nous écrirons les paramètres de son accessibilité. La disponibilité de chaque composant - ci-après nous utiliserons le terme « fiabilité » - doit être obtenue auprès du fournisseur du composant (équipement, Logiciel ou service). Si, pour une raison quelconque, cela est impossible (par exemple, pour les composants logiciels, la valeur de fiabilité est généralement inconnue), la valeur requise devra être estimée et attribuée de manière indépendante. Chaque composant est un point de défaillance unique, ils sont donc connectés en série dans le schéma de fonctionnement pour le calcul de la fiabilité (Fig. 1). Notez qu'il ne s'agit pas d'un schéma de connexion des composants d'infrastructure, mais uniquement d'un schéma de calcul de fiabilité.

Donc, nous calculons la fiabilité. Comme nous avons une connexion série de composants, les valeurs de fiabilité sont multipliées :

Fiabilité = (0,985 x 0,97 x 0,975 x 0,98 x 0,99 x 0,9999 x 0,99) x 100 % = 89,47 %

C'est nettement insuffisant par rapport à la valeur requise de 99,40 %. Ensuite, nous modifierons notre décision - nous inclurons dans le système un fournisseur alternatif de services d'accès Internet (Fig. 2) et calculerons sa fiabilité. Étant donné que nous avons une connexion parallèle en ce qui concerne l'accès à Internet, la fiabilité globale est déterminée comme suit :

Fiabilité globale =

Fiabilité = × 100 % = 91,72 %

Je pense que le principe de "travailler avec fiabilité" du futur système a été démontré. Il est à noter que l'exemple considéré n'incluait pas les composants de l'infrastructure réseau et la fiabilité des connexions (par exemple, entre le serveur de base de données et le stockage sur disque), ainsi que les composants de l'infrastructure technique (alimentation électrique, climatisation , etc.), qui sont également des points de défaillance et doivent être inclus dans le calcul. L'évaluation de la fiabilité des composants logiciels mérite une attention particulière. Le principal conseil ici est un conservatisme raisonnable : utilisez des composants logiciels qui sont utilisés depuis longtemps dans de telles solutions et qui ont fait leurs preuves.

En utilisant les techniques qui ont été brièvement décrites ci-dessus, vous pouvez sélectionner une solution avec la disponibilité requise.

Maintenabilité et facilité d'entretien

Passons aux autres composants de l'accessibilité - la maintenabilité et la facilité d'entretien. Notez que les traductions « maintainability » et « maintainability » sont infructueuses, car elles ne montrent pas très clairement ce que cela signifie. Mieux vaut utiliser des traductions plus compréhensibles : maintenabilité - les activités du service informatique interne de l'organisation ; la facilité d'entretien - les services fournis par des fournisseurs externes.

Pour clarifier la situation, envisagez les options extrêmes. Quand la maintenabilité est-elle complètement absente ? Cela se produit lorsqu'une entreprise externalise son propre service informatique. Ici, la disponibilité n'est qu'une combinaison de fiabilité et de prestataires externes.

Quand la facilité d'entretien est-elle complètement absente ? C'est le cas, par exemple, du FSB qui, pour des raisons de secret, est contraint de mener toutes les activités pour maintenir le système en état de fonctionnement exclusivement par son service informatique, même les pièces de rechange sont achetées indépendamment, et ne sont pas fournies dans le cadre d'un contrat technique. contrat d'accompagnement. La disponibilité n'est alors qu'une combinaison de la fiabilité du système et des activités du service informatique interne de l'organisation.

Il est clair que la décision doit être prise en même temps que le développement des schémas de maintenabilité et d'entretien. Dans l'ensemble, la fiabilité, la maintenabilité et la facilité d'entretien sont les trois dimensions de l'accessibilité. Les changements dans l'un d'eux doivent être compensés par des changements dans les deux autres - sinon, le paramètre de disponibilité des services informatiques changera, ce qui peut nuire à l'entreprise.

Manières de manipuler les composants d'accessibilité

Pour comprendre comment tous les éléments de l'accessibilité peuvent être manipulés, considérons un autre exemple pratique. L'entreprise, qui possède des centres de traitement de données dans deux villes russes, Zelenograd (ville satellite de Moscou) et Irkoutsk, a acquis deux systèmes clés en main identiques. Par conséquent, la fiabilité - la fiabilité - est la même pour eux. Les deux systèmes informatiques étaient soutenus par les mêmes contrats de support matériel et logiciel, ce qui signifie que les services fournis par le fournisseur externe — la facilité d'entretien — étaient également les mêmes. Cependant, la disponibilité des systèmes variait. Et l'entreprise a commencé à se plaindre au fournisseur de la faible disponibilité du système à Irkoutsk, affirmant que l'une des solutions était «défectueuse» et exigeant un audit.

Cependant, dans ce cas, l'audit de la solution ne révélera probablement pas la cause première de la "défaillance" de la disponibilité, car un seul composant sera étudié - la fiabilité, qui devrait être la même pour les deux systèmes, et seulement deux autres les composants doivent être étudiés. Si vous y prêtez attention, il s'avère que deux options sont possibles.

Option 1 : les pannes matérielles ont causé la perte de disponibilité. En raison de l'emplacement géographique des centres de données, les mêmes contrats de support matériel peuvent en réalité être différents. Par exemple, centre de services le fournisseur externe est situé à Moscou, et le contrat d'assistance technique indique qu'il n'est valable que les jours de semaine et que l'ingénieur arrive sur le site d'installation de l'équipement « par le premier train ou vol disponible ». Évidemment, pour un ingénieur quittant Moscou, cette valeur sera différente pour Zelenograd et Irkoutsk.

Solutions possibles au problème de disponibilité dans ce cas :

• modifier la fiabilité du système informatique à Irkoutsk, par exemple, mettre un nœud supplémentaire dans le cluster ;
• modifier le paramètre de maintenance - pour créer un entrepôt à Irkoutsk, pour donner la possibilité aux spécialistes informatiques de l'entreprise de modifier eux-mêmes les composants défectueux, si cela ne contredit pas les règles du fabricant.

Il est également judicieux de vérifier les conditions de fonctionnement. Exemples de violations typiques de ces conditions :

• effectuer des travaux de réparation dans les locaux avec les systèmes allumés, ce qui entraîne leur accumulation de poussière, et la poussière est très dangereuse pour les équipements de serveur ;
• l'utilisation de climatiseurs domestiques dans les salles de serveurs, bien que chaque type d'équipement ait ses propres exigences en matière d'humidité et que les climatiseurs domestiques ne soient pas conçus pour maintenir son niveau spécifié et que l'air complètement sec soit destructeur pour la technologie.

Option 2 : des problèmes logiciels ont entraîné une réduction du niveau de disponibilité requis. Dans ce cas, le problème vient probablement du service informatique d'Irkoutsk. Les services de support technique logiciel sont fournis à distance. Par conséquent, il n'y a pas de différence dans les services, sauf qu'il existe différentes périodes de service par rapport à l'heure locale pour différents fuseaux horaires, mais cela n'a généralement pas d'effet significatif. La raison probable de "l'échec" de l'accessibilité ici est le niveau différent de professionnalisme des services informatiques - à Irkoutsk, il est probablement inférieur à celui de Zelenograd. Solutions possibles:

• resserrer la maintenabilité au niveau requis - dispenser une formation au personnel informatique à Irkoutsk sur les produits logiciels et matériels faisant partie du système informatique, organiser des séminaires pour transférer l'expérience de l'équipe informatique de Zelenograd, copier les processus d'exploitation, etc. ;
• compenser la maintenabilité par la facilité d'entretien - acheter des services d'assistance technique avancés, des services externes, etc.

Pour en revenir à notre exemple de boutique en ligne, quelle est la meilleure combinaison de fiabilité, de maintenabilité et de facilité d'entretien ? La réponse à cette question dépend de chaque cas particulier. Par exemple, vous pouvez recommander l'hébergement plutôt que la mise en œuvre complète de l'ensemble de l'infrastructure (informatique et technique) vous-même. En général, nous avons les méthodes standard suivantes pour gérer la disponibilité. 1. Changement de fiabilité :

• évolution de la solution informatique vers la haute disponibilité (Haute Disponibilité) - l'utilisation de clusters, l'utilisation d'équipements avec prise en charge du remplacement "à chaud", duplication répétée de points de défaillance potentiels, etc. ;
• location de l'intégralité ou d'une partie de l'infrastructure auprès de fournisseurs externes (hébergement, colocation).

2. Changement de maintenabilité (changements dans les activités du service informatique de l'entreprise) :

• diffusion au sein de l'organisation de ses propres bonnes pratiques en matière de gestion informatique ;
• inviter des consultants externes pour organiser les processus dans le service informatique ;
• formation du personnel informatique.

3. Modification de la facilité d'entretien - modification des contrats de services informatiques avec des fournisseurs externes pour augmenter le niveau de service, augmenter le volume de services, étendre le domaine de responsabilité des fournisseurs de services externes, etc. Toutes les techniques pour manipuler trois sources et trois composants de l'accessibilité ne peut pas être décrite dans un seul article. Cependant, les principales approches pour compenser certaines composantes de l'accessibilité par d'autres ont été démontrées. Pour améliorer encore vos compétences dans ce domaine, vous devriez étudier expérience pratique conception et exploitation de systèmes informatiques.

L'évolution du regard des entreprises sur la fourniture des services informatiques conduit à la nécessité de mettre en place un processus de gestion de leur disponibilité.

Dans la troisième version, les processus ITIL de gestion de la disponibilité et de la continuité des services informatiques sont considérés ensemble (ci-après dénommé le processus). Les concepts clés les plus importants de ce processus collaboratif sont :

disponibilité- la capacité d'un service informatique ou de ses composants à remplir leurs fonctions dans un certain laps de temps ;

fiabilité- la capacité d'un service informatique ou de ses composants à exécuter des fonctions spécifiées dans certaines conditions d'exploitation ;

recouvrabilité- la capacité du service informatique ou de ses composants à retrouver leurs caractéristiques opérationnelles, partiellement ou totalement perdues à la suite d'une défaillance ;

facilité d'entretien- caractéristique des composants informatiques, qui détermine leur emplacement et leurs paramètres afin d'assurer la rationalité des actions du personnel lors de l'installation, du transport, de la prévention et de la réparation (cette notion est appliquée en relation avec les prestataires externes de services informatiques).

L'entreprise a sa propre compréhension de la disponibilité et du coût des services informatiques et, par conséquent, l'objectif du processus est d'assurer le niveau de disponibilité requis tout en maintenant un certain niveau de coûts. Pour atteindre cet objectif, le processus vise à accomplir les tâches suivantes :

Planification et développement des services informatiques en tenant compte des exigences de l'entreprise pour le niveau de disponibilité ;

Optimiser la disponibilité des services informatiques grâce à des améliorations rentables ;

Réduire le nombre et la durée des incidents affectant la disponibilité des services informatiques.

Au cours de la résolution de ces problèmes, les exigences commerciales pour la disponibilité des services informatiques et des composants de l'infrastructure informatique sont fixées ; les rapports requis sont élaborés ; les niveaux de disponibilité des services informatiques sont revus périodiquement ; un plan de disponibilité est formé qui définit les priorités et reflète les mesures visant à améliorer la disponibilité des services informatiques. En d'autres termes, le processus se résume à planifier la livraison des services informatiques, à mesurer le niveau de disponibilité et à prendre des mesures pour l'améliorer.

Planification

Lors de la planification, les exigences commerciales pour la disponibilité des services informatiques sont formulées, des critères pour déterminer le niveau de disponibilité et les temps d'arrêt acceptables des services informatiques sont développés et certains aspects sont pris en compte. sécurité de l'information... L'entreprise doit établir une limite qui définit la disponibilité et l'indisponibilité d'un service informatique, comme la durée pendant laquelle un service informatique peut être interrompu en cas de défaillance de l'infrastructure informatique.

Lors de la conception de la disponibilité des services informatiques, une analyse de l'infrastructure informatique est réalisée afin d'identifier les composants les plus vulnérables qui ne disposent pas de réserve et peuvent, en cas de panne, avoir un impact négatif sur la fourniture de l'informatique prestations de service. Dans la terminologie ITIL, ces composants sont appelés Single Point of Failure (SPOF) et sont définis à l'aide de la méthode Component Failure Impact Analysis (CFIA). Cette méthode est utilisée pour évaluer et prévoir l'impact des défaillances de composants informatiques sur un service informatique. Les principaux objectifs de l'ACIA sont les suivants :

Identifier les points de défaillance affectant la disponibilité ;

Analyser l'impact de la défaillance d'un composant sur l'entreprise et les utilisateurs ;

Détermination de la relation entre les composants et le personnel ;

Déterminer le temps de récupération des composants ;

Identifier et documenter les options de récupération.

Pour l'analyse des risques, la méthode d'analyse et de gestion des risques (méthode d'analyse et de gestion des risques CCTA, CRAMM) est utilisée, qui analyse les menaces et les dépendances possibles des composants informatiques, évalue la probabilité de situations non standard ou d'événements d'urgence.

Pour assurer le niveau de disponibilité requis, il est possible d'utiliser une technique de masquage de l'impact négatif dû aux temps d'arrêt planifiés ou non planifiés d'un composant, la duplication de composants informatiques, ainsi que l'utilisation de moyens pour améliorer les performances d'un composant en cas d'une augmentation de la charge, etc. Dans les cas où des fonctions commerciales spécifiques dépendent fortement de la disponibilité des services informatiques et de la perte réputation de l'entreprise les temps d'arrêt sont considérés comme inacceptables, la disponibilité de certains services informatiques est plus élevée et des ressources supplémentaires sont allouées.

La conception de la prestation de services informatiques garantit que les exigences de disponibilité énoncées sont satisfaites, mais cela fait référence à l'état opérationnel stable du service informatique. Cependant, des défaillances sont également possibles, par conséquent, une planification de la reprise des services informatiques est également effectuée, y compris l'organisation de l'interaction avec le processus de gestion des incidents et le Service Desk ; la planification et la mise en œuvre de systèmes de surveillance pour détecter les défaillances et en informer en temps opportun ; développement d'exigences pour la sauvegarde et la restauration du matériel, des logiciels et des données ; développer une stratégie de sauvegarde et de restauration ; définir des métriques de récupération, etc.

Un autre aspect de la planification consiste à déterminer les temps d'arrêt. Tous les composants informatiques doivent faire l'objet d'une stratégie de service. Selon l'application informatique, la criticité et l'importance des fonctions métier prises en charge par un composant informatique particulier, la fréquence et le niveau de service peuvent varier. Si vous devez fournir un service en mode 24x7, vous devez trouver un équilibre optimal entre les exigences de maintenance des composants informatiques et les pertes commerciales dues aux interruptions de service. Les programmes de service approuvés doivent être documentés dans des accords de niveau de service (SLA).

Améliorer la disponibilité des services informatiques

Pourquoi améliorer l'accessibilité ? Les raisons peuvent être multiples : inadéquation entre la qualité des services informatiques et les exigences du SLA ; instabilité dans la fourniture de services informatiques; les tendances à la baisse de la disponibilité des services informatiques ; des temps de récupération trop longs ; les demandes des entreprises pour une disponibilité accrue.

L'amélioration de l'accessibilité nécessite des les coûts financiers et certaines techniques et technologies sont utilisées pour identifier les opportunités d'amélioration des services informatiques, notamment l'analyse des arbres de défaillance (FTA) et l'analyse des pannes de système (SOA).

L'analyse de l'arbre de défaillance identifie la chaîne d'événements conduisant à la défaillance d'un composant informatique ou d'un service informatique. Graphiquement, un arbre de défaillance (voir Fig.) est une séquence d'événements qui commence par un événement initiateur suivi d'un ou plusieurs événements fonctionnels et se termine par un état final. Selon les événements, les séquences peuvent se ramifier logiquement.

L'analyse des temps d'arrêt du système est une approche structurée pour identifier les causes profondes des interruptions dans la fourniture de services informatiques et utilise plusieurs sources de données pour déterminer l'emplacement et la cause des interruptions. Les objectifs de cette analyse :

Détermination des causes profondes des perturbations dans la fourniture de services informatiques ;

Déterminer l'efficacité du support des services informatiques ;

Préparation de rapports ;

Lancement du programme de mise en œuvre des recommandations acceptées ;

Analysez les améliorations de la disponibilité sur la base de l'analyse des temps d'arrêt du système.

L'analyse des temps d'arrêt du système augmentera le niveau de disponibilité sans augmenter les coûts, améliorera les compétences et les capacités du personnel pour éviter les coûts de consultation sur l'amélioration de l'accessibilité et identifiera un programme d'amélioration spécifique.

Le résultat des activités d'amélioration de la disponibilité des services est un plan à long terme visant à améliorer de manière proactive la disponibilité des services informatiques, en tenant compte des contraintes financières. Un plan d'accessibilité décrit les niveaux d'accessibilité actuels et prévus, ainsi que les mesures qui doivent être prises pour l'améliorer. La préparation du plan nécessite la participation des représentants des entreprises, des responsables des processus ITSM mis en œuvre, des représentants des fournisseurs de services informatiques externes, des spécialistes du support technique chargés des tests et de la maintenance. Le plan est établi pour une période pouvant aller jusqu'à deux ans et, pour les six prochains mois, il doit contenir Description détaillée Activités. Le plan est revu tous les trimestres avec des ajustements minimes et tous les six mois avec la possibilité de changements majeurs.

Mesurer la disponibilité des services informatiques

Un service informatique, du point de vue du consommateur, peut être considéré comme abordable lorsque les fonctions commerciales vitales qui l'utilisent fonctionnent bien. Dans ce cas, les principaux indicateurs quantitatifs sont la disponibilité - le rapport entre le temps de disponibilité réelle d'un composant informatique et le temps de disponibilité spécifié dans les contrats de niveau de service, et l'indisponibilité (en %) - l'inverse de la disponibilité. Ces paramètres sont utilisés par les services informatiques et, d'un point de vue commercial, ne sont pas très indicatifs, car ils ne reflètent pas les valeurs de disponibilité pour les entreprises ou les utilisateurs - ils peuvent démontrer un niveau élevé de disponibilité des composants informatiques, tout en le niveau actuel de disponibilité des services informatiques sera faible...

L'entreprise peut comprendre des indicateurs tels que : la fréquence des pannes des services informatiques, la durée totale des pannes, la zone d'influence de l'interruption des services informatiques.

Rôles et responsabilités

Le processus définit le rôle du gestionnaire de processus, qui est chargé de guider le processus et de prendre les mesures nécessaires. Le gestionnaire de processus est responsable de l'exploitation et du développement du processus conformément aux règlements et aux plans. Il est recommandé d'employer un employé ayant une expérience pratique de la gestion des processus, une connaissance de l'ITSM, des méthodes statistiques et analytiques utilisées en informatique, des principes de gestion des coûts, une expérience du travail avec le personnel, une connaissance des méthodes de négociation, etc. pour le rôle d'un processus directeur.

Mise en œuvre du processus

La mise en œuvre de tout processus ITSM est un projet long et complexe avec des objectifs et des délais précis. La mise en œuvre en interne est difficile : la mise en œuvre du processus en parallèle des activités opérationnelles quotidiennes ne permet pas de se concentrer pleinement sur le projet ; le « tirage » constant de ressources pour des tâches externes au projet entraîne au final une augmentation des coûts financiers, un décalage du calendrier du projet pour une durée indéterminée, une perte d'attention progressive voire un arrêt éventuel du projet. De plus, la mise en œuvre en interne nécessite des connaissances dans un domaine donné, ce qui entraîne la nécessité d'une formation coûteuse.

Comme tout projet, la mise en œuvre des processus commence par la constitution d'équipes de projet, l'élaboration de documents de gestion de projet, l'élaboration d'un plan de projet, etc. Au stade des travaux de « pré-conception », des actions marketing sont menées pour familiariser les représentants de l'entreprise avec les technologies et recommandations ITIL et justifier la nécessité pour une entreprise de mettre en place un processus de gestion de la disponibilité des services informatiques.

Après avoir accepté et reçu une réponse positive sur la mise en œuvre du processus, les objectifs et les limites du domaine du processus sont déterminés.

Effet et problèmes

Le principal effet de la mise en œuvre des processus est que les services informatiques sont conçus en tenant compte de la disponibilité et sont exploités et gérés à un niveau de disponibilité et de coût convenu. Les facteurs positifs sont également : une personne responsable de la disponibilité des services informatiques ; utilisation optimale des performances de l'infrastructure informatique pour assurer le niveau requis de disponibilité des services informatiques ; réduire la fréquence et la durée des pannes des services informatiques au fil du temps ; une transition qualitative dans les activités des fournisseurs de services informatiques de l'élimination des erreurs dans la fourniture des services à l'augmentation de leur niveau de disponibilité.

Les problèmes potentiels pouvant influencer négativement la prise de décision sur la mise en œuvre et le fonctionnement du processus sont généralement de nature organisationnelle :

L'existence d'une situation où chaque responsable informatique est responsable de la disponibilité des systèmes ou composants informatiques qui relèvent de son domaine de responsabilité, alors que la disponibilité globale des services informatiques n'est pas surveillée et peut être insatisfaisante ;

Refus de mettre en œuvre le processus car la disponibilité actuelle des services informatiques est considérée comme acceptable ;

Hypothèses selon lesquelles s'il existe d'autres processus TSM, le processus de gestion de la disponibilité sera effectué automatiquement ;

Résistance à la centralisation de la gestion des infrastructures informatiques par les responsables informatiques ;

Autorité insuffisante du gestionnaire de processus, conduisant à l'incapacité d'exécuter correctement les tâches.

Evgeny Bulychev (Bulychev@i-teco.ru) - Consultant du département I-Teco Business Consulting (Moscou).

L'idée d'écrire cet article est venue après une conversation avec l'un des gros clients - un collègue a raconté l'histoire du choix d'un fournisseur de cloud IaaS pour son entreprise.

Le premier ensemble de critères d'évaluation d'un fournisseur de services ressemblait à ceci : un nom (marque) bien connu, une histoire commerciale positive dans le domaine des services cloud, une valeur adéquate. Sur la base des résultats de l'analyse, les candidats potentiels ont été choisis parmi plusieurs entreprises, qui, selon les critères ci-dessus, étaient presque les mêmes, et chacune a essayé de prouver leurs avantages, en se référant aux différentes caractéristiques de leurs services cloud.

Vladimir Kourilov, société Onlanta.

La conversation a donc atteint les indicateurs de fiabilité. Et il s'agissait de comparer les niveaux de disponibilité des centres de données dans lesquels se trouvaient les nuages. Il est rapidement devenu évident que seuls deux candidats disposent de centres de données avec une disponibilité de 99,98 %. Le choix s'est porté sur un fournisseur de services cloud étranger - le prix a été gagné. Le collègue a tout expliqué simplement : - "A quoi ça sert de payer plus pour les mêmes indicateurs de fiabilité ?"

Étant donné l'existence différentes options, définissons l'interprétation du terme « Accessibilité » dans le cadre de cet article. Définissons la disponibilité comme la disponibilité du système dans un certain intervalle de temps, exprimée en pourcentage de cet intervalle. Ou sous la forme classique : "La propriété d'un objet d'effectuer la fonction requise dans des conditions spécifiées pour un intervalle de temps spécifié." Cela, en général, est plus proche du concept déjà bien établi de « préparation » du système.

L'année d'exploitation qui a suivi cette décision a montré que le fournisseur subit des perturbations mineures dans le travail des systèmes d'ingénierie du centre de données lors des commutations planifiées. Dans le même temps, la disponibilité du centre de données est restée dans le SLA, car le basculement a pris quelques secondes. Toutefois, si Système d'Information le client ne s'arrêtait pas à l'avance avant de tels basculements, alors la base de données en cas de panne nécessitait une reprise à partir d'une sauvegarde, ce qui arrêtait le travail des employés pendant plusieurs heures. Éteindre / allumer les systèmes, avant de basculer, a légèrement corrigé la situation, mais en même temps, il y avait un temps d'arrêt des employés pendant 25 à 30 minutes, ce qui a également provoqué des plaintes des utilisateurs.

Un an s'est écoulé et maintenant, le collègue loue de la capacité dans un autre cloud, où la disponibilité de l'un des centres de données est inférieure à ce qui précède et où les temps d'arrêt ont considérablement diminué. Comment y parvenir et qu'est-ce qui est important lors de l'évaluation de la fiabilité des solutions cloud, et qu'est-ce qui n'est pas très important ? Quelles sont les possibilités d'économiser, de réduire le risque de trop-payé "pour de beaux numéros", et non pour la fiabilité réelle ? Comment mettre en évidence les paramètres critiques des services cloud pour la fiabilité de votre application ?

Je vais essayer de formuler les réponses à ces questions plus loin.

Fiabilité des applications - comment elle s'empile dans le cloud

Fiabilité des services applicatifs

Si nous essayons de formuler la définition de la fiabilité de l'application, cela ressemblera à ceci : « La fiabilité est la propriété d'une application de maintenir des performances dans le temps avec toutes les fonctionnalités qui y sont incorporées ».

Qu'est-ce qui détermine les performances de l'application et comment la fiabilité de l'application est-elle liée à la disponibilité du centre de données ?

L'application est basée sur une plate-forme logicielle, qui, à son tour, est située sur une plate-forme d'infrastructure utilisant une plate-forme d'ingénierie, voir Fig. Collectivement, ces quatre niveaux fournissent le « service d'application ».

Riz. Un exemple simplifié de calcul de la disponibilité du Service applicatif

Comme on peut le voir sur la figure, nous avons affaire à un système d'éléments séquentiels, où la défaillance de n'importe quel élément entraîne une défaillance du système dans son ensemble.

La disponibilité d'un tel système (As) est définie comme le produit d'indicateurs de la disponibilité de tous les éléments :

A i - disponibilité de chaque composant connecté en série.
A s = 0,99995 0,99995 0,993 0998 ≈ 0,99091 ou 99,091

Comme vous pouvez le voir, la disponibilité du service d'application importe loin de la disponibilité de la plate-forme d'ingénierie du centre de données. Il est possible de convertir les chiffres de disponibilité en valeurs de temps d'arrêt du système. Il s'avère, malgré le temps d'arrêt annuel autorisé de la plate-forme d'ingénierie, à 1 heure. 45 minutes, pour le service applicatif le temps d'arrêt annuel sera de 86 heures 22 minutes.

En conséquence, le taux de haute disponibilité d'un datacenter ne signifie pas la même fiabilité élevée des services applicatifs opérant dans ce datacenter.

Fiabilité de l'application réseau

Par conséquent, lors du choix des fournisseurs de services, serait-il juste de se concentrer sur la disponibilité globale des services applicatifs ? Malheureusement, les choses ne sont pas si simples ici.

Il s'avère qu'un développeur de logiciels est capable d'influencer l'assurance de la fiabilité (résilience aux pannes, charges) d'une application particulière. Par exemple, la fiabilité d'une application dans le cloud peut être considérablement améliorée grâce à l'utilisation de bibliothèques spécialisées axées sur la gestion de la latence des requêtes exécutées. Les applications écrites de manière standard auront des indicateurs de fiabilité comparativement plus faibles.

L'une des options pour mettre en œuvre l'utilisation de bibliothèques spécialisées par Microsoft est le bloc d'application de gestion des erreurs transitoires (voir http://msdn.microsoft.com/en-us/library/hh680934(v=pandp.50).aspx).

Fiabilité de la plateforme logicielle

Fiabilité de la plate-forme logicielle, y compris système opérateur, pilotes, bibliothèques, là encore, reste « du côté des développeurs » et, pour l'instant, ne dépend pas fortement du prestataire. Cependant, si le fournisseur de services a pensé à une politique de support technique appropriée, cela peut affecter indirectement la disponibilité.

Je parle des équipements de sécurité « hygiéniques ». Tout d'abord, à propos du service de mise à jour du logiciel système. Il devrait être inclus dans le portefeuille de services du fournisseur de services, ou mieux encore, il devrait être inclus dans le prix du service « par défaut ». Deuxièmement, il s'agit d'un service de protection antivirus avec un choix de programmes antivirus. Et troisièmement, sauvegarde serveurs virtuels du client. Ce ne sont pas tous, mais les moyens les plus importants pour améliorer la disponibilité de votre service d'application.

Fiabilité de la plate-forme d'infrastructure

Cette composante de fiabilité dépend entièrement du fournisseur de services et doit être évaluée par vous sur un pied d'égalité avec la disponibilité de la plate-forme d'ingénierie du centre de données. Vous devez demander ce paramètre à votre fournisseur car il n'est généralement pas répertorié dans les documents marketing. Dans le même temps, il est nécessaire d'obtenir une explication sur la façon dont ce paramètre a été calculé.

Bien qu'il faille garder à l'esprit que tous les fournisseurs de services ne voudront pas présenter de telles données, car à partir du calcul, le schéma structurel de la solution d'infrastructure et des équipements utilisés devient clair - et c'est un certain savoir-faire.

Pourtant:

• Demandez un schéma de la structure fonctionnelle de la plateforme d'infrastructure pour héberger votre Application Service. Il doit comprendre :
  • Infrastructure de réseau;
  • Réseau de zones de mémorisation;
  • Infrastructure informatique.
• Demandez à indiquer sur ce schéma les lieux de réservation du matériel. Il n'est pas nécessaire d'indiquer le type d'équipement utilisé.
• Demandez la disponibilité (ou l'état de préparation) pour chaque niveau.
• Comptez la disponibilité comme le produit de la disponibilité des éléments de la plate-forme d'infrastructure.

Vous avez maintenant la possibilité de déterminer la disponibilité de votre service applicatif aussi précisément que possible. D'après notre expérience, 90 % des coentreprises en Russie ont une disponibilité totale ne dépassant pas 99 %. Et c'est le risque de temps d'arrêt jusqu'à 87 heures par an. Il s'agit de taux de disponibilité normaux, à moins que vous n'ayez des applications critiques pour l'entreprise qui vous coûtent des millions de dollars en une heure d'indisponibilité. Et si un arrêt d'une heure s'apparente à un désastre pour votre entreprise, alors il y a les 10 % restants pour vous, des coentreprises qui fournissent un service au niveau de l'entreprise avec la disponibilité du service d'application au niveau de 99,99 %. Comment cela est réalisé dans la section suivante.

Solutions pour la haute disponibilité du service applicatif

En conséquence, le client ne se soucie pas de la façon dont le SLA pour les systèmes d'ingénierie est respecté ; il est important pour lui quelle est la disponibilité du service de ses applications, c'est-à-dire. - temps de récupération garanti pour l'application.

Les systèmes dont nous avons parlé précédemment avaient une structure séquentielle. La disponibilité, que nous avons considérée ci-dessus comme le produit d'éléments individuels, est la limite technique fournie par de tels systèmes. En fait, en raison de l'apparition de divers facteurs supplémentaires, la disponibilité est encore plus faible. Rappelez-vous au début de l'article l'histoire d'une deuxième panne de courant et de cinq heures d'indisponibilité ?

Est-il possible d'augmenter la disponibilité d'une application si les paramètres de disponibilité d'un centre de données particulier sont définis et ne peuvent pas être modifiés ?

La réponse est que vous pouvez.

Par exemple, voici deux approches qui vous permettent de faire cela :

• Cluster haute disponibilité distribué géographiquement ;
• Reprise des traitements dans un datacenter de sauvegarde géographiquement distant (Disaster Recovery).

Riz. Schéma structurel d'un cluster haute disponibilité distribué géographiquement

Riz. Schéma fonctionnel pour la restauration du traitement dans un centre de données de sauvegarde géographiquement distant

La première approche est idéale du point de vue de la disponibilité (la récupération des performances se fait en quelques secondes), mais elle perd en prix et est assez difficile à mettre en œuvre. La deuxième approche restaure un service à partir d'une copie de travail - ce n'est pas si rapide et une petite partie des données en cas de panne devra être restaurée manuellement, mais cette option a un coût inférieur et est plus facile à mettre en œuvre.

Dans les deux cas, il faut parler d'éloignement géographique des datacenters afin d'éviter au maximum la possibilité de ressources interconnectées. Par exemple, l'utilisation des mêmes sous-stations qui alimentent les centres de données. Vous vous souvenez de la panne de courant dans le sud-est de Moscou en mai 2008 en raison d'un incendie à la sous-station Chaginskaya, New York 2003. Par conséquent, le centre de données de sauvegarde doit être situé plus loin du centre principal.

L'approche avec deux centres de données nous permet de parler de créer un système avec des éléments parallèles. Dans le même temps, d'une part, les centres de données principaux et de secours sont des systèmes indépendants, d'autre part, ils constituent une plate-forme commune pour le service d'application - quel que soit le centre de données dans lequel l'application s'exécute actuellement, elle peut se déplacer d'un centre de données à un autre.

La différence fondamentale entre un système parallèle est que la fiabilité augmente avec une augmentation des éléments parallèles du système. Le calcul de la disponibilité d'un système composé d'éléments parallèles peut être effectué à l'aide de la formule :

Où : A s - Disponibilité totale, disponibilité de l'ensemble du système,
A i - disponibilité de chaque composant connecté en parallèle.

Par exemple, calculons un système d'un cluster à haute disponibilité distribué géographiquement de deux centres de données avec une disponibilité de 99 % chacun.

As = 1- (1-0,99) * (1-0,99) = 0,9999 ou 99,99

Autrement dit, deux centres de données pas les plus fiables peuvent fournir une disponibilité au niveau des systèmes critiques.

Pour déterminer la disponibilité du service applicatif dans l'option de restauration du traitement dans un datacenter de sauvegarde géographiquement distant avec un intervalle de synchronisation de 15 minutes pour le cas d'une seule panne, elle est calculée comme suit : il faut demander le temps de récupération de le service applicatif, garanti par la joint-venture ; puis nous calculons le pourcentage de l'intervalle annuel - et soustrayons le résultat de un. Nous obtenons la disponibilité après le premier échec. Par exemple, pour un système avec un intervalle de synchronisation de 15 minutes :

Le nombre total d'heures dans une année est de 365 * 24 = 8760
Temps d'arrêt garanti = temps d'arrêt maximal
15 minutes ou 0,25 heures, soit ≈ 0,003 du temps annuel

Celles. chaque échec aura un poids de 0,003%. Ainsi, le système avant la panne du système a une disponibilité égale à 100%, après la première panne, 99,997%, après la seconde panne 99,994%. Calculons la même chose pour un système avec un intervalle de synchronisation horaire :

Temps de récupération garanti = Temps d'arrêt maximal = 1 heure, soit ≈ 0,01 du temps annuel

Chaque échec aura un poids de 0,01%. Ainsi, le système avant la panne du système a une disponibilité égale à 100 %, après la première panne, 99,99 %, après la deuxième panne 99,98 %. En outre, les adeptes de la théorie des probabilités peuvent s'exercer à évaluer la probabilité d'occurrence des premier, deuxième et troisième échecs. Le résultat vous convaincra que l'influence de ce facteur est négligeable sur les résultats obtenus. Cela me permet de recommander une méthodologie suggérée pour évaluer la disponibilité des services pour vos applications dans le cloud.

En résumé ...

• Commencez par évaluer la criticité métier de l'application que vous envisagez d'héberger dans le cloud. Estimez le coût des temps d'arrêt des applications. Combien l'absence de service d'application vous coûtera-t-elle ?
• À partir de là, estimez la valeur acceptable du temps d'arrêt par jour, par an. Calculez la disponibilité critique du service applicatif.
• Comparez le coût potentiel des temps d'arrêt aux prix JV qui offrent une disponibilité raisonnable pour vos applications.
• Lors du choix d'une coentreprise, privilégiez quelqu'un qui peut non seulement fournir le niveau de disponibilité actuel, mais également, en tant que service / service supplémentaire, fournir une amélioration de la disponibilité. Surtout si votre entreprise grandit et se développe.
• Et restez entraîné. Prendre ce qu'ils donnent au toucher = tester. La théorie sans la pratique n'est pas très utile pour les affaires.