Pourquoi les sites Web (même celui-ci) sont-ils parfois «Down for Maintenance»?


36

Personnellement, je n'ai jamais fait ça. Je ne comprends pas pourquoi tant de sites le font. Si vous développez sur un serveur de développement, pourquoi auriez-vous besoin de fermer votre site de production?

Je me suis toujours demandé à ce sujet.

Que font-ils pendant ce temps, qu'est-ce qui nécessite de faire ça?


56
Ils remplacent les tubes à vide dans les serveurs.
Mipadi

11
Je pensais qu'ils empilaient les cartes perforées.
Christopher Mahan

5
Gardez à l' esprit que le site probablement ne reste pour la plupart des mises à jour. De toute évidence, vous ne voyez que ceux qui doivent être déconnectés pendant un certain temps.
Dean Harding

4
Personne n'a abordé une raison de sécurité; il pourrait y avoir un exploit connu (une personne ayant publié comment exploiter certains sites Web) et les administrateurs le mettent hors ligne pour limiter les abus des autres parties tout en le corrigeant.
Francisco Presencia

1
Je me pose la question suivante: "Quelles stratégies puis-je utiliser pour atteindre zéro temps d'immobilisation (prévu) dans une application Web sauvegardée avec une base de données?" Mises à niveau spécifiques nécessitant des modifications de schéma de base de données: softwareengineering.stackexchange.com/questions/336945/…
Stephen

Réponses:


59

Le plus gros avantage pour tout ce qui a une 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 doit généralement exécuter de gros scripts de maintenance désagréables.

À présent, ils peuvent prendre une seconde ou deux 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 colonne à une table peut prendre des heures.

Ainsi, peu importe la rapidité et l'automatisation du déploiement, vous avez toujours des problèmes de maintenance des données à résoudre. Si vous planifiez vraiment bien, vous pouvez placer 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.


3
+1 - un débordement de pile en lecture seule ne serait pas très utile. Vous ne trouverez pas grand-chose que vous ne pourriez pas trouver sur Google :)
corsiKa

10
@glowcoder: Lorsque vous effectuez une recherche sur Google, vous trouvez SO réponses.
Donal Fellows

@Donal c'était exactement ce que je voulais dire.
CorsiKa

1
Google est massif et sûr d'avoir une base de données massive; comment se fait-il que je ne voie jamais "en maintenance" pour google? (Page d'accueil Google.com)
alexyorke Le

7
@ alexy13 - Google est dans une catégorie d'échelle spéciale dans laquelle ils ne peuvent pas avoir une seule base de données ni même un centre de données, certaines parties du système sont toujours en panne et ils ont écrit le front-end pour le gérer. Je le ferais aussi si vous me donniez ce genre de temps et de budget de R & D.
Wyatt Barnett

7

Il existe un certain nombre de raisons pour lesquelles vous pourriez vouloir retirer un site pour la maintenance. Pour en nommer quelques uns:

  • Changements de base de données
  • Changements de DAL
  • Mise à jour des services

Fondamentalement, si votre site n'est pas statique, vous souhaitez le supprimer lorsque vous effectuez une mise à jour logique, sinon les personnes qui consultent votre site risquent de recevoir des erreurs ou un comportement inattendu.

De plus, si vous voulez toucher le fichier web.config (en ASP.NET) de votre site, vous devez d'abord le désactiver pour maintenance, car la session des utilisateurs sera supprimée. Ainsi, s'ils étaient au milieu de quelque chose, ce serait perdu.


2
la session serait perdue si vous utilisiez l'état de session "En cours de traitement". Si vous utilisez l'état de session en dehors du processus, la session ne sera pas perdue si le fichier web.config est modifié.
Anthony

2
Le dernier point n’est vrai que si vous participez à des sessions en cours de traitement, et j’espère que vous n’êtes pas sur un site de production! Il ne suffit pas de toucher à la configuration web pour arrêter le processus de travail.
Dean Harding

7

Eh bien, c’est une question quelque peu 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 des mises à 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 désactivé car l'affichage de 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 le redémarrage de l'application ou même du système.

Une fois, j’ai participé à la modernisation 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 incluait également une sauvegarde complète de tout, afin qu'en cas de panne, le système puisse revenir à l'ancienne version.


