SlideShare uma empresa Scribd logo
1 de 28
Baixar para ler offline
Théorie et Pratique du Système d’Information
Huitième Chapitre: QoS et Haute-Disponibilité
Janvier-Mars 2012
Ecole Polytechnique
Yves Caseau

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

1/28
Plan du Cours – Architecture du Système
d’Information

Première partie:
Introduction à la Fiabilité
 Deuxième partie:
Fiabiliser le SI
 Troisième partie:
SLA: gestion contractuelle de la QoS


Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

2/28
Première Partie: Formalisation

Fiabilité et Complexité


La fiabilité des SI est souvent incriminée:






Pourquoi ?





Les SI sont des systèmes complexes
 Nombreuses interactions (cf. 1 SI = 1 Airbus)
Les conséquences sont très importantes
Causes multiples (cf. Schmidt)
Nature hybride :
 beaucoup d’actions manuelles
 Systèmes hétérogènes (assemblage)

Qu’est-ce qui tombe en panne ?



Marcus & Stern : pas de consensus !
Les classiques:







System software : 27%
Hardware : 23%
Human error: 18%
Network failure: 17%
Natural disaster: 8%
Other: 7%

II.1 : Processus - Principes

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

3/28
Fiabilité : Concepts Statistiques








Le temps moyen d’occurrence d’une panne (MTTF = Mean Time to Fail) est le temps
constaté entre le début et la fin d’une période de fonctionnement normal. La notion de
moyenne ici s’effectue sur un ensemble d’équipements, pas sur la vie d’un équipement
donné (cf. la notion de durée de vie).
Le temps moyen de réparation (MTTR = Mean Time to Repair) est le temps qu’il faut pour
détecter une défaillance, la réparer et remettre l’équipement en condition de fonctionnement.
Le temps moyen de défaillance (MTBF = Mean Time Between Failure) est la somme des
deux.
La disponibilité est le ratio (MTTF/MTBF).

MTBF = MTTF + MTTR
MTTR

MTTF

OK

KO

Disponibilité (%)

temps

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

La pratique veut que l’on mesure la
disponibilité en « neufs »
•« trois neufs » représente 99,9%,
soit une indisponibilité cumulée de
8h (un jour de travail) sur une année,
•« quatre neufs » représente
99,99%, soit une indisponibilité
cumulée de 1h (52 minutes
précisément) sur une année,
•« cinq neufs » représente 99,999%,
soit une indisponibilité cumulée de 5
minutes sur une année.
Ce chiffre s’interprète selon les exigences
de service:
•24 x 7, 24 x 6, 14 x 5, …
4/28
Durée de vie et MTBF


La fiabilité évolue au cours du temps en fonction du cycle de vie:
Durée de vie

Fréquence
des
incidents

jeunesse
usure

Période stable de définition du MTBF

âge

Attention aux phases de mise en service
 Attention à la gestion des équipements en fin de vie






Cf. chapitre 5 sur les « coûts du socle »

La notion de disponibilité s’applique pour des « événements
statistiques »:



Pannes: HW, réseau, erreur de paramétrages, facilités, …
Pas des « accidents logiciels » ou des « désastres »

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

5/28
Fiabilité du matériel


Il existe une grande variabilité selon la qualité des composants et
surtout selon l’architecture matérielle




Les fiabilités des matériels sont mesurées et publiées par les
constructeurs.




Redondance à tous les niveaux (ex: alimentation)

Attention les valeurs en laboratoire sont toujours meilleures que la
réalité

Les valeurs observées de disponibilité :


De 99.9% à 99.99%






The 2006 survey found that both Linux and Windows Server 2003 (nine hours per
server per year) were relatively crash-prone compared to Unix, but that the Linux
systems surveyed have now closed the gap slightly.
Unix systems, which represented about 10 percent of the installed base covered by
the survey, still achieved the highest reliability figures. IBM's AIX came highest, with
enterprises reporting an average of 36 minutes of downtime per server over a 12month period. HP-UX version 11.1 recorded 1.1 hours of downtime, while Sun
Solaris users reported 1.4 hours per server, per year.
ZDNET : Yankee Group Survey

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

6/28
Fiabilité du logiciel


Cycle





Fiabilité des composants





Software reliability metrics: taille et complexité 
Liée à la qualité du processus
de fabrication

Fiabilité des assemblages





Fault/defect > error > failure
Soft or hard failure: pb de la détection

Versions
Compatibilité

Axiome : il reste toujours des
défauts




CJ: 0.4 défaut par point
de fonction
(commercial SW, small)
1MLOC: 10-20 kPF : 4-8K

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

source: http://www.sei.cmu.edu
7/28
Anatomie d’une crise
Causes multiples vs. confiance dans les plans de protections
 Plus le temps de détection est long, plus les dégâts sont importants
 La crise provoque un état de fonctionnement non nominal qui peut
provoquer d’autres fautes : effet de cascade
 Les temps de migration de données sont sous-estimés
 Cf. Ch. Perrow « Normal Accidents »


Perte éventuelle de données
Dernière
sauvegarde

Cause

Durée de restauration des données

Alerte :
Effet :
Dégradation Détection

Analyse

Diagnostic Action

Réparation

Restauration

Si action insuffisante → boucle

Si durée prévisionnelle est trop longue → Activation du Plan de secours

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

8/28
Risque et Incertitude
Cf. Bernstein’s « a History of Risk »
 Risque: des évènements pour lesquels il
existe un historique et pour lesquels la
gestion statistique est possible, entrainant
des pertes linéaires en fonction de
l’indisponibilité
 Incertitude: les évènements graves sans
statistiques, entrainant des pertes non
linéaires
Deux gestions contractuelles avec la
maîtrise d’ouvrage:
 Les SLA (cf. plus loin) pour la gestion des
incidents
 Le plan de secours, défini en terme de:



RTO: Recovery Time Objective (DMIA)
RPO: Recovery Point Objective (PDMA)

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

(a)

Pertes
(€)
Probabilité

indirectes
productivité
Directes (CA)
Durée indisponibilité
Incidents :
Traitement
quantitatif

Crises :
Traitement qualitatif

Analyse
probabiliste

Étude de
scénarios

9/28
AMDEC


