Artyom Galonsky, Bureau de la STO du Bureau: «Je suis contre une chose telle qu'un ingénieur DevOps»

Utilisez-vous l'approche DevOps à la maison? Voici le code mari déployé pour travailler. Une femme de l'infrastructure prépare des œufs au plat, prépare du café et repasse des chemises. Le chat surveillant glisse sous ses pieds dans le temps, nettoie son plateau et indique fort quand la femme s'écarte du protocole établi.

Le premier jour de Slurm DevOps, j'ai rencontré Artyom Galonsky, Bureau STO du Bureau. Il a donné des conférences sur CI / CD et l'introduction à l'automatisation. Il a parlé des lignes de convoyeurs d'assemblage en usine et de leur application en informatique. Et en même temps, il a partagé des exemples pratiques, tels que la construction d'un pipeline «commun».

Après le discours, je l'ai surpris en pause-café et je lui ai demandé de parler de la place du DevOps dans son activité professionnelle, et en même temps quelles exigences il voit pour le poste d'ingénieur DevOps. Artyom m'a choqué, disant que les ingénieurs DevOps existent dans le même univers que les licornes roses. Et pour lui, " il n'y a pas d'ingénieurs DevOps, il y a de bons administrateurs qui comprennent Kubernetes ."

À propos de la carrière

Vous êtes en développement depuis 11 ans. Vous avez commencé chez Bureau Bureau?

Non. Il a commencé en tant que pigiste en 2008, puis a créé plusieurs startups. "Otfermery" était une telle startup. Il a existé pendant 2 ans et a pris forme. En 2011, il a commencé à s'engager dans des systèmes CRM pour une agence d'assurance. Il y avait une petite équipe - 4 personnes. En 11-12, il est devenu chef d'équipe. Il était un développeur de premier plan, chef du département de développement de l'entreprise. En 2017, il est devenu la STO de RedStart à Kaliningrad. Et au début de 2018, j'ai déménagé au Bureau du Bureau.

Qu'est-ce qui vous a attiré?

La prochaine étape. Ils ont offert des conditions intéressantes. L'occasion de rassembler votre équipe. Plus des projets intéressants. J'ai déménagé de Kaliningrad à Moscou. Il a travaillé à Moscou pendant six mois. Ensuite, les directeurs du Bureau of Bureau ont décidé d'ouvrir un back office à Kaliningrad.

Pourquoi?

Premièrement, je suis moi-même de Kaliningrad. Je connais plus de professionnels de qualité et forts à Kaliningrad qu'à Moscou. L'entretien de tous les besoins est moins cher à Kaliningrad. Et la communauté informatique y est forte. Et la zone économique libre progresse lentement.

À Southbridge, nous pensons que le potentiel de la province n’a pas encore été pleinement exploité. Qu'il y a un grand nombre de personnes talentueuses et intelligentes qui, pour un certain nombre de raisons - psychologiques, sociales, financières - ne peuvent pas déménager dans la capitale.

Oui, ce n'est même pas psychologique ou pour quelles raisons ... Les gens ne veulent tout simplement pas bouger.

Oui, j'en parle. Tout le monde ne veut pas bouger.

Et ce n'est pas une sorte de problème - psychologique ou financier. Une personne ne veut tout simplement pas.

Oui Je suis d'accord. «Problème» est un mauvais mot. Plutôt, «installation».

Une personne ne veut tout simplement pas. Il est à l'aise là-bas. J'ai travaillé six mois à Moscou, rassemblant une équipe. Le matin, il m'était difficile de passer 40 minutes en voyage dans le métro. Ou dans les embouteillages sur la voiture encore plus longtemps. Je suis maintenant à Kaliningrad ces quarante minutes à pied à travers des endroits pittoresques, des lacs passés, de belles maisons passées. Et ces quarante minutes j'apprécie la vie. Et respirez un air pur. 20 minutes - et je suis en mer. 40 minutes - et je suis en Europe. De plus, beaucoup de gars qui vivent à Kaliningrad quand ils ont découvert que je revenais, ont dit: " OK, allez, nous serons heureux de retourner dans votre équipe et de continuer à travailler avec vous ." Et depuis un an, notre back-office - développement, tests, analyses, responsables support - est situé à Kaliningrad. Et nous sommes heureux et heureux.

