Introduction
Dans cet entretien, Sam Haskins partage son expérience de l'application DevOps chez Etsy. Etsy utilise Git comme système de gestion de version et met à jour son application en moyenne 30 fois par jours. Certains jours, ce nombre peut aller jusqu'à 70 par jour. Avec une aussi haute fréquence de déploiement, comment Etsy peut-elle auditer ses codes ? Comment surveille-t-elle les performances de ses applications ? Et quels sont ses processus lors de la détection d’un bug ? L’ensemble de ces questions sera évoqué dans cet entretien.
InfoQ : Sam, merci de répondre à nos questions. Quand avez-vous commencé à travailler pour Etsy ?
Sam : J’ai commencé il y a deux ans et demi comme stagiaire. J’étais encore à l’école. Lorsque j’ai été diplômé, je suis resté chez eux à plein temps.
InfoQ : Ainsi, c’est votre premier job ?
Sam : Oui, et j'ai vraiment de la chance car il est super.
InfoQ : Vous êtes DevOps, plutôt développement ou plutôt exploitation ?
Sam : Je travaille plus sur la partie développement, mais mon équipe s’occupe aussi de l’organisation développement, on est vraiment proche des ops.
InfoQ : Combien de personne y a-t-il dans votre équipe ?
Sam : On est un peu plus d’une dizaine de personnes.
InfoQ : Quel est le rôle de cette équipe ?
C’est l’équipe qui s’occupe de la plate-forme principale. Nous travaillons sur l’interface entre les serveurs et le niveau opérationnel des choses. C’est l’endroit où les personnes développent des fonctionnalités applicatives. Nos clients sont les ingénieurs développant de nouvelles fonctionnalités.
InfoQ : Mais alors quelles sont vos principales responsabilités ? Développer de nouvelles fonctionnalités ?
Sam : Je travaille principalement sur notre couche d’accès à la base de données, sur notre ORM, et aussi un peu sur notre framework web qui est en quelque sorte un rail pour nos développeurs. Les autres personnes de mon équipe développent notre application de stockage de photographies, et de management de travail asynchrone. De plus, durant les urgences, nous intervenons car nous connaissons la plupart du code de base de chaque application et c’est principalement nous qui les corrigeons.
Pouvez-vous nous parler un peu de votre système de déploiement de code ? Quels outils utilisez vous (Git, Puppet ou BT) ? Quelles sont vos procédures d’audit de code ?
InfoQ : La première question porte sur votre système de déploiement. Quels sont les outils que vous utilisez ?
Sam : Nous utilisons Git pour gérer le versionage de notre code et ensuite nous utilisons notre propre outil, le Deployinator, pour déployer les codes depuis Git. Le Deployinator copie seulement les fichiers. Rien de particulier. Mais nous utilisons Chef pour le management de la configuration. Pour conserver le code, nous utilisons GitHub. Nous avons notre GitHub personnel.
En ce qui concerne nos procédures d’audit, nous n’en avons que très peu de formelles. Ce n’est pas indispensable, donc tant que le code fonctionne, tant qu’il compile, il peut être commité, mais nous encourageons nos développeurs à faire relire leur code et ils le font souvent. La plupart du temps, c’est juste quelqu’un qui regarde le patch et donne ses commentaires. La plupart de nos développeurs font cela avant de pousser leur code sur Git.
InfoQ : Avez vous un QA ?
Sam : Non, nous n’avons pas de QA. En effet, nous travaillons souvent sur des petites parties, la plupart du temps il est facile de déterminer si on effectue de la régression de code. Par contre certaines personnes ont pour travail d’éprouver notre code. Nous faisons trop de déploiement pour avoir un QA, parfois plus de 50 par jour, voire plus. Cela serait impossible pour nous d’avoir un ensemble de QA testant nos applications, avant ou après chaque déploiement. Nous n’avons pas assez de temps. Par contre, nous utilisons des tests automatisés et des correcteurs de code. Comme nous travaillons seulement sur de petits changements, nous pensons que ce système convient mieux qu’un processus QA.
InfoQ : Quand vous sortez une mise à jour, comment contrôlez-vous l'environnement et comment sécurisez-vous le code ?
Sam: L'outil que nous avons, le Deployinator, prend la dernière version sur Git et la déploie sur nos serveurs.
InfoQ : Seulement le code source ? Pas de paquet ?
Sam : Nous, nous ne faisons pas de paquet. Je crois que ça va dans un dossier sur les serveurs web, ce n’est pas très compliqué. Nous travaillons peu comme cela. C’est très simple et cela prend seulement quelques minutes pour fonctionner, c’est pourquoi nous déployons autant.
InfoQ : 50 déploiements par jour, c'est donc votre fréquence habituelle ?
Sam : Oui. La moyenne actuelle cette année tourne autour de 30–33 déploiements par jour et cela parce que les week-ends où nous ne travaillons pas sont comptés. Je pense que notre record tourne autour de 60–70. Le minimum est de 20 à 30 par jour. C’est beaucoup, mais nous avons changé notre manière de coder pour rendre une telle chose possible. Si nous ne poussions que des changements importants, cela ne marcherait pas, et serait même désastreux. Mais nous ne travaillons que sur des petits changements, cela fonctionne à merveille.
Quelle sont vos procédures / méthodes de réponse ? Comment évaluez-vous les bugs, et quelles sont vos procédures pour les gérer à tous les niveaux ?
InfoQ : Comme vous déployez autant par jour, quand vous faites un changement, est-ce que vous l’observez pendant quelques minutes avant d’en pousser un autre ?
Sam : Bien entendu. Nous avons de nombreuses métriques. Des centaines de milliers. Et quand on fait un changement, en plus de regarder si notre changement fonctionne, nous devons regarder un dashboard synthétisant les métriques. Il y a de nombreux graphiques sur lesquels on doit jeter un œil. Nous devons surveiller le dashboard et détecter toute anomalie.
Nous avons aussi un outil pour lire les logs en live et nous sommes supposés les regarder également. Si quelque chose semble cassé, nous devons le régler. Nous ne regardons pas ces logs plus d’une minute ou deux. D’ailleurs, je devrais rajouter de nouveaux graphiques dans cette application. Si tout semble normal et que ton ajout fonctionne, le groupe d’après peut envoyer son amélioration.
InfoQ : Quand vous poussez un changement, le poussez-vous dans un environnement de test d’abord ?
Sam : On suppose que chaque développeur l’a testé de son côté avant de pousser sa modification mais nous avons un environnement de test. Cet environnement de test est sur la même plateforme que notre environnement de production. C’est le même environnement. Le code a juste une version d’avance et aucun utilisateur ne va utiliser cet environnement, excepté nous. Quand on pousse un code, on commence par le mettre dans l’environnement de test ensuite notre CO va exécuter les tests, les tests unitaires. Nous utilisons Jenkins. Et ensuite dès que tous ceux qui ont poussé un code pensent que c’est OK, qu’ils ont testé ce qu’ils avaient changé et que cela fonctionne correctement, et aussi dès que le processus Jenkins est terminé, ce qui dure environ 5 minutes au total, alors on passe en production.
InfoQ : Quand vous dites production, voulez-vous dire toutes les machines ?
Sam : Oui toutes les machines, absolument toutes. L’outil a seulement deux boutons : « test » et « production ».
InfoQ : Divisez-vous les clusters par service ? Par exemple un service, un cluster ?
Sam : Oui, en quelque sorte. Ils sont tous déployés sur une pile. Nous avons une pile séparée pour la recherche et le stockage de photographie, mais c’est tout. Nous ne faisons pas tant de services. Nous avons un seul code, qui est donc plutôt gros. C’est presque 2 GO de code. Mais la plupart du code est uniquement sur une seule pile.
Donc quand on déploie, cela va sur les serveurs web et donc aussi les API des serveurs. Nous avons un système de support interne, des tâches asynchrones, Gearman et divers outils comme Crons qui lancent des boites et des scripts. Tous cela marche en même temps.
InfoQ : Divisez-vous ces push par importance ? Vous savez certains push qui peuvent avoir un impact plus important pour les utilisateurs.
Sam : Nos développeurs travaillent de manière à empêcher que cela arrive trop souvent. Si on a quelque chose de vraiment important en cours, nous le poussons en passant devant les autres et on s’assure que l’application fonctionne. Mais normalement, nous encourageons les développeurs à développer un style de code qui empêche que cela arrive trop souvent.
InfoQ : Essayez-vous d’éviter les gros changements en une seule fois ? Préférez-vous faire des petits changements plus souvent ?
Sam : Exactement. On ne peut pas faire comme cela pour le lancement d’une nouvelle fonctionnalité. Nous utilisons un fichier de configuration où on peut activer/désactiver les fonctionnalités. Ainsi quand on lance une nouvelle fonctionnalité, il nous suffit de l’activer dans ce fichier. Mais cela ne suffit pas toujours à rendre le lancement d’une nouvelle fonctionnalité sans danger. Dans ce fichier de configuration, nous pouvons aussi configurer la fonctionnalité seulement pour nos développeurs. Nous pouvons aussi réserver son utilisation à un certain groupe de beta testeur, ou/et à un pourcentage d’utilisateurs.
Ainsi, la plupart du temps lorsqu’on change une implémentation, on l’active pour seulement 1% des utilisateurs, pour être sûr que cela ne détruit pas tout. Puis au fur et à mesure, on augmente ce pourcentage jusqu'à atteindre 100%. Si c’est une nouvelle fonctionnalité, la plupart du temps on l’active pour tout le monde mais cela nous arrive de ne l’activer que sur une certaine partie du site et de regarder son utilisation pendant quelques jours.
InfoQ : Ainsi tous les testeurs sont traités par un serveur bien particulier ?
Sam : Non c’est sur le même serveur. C’est pendant que l’application tourne que l’on vérifie leur droit grâce à leur Id.
InfoQ : Avez-vous écrit votre propre programme pour gérer cela ou utilisez-vous un programme déjà existant ?
Sam : Nous avons écrit notre propre programme. Une vieille version est Open Source. La nouvelle version est nettement meilleure et elle sera Open Source. Le projet n’a pas un très beau nom. Je crois que c’est « Feature Flags » ou quelque chose comme cela. Mais c’est sur notre page d’accueil Git.
Je peux vous parler de beaucoup d’astuces qui permettent de développer de cette manière. Nous n’utilisons que très peu de branches sur Git. Nos développeurs ne poussent pas leur code et ne travaillent pas sur des branches pendant une longue durée. Ils y travaillent seulement pendant une courte durée avant de déployer.
InfoQ : Pouvez-vous nous décrire un échec que vous avez récemment rencontré, et comment vous l’avez résolu ?
Sam : Voulez-vous que j’évoque la manière de gérer les défaillances ?
InfoQ : Oui, s’il vous plait.
Sam : Nos développeurs sont entrainés à regarder les graphiques et les logs de notre site ; on détecte les défaillances très, très rapidement. En effet nous avons toujours quelqu’un en train de regarder les métriques et nous avons beaucoup de métriques, nous savons donc comment notre système est supposé se comporter.
InfoQ : Cela semble très difficile et doit demander beaucoup de temps aux développeurs.
Sam : C’est le cas. Mais nous avons des outils comme Nagios qui vérifient que les choses restent normales. Il n’y a que peu de défaillances que nous n’arrivons pas à détecter rapidement. Elles sont presque toutes détectées instantanément. Je pense que si les choses ne vont pas mal au milieu de la nuit, c’est parce que personne ne déploie quand le reste de l’équipe n’est pas là. Le type d’erreurs rencontrées habituellement est souvent dû au système, ce que vérifie Nagios. Pendant la journée, lorsque nous travaillons, d’autres défaillances peuvent être remarquées à cause d’un déploiement récent, mais nos développeurs veillent. Donc les défaillances qui sont difficiles à percevoir automatiquement ne se passent pas la nuit.
InfoQ : Alors dites moi, si une défaillance est détectée, quelle sont les procédures habituelles que vous mettez en œuvre ?
Sam : Si quelque chose empêche le bon fonctionnement du site, nous demandons aux développeurs d’arrêter de pousser le code ; nous freinons le développement et tous essaient de résoudre le problème. Ils ont tous accès aux logs et aux graphiques. Quand nous déterminons quelle fonctionnalité est à l’origine de l’erreur, nous appelons les personnes responsables de ce code, davantage susceptibles de résoudre le problème. La plupart du temps, si cette erreur est due à un déploiement récent, les responsables sont dans les locaux. Nous utilisons IRC Chat tout le temps. Donc ils sont sur les canaux IRC. Ils sont dans les bâtiments et s’ils sont reliés au déploiement, ils regardent les métriques et savent ce qui ne va pas. La plupart du temps ils savent comment réparer l’erreur, car il ne déploie que des petites modifications. Pour les petits bugs, nous préférons aller de l’avant plutôt que de revenir sur notre ancienne version. Au lieu de revenir en arrière, on répare pour obtenir le résultat escompté.
InfoQ : Mais cela prend plus de temps.
Sam : Oui. Donc si c’est un petit problème et si c’est quelque chose que l’on peut réparer rapidement, on va de l’avant. Parce que si on revient à une ancienne version, nous devons toujours reprendre a minima le processus de déploiement qui dure 10 minutes au total. On doit refaire la phase de test avant de mettre le code en production. Donc, quoi que l’on fasse, cela durera au minimum 10 minutes. Si on passe 5 minutes à régler le problème, cela n’est pas si grave et sera mieux que de revenir à une version antérieure.
C’est ce que l’on a l’habitude de faire. Quand c’est un bug vraiment compliqué, bien entendu nous revenons à une version antérieure et réparons notre code plus tard. Mais la plupart du temps revenir en arrière ce n’est pas préférable et nous préférons plutôt réparer le vrai problème.
InfoQ : Habituellement comment faites-vous quand vous revenez à un ancienne version ?
Sam : La plupart des bugs rencontrés lors du déploiement n’affectent pas tous le site mais seulement une partie. Si on cherche à déterminer l’erreur, d’autres personnes peuvent continuer à pousser leur code pendant que vous trouvez une solution. Bien entendu vous déterminez si les autres peuvent pousser leur code en fonction de la gravité du bug.
InfoQ : Que se passe t-il si vous n’arrivez pas à réparer ?
Sam : Si on n’arrive pas à réparer, on commence le reverting.
InfoQ : Disons qu’après 10 minutes vous n’arriviez toujours pas à réparer le bug.
Sam : Ce n’est pas une règle précise, mais si les autres développeurs doivent attendre que vous répariez votre code, les autres ne pourront pas déployer. Si cela dure trop longtemps, on intervient pour que les autres personnes puissent déployer leur code le plus rapidement possible. Donc oui, si après 10 minutes vous ne savez pas où est le problème et que vous êtes sûr que revenir à une ancienne version permettra de corriger le problème, vous effectuez le retour à cette version et essayez de trouver la solution sur votre propre machine.
InfoQ : D’accord. Pouvez-vous nous décrire un bug récent ?
Sam : La plupart du temps nous ne voyons que de petits problèmes, par exemple si quelqu’un change une page. Quand un vendeur essaie de vendre un objet sur notre site, il doit éditer le nombre d’objets qui lui restent, d’accord ? Disons que quelqu’un a fait un changement sur cette page, et tout d’un coup lorsque le vendeur veut éditer son nombre d’objets une erreur apparait sans que cela empêche pour autant les autres transactions. Pour le moment on est ok. Cette personne regarde ce qu’elle a fait et essaie de le réparer. Et normalement, comme c’est une petite modification, elle trouve la solution rapidement et déploie de nouveau. Et dans le pire des cas, si c’est vraiment un gros bug, il déploie l’ancienne version.
Un exemple de bug plus sérieux, qui nous est arrivé il n’y a pas longtemps : on utilise des full id dans notre base de données. Ils ne sont pas automatiquement incrémentés. Nous n’utilisons pas notre base de données pour les créer car nous avons deux masters.
Nous avons un master de master. On ne peut pas faire une incrémentation automatique car on ne sait pas quel est le dernier master qui a incrémenté. A la place nous avons des serveurs indépendants qui nous donnent les nombres. On en a deux : un qui nous génère les nombres pairs et l’autre qui nous génère les nombres impairs. Et c’est comme cela que nous obtenons nos Id.
Il y a quelques mois, ces serveurs ont généré des Id au dessus des 2^32. On avait donc un overflow sur notre colonne 32 bits. Et cela ne devait pas poser de problème car on est supposé les garder dans un colonne 64 bits. Il y avait des endroits dans notre code de base où ce n’était pas le cas. Il y avait des fonctionnalités qui marchaient, mais qui n’étaient pas en 64 bits. Et quand un overflow apparut, ces fonctionnalités ont arrêté de fonctionner.
Donc elles ne pouvaient avoir un Id qui faisait sens. Elles essayaient de l’enregistrer dans la base de donnée qui n’aimait pas. Quand c’est arrivé, on a empêché les développeurs de pousser leurs codes. Cela nous a pris une minute pour trouver la cause du problème car grâce aux logs nous avions beaucoup d’erreurs et les Id défectueux étaient affichés. Il était facile de tracer ces Id défectueux dans les logs. Tu sais que ca ne vas pas quand tu vois le mauvais Id.
Quand on a vu ça, on a directement arrêté de pousser notre code, et mon équipe, celle qui s’occupe du cœur de la plate-forme, était celle qui a détecté l’erreur. On savait que cela pouvait être un problème grave, mais nous ne savions pas encore combien de tables avaient ce problème car on ne savait pas où regarder. Nous tous, quelques ingénieurs opérationnels et certains membres de mon équipe, sommes allés dans une salle de réunion pour nous organiser. Nous avons décidé de regarder dans chaque table pour identifier lesquelles avaient des colonnes Id mal formatées.
Nous avons écrit nos structures et notre code comme dans la base de données. On a du parcourir notre code et déterminer combien de structures étaient fausses. Certaines étaient seulement fausses dans le code, d’autres dans la base de données et parfois les deux. On a donc commencé à lister chaque endroit ainsi que la manière dont il fallait les corriger. Par ailleurs, d’autres personnes étaient chargées de repérer quelles fonctionnalités ne marchaient pas, grâce aux erreurs dans les logs ou en raison de graphiques mauvais. Par la suite, ils désactivaient les fonctionnalités ne marchant pas grâce aux fichiers de configuration.
Quand on a été capable de déterminer tout ce que l’on devait changer, on a lancé notre correction de table dans la base de données, qui a changé toutes les colonnes concernées en 64 bits, puis nous avons remis en marche les fonctionnalités et avons commencé à regarder quelles données auraient pu être corrompues. Tout ce processus n’a duré que quelques heures, et seules de petites fonctionnalités ont vraiment été affectées. Mais ne savions pas combien de fonctionnalités avait été endomagées avant de finir de les réparer, ce n’était pas évident.
InfoQ : C’est plutôt une réparation rapide.
Sam : Oui. Et c’était une des pires. Je ne pense pas que nous avons eu beaucoup de problèmes ces dernières années, tout au plus trois heures d’indisponibilité de nos serveurs et cela arrive vraiment très rarement. C’est vraiment grave quand cela arrive.
A propos de monitoring, comment gérez-vous la surveillance de la performance de vos réseaux ? Et du côté application comment évaluez-vous l’expérience des utilisateurs ?
InfoQ : Comment surveillez-vous vos serveurs ? Particulièrement la surveillance des performances de votre réseau, et de vos applications ?
Sam : A propos de la performance de notre réseau, je pense que nous utilisons quelque chose comme Cacti. Nous utilisons Cacti et un autre outil que nous avons écrit. Je crois qu’il est Open Source et qu’il s’appelle FITB.
FITB regarde les échangeurs et garde les métriques petites. Oui, je sais, c’est un peu comme Cacti. Je ne me rappelle plus très bien la différence entre ces deux outils, je n’ai pas l’habitude de regarder les métriques du réseau, mais nous utilisons ces deux outils. Nous avons très rarement des problèmes de réseau. Nous avons beaucoup de capacité.
InfoQ : Quels sont les principaux goulots d’étranglement dans votre système ?
Sam : la plupart du temps nous utilisons une base de données ou un cache mémoire. Récemment, nous avons eu des problèmes avec la mémoire cache qui était reliée au réseau. Il y avait une clef particulière qui renouvelait la mémoire cache que beaucoup de personnes avaient besoin d’utiliser et notre trafic a augmenté récemment aux Etats-Unis. C’était le « Cyber Monday ».
Donc, notre trafic était vraiment élevé et il y avait cette clef qui était utilisée de nombreuses fois car un des serveurs cache mémoire saturait les connections réseaux. Nous avons résolu ce problème en ne sauvegardant pas cette clef dans la mémoire cache. Elle n’avait aucune obligation d’y être et nous l’avons enlevée. C’était du mauvais code, mais nous ne nous en sommes pas rendus compte avant que la carte réseau soit saturée.
Mais nous utilisons Cacti et – je ne connais pas tous les tenants et aboutissants de tout ça, ni à quelle fréquence nous regardons les données – mais je suis sûr que nous utilisons Nagios sur cette donnée pour vérifier si tout va bien.
A propos de la partie cliente, nous avons notre propre ensemble de balises qui loguent les actions que les utilisateurs font sur notre site ; cette information est enregistrée dans une pile de données. Donc pour surveiller le comportement de nos utilisateurs nous disposons de notre cluster Hadoop. Nous recherchons, à partir de ces données, des patterns tels que : l’utilisateur a chargé la page d’accueil, a cliqué sur cet objet puis a quitté le site. Nous logons aussi les erreurs JavaScript du front-end que nous envoyons au back-end. Nous avons souvent des tests de performance ainsi que sur les pages du site. Nous utilisons ces résultats pour savoir si les performances sont bonnes ou pas.
Nous corrélons aussi les métriques de l’application et les actions des utilisateurs. Nous avons donc des métriques sur les paniers des utilisateurs qui nous servent de mesure pour savoir comment les utilisateurs utilisent notre site. Si certaines fonctions ne sont pas utilisées depuis longtemps, nous essayons d’améliorer l’expérience utilisateur. Nous faisons aussi des graphiques sur notre FAQ. Si nous constatons que de nombreuses personnes posent les mêmes questions, alors nous faisons évoluer. Et bien sûr nous leur répondons. Nous communiquons souvent avec eux, ce qui nous permet de déterminer les problèmes des utilisateurs qui fréquentent notre site.
A propos de l’interviewé
Sam Haskins travaille actuellement dans l’équipe Core Platform d'Etsy, qui se concentre sur l’interface entre les serveurs et la problématique opérationnelle. Sam a rejoint Etsy à mi 2010 et travaille en particulier sur l’accès aux bases de données. Sam est diplômé de Carnegie Mellon University en mathématiques.