Issu de l’armée américaine: « Procédures pour l'Analyse des Modes de
Défaillance, de leurs Effets leurs Criticités » (1949)




Une AMDEC est défini comme "un procédé systématique pour identifier les
modes potentiels et traiter les défaillances avant qu'elles ne surviennent, avec
l'intention de les éliminer ou de minimiser les risques associés.

Pour réaliser une AMDEC, on utilise un tableau qui comporte les
colonnes suivantes :










identification du composant ou du sous-ensemble,
identification de la ou des défaillances pouvant affecter le composant ou le
sous-ensemble,
recherche des conséquences de cette (ces) défaillance(s) sur le système,
Probabilité/facilité de
détection
cotations de la fréquence,
gravité et probabilité de
non-détection de la
défaillance,
évaluation de la criticité
(en général on retient le
produit fréquence × gravité).

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

10/28
Plan de Secours (Disaster Recovery Plan)


PCA : plan de continuité d’activité





Composants:







Orienté processus métier
Avec l’assistance et l’implication de la maîtrise d’ouvrage
Scénarios (et tests associés)
Ressources de calcul
Données (back-up & restore)
Procédures (à suivre, rigoureusement définies)

Double arbitrage économique:




Périmètre des scénarios à couvrir
 Utilisation des AMDEC pour prioriser
Prix de la solution de continuité
 Shared System, Cold Standby, Hot Standby
 cf. section suivante (parallèle avec haute-disponibilité) … mais
sur des lieux différents

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

11/28
Deuxième partie
Introduction à la Fiabilité
 Fiabiliser le SI
 SLA: Gérer la qualité de service


Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

12/28
Deuxième Partie: Fiabiliser le SI

Fiabilisation matérielle


Meilleure disponibilité:





Fiabiliser (cf. livre de Klaus Schmidt)





Augmenter le MTBF
Réduire le MTTR (partie suivante)
Robustesse
Redondance = repetition + (replication + fault handling)

Trois pistes:




Matériel fiable
Matériel redondant (clusters)
Architecture redondante

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

13/28
Matériel Fiable


Cf. point précédent : les serveurs
« haut-de-gamme » sont plus
fiables (sauf exceptions)





Stockage




Technologies RAID (1 à 5)

Importance du contrat de maintenance






HW dédié « fault-tolerant »
(ex: Status): 99.999%

Détermine le temps d’intervention
(fonction du coût)
Suivre les statistiques de disponibilité
et d’intervention – éviter les « mauvaises séries »

Importance des condition d’hébergement



Redondance de l’alimentation électrique
Redondance de la réfrigération

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

14/28
Clusters


Redondance binaire





Avantages








Actif/passif
Actif/actif
Solution classique
éprouvée
Applicable avec des
configurations simples
Solution DBMS

Inconvénients






Détection : maillon faible
Failover: 90/95% de succès
est un bon chiffre (Schmidt)
Actif/actif: attention à la surcharge
Maintenir deux copies exactes

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

15/28
Architectures redondantes


Redondance N/N+1



Ou N/N+2, etc
Le répartiteur doit être HA .

Très judicieux pour les traitements
sans mémoire/état
 Adapté pour une architecture Ntiers






Il faut également une approche HA
pour les BD

Peut-être combiné avec une
stratégie de virtualisation





Découper une machine en
machines logiques
HA: utiliser une « ferme »
DRC: plusieurs sites

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

16/28
Fiabilisation logicielle
« Big Picture »: 3 approches
 Test




Fault-tolerance et construction rigoureuse des applications





Éliminer le plus de défauts possible
Résister aux défauts
Détecter les problèmes

Redondance logicielle


Cf. approche matérielle

Principe KISS: Keep It Simple, Stupid 




Cf. chapitre 4 – la complexité est l’ennemi de la fiabilité
Nombre des interactions possibles
Capacité à documenter et transmettre ce qui est sophistiqué

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

17/28
Tests
Trois difficultés:
Couverture
 Bonne pratique: mesurer des taux de couverture statiques
 Temps (surtout en mode projet – can you see why ? )







Automatiser !
Penser aux tests le plus tôt possible

Coût


Optimisation économique – pas facile à trouver en pratique

# total
anomalies

Stock résiduel

