Le 7 décembre, la troisième conférence
DevOpsDays Moscou a été organisée par la communauté DevOps de Moscou avec le soutien de Mail.ru Cloud Solutions. En plus des rapports des principaux praticiens de DevOps, les participants ont pu assister à de courts exposés éclairants et motivants, à des ateliers et à des discussions dans des espaces ouverts.
Nous avons recueilli des informations importantes à partir de six présentations et mené des entretiens avec plusieurs orateurs pour découvrir ce qui a été omis des rapports.
À l'intérieur:
- Baruch Sadogursky, JFrog: «Laissez le logiciel couler du vendeur à l'utilisateur, comme un liquide»
- Pavel Selivanov, Southbridge: «Dev et Ops ont une tâche commune - créer un produit qui fonctionne»
- Vladimir Utratenko, X5 Retail Group: «DevOps in Enterprise est un développement sans douleur et sans incendie»
- Sergey Puzyrev, Facebook: «L'ingénieur de production s'occupe du service dans son ensemble: pour que les utilisateurs et les développeurs se sentent bien»
- Mikhail Chinkov, AMBOSS: «Une unité ne peut pas suivre le chemin DevOps, toute l'entreprise doit le suivre»
- Amateurs de Rosbank DevOps: «1000 jours pour implémenter DevOps dans l'entreprise sanglante»
1. Baruch Sadogursky, JFrog: «Laissez le logiciel couler du vendeur à l'utilisateur, comme un liquide»
Les échecs lors de la mise à jour du logiciel se produisent toutes les heures et pour tout le monde. Voici juste une histoire effrayante du discours: Knight Capital a perdu 440 millions de dollars par heure après une mise à jour infructueuse.
Baruch a parlé des modèles DevOps de mises à jour continues qui aideront à éviter les échecs et la haine des utilisateurs:
Restauration locale - conservez la version précédente du logiciel sur l'appareil pour la restaurer en cas de problème. Cela vous protégera si tout est si mauvais que vous ne pouvez pas envoyer le patch dans les airs.
Les mises à jour de l'air sont mieux continues. Ce sera différent, comme avec les développeurs Jaguar: à cause d'un bug dans le système de freinage qui ne pouvait pas être mis à jour par voie aérienne, il fallait rappeler des voitures de vente. C'était douloureux et cher.
Mises à jour continues - mettez à jour le logiciel en continu dès qu'une nouvelle fonctionnalité est prête. Avec les mises à jour rares, les fonctionnalités sont regroupées, une mise à jour critique peut attendre les mises à jour non critiques. Comme dans Tesla, une mise à jour censée corriger le freinage aléatoire attendait la mise à jour du jeu d'échecs.
Déploiement automatisé - remplacez les personnes par des machines, car les personnes ne savent pas comment effectuer des actions de routine.
Mises à jour fréquentes - aidez à développer une habitude et à vous débarrasser de la peur. Les mises à jour rares se transforment en événement d'urgence.
Connaissance de l'état de l'appareil - testez les mises à jour, pas l'installation à partir de zéro. Ceci est important, car les mises à jour peuvent se comporter différemment selon l'état de l'appareil.
Canary releases - déployez des mises à jour pour un petit nombre d'utilisateurs et regardez. Cela réduit les dommages en cas de problème.
Mises à jour sans inaccessibilité - laissez les clients remarquer uniquement les nouvelles fonctionnalités et ne restez pas sans service pendant plusieurs semaines jusqu'à ce que vous déployiez la mise à jour.
Nous avons discuté avec Baruch Sadogursky de la façon dont les perspectives sur DevOps diffèrent dans l'informatique russe et occidentale, si le cloud fera tout pour nous bientôt et si tous les services logiciels glisseront dans le schéma aaS - voir l'interview:
2. Pavel Selivanov, Southbridge: «Dev et Ops ont une tâche commune - créer un produit qui fonctionne»
La mise en œuvre de Kubernetes n'aidera pas à réaliser DevOps, et même vice versa - elle peut tout casser. Pavel a expliqué pourquoi les technologies (même les plus cool) ne peuvent pas résoudre tous vos problèmes:
La complexité du projet a dépassé le code . Auparavant, il y avait une application complexe: interaction au sein du projet et développement complexe, mais une structure simple - l'administrateur déployé, tout fonctionne. Nous sommes passés aux microservices: chaque service est une application simple, une communication utilisant des protocoles standards et un développement rapide, mais la structure du projet est devenue plus compliquée. La complexité du projet avec une architecture de microservices n'a pas disparu - il est allé au-delà du code. Maintenant, l'ingénieur DevOps en est responsable.
Les développeurs ne veulent pas de changements après l'implémentation de DevOps . En conséquence, le flux de travail avec Kubernetes continue de ressembler à des tâches de développement à des opérations à travers un mur, mais plus métaphoriques - Git devient un tel mur. Le développeur y met le code et fonctionne comme auparavant, et les administrateurs ont Kubernetes, CI / CD et tout le reste.
Cependant, les développeurs doivent accepter les modifications . La situation où les développeurs ne savent pas ce que font les administrateurs et les administrateurs ne savent pas ce qui se passe avec les développeurs crée des problèmes.
Si les développeurs n'ont rien changé, ils ne se rendent pas compte que le travail de l'application est de leur responsabilité - différentes astuces techniques ne fonctionneront pas.
Avec l'avènement de DevOps et Kubernetes, beaucoup de choses vont changer dans le développement. Le développeur doit être compétent en Ops, et vice versa. Ces spécialistes ont leurs propres compétences spécifiques, mais ils doivent être conscients du travail de chacun. Dev et Ops doivent être amis avant d'implémenter Kubernetes, sinon vous casserez ce qui est.
Pavel Selivanov a parlé de ce qui arrivera à Kubernetes dans 5 ans et de quoi construire une pile technologique pour une startup moderne - voir l'interview:
3. Vladimir Utratenko, Groupe de vente au détail X5: «DevOps in Enterprise est un développement sans douleur ni incendies»
Les entreprises entrent dans la transformation DevOps lorsqu'elles réalisent que le développement est trop lent et ne correspond pas à la réalité, elles ont le désir de mieux se développer et de se déployer plus rapidement.
Vladimir a expliqué comment cela se produit et quel est le problème:
- Tout d'abord, les entreprises embauchent un ingénieur DevOps. Il s'agit d'un administrateur système principal, il est engagé dans le déploiement de la version en production, la normalisation de l'environnement de développement, la mise en place de l'infrastructure, la détection et la résolution de divers problèmes, l'automatisation des processus et d'autres tâches techniques.
- Ensuite, un ingénieur DevOps ne suffit plus et l'entreprise embauche une équipe DevOps. Il s'agit d'un centre de compétence, qui organise les efforts d'ingénieurs disparates, vous permet de les focaliser dans une direction.
- En fait, l'ingénieur DevOps et les équipes DevOps sont les antipatterns des transformations DevOps. Étant donné que DevOps concerne les pratiques et la culture, il existe en outre des implémentations de DevOps dans les entreprises technologiques (SRE, Production Engineering).
Que faire? L'embauche d'une équipe DevOps temporaire pour aider à mettre en œuvre la transformation DevOps poursuivra les pratiques, cultivera une culture de développement et une culture technologique.
Lorsqu'une entreprise entre dans le jeu et investit dans DevOps, plusieurs scénarios sont possibles: tout s'effondrera au décollage; restera SRE / Ingénierie de production ou Opérations intégrées; passera à BizOps lorsque les processus s'appuieront sur des métriques métier.
Vladimir Utratenko nous a expliqué à quel point les DevOps sont «sanglants» dans l'entreprise et comment les pratiques sont mises en œuvre dans les grands magasins de détail - voir l'interview:
4. Sergey Puzyrev, Facebook: «L'ingénieur de production s'occupe du service dans son ensemble: pour que les utilisateurs et les développeurs se sentent bien»
Facebook est une énorme entreprise avec de nombreux composants, serveurs, personnes, centres de données. Malgré sa taille énorme, il est très rapide - les développeurs peuvent déployer des services plusieurs fois par jour. Facebook se développe également rapidement, et il ne s'agit pas seulement de l'augmentation du nombre d'utilisateurs et de serveurs, le nombre de développeurs augmente également, ce qui complique les processus.
Sergey a raconté ce que fait l'ingénieur de production sur Facebook:
- L'ingénieur de production codifie beaucoup, il doit avoir des connaissances système: systèmes d'exploitation, systèmes de fichiers, bases de données, réseaux et autres. Doit avoir de l'expérience avec les systèmes distribués et l'ingénierie de la fiabilité, c'est-à-dire dans le soutien de la fiabilité du produit. Il doit être disponible sur appel, c'est-à-dire disponible à tout moment.
- L'ingénieur de production se distingue de l'ingénieur logiciel par ses compétences avancées en exploitation, mais, en fait, est une sous-espèce d'ingénieur logiciel. Les ingénieurs logiciels codent davantage, ils peuvent avoir des compétences supplémentaires liées, par exemple, au traitement des données. Sur Facebook, ces spécialistes devraient également être sur appel, ce qui est pour beaucoup une surprise désagréable.
- La pyramide des besoins de l'ingénieur de production dans l'entreprise commence par la surveillance des serveurs et de leur cycle de vie, c'est-à-dire la réception du nouveau matériel, sa configuration, sa mise en service. Le niveau suivant est le même au niveau du service: le suivi des services et leur cycle de vie. Viennent ensuite une mise à l'échelle transparente et une surveillance avancée. Ils passent à l'autoscaling après l'automatisation du cycle de vie. Et en fin de compte, vous devez effectuer un réglage pour que la mise à l'échelle soit efficace, l'entreprise économise de l'argent et des ressources.
5. Mikhail Chinkov, AMBOSS: «Une unité ne peut pas suivre le chemin DevOps, toute l'entreprise doit le suivre»
Michael pense que DevOps est un développement continu. Vous ne pouvez pas introduire d'outils et vous arrêter là. Quels problèmes empêchent les entreprises de devenir DevOps et comment mettre en œuvre des pratiques?
Différence dans la compréhension de DevOps . Les évêques canoniques, selon les évangélistes, reposent sur 5 piliers:
- culture - se concentrer sur les gens et la collaboration;
- automatisation - délégation de la routine au flux de travail;
- lean - accent mis sur l'apport de valeur à l'utilisateur;
- partage - partage continu des connaissances;
- métriques et obtenir des commentaires avec leur aide.
Les entreprises se concentrent généralement uniquement sur l'automatisation et la fourniture de valeur à l'utilisateur. Mais la culture, le partage des connaissances et les métriques DevOps, par lesquels vous pouvez suivre le développement, passent par le chemin.
Problèmes de standardisation DevOps . Les objectifs des produits sont différents pour toutes les entreprises, ils ne peuvent pas être standardisés. L'état de DevOps dans l'entreprise dépend de l'entreprise elle-même, mais beaucoup ne le comprennent pas et pensent qu'il suffit d'engager un ingénieur DevOps.
Pourquoi ne sommes-nous pas encore DevOps? Il y a deux problèmes clés. Dans l'entreprise - le lent développement de l'organisation, la difficulté de changer le vecteur dans la tête de milliers d'employés. Dans les startups, il y a un manque de sources de connaissances, un problème d'allocation des ressources pour la transformation.
Étapes de développement de DevOps dans l'entreprise :
- le premier est l'infrastructure dans le cloud, mais personne ne sait comment cela fonctionne, à l'exception d'un ou deux administrateurs;
- le second - l'infrastructure est transparente et compréhensible pour tous les ingénieurs, mais les processus ne sont pas mis en service;
- le troisième - les ingénieurs lancent et réparent indépendamment des services en direct;
- le quatrième - les ingénieurs, s'ils le souhaitent, contribueront à l'infrastructure de base, au code transparent dans le cloud, au déploiement des boutons.
Le schéma idéal - tout le monde a le même accès à l'infrastructure, tous les ingénieurs ont accès au produit et comprennent ce qu'ils font.
Clôturant toute gestuelle culturelle et technique, la transformation DevOps de l'entreprise prendra en compte les retours des métriques métiers et métriques des plateformes.
6. Les passionnés DevOps de Rosbank: "1000 jours pour implémenter DevOps dans l'entreprise sanglante"
Yuri Bulich, Dina Maltseva, Eugene Pankov de Rosbank ont raconté comment ils sont arrivés à DevOps en trois ans. Il y avait deux objectifs: résoudre des problèmes spécifiques dans des équipes spécifiques et mettre en œuvre des outils centralisés.
Voici les résultats obtenus:
Résultats pour les équipes produits : assemblage 30 fois plus rapide, installation 6 fois plus rapide, jusqu'à 30% d'économies sur un cycle complet. Nous avons eu l'opportunité de faire rouler le bouton dans le
Résultats pour les équipes de plateforme : le montage et l'installation sont 10 fois plus rapides, le nombre d'installations a augmenté de 87%, la couverture des autotests est de 46%. L'équipe d'intégration a cessé d'être un goulot d'étranglement
Alors, comment mettre en œuvre les pratiques DevOps dans l'entreprise sanglante?
Tout d'abord, introduisez un projet pilote : choisissez des équipes, décidez comment mettre en œuvre l'architecture et choisissez les outils. Nous avons choisi des outils avec une licence ouverte, avec l'installation en banque et l'expertise pour travailler avec eux. À Rosbank, avec la plate-forme DevOps, un cloud privé a été déployé, ce qui a aidé au début. Dans le cloud, il était possible d'obtenir les ressources nécessaires par un bouton en 15 minutes, auparavant un tel processus pouvait prendre une semaine.
Dans les banques et autres entreprises, vous devez déterminer à l'avance les restrictions avec l'équipe de sécurité de l'information et trouver une solution qui vous permettra de mettre en œuvre les changements.
Après le pilote, une solution réussie doit être mise à l'échelle .
- Il est important de «redresser» le convoyeur autant que possible, en éliminant les liens inutiles, de mettre en évidence les fournisseurs de valeur et de supprimer les composants restants. Les intermédiaires sont des antipatterns. Par exemple, à Rosbank, un certain nombre d'équipes n'ont pas eu de développement interne, seules les externes sont restées. Cela a conduit à l'émergence d'une équipe DevOps dédiée, qui a fourni le transfert de code des développeurs externes aux développeurs internes. Le problème a été résolu en intégrant le développement externe dans CI / CD afin qu'ils puissent non seulement transférer le code d'eux-mêmes à la banque, mais également être responsable de son succès.
- Des éléments de la pratique DevOps ont été inclus dans le modèle de maturité, les outils ont été répertoriés et les fonctionnalités de travail avec des fournisseurs externes ont été prises en compte - à l'avenir, cela a permis de réduire rapidement l'arriéré de tâches lors de la mise en œuvre dans de nouvelles équipes.
- La gouvernance est nécessaire sous la forme d'un contrôle souple et de recommandations. Le manuel DevOps fonctionne bien - c'est un ensemble de caractéristiques organisationnelles et instrumentales qui aident les équipes à utiliser correctement la plateforme.
- Il convient de prêter immédiatement attention à la culture, alors de nombreux changements seront plus rapides et plus faciles. Développez la communauté interne, organisez des réunions, des ateliers techniques, des formations, des activités amusantes. Cela porte ses fruits: les gens partagent leurs pratiques, voient qui a fait quoi, savent vers qui se tourner, il y a du battage médiatique et une saine concurrence au sein de l'entreprise.
- Cela n'a aucun sens de travailler avec ceux qui ne sont pas impliqués dans le processus, avec des équipes qui ne sont pas mûres, il vaut mieux investir dans des équipes intéressées et des personnes fidèles.
- La solution choisie doit convenir aux ingénieurs qui l'utilisent.
- Le développement externe n'est pas un bloqueur, vous pouvez également y mettre en place des pratiques, l'essentiel est que l'équipe elle-même ait une envie.
Un peu plus bien
La liste des livres qui devraient être lus à ceux qui sont dans DevOps, d'Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko «Volonté et maîtrise de soi».
- Daniel Kahneman "Penser, vite et lentement."
- Barbara Oakley "Un esprit pour les nombres".
- Maxim Dorofeev "Techniques Jedi".
- Viktor Frankl "La recherche de sens par l'homme".
Restez à l'écoute
Nous aimons aussi DevOps. Suivez les annonces des
séries @DevOps et @Kubernetes, ainsi que d'autres événements Mail.ru Cloud Solutions, sur notre canal Telegram:
t.me/k8s_mail