une chaussure a une durée de vie de quelques années et un temps moyen de panne de plusieurs milliers d’années : il n’y a qu’une chance sur mille de devoir changer sa chaussure avant d’avoir atteint la phase d’usure (le taux de panne prend son sens sur un échantillon d’un million de chaussure).
Dans la pratique, les serveurs informatiques produisent des disponibilités qui vont de 99.9% pour des matériels bas de gamme à 99.99% pour des serveurs haut de gamme. La corrélation avec le prix est une approximation, il y a des matériels chers et fragiles, ainsi que des serveurs Intel Windows ou LINUX (serveurs d’ « entrée de gamme ») avec de très bonnes disponibilités. Il y a presque un ordre de grandeur de différence entre ces chiffres qui reflètent « la vraie vie » et ce qui est observé en laboratoire et qui est publié dans les brochures. N’étant pas un spécialiste du hardware, je ne peux que me hasarder à deux conjectures pour expliquer cette différence. Premièrement la charge et les conditions de charge (température, mode de fonctionnement, etc.) sont plus régulières en laboratoire que dans la vraie vie. Deuxièmement le « MTTR pratique » est plus long que le MTTR de laboratoire qui est proche du MTTR théorique (dans la vraie vie, il y a les week-ends, les mauvais diagnostics, les pièces en rupture de stock, les encombrements, etc.).
http://www.zdnet.com.au/news/hardware/soa/Windows-Server-reliability-crashes-in-2007/0,130061702,339288227,00.htm
http://satc.gsfc.nasa.gov/support/ISSRE_NOV98/software_metrics_and_reliability.html
http://www.softrel.com/Current%20defect%20density%20statistics.pdf
http://www.sans.org/top25errors/print.pdf
Il s’agit des 25 erreurs de programmation les plus graves/classiques/ennuyeuses lorsqu’on développe.
La durée maximale d'interruption admissible, en anglais Recovery Time Objective (RTO) constitue le temps maximal acceptable durant lequel une ressource (généralement informatique) peut ne pas être fonctionnelle après une interruption majeure de service.
Le RTO est considéré en conjonction avec le Recovery Point Objective (RPO) qui quantifie la capacité de reprise sur sauvegarde de la ressource. L'ensemble permet de déterminer le temps total d'interruption d'une ressource après un incident majeur.
Ce délai d'interruption de service se décompose en :
Délai de détection de l'incident
Délai de décision du passage en secours (s'il n'est pas automatique)
Délai de mise en oeuvre des procédures de secours (aiguillage réseau, restauration des données...)
Délai de controle + relance de l'application
La somme de ces délais doit en théorie être inférieure au RTO.
La Perte de Données Maximale Admissible, en anglais Recovery Point Objective (RPO) est la durée maximale entre la dernière sauvegarde d'une ressource et un incident majeur provoquant la perte des données. Elle quantifie les données que l'exploitation informatique peut être amenée à perdre.
Concrètement, elle est déterminée par la fréquence et la nature des sauvegardes (ou réplications, ...) effectuées sur les ressources informatiques.
Le RPO est utilisé dans le cadre de développement des Plans de Continuité d'Activité et Plans de Reprise d'Activité, de même que le Recovery Time Objective (RTO).
Note: les tests se font aussi après la mise en prod
http://en.wikipedia.org/wiki/Fault_tolerant
Fault-tolerance or graceful degradation is the property that enables a system (often computer-based) to continue operating properly in the event of the failure of (or one or more faults within) some of its components. If its operating quality decreases at all, the decrease is proportional to the severity of the failure, as compared to a naively-designed system in which even a small failure can cause total breakdown. Fault-tolerance is particularly sought-after inhigh-availability or life-critical systems.
la valeur d’usage : lorsqu’une application est indisponible, il y a une perte économique,
la valeur d’image : la qualité de service participe à la satisfaction globale du client et contribue à créer une image positive,
la valeur d’efficacité : l’entreprise optimise le fonctionnement nominal de ses processus ; la dégradation de la QoS entraîne une déviation par rapport au déroulement nominal qui se traduit par une perte de productivité.
Pourquoi externaliser : parce qu’on fait mieux si on fait souvent et en grand
Dans la plupart des désastres qui ont été analysés, les problèmes qui sont à l’origine de la crise sont connus, et ont été bloqués par des raisonnements approximatifs ou des décisions douteuses de management : l’intégrité du professionnel des systèmes d’information consiste à ne pas laisser les messages d’alerte se perdre.
La plupart des problèmes sont causés par des changements. Si le changement fait partie de la vie de l’entreprise, l’intégrité peut signifier savoir résister à un rythme qui n’est pas raisonnable.
Les « règles de l’art » doivent être appliquées, la construction du plan de secours étant un parfait exemple. Les règles de l’art sont la seule protection contre la recherche d’un coupable lors d’une crise grave, puisqu’il n’existe pas de méthode absolue de fiabilisation.
Les tests ne sont utiles que s’ils sont appliqués. Comme cela a été souligné, tous les ouvrages ou témoignages sur la fiabilisation, sans exception, insistent sur le rôle des tests. Il faut une véritable intégrité pour conduire les plans de test sous situation de stress liée au délai, et pour imposer le test de l’ensemble des composants, y compris le plan de secours.