: détection
(# anos)
: détection
(fréquence)

seuil
rentabilité
marginale
fin du test

temps

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

18/28
« Fault Tolerance »
La qualité des applications joue un rôle essentiel (La Palisse)
 Résister aux erreurs:






Détecter les erreurs / soft failures





Fault -> error:
 respecter les normes de qualité de code
 Utiliser les outils de qualimétrie (ex: Purify)
 Assertions, contrats, etc.
Error –> failure: gestion des erreurs
Gestion des performances
Auto-diagnostic

Permettre une relance plus rapide



Recovery point (back-up)
Démarrage rapide

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

19/28
Redondance Logicielle

2 versions ne suffisent pas
: comment savoir laquelle
se « trompe » ?

Redondance + vote : 3 versions
 Nécessite 3 implémentations différentes
 Utilisé dans les secteurs militaires et aéronautiques
 Coût très important (pas seulement fois 3 )
 Exige une spécification impeccable (facteur de coût) pour que les
trois implémentations coïncident.
 Redondance dans l’exécution des processus métiers:
 Prévoir et traiter les cas d’erreur
 Mécanismes de rejeu et de retraitement des données (solutions
dégradées)
 Parallélisation massive (GRID)
 Ne résout pas les problèmes de design et les erreurs de
programmation
 Se prête mieux à la programmation hybride/redondante






Méthodes par approximation successives
Combinaison d’agents
Réparation « à chaud »

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

20/28
Détection Rapide et mise en œuvre des palliatifs


S’appuie sur des outils logiciels standards





Cf. Marcus & Stern (Chap. 16) : se méfier des solutions ad hoc
Surveiller le réseau !

Gestion des performances, des files d’attentes, …



Cf. chapitre suivant
Suivre les indicateurs métiers (sous forme d’alertes)
 La vision métier est souvent plus fine que la vision technique
ex: défaut de paramétrage de facturation

Qualité des opérations – cf. plus loin
 Tester régulièrement les mécanismes de partage – automatique
et manuels (procédures)
 Garder de la flexibilité




L’expérience montre qu’on se tire souvent d’une crise avec des
matériels supplémentaires (pas forcément ceux qu’on croit)t

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

21/28
Récupération Rapide


Schéma tiré de Marcus & Stern
Days

Hours Mins

Secs

Data Loss

Secs

Mins

Hours Days

downtime

Tape
Clusters
Sync Replication
Restore
Manual
or Mirroring
Migration
Async Replication

Tape
Back-up Periodic
Replication



La gestion des données est souvent un facteur aggravant dans
une crise




« Back-up » corrompus (surtout les version incrémentales)
Temps de chargement plus long que prévu
C’est là qu’on réalise que le planning des back-up ne respecte pas le
RPO parce qu’il a été « optimisé »

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

22/28
Troisième Partie
Introduction à la Fiabilité
 Fiabiliser le SI
 SLA: Gérer la qualité de service


Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

23/28
SLA: Service Level Agreement


Un terme et une pratique qui vient des télécom







Détermine la qualité de service qui doit être fournie au moyen
d’indicateurs mesurables
De disponibilité
De performance

Le SLA est un contrat qui lie les deux parties




La DSI s’engage à tenir ses engagements
 Dans le cas d’une externalisation, il y a des pénalités associées
Le client accepte le compromis et attends la renégotiation pour
relever ses exigences:
 SLR: Service Level Requested

Le SLA est un outil de pilotage
 Le SLA est le résultat d’une négociation (souhaitable)





Force la DSI à expliquer ses contraintes, ses capacités, ses coûts
Force la MOA à expliquer ses enjeux métiers

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

24/28
Gestion économique du SLA
incidents
Le SLA optimal correspond à un
équilibre entre les pertes et les
surcoûts d’exploitation
 Le SLA réel tient compte de
 La capacité à faire,
technique et budgétaire
 Un arbitrage de risque
(dépenses sures vs. Pertes
possibles)




Pertes
Coûts
(€)

La perte produite par les
Coûts
(€)
incidents n’est pas seulement
un perte d’usage, mais
également une perte d’efficacité
qui doit être mesurée, ce qui
permet de piloter l’effort
récurrent de fiabilisation

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

Pertes

Coûts
Durée totale indisponibilité
SLA
théorique

Coût total
Coût de fiabilisation

amélioration

98 %

Coût de non-efficacité
100%

disponibilité

25/28
Importance des procédures
Axiome (Schmidt):
« No tool and no automation can save you from bad operations –
bad operations will make any good design fail. It is the biggest
threat in high availability »
 S’appuyer sur des procédures








Leçon tirée du monde industriel (systèmes critiques)
 Nucléaire, chimie, transport aérien, etc.
Documentée, appliquées, vérifiées

S’appuyer sur un référentiel







ITIL: standard de fait, produit au Royaume-Uni dans les années 80
 Office public britannique du commerce (OGC)
Ensemble de bonnes pratiques
Référentiel de processus
 Service Support
 Service Delivery
Fournit un vocabulaire commun

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

26/28
Importance de la compétence


Professionnalisme




La combinaison des niveaux d’exigence/excellence modernes et des
objectifs de réduction de coût exige la professionnalisation des
opérations de production
Internalisé ou externalisé / formation ou concentration






Compétences sur le SI





Pourquoi externaliser : parce qu’on fait mieux si on fait souvent et sur des
gros volumes
Internaliser: pour développer une compétence propre

Essentiel pour le bon diagnostic préventif
Fondamental en cas de crise (expérience Bytel)
 c’est ce qui permet de trouver les « contournements »

Intégrité




Savoir résister aux changements trop rapides
Appliquer les règles de l’art
Effectuer les tests prévus
 Cf. les livres sur les histoires des crises … (ex. Perrow, Colwell)

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

27/28
Importance du monitoring


La supervision des processus a un double objectif






Vérifier les SLA (Service Level Agreements) pour intervenir sur les
incidents
Suivre le fonctionnement de façon préventive

Elle s’appuie sur deux principes



Génération et remontée d’alarmes (cf. détection)
Corrélation (remonter les niveaux d’abstraction)
SL Monitoring

Incident
Monitoring

Alertes
+
stats +

Processus
métier

BAM

Diagnostic

II.2 : Processus - Exploitation

SLA

Système
fonctionnel

SLA

Système Applicatif
erreur
requêtes

Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII)

Processus
technique

Système
technique

incident

28/28

Mais conteúdo relacionado

Destaque

[FR] Presentation Club Automation "Modele Qualite pour l'automatisme" 22 nov....
[FR] Presentation Club Automation "Modele Qualite pour l'automatisme" 22 nov....[FR] Presentation Club Automation "Modele Qualite pour l'automatisme" 22 nov....
[FR] Presentation Club Automation "Modele Qualite pour l'automatisme" 22 nov....Itris Automation Square
 
Comparison of Cloud Computing Services | Torry Harris Whitepaper
Comparison of Cloud Computing Services | Torry Harris WhitepaperComparison of Cloud Computing Services | Torry Harris Whitepaper
Comparison of Cloud Computing Services | Torry Harris WhitepaperTorry Harris Business Solutions
 
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...ibtissam el hassani
 
Union square
Union squareUnion square
Union squarejonvano31
 
Actividad 4 de las tic´s
Actividad 4 de las tic´sActividad 4 de las tic´s
Actividad 4 de las tic´sAlberto Galvis
 
Webconf CRM Divalto Android juin 2014
Webconf CRM Divalto Android juin 2014Webconf CRM Divalto Android juin 2014
Webconf CRM Divalto Android juin 2014Patrick Le Guillou
 
Social media marketing
Social media marketingSocial media marketing
Social media marketingANOV Agency
 
Taller de arteterapia
Taller de arteterapiaTaller de arteterapia
Taller de arteterapiaIsabel Elvira
 
FBI TRANSCRIPCIÓN ORMACHEA 2-2
FBI TRANSCRIPCIÓN ORMACHEA 2-2FBI TRANSCRIPCIÓN ORMACHEA 2-2
FBI TRANSCRIPCIÓN ORMACHEA 2-2Alejandra Prado
 
Triangle by Keynote
Triangle by KeynoteTriangle by Keynote
Triangle by Keynotemrivard8
 
