Faire valoir que le site doit toujours être accessible est de mauvaises manières et de la banalité, mais l'accessibilité à 100%, bien que ce soit une condition préalable, est le plus souvent encore un idéal inaccessible. Maintenant, il existe de nombreuses solutions sur le marché qui promettent un temps de disponibilité maximal ou proposent des solutions pour l'augmenter, mais leur application n'est pas seulement toujours utile, dans certains cas, elle peut même entraîner des risques accrus et une accessibilité réduite du projet. Dans cet article, nous passerons en revue les erreurs classiques que nous rencontrons constamment. La plupart des problèmes sont élémentaires, mais les gens les autorisent encore et encore.
Préface nécessaire: avant d'essayer d'assurer la disponibilité maximale du projet, vous devez corréler les coûts et le coût des temps d'arrêt. Habituellement, cela est très important pour les entreprises dont le travail dépend du travail d'autres entreprises - solutions B2B, services API, services de livraison. L'inaccessibilité, ne serait-ce que quelques minutes, entraînera, au moins pour les clients mécontents, une charge sur le centre d'appels. Pour les entreprises d'un autre type, par exemple, une petite boutique en ligne ou une entreprise dont les clients travaillent de 9 à 18 ans, l'inaccessibilité même pendant plusieurs heures peut être moins chère qu'un site de sauvegarde complète.
1. Localisation de l'ensemble du projet dans un centre de données / une zone d'hébergement cloud
Le marketing d'hébergement cloud a fermement corrigé le mauvais concept dans la tête des gens: l'hébergement cloud n'est pas lié au matériel et cela signifie que l'infrastructure cloud ne tombera pas. Trois pannes d'Amazon Web Services de 24 heures, le récent crash de cloud4y et la perte de données de cloudmouse ont montré que la localisation des données et du projet lui-même dans un centre de données est un moyen garanti d'obtenir de nombreuses heures d'indisponibilité sans la possibilité de déplacer facilement le projet vers un autre site. À cet égard, la loi sur les données personnelles crée des problèmes supplémentaires. Nous pensons que tout hébergement cloud devrait passer par plusieurs accidents majeurs afin d'apprendre à les prévenir (foudre qui a frappé Amazon, problèmes de configuration réseau liés au facteur humain, etc.), et si l'hébergement cloud occidental a traversé cette série de catastrophes, alors de nombreux sites russes doivent encore le faire, et cela doit être pris en compte.
La situation est à peu près la même avec les centres de données «de fer». Souvent, nous voyons la configuration du client, où plusieurs serveurs sont réservés sur un site, au cas où l'un d'entre eux tombe en panne, cependant, selon notre expérience, il y a des problèmes de réseau lorsque plusieurs racks dans un centre de données ou l'ensemble du centre de données dans son ensemble deviennent inaccessibles se produisent beaucoup plus souvent que les pannes de serveur unique, et cela doit également être pris en compte.
Le flux de travail de projet recommandé par AWS implique l'utilisation de plusieurs zones de disponibilité par défaut pour obtenir une disponibilité maximale du projet.
2. Absence de duplication adéquate sur le site de la réserve
Donc, nous sommes arrivés à la conclusion banale sur la nécessité d'avoir un site de sauvegarde pour atteindre la disponibilité maximale du projet, cependant, pour y basculer, les données doivent être adéquates au site de production. L'important ici n'est pas la création initiale de la réserve - il s'agit d'une procédure assez simple et compréhensible, la synchronisation et le suivi de la synchronisation des modifications ultérieures étant beaucoup plus importants. Tout d'abord, nous parlons de:
- Configuration du cluster / synchronisation des données dans le cluster lorsque nous parlons d'un site complexe
- Synchronisation de la structure des fichiers et surveillance du retard de synchronisation
- Suivre les changements dans la configuration du serveur
- Débogage des processus de suivi et d'ajout à la synchronisation des nouveaux projets / services sur le site.
- Suivi de l'ajout de nouveaux services secondaires (nouvelles files d'attente, mécanismes de traitement et interactions, etc.).
- Surveillance continue adéquate de tous ces processus.
3. Absence de plan de changement et passage régulier à un site de sauvegarde
Aucune, même la meilleure surveillance, ne peut garantir que le site de sauvegarde sera prêt à basculer lorsque cela est vraiment nécessaire. D'après notre expérience, un accident se produira lors du premier passage à la réserve, et cela se reproduira plusieurs fois. Dans leurs rapports, Stack Overflow dit qu'il leur a fallu environ cinq permutations vers la réserve, avant d'être convaincus qu'il était désormais prêt à accepter du trafic après l'accident. Par conséquent, dans le plan de travail visant à augmenter le temps de disponibilité du projet, il est nécessaire d'inclure des interrupteurs d'essai dans la réserve et de tenir compte du fait que ces commutations entraîneront un accident. Après avoir travaillé et corrigé le mécanisme de commutation dans la documentation, vous devez continuer à passer régulièrement à la réserve afin de vous assurer que tout fonctionne toujours.
4. Localisation du site de réserve sur le même canal / dans la même région du cloud
Si les sites de production et de réservation sont au sein de la même société d'hébergement, il est fort possible qu'en cas d'accident, vos deux sites cessent de fonctionner immédiatement. Plusieurs accidents majeurs dans AWS ont immédiatement affecté toutes les zones de disponibilité d'une région, Selectel est tombé en même temps que les centres de données de Saint-Pétersbourg et de Moscou, les entreprises peuvent parler d'isolement complet, mais l'accident cloud4y, qui a conduit à l'inaccessibilité complète de Bitrix24 suggère que même dans de tels cas il y a de gros risques. L'idéal, de notre point de vue, est une configuration où une configuration de sauvegarde est située dans la même société d'hébergement (pour utiliser des moyens réguliers de basculer vers une réserve, comme VRRP ), et une plate-forme de sauvegarde secondaire dans une autre société d'hébergement.
5. Placement de versions identiques sur les sites principaux et de réserve.
Même l'utilisation d'un site de réserve vérifié et l'utilisation d'un site secondaire dans un autre centre de données ne garantissent pas que la réserve est prête à prendre rapidement en charge la charge de production. Cela est dû à l'essence de la redondance: une nouvelle version du code qui a créé une charge fatale sur l'environnement de production créera exactement la même charge sur le site de sauvegarde et le projet deviendra complètement inaccessible. Comme solution simple, il devrait y avoir un mécanisme pour revenir à la version précédente, cependant, dans la course aux versions commerciales, ce n'est pas toujours possible, puis nous commençons à penser à un autre site de sauvegarde avec la version précédente. Nous devrions également parler de sauvegarde : la suppression accidentelle de données sur le site principal affectera également le site de sauvegarde, vous devriez donc penser à la réplication retardée (pendant 15 minutes, par heure) afin de pouvoir basculer vers une base de données qui ne s'est pas encore produite opération fatale.
6. Dépendance à l'égard des services externes auxquels le projet accède.
Mais cela ne suffit pas. Un grand nombre de projets utilisent désormais des services externes pour fournir leurs propres services. La plupart d'entre eux utilisent SMS pour la double authentification, les boutiques en ligne calculent les délais de livraison à l'aide de services de livraison, le paiement est accepté via des passerelles de paiement tierces, et si ces services tombent, peu importe qu'il y ait une réservation ou non, le projet sera toujours indisponible. Nous voyons rarement réserver des services externes, mais, en attendant, ce sont exactement les mêmes projets qui peuvent avoir des problèmes avec le site de réserve, ou il peut n'y avoir aucune réserve du tout. Et si le service externe n'est pas disponible, l'entretien de vos clients sera également impossible. Nous vous recommandons de dupliquer tous les systèmes externes critiques, de surveiller leur disponibilité et d'avoir un plan pour les commuter en cas d'accident.
C'est loin d'être tout, mais au moins des choses basiques. Nous en discuterons plus en détail lors des réunions uptime.community , la prochaine aura lieu en octobre, mais pour l'instant vous pouvez discuter dans le groupe télégramme .