Reprise sur incident - ConFoo 2012

1 401 vues

Publié le

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

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 401
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
25
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Reprise sur incident - ConFoo 2012

  1. 1. Reprise sur incident ConFoo 2012
  2. 2. Jean-Marc FontainePassionné de web depuis 1996, de PHP depuis 2000 et demusique 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éeLimiter le périmètre du problème ‣ Indisponibilité ‣ Perte de données ‣ Rupture de la confidentialité 4
  5. 5. Minimiser l’impactLimiter 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; cest laplanification qui compte” Dwight Eisenhower 7
  8. 8. Avoir un plan 8
  9. 9. Se préparer à être efficace le jour JConnaître son rôle et ses actions 9
  10. 10. Avoir une équipe spécialiséeCellule transverse de crise 10
  11. 11. Mesures de mitigation 11
  12. 12. Machines virtuellesPossibilité d’augmenter très rapidement la capacité 12
  13. 13. Base de donnéesRéplication master/slave 13
  14. 14. Feature flippingDésactivation de fonctionnalité pour préserver lecœur de l’activité 14
  15. 15. Version statiqueTout ou partie du site devient statique pour être servitrès rapidement 15
  16. 16. Sauvegardes 16
  17. 17. Sauvegarder toutChaque élément manquant dans la sauvegarde estun élément perdu en cas de problème 17
  18. 18. Sauvegarder régulièrementIl faut éviter d’avoir une trop grande différence entrela production et la dernière sauvegarde 18
  19. 19. Vérifier les sauvegardesUne sauvegarde peut être inutilisable. On doit doncla vérifier régulièrement. 19
  20. 20. Garder un historique intelligentIl est inutile d’accumuler les sauvegardes sansdiscernement 20
  21. 21. Journalisation 21
  22. 22. Que journaliser ?L’activité système, celle des applications, lesdéploiements, opérations de maintenance 22
  23. 23. Etsy 23
  24. 24. Privilégier les fichiers platsIls sont plus facilement manipulables 24
  25. 25. Déporter les logsLa centralisation des logs permet de mieux lesaggréger 25
  26. 26. Communiquer en interne 26
  27. 27. Certains pics de fréquentations sontanticipablesPériode de lannée, publicité, promotion,ommunication dans les médias 27
  28. 28. Déploiement automatisé 28
  29. 29. RapideUn script ira toujours plus vite qu’un humain 29
  30. 30. Pas sujet à la pressionLa criticité du problème n’impactera en rien letravail du script 30
  31. 31. Tester les procédures 31
  32. 32. RégulièrementRien ne vaut une mise en situation 32
  33. 33. Avec précautionNe 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 journauxY chercher des indices de problèmes 37
  38. 38. Surveiller l’applicationEst-elle disponible pour les utilisateurs 38
  39. 39. Faciliter le contactVos utilisateurs sont autant de sondes de surveillance 39
  40. 40. Communiquer 40
  41. 41. Isoler léquipe dinterventionToute leur énergie doit être mobilisée pour régler leproblème 41
  42. 42. Parefeu humainLa communciation ne doit pas être faite par l’équiped’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. InternePanne matérielle, instabilité logicielle, bogueapplicatif, erreur humaine, etc. 47
  48. 48. ExterneAttaque, 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 mitigationnécessairesY aller progressivement et se limiter au strictné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 couperC’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 acquisUn 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 detest 67
  68. 68. Se préparerCe n’est pas le jour J qu’il faut commencer à chercher des solutions 1CommuniquerLa communication est primordiale mais ne doit pas nuire à la résolution 2AnalyserPrendre le temps de comprendre le problème 3CorrigerIntervenir de manière précise et efficace pour corriger le problème 4ApprendreAccumuler 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 photographiquesLes photos et illustrations suivantes ont été utilisées dans cettepré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

×