Présentation d'un travail exploratoire
Présentation d'un travail exploratoirePrésentation d'un travail exploratoire
Présentation d'un travail exploratoireRanachallah
 
Une application participative autour de l'hymne - Etude de cas Malakoff Médéric
Une application participative autour de l'hymne - Etude de cas Malakoff MédéricUne application participative autour de l'hymne - Etude de cas Malakoff Médéric
Une application participative autour de l'hymne - Etude de cas Malakoff MédéricMake Me Viral
 

Destaque (20)

[FR] Presentation Club Automation "Modele Qualite pour l'automatisme" 22 nov....
[FR] Presentation Club Automation "Modele Qualite pour l'automatisme" 22 nov....[FR] Presentation Club Automation "Modele Qualite pour l'automatisme" 22 nov....
[FR] Presentation Club Automation "Modele Qualite pour l'automatisme" 22 nov....
 
Comparison of Cloud Computing Services | Torry Harris Whitepaper
Comparison of Cloud Computing Services | Torry Harris WhitepaperComparison of Cloud Computing Services | Torry Harris Whitepaper
Comparison of Cloud Computing Services | Torry Harris Whitepaper
 
Cloud computing final
Cloud computing finalCloud computing final
Cloud computing final
 
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...
 
Amdec
AmdecAmdec
Amdec
 
Union square
Union squareUnion square
Union square
 
Actividad 4 de las tic´s
Actividad 4 de las tic´sActividad 4 de las tic´s
Actividad 4 de las tic´s
 
Webconf CRM Divalto Android juin 2014
Webconf CRM Divalto Android juin 2014Webconf CRM Divalto Android juin 2014
Webconf CRM Divalto Android juin 2014
 
Social media marketing
Social media marketingSocial media marketing
Social media marketing
 
Guión docente 2 (optativo)
Guión docente 2 (optativo)Guión docente 2 (optativo)
Guión docente 2 (optativo)
 
Taller de arteterapia
Taller de arteterapiaTaller de arteterapia
Taller de arteterapia
 
#Bac2014 Festival du Off Maths
#Bac2014 Festival du Off Maths#Bac2014 Festival du Off Maths
#Bac2014 Festival du Off Maths
 
R
RR
R
 
FBI TRANSCRIPCIÓN ORMACHEA 2-2
FBI TRANSCRIPCIÓN ORMACHEA 2-2FBI TRANSCRIPCIÓN ORMACHEA 2-2
FBI TRANSCRIPCIÓN ORMACHEA 2-2
 
Paris La Nuit
Paris La NuitParis La Nuit
Paris La Nuit
 
Triangle by Keynote
Triangle by KeynoteTriangle by Keynote
Triangle by Keynote
 
Linux
LinuxLinux
Linux
 
Présentation d'un travail exploratoire
Présentation d'un travail exploratoirePrésentation d'un travail exploratoire
Présentation d'un travail exploratoire
 
les acctions
les acctionsles acctions
les acctions
 
Une application participative autour de l'hymne - Etude de cas Malakoff Médéric
Une application participative autour de l'hymne - Etude de cas Malakoff MédéricUne application participative autour de l'hymne - Etude de cas Malakoff Médéric
Une application participative autour de l'hymne - Etude de cas Malakoff Médéric
 

Semelhante a Cours chapitre8 2012

Le Plan de Reprise d'Activité pour les PME
Le Plan de Reprise d'Activité pour les PMELe Plan de Reprise d'Activité pour les PME
Le Plan de Reprise d'Activité pour les PMEAvignon Delta Numérique
 
Analyse de risques en cybersécurité industrielle
Analyse de risques en cybersécurité industrielleAnalyse de risques en cybersécurité industrielle
Analyse de risques en cybersécurité industriellePatrice Bock
 
Restauration de donnée de haute performance
Restauration de donnée de haute performanceRestauration de donnée de haute performance
Restauration de donnée de haute performancenesrine attia
 
Cwin16 - Paris - surveillance site_seveso_ analyse_prédictive
Cwin16 - Paris - surveillance site_seveso_ analyse_prédictiveCwin16 - Paris - surveillance site_seveso_ analyse_prédictive
Cwin16 - Paris - surveillance site_seveso_ analyse_prédictiveCapgemini
 
Résilience des systèmes sociotechniques
Résilience des systèmes sociotechniques Résilience des systèmes sociotechniques
Résilience des systèmes sociotechniques Jean-René RUAULT
 
Black Hat Europe 2008
Black Hat Europe 2008Black Hat Europe 2008
Black Hat Europe 2008fropert
 
E lm22 programme tutoriels
E lm22 programme tutorielsE lm22 programme tutoriels
E lm22 programme tutorielsChloé Philibert
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxssuserec8501
 
sûreté de fonctionnement du logiciel
 sûreté de fonctionnement du logiciel sûreté de fonctionnement du logiciel
sûreté de fonctionnement du logicielEs-sahli bilal
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptxLatifaBen6
 

Semelhante a Cours chapitre8 2012 (20)

Fiabilite
FiabiliteFiabilite
Fiabilite
 
RCM data
RCM dataRCM data
RCM data
 
Le Plan de Reprise d'Activité pour les PME
Le Plan de Reprise d'Activité pour les PMELe Plan de Reprise d'Activité pour les PME
Le Plan de Reprise d'Activité pour les PME
 
Sécurité & Continuité
Sécurité & ContinuitéSécurité & Continuité
Sécurité & Continuité
 
Analyse de risques en cybersécurité industrielle
Analyse de risques en cybersécurité industrielleAnalyse de risques en cybersécurité industrielle
Analyse de risques en cybersécurité industrielle
 
Gl intro
Gl introGl intro
Gl intro
 
Restauration de donnée de haute performance
Restauration de donnée de haute performanceRestauration de donnée de haute performance
Restauration de donnée de haute performance
 
L'audit et la gestion des incidents
L'audit et la gestion des incidentsL'audit et la gestion des incidents
L'audit et la gestion des incidents
 
Cwin16 - Paris - surveillance site_seveso_ analyse_prédictive
Cwin16 - Paris - surveillance site_seveso_ analyse_prédictiveCwin16 - Paris - surveillance site_seveso_ analyse_prédictive
Cwin16 - Paris - surveillance site_seveso_ analyse_prédictive
 
