Reprise sur incident - ConFoo 2012

Post on 02-Jul-2015

984 views 1 download

description

Que se soit suite à une attaque, une défaillance matérielle ou un bogue applicatif, et malgré toute les précautions prises en amont, aucune application en production n'est à l'abri d'une catastrophe.L'important est d'avoir un plan de reprise sur incident efficace pour limiter le plus possible l'impact d'un tel incident sur la qualité de service.Cela passe par une phase de préparation (mise en place de logs, sauvegardes régulière, etc) et par un plan d'action pour le jour J (Communication de crise, diagnostiques, priorisation des tâches, etc.)

Transcript of Reprise sur incident - ConFoo 2012

Reprise surincidentConFoo 2012

Passionné de web depuis 1996, de PHP depuis 2000 et de musique depuis 1977

Jean-Marc Fontaine

‣ Consultant PHP chez Alter Way‣ Ex-Président de l’AFUP‣ Co-Auteur du livre blanc

«Industrialisation PHP»‣ Auteur du blog

industrialisation-php.com

2

3

Cela va arriver !

Limiter le périmètre du problème

4

Diminuer la portée

‣ Indisponibilité‣ Perte de données‣ Rupture de la confidentialité

Limiter les conséquences du problème

5

Minimiser l’impact

‣ En terme financier‣ En terme d’image

6

Se préparer

8

Avoir un plan

9

Se préparer à être efficace le jour JConnaître son rôle et ses actions

10

Avoir une équipe spécialiséeCellule transverse de crise

11

Mesures de mitigation

12

Machines virtuellesPossibilité d’augmenter très rapidement la capacité

13

Base de donnéesRéplication master/slave

14

Feature flippingDésactivation de fonctionnalité pour préserver le cœur de l’activité

15

Version statiqueTout ou partie du site devient statique pour être servi très rapidement

16

Sauvegardes

17

Sauvegarder toutChaque élément manquant dans la sauvegarde est un élément perdu en cas de problème

18

Sauvegarder régulièrementIl faut éviter d’avoir une trop grande différence entre la production et la dernière sauvegarde

19

Vérifier les sauvegardesUne sauvegarde peut être inutilisable. On doit donc la vérifier régulièrement.

20

Garder un historique intelligentIl est inutile d’accumuler les sauvegardes sans discernement

21

Journalisation

22

Que journaliser ?L’activité système, celle des applications, les déploiements, opérations de maintenance

23

Etsy

24

Privilégier les fichiers platsIls sont plus facilement manipulables

25

Déporter les logsLa centralisation des logs permet de mieux les aggréger

26

Communiquer en interne

27

Certains pics de fréquentations sont anticipablesPériode de l'année, publicité, promotion, ommunication dans les médias

28

Déploiement automatisé

29

RapideUn script ira toujours plus vite qu’un humain

30

Pas sujet à la pressionLa criticité du problème n’impactera en rien le travail du script

31

Tester les procédures

32

RégulièrementRien ne vaut une mise en situation

33

Avec précautionNe surtout pas impacter la production

34

Détecter

35

Supervision

36

Surveiller les ressources

37

Surveiller les journauxY chercher des indices de problèmes

38

Surveiller l’applicationEst-elle disponible pour les utilisateurs

39

Faciliter le contactVos utilisateurs sont autant de sondes de surveillance

40

Communiquer

41

Isoler l'équipe d'interventionToute leur énergie doit être mobilisée pour régler le problème

42

Parefeu humainLa communciation ne doit pas être faite par l’équipe d’intervention

43

Amazon Web Services

44

Twitter

45

Analyser

46

Identification de la cause

47

InternePanne matérielle, instabilité logicielle, bogue applicatif, erreur humaine, etc.

48

ExterneAttaque, panne matérielle, pic de fréquentation, etc.

49

Identification de la portée

50

Quels sont les services touchés ?

51

Le service est-il réduit voire coupé ?

52

Identification de l’impact

53

Problème de sécurité ?

54

Perte de données ?

55

Atteinte à l’image ?

56

Corriger

57

Activer les mesures de mitigation nécessairesY aller progressivement et se limiter au strict nécessaire

58

Appliquer les mesures correctives

59

Déployer l’application si nécessaire

60

En dernier recours : tout couperC’est parfois la seule solution

61

Le problème est réglé.Il est donc temps de…

62

Fêter cela !

63

Fêter cela !

64

Apprendre

65

Capitaliser le savoir acquisUn problème résolu ne doit jamais se reproduire … en théorie

66

Méthodes des 5 pourquois

67

Intégrer les résultats aux procédures de test

68

CommuniquerLa communication est primordiale mais ne doit pas nuire à la résolution

AnalyserPrendre le temps de comprendre le problème

CorrigerIntervenir de manière précise et efficace pour corriger le problème

ApprendreAccumuler le savoir pour éviter de voir le problème se reproduire

Se préparerCe n’est pas le jour J qu’il faut commencer à chercher des solutions 1

2

3

4

5

69

Merci !

‣ Commentaires et slides : https://joind.in/6086‣ Blog : http://www.industrialisation-php.com/‣ Twitter : @jmfontaine / @indusphp‣ Email : jean-marc.fontaine@alterway.fr

Les photos et illustrations suivantes ont été utilisées dans cette présentation. Merci à leurs auteurs !

70

Crédits photographiques

‣ http://www.flickr.com/photos/r000pert/136999467/

‣ http://www.flickr.com/photos/illetirres/2214018398/

‣ http://www.flickr.com/photos/larimdame/2575986601/

‣ http://www.flickr.com/photos/techne/107093245/

‣ http://www.flickr.com/photos/p-doodle/466500483/

‣ http://www.flickr.com/photos/dennissylvesterhurd/141183312/