DevOps @ Rafter

L'amorce

Au cours des 6 dernières années, j'ai eu le privilège rare d'assister à l'essor de notre entreprise, de voir l'initiative d'une paire de collègues fraichement diplômés, partis avec l'idée simple de louer des manuels scolaires, donner naissance à une entreprise importante et mature. Rétrospectivement, j'ai tendance à distinguer deux phases dans la croissance que nous avons connue : avant et après le financement de Série A. Contrairement à la plupart des startups dont on peut entendre parler, nous avons eu une période pré-"Série A" plutôt longue, presque 3 ans.

Durant cette phase de notre croissance, nous n'avons pas engagé beaucoup de ressources sur DevOps. Nous nous sommes même très peu préoccupés du sujet car nous étions plutôt concentrés sur l'élaboration de notre produit. Globalement, sur ces premières années, je me considérais comme un ingénieur en développement logiciel qui avait à passer quelques jours par mois sur des tâches d'administration système.

Nous plaisantions toujours sur le fait que j'étais celui qui avait été tiré à la courte paille et qui était "collé" à la gestion des serveurs. Mais, en toute honnêteté, cela ne me déplaisait pas. Pour autant, à l'époque, il ne m'est jamais venu à l'esprit que ma passion pour le développement logiciel pourrait être appliquée à la gestion de nos serveurs.

Faire au plus simple (autant que possible)

Il y a quelques explications au fait que, durant les premiers temps, nous nous en sommes sortis sans trop porter d'attention à DevOps. En grande partie, c'est parce que nous étions une entreprise de petite taille et que nous nous efforcions de ne trop rien bouleverser. Nous avions choisi une architecture simple et avions un nombre d'applications assez réduit, donc, même si nos produits évoluaient, nous n'exercions que peu de changements sur l'architecture sous-jacente.

Surinvestir

Ensuite, assez rapidement, nous avons investi en grande quantité dans le matériel pour les serveurs. Nous aurions probablement pu faire tourner tout notre site sur 2 serveurs physiques. Nous en avons pris 10. Cela nous a permis de ne pas perdre de temps à nous inquiéter au sujet de la performance ou de l'évolution de l'infrastructure. Et effectivement, cela a pris plusieurs années avant que nous nous heurtions aux limites de cet investissement initial en matériel. Il y a eu, évidemment, des coûts initiaux pour la configuration des serveurs, mais une fois cela fait, nous avons eu très peu de modifications à y apporter.

Choisir les bon outils

Enfin, ayant choisi Ruby On Rails comme Framework pour nos applications, nous avons été confrontés tôt à des outils qui nous ont permis d'adopter de bonnes pratiques en matière de livraisons et déploiements, comme Git, Capistrano et TeamCity. Nous avons aussi construit au-dessus de solutions open source stables et bien testées, telles que nginx, MySQL et memcached.

Pouvoir profiter de tous ces outils et Frameworks nous a permis de ne pas avoir à construire nous-mêmes de solutions complexes et propriétaires qui, selon moi, finissent trop souvent par ralentir les développements, au fur et à mesure que l'entreprise croît.

La croissance

Au moment où nous avons atteint notre deuxième phase de croissance, nous avons significativement étoffé nos équipes produit et ingénierie. L'époque où nous étions deux ingénieurs était révolue. En un clin d'œil, nous nous sommes retrouvés à 10, puis à 20 à travailler sur les différents projets, en cours et nouveaux. Comme on peut l'imaginer, la quantité de changements à laquelle il fallait faire face a elle aussi augmenté significativement. Le nombre d'applications qu'il nous fallait héberger sur notre infrastructure matérielle a doublé, puis triplé, et les développeurs ont commencé à vouloir utiliser de nouveaux types de Frameworks applicatifs, de nouveaux langages de programmation, de bases de données, de systèmes de queuing, de serveurs de caches, etc.

Avec cette complexité supplémentaire, le coût des erreurs et incidents a augmenté également. Il est devenu rapidement évident que nous ne pourrions pas suivre le rythme en persistant dans notre ancienne façon de procéder, en continuant à configurer manuellement notre infrastructure. Le manque de maturité et de flexibilité quant à notre gestion de la couche d'infrastructure allait commencer à causer des problèmes, à la fois en ralentissant la sortie de nouveaux produits et fonctionnalités mais aussi en mettant en danger notre stabilité. Cette prise de conscience m'a détourné des développements sur nos produits pour m'amener à me consacrer à l'automatisation, à la supervision et aux processus de livraison à plein temps.

Cuisiner avec Chef