Qualite1
Qualite1Qualite1
Qualite1
 
20150707_Soutenance_Ruault
20150707_Soutenance_Ruault20150707_Soutenance_Ruault
20150707_Soutenance_Ruault
 
Résilience des systèmes sociotechniques
Résilience des systèmes sociotechniques Résilience des systèmes sociotechniques
Résilience des systèmes sociotechniques
 
20150707_Soutenance_Ruault
20150707_Soutenance_Ruault20150707_Soutenance_Ruault
20150707_Soutenance_Ruault
 
Chapitre 1 sem
Chapitre 1 semChapitre 1 sem
Chapitre 1 sem
 
Black Hat Europe 2008
Black Hat Europe 2008Black Hat Europe 2008
Black Hat Europe 2008
 
E lm22 programme tutoriels
E lm22 programme tutorielsE lm22 programme tutoriels
E lm22 programme tutoriels
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
 
Paris Chaos Engineering Meetup #6
Paris Chaos Engineering Meetup #6Paris Chaos Engineering Meetup #6
Paris Chaos Engineering Meetup #6
 
sûreté de fonctionnement du logiciel
 sûreté de fonctionnement du logiciel sûreté de fonctionnement du logiciel
sûreté de fonctionnement du logiciel
 
Génie Logiciel.pptx
Génie Logiciel.pptxGénie Logiciel.pptx
Génie Logiciel.pptx
 

Mais de Yves Caseau

DataAquitaine February 2022
DataAquitaine February 2022DataAquitaine February 2022
DataAquitaine February 2022Yves Caseau
 
Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3Yves Caseau
 
Machine Learning for Self-Tracking
Machine Learning for Self-TrackingMachine Learning for Self-Tracking
Machine Learning for Self-TrackingYves Caseau
 
Information Systems for Digital Transformation
Information Systems for Digital TransformationInformation Systems for Digital Transformation
Information Systems for Digital TransformationYves Caseau
 
Lean from the guts
Lean from the gutsLean from the guts
Lean from the gutsYves Caseau
 
Taking advantageofai july2018
Taking advantageofai july2018Taking advantageofai july2018
Taking advantageofai july2018Yves Caseau
 
Software Pitch 2018
Software Pitch 2018Software Pitch 2018
Software Pitch 2018Yves Caseau
 
Intelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIAIntelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIAYves Caseau
 
Big data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT ArchitectureBig data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT ArchitectureYves Caseau
 
XEBICON Public November 2015
XEBICON Public November 2015XEBICON Public November 2015
XEBICON Public November 2015Yves Caseau
 
Smart selfnovember2013
Smart selfnovember2013Smart selfnovember2013
Smart selfnovember2013Yves Caseau
 
Management socialnetworksfeb2012
Management socialnetworksfeb2012Management socialnetworksfeb2012
Management socialnetworksfeb2012Yves Caseau
 
Google socialnetworksmarch08
Google socialnetworksmarch08Google socialnetworksmarch08
Google socialnetworksmarch08Yves Caseau
 
Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance Yves Caseau
 
Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013Yves Caseau
 
Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015Yves Caseau
 
The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014Yves Caseau
 

Mais de Yves Caseau (20)

CCEM2023.pptx
CCEM2023.pptxCCEM2023.pptx
CCEM2023.pptx
 
DataAquitaine February 2022
DataAquitaine February 2022DataAquitaine February 2022
DataAquitaine February 2022
 
Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3
 
Machine Learning for Self-Tracking
Machine Learning for Self-TrackingMachine Learning for Self-Tracking
Machine Learning for Self-Tracking
 
Information Systems for Digital Transformation
Information Systems for Digital TransformationInformation Systems for Digital Transformation
Information Systems for Digital Transformation
 
Lean from the guts
Lean from the gutsLean from the guts
Lean from the guts
 
Taking advantageofai july2018
Taking advantageofai july2018Taking advantageofai july2018
Taking advantageofai july2018
 
Software Pitch 2018
Software Pitch 2018Software Pitch 2018
Software Pitch 2018
 
Intelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIAIntelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIA
 
Big data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT ArchitectureBig data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT Architecture
 
XEBICON Public November 2015
XEBICON Public November 2015XEBICON Public November 2015
XEBICON Public November 2015
 
Smart selfnovember2013
Smart selfnovember2013Smart selfnovember2013
Smart selfnovember2013
 
Management socialnetworksfeb2012
Management socialnetworksfeb2012Management socialnetworksfeb2012
Management socialnetworksfeb2012
 
Google socialnetworksmarch08
Google socialnetworksmarch08Google socialnetworksmarch08
Google socialnetworksmarch08
 
Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance
 
Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013
 
Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015
 
GTES UTC 2014
GTES  UTC 2014GTES  UTC 2014
GTES UTC 2014
 
The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014
 
Disic mars2014
Disic mars2014Disic mars2014
Disic mars2014
 

Último

Exercice de FLE pour enfants sur les transports et les prépositions
Exercice de FLE pour enfants sur les transports et les prépositionsExercice de FLE pour enfants sur les transports et les prépositions
Exercice de FLE pour enfants sur les transports et les prépositionslaetitiachassagne
 
Planning de la semaine du 25 mars au 2 avril 2024
Planning de la semaine du 25 mars au 2 avril 2024Planning de la semaine du 25 mars au 2 avril 2024
Planning de la semaine du 25 mars au 2 avril 2024frizzole
 
Semaine de la Passion de Jésus-Christ.pptx
Semaine de la Passion de Jésus-Christ.pptxSemaine de la Passion de Jésus-Christ.pptx
Semaine de la Passion de Jésus-Christ.pptxMartin M Flynn
 
Rapport projet de fin d'études licence PFE
Rapport projet de fin d'études licence PFERapport projet de fin d'études licence PFE
Rapport projet de fin d'études licence PFEAhmam Abderrahmane
 
Présentation de lancement de la SAE203 - MMI S2
Présentation de lancement de la SAE203 - MMI S2Présentation de lancement de la SAE203 - MMI S2
Présentation de lancement de la SAE203 - MMI S2JeanLucHusson
 
