Pourquoi les sites Web (même celui-ci) sont-ils parfois "en panne pour maintenance"?
Personnellement, je ne l'ai jamais fait. Je ne comprends pas pourquoi tant de sites le font, si vous faites votre développement sur un serveur de développement, pourquoi auriez-vous besoin de fermer votre site de production?
Je me suis toujours posé des questions à ce sujet.
Que font-ils pendant ce temps, que faut-il faire?
Le gros coup de pouce pour tout ce qui est à grande échelle est que si l'on modifie les schémas de base de données d'une manière ou d'une autre, on a généralement de gros scripts de maintenance à exécuter.
Maintenant, cela peut prendre une seconde environ pour s'exécuter avec votre jeu de données de développement. Mais lorsque vous commencez à mesurer des données en téraoctets et en pétaoctets, même l'ajout d'une seule colonne à une table peut prendre des heures.
Donc, quelle que soit la rapidité et l'automatisation du déploiement, vous avez toujours des problèmes de maintenance des données à résoudre. Si vous planifiez très bien, vous pouvez mettre en place un miroir en lecture seule du site pendant que vous suivez le processus, mais pour de nombreux sites, la lecture seule est inutile et ne vaut donc pas la peine.
Il existe un certain nombre de raisons pour lesquelles vous souhaiterez peut-être supprimer un site pour maintenance. Pour n'en nommer que quelques-uns:
- Modifications de la base de données
- Modifications DAL
- Mise à jour des services
Fondamentalement, si votre site n'est pas statique, lorsque vous effectuez une mise à jour logique, vous souhaitez le supprimer, sinon les personnes qui visitent votre site peuvent recevoir des erreurs ou un comportement inattendu.
De plus, si vous touchez le web.config (dans ASP.NET) pour votre site, vous devez d'abord le retirer pour maintenance car il fera exploser la session pour les utilisateurs. Ainsi, s'ils étaient au milieu de quelque chose, cela serait perdu.
Eh bien, c'est en quelque sorte une question abstraite - j'ai même vu des sites qui utilisaient "Down for Maintenance" au lieu de HTTP 500.
Pour les sites Web, vous devez parfois effectuer une mise à niveau. Par exemple, si vous changez de base de données, vous ne voulez pas qu'un autre utilisateur touche la base de données pendant cette période. Si la base de données est hors ligne, le site doit également être gracieusement désactivé, car afficher SqlException n'est pas très agréable. Une autre raison est une défaillance matérielle ou une défaillance du système (comme une fuite de ressources) qui nécessite un redémarrage de l'application ou même du système.
Une fois, j'ai participé à la mise à niveau du système bancaire Internet dans l'une des plus grandes banques de mon pays. L'ensemble du processus de mise à niveau des sites Web, du niveau intermédiaire et des bases de données a pris trois jours lorsque le système était hors ligne pour les clients. Il comprenait également une sauvegarde complète de tout, donc en cas de panne, le système pourrait être rétabli à l'ancienne version.
Les serveurs ont besoin de correctifs pour être exécutés et sur de nombreux systèmes d'exploitation, ces correctifs nécessitent des redémarrages. C'est donc une catégorie de temps d'arrêt. De nombreuses entreprises planifient des redémarrages à partir de correctifs pour des durées d'utilisation réduites, comme le dimanche matin. S'il n'y a pas de correctifs, ils redémarrent quand même les serveurs à l'heure de maintenance régulière (c'est une gueule de bois des jours NT4 lorsque certains compteurs débordaient chaque semaine et demie, donc le redémarrage hebdomadaire a évité d'autres bogues).
À la fin des années 90, une entreprise pour laquelle je travaillais avait un site de commerce électronique qui rapportait plus de 1 000 000 $ de ventes par mois. Quelqu'un a promu la mauvaise table de taxe sur le serveur de base de données de production. Le remède consistait à restaurer le serveur db à partir de la sauvegarde et à appliquer les transactions depuis la dernière sauvegarde. Cela a pris plusieurs heures, pendant lesquelles le site Internet n'était pas disponible pour prendre les commandes. Étant donné que la partie commandes et les brochures de vente statiques fonctionnaient sur le même site et étaient inséparables, les deux ont dû baisser.
Une entreprise pour laquelle je travaillais avait un mauvais texte inséré au mauvais endroit et le PDG a été déplacé et a mis le site Web hors ligne "pour maintenance" tandis que la mise en page et le texte étaient "corrigés" et la victime appropriée blâmée et licenciée.
Bien que les autres réponses soient correctes, vous pouvez presque toujours éviter les temps d'arrêt en utilisant les bonnes architectures. Mais cela a un coût, et ce coût n'en vaut peut-être pas la peine: une heure d'indisponibilité coûte beaucoup à Amazon ou à l'infrastructure derrière le NASDAQ. Stackoverflow? Probablement pas tant que ça.
Comment éviter les temps d'arrêt:
- fermeture des pages de diffusion de matériel: si vous avez des proxys devant votre site Web, vous pouvez les mettre hors ligne à la place sans aucun impact sur l'utilisateur
- reconfiguration des serveurs: comme ci-dessus
- mise à jour/modification des données dans les bases de données: vous pouvez mettre votre site en lecture seule, etc ...
Généralement, dans une architecture en couches, plus vous êtes proche du "haut", plus il devient difficile d'éviter les temps d'arrêt, même pour les états (serveur Web vs base de données).
Il y a aussi un aspect psychologique et marketing à cela. Dans certains cas (j'ose dire la plupart des cas mais je ne suis pas si gras * g *), lire "Arrêt pour maintenance" peut également signifier "Le serveur est tombé en panne ou a été mis hors service pour toute autre raison".
Je l'ai vu assez souvent. Normalement, en tant que développeur, vous voudrez un "vrai" message d'erreur disant quelque chose comme "Oups, nous rencontrons une charge élevée en ce moment et toutes les demandes ne peuvent pas être traitées" mais certaines personnes du marketing vous diront "mec, vous ne pouvez pas Dites au client que nous avons un problème. Dites-lui que nous sommes en maintenance programmée - cela sera beaucoup mieux ".
Ainsi, "Arrêt pour maintenance" n'est souvent qu'un autre terme pour "hors service".
Un site peut planifier des temps d'arrêt réguliers même s'il n'y a rien à faire à chaque fois que le temps d'arrêt prévu se produit. Ce faisant, ils habituent les utilisateurs à l'idée que le site sera en panne pendant un certain temps de temps en temps, de sorte que lorsque le travail ne doit être fait, les utilisateurs ne se plaindront pas autant .
Aucun serveur n'a besoin de descendre pour maintenance. Vous pouvez éviter de le faire pour n'importe quoi, à n'importe quelle échelle, changement de base de données, mises à jour de serveur, etc.
Le problème est qu'un système à 0 temps d'arrêt, à une certaine échelle, est très coûteux à créer et à maintenir. Vous avez besoin de redondance partout, d'équilibrage de charge partout, de réplication des données, de synchronisation. Ce sont des problèmes difficiles.
Fondamentalement, vous devez arriver au niveau de pouvoir libérer le Netflix Chaos Monkey en prod pour être sûr que cela fonctionne même si une partie de votre système est occupée par la mise à jour, ou tout simplement désynchronisée. C'est certainement faisable. Il est également très coûteux, nécessite beaucoup de temps et de nombreux experts pour travailler sur le problème.
Mettre un site en mode maintenance peut être un terrain d'entente que vous choisissez, car vous ne voulez pas investir autant pour éviter de supprimer votre site pendant un certain temps de temps en temps.
Économie.
Bien sûr, si vous choisissez la route du temps d'arrêt, votre site gagnera plus que la simple disponibilité, il gagnera également en fiabilité, car ces meilleures pratiques servent les deux objectifs.
Je ne comprends pas pourquoi tant de sites le font, si vous faites votre développement sur un serveur de développement, pourquoi auriez-vous besoin de fermer votre site de production?
La merde arrive. À moins que vous ne fassiez une vérification mathématique de vos livrables ( et que vos spécifications soient valides ), peu importe votre prudence, la merde se produit.
En outre, il peut arriver que vous deviez modifier un élément clé de votre infrastructure (par exemple, une modification des structures de votre base de données) qui nécessitent un temps d'arrêt.
À moins que vous ne développiez un système critique (disons un système cinq-neuf ou six-neuf ), la chose responsable et rentable à faire est de construire un système avec l'acceptation des temps d'arrêt dans le cadre de la réalité.
De plus, vous allez plus loin dans ce principe en rendant les temps d'arrêt gérables et faciles à planifier (ou au moins détectables) avec une compréhension et une procédure claires pour une récupération efficace.