Au moins quelques années se sont écoulées depuis que le mot "DevOps" a été entendu par tout le monde. Qui n'a tout simplement pas mis en œuvre et ce qui n'a pas été le cas.

Pendant ce temps, la région est très inexplorée, chargée de nombreuses découvertes. Par exemple, la communauté russophone n'a toujours pas décidé de la terminologie: quelqu'un engage déjà des personnes pour le poste de «devops», et quelqu'un dit toujours que «devops» est une culture et une pratique conçues pour combiner développement, fonctionnement et c'est aussi donc appeler la position si incorrecte.

Beaucoup cherchent une réponse dans les livres, car il y en a eu beaucoup récemment. Par exemple, l'un des plus importants me semble être le Devops Handbook, rédigé par notre conférencier John Willis, et le Google SRE Book, disponible gratuitement sur Internet. Cependant, en lisant ces livres, j'ai trouvé la chose suivante: un texte sec n'est pas très adapté au transfert de connaissances, très basé sur le vrai travail de personnes vivantes. Il s'avère que la connaissance est trop abstraite.

Par exemple, nous prenons le chapitre 14, «Gestion des incidents» . On nous donne deux exemples: dans un premier temps, l'histoire d'un incident, mal traité, est racontée de façon colorée. Ensuite, la même histoire est racontée, mais avec la bonne structure et de bons résultats. Un bon résultat se produit si vous suivez des pratiques importantes:

• Une répartition claire des rôles, avec répartition des responsables:
  
  • tout l'incident («commandant»);
  • partie opérations;
  • la communication
  • planification du travail;
• Mettre en évidence un message d'équipe (à la fois physique et juste chat);
• Un document constamment mis à jour décrivant l'état actuel de l'incident;
• Transfert d'autorité opportun et compréhensible (par exemple, à la fin d'un quart de travail).

En fin de compte, un tas de bons conseils sont donnés sur tout dans le monde. En principe, c'est bien, mais il y a une question: et comment mettre tout cela en pratique? Chaque élément convient à un livre entier, et certains d'entre eux nécessitent des compétences générales qui ne peuvent pas être décrites dans les livres. Imaginez qu'au milieu de l'incident, le CTO vienne à vous et commence à donner des conseils inutiles d'une vie informatique passée: il proposera d'augmenter la taille des pages de mémoire sous Linux, bien que ce soit complètement différent, ou de désactiver les barrières ext4, bien que la mise en cache soit activée. Est-il si facile de lui donner des coups de pied dans le cul depuis notre poste de commandement sous prétexte qu'il n'a aucun rôle dans l'équipe? Comment celui qui a écrit l'article a-t-il fait cela?

Idéalement, je souhaite ce qui suit: premièrement, avoir plus d'un point de vue sur le même problème, dont un issu de l'expérience de différentes équipes. Toutes les entreprises ne sont pas comme Google. Même ainsi: les entreprises de type Google peuvent être comptées sur les doigts. Deuxièmement, je veux rencontrer les auteurs de cette connaissance sacrée en direct, me regarder dans les yeux et poser quelques questions. Par exemple, de nombreux auteurs de documents élogieux sur un merveilleux devoop dans leur organisation sont des mensonges ringards, mais en fait, ils contiennent des scripts bash et des bâtons collés sur du ruban électrique. Il est très utile de regarder dans les yeux. Et je veux vraiment obtenir non seulement quelques conseils généraux, mais poser mes propres questions délicates - et obtenir des réponses.

Les questions de nombreux points de vue et divers problèmes ne sont en aucun cas résolus par de petites mitaps. Avec l'aide de livres, vous ne pouvez pas creuser plus profondément et parler de cœur à cœur. Personne n'a définitivement tranché des questions telles que la terminologie pratique; la composition des postes vacants dépend de la situation. Pour obtenir des connaissances pertinentes et utiles, vous pouvez et devez utiliser toutes les ressources en même temps.

L'année dernière, nous avons réalisé que tout était si déroutant qu'il était temps d'organiser une grande conférence sur DevOps et seulement lui. Il s'appelle DevOops et a lieu à l'automne à Saint-Pétersbourg. La prochaine fois, elle aura lieu le 14 octobre de cette année.

