• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Reprise sur incident - ConFoo 2012
 

Reprise sur incident - ConFoo 2012

on

  • 1,073 views

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

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

Statistics

Views

Total Views
1,073
Views on SlideShare
1,073
Embed Views
0

Actions

Likes
1
Downloads
17
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Reprise sur incident - ConFoo 2012 Reprise sur incident - ConFoo 2012 Presentation Transcript

    • Reprise sur incident ConFoo 2012
    • 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
    • Cela va arriver ! 3
    • Diminuer la portéeLimiter le périmètre du problème ‣ Indisponibilité ‣ Perte de données ‣ Rupture de la confidentialité 4
    • Minimiser l’impactLimiter les conséquences du problème ‣ En terme financier ‣ En terme d’image 5
    • Se préparer 6
    • “Les plans ne sont rien; cest laplanification qui compte” Dwight Eisenhower 7
    • Avoir un plan 8
    • Se préparer à être efficace le jour JConnaître son rôle et ses actions 9
    • Avoir une équipe spécialiséeCellule transverse de crise 10
    • Mesures de mitigation 11
    • Machines virtuellesPossibilité d’augmenter très rapidement la capacité 12
    • Base de donnéesRéplication master/slave 13
    • Feature flippingDésactivation de fonctionnalité pour préserver lecœur de l’activité 14
    • Version statiqueTout ou partie du site devient statique pour être servitrès rapidement 15
    • Sauvegardes 16
    • Sauvegarder toutChaque élément manquant dans la sauvegarde estun élément perdu en cas de problème 17
    • Sauvegarder régulièrementIl faut éviter d’avoir une trop grande différence entrela production et la dernière sauvegarde 18
    • Vérifier les sauvegardesUne sauvegarde peut être inutilisable. On doit doncla vérifier régulièrement. 19
    • Garder un historique intelligentIl est inutile d’accumuler les sauvegardes sansdiscernement 20
    • Journalisation 21
    • Que journaliser ?L’activité système, celle des applications, lesdéploiements, opérations de maintenance 22
    • Etsy 23
    • Privilégier les fichiers platsIls sont plus facilement manipulables 24
    • Déporter les logsLa centralisation des logs permet de mieux lesaggréger 25
    • Communiquer en interne 26
    • Certains pics de fréquentations sontanticipablesPériode de lannée, publicité, promotion,ommunication dans les médias 27
    • Déploiement automatisé 28
    • RapideUn script ira toujours plus vite qu’un humain 29
    • Pas sujet à la pressionLa criticité du problème n’impactera en rien letravail du script 30
    • Tester les procédures 31
    • RégulièrementRien ne vaut une mise en situation 32
    • Avec précautionNe surtout pas impacter la production 33
    • Détecter 34
    • Supervision 35
    • Surveiller les ressources 36
    • Surveiller les journauxY chercher des indices de problèmes 37
    • Surveiller l’applicationEst-elle disponible pour les utilisateurs 38
    • Faciliter le contactVos utilisateurs sont autant de sondes de surveillance 39
    • Communiquer 40
    • Isoler léquipe dinterventionToute leur énergie doit être mobilisée pour régler leproblème 41
    • Parefeu humainLa communciation ne doit pas être faite par l’équiped’intervention 42
    • Amazon Web Services 43
    • Twitter 44
    • Analyser 45
    • Identification de la cause 46
    • InternePanne matérielle, instabilité logicielle, bogueapplicatif, erreur humaine, etc. 47
    • ExterneAttaque, panne matérielle, pic de fréquentation, etc. 48
    • Identification de la portée 49
    • Quels sont les services touchés ? 50
    • Le service est-il réduit voire coupé ? 51
    • Identification de l’impact 52
    • Problème de sécurité ? 53
    • Perte de données ? 54
    • Atteinte à l’image ? 55
    • Corriger 56
    • Activer les mesures de mitigationnécessairesY aller progressivement et se limiter au strictnécessaire 57
    • Appliquer les mesures correctives 58
    • Déployer l’application si nécessaire 59
    • En dernier recours : tout couperC’est parfois la seule solution 60
    • Le problème est réglé.Il est donc temps de… 61
    • Fêter cela ! 62
    • Fêter cela ! 63
    • Apprendre 64
    • Capitaliser le savoir acquisUn problème résolu ne doit jamais se reproduire …en théorie 65
    • Méthodes des 5 pourquois 66
    • Intégrer les résultats aux procédures detest 67
    • 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
    • Merci ! ‣ Commentaires et slides : https://joind.in/6086 ‣ Blog : http://www.industrialisation-php.com/ ‣ Twitter : @jmfontaine / @indusphp ‣ Email : jean-marc.fontaine@alterway.fr 69
    • 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