Par chance, alors que nous en étions à réaliser cette nécessité de développer des pratiques DevOps au sein de notre entreprise, nous avons découvert Chef, d'OpsCode, ainsi que toute la philosophie de l'"infrastructure as code". Pour commencer, nous avons passé plusieurs mois à écrire tous les modes opératoires, les recettes Chef, pour l'automatisation de chaque élément de l'infrastructure existante. Ceci fait, nous étions capables de remonter tous nos serveurs à partir de ces recettes, ce qui nous a soulagés d'un poids considérable. Tous nos serveurs s'installaient alors de façon cohérente et nous avions enfin un endroit où n'importe qui dans l'équipe pouvait voir précisément comment chaque élément de l'infrastructure était installé et configuré. Ceci nous a aussi permis, et c'est tout aussi important, de pouvoir intégrer rapidement et de façon relativement aisée de nouvelles ressources.

Une équipe DevOps est née

DevOps a commencé à prendre une place toute particulière au sein de notre organisation, à fournir des fonctions de support applicatif critiques pour nos lignes produits et à permettre que notre infrastructure continue à suivre notre expansion. Pour répondre à ces aspects très prioritaires, nous avons construit des outils et des produits permettant de gérer l'infrastructure, qui avait elle-même besoin d'être supportée et améliorée. Au début particulièrement, l'intégration de nouvelles applications à notre infrastructure impliquait souvent des modifications de l'automatisation sous-jacente. Le nombre de requêtes liées à DevOps faites par nos clients internes, collègues de l'ingénierie ou des opérations, a aussi fortement augmenté, étant donné que de plus en plus de monde s'appuyait sur notre travail.

En ce qui concerne l'ingénierie, notre organisation étant déjà découpée en équipes produits, chacune concentrée sur des éléments distincts du business. Nous avons décidé de confier la responsabilité des pratiques DevOps à une équipe à part entière, que nous avons créée au sein de notre organisation. Ceci nous a permis de dédier des ingénieurs à plein temps à la résolution des problèmes d'infrastructure. La disponibilité et la fiabilité de notre plate-forme applicative étant extrêmement importante, le moindre incident ou problème peut avoir de gros impacts. Nous avions donc besoin d'être sûrs de la présence et de la disponibilité d'ingénieurs dédiés et bien entrainés pour nous assister et investiguer, particulièrement pour les problèmes concernant plusieurs équipes ou ceux qui ne sont pas triviaux.

Les fruits de l'automatisation

Provisionnement à la demande

Une des choses que nous avons faites presque immédiatement après avoir adopté Chef et automatisé notre infrastructure de production a été d'améliorer nos environnements de tests et de pré-production en apportant un niveau d'automatisation équivalent. Une plainte récurrente que nous entendions était que nos ingénieurs étaient incapables de faire facilement des démonstrations aux personnes du business avec lesquelles ils travaillaient. En réponse, nous avons construit un portail 100% libre-service permettant à quiconque dans l'entreprise de lancer un serveur préconfiguré exécutant notre pile applicative complète, sur EC2.

Du portail, l'utilisateur peut choisir lesquelles de nos applications il souhaite voir installées sur le serveur, leurs versions, et peut choisir une base de données de tests ou un snapshot propre de la base de production à une date donnée. Un des gros avantages de ce système, c'est que nous réutilisons tout simplement exactement les mêmes recettes Chef que pour le montage de nos serveurs de production. Ceci nous permet d'éliminer beaucoup de problèmes potentiels avant même qu'ils n'apparaissent en production. Nos équipes d'ingénierie et d'assurance qualité peuvent aussi se sentir plus en confiance, étant donné qu'elles testent les nouvelles fonctionnalités sur des serveurs ayant les mêmes configurations et les mêmes versions que nos serveurs de production.

L'environnement de pré-production a rencontré beaucoup de succès dans l'entreprise. De nombreux collaborateurs ont remarqué la différence avec leurs anciennes entreprises, où obtenir des serveurs pour leurs démonstrations prenait plusieurs semaines et demandait énormément de paperasse. Avec notre système, il suffisait d'une quinzaine de petites minutes à n'importe qui pour obtenir un serveur de pré-production. Construire un tel système aurait été impossible sans une solide fondation automatisée en place.

Basculer des datacenters en quelques minutes

Une autre tâche difficile que l'automatisation DevOps nous a aidé à résoudre chez Rafter, ce sont les bascules de datacenters. Il y a à peu près deux ans, nous avions décidé que nous devrions être capables de basculer à tout moment vers un datacenter secondaire afin de réduire l'impact financier des interruptions de service. Etant dans l'industrie de l'éducation, notre activité est saisonnière et une période prolongée d'inactivité peut être coûteuse. Pouvoir basculer bénéficie aussi énormément aux équipes des opérations car cela leur permet d'effectuer des tâches de maintenances risquées sur un datacenter sur lequel il n'y a pas de trafic.

