Berbe a dit:

Paradoxalement, les plus gros sites Web sont devenus les moins disponibles. Un CDN, c’est bien, mais un CDN redondé c’est mieux… et d’un seul coup les rapports bénéfice/risque & bénéfice/coût ont une autre allure.

Les circuits de secours sont toujours vus comme superfétatoires lorsqu’il s’agit de justifier leur coût, et ça couine quand finalement ils auraient bien été nécessaires. Cas d’école d’une mauvaise gestion de risques : les œufs dans le même panier pour limiter les coûts d’une décision prise sans vue d’ensemble.

Je te trouve bien catégorique. Ces sites n’ont jamais affirmé nulle part garantir un uptime. Les contrats entre grosses boîtes (puisque tu parles spécifiquement des “plus gros sites web”) et gros fournisseurs impliquent en général des SLAs et assurances complémentaires pour couvrir les pertes d’exploitation, c’est aussi une façon de gérer le risque. En l’absence d’accès à l’administratif des entreprises touchées, rien ne permet d’affirmer que ce downtime ne fait pas partie de leur modèle de risque acceptable.
J’ai l’impression que tu confonds “gérer les risques” et “assurer une disponibilité totale”. Mais ça n’a rien à voir. Tant que la durée de dowtime coûte moins cher que ce qu’il aurait fallu pour l’éviter et reste dans une fourchette anticipée, le risque est géré correctement.

Évidemment je parle de risque financier, parce qu’on parle de plateformes commerciales.

Elles ont été indisponibles 1h, ce qui est largement dans les marges de tolérances. Améliorer la disponibilité, ce n’est pas une opération linéaire en termes de coûts, c’est une exponentielle, les derniers pouillèmes de pourcent à eux seuls sont plus chers que quasiment l’ensemble de la couverture précédente.

Je travaille dans une très grosse boîte et j’opère un grand nombre de sites e-commerce. Nous avons un contrat avec un seul CDN, et un prestataire cloud pour l’infra. Évidemment tout est backupé dans plusieurs data centers (et tous les sites ne tournent pas dans le même) et nous avons une procédure, testée, qui nous permet de tout remonter si ça plante.
Mais ce remontage se fait forcément “à froid”, on a donc un incompressible de 1 à quelques heures pour retrouver une activité dans le cas où un datacenter aurait sauté.
Le seul moyen pour battre ce gap de dispo, ce serait de pouvoir remonter “à chaud”, et donc d’avoir un full miroir toujours up, dimensionné pour encaisser le pic de transition de tout le traffic si nécessaire. Ça reviendrait à augmenter nos coûts d’infra d’un bon 50%, juste pour gagner 1h ou 2 dans le rare cas où on aurait un datacenter qui chute. (c’est arrivé une fois en 7 ans)
Pour des sites de vente en ligne.

J’ai vraiment besoin d’expliquer en quoi ce serait absurde de mettre une telle débauche de moyens (ça cuberait en millions d’euros) pour un gain de dispo aussi ridicule ? (1h de dispo gagnée sur 7 ans…)

Un bon modèle de risque est un modèle qui reste réaliste par rapport à la criticité des services considérés. Est-ce flouer mes utilisateurs de m’autoriser la possibilité d’un downtime ? Je ne pense pas.

Évidemment, si j’opérais l’infra du réseau électrique, des services hospitaliers ou des numéros d’urgence (hem…), le modèle de risque serait entièrement différent.

A mon sens la position que tu sembles défendre comme quoi tout service quel que soit sa nature devrait à ses utilisateurs une dispo 100% à tout prix n’a pas de sens, ce serait juste un gaspillage de ressources monstrueux.
Pour une plateforme commerciale non-essentielle, il est tout à fait normal d’intégrer le risque de dispo dans le cadre financier.
Pour un service essentiel, la disponibilité devrait primer, mais ici ce n’est pas le contexte.