Formation M2i - Femmes entrepreneures : soyez actrices du changement
Formation M2i - Femmes entrepreneures : soyez actrices du changementFormation M2i - Femmes entrepreneures : soyez actrices du changement
Formation M2i - Femmes entrepreneures : soyez actrices du changementM2i Formation
 
La Projection orthogonale en dessin technique
La Projection orthogonale en dessin techniqueLa Projection orthogonale en dessin technique
La Projection orthogonale en dessin techniquessuser4dbdf2
 

Último (7)

Exercice de FLE pour enfants sur les transports et les prépositions
Exercice de FLE pour enfants sur les transports et les prépositionsExercice de FLE pour enfants sur les transports et les prépositions
Exercice de FLE pour enfants sur les transports et les prépositions
 
Planning de la semaine du 25 mars au 2 avril 2024
Planning de la semaine du 25 mars au 2 avril 2024Planning de la semaine du 25 mars au 2 avril 2024
Planning de la semaine du 25 mars au 2 avril 2024
 
Semaine de la Passion de Jésus-Christ.pptx
Semaine de la Passion de Jésus-Christ.pptxSemaine de la Passion de Jésus-Christ.pptx
Semaine de la Passion de Jésus-Christ.pptx
 
Rapport projet de fin d'études licence PFE
Rapport projet de fin d'études licence PFERapport projet de fin d'études licence PFE
Rapport projet de fin d'études licence PFE
 
Présentation de lancement de la SAE203 - MMI S2
Présentation de lancement de la SAE203 - MMI S2Présentation de lancement de la SAE203 - MMI S2
Présentation de lancement de la SAE203 - MMI S2
 
Formation M2i - Femmes entrepreneures : soyez actrices du changement
Formation M2i - Femmes entrepreneures : soyez actrices du changementFormation M2i - Femmes entrepreneures : soyez actrices du changement
Formation M2i - Femmes entrepreneures : soyez actrices du changement
 
La Projection orthogonale en dessin technique
La Projection orthogonale en dessin techniqueLa Projection orthogonale en dessin technique
La Projection orthogonale en dessin technique
 