Et à Moscou?

À Moscou, nous avons un front office. Gestion, chefs de projet, directeur directeur, concepteurs d'interface, concepteurs et administrateurs système.

Et comment est l'interaction?

Rien n'interfère. Tout fonctionne presque parfaitement. Tout dépend de la façon dont vous l'avez configuré.

Vous-même, en tant que station-service, qui préférez-vous - les employés à distance ou au bureau?

L'essentiel est d'établir le bon échange de connaissances. J'omets Workflow - car si le workflow n'est pas établi, peu importe la façon dont les connaissances sont échangées. De toute façon, rien ne fonctionnera. Mais l'échange de connaissances pour que les gens partagent leurs pratiques - ce qu'ils ont inventé, compris, fait - c'est mieux en interne lorsqu'ils sont assis dans le même bureau. D'une manière ou d'une autre, ils commenceront à communiquer sur ce sujet. Et lorsque les gens sont à distance, ils peuvent ne pas partager. Il est donc important de créer une base de connaissances. Il est nécessaire de motiver les gens à partager ces informations. Tous les vendredis, la technologisation, c'est-à-dire tous ceux qui n'ont pas de projet «brûlant», s'engagent dans l'auto-éducation dans la deuxième moitié de vendredi. Et puis il partage avec les autres.

À propos du développement

Comment motivez-vous?

Je motive le développement. Franchement, tout change très rapidement dans le "web", et si vous ne vous développez pas, vous resterez à ce niveau pour toujours. Et en termes d'argent, vous ne grandirez pas, et en termes de développement.

Une de mes citations préférées de Lewis Carroll de "Alice au pays des merveilles": "Ici, vous devez courir aussi vite juste pour rester au même endroit, mais pour aller à un autre endroit, vous devez courir deux fois plus vite."

Nous avons presque la même chose. Depuis 11 ans que je suis impliqué dans le Web, la technologie a radicalement changé. Il y a deux ans, relativement parlant, nous ne savions pas ce qu'est Kubernetes et comment le mettre en œuvre. Maintenant, c'est partout. Et dans un an ce sera nécessaire pour tout le monde. Parce que la charge va augmenter. Si vous ne pompez pas les connaissances et ne les utilisez pas dans vos projets, vous serez laissé pour compte. En commençant chaque projet, nous essayons d'introduire quelque chose de nouveau. Travaillant constamment sur un produit, il est assez difficile d'en introduire un nouveau. Et c’est un peu plus facile pour nous - démarrer un nouveau projet, nous introduisons de nouvelles technologies que nous avons étudiées et testées. Et nous évoluons de projet en projet.

Quelles technologies utilisez-vous actuellement, lesquelles jugez-vous pertinentes, nécessaires?

Nous avons ce que nous faisons maintenant, la pile est assez simple - le frontend react.js, pour le backend que nous utilisions partiellement PHP avant et maintenant, maintenant nous essayons de passer à Go. C'est une telle ligne droite, où nous nous déplaçons, pour laisser PHP complètement sur Go et s'y développer. Il s'agit d'une nouvelle technologie, bonne et stable, qui donne une excellente augmentation de la vitesse - à la fois dans le développement et dans la vitesse du produit lui-même. Autrement dit, notre pile est React.js, PHP et Go. C'est pour les langages de programmation. Eh bien, ainsi que les technologies standard de Redis, PostgreSQL, RabbitMQ.

Vous pouvez rappeler des technologies déjà obsolètes. Nous avons récemment discuté avec les gars - ils se sont donc taquinés parce qu'ils étaient autrefois des pros en Perl.