Disposer d'une infrastructure automatisée nous a permis de remplir cet objectif de façon relativement aisée. Au début de cette entreprise, j'aurais été choqué si quelqu'un m'avait dit qu'un jour, les bascules de datacenters entiers seraient l'affaire de quelques minutes. Mais en nous appuyant sur l'automatisation pour faire le gros du travail, nous sommes réellement capables de concevoir une infrastructure répondant à cet objectif.

Partager l'expérience des déploiements

Un autre domaine à noter dans le travail de notre équipe DevOps concerne l'amélioration des processus de déploiement. Dès le début, nous utilisions un très bon outil, appelé Capistrano, pour gérer nos déploiements et nous en étions globalement contents. Une amélioration que nous y avons apportée a été d'apprendre à notre robot Campfire (que nous avons baptisé Reginald) à déployer avec Capistrano. A présent, dès lors que nos ingénieurs produit souhaitent déployer leurs applications, il leur suffit de demander à Reginald de le faire pour eux.

Le plus gros bénéfice ici a été de faire du déploiement une expérience partagée. Toute personne connectée au salon de chat Campfire peut voir qu'un déploiement est en cours et s'il y a un problème, quelqu'un peut réagir immédiatement et aider. Tous les logs d'erreurs et de déploiements sont également stockés dans notre base de données et visualisables depuis une application web que Reginald indique aux développeurs. Il est ainsi beaucoup plus pratique de partager toute question éventuelle. Avant cela, lorsque les développeurs déployaient depuis un serveur, cela tenait plus d'une opération individuelle, alors que lorsque vous devez déployer de façon visible et publique, c'est beaucoup plus facile pour tout le monde de savoir ce qu'il se passe.

Des outils en libre-service

Un principe que nous avons toujours suivi pour la conception des produits que notre équipe DevOps construit et utilise, c'est que, autant que possible, ils soient utilisables en libre-service. Le succès de l'automatisation tient dans le fait de supprimer toutes les interventions manuelles faisant obstacle, y-compris nous-mêmes. Donner aux gens les outils et les plates-formes leur permettant de gérer les parties de l'infrastructure qui les intéressent rend toute l'organisation plus efficace dans son ensemble. En particulier dans les domaines où d'autres peuvent faire le travail à votre place (et probablement mieux), les outils doivent leur donner le pouvoir de le faire. Nous essayons de garder cette philosophie dans les outils et les pratiques que nous adoptons.

La composition de notre équipe

J'ai remarqué qu'on a tendance à retrouver dans l'industrie un large éventail de possibilités quant à la position d'une organisation DevOps, entre les équipes de développements et celles des opérations. Notre équipe DevOps est issue de l'équipe d'ingénierie produit, elle a donc toujours été constituée d'ingénieurs en développement logiciel traditionnels. Tous les membres actuels de notre équipe ont passé du temps sur le développement de fonctionnalités de notre ligne produit principale avant de se ré-aiguiller vers DevOps. Nous avons aussi eu la chance de bénéficier de l'aval d'une équipe de production fantastique, aux petits soins pour notre matériel et nos datacenters, et nous laissant le luxe de nous concentrer uniquement sur la partie logicielle.

Focus sur le développement

J'estime que le fort accent que nous avons porté sur côté "dev" a bien fonctionné pour nous. Puisque nous construisons et supportons des infrastructures applicatives toujours plus complexes, nos besoins en matière de développement traditionnel ne pourront que croitre. Ceci dit, nous nous sommes rendu compte qu'il était difficile d'embaucher, la plupart des ingénieurs en développement ne s'intéressant pas beaucoup à tout ce qui touche au côté "ops", à l'infrastructure, et d'autre part, les ingénieurs des opérations ayant peu d'expérience dans le rôle de développeur traditionnel. Il y a vraiment un besoin de profils bien particuliers pour ce job. Chez Rafter, j'ai remarqué que DevOps a l'air d'attirer ceux qui sont très pointus dans certains domaines, plutôt que les généralistes. Actuellement, notre équipe DevOps est composée de trois ingénieurs et nous sommes constamment à la recherche de talents.