Cours chapitre8 2012

  • 1. Théorie et Pratique du Système d’Information Huitième Chapitre: QoS et Haute-Disponibilité Janvier-Mars 2012 Ecole Polytechnique Yves Caseau Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 1/28
  • 2. Plan du Cours – Architecture du Système d’Information Première partie: Introduction à la Fiabilité  Deuxième partie: Fiabiliser le SI  Troisième partie: SLA: gestion contractuelle de la QoS  Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 2/28
  • 3. Première Partie: Formalisation Fiabilité et Complexité  La fiabilité des SI est souvent incriminée:    Pourquoi ?    Les SI sont des systèmes complexes  Nombreuses interactions (cf. 1 SI = 1 Airbus) Les conséquences sont très importantes Causes multiples (cf. Schmidt) Nature hybride :  beaucoup d’actions manuelles  Systèmes hétérogènes (assemblage) Qu’est-ce qui tombe en panne ?   Marcus & Stern : pas de consensus ! Les classiques:       System software : 27% Hardware : 23% Human error: 18% Network failure: 17% Natural disaster: 8% Other: 7% II.1 : Processus - Principes Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 3/28
  • 4. Fiabilité : Concepts Statistiques     Le temps moyen d’occurrence d’une panne (MTTF = Mean Time to Fail) est le temps constaté entre le début et la fin d’une période de fonctionnement normal. La notion de moyenne ici s’effectue sur un ensemble d’équipements, pas sur la vie d’un équipement donné (cf. la notion de durée de vie). Le temps moyen de réparation (MTTR = Mean Time to Repair) est le temps qu’il faut pour détecter une défaillance, la réparer et remettre l’équipement en condition de fonctionnement. Le temps moyen de défaillance (MTBF = Mean Time Between Failure) est la somme des deux. La disponibilité est le ratio (MTTF/MTBF). MTBF = MTTF + MTTR MTTR MTTF OK KO Disponibilité (%) temps Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) La pratique veut que l’on mesure la disponibilité en « neufs » •« trois neufs » représente 99,9%, soit une indisponibilité cumulée de 8h (un jour de travail) sur une année, •« quatre neufs » représente 99,99%, soit une indisponibilité cumulée de 1h (52 minutes précisément) sur une année, •« cinq neufs » représente 99,999%, soit une indisponibilité cumulée de 5 minutes sur une année. Ce chiffre s’interprète selon les exigences de service: •24 x 7, 24 x 6, 14 x 5, … 4/28
  • 5. Durée de vie et MTBF  La fiabilité évolue au cours du temps en fonction du cycle de vie: Durée de vie Fréquence des incidents jeunesse usure Période stable de définition du MTBF âge Attention aux phases de mise en service  Attention à la gestion des équipements en fin de vie    Cf. chapitre 5 sur les « coûts du socle » La notion de disponibilité s’applique pour des « événements statistiques »:   Pannes: HW, réseau, erreur de paramétrages, facilités, … Pas des « accidents logiciels » ou des « désastres » Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 5/28
  • 6. Fiabilité du matériel  Il existe une grande variabilité selon la qualité des composants et surtout selon l’architecture matérielle   Les fiabilités des matériels sont mesurées et publiées par les constructeurs.   Redondance à tous les niveaux (ex: alimentation) Attention les valeurs en laboratoire sont toujours meilleures que la réalité Les valeurs observées de disponibilité :  De 99.9% à 99.99%    The 2006 survey found that both Linux and Windows Server 2003 (nine hours per server per year) were relatively crash-prone compared to Unix, but that the Linux systems surveyed have now closed the gap slightly. Unix systems, which represented about 10 percent of the installed base covered by the survey, still achieved the highest reliability figures. IBM's AIX came highest, with enterprises reporting an average of 36 minutes of downtime per server over a 12month period. HP-UX version 11.1 recorded 1.1 hours of downtime, while Sun Solaris users reported 1.4 hours per server, per year. ZDNET : Yankee Group Survey Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 6/28
  • 7. Fiabilité du logiciel  Cycle    Fiabilité des composants    Software reliability metrics: taille et complexité  Liée à la qualité du processus de fabrication Fiabilité des assemblages    Fault/defect > error > failure Soft or hard failure: pb de la détection Versions Compatibilité Axiome : il reste toujours des défauts   CJ: 0.4 défaut par point de fonction (commercial SW, small) 1MLOC: 10-20 kPF : 4-8K Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) source: http://www.sei.cmu.edu 7/28
  • 8. Anatomie d’une crise Causes multiples vs. confiance dans les plans de protections  Plus le temps de détection est long, plus les dégâts sont importants  La crise provoque un état de fonctionnement non nominal qui peut provoquer d’autres fautes : effet de cascade  Les temps de migration de données sont sous-estimés  Cf. Ch. Perrow « Normal Accidents »  Perte éventuelle de données Dernière sauvegarde Cause Durée de restauration des données Alerte : Effet : Dégradation Détection Analyse Diagnostic Action Réparation Restauration Si action insuffisante → boucle Si durée prévisionnelle est trop longue → Activation du Plan de secours Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 8/28
  • 9. Risque et Incertitude Cf. Bernstein’s « a History of Risk »  Risque: des évènements pour lesquels il existe un historique et pour lesquels la gestion statistique est possible, entrainant des pertes linéaires en fonction de l’indisponibilité  Incertitude: les évènements graves sans statistiques, entrainant des pertes non linéaires Deux gestions contractuelles avec la maîtrise d’ouvrage:  Les SLA (cf. plus loin) pour la gestion des incidents  Le plan de secours, défini en terme de:   RTO: Recovery Time Objective (DMIA) RPO: Recovery Point Objective (PDMA) Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) (a) Pertes (€) Probabilité indirectes productivité Directes (CA) Durée indisponibilité Incidents : Traitement quantitatif Crises : Traitement qualitatif Analyse probabiliste Étude de scénarios 9/28
  • 10. AMDEC  Issu de l’armée américaine: « Procédures pour l'Analyse des Modes de Défaillance, de leurs Effets leurs Criticités » (1949)   Une AMDEC est défini comme "un procédé systématique pour identifier les modes potentiels et traiter les défaillances avant qu'elles ne surviennent, avec l'intention de les éliminer ou de minimiser les risques associés. Pour réaliser une AMDEC, on utilise un tableau qui comporte les colonnes suivantes :       identification du composant ou du sous-ensemble, identification de la ou des défaillances pouvant affecter le composant ou le sous-ensemble, recherche des conséquences de cette (ces) défaillance(s) sur le système, Probabilité/facilité de détection cotations de la fréquence, gravité et probabilité de non-détection de la défaillance, évaluation de la criticité (en général on retient le produit fréquence × gravité). Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 10/28
  • 11. Plan de Secours (Disaster Recovery Plan)  PCA : plan de continuité d’activité    Composants:      Orienté processus métier Avec l’assistance et l’implication de la maîtrise d’ouvrage Scénarios (et tests associés) Ressources de calcul Données (back-up & restore) Procédures (à suivre, rigoureusement définies) Double arbitrage économique:   Périmètre des scénarios à couvrir  Utilisation des AMDEC pour prioriser Prix de la solution de continuité  Shared System, Cold Standby, Hot Standby  cf. section suivante (parallèle avec haute-disponibilité) … mais sur des lieux différents Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 11/28
  • 12. Deuxième partie Introduction à la Fiabilité  Fiabiliser le SI  SLA: Gérer la qualité de service  Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 12/28
  • 13. Deuxième Partie: Fiabiliser le SI Fiabilisation matérielle  Meilleure disponibilité:    Fiabiliser (cf. livre de Klaus Schmidt)    Augmenter le MTBF Réduire le MTTR (partie suivante) Robustesse Redondance = repetition + (replication + fault handling) Trois pistes:    Matériel fiable Matériel redondant (clusters) Architecture redondante Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 13/28
  • 14. Matériel Fiable  Cf. point précédent : les serveurs « haut-de-gamme » sont plus fiables (sauf exceptions)    Stockage   Technologies RAID (1 à 5) Importance du contrat de maintenance    HW dédié « fault-tolerant » (ex: Status): 99.999% Détermine le temps d’intervention (fonction du coût) Suivre les statistiques de disponibilité et d’intervention – éviter les « mauvaises séries » Importance des condition d’hébergement   Redondance de l’alimentation électrique Redondance de la réfrigération Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 14/28
  • 15. Clusters  Redondance binaire    Avantages     Actif/passif Actif/actif Solution classique éprouvée Applicable avec des configurations simples Solution DBMS Inconvénients     Détection : maillon faible Failover: 90/95% de succès est un bon chiffre (Schmidt) Actif/actif: attention à la surcharge Maintenir deux copies exactes Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 15/28
  • 16. Architectures redondantes  Redondance N/N+1   Ou N/N+2, etc Le répartiteur doit être HA . Très judicieux pour les traitements sans mémoire/état  Adapté pour une architecture Ntiers    Il faut également une approche HA pour les BD Peut-être combiné avec une stratégie de virtualisation    Découper une machine en machines logiques HA: utiliser une « ferme » DRC: plusieurs sites Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 16/28
  • 17. Fiabilisation logicielle « Big Picture »: 3 approches  Test   Fault-tolerance et construction rigoureuse des applications    Éliminer le plus de défauts possible Résister aux défauts Détecter les problèmes Redondance logicielle  Cf. approche matérielle Principe KISS: Keep It Simple, Stupid     Cf. chapitre 4 – la complexité est l’ennemi de la fiabilité Nombre des interactions possibles Capacité à documenter et transmettre ce qui est sophistiqué Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 17/28
  • 18. Tests Trois difficultés: Couverture  Bonne pratique: mesurer des taux de couverture statiques  Temps (surtout en mode projet – can you see why ? )     Automatiser ! Penser aux tests le plus tôt possible Coût  Optimisation économique – pas facile à trouver en pratique # total anomalies Stock résiduel : détection (# anos) : détection (fréquence) seuil rentabilité marginale fin du test temps Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 18/28
  • 19. « Fault Tolerance » La qualité des applications joue un rôle essentiel (La Palisse)  Résister aux erreurs:    Détecter les erreurs / soft failures    Fault -> error:  respecter les normes de qualité de code  Utiliser les outils de qualimétrie (ex: Purify)  Assertions, contrats, etc. Error –> failure: gestion des erreurs Gestion des performances Auto-diagnostic Permettre une relance plus rapide   Recovery point (back-up) Démarrage rapide Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 19/28
  • 20. Redondance Logicielle 2 versions ne suffisent pas : comment savoir laquelle se « trompe » ? Redondance + vote : 3 versions  Nécessite 3 implémentations différentes  Utilisé dans les secteurs militaires et aéronautiques  Coût très important (pas seulement fois 3 )  Exige une spécification impeccable (facteur de coût) pour que les trois implémentations coïncident.  Redondance dans l’exécution des processus métiers:  Prévoir et traiter les cas d’erreur  Mécanismes de rejeu et de retraitement des données (solutions dégradées)  Parallélisation massive (GRID)  Ne résout pas les problèmes de design et les erreurs de programmation  Se prête mieux à la programmation hybride/redondante     Méthodes par approximation successives Combinaison d’agents Réparation « à chaud » Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 20/28
  • 21. Détection Rapide et mise en œuvre des palliatifs  S’appuie sur des outils logiciels standards    Cf. Marcus & Stern (Chap. 16) : se méfier des solutions ad hoc Surveiller le réseau ! Gestion des performances, des files d’attentes, …   Cf. chapitre suivant Suivre les indicateurs métiers (sous forme d’alertes)  La vision métier est souvent plus fine que la vision technique ex: défaut de paramétrage de facturation Qualité des opérations – cf. plus loin  Tester régulièrement les mécanismes de partage – automatique et manuels (procédures)  Garder de la flexibilité   L’expérience montre qu’on se tire souvent d’une crise avec des matériels supplémentaires (pas forcément ceux qu’on croit)t Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 21/28
  • 22. Récupération Rapide  Schéma tiré de Marcus & Stern Days Hours Mins Secs Data Loss Secs Mins Hours Days downtime Tape Clusters Sync Replication Restore Manual or Mirroring Migration Async Replication Tape Back-up Periodic Replication  La gestion des données est souvent un facteur aggravant dans une crise    « Back-up » corrompus (surtout les version incrémentales) Temps de chargement plus long que prévu C’est là qu’on réalise que le planning des back-up ne respecte pas le RPO parce qu’il a été « optimisé » Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 22/28
  • 23. Troisième Partie Introduction à la Fiabilité  Fiabiliser le SI  SLA: Gérer la qualité de service  Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 23/28
  • 24. SLA: Service Level Agreement  Un terme et une pratique qui vient des télécom     Détermine la qualité de service qui doit être fournie au moyen d’indicateurs mesurables De disponibilité De performance Le SLA est un contrat qui lie les deux parties   La DSI s’engage à tenir ses engagements  Dans le cas d’une externalisation, il y a des pénalités associées Le client accepte le compromis et attends la renégotiation pour relever ses exigences:  SLR: Service Level Requested Le SLA est un outil de pilotage  Le SLA est le résultat d’une négociation (souhaitable)    Force la DSI à expliquer ses contraintes, ses capacités, ses coûts Force la MOA à expliquer ses enjeux métiers Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 24/28
  • 25. Gestion économique du SLA incidents Le SLA optimal correspond à un équilibre entre les pertes et les surcoûts d’exploitation  Le SLA réel tient compte de  La capacité à faire, technique et budgétaire  Un arbitrage de risque (dépenses sures vs. Pertes possibles)   Pertes Coûts (€) La perte produite par les Coûts (€) incidents n’est pas seulement un perte d’usage, mais également une perte d’efficacité qui doit être mesurée, ce qui permet de piloter l’effort récurrent de fiabilisation Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) Pertes Coûts Durée totale indisponibilité SLA théorique Coût total Coût de fiabilisation amélioration 98 % Coût de non-efficacité 100% disponibilité 25/28
  • 26. Importance des procédures Axiome (Schmidt): « No tool and no automation can save you from bad operations – bad operations will make any good design fail. It is the biggest threat in high availability »  S’appuyer sur des procédures     Leçon tirée du monde industriel (systèmes critiques)  Nucléaire, chimie, transport aérien, etc. Documentée, appliquées, vérifiées S’appuyer sur un référentiel     ITIL: standard de fait, produit au Royaume-Uni dans les années 80  Office public britannique du commerce (OGC) Ensemble de bonnes pratiques Référentiel de processus  Service Support  Service Delivery Fournit un vocabulaire commun Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 26/28
  • 27. Importance de la compétence  Professionnalisme   La combinaison des niveaux d’exigence/excellence modernes et des objectifs de réduction de coût exige la professionnalisation des opérations de production Internalisé ou externalisé / formation ou concentration    Compétences sur le SI    Pourquoi externaliser : parce qu’on fait mieux si on fait souvent et sur des gros volumes Internaliser: pour développer une compétence propre Essentiel pour le bon diagnostic préventif Fondamental en cas de crise (expérience Bytel)  c’est ce qui permet de trouver les « contournements » Intégrité    Savoir résister aux changements trop rapides Appliquer les règles de l’art Effectuer les tests prévus  Cf. les livres sur les histoires des crises … (ex. Perrow, Colwell) Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) 27/28
  • 28. Importance du monitoring  La supervision des processus a un double objectif    Vérifier les SLA (Service Level Agreements) pour intervenir sur les incidents Suivre le fonctionnement de façon préventive Elle s’appuie sur deux principes   Génération et remontée d’alarmes (cf. détection) Corrélation (remonter les niveaux d’abstraction) SL Monitoring Incident Monitoring Alertes + stats + Processus métier BAM Diagnostic II.2 : Processus - Exploitation SLA Système fonctionnel SLA Système Applicatif erreur requêtes Copyright © Yves Caseau 2012 – Cours Polytechnique (VIII) Processus technique Système technique incident 28/28

Notas do Editor

  1. 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).
  2. 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
  3. 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.  
  4. 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).
  5. http://chaqual.free.fr/outils/amdec/histoireamdec.html
  6. http://www.apachefrance.com/Articles/3/page1.html
  7. Note: les tests se font aussi après la mise en prod
  8. 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.
  9. 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é.
  10. 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.