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.)

1. Reprise sur
incident
ConFoo 2012

2. Jean-Marc Fontaine
Passionné de web depuis 1996, de PHP depuis 2000 et de
musique depuis 1977
‣ 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 !
3

4. Diminuer la portée
Limiter le périmètre du problème
‣ Indisponibilité
‣ Perte de données
‣ Rupture de la confidentialité
4

5. Minimiser l’impact
Limiter les conséquences du problème
‣ En terme financier
‣ En terme d’image
5

6. Se préparer
6

7. “Les plans ne sont rien; c'est la
planification qui compte”
Dwight Eisenhower
7

8. Avoir un plan
8

9. Se préparer à être efficace le jour J
Connaître son rôle et ses actions
9

10. Avoir une équipe spécialisée
Cellule transverse de crise
10

11. Mesures de mitigation
11

12. Machines virtuelles
Possibilité d’augmenter très rapidement la capacité
12

13. Base de données
Réplication master/slave
13

14. Feature flipping
Désactivation de fonctionnalité pour préserver le
cœur de l’activité
14

15. Version statique
Tout ou partie du site devient statique pour être servi
très rapidement
15

16. Sauvegardes
16

17. Sauvegarder tout
Chaque élément manquant dans la sauvegarde est
un élément perdu en cas de problème
17

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

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

20. Garder un historique intelligent
Il est inutile d’accumuler les sauvegardes sans
discernement
20

21. Journalisation
21

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

23. Etsy
23

24. Privilégier les fichiers plats
Ils sont plus facilement manipulables
24

25. Déporter les logs
La centralisation des logs permet de mieux les
aggréger
25

26. Communiquer en interne
26

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

28. Déploiement automatisé
28

29. Rapide
Un script ira toujours plus vite qu’un humain
29

30. Pas sujet à la pression
La criticité du problème n’impactera en rien le
travail du script
30

31. Tester les procédures
31

32. Régulièrement
Rien ne vaut une mise en situation
32

33. Avec précaution
Ne surtout pas impacter la production
33

34. Détecter
34

35. Supervision
35

36. Surveiller les ressources
36

37. Surveiller les journaux
Y chercher des indices de problèmes
37

38. Surveiller l’application
Est-elle disponible pour les utilisateurs
38

39. Faciliter le contact
Vos utilisateurs sont autant de sondes de surveillance
39

40. Communiquer
40

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

42. Parefeu humain
La communciation ne doit pas être faite par l’équipe
d’intervention
42

43. Amazon Web Services
43

44. Twitter
44

45. Analyser
45

46. Identification de la cause
46

47. Interne
Panne matérielle, instabilité logicielle, bogue
applicatif, erreur humaine, etc.
47

48. Externe
Attaque, panne matérielle, pic de fréquentation, etc.
48

49. Identification de la portée
49

50. Quels sont les services touchés ?
50

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

52. Identification de l’impact
52

53. Problème de sécurité ?
53

54. Perte de données ?
54

55. Atteinte à l’image ?
55

56. Corriger
56

57. Activer les mesures de mitigation
nécessaires
Y aller progressivement et se limiter au strict
nécessaire
57

58. Appliquer les mesures correctives
58

59. Déployer l’application si nécessaire
59

60. En dernier recours : tout couper
C’est parfois la seule solution
60

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

62. Fêter cela !
62

63. Fêter cela !
63

64. Apprendre
64

65. Capitaliser le savoir acquis
Un problème résolu ne doit jamais se reproduire …
en théorie
65

66. Méthodes des 5 pourquois
66

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

68. Se préparer
Ce n’est pas le jour J qu’il faut commencer à chercher des solutions 1
Communiquer
La communication est primordiale mais ne doit pas nuire à la résolution 2
Analyser
Prendre le temps de comprendre le problème 3
Corriger
Intervenir de manière précise et efficace pour corriger le problème 4
Apprendre
Accumuler le savoir pour éviter de voir le problème se reproduire 5
68

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

70. Crédits photographiques
Les photos et illustrations suivantes ont été utilisées dans cette
présentation. Merci à leurs auteurs !
‣ 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/
70