Un aspect qui rend notre équipe DevOps unique en son genre, c'est que nous prenons souvent des tâches que des équipes produit ou des ingénieurs en charge de la fiabilité de la plateforme pourraient réaliser. Par exemple, nous avons conduit des projets comme la mise à niveau de nos applications sur de nouvelles versions majeures de Ruby et Ruby On Rails. Si vous avez déjà été impliqué dans de telles mises à niveau sur de grosses applications, vous savez que c'est loin d'être simple et que cela requiert une réelle expertise, à la fois sur Rails et sur le code avec lequel on travaille. Nous assistons aussi souvent les équipes produit à débuguer et à résoudre des problèmes de performance et de scalabilité sur leurs applications. Les interventions de ce type nous ont permis de nous exposer à toutes les parties de la plateforme que nous avons à supporter.

Au jour le jour

Du support

Une journée typique pour les membres de notre équipe DevOps est une combinaison de résolutions de demandes de support, d'investigations sur des alertes et du travail sur des projets à plus long terme. En moyenne, nous passons à peu près 50% de notre temps sur le support et les alertes, 50% sur les projets, sachant que les demandes et les alertes ont priorité car généralement, c'est le délai de traitement qui prime. Les demandes de support sont de nature variable, mais tournent souvent autour de sujets liés au support applicatif. Par exemple, il peut s'agir d'un ingénieur qui aimerait ajouter une nouvelle application à la plate-forme ou qui souhaiterait effectuer quelques modifications d'infrastructure sur une application existante, avoir plus de serveurs. Parfois, les requêtes peuvent porter sur un large périmètre et nécessiter des changements significatifs et beaucoup de tests, comme par exemple intégrer un nouveau langage de programmation ou une nouvelle base de données.

Le monitoring et les alertes

Un autre ensemble courant de demandes concerne les investigations autours d'alertes (automatisées ou rapportées par les ingénieurs). Souvent, l'équipe DevOps joue le rôle de coordinateur pour le traitement des alertes, fait les premières investigations et désigne l'équipe la plus à même de résoudre le problème. Ce n'est pas tout à fait comme cela, cependant, que nous fonctionnons pour toutes les alertes : nous traitons celles qui affectent l'infrastructure (par exemple, les questions liées à une sollicitation excessive du réseau, des I/O, CPUs ou de la mémoire), ou les sujets sur lesquels il y a une responsabilité et une utilisation partagées par les équipes d'ingénierie, comme les librairies communes, les bases de données, les applications historiques.

Les projets

Souvent, le travail de support que nous effectuons en répondant aux demandes ou en investiguant sur les alertes met en évidence des zones qui nécessitent plus d'investissement. En particulier, ce sont les domaines sur lesquels nous ne mettons pas suffisamment d'outils ou d'informations à la disposition de nos ingénieurs, afin qu'il soient capables de résoudre les problèmes par eux-mêmes. Pour illustrer ce cas avec un exemple actuel, nous n'avons pour le moment rien qui permettrait aux ingénieurs de déployer eux-mêmes leurs modifications de tâches planifiées. Donc, lorsque quelqu'un a besoin de faire ce genre de modification, il doit ouvrir une demande de support. Quand on en reçoit 10 par semaine, ça devient vite apparent qu'il est nécessaire de développer un outil pour rendre les ingénieurs autonomes là-dessus. Ainsi, une partie significative de nos projets est issue de manques que nous découvrons à travers les demandes de support et les alertes.

Nous passons également du temps à mettre à niveau nos systèmes et à effectuer les tests nécessaires pour être confiants sur ces mises à niveau. Je pourrais remplir des pages avec tous les différents types de serveurs, de bases de données, d'applications, de librairies et de systèmes d'opération de notre plateforme. Maintenir tout cela avec les versions les plus récentes et les plus sécurisées représente assez de travail pour occuper plusieurs ingénieurs à temps complet, tout au long de l'année.

Une autre source de travail pour les projets provient directement de demandes externes. Par exemple, le management peut nous demander d'être capable de basculer sur un autre datacenter, un auditeur peut nous demander une fonctionnalité spécifique concernant la sécurité, ou un ingénieur nous demander des changements d'infrastructure impactant un grand nombre d'applications.

DevOps en tant que plate-forme

Avec la croissance de notre entreprise, DevOps a trouvé sa place entre nos équipes d'ingénierie produit et les opérations. Je vois cela comme un gâteau à trois couches. En bas, c'est notre équipe en charge des opérations, responsable d'acquérir le matériel et de l'installer. Au milieu, c'est notre équipe DevOps, responsable de mettre à disposition une plate-forme utilisant les ressources matérielles. Et par-dessus, notre équipe d'ingénierie produit, qui utilise la plate forme DevOps pour déployer, superviser et héberger ses applications.

