Ma présentation du #WAQ15

1. Quelque part au 21e siècle
WAQ
Bien qu’en ligne
Votre site n’est probablement pas en production

2. À propos
• Web depuis 2003
• Mandats pour toute sorte de clients
• Dev frontend, dev backend, directeur
techno
• Maintenant s’occupe que les choses soient
up (un monde assez étrange)
• @marcboivin

3. • Cette présentation est basée sur des erreurs que j’observe depuis 2 ans;
• Si vous avez fait ces erreurs, sachez que je n’ai rien contre vous #biglove;
• Je déteste les PowerPoints (c’est d’ailleurs un Keynote);
• La structure n’est pas mon forte;
• Laissez-moi vous poser quelques questions afin d’ajuster mon « geek knob »
Avant de commencer

4. Alors vous êtes en ligne…

5. Jusqu’au moment où…

6. … vous n’êtes plus tant en
ligne :
Hacké
Erreur de code
Surcharge du serveur
Mise à jour ratée
L’internet est mort?

7. • Votre site est sur une infrastructure qui va tomber;
• Sur un logiciel qui ne tolère pas les erreurs, dans un environnement ou les
données se corrompent toute seule;
• Et ou une durée de vie de 2 ans est plus qu’excellente.
Soyons brutalement honnêtes

8. Crédit @stephaniesalman pour l’inspiration
…sans offense

9. Date
Uptime et visibilité
Comment avoir un site en
productions (le gros minimum)

10. « If you’re not monitoring something it is out of control »
-Jonh Wikes, PSE, Google

11. • Au minimum : un script quelque part qui valide que le serveur ping
• ping www.example.com
• Pour un site vignette : un service comme server density
• On parle du DNS, de redirections et que les noms de domaines arrivent
quelque part
Surveillance du site

12. • Codes de retour
• Le titre de votre page
• Le temps de réponse
• Les entêtes HTTP
• Au minimum : un des 50 000 services SaaS, ou, un script bash dans une cron
Surveillance du serveur web

13. • Mises à jour de sécurité
• SURTOUT pas les mises à jours recommandées
• Valider pour les erreurs dans les mises à jour
• Je vous encourage à ne pas faire ça sur du Windows
• Au minimum : un cron, comme apt-cron qui vous envoi un mail
S’assurer des mises à jour

15. • Une vrai sauvegarde est :
• Complète
• Peut-être validée
• Utilisable par le client
• Adapté à son environnement (OS, contrainte spécifiques)
• Au minimum : un genre de rsync bancale (au moins il y aura quelque chose)
Une sauvegarde, une vraie

16. • HA (high availability : Haute disponibilité)
• Buzzword des 2-3 dernières années
• C’est le future
• Si vous avez des VRAIES web app, go for it
• Votre CMS N’EST PAS HA arrêtez, maintenant.
Oui mais pourquoi pas du HA?

17. • Si jamais vous faite du HA pareil :
• Fail hard (pas de demie état)
• Fail fast
• Don’t look back
Juste au cas

18. • Un git de production
• etckeeper
• binlog, wal ou autre pour votre BD
• UN README, utile et utilisable (we’ll find your secret sauce, might as well
share)
Donc des mécanismes de secours

19. « Stop writing tutorials -
start writing Vagrantfiles or Dockerfiles »
-Hendrik Volkmer

20. • Si votre CMS prends plus de 30 minutes à remonter X
• Si seulement votre fournisseur peut remonter votre site X
• Si déployer une mise à jour demande une planif en
heures et non en minutes X
• Au minimum: un Vagrantfile avec des bash scripts
« Reproduisible »

21. • Il arrive quoi si ma BD plante
• Il arrive quoi si mon serveur web plante
• Il arrive quoi si ma cache plante
• Est-ce que mon site est affecté si Facebook est down?
• On fait quoi s’il y a une sauvegarde corrompue?
• Minimum : un petit « disaster recovery plan »
Prévisible

22. • Il y a des gens qui s’occupent de tout ça pour vous. On appel ça du managed
hosting (validé quand même un peu avant)
• Un webmestre devrait être au courant des mécanismes en place pour chacun de
ses aspects. Pas d’excuse! C’est votre site.
• Livrer quelque chose qui ne couvre pas ces aspects, en production, c’est juste
amateur, sorry mate!
• Le cloud transforme la manière de développer, mais on est pas encore là dans le
domaine du service, désolé à tous.
Petites pensées de la fin

23. Questions ?
Merci !