2
HTTP 503 (au lieu de 500) n’est-il pas le code de statut correct pour "arrêté pour maintenance"?
Nubok

4

Les serveurs ont besoin de correctifs pour s'exécuter et, sur de nombreux systèmes d'exploitation, ces correctifs nécessitent un redémarrage. 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 faibles, telles que le dimanche matin. S'il n'y a pas de correctifs, ils redémarrent quand même les serveurs à l'heure de maintenance programmée (c'est la gueule de bois des jours NT4 où certains compteurs débordaient toutes les semaines et demie, donc le redémarrage hebdomadaire évitait d'autres bugs).

Une entreprise pour laquelle je travaillais avait un site de commerce électronique à la fin des années 90 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. La solution consistait à restaurer le serveur de base de données à partir d'une sauvegarde et à appliquer les transactions depuis la dernière sauvegarde. Cela a pris plusieurs heures, pendant lesquelles le site Web n'était pas disponible pour prendre des 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û être supprimées.

Une entreprise pour laquelle je travaillais avait un texte erroné inséré au mauvais endroit et le PDG a basculé et le site Web a été mis hors service "pour maintenance", tandis que la mise en page et le texte étaient "corrigés" et la victime appropriée blâmée et renvoyée.


Même ceci peut être atténué avec un bon équilibrage de la charge
Voycey

4

Tandis que les autres réponses sont 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 peut ne pas en valoir la peine: une heure d'indisponibilité coûte beaucoup à Amazone ou à l'infrastructure derrière NASDAQ. Stackoverflow? Probablement pas tellement.

Comment éviter les temps d'arrêt:

  • fermeture des pages de service du matériel: si vous avez des mandataires devant votre site Web, vous pouvez les mettre hors ligne sans aucun impact pour l'utilisateur.
  • reconfiguration des serveurs: comme ci-dessus
  • mise à jour / modification de données dans des bases de données: vous pouvez mettre votre site Web en mode lecture seule, etc.

En règle générale, dans une architecture en couches, plus vous êtes proche du "sommet", plus il devient difficile d'éviter les temps morts, de même pour l'étatful (serveur Web / base de données).


4
NASDAQ ne dispose-t-il pas environ 14 heures par jour d'indisponibilité?
Peter Taylor

3

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 planifié arrive. Ce faisant, ils habituent les utilisateurs à l’idée que le site sera hors service pendant un certain temps de temps en temps, de sorte que les utilisateurs ne se plaindront pas beaucoup quand il leur faudra travailler .


il existe un remède pour cela: abaisser le système de traitement des plaintes pendant les périodes d'inactivité :) J'ai en fait vu des entreprises le faire. Une entreprise de MMO qui supprime le site Web hébergeant l’annonce des temps morts, ainsi que les forums de support ainsi que la maintenance du jeu, en est un bon exemple. Toute personne qui n'a pas entendu l'annonce au cours des quelques heures écoulées avant que la maintenance ne sache jamais ce qui se passait.
Jwenting

3