Je pense que le mot plate-forme correspond à un concept clé quand on parle de DevOps. A l'époque où je débutais avec DevOps, je voyais nos outils comme des éléments séparés et indépendants. Cependant, quand vous commencez à mettre en place tous les morceaux, vous réalisez que chaque composant prend sa place au sein d'une plate-forme plus large et a besoin d'accéder à un ensemble d'informations communes. Chacun de ces outils doit être intégré, autrement, ce sont beaucoup de complexité et de duplication qui vont commencer à apparaitre.

Construire une plate-forme DevOps

Transformer nos outils DevOps en plate-forme de services est un projet constamment en cours pour nous. Cela peut sembler étrange mais, quand on y pense, de nombreux clients différents ont besoin d'information sur notre infrastructure. Par exemple, certaines des applications auxquelles il est fait allusion dans cet article peuvent avoir besoin d'accéder à la plate-forme d'une des façons suivantes :

• Notre portail de gestion des serveurs de pré-production a besoin de connaitre une liste d'applications pouvant être installées sur les serveurs.
• Notre Framework de déploiement a besoin de savoir quelles applications peuvent être déployées et où les déployer.
• Dans le cas d'une bascule de datacenter, nous devons savoir comment remonter les applications dans l'autre datacenter.
• Nos recettes Chef ont besoin de savoir comment configurer les serveurs correctement en fonction des applications qu'on lui demande d'installer.

Ces exemples montrent qu'il y a un ensemble d'informations communes qui peuvent être exposées via des services pour répondre aux questions basiques au sujet de l'infrastructure.

On peut pousser cette idée encore plus loin et développer des services additionnels qui apportent des changements à l'infrastructure. Cela peut être un service pour placer un serveur ou une application en mode maintenance, un service pour ajouter de nouvelles applications à la plate-forme, etc. Certaines organisations DevOps peuvent implémenter ces fonctions sous forme de scripts ad-hoc. L'inconvénient ici, c'est que seul un ingénieur DevOps sera à même d'exécuter ce genre de scripts, la plupart du temps. Un service présente l'avantage de permettre aux différents outils et applications d'interagir avec lui simplement. Il est également possible de s'appuyer sur ces services pour construire des applications, pour encore plus de flexibilité. Ceci va aussi dans le sens de l'idée de mettre un maximum d'outils en libre-service.

Chef en tant que base de données

Nous avons aussi changé notre façon de voir la place qu'occupe Chef dans notre écosystème. Chef est beaucoup plus qu'un simple outil pour automatiser nos serveurs. Nous le voyons comme une couche à part entière de notre plate-forme DevOps. En tirant avantage de la plate-forme offerte par Chef et de ses API, nous pouvons stocker et requêter des informations concernant tous les serveurs et les applications de notre infrastructure. Chef fournissant la couche de stockage des données, nous pouvons construire notre propre ensemble de services pour accéder à la donnée et offrir un moyen flexible d'interagir avec.

Un travail qui ne finit jamais

Tout ceci a été mis en place pour nous assurer que nous pourrons continuer à supporter l'expansion de la plate-forme et faire en sorte que l'infrastructure ne soit jamais un obstacle au lancement un nouveau produit. Par contre, même une fois qu'une bonne part de l'automatisation est en place, il faut continuer à itérer pour construire au-dessus de cette automatisation.

Je peux citer un exemple qui me vient en tête. Notre équipe a fait beaucoup d'efforts pour construire un Framework pour contrôler comment nos applications sont installées sur chaque serveur. Tout ce qu'il faut à présent, c'est seulement un petit fichier JSON avec les informations basiques sur l'application et ses dépendances. Nous nous sommes félicités et nous nous sommes tournés vers le problème suivant. Cependant, nous avons commencé à remarquer que nous ajoutions beaucoup de nouvelles applications et que nous passions un temps conséquent à écrire ces fichiers de configuration, qui impliquaient plusieurs aller-retour inefficaces avec les ingénieurs produit. Il est devenu rapidement évident que nous étions devenus un goulot d'étranglement dans notre propre automatisation. Le travail de l'équipe DevOps n'est jamais fini et ce qui peut paraître suffisant en matière d'automatisation un jour peut toujours vous ralentir le lendemain.

Au sujet de l'auteur

Chris Williams est le cofondateur de BookRenter.com, le premier service de location de manuels scolaires, devenu Rafter Inc. en 2012. Actuellement, il dirige le groupe DevOps chez Rafter et supervise l'automatisation de l'infrastructure, les processus de déploiement et de release et la disponibilité de la plate-forme.