TL; DR: construction redondante, modulaire; tester la disponibilité; surveiller de près.
Après avoir réalisé qu'essayer de saisir une explication peut durer très longtemps, je vais donc noter toutes les observations que j'ai faites.
Questionner la prémisse
Le système cloud est la panacée
Même si vous deviez vous lancer pleinement dans le cloud, avec un fournisseur de cloud de premier plan, vous devrez toujours concevoir votre application pour la résilience, ce qui est le cas. AWS peut remplacer votre machine virtuelle, mais votre application doit pouvoir redémarrer si elle est laissée au milieu du calcul.
Nous ne voulons pas utiliser le système cloud, à cause de x / y / z
À moins que vous ne soyez une organisation de très grande taille, vous avez intérêt à utiliser des systèmes cloud. Les trois principaux systèmes cloud (AWS, MSFT, Google) emploient des milliers d'ingénieurs pour vous offrir les SLA promis et le tableau de bord facile à gérer. C'est en fait une bonne affaire pour les utiliser au lieu de dépenser un centime sur cette maison.
Problèmes de cadrage et de conception
Définir, quantifier puis mesurer en continu la disponibilité d'un service est un défi plus important que d'écrire une solution pour les problèmes de disponibilité.
Définir et mesurer la «disponibilité» est plus difficile que prévu
Plusieurs parties prenantes ont une vision différente de la disponibilité, et ce qui peut arriver, c'est que la définition préférée par une personne avec le salaire le plus élevé l'emporte sur une autre définition. C'est parfois une définition correcte, mais souvent l'écosystème n'est pas construit autour de la mesure de la même chose car cette définition idéale est beaucoup plus délicate à mesurer, et encore moins à surveiller en temps réel. Si vous avez une définition de la disponibilité qui ne peut pas être surveillée en temps réel, vous trouverez encore et encore votre propre projet similaire avec des similitudes étranges. Restez avec quelque chose qui a du sens et quelque chose qui peut être facilement surveillé.
Les gens sous-estiment la complexité du système toujours disponible.
Pour m'adresser à l'éléphant dans la pièce, permettez-moi de dire ceci: "Aucun système multi-ordinateur n'est disponible à 100%, il se peut qu'à l'avenir mais pas avec la technologie actuelle." Ici, par la technologie actuelle, je fais référence à notre incapacité à envoyer des signaux plus rapidement que la vitesse de la lumière et de telles choses. Tous les ingénieurs comp-sci dignes de ce nom connaissent les limites de l'informatique distribuée , et la plupart d'entre eux ne le mentionneront pas lors des réunions, craignant de ressembler à des noobs. Pour compenser tous ceux qui ne mentionnent pas les limitations de l'informatique distribuée, je dirai que c'est compliqué mais ne faites pas toujours confiance aux ordinateurs .
Les gens surestiment leurs capacités d'ingénieur
Malheureusement, la disponibilité tombe dans la catégorie, où vous ne savez pas ce que vous voulez mais vous savez ce que vous ne voulez pas. Il est un peu plus délicat que la catégorie «connaître les besoins» comme l'interface utilisateur. Il faut un peu d'expérience et beaucoup de lecture pour apprendre de l'expérience des autres et encore plus.
Construire un système disponible à partir de zéro
Assurez-vous que vous évangéliserez à chaque équipe d'architecture et de conception la bonne priorité de la disponibilité en tant qu'exigence du système.
Attributs du système favorisant la disponibilité
Les caractéristiques du système suivantes ont montré qu'elles ont contribué à la disponibilité du système:
Redondance
Certains exemples de cela sont de ne jamais avoir qu'une seule machine virtuelle derrière un VIP ou de ne jamais stocker qu'une seule copie de vos données. Ce sont les questions qu'un bon IAAS vous facilitera la tâche, mais vous devrez toujours prendre ces décisions.
Modularité
Un REST modulaire est meilleur qu'un SOA monolithique. Un microservice même modulaire est en fait plus disponible que le HATEOS REST habituel . Le raisonnement peut être trouvé dans la discussion relative au rendement dans la section suivante. Si vous effectuez un traitement par lots, mieux vaut un traitement par lots dans un lot raisonnable de 10 par rapport à un lot de 1 000 000.
Élasticité
"I am always angry"
- Hulk
Un système résilient est toujours prêt à récupérer. Cette résilience s'applique à des instances telles que la reconnaissance d'un ACK pour une écriture uniquement après l'écriture sur un disque RAID, et éventuellement sur au moins deux centres de données. Une autre tendance récente consiste à utiliser des structures de données sans conflit , où la structure de données assume la responsabilité de résoudre les conflits lorsqu'elle est présentée avec deux versions différentes. Un système ne peut pas être résilient après coup, il doit être prévu et intégré. Un échec est garanti sur le long terme, nous devons donc toujours être prêts avec un plan de redressement.
Sentier des journaux
C'est techniquement un sous-type de résilience, mais très spécial car il capture toutes les capacités. Malgré tous les efforts, nous ne pouvons peut-être pas prédire le modèle d'indisponibilité. Si possible, conservez suffisamment de journal des activités système pour pouvoir lire les événements système. Cela, à un coût manuel élevé, vous permettra de vous remettre de situations imprévues.
Attributs de disponibilité
La liste d'attributs non exhaustive de la «disponibilité»: Pour la discussion, supposons que la question que l'utilisateur pose est: «Combien d'articles ai-je dans mon panier?»
Exactitude
Avez - vous devez produire la réponse la plus précise possible ou est - ce ok faire des erreurs? Juste pour référence, lorsque vous retirez de l'argent à un guichet automatique, il n'est pas garanti qu'il soit correct. Si la banque découvre qu'elle a fait une erreur, vous pourriez annuler les transactions. Si votre système produit des nombres premiers, alors je suppose que vous voudrez peut-être toujours les bonnes réponses.
rendement
Ignorez ce point, si vous avez toujours répondu correctement à la question précédente. Parfois, la réponse aux questions n'a pas à être précise, par exemple, combien d'amis ai-je sur Facebook en ce moment? Mais la réponse devrait être dans le stade +/- 1 tout le temps. Lorsque vous produisez le résultat attendu, votre rendement est de 100.
Cohérence
Votre réponse peut être correcte à un moment donné, mais au moment où la lumière a quitté l'écran et est entrée dans la rétine de l'observateur, les choses auraient pu changer. Cela rend-il votre réponse fausse? Non, cela rend tout simplement incohérent. La plupart des applications sont finalement cohérentes, mais l'astuce consiste à définir le type de modèle de cohérence que votre application va fournir. Par hasard, votre application peut fonctionner sur un seul ordinateur, vous pouvez ignorer cette belle lecture sur le théorème de CAP .
Coût
Beaucoup dépend de l'impact total des effets à court terme (perte de revenus) et des effets à long terme (mauvaise réputation, fidélisation de la clientèle). Selon le type de client (payant / gratuit, répété / unique, captif) et la disponibilité des ressources, différents niveaux de garanties de disponibilité doivent être intégrés.
Vers l'amélioration de la disponibilité d'un système existant
La gestion opérationnelle des machines individuelles et d'un réseau est si complexe que je suppose que vous l'avez laissé au fournisseur de cloud ou que vous êtes déjà suffisamment expert pour savoir ce que vous faites. Je toucherai d'autres sujets sous disponibilité. Pour la stratégie à long terme, Définir-Mesurer-Analyser-Contrôler est un match paradisiaque, quelque chose que j'ai vu moi-même.
- Définissez ce qu'est la «disponibilité» pour vos parties prenantes
- Comment allez-vous mesurer ce que vous avez défini
- Analyse des causes profondes pour identifier les goulots d'étranglement
- Tâches d' amélioration
- Surveillance continue ( contrôle ) du système
Causes de non-disponibilité
Puisque nous avons convenu que la gestion opérationnelle, qui couvrirait toute gestion d'infrastructure physique, devrait être effectuée par des professionnels, je toucherai à d'autres causes d'indisponibilité pour des raisons d'exhaustivité. La disponibilité de l'OMI doit également inclure le manque de comportement attendu, ce qui signifie que si l'utilisateur ne voit pas l'expérience attendue, alors quelque chose n'est pas disponible. Avec cette définition large à l'esprit, les éléments suivants pourraient entraîner une indisponibilité: - Bogues de code - Incidences de sécurité - Problèmes de performances