Il s'agit bien sûr de . Si vous n'entrez pas dans les détails, les 30 septembre et 1er octobre, nous organiserons une conférence sur la combinaison des processus de développement, de test et d'exploitation, et si vous entrez dans les détails, s'il vous plaît, sous cat.
Dans l’approche DevOps, toutes les parties du développement technologique du projet sont étroitement liées, se déroulent en parallèle et s’influencent mutuellement. La création de processus de développement automatisés qui peuvent être modifiés, simulés et testés en temps réel revêt ici une importance particulière. Cela vous aide à réagir instantanément aux changements du marché.
Lors de la conférence, nous souhaitons montrer comment cette approche influence le développement de produits. Comment la fiabilité et l'adaptabilité du système pour le client sont assurées. Comment DevOps change la structure et l'approche d'une entreprise pour organiser son processus de travail.
Dans les coulisses
Il est important pour nous de savoir non seulement ce que font les différentes entreprises dans le cadre de l'approche DevOps, mais aussi de comprendre pourquoi tout cela est fait. Par conséquent, nous avons invité non seulement des experts à rejoindre le comité de programme, mais également des spécialistes qui voient le discours DevOps sous différents angles :
- ingénieurs supérieurs;
- développeurs;
- chefs d'équipe;
- Directeur technique.
D'une part, cela crée des difficultés et des conflits lors de l'examen des demandes de rapports. Si un ingénieur souhaite analyser un accident majeur, il est alors plus important qu'un développeur comprenne comment créer un logiciel qui fonctionne dans les cloud et les infrastructures. Mais en acceptant, nous créons un programme qui sera précieux et intéressant pour tout le monde : des ingénieurs au CTO.
L'objectif de notre conférence n'est pas seulement de sélectionner les rapports les plus médiatisés, mais de présenter une vue d'ensemble : comment l'approche DevOps fonctionne dans la pratique, quel type de râteau vous pouvez rencontrer lorsque vous passez à de nouveaux processus. En parallèle, nous construisons la partie contenu, en descendant de la problématique métier jusqu'aux technologies spécifiques.
Les sections de conférence resteront les mêmes que dans .
- Plateforme d'infrastructures.
- Infrastructure en tant que code.
- Livraison continue.
- Commentaires
- Architecture en DevOps, DevOps pour CTO.
- Pratiques SRE.
- Formation et gestion des connaissances.
- Sécurité, DevSecOps.
- Transformation DevOps.
Appel à communications : quel type de rapports recherchons-nous
Nous avons divisé de manière conditionnelle le public potentiel de la conférence en cinq groupes : ingénieurs, développeurs, spécialistes de la sécurité, chefs d'équipe et CTO. Chaque groupe a sa propre motivation pour venir à la conférence. Et, si vous examinez DevOps à partir de ces positions, vous pouvez comprendre comment concentrer votre sujet et sur quoi mettre l'accent.
Pour les ingénieurs, qui créent une plateforme d'infrastructure, il est important de comprendre les tendances existantes, de comprendre quelles technologies sont désormais les plus avancées. Ils seront intéressés à découvrir des expériences concrètes d’utilisation de ces technologies et à échanger des opinions. Un ingénieur sera heureux d’écouter un rapport analysant un accident grave, et nous, à notre tour, essaierons de sélectionner et de peaufiner ce rapport.
Pour les développeurs il est important de comprendre un concept tel que application cloud native. C'est-à-dire comment développer un logiciel pour qu'il fonctionne dans les cloud et diverses infrastructures. Le développeur doit constamment recevoir des commentaires du logiciel. Ici, nous souhaitons entendre des cas sur la façon dont les entreprises construisent ce processus, comment surveiller les performances des logiciels et comment fonctionne l'ensemble du processus de livraison.
Spécialistes de la cybersécurité Il est important de comprendre comment mettre en place le processus de sécurité afin qu’il ne bloque pas les processus de développement et de changement au sein de l’entreprise. Les sujets sur les exigences que DevOps impose à ces spécialistes seront également intéressants.
Les chefs d'équipe veulent savoir, comment fonctionne le processus de livraison continue dans d'autres entreprises. Quel chemin les entreprises ont-elles emprunté pour y parvenir, comment ont-elles construit des processus de développement et d'assurance qualité au sein de DevOps. Les chefs d’équipe s’intéressent également au Cloud natif. Et aussi des questions sur les interactions au sein de l’équipe et entre les équipes de développement et d’ingénierie.
Pour CTO le plus important est de trouver comment connecter tous ces processus et les ajuster aux besoins de l’entreprise. Il s'assure que l'application est fiable tant pour l'entreprise que pour le client. Et ici, vous devez comprendre quelles technologies fonctionneront pour quelles tâches commerciales, comment construire l'ensemble du processus, etc. Le CTO est également responsable de la budgétisation. Par exemple, il doit comprendre combien d'argent doit être dépensé pour recycler les spécialistes afin qu'ils puissent travailler dans DevOps.
Si vous avez quelque chose à dire sur ces sujets, ne restez pas silencieux, . La date limite pour l'appel à communications est le 20 août. Plus vous vous inscrivez tôt, plus vous aurez de temps pour finaliser votre rapport et préparer votre présentation. Alors, ne tardez pas.
Eh bien, si vous n’avez pas besoin de parler publiquement, et venez les 30 septembre et 1er octobre pour communiquer avec vos collègues. Nous promettons que ce sera intéressant et inspirant.
Comment nous voyons le DevOps
Pour comprendre exactement ce que nous entendons par DevOps, je vous recommande de lire (ou relire) mon rapport »" En parcourant les vagues du marché, j'ai observé comment l'idée du DevOps se transformait dans des entreprises de différentes tailles : d'une petite startup aux entreprises multinationales. Le rapport est construit sur une série de questions, en y répondant vous pouvez comprendre si votre entreprise s'oriente vers DevOps ou s'il y a des problèmes quelque part.
DevOps est un système complexe, il doit inclure :
- Produit numérique.
- Modules métiers qui développent ce produit numérique.
- Équipes produit qui écrivent du code.
- Pratiques de livraison continue.
- Plateformes en tant que service.
- Infrastructure en tant que Service.
- Infrastructure en tant que code.
- Pratiques distinctes pour maintenir la fiabilité, intégrées à DevOps.
- Une pratique de feedback qui décrit tout.
A la fin du rapport se trouve un schéma qui donne une idée du système DevOps dans l'entreprise. Cela vous permettra de voir quels processus dans votre entreprise ont déjà été rationalisés et lesquels doivent encore être construits.
Vous pouvez regarder la vidéo du reportage .
Et maintenant, il y aura un bonus : plusieurs vidéos du RIT++ 2019, qui abordent les problématiques les plus générales de la transformation DevOps.
L'infrastructure de l'entreprise en tant que produit
Artyom Naumenko dirige l'équipe DevOps chez Skyeng et s'occupe du développement de l'infrastructure de son entreprise. Il a expliqué comment l'infrastructure affecte les processus commerciaux chez SkyEng : comment calculer le retour sur investissement, quelles mesures doivent être choisies pour le calcul et comment travailler pour les améliorer.
Sur la route des microservices
La société Nixys fournit un support pour les projets Web chargés et les systèmes distribués. Son directeur technique, Boris Ershov, a expliqué comment traduire des produits logiciels dont le développement a commencé il y a 5 ans (voire plus) sur une plateforme moderne.
En règle générale, de tels projets constituent un monde spécial où se trouvent des coins si sombres et si anciens de l'infrastructure que les ingénieurs actuels ne les connaissent pas. Et les approches d'architecture et de développement qui ont été choisies autrefois sont obsolètes et ne peuvent pas offrir à l'entreprise le même rythme de développement et de publication de nouvelles versions. En conséquence, chaque sortie de produit se transforme en une aventure incroyable, où quelque chose tombe constamment et à l'endroit le plus inattendu.
Les responsables de tels projets sont inévitablement confrontés à la nécessité de transformer tous les processus technologiques. Dans son rapport, Boris a déclaré :
- comment choisir la bonne architecture pour le projet et mettre de l'ordre dans l'infrastructure ;
- quels outils utiliser et quels pièges sont rencontrés sur le chemin de la transformation ;
- que faire ensuite.
Automatisation des versions ou comment livrer rapidement et sans douleur
Alexander Korotkov est l'un des principaux développeurs du système CI/CD au CIAN. Il a parlé des outils d'automatisation qui ont permis d'améliorer la qualité et de réduire de 5 fois le délai de livraison du code en production. Mais de tels résultats ne pouvaient être obtenus avec la seule automatisation, c'est pourquoi Alexander a également prêté attention aux changements dans les processus de développement.
Comment les accidents vous aident-ils à apprendre ?
Alexey Kirpichnikov met en œuvre DevOps et l'infrastructure chez SKB Kontur depuis 5 ans. En trois ans, environ 1000 36 fakaps, plus ou moins épiques, ont eu lieu en sa compagnie. Parmi eux, par exemple, 14 % étaient dus au déploiement d'une version de mauvaise qualité en production, et XNUMX % étaient dus à des travaux de maintenance matérielle dans le centre de données.
Une archive de rapports (post-mortems), que les ingénieurs de l’entreprise conservent depuis plusieurs années consécutives, permet d’obtenir des informations aussi précises sur les accidents. L'autopsie est rédigée par l'ingénieur de service, qui a été le premier à répondre au signal d'urgence et a commencé à tout réparer. Pourquoi tourmenter les ingénieurs qui se battent la nuit avec des facaps en écrivant des rapports ? Ces données vous permettent d’avoir une vue d’ensemble et d’orienter le développement des infrastructures dans la bonne direction.
Dans son discours, Alexey a expliqué comment rédiger un post-mortem vraiment utile et comment mettre en œuvre la pratique de tels rapports dans une grande entreprise. Si vous aimez les histoires sur les erreurs de quelqu'un, regardez la vidéo du spectacle.
Nous comprenons que votre vision du DevOps peut ne pas correspondre à la nôtre. Il sera intéressant de savoir comment vous envisagez la transformation DevOps. Partagez votre expérience et votre vision de ce sujet dans les commentaires.
Quels rapports avons-nous déjà acceptés dans le programme ?
Cette semaine, le Comité du Programme a adopté 4 rapports : sur la sécurité, les infrastructures et les pratiques SRE.
Peut-être le sujet le plus douloureux de la transformation DevOps : comment s'assurer que les gars du service de sécurité de l'information ne détruisent pas les liens déjà établis entre le développement, l'exploitation et l'administration. Certaines entreprises se débrouillent sans service de sécurité de l'information. Comment assurer la sécurité des informations dans ce cas ? À ce sujet Mona Arkhipova de sudo.su. De son rapport, nous apprenons :
- ce qui doit être protégé et de qui ;
- quels sont les processus de sécurité de routine ;
- comment les processus informatiques et de sécurité de l'information se croisent ;
- qu'est-ce que CIS CSC et comment le mettre en œuvre ;
- comment et par quels indicateurs effectuer des contrôles réguliers de sécurité des informations.
Le prochain rapport concerne le développement de l'infrastructure as code. Réduire la quantité de routine manuelle et ne pas transformer l’ensemble du projet en chaos, est-ce possible ? A cette question Maxim Kostrikin d'Ixtens. Son entreprise utilise Terraform pour travailler avec l'infrastructure AWS. L'outil est pratique, mais la question est de savoir comment éviter de créer un énorme bloc de code lors de son utilisation. L’entretien d’un tel héritage deviendra de plus en plus coûteux chaque année.
Maxim montrera comment fonctionnent les modèles de placement de code, visant à simplifier l'automatisation et le développement.
Autre nous entendrons parler des infrastructures de Vladimir Ryabov de Playkey. Ici, nous parlerons de la plateforme d'infrastructure et nous apprendrons :
- comment comprendre si l’espace de stockage est utilisé efficacement ;
- comment plusieurs centaines d’utilisateurs peuvent recevoir 10 To de contenu si seulement 20 To de stockage sont utilisés ;
- comment compresser les données 5 fois et les fournir aux utilisateurs en temps réel ;
- comment synchroniser les données à la volée entre plusieurs centres de données ;
- comment éliminer toute influence des utilisateurs les uns sur les autres lors de l'utilisation séquentielle d'une machine virtuelle.
Le secret de cette magie est la technologie ZFS pour FreeBSD et sa fourchette fraîche ZFS sur Linux. Vladimir partagera des cas de Playkey.
Matvey Kukuy d'Amixr.IO prêt avec des exemples de la vie , quoi SRE et comment cela aide à construire des systèmes fiables. Amixr.IO transmet les incidents clients via son backend ; des dizaines d'équipes de service à travers le monde ont déjà traité 150 XNUMX cas. Lors de la conférence, Matvey partagera les statistiques et les connaissances que son entreprise a accumulées en résolvant les problèmes des clients et en analysant les échecs.
Encore une fois, je vous invite à ne pas être gourmand et à partager votre expérience de samouraï DevOps. Servir pour un rapport, et vous et moi aurons 2,5 mois pour préparer un excellent discours. Si vous voulez être un auditeur, à la newsletter avec les mises à jour du programme et pensez sérieusement à réserver vos billets à l'avance, car ils deviendront plus chers à l'approche des dates de la conférence.
Source: habr.com