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 !