Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Reprise sur incident - ConFoo 2012

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 70 Publicité

Reprise sur incident - ConFoo 2012

Télécharger pour lire hors ligne

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

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

Publicité
Publicité

Plus De Contenu Connexe

Similaire à Reprise sur incident - ConFoo 2012 (20)

Publicité

Plus par Jean-Marc Fontaine (14)

Plus récents (20)

Publicité

Reprise sur incident - ConFoo 2012

  1. 1. Reprise sur incident ConFoo 2012
  2. 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. 3. Cela va arriver ! 3
  4. 4. Diminuer la portée Limiter le périmètre du problème ‣ Indisponibilité ‣ Perte de données ‣ Rupture de la confidentialité 4
  5. 5. Minimiser l’impact Limiter les conséquences du problème ‣ En terme financier ‣ En terme d’image 5
  6. 6. Se préparer 6
  7. 7. “Les plans ne sont rien; c'est la planification qui compte” Dwight Eisenhower 7
  8. 8. Avoir un plan 8
  9. 9. Se préparer à être efficace le jour J Connaître son rôle et ses actions 9
  10. 10. Avoir une équipe spécialisée Cellule transverse de crise 10
  11. 11. Mesures de mitigation 11
  12. 12. Machines virtuelles Possibilité d’augmenter très rapidement la capacité 12
  13. 13. Base de données Réplication master/slave 13
  14. 14. Feature flipping Désactivation de fonctionnalité pour préserver le cœur de l’activité 14
  15. 15. Version statique Tout ou partie du site devient statique pour être servi très rapidement 15
  16. 16. Sauvegardes 16
  17. 17. Sauvegarder tout Chaque élément manquant dans la sauvegarde est un élément perdu en cas de problème 17
  18. 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. 19. Vérifier les sauvegardes Une sauvegarde peut être inutilisable. On doit donc la vérifier régulièrement. 19
  20. 20. Garder un historique intelligent Il est inutile d’accumuler les sauvegardes sans discernement 20
  21. 21. Journalisation 21
  22. 22. Que journaliser ? L’activité système, celle des applications, les déploiements, opérations de maintenance 22
  23. 23. Etsy 23
  24. 24. Privilégier les fichiers plats Ils sont plus facilement manipulables 24
  25. 25. Déporter les logs La centralisation des logs permet de mieux les aggréger 25
  26. 26. Communiquer en interne 26
  27. 27. Certains pics de fréquentations sont anticipables Période de l'année, publicité, promotion, ommunication dans les médias 27
  28. 28. Déploiement automatisé 28
  29. 29. Rapide Un script ira toujours plus vite qu’un humain 29
  30. 30. Pas sujet à la pression La criticité du problème n’impactera en rien le travail du script 30
  31. 31. Tester les procédures 31
  32. 32. Régulièrement Rien ne vaut une mise en situation 32
  33. 33. Avec précaution Ne surtout pas impacter la production 33
  34. 34. Détecter 34
  35. 35. Supervision 35
  36. 36. Surveiller les ressources 36
  37. 37. Surveiller les journaux Y chercher des indices de problèmes 37
  38. 38. Surveiller l’application Est-elle disponible pour les utilisateurs 38
  39. 39. Faciliter le contact Vos utilisateurs sont autant de sondes de surveillance 39
  40. 40. Communiquer 40
  41. 41. Isoler l'équipe d'intervention Toute leur énergie doit être mobilisée pour régler le problème 41
  42. 42. Parefeu humain La communciation ne doit pas être faite par l’équipe d’intervention 42
  43. 43. Amazon Web Services 43
  44. 44. Twitter 44
  45. 45. Analyser 45
  46. 46. Identification de la cause 46
  47. 47. Interne Panne matérielle, instabilité logicielle, bogue applicatif, erreur humaine, etc. 47
  48. 48. Externe Attaque, panne matérielle, pic de fréquentation, etc. 48
  49. 49. Identification de la portée 49
  50. 50. Quels sont les services touchés ? 50
  51. 51. Le service est-il réduit voire coupé ? 51
  52. 52. Identification de l’impact 52
  53. 53. Problème de sécurité ? 53
  54. 54. Perte de données ? 54
  55. 55. Atteinte à l’image ? 55
  56. 56. Corriger 56
  57. 57. Activer les mesures de mitigation nécessaires Y aller progressivement et se limiter au strict nécessaire 57
  58. 58. Appliquer les mesures correctives 58
  59. 59. Déployer l’application si nécessaire 59
  60. 60. En dernier recours : tout couper C’est parfois la seule solution 60
  61. 61. Le problème est réglé. Il est donc temps de… 61
  62. 62. Fêter cela ! 62
  63. 63. Fêter cela ! 63
  64. 64. Apprendre 64
  65. 65. Capitaliser le savoir acquis Un problème résolu ne doit jamais se reproduire … en théorie 65
  66. 66. Méthodes des 5 pourquois 66
  67. 67. Intégrer les résultats aux procédures de test 67
  68. 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. 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. 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

×