À la veille de DevOps Conf Russia 2018, nous avons discuté avec le directeur technique d'Uchi.ru Alexei Vakhov des étapes de développement de la plateforme, des outils qu'ils utilisent et de la quantité d'Ovo DevOps.
Alexey Vakhov - Directeur technique d'Uchi.ru. Il a travaillé en tant que développeur C ++ sur des systèmes énormes (des dizaines de millions de lignes de code). La technologie de serveur préférée - Ruby on Rails, fait partie des 100 meilleurs contributeurs. Il aime l'organisation de la production informatique, l'exploitation, l'architecture des applications web.
Uchi.ru est une plateforme éducative russe où les élèves de la 1re à la 11e année étudient les matières scolaires de manière amusante et divertissante. La plateforme est utilisée par plus de 2,5 millions d'élèves et 220 000 enseignants en Russie, aux États-Unis, au Brésil, en Inde, en Afrique du Sud et en Chine. Il occupe la 36e place du classement mondial des plateformes de e-learning. L'entreprise compte plus de 400 employés.- Comment tout a commencé? Combien de personnes étaient dans l'entreprise à votre arrivée?- J'ai été invité dans l'entreprise en 2012, c'est-à-dire il y a six ans. À cette époque, j'étais le cinquième ou le sixième employé et le seul développeur. J'ai composé et fait le développement du serveur. Nous avons créé la première application Web et l'avons publiée sur Heroku.
"Comment ça va maintenant?" Combien d'équipes et quelles tailles? Comment indépendant? Comment interagissent-ils entre eux?- Nous comptons aujourd'hui plus de 400 personnes, dont une centaine d'ingénieurs réunis en une vingtaine d'équipes distinctes. Nous avons deux grandes directions: le développement de la production et le développement de tâches interactives.
Les équipes distinctes ont leur propre environnement isolé, des systèmes de construction spéciaux, affinés pour les tâches que l'équipe effectue, leurs propres serveurs, les codes source. Ils communiquent entre eux uniquement lorsque cela est nécessaire.
- Avec ce taux de croissance de l'entreprise, parvenez-vous à créer votre propre wiki? Comment la soutenez-vous?- Nous avons plusieurs bases de connaissances. Il y a un wiki sous forme de confluence, où il y a des sections générales et thématiques, et chaque équipe a sa propre section. Dans chaque référentiel, nous prenons en charge le fichier Lisez-moi et les livres blancs supplémentaires. En tout cas, chaque équipe se voit allouer son propre espace, sa propre pièce en jira, en confluence, tout cela est aménagé selon les souhaits de l'équipe. Nous n'avons pas de diktat et de standardisation sur la conception.
- Une forte augmentation s'accompagne d'une perte de contrôle. Comment gérez-vous cela? Comment coordonnez-vous le travail de tant d'équipes?- La coordination générale est obtenue en construisant une hiérarchie de gestion. Nous avons des coordonnateurs de référence et chaque équipe a son propre chef. Ici, tout est simple.
Si vous répondez à cette question du point de vue de la technologie, les équipes respectent les règles générales, par exemple, les tests sont connectés à chaque référentiel, l'ensemble du développement va à de nouvelles branches, qui sont vérifiées, déployées dans l'environnement de test, puis en production.
- Quelles sont les étapes de la formation de l'entreprise que vous vous démarquez?- J'aime l'approche que j'ai lue dans un livre intéressant, selon laquelle la crise survient lorsque le système de valeurs habituel s'effondre. Dans notre cas, en raison d'une croissance rapide des crises, il y a eu de nombreuses crises et chacune d'elles détermine le mouvement ultérieur.
La première crise est survenue lorsque nous sommes devenus à l'étroit dans une pièce et avons dû nous étendre à deux. À ce stade, des informations sont apparues qui ont cessé d'être connues de tous. La deuxième crise et les suivantes sont survenues lorsque les développeurs ont dû se diviser en équipes de produits. Encore une fois, notre grande équipe amicale a été forcée de se séparer et de se séparer sous différents angles.
Tout changement intervenu avec nous était nécessairement soutenu par des innovations technologiques opportunes et pertinentes. Il en va de même pour la méthodologie DevOps. Nous pouvons dire que j'ai moi-même récemment commencé à comprendre quelles sont les valeurs culturelles et pourquoi elles sont importantes dans les grandes équipes. Par exemple, il fut un temps où personne ne se demandait qui était responsable de la stabilité du site. Tout le monde a compris que celui qui a déployé le service était responsable de lui. Nous avons embauché une personne qui était censée être uniquement responsable du serveur - et la confrontation «développeurs vs administrateurs» a commencé le même jour. C'était incroyable, comme un livre.
- Parlez-moi de chacune des étapes. Quels outils avez-vous pris pour vous, lesquels avez-vous dû abandonner? Si je comprends bien l' annonce de vos performances à DevOpsConf 2018, toute votre infrastructure est déployée dans les nuages dans des conteneurs de docker. Pourquoi avez-vous pris une telle décision? Depuis quand ne pouvez-vous pas vivre sans conteneurs?- Au début, il n'y avait rien, pas même un tracker. Seul déploiement sur Heroku: git push, et tout le monde est content. Mais Heroku a rapidement cessé de nous satisfaire, car il y avait beaucoup de ping avant, et ils ne toléraient pas la charge. Nous avons déménagé sur des serveurs de fer réguliers et embauché des consultants. Au fil du temps, le serveur est très jonché. A cette époque, nous avons considérablement augmenté le trafic, le nombre de production, les services internes et externes. Nous avons configuré les serveurs via Chef. Un beau jour, nous sommes tombés sous la charge et le soir, nous sommes passés au cloud en utilisant Ansible. Le sentiment de passer à Ansible était juste cosmique. Cela s'est avéré simple et compréhensible, en particulier dans le cas de telles petites infrastructures.
Commençant par environ 60 applications, notre infrastructure est devenue des «sites» distincts, comme nous les appelons. Ce sont des nuages isolés avec leurs propres sous-réseaux, avec leurs propres configurations terraform et ansible.
Avec le nombre croissant d'applications et de serveurs, notre configuration a commencé à flotter, car il y a beaucoup de choses à considérer avant de démarrer une application simple sur RoR. De plus, une partie de la configuration de déploiement était dans le référentiel avec l'application, une partie des recettes d'ensemble, les développeurs ont commencé à utiliser la magie secrète, à créer des liens vers des dossiers, une sorte de synchronisation. En conséquence, il est devenu complètement impossible à entretenir.
Lorsque nous avons eu une centaine d'applications dans différents nuages, nous avons commencé à regarder de plus près Docker. C'était l'été dernier. En environ 10 mois, nous avons transféré toutes nos applications, et à ce moment-là, il y en avait environ 150, sur des dockers-clusters. C'est devenu pour nous un véritable salut. Nous avons été épargnés par la surveillance des versions et des bribes d'environnements sur les serveurs. Tout est devenu beaucoup plus pratique et plus simple: l'application pourrait facilement être placée dans un cluster de dockers, facilement supprimée de là, elle avait ses propres méta-informations, à partir desquelles il était clair quels services constituaient l'application, quelles couronnes, tâches d'arrière-plan, etc. étaient lancées.
- Quelle est votre position sur l'approche DevOps originale? Est-ce que tout vous convient ou avez-vous changé quelque chose par vous-même? A-t-il été difficile de reconstruire l'équipe?- Je n'ai pas moi-même de réponse exacte à la question de ce qu'est DevOps. Au travail, je procède toujours du simple bon sens. Et les gens disent qu'il se trouve qu'ici, DevOps a grandi. En fait, je n'ai presque pas besoin de la partie théorique de DevOps, car l'entreprise me demande des résultats. En d'autres termes, si je leur dis bien et que je ne fais rien, ce sera très mauvais, et si je le fais, mais ne parle pas de beauté, ce sera quand même bien.
Ma compréhension de DevOps est la suivante. Par exemple, il y a une grande entreprise qui veut fabriquer ou qui fabrique déjà des produits numériques. Les produits numériques sont toujours des retours rapides du marché. La livraison continue se produit automatiquement, les frontières entre le développement et le support sont floues, la culture DevOps est resserrée, ce qui interprète les règles de bonne forme entre les personnes responsables du déploiement, des tests et du support. En conséquence, de telles relations leur permettent de s'entendre entre elles afin d'atteindre un objectif commun, ainsi que de détourner l'attention de leurs responsabilités personnelles vers un résultat commun. Dans une grande entreprise bien établie, des changements de processus se produisent, leur rupture.
Comme nous n'avions pas d'entreprise bien établie, nous avons donc développé très rapidement des principes de travail. De plus, l'entreprise nous a constamment lancé de nouvelles tâches, nous avons donc construit notre infrastructure principalement sur la base du bon sens et des exigences internes.
Le mot DevOps ne signifiait pas grand chose pour moi. Mais maintenant, quand nous avons traversé tout cela, quand j'ai vu l'émergence de points de conflit, le flou des responsabilités, j'ai réalisé que DevOps est comme un aspect culturel de l'interaction entre les personnes dans un but commun. Et les objectifs communs des produits numériques sont de créer de nouvelles fonctionnalités et de les déployer le plus rapidement possible.
- Il serait intéressant de savoir à quel point il est difficile pour les débutants de rejoindre votre travail avec autant d'outils modernes. Comment votre travail avec les gens est-il organisé?- Nous avons des programmes d'adaptation. Nous expliquons au nouvel employé comment nous avons évolué et comment tout est organisé maintenant, nous lui attachons un mentor. Le premier jour, nous l'aidons à mettre en place l'environnement et à lancer un combat, mais pas une tâche très difficile. Le mentor l'accompagne pendant plusieurs mois, aide à l'adaptation.
- Parlez-nous des plans de l'entreprise. Où prévoyez-vous de grandir et quels domaines développer? La pile technologique actuelle fournit-elle les bases d'une croissance future, ou devrez-vous la changer à nouveau?- Les plans d'affaires sont ambitieux. Aujourd'hui, plus de deux millions d'écoliers fréquentent régulièrement Uchi.ru, ce qui représente environ 30% de tous les élèves des écoles primaires du pays. Nous continuerons d'attirer de nouveaux utilisateurs sur la plateforme en Russie et de nous engager dans le développement international.
Techniquement, nous avons 15 clusters de dockers isolés et nous passons beaucoup de temps à passer de l'un à l'autre, il est devenu difficile à maintenir et à mettre à niveau. Les exigences de vitesse de changement et de fiabilité ne font que croître. Par conséquent, il y a une réserve, mais nous mettrons également à jour.
Amis, si vous êtes intéressé par l'expérience d'Alexey, nous nous empressons d'inviter à notre
DevOps Conf Russia 2018 , qui se tiendra les 1er et 2 octobre. Dans son rapport, il parlera de l'expérience d'utilisation des nuages, de l'application de la méthodologie DevOps, des valeurs et principes de son équipe.
Abonnez-vous à la newsletter thématique Ontiko DevOps pour recevoir les mises à jour du programme dès qu'elles seront disponibles. Nous essayons de rendre les lettres utiles et non intrusives, nous envoyons des nouvelles de la conférence, des transcriptions de rapports et de nouvelles vidéos.
Soit dit en passant, la vidéo peut être contrôlée séparément sur la chaîne YouTube - il y a toutes les vidéos collectées ces dernières années et la liste est constamment mise à jour.