QCon London 2014, day One

Introduction

J'ai découvert la QCon en allant à la QCon London 2014. En plus d'un cadre fantastique en plein cœur de Londres, on a eu le droit à des conférences passionantes. Je n'ai pas fait de compte-rendu des keynotes, qui étaient plus de l'entertainment (à la TED) et qui méritent plus d'être vues en vidéos que racontées à l'écrit.

Je retiendrai surtout de cette QCon la qualité de l'outillage d'Etsy et le niveau d'excellence qu'ils ont.

How outages shaped Etsy's architecture

Après chaque problème en prod chez Etsy, ils font des post-mortem publics. Tout le monde est invité à venir voir pourquoi ça a planté, et comment on fait pour éviter que ça se reproduise. Tous les post-mortem sont "no blame", si quelqu'un a été assez confiant pour pusher en prod et que ça a planté, c'est que le système ne possède pas assez de vérifications, il faut donc améliorer le système plutot que de pointer quelqu'un du doigt.

Ils ont même un outil (open-source) nommé morgue qui permet d'historiser les fails et de voir leur fréquence, ceux qui reviennent souvent, ceux qui ont des causes communes, etc.

Leur motto est que "There is no such thing as human error when building resilient systems". Ca veut dire que si on veut un système qui résiste aux erreurs, et bien il faut des erreurs pour pouvoir s'y adapter.

Parmis les solutions qu'ils donnent pour réussir à éviter et/ou plus facilement se relever d'une erreurs :

• Les équipes doivent connaitre le code des autres équipes. Il est très difficile de trouver une erreur avant qu'elle n'arrive en prod si chacun ne regarde que le code de sa team.

• Ils releasent en open-source tout ce qu'ils font qui peut aider. Ca permet de rendre aux autres ce qu'ils ont appris de l'open-source et permet d'améliorer leurs outils.

Ils ont une batterie de test avant la mise en prod, et des code reviews. Néanmoins certaines choses peuvent quand même peter en ligne, comme par exemple une modification de code qui est impactée par une modif de l'archi (exemple d'un script qui s'attendait à remplir la mémoire de 4Go mais qui a rempli la mémoire upgradée de 32Go).

La suite de la prod était une suite de leurs fails en prod, mais c'était très spécifique à leur config et peu utilisable tel quel :

Ils avaient un sharding de couples master/master en mysql, plus un serveur global mysql qui contient leur dbIndex pour retrouver le noeud du shard en fonction de l'id de l'objet. Mais ils ont aussi utilisé ce même serveur pour garder leurs logs, qui à cause d'un incident en prod ont explosés, qui ont tué le serveur et re-fait péter la prod.

Ils ont eu un tweet-pocalypse aussi en ayant utilisé toute la place nécessaire pour les int à cause d'un auto-increment.

Development, Deployment and Collaboration at Etsy

Etsy est construit sur une stack LAMP classique, avec un Master/Slave MySQL. Le tout dans une app monolithique, qui comporte à la fois le site public et leur interface d'admin. Néanmoins, ils parviennent à déployer tout ça environ 50 fois par jour.

Ils emploient abondamment le feature flipping. Ils ont en fait un énorme fichier de config PHP qui contient la totalité de leurs configs, et il est interdit de déployer quelque chose qui modifie à la fois le code et la config. Dans leur process, ils poussent régulièrement du code en cours de conception sur la prod, mais qui n'est pas forcément activé, et ils l'activent petit à petit à une certaine partie de leurs utilisateurs, progressivement, en gardant les deux versions en parallelle jusqu'à ce que la nouvelle est été déployée à toute la population, et à ce moment seulement ils enlevent l'ancienne version de la code base.

Chaque développeur possède une VM avec les recettes Chef qui vont bien pour déployer en local une copie conforme du site. Même OS, même version de php, même config. Seule la base de donnée est réduite. Comme ça chaque dev peut voir l'impact de son code sur la totalité de la stack et l'excuse "Works for me" ne marche plus.

