Fermer

novembre 1, 2019

Résilience – Un pilier de base de toute application critique fonctionnant sur le cloud


Intro

Le cloud offre des avantages indéniables pour la création de solutions agiles rentables. Les efforts déployés à l'échelle de l'entreprise pour moderniser la pile d'applications ont alimenté les initiatives de migration dans le nuage. Alors que de plus en plus de monolithes sont décomposés et repensés à l'aide d'une architecture de microservices distribués, un vaste portefeuille de services en nuage rend le développement et le déploiement sur le nuage plus rapides et économiques. Cependant, les utilisateurs qui construisent et planifient le cloud supposent la haute disponibilité des services cloud annoncés par le fournisseur de services et, en tant que tels, présument de la disponibilité continue de leur solution en cas de sinistre. Pour mettre en perspective, la migration dans le cloud et l’adoption de services natifs dans le cloud n’aident pas automatiquement la «résilience» de l’architecture de votre application. Une conséquence involontaire de cette hypothèse est une augmentation du risque global de l'entreprise.

Fonction de résilience

En tant que telle, pour mieux tenir compte de la résilience, le cloud devrait en soi être considéré comme une entité distincte présentant des aspects fonctionnels et non fonctionnels. doivent être définis, évalués et contrôlés séparément. La plupart des implémentations tiennent compte de l'utilisation optimale et économique du cloud, sans planification généralisée sur la résilience. Le fait de disposer d'une fonction d'entreprise ou d'une équipe centrée sur la résilience peut aider à réaliser une meilleure évaluation et planification en amont de l'application et de l'architecture physique. Une telle fonction peut permettre de trouver le juste équilibre entre l’agilité offerte par le cloud et la tolérance au risque de l’entreprise. Si les entreprises ne parviennent pas à créer et à intégrer une fonction de résilience dans leur cycle de vie de développement d'applications, elles acceptent volontiers davantage le risque d'indisponibilité non planifiée lorsqu'elles font face à des charges de travail critiques. L'évaluation de ce risque nécessite de quantifier de manière fiable le coût des temps d'arrêt. Selon certaines estimations, « En moyenne, une défaillance d'infrastructure peut coûter 100 000 dollars par heure et une défaillance d'applications critiques, entre 500 000 et 1 million de dollars par heure. * » Les entreprises ne peuvent pas se permettre de répéter des événements indisponibles et imprévisibles. en tant que telle La ​​fonction de résilience revêt une importance primordiale pour toute organisation dont les charges de travail critiques sont développées sur le cloud ou sont en cours de reformulation et de migration vers le cloud. La fonction de résilience peut aider à apporter une résilience sans précédent aux entreprises tout en évaluant, en mesurant et en corrigeant tout problème technique potentiel pouvant poser un risque par inadvertance pour toute application critique. L'équipe chargée de cette fonction élabore une hypothèse sur les cas extrêmes pouvant affecter la disponibilité des applications. " À la fin de ce blog, j'ai publié des liens vers des articles détaillant les conséquences lorsque la société ne surestime pas l'importance des cas critiques pour les charges de travail critiques. "

Approche de la résilience

Examinez tous les composants liés à la conception d'applications. L'analyse des effets du mode de défaillance ou FMEA est un bon point de départ pour évaluer l'intensité de la défaillance. L’équipe de résilience doit travailler avec les architectes d’application, de réseau, de sécurité et d’infrastructure pour développer un diagramme d’interaction de tous les composants faisant partie de la pile d’applications globale. Chaque point d'interaction doit ensuite être évalué individuellement pour toutes les défaillances possibles. De tels échecs doivent être évalués en fonction de la gravité, de l'observabilité et de la probabilité. Le résultat de cet exercice est la création d'un profil de risque pour chaque défaillance en calculant le numéro de priorité du risque (RPN) en utilisant les trois spécificités ci-dessus. Les défaillances à haut risque sont celles présentant une probabilité élevée, une gravité élevée et une faible observabilité. L’équipe de résilience doit ensuite identifier un ensemble fini d’échecs en RPN élevés pouvant être évalués et répliqués via des POC. L’équipe chargée de la résilience devrait alors recommander des solutions potentielles à différents intervenants sur la base des résultats observables des POC. Dans une configuration plus mature, les équipes de résilience peuvent devenir une partie intégrante des équipes de développement d'applications et peuvent aider à la création d'utilitaires et de structures qui ciblent spécifiquement les points de défaillance et permettent de combler les lacunes structurelles dans le code des applications.

CHAOS et la vérification de services dans le nuage sont deux autres ramifications de la fonction de résilience. CHOAS s’appuie sur l’hypothèse de défaillance et procède à l’ingestion de défaillance dans toutes les sections vulnérables de l’architecture d’application et de son infrastructure associée. CHAOS indique la capacité de votre application à résister aux attaques éventuelles par inadvertance et vérifie la défense intégrée des applications contre de telles attaques. Idéalement, les expériences CHAOS sont conduites dans des environnements de production réels. Toutefois, si votre entreprise est nouvelle dans les tests CHAOS, son exécution dans un environnement de type production (UAT, Performance, etc.) constitue un bon point de départ. La vérification des services en nuage est un autre exercice spécifique à l’exécution d’expériences ciblées approfondies sur des services natifs en nuage, qui font partie de l’architecture de votre application. Cela inclut la compréhension et la conception de bout en bout du service fourni et de son fonctionnement en cas de stress. Tout incident ou problème rencontré lors de ce processus est résolu en créant des utilitaires personnalisés ou en ajustant la configuration du service. Les problèmes rencontrés au cours du processus de vérification de service doivent également être discutés en détail avec le fournisseur de cloud.

Résumé

Un monde toujours actif dans le cloud comporte des risques inhérents. La complexité et l’impact des pannes nécessitent une attention particulière et ciblée. Une architecture d'application typique sur le cloud comprend de nombreux composants. La disponibilité d'une telle application est un agrégat de disponibilité pour tous les composants. Comprendre les points d’interaction, créer un mode de défaillance pour chaque scénario de défaillance possible lié à ce point d’interaction et tester chacun de ces scénarios pour en comprendre l’impact et élaborer des solutions pour remédier à ces lacunes peuvent améliorer considérablement l'efficacité de vos plans de reprise après sinistre. Chez Perficient, nous continuons à surveiller les technologies et les tendances du cloud. Nous comprenons les défis liés à l’adoption des technologies cloud et avons donc mis au point des solutions, plateformes, architectures et méthodologies cloud éprouvées pour faciliter la migration. Si vous souhaitez en savoir plus, contactez l'un de nos spécialistes à l'adresse suivante: sales@perficient.com

Références et liens

* «IDC,« DevOps et le coût des temps d'arrêt: statistiques Fortune 1000 de meilleures pratiques quantifiées » . ”Stephen Elliot. Décembre 2014, IDC # 253155 ”

https://www.forbes.com/sites/donnafuscaldo/2019/10/17/chime-suffers-outage-that-prevents-customers-from-making-purchases-accessing- cash / # 7e9e5c75ca3a

https://www.wired.com/story/feds-boeing-737s-better-design-humans/

https://www.ntsb.gov/investigations/AccidentReports/Reports/ ASR1901.pdf

ttps: //www.bleepingcomputer.com/news/technology/amazon-aws-outage-shows-data-in-the-cloud-is-not-always-safe/




Source link