Une grande conférence est exactement ce qui résout la plupart des problèmes énoncés. Par exemple, si vous avez mal compris quelque chose dans le livre de John Willis, vous pouvez non seulement aller à son rapport et comprendre le sujet plus en détail, mais aussi le rencontrer dans la zone de discussion et poser des questions directement.

Uniquement sur DevOps

Premièrement, la caractéristique est que cette conférence ne concerne que DevOps. En principe, dans la plupart des grandes conférences informatiques en Russie, il y a maintenant quelques sujets dévoptiques. Si vous allez immédiatement à un tas de conférences, vous pouvez obtenir une bonne base. Mais ils devront écouter une tonne de tout ce que les programmeurs Java, .NET, JavaScript, etc. sont devenus douloureux, et généralement - en vain. Mais tout cela est incroyablement long et incroyablement cher. La conférence DevOops se concentre uniquement sur DevOps et résout ainsi de nombreux problèmes d'organisation ennuyeux.

Ils parleront des conteneurs et de leur orchestration, de la virtualisation et des clouds, de la surveillance et de l'audit, des CI et des CD, et en général de tout ce qui me vient à l'esprit lorsque le mot "DevOps".

Présentateurs

Mais le plus important, ce sont les haut-parleurs. Déjà, au moment de l'annonce de la conférence, neuf personnes d'entreprises comme Google et Microsoft étaient prêtes à partager leur expérience. Au final, le programme aura environ 17 rapports sur trois pistes. Il y aura peut-être plus de pistes et de rapports. Nous avons soigneusement étudié vos commentaires des précédents DevOops et avons essayé d'inviter ceux que vous vouliez le plus. Voyons qui est déjà avec nous.

John Willis

Il est impossible de dire par des mots combien il est cool qu'il vienne à nous. John est l'un des pères de DevOps, l'auteur de 10 livres publiés au cours des vingt dernières années, dont le célèbre DevOps Handbook et Beyond the Fenix ​​Project , un gourou des Ops depuis 35 ans et juste une légende vivante.

Set Wargo

Seth est un défenseur des développeurs Google, et avant cela, il a travaillé chez HashiCorp, Chef Software et d'autres endroits. Vous avez peut-être lu son livre Learning Chef ou déjà rencontré lors de conférences.

Son rapport s'intitule Modern Security with Microservices and the Cloud . L'importance de la sécurité dans les applications de microservices est difficile à surestimer, ce qui rend le rapport de Seth particulièrement pertinent. Le rapport comprendra une description des principes de base de la sécurité et des meilleures pratiques dans les systèmes modernes basés sur des microservices, et il y aura également une démonstration en direct de Vault comme exemple de leur application.

Riz Liz

Evangéliste technique chez Aqua Security, chef du comité du programme KubeCon, réalisant les meilleurs discours lors de conférences à travers le monde.

Spécialisée au départ dans le développement de logiciels (en particulier, l'implémentation de la pile réseau multiplateforme), Liz connaît bien Kubernetes, Go et Python (le profil sur GitHub montre clairement qu'elle n'est pas de ces évangélistes qui ont oublié comment coder), écrit des articles sur Medium ( parce qu'elle n'a pas d'invitation à Habr! ) et a un tas de compétences spécifiques comme le codage en direct .

Liz va présenter un rapport intitulé «Étapes pratiques pour sécuriser le déploiement de vos conteneurs» , dont l'essence est que lorsque vous passez à la culture DevOps, la sécurité devient en quelque sorte la responsabilité de tous les membres de l'équipe. Des choses concrètes seront démontrées sur la façon dont les principes de sécurité sont fournis à toutes les étapes du pipeline CI / CD et sur ce qui doit être fait à la main.

Jessica Dean

Jessica est une représentante de la communauté des développeurs Microsoft Cloud, spécialisée dans Azure, l'infrastructure et les conteneurs. Et elle en sait beaucoup sur GNU / Linux et Open Source - dites-moi il y a cinq ans que j'écrirais sur une personne de Microsoft, elle rirait.

Avant de rejoindre Microsoft, elle a travaillé avec les utilisateurs finaux de San Francisco en tant que consultante informatique et administrateur système pour les environnements d'entreprise pendant plus de dix ans.

Jessica a occupé pendant 4 ans le rang de Microsoft Most Valuable Professional dans la catégorie "Windows and Devices for IT" (dans le monde Microsoft, c'est une chose assez importante). Bien sûr, elle a une tonne d'autres certifications. En 2013, elle a notamment reçu la certification FEMA du Département américain de la sécurité intérieure (Homeland Security) en tant que leader dans les crises et les situations d'urgence.

Elle fait aussi du crossfit et est très physiquement très pompée. Avec elle, vous pouvez discuter d'un tas de questions à la fête et non sur le sujet des devops. N'oubliez pas que les conférenciers ne sont pas seulement des sources abstraites de connaissances sur un sujet étroit, mais aussi des personnalités très polyvalentes qui ont quelque chose à apprendre dans des domaines très différents.

Paul Stack

Paul est un développeur d'infrastructure qui travaillait chez HashiCorp et était impliqué dans le développement d'outils utilisés par des millions de personnes (comme Terraform). Il s'exprime souvent lors de conférences et transmet des pratiques à l'avant-garde des implémentations CI / CD, les principes de la bonne organisation de la partie opérations, et est capable d'expliquer clairement pourquoi les administrateurs le font.

Paul a déjà pris la parole lors des précédents DevOops, et les participants à la conférence l'ont tellement aimé que nous avons décidé de l'inviter à nouveau!

Le compte rendu du rapport précédent peut être consulté ici:

Cette fois, le rapport sera complètement différent. Son essence est que nous construisons des systèmes fiables à haute tolérance aux pannes - mais comment s'assurer que le système est vraiment fiable? Nous avons le choix: attendre un incident et réparer dans un incendie, ou ajouter nous-mêmes des incidents jusqu'à ce que nous apprenions à survivre. Vous ne pouvez pas battre les incidents? Alors dirigez-les! Paul promet de montrer comment ajouter le Chaos à votre infrastructure et comment y résister.

Alena Prokharchik

Alena est ingénieur logiciel principal chez Rancher Labs (oui, ce sont les mêmes gars qui ont fait Rancher , dont le slogan sonne comme "Kubernetes Everywhere") et le comité de gestion de projet à l'Apache Software Foundation. Auparavant, j'ai travaillé sur la création de services d'infrastructure pour les machines virtuelles dans le projet CloudStack, et maintenant, comme vous pouvez le deviner, pour les conteneurs en mettant l'accent sur Kubernetes. C'est une personne qui sait non seulement tout sur Kubernetes, mais qui peut aussi parler de lui, occupant les premières places lors de conférences.

Son rapport est «Construire une plateforme pour gérer plusieurs clusters Kubernetes: pièges et solutions» . L'essentiel est que s'il était autrefois difficile de travailler avec des k8 dans un cluster, c'est maintenant un problème résolu, et le travail est passé à la gestion de plusieurs clusters. Des problèmes concrets et des solutions seront considérés, soutenus non par un raisonnement abstrait, mais par des exemples de leur solution dans le développement de Rancher. Mais ce n'est pas un rapport sur Rancher en tant que produit, mais sur l'expérience acquise dont les ingénieurs peuvent avoir besoin à la fois en dev et en ops. Si vous ne savez pas pourquoi l'entreprise compte plusieurs clusters Kubernetes, vous devez consulter ce rapport.

Anton Weiss

Anton Weiss est copropriétaire du conseil technologique Otomato Software, propriétaire de plus de 15 ans d'expérience dans le domaine de la haute technologie. Il est expert en enseignement technique, initiateur et co-auteur du premier cours de certification Israel DevOPS. Anton participe à des conférences internationales et est connu comme un conférencier cool.

Cette fois, Anton nous présentera le rapport "DevOps pour les dinosaures: comment changer les processus, les approches et la pensée dans une entreprise traditionnelle . " Au cours des trois dernières années, Otomato a réalisé des projets de transformation DevOps dans plusieurs grandes sociétés internationales. Ils ont aidé à la transition vers les nouvelles technologies, les infrastructures cloud et les processus de livraison continue.
Mais l'essentiel est que nous avons changé les modèles de coopération et de flux d'informations.
Ce n'était pas facile, loin de tout fonctionnait. Beaucoup a pris beaucoup plus de temps et d'efforts que souhaité. Ce rapport est basé sur une expérience réelle. Dans ce document, Anton considérera tout ce qu'ils ont appris et vous dira: ce qui fonctionne, ce qui ne fonctionne pas, ce qui doit être fait en premier, puis quoi, et ce à quoi vous devez faire attention en premier.

Anton Babenko

De nombreuses personnes connaissent et utilisent Terraform dans leur travail quotidien. Mais jusqu'à présent, il n'y a pas de meilleures pratiques pour Terraform. Chaque équipe doit inventer ses propres approches, méthodes.
Anton gère une collection de modules de communauté Terraform pour AWS sur GitHub ( modules terraform-aws , soit dit en passant - plus d'un million de téléchargements!) Et sait tout sur la maintenance à long terme de Terraform en production. Il est prêt à partager sa précieuse expérience avec nous. Comment écrire des modules TF pour ne pas faire de mal.

Alexander Titov

Alexander est l'organisateur de la communauté DevOps Moscou et de la conférence DevOpsDays Moscou.

En tant que directeur associé chez Express 42, il développe désormais des DevOps dans des entreprises technologiques. Avant cela, il était le directeur technique du premier hébergement cloud en Russie - Scalaxy, et avant cela, il a suivi le fascinant chemin de prise de contrôle avec Qik - le chemin de l'exploitation d'une startup à croissance rapide à celui d'une grande entreprise internationale Microsoft.

Kirill Tolkachev ( @tolkv )

C'est l'un des orateurs que le public voulait vraiment. Vous le connaissez peut-être en tant que co-fondateur de Two Devs One Ops, un podcast extrêmement subjectif et cool sur DevOps et la pile moderne. Ou en tant que résident permanent du podcast du débriefing , ou à partir d'histoires et de rapports sur Groovy, Gradle, Spring et la pile technologique Netflix.

Jusqu'à récemment, Cyril était le développeur principal d'Alpha Laboratory et a développé des API bancaires, formant les principes et les boîtes à outils pour travailler avec l'architecture de microservices. Il connaît bien la méthodologie DevOps et possède quatre ans d'expérience dans son application. Maintenant, Cyril est crypté, mais il a probablement quelque chose à partager.

Baruch Sadogursky ( @jbaruch ) et Leonid Igolnik

Ce sera un rapport conjoint de nos grands amis et de certains des meilleurs keyouters lors des conférences du groupe JUG.ru. Les détails sur le rapport sont encore inconnus, il y a donc beaucoup de temps pour profiter de l'intrigue.

Chez DevOops, ils ont fait un magnifique discours de clôture, dont un enregistrement peut être consulté ici:

Pour ceux qui ne le savent pas encore (y en a-t-il?), Baruch est un défenseur des développeurs chez JFrog et fait exactement 3 choses dans la vie: se bloque avec les développeurs, les utilisateurs et les clients, écrit du code pour eux et parle des impressions dans les blogs et lors de conférences - tels que DockerCon, DevOps Days, Container World, JPoint et Joker, et bien d'autres. Et donc pendant plus de dix ans d'affilée, pas une minute ne le regrette.

Leonid est un business angel et une station-service d'une grande entreprise de la Silicon Valley, où il gère le développement d'applications SaaS dans le domaine de la sécurité d'entreprise. Tout au long de sa carrière, il s'est engagé dans des applications en ligne, en commençant par l'un des premiers fournisseurs Internet d'Israël. De toute évidence, Leonid connaît bien le développement, la gestion et l'administration de projets à grande échelle.

Appel à communications

Avez-vous un sujet intéressant pour le rapport? Vous voulez rivaliser avec des bisons tels que Set Wargo et Liz Rice? Il est donc temps de postuler! FP ferme à une vitesse fulgurante, jusqu'au 14 août il y a très peu de temps, et il ne reste que quelques places dans le programme. Postulez maintenant .

Prochaines étapes

DevOops 2018 aura lieu le 14 octobre 2018 à Saint-Pétersbourg.

La connaissance du projet peut être poursuivie sur le site . Faites attention au formulaire d'inscription sur la page principale: il y aura certainement des nouvelles.

Rendez-vous à DevOops 2018! Ce sera génial!