bien qu'en ligne votre site web n'est probablement pas en production
TRANSCRIPT
Quelque part au 21e siècle
WAQ
Bien qu’en ligneVotre site n’est probablement pas en production
À 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
• 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
Alors vous êtes en ligne…
Jusqu’au moment où…
… vous n’êtes plus tant en ligne :Hacké
Erreur de code
Surcharge du serveur
Mise à jour ratée
L’internet est mort?
• 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
Crédit @stephaniesalman pour l’inspiration
…sans offense
Date
Uptime et visibilité
Comment avoir un site en productions (le gros minimum)
« If you’re not monitoring something it is out of control »
-Jonh Wikes, PSE, Google
• 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
• 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
• 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
• 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
• 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?
• Si jamais vous faite du HA pareil :
• Fail hard (pas de demie état)
• Fail fast
• Don’t look back
Juste au cas
• 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
« Stop writing tutorials - start writing Vagrantfiles or Dockerfiles »
-Hendrik Volkmer
• 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 »
• 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
• 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
Questions ?Merci !