La troisième conférence s'est tenue le 7 décembre , organisé par la communauté DevOps de Moscou avec le soutien de Mail.ru Cloud Solutions. En plus des présentations d'éminents praticiens DevOps, les participants ont pu assister à de courts Lightning Talks et à des ateliers motivants et communiquer dans des espaces ouverts.
Nous avons recueilli des informations importantes à partir de six discours et mené des entretiens avec plusieurs intervenants pour découvrir ce qui restait derrière les rapports.
À l'intérieur:
- Baruch Sadogursky, JFrog : « Laissez le logiciel passer du fournisseur à l'utilisateur comme un liquide »
- Pavel Selivanov, Southbridge : « Les développeurs et les opérateurs ont une tâche commune : créer un produit qui fonctionne »
- Vladimir Utratenko, X5 Retail Group : « DevOps in Enterprise, c'est un développement sans douleur ni incendie »
- Sergey Puzyrev, Facebook : « L'ingénieur de production se soucie du service dans son ensemble : pour que les utilisateurs et les développeurs passent un bon moment »
- Mikhail Chinkov, AMBOSS : « Un département ne peut pas suivre la voie DevOps, toute l'entreprise doit la suivre »
- Passionnés de DevOps de Rosbank : « 1000 jours pour mettre en œuvre DevOps dans une entreprise sanglante »
1. Baruch Sadogursky, JFrog : « Laissez le logiciel passer du fournisseur à l'utilisateur comme un liquide »
Les échecs de mise à jour logicielle se produisent toutes les heures et pour tout le monde. Voici juste une histoire d'horreur tirée du discours : Knight Capital a perdu 440 millions de dollars en une 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 votre appareil pour la restaurer si quelque chose se produit. Cela vous protégera si les choses tournent si mal que vous ne pouvez pas envoyer de patch par voie hertzienne.
Mises à jour en direct - mieux continu. Sinon, ce sera comme avec les développeurs Jaguar : en raison d'un bug dans le système de freinage, qui n'a pas pu être mis à jour par voie hertzienne, les voitures ont dû être rappelées de la vente. C'était douloureux et coûteux.
Mises à jour continues — mettre à 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 des mises à jour non critiques. Comme chez Tesla, une mise à jour censée corriger le freinage aléatoire attendait une mise à jour du jeu d'échecs.
Déploiement automatisé - remplacer les gens par des machines, car les gens sont mauvais dans l'exécution des actions de routine.
астые обновления - vous aider à développer une habitude et à vous débarrasser de la peur. Les mises à jour rares se transforment en événements d’urgence.
Connaître l'état de l'appareil - tester 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.
Sorties Canaries — déployer les mises à jour auprès d'un petit nombre d'utilisateurs et observer. Cela réduit les dégâts en cas de problème.
Mises à jour sans indisponibilité - laissez les clients remarquer uniquement les nouvelles fonctionnalités et ne pas rester sans service pendant plusieurs semaines pendant que vous déployez une mise à jour.
Nous avons discuté avec Baruch Sadogursky de la façon dont les points de vue sur le DevOps diffèrent dans l'informatique russe et occidentale, si le Cloud fera bientôt tout pour nous et si tous les services logiciels seront intégrés au système aaS - regardez l'interview :
2. Pavel Selivanov, Southbridge : « Les développeurs et les opérateurs ont une tâche commune : créer un produit qui fonctionne »
La mise en œuvre de Kubernetes n’aidera pas à réaliser le DevOps, et au contraire, cela peut tout casser. Pavel a expliqué pourquoi la technologie (même la plus cool) ne peut 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 l'a déployée, tout fonctionne. Nous sommes passés aux microservices : chaque service est une application simple, communication utilisant des protocoles standards et développement rapide, mais la structure du projet est devenue plus complexe. La complexité d'un projet avec une architecture de microservices n'a pas disparu : elle a dépassé le code. Désormais, l'ingénieur DevOps en est responsable.
Les développeurs ne veulent pas de changements après la mise en œuvre de DevOps. En conséquence, le flux de travail avec Kubernetes continue de ressembler à un transfert de tâches du développement vers l'exploitation par-dessus un mur, mais pas métaphorique - Git devient un tel mur. Le développeur y met le code et fonctionne comme avant, et les administrateurs ont Kubernetes, CI/CD et tout le reste.
Cependant, les développeurs doivent accepter les changements. La situation dans laquelle 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 rien n'a changé pour les développeurs, ils ne se rendent pas compte que le fonctionnement de l'application relève de leur responsabilité - diverses astuces techniques ne fonctionneront pas.
Avec l’avènement de DevOps et Kubernetes, beaucoup de choses vont changer dans le développement. Les développeurs doivent être compétents en Ops et vice versa. Ces spécialistes ont leurs compétences spécifiques, mais ils doivent être conscients du travail de chacun. Les développeurs et les opérateurs doivent être amis avant d'implémenter Kubernetes, sinon vous casserez ce que vous avez.
Pavel Selivanov a parlé de ce qui arrivera à Kubernetes dans 5 ans et sur quoi une startup moderne devrait construire une pile technologique - regardez l'interview :
3. Vladimir Utratenko, X5 Retail Group : « DevOps in Enterprise, c'est un développement sans douleur ni incendie »
Les entreprises se tournent vers la transformation DevOps lorsqu'elles se rendent compte que le développement est trop lent et ne répond pas aux réalités. Elles souhaitent mieux se développer et se déployer plus rapidement.
Vladimir a expliqué comment cela se produit et quel est le problème :
- Premièrement, les entreprises embauchent un ingénieur DevOps. Il s'agit d'un administrateur système senior, il est impliqué dans le déploiement d'une version en production, la standardisation 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.
- Alors un seul ingénieur DevOps ne suffit plus et l’entreprise engage une équipe DevOps. Il s'agit d'un centre de compétences qui organise les efforts d'ingénieurs disparates et leur permet de se concentrer dans une seule direction.
- En fait, les ingénieurs DevOps et les équipes DevOps sont anti-modèles de transformation DevOps. Puisque DevOps est une question de pratiques et de culture, il existe également des implémentations de DevOps dans des entreprises technologiques (SRE, Production Engineering).
Ce qu'il faut faire? Embauchez une équipe DevOps temporaire qui aidera à mettre en œuvre la transformation DevOps, à mettre en œuvre des pratiques, à cultiver une culture de développement et une culture technologique.
Lorsqu’une entreprise entre en jeu et investit dans le DevOps, plusieurs scénarios sont possibles : tout s’écroule au décollage ; restera en tant que SRE/Ingénierie de production ou Opérations embarquées ; passera à BizOps, lorsque les processus seront basés sur des mesures commerciales.
Vladimir Utratenko nous a expliqué à quel point le DevOps est « sanglant » dans une entreprise et comment les pratiques sont mises en œuvre dans la grande distribution - regardez l'interview :
4. Sergey Puzyrev, Facebook : « L'ingénieur de production se soucie du service dans son ensemble : pour que les utilisateurs et les développeurs passent un bon moment »
Facebook est une immense entreprise, avec un grand nombre de composants, de serveurs, de personnes et de 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. De plus, Facebook connaît une croissance rapide, et ce n’est pas seulement le nombre d’utilisateurs et de serveurs qui augmente, le nombre de développeurs augmente également, ce qui rend les processus plus complexes.
Sergey a expliqué ce que fait un ingénieur de production sur Facebook :
- Un ingénieur de production code beaucoup, il doit avoir des connaissances système : systèmes d'exploitation, systèmes de fichiers, bases de données, réseaux, etc. Doit avoir une expérience de travail avec des systèmes distribués et de l'ingénierie de la fiabilité, c'est-à-dire la prise en charge de la fiabilité des produits. Il doit être de garde, c'est-à-dire disponible pour appeler à tout moment.
- L’ingénieur de production diffère de l’ingénieur logiciel par ses compétences avancées en fonctionnement, mais il s’agit en fait d’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 doivent également être de garde, ce qui est pour beaucoup une mauvaise surprise.
- La pyramide des besoins d'un Ingénieur de Production dans une entreprise commence par la surveillance des serveurs et de leur cycle de vie, c'est-à-dire l'obtention du nouveau matériel, sa mise en place, sa mise en service. Le niveau suivant est le même au niveau des services : la surveillance des services et de leur cycle de vie. Vient ensuite une mise à l’échelle transparente et une surveillance avancée. Ils passent à la mise à l'échelle automatique une fois le cycle de vie du service automatisé. Et en fin de compte, il est nécessaire de procéder à des réglages pour que la mise à l'échelle soit efficace et que l'entreprise économise de l'argent et des ressources.
5. Mikhail Chinkov, AMBOSS : « Un département ne peut pas suivre la voie DevOps, toute l'entreprise doit la suivre »
Mikhail estime que DevOps est un développement continu. Vous ne pouvez pas introduire certains 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 du DevOps. Le devops canonique, tel que le voient les évangélistes, repose sur 5 piliers :
- culture - concentration sur les personnes et la collaboration ;
- automatisation - délégation de routine au flux de travail ;
- lean - accent mis sur la fourniture de valeur à l'utilisateur ;
- partage - échange continu de connaissances;
- métriques et recevoir des commentaires en les utilisant.
Les entreprises se concentrent généralement uniquement sur l’automatisation et la création de valeur pour l’utilisateur. Mais la culture, le partage des connaissances et les mesures DevOps permettant de suivre le développement passent au second plan.
Les défis de la normalisation DevOps. Les objectifs des produits sont différents pour toutes les entreprises et ne peuvent pas être standardisés. L'état du DevOps dans une entreprise dépend de l'entreprise elle-même, mais beaucoup ne le comprennent pas et pensent qu'il suffit d'embaucher un ingénieur DevOps.
Pourquoi ne sommes-nous pas encore DevOps ? Il y a deux problèmes clés. Dans Enterprise, il y a un développement lent de l'organisation, des difficultés à changer de vecteur dans l'esprit de milliers d'employés. Dans les startups, il y a un manque de sources de connaissances et un problème d’allocation des ressources pour la transformation.
Les étapes du développement DevOps dans une entreprise:
- le premier est l’infrastructure dans le cloud, mais personne ne sait comment cela fonctionne, à l’exception d’un ou deux administrateurs ;
- deuxièmement, l'infrastructure est transparente et compréhensible pour tous les ingénieurs, mais les processus ne sont pas rationalisés ;
- troisièmement - les ingénieurs lancent et réparent indépendamment les services en direct ;
- quatrièmement - les ingénieurs contribueront éventuellement à l'infrastructure de base, au code transparent dans le cloud, au déploiement par bouton.
Le schéma idéal est que tout le monde ait le même accès à l’infrastructure, que tous les ingénieurs aient accès au produit et comprennent ce qu’ils font.
Après avoir bouclé toutes les gestalts culturelles et techniques, la transformation DevOps de l'entreprise prendra en compte les retours des métriques commerciales et de la plateforme.
6. Passionnés de DevOps de Rosbank : « 1000 jours pour mettre en œuvre DevOps dans une foutue entreprise »
Yuri Bulich, Dina Maltseva et Evgeny Pankov de Rosbank ont raconté comment ils sont arrivés au DevOps en trois ans. L'objectif était double : 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 produit: Assemblage 30 fois plus rapide, installation 6 fois plus rapide, jusqu'à 30% d'économie sur le cycle complet. Nous avons désormais la possibilité d'appuyer sur un bouton pour accéder à la productivité
Résultats pour les commandes de plateforme: Assemblage et installation 10 fois plus rapides, nombre d'installations augmenté de 87%, couverture d'autotest de 46%. L'équipe d'intégration n'est plus un goulot d'étranglement
Alors, comment mettre en œuvre les pratiques DevOps dans une foutue entreprise ?
Mettre en œuvre d’abord un projet pilote: Sélectionnez les équipes, décidez comment mettre en œuvre l'architecture et sélectionnez les outils. Nous avons choisi des outils avec une licence ouverte, avec une installation dans la banque et une expertise dans leur utilisation. Rosbank a déployé simultanément un cloud privé avec la plateforme DevOps, ce qui a aidé au début. Dans le cloud, il était possible d'obtenir les ressources nécessaires en appuyant sur un bouton en 15 minutes ; auparavant, un tel processus pouvait prendre une semaine.
Dans les banques et autres entreprises, il est nécessaire de définir les restrictions à l'avance avec l'équipe de sécurité de l'information et de trouver une solution qui permettra la mise en œuvre des changements.
Après le projet pilote, une solution réussie doit être étendue.
- Il est important de « redresser » le pipeline autant que possible, en éliminant les liens inutiles, en mettant en évidence les fournisseurs de valeur et en supprimant les composants restants. Les intermédiaires sont des anti-modèles. Par exemple, chez Rosbank, un certain nombre d'équipes n'ont pas développé le développement interne, ne laissant que le développement externe. Cela a conduit à l’émergence d’une équipe DevOps dédiée, qui assurait le transfert du code des développeurs externes vers les développeurs internes. Le problème a été résolu en intégrant le développement externe dans CI/CD, afin qu'ils ne se contentent pas de transférer le code d'eux-mêmes à la banque, mais soient également responsables de son succès.
- Le modèle de maturité comprenait des éléments de pratiques DevOps, des outils répertoriés et prenait en compte les caractéristiques du travail avec des fournisseurs externes - à l'avenir, cela a permis de réduire rapidement l'arriéré de tâches lors de leur mise en œuvre dans de nouvelles équipes.
- Nous avons besoin d’une gouvernance sous forme de contrôle souple et de recommandations. Un manuel DevOps qui fonctionne bien est un ensemble de caractéristiques organisationnelles et d'outils qui aident les équipes à utiliser correctement la plateforme.
- Vous devez immédiatement prêter attention à la culture, de nombreux changements se produiront alors plus rapidement et plus facilement. Développez votre communauté interne, organisez des rencontres, des ateliers techniques, des formations et 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 un battage médiatique et une saine concurrence au sein de l'entreprise.
- Cela ne sert à rien de travailler avec ceux qui ne sont pas impliqués dans le processus, avec des équipes qui ne sont pas matures, mieux vaut 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, des pratiques peuvent aussi y être mises en œuvre, l'essentiel est que l'équipe elle-même en ait l'envie.
Un peu plus d'avantage
Liste des livres qui valent la peine d'être lus pour ceux qui travaillent 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 chiffres".
- Maxim Dorofeev « Techniques Jedi ».
- Viktor Frankl "La recherche de sens de l'homme".
Restez à l'écoute
Nous aimons aussi DevOps. Suivez les annonces de la série et @Kubernetes, ainsi que d'autres événements Mail.ru Cloud Solutions, sur notre chaîne Telegram :
Source: habr.com