Ils ont aussi un outil en interne qui permet de télécharger des VM pré-configurés de différents tailles (il est parfois nécessaire de faire des tests avec une plus grosse db, avec plus d'images, etc).

Ils utilisent une batterie de Jenkins (~400) en parallelle pour executer leurs tests. Ceux-ci sont installés dans des containers LXC, répartis sur trois disques SSD. Certains builds Jenkins sont marqués comme heavy et seulement un build heavy peut être executé sur un SSD à la fois, les autres sont executés en parallelle du moment qu'il reste des resources.

Ils possèdent aussi un environnement nommé Princess qui est une copie à l'identique du site de prod, avec exactement la même config, même serveur, même database, mais qui n'est accessible qu'en interne. C'est sur cette version que les tests d'intégration sont executés. Si ça passe sur Princess, ça passera en prod.

Ils utilisent aussi un outil nommé "try" qui va créer un patch de leur branche actuelle, l'appliquer sur la branche master, lancer la batterie de tests et reporter le résultat. Ca leur permet de lancer leur batterie de tests sans pourrir l'Intégration Continue.

Le déploiement chez Etsy n'est pas sale, ni compliqué, et ne fait pas peur. Tous les nouveaux développeurs sont invités à déployer dès leur premier jour, grâce à leur outil interne nommé Deployinator. Il permet de déployer en un clic, indique l'historique des déploiement passés ainsi que la version actuellement déployé sur chaque environnement.

Ils ont un dashboard qui affiche des graphs sur plein de choses, beaucoup de choses. A la question "Should I graph that ?", la réponse est toujours Yes. L'outil est accessible à tout Etsy et indique par exemple le nombre de login, logout, inscriptions, paiement, erreurs 404, etc. Si une courbe devient anormale, ça veut dire que quelque chose ne se passe pas normalement.

La totalité des logs de tous leurs serveurs sont agrégés et streamés sous forme d'appli web (Supergrep++), accessible à tous, avec possibilité de filtrer les logs. Un autre outil similaire, Supertop, est aussi accessible.

Chaque année, ils félicitent le dev qui a pété la prod de la manière la plus originale possible. Ils ont par exemple explosé la mémoire disponible sur leurs serveurs simplement en supprimant un fichier CSS. Il s'avère qu'il était utilisé sur la page d'erreur, qui le chargeait, qui donc chargeait la page d'erreur, qui chargeait le css, etc. Ce genre de bug montre que le système n'est pas complétement maitrisé et qu'il y a moyen de s'améliorer.

Ils font des Post-Mortem après les urgences en prod, où tout le monde peut venir, et où le motto est "No Blaming". La question est "Pourquoi la personne qui a pushé pensait que ça n'allait rien péter ?". L'outil ne doit pas permettre de pousser quelque chose qui va peter, si ça a été possible, il faut donc améliorer l'outil, pas punir les gens.

Il n'y a pas que les ops qui peuvent etre d'atsreinte. Ils ont des équipes d'astreinte pour les devs, le payment, le support aussi. Chacun est d'astreinte une semaine toutes les 4 semaines. Ca veut dire en cas de prob sur la prod, s'en occuper en priorité (en moyenne 1 ou 2 probs par semaine).

Si le probleme a lieu juste après un deploy, on appelle un dev car c'est sans doute lié à du code pushé. Si c'est à un autre moment, on appelle un ops.

Il est interdit de déployer avant 7AM ou après 10PM.

De la même manière qu'on utilise les mailing list interne à Octo, ils ont une centaine de channels irc, sur différents sujets. Ca leur permet de coordonner facilement les choses au travers de l'entreprise sur un sujet donné.

Par exemple, leur channel #warroom est là où tout le monde va en cas de problème majeur sur le site. Le topic indique la source des problème et est mis à jour dès qu'une nouvelle info est trouvée, de manière à ce que chacun puisse être tenu au courant des soucis. C'est plus facile pour se coordonner, partager l'information, etc.

Chaque semaine, ils font un BBL (pizza payée par Etsy) où un membre de la boite présente une partie sur laquelle il travaille (pas forcément du code, peut etre paiment, support, etc) pour que tout le monde ai une vue d'ensemble.

Chacun est encouragé à visiter les datacenters, à s'inscrire comme "touriste" sur l'astreinte (pour voir à quoi ressemble un probleme en prod quand ça arrive, mais sans avoir besoin d'aller le corriger).

Après un 1 an à Etsy, on devient un Senior, et on doit alors passer 1 mois par an dans une équipe complétement différente de la sienne.

How you can trust crypto

Rappel de quelques fondamentaux en crypto. Ou plutot de dire que la crypto c'est très difficile et qu'il faut vraiment etre un expert pour savoir ce que l'on fait, et que c'est très facile de faire n'importe quoi.

C'est toujours un compromis entre le rêve du cryptographe et le real world, l'équilibre à trouver entre sécurity et convenience.

Il faut bien faire la différence etre les algorithmes de crypto qui existent, mathématiquement, et leurs implémentations dans les différentes librairies des différents langages.

Les librairies propriétaires en closed sources sont déjà très dangereuses, à éviter complétement, mais les libraires open-sources ne sont pas forcément mieux (cf. les 10 millions de $ payés par la NSA à RSA pour laisser par défaut un random generator possèdent une backdoor).

Une bonne API doit avoir des paramètres par défaut qui sont sains. Facile à faire les choses bien, difficile de faire n'importe quoi. Ne doit pas utiliser les vieilles méthodes (legacy) qui avaient une limite sur la taille des clés à cause d'une législation américaine.

PKCS#11 est trop vieux, limite sur la taille des clés. SHA1 est trop faible. Et la spec est trop lache, trop de détails sont laissés et les implémentations sont toutes différentes.

Attention à OpenSSL, qui est un projet initié par un gars initialement pour apprendre. Le code source contient encore une 40aine de TODO/FIXME.

W3C a proposé une crypto API, qui partait sur de bonnes bases, mais qui à cause du support de SSL legacy a été obligé de permettre des clés faibles. Néanmoins, les defaults sont bons.

NaCl utilise des primitives qui semblent très robustes, créé par Dan Berstein. Le soucis est qu'il n'y a pas assez de reviews officielles, scientifiques dessus, donc difficile de savoir si c'est vraiment robuste.

Eviter les implémentations mathématiquement trop peu connues, car l'intéropérabilité va etre un cauchemar.

Le quantique n'est pas la solution pour la crypto dans le futur car il n'y a actuellement que 3-4 personnes au monde qui sont capables de comprendre la crypto quantique, c'est donc assez dangereux de faire confiance sur un sujet aussi important uniquement à une poignée de personnes.

Pour finir, "Security is fractal", on peut se pencher sur n'importe quelle partie de la sécurité et trouver des challenges énormes aussi important que ceux de la big picture.

En quelques mots : - Open and not Proprietary - Avoid legacy - Check out common pitfalls - Review by others

BladeRunnerJS

Les gars de BladeRunnerJs travaillent sur une grosse application front de trading. Ils ont une énorme codebase, plein de développeurs, dans différents pays, depuis plusieurs années et ils ont bien sur du mal à maintenir tout ça.

Ils ont donc des besoins de structure du code, facilité à trouver les fichiers responsables d'une feature, besoin d'avoir une UI cohérente sur l'ensemble des features. Ils ont aussi besoin qu'il soit facile pour de nouveaux arrivants de comprendre le code, et pour d'anciens de contribuer sur d'autres parties.

Ils résolvent cela grâce à des guidelines de code communes, et pour que chacun puisse lancer la totalité de l'appli, ils ont des mocks de chaque partie. (pour le coup, c'est une approche complétement contraire à Etsy qui instancie une copie-conforme du site de prod dans une VM pour chaque developpeur).

Jusque là, leurs problèmes sont normaux, et on a les mêmes. Mais ils ont mis en place leur propre solution, nommée BladeRunnerJs.

C'est un ensemble de conventions de nommages et un serveur nodeJS qui tourne par dessus pour pouvoir lancer leur appli en mockant chaque component qui n'est pas utilisé.

Globalement leur solution est bien pensée et réponds sans doute à leur besoin, mais elle est en version 0.4 et si on veut l'utiliser il faut se plier à des tas de leurs conventions qui marchent bien dans leur framework mais qui rendent les fichiers inutilisables à l'exterieur. Au final, pas convaincu.

Tags : #qcon

Want to add something ? Feel free to get in touch on Twitter : @pixelastic