Je n'ai fait que parcourir sa thèse qui est surement passionnante, mais j'ai l'impression qu'il ne s'attache qu'à l'aspect logiciel. Or un système d'information c'est beaucoup plus que celà. Et quand on parle de haute disponibilité il faut prendre en compte toutes les composantes du SI sous peine d'avoir effectué un boulot aussi faramineux qu'inutile.
En bref et pour répondre à Djinns, je lui conseillerai comme démarche d'identifier dans un 1er temps toutes les composantes du SI: postes clients, matériels serveurs, réseaux, logiciels, load-balancing, procédures de backups, etc., redondance à tous les niveaux y compris pour les processus humains (et oui le SI n'est pas toujours 100% automatisé). Ensuite d'étudier chacune des ces composantes et d'y détecter les failles et les moyens d'y remédier. Ce n'est qu'après cette phase d'étude que l'on peut proposer une véritable stratégie.
Car un serveur ou un switch qui tombe en rade ce n'est pas bien grave s'il y a un équipement de répartition de charge en amont. Mais les plus anciens se rappeleront par exemple l'incendie d'une banque dont je tairais le nom où le plan de reprise d'activité (PRA pour les + agés) avait permis une interruption de quelques heures seulement.
Bel exemple d'un plan sécurité correctement mis en oeuvre.
[^] # Re: La thèse de Joe Armstrong
Posté par Raoul Volfoni (site web personnel) . En réponse au journal La haute disponibilité. Évalué à 5.
Je n'ai fait que parcourir sa thèse qui est surement passionnante, mais j'ai l'impression qu'il ne s'attache qu'à l'aspect logiciel. Or un système d'information c'est beaucoup plus que celà. Et quand on parle de haute disponibilité il faut prendre en compte toutes les composantes du SI sous peine d'avoir effectué un boulot aussi faramineux qu'inutile.
En bref et pour répondre à Djinns, je lui conseillerai comme démarche d'identifier dans un 1er temps toutes les composantes du SI: postes clients, matériels serveurs, réseaux, logiciels, load-balancing, procédures de backups, etc., redondance à tous les niveaux y compris pour les processus humains (et oui le SI n'est pas toujours 100% automatisé). Ensuite d'étudier chacune des ces composantes et d'y détecter les failles et les moyens d'y remédier. Ce n'est qu'après cette phase d'étude que l'on peut proposer une véritable stratégie.
Car un serveur ou un switch qui tombe en rade ce n'est pas bien grave s'il y a un équipement de répartition de charge en amont. Mais les plus anciens se rappeleront par exemple l'incendie d'une banque dont je tairais le nom où le plan de reprise d'activité (PRA pour les + agés) avait permis une interruption de quelques heures seulement.
Bel exemple d'un plan sécurité correctement mis en oeuvre.