Il y a aussi un côté psychologique et marketing à cela. Dans certains cas (j'ose dire la plupart des cas, mais je ne suis pas si audacieux * g *), lire "Arrêt pour maintenance" peut également signifier "Le serveur est tombé en panne ou est hors service pour une autre raison".

J'ai vu cela assez souvent. Normalement, en tant que développeur, vous voudrez un "vrai" message d'erreur disant "Oups, nous subissons actuellement une charge énorme et toutes les demandes ne peuvent pas être traitées", mais certaines personnes du marketing vous diront que "mec, vous ne pouvez pas Dites au client que nous avons un problème. Dites-lui que nous sommes en maintenance programmée - cela aura l'air beaucoup mieux ".

Donc, "Down for maintenance" n'est souvent qu'un autre terme pour "hors service".


2

Aucun serveur NE DOIT être arrêté pour maintenance. Vous pouvez éviter de le faire pour n'importe quoi, à n'importe quelle échelle, modification de base de données, mises à jour de serveur, etc.

Le problème est qu’un système sans 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 de données, de synchronisation. Ce sont des problèmes difficiles.

Pour être sûr que cela fonctionne même si une partie de votre système est occupée par la mise à jour, ou juste désynchronisée, vous devez être capable de libérer le monstre Netflix Chaos Monkey. C'est certainement faisable. C'est également très coûteux, cela prend beaucoup de temps et de nombreux experts pour travailler sur le problème.

Placer un site en mode de maintenance peut être un moyen terme que vous choisissez, car vous ne voulez pas investir autant, vous éviterez de détruire votre site pendant un certain temps de temps en temps.

Économie.

Bien sûr, si vous choisissez la route du zéro, votre site gagnera bien plus que la disponibilité, il gagnera également en fiabilité, puisque ces meilleures pratiques servent les deux objectifs.


0

Je ne comprends pas pourquoi tant de sites le font. Si vous développez sur un serveur de développement, pourquoi auriez-vous besoin de fermer votre site de production?

Merde arrive. Merde, à moins que vous ne fassiez une vérification mathématique de vos livrables ( et que vos spécifications soient valides ), quelle que soit votre prudence.

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écessite un temps d'arrêt.

Sauf si vous développez un système critique (disons un système à cinq ou neuf ou neuf ), la chose responsable et rentable à faire est de construire un système avec l'acceptation des temps d'arrêt comme faisant partie de la réalité.

En outre, vous allez plus loin dans ce principe en rendant les temps d'arrêt gérables et faciles à programmer (ou au moins détectables) avec une compréhension et une procédure claires pour une récupération efficace.


1
La vérification mathématique n'est pas une panacée non plus; Parfois, vous trouvez que ce que vous avez vérifié n'est pas ce que vous vouliez vérifier.
Donal Fellows

Vrai. Mais ensuite, je dirais que le problème ne réside pas dans la vérification formelle des spécifications, mais dans la validation de ces spécifications. Si vos spécifications ne sont pas valides, il est évident que tout va se dégrader, mais la validation des spécifications ( "construisons-nous vraiment le bon outil dont l'utilisateur prévu a besoin pour le but recherché" ), ce n'est pas l'objet de la vérification (* "étant donné ces caractéristiques, construisons-nous cette chose correctement, ou pouvons-nous la construire? "), informelle ou autre. Je suppose que j'aurais dû mettre une mise en garde à ce sujet (en ce qui concerne la validité des spécifications.)
luis.espinal

Je ne dis pas que vous avez tort de le mentionner. Je souligne simplement qu'il y a des limites à ce qu'il peut faire. J'avais l'habitude de travailler sur la vérification formelle, et le gros problème à l'époque était de savoir comment faire évoluer correctement les spécifications afin de prendre en compte l'évolution de la compréhension des exigences. Puisqu'il s'agit principalement d'un problème humain, secondairement d'un problème d'ingénierie, et uniquement tertiaire, d'un problème mathématique, je ne pense pas qu'il ait été complètement résolu.
Donal Fellows

Oh. Je pense que nous sommes alors comme penser. Les exigences changeantes (et la validation requise) sont le talon d’Achille des méthodes formelles. Puisqu'il s'agit d'une tâche créative (en raison de sa nature humaine), je ne crois pas qu'elle soit résoluble, pas comme le voudraient les formalistes / les puristes . Je pense que cela a été l’une des promesses manquées de FM; ils ont été survendus (je veux dire, par exemple, des méthodes formelles de développement Web ?). Les spécifications doivent être scrupuleusement examinées et ne doivent pas pouvoir être modifiées rapidement (c'est typique des systèmes critiques et non très malléables). Les derniers sont la norme plutôt que l'exception.
luis.espinal

99% des interfaces utilisateur ne concernent pas les méthodes formelles, mais plutôt la psychologie appliquée. Les preuves restantes sont évidentes («ne bloquez pas l'interface utilisateur») même si ce n'est pas toujours évident de prouver. Mais si vous avez séparé l'application Web en fonction des meilleures pratiques, les méthodes formelles auront alors beaucoup de sens dans la couche Méthodes de gestion (également dans la couche de stockage de données), mais c'est généralement là que le conseil standard «n'écrivez pas votre propre DB ”s'applique quand même. :-))
Donal Fellows Le

-2

Une fois que notre site Web a été piraté (ancien serveur IIS6 et Windows 2003 il y a quelques années). pendant que nous travaillions sur la restauration, nous avons mis la page "sous maintenance" pendant quelques heures ...

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.