Oui Eh bien, probablement quelqu'un d'autre utilise Perl. Le même JS, qui évolue constamment ... Ce qui était avant ES6 est obsolète, ou le même jpl. Les mêmes js sont arrivés au «nœud» et sont devenus nœud.js. Le même php, eh bien, quelqu'un ne l'aime pas - la version 5 était mauvaise, maintenant 7.2 se développe dans les tendances actuelles. Pour moi, il n'y en a pas un qui soit complètement dépassé. Moralement, peut-être oui. Ou je sort de la technologie. Auparavant, il y a 10 ans, j'utilisais MySQL, maintenant pour les projets que je pose, il est inutile presque partout. Les technologies que je possédais ... Très probablement, je viens de sortir d'eux car ils étaient obsolètes.

Qu'aimez-vous chez Go now?

Rapidité d'exécution, économie. À tout le monde. Ce que je vois, communiquant avec mes architectes, prospects et développeurs, disons simplement que ce que nous avons l'habitude de voir dans le script php, il reste dans Go plus les fonctionnalités des langages compilés sont ajoutées. Goroutines, multicanaux. Ce qui n'était pas en php, et nous l'avons fait via php-fpm, relativement parlant. De plus, un typage de données puissant. Et aussi une compilation rapide du binaire lui-même.

Qu'est-ce qu'un bon développeur pour vous?

Pour moi, un bon développeur est quelqu'un qui peut passer à un nouveau langage de programmation dans environ 2-3 mois pour le comprendre. Naturellement, il ne fera rien pendant 2-3 mois. Il sera au stade de "juin", effectuera des tâches simples. Pompé rapidement - et commence à fermer de bonnes tâches complexes.

À quelle entreprise êtes-vous lié - orange, turquoise?

Nous ne sommes pas turquoise à coup sûr. Plutôt orange. Avec contrôle vertical. Je suis moi-même un peu autoritaire dans la gestion. Nous faisons ceci et cela - et s’ils ne viennent pas me voir et prouvent avec des exemples évidents que c’est mieux d’une autre manière, il sera très difficile de me convaincre. Si cela n'est pas prouvé, cela n'est pas nécessaire. Supposons qu'un employé vienne et dit: «Artyom, nous devons le faire. Pour ceci et pour cette raison. Vous avez suggéré une mauvaise idée. Oui, vous êtes directeur et architecte. Mais vous n’avez pas proposé une très bonne idée. Et nous devons le faire. » Et si je n'ai pas été clairement et à 100% prouvé, je vais pousser ma décision. Donc pas turquoise à coup sûr.

Disons, relativement parlant, qu'une nouvelle technologie est apparue. Et comment un employé peut-il vous prouver qu'il vaut la peine d'être utilisé si peu de gens l'utilisent encore et qu'il n'y a pas d'exemples représentatifs et de cas pratiques? Mais la technologie est censée être prometteuse.

Afficher le projet pour animaux de compagnie. Eh bien, pas seulement: " Regardez, c'est ce que j'ai fait ." Cela doit être déjà mis en place. Pour qu'une personne le fasse consciemment, il a essayé de la mettre en production, de lui donner une charge. Il est venu me voir et m'a dit: « J'ai trouvé une telle fonctionnalité, un tel langage, une telle technologie. J'ai créé un petit produit ou microservice terminé . " Alors j'écoute. Il y a toujours un problème - lorsque l'on travaille avec une entreprise sérieuse, des technologies établies sont nécessaires. Nous pouvons avancer et avancer. Et nos clients - ils sont parfois monstrueux, du fait qu'ils sont très grands, surtout étatiques - ils ne sont prêts qu'à des technologies stables et n'aiment pas les expérimentations. Je me souviens il y a deux ans, j'ai suggéré de réagir.js à quelqu'un - et la réponse nette est « Non. Nous ne travaillerons pas. Pourquoi? Il s'agit d'une sorte de bibliothèque pour l'interface utilisateur. Non. Html, Css, Js - cela nous convient. " Dans les grandes entreprises, les structures étatiques, il s'avère que le développement des nouvelles technologies est un peu en retard. Jusqu'à ce que la technologie se stabilise, jusqu'à ce qu'ils trouvent une personne qui connaît cette technologie et la soutient de l'intérieur, ils ne prendront pas de risques.

À propos des projets

Quand est-il facile pour vous de travailler avec un client?

Je pense qu'il y a un bon architecte côté client. Il devient alors intéressant de travailler. Ensuite, nous obtenons un bon ordre, de bonnes tâches et de bonnes solutions. Et ils comprennent comment cela sera mis en œuvre. Et quand chez le client il n'y a que la direction et un analyste produit qui veulent quelque chose comme ça, alors c'est plus difficile. Les systèmes sont très grands. Et nous livrons un produit qui fera partie du système. Et ils nous disent: « Oh, et connectez ces deux produits ensemble. Pour que l'utilisateur clique sur ce bouton et qu'il ait ceci… »Et il y a beaucoup de choses sous le capot - autorisation, transfert de données. Et vous demandez: «Les gars, d'accord, comment cela devrait-il se produire à l'intérieur? Que veux-tu exactement? "Et ils ont répondu:" Oh, nous ne savons pas. L'essentiel est que tout soit beau. Et ce qui est sous le capot - vous dites à notre sécurité de l'information. Laissez-les vérifier si cela fonctionne bien ou non . »

Vous souvenez-vous d'un exemple où vous avez résolu rapidement et à l'origine un problème?

Nous avons des projets dans lesquels l'autorisation n'est accordée que par l'EIES. Et l'EIES se couche souvent. Lorsqu'une personne se connecte, nous vérifions que c'est bien elle qui s'est connectée. Et il y a un rapprochement des données de l'EIES que son passeport ou d'autres documents n'ont pas été mis à jour. Et puis l'EIES a gâché quelque chose. Et nous avons un groupe de clients qui a essayé de se connecter, a reçu le message « Vos données ont changé. Veuillez confirmer . " L'EIES a commencé à délivrer un nouveau prénom ou un deuxième prénom ou de nouvelles données de passeport. Et nous ne pouvons rien faire, car notre système est tellement configuré que l’ESIE est le centre de vérité pour nous. Et nous avons arrêté l'autorisation pendant un certain temps. L'ESIA a rapidement tout décidé. Nos administrateurs au niveau de l'équilibreur d'utilisateurs ont lancé la page " Désolé, cela ne fonctionne pas temporairement ." Et nous l'avons rapidement terminé afin que seuls les anciens clients puissent se connecter sans mises à jour temporairement. Et les nouveaux utilisateurs n'étaient pas autorisés. Eh bien, ce n'est pas vraiment notre situation, mais nous nous sommes connectés là-bas pour une solution.

Dites-moi, quel a été le projet de défi le plus intéressant pour vous ces derniers temps? De quoi avez-vous eu un plaisir professionnel?

R: J'ai bien aimé ... Nous avons créé un compte personnel pour Siemens Finance. Une filiale de Siemens, qui est engagée dans la location en Russie. Avec eux, nous avons développé un compte personnel. C’est un plaisir ici que Siemens nous ait donné l’occasion de construire une bonne architecture, le client n’est pas intervenu et a diffusé «Les gars, nous vous faisons confiance ». Nous avons fait une bonne interface utilisateur et UX pour eux. Très beau travail avec le client. Et ce n'était ni un défi ni un défi. Ensuite, j'ai vraiment apprécié le travail. Du produit qui est finalement reçu. Et maintenant, le produit fonctionne, vit. Tout le monde l'aime - et je l'aime. Et donc les défis que nous avons sont constamment. Lorsque vous travaillez avec de grandes entreprises sans cela en aucune façon. Chaque entreprise a 12 départements - il y a un département informatique, il y a un département d'infrastructure, un département de logique métier et autre chose. De plus, il y a un tas de fournisseurs, des gens comme vous qui intègrent leur CRM. Et coordonner tout changement avec tous ces services est un défi. Vous proposez votre architecture, communiquez avec l'architecte de l'entreprise principale, interagissez avec les architectes vendeurs ...

Mais l'architecte de l'entreprise cliente ne devrait-il pas s'en occuper?

Pas toujours. Il y a un sujet à la mode: la transformation numérique. Par exemple, l'entreprise a un architecte, et il a été directement impliqué dans l'architecture de sa solution. Par exemple, la facturation ou le secteur bancaire. Mais lui, en tant qu'architecte de l'ensemble du système, n'a pas l'expérience et les compétences nécessaires. Mais un bon spécialiste commence à apprendre. Et qui n'est pas très ou déjà en âge est un peu plus compliqué ici - parce qu'ils guettent mal les nouvelles tendances. Et vous devez communiquer pendant longtemps et expliquer, disent-ils, les gars, essayons cette solution progressive. Et quelque part, il y a de jeunes architectes qui ont grandi sur le "web" moderne. C'est assez simple là-bas - conditionnellement, nous synchronisons comme ça, connectons ces modules comme ça. Et ils dirigent rapidement et avec compétence.

Vous voyez donc déjà deux générations différentes de développeurs?

Sur le Web, oui. Parce que maintenant tout se déplace vers le web. Désormais, même les systèmes internes évoluent progressivement vers des microservices qui communiquent par API. Et l'API est le plus souvent http et https. Les architectes doivent comprendre comment cela fonctionne. Et la manière la plus simple d'écouter ceux qui ont travaillé sur le web. À mon avis. Très souvent, cette situation se produit. Le client veut un nouveau site sympa. Il voit quel site possède un concurrent, comment ce site fonctionne. Et il vient, exige que nous établissions toute l'histoire numérique du site, jusqu'au CRM. Et nous ne traitons qu'avec le site. Nous sommes prêts à intégrer le CRM de quelqu'un. Et il s'avère que nous devenons un moteur de changement pour une entreprise particulière.

À propos de la technologie

Transformation numérique - combien pensez-vous qu'il est nécessaire?

Comme tout thème de battage médiatique, il est à la mode et nécessaire. Nous avons un très grand nombre de commandes pour effectuer un téléchargement Excel. Un nombre incroyable d'entreprises travaillent dans Excel. Et ils doivent faire de cette charge "excel", des pars, se transformer en une base de données et ensuite vous pouvez travailler avec, puis la décharger. La transformation numérique devrait conduire à la transition vers des systèmes de travail normaux - CRM, systèmes de contenu, CMS. Et abandonnez Excel et vivez dans un monde Web normal. Il y a un si bon exemple. Dans l'entreprise précédente, où je travaillais avant Bureau-Bureau, nous avions deux entreprises clientes. Et nous avons pu suivre en détail comment tout se passe. Dans une entreprise, le service client passait par Excel. Il y avait une grande base de données. C'était l'année 2012-2013. Le CRM normal ne convenait pas là-bas - beaucoup de flux de travail et il a fallu beaucoup de temps pour le configurer sur le CRM ordinaire. Et une entreprise est allée travailler chez Excel. Et la seconde a passé six mois - et a écrit son CRM. En conséquence, la première entreprise six mois après avoir atteint le sommet des ventes, et ils ont commencé à travailler avec les clients - ils se sont effondrés. C’est juste que leur service d’appel n’a pas été en mesure de fournir un service efficace et rapide. Et la deuxième entreprise, avec son CRM, au contraire, a rapidement suivi avec un seul bouton, quel type de client, comment il est arrivé à eux, ce que les gestionnaires lui ont répondu. Ils ont survécu à ce pic de croissance - et travaillent toujours. Le flux de travail électronique est également une tendance. Gain de temps. Qui opère plus vite avec l'information, il gagne plus vite. Donc dans tout. S'il n'y a pas de bonne surveillance et pas de bonne journalisation sur le projet, les ingénieurs ne pourront pas comprendre rapidement quel est le problème. Et la survie et le succès de l'entreprise en dépendent vraiment maintenant. Il est donc nécessaire non seulement de baiser un beau site Web, mais de créer le bon site Web et le bon système de journalisation. La transformation numérique est nécessaire. Il est nécessaire de se tenir à jour. S'il existe de telles technologies, nous devons essayer de les introduire.

Quelles technologies voyez-vous maintenant qui seront prometteuses dans un avenir proche? Par exemple, il y a deux ans, Kubernetes était considéré comme prometteur. Maintenant, c'est tout simplement nécessaire.

L'avenir est l'apprentissage automatique et l'IA. Dans cinq ans, cela deviendra pertinent. Il y a un an, il y avait la crypto et l'apprentissage automatique sur le battage médiatique. Maintenant, tout est calme. Mais encore, au cours des cinq prochaines années, l'apprentissage automatique va tourner, comme je pense. Le travail est en cours - l'expérience et les solutions s'accumulent.

On pense qu'avec l'apprentissage automatique et l'intelligence artificielle, de nombreuses professions disparaîtront tout simplement. Cela vaut tant pour les enseignants que pour les économistes. Et les avocats disent que la technologie de la blockchain va déplacer certains domaines de la jurisprudence. Quelles professions dans l'informatique, comme vous le voyez, vont disparaître?

Les couvertures, comme je pense, disparaîtront. Cela me semble au cours des trois prochaines années. Comme le dit le proverbe, souvenez-vous de ce tweet. (rires) Très probablement, l'apprentissage automatique sera bientôt écrit, ce qui sera une bonne mise en page. Ils trouveront quelque chose. Et puis, probablement, les programmeurs de systèmes simples disparaîtront. Mais toujours, il y aura toujours des programmeurs qui concevront et programmeront le noyau de la puce électronique. Il y aura toujours des programmeurs.

O devops

Maintenant sur le marché il y a un certain déficit d'ingénieurs DevOps ...

Écoutez, je suis catégoriquement contre une telle chose comme un ingénieur DevOps.

Pourquoi?

DevOps est une pratique, c'est une philosophie. Ingénieur DevOps - qui est-ce? Est-ce un administrateur pompé ou un "backend" bien pompé qui peut être dans l'administrateur? Pour moi, il n'y a pas d'ingénieurs DevOps, pour moi, il y a de bons administrateurs qui comprennent Kubernetes. Mais Kubernetes n'est pas DevOps. La seule chose que j'accepte pour moi est l'évangéliste DevOps. Qui peut venir dans l'entreprise et dire: «Les gars, nous devons aller dans cette direction. Apprenez à communiquer et à interagir . » Parce que DevOps n'est pas une question de technologie. En général, toute la philosophie de DevOps concerne l'interaction. Pour apprendre à communiquer, au développement et à l'assurance qualité, ainsi qu'à un soutien supplémentaire. Et tous ces ingénieurs DevOps me rappellent le battage médiatique des scrum-masters il y a environ trois ans. Tout le monde avait besoin de maîtres de mêlée, personne ne pouvait travailler sans eux. Il y a cinq ans, tout le monde avait un besoin urgent d'un gestionnaire de configuration Jira. , «», . , DevOps — .

, - ?

, - . . , — , , «», , . , «». , DevOps. , DevOps-. . — . Kubernetes.

, IT-?

. . . . 90- .

, , ?

. . , . - . — , . , . , , , . . . , . , . , , . — .

Post scriptum

. , , , , - — , , . . , , , , , -. , . ? «Time will tell. Sooner or later time will tell».©