¿Utiliza el enfoque DevOps en casa? Aquí está el código de marido implementado para trabajar. La esposa de la infraestructura prepara huevos fritos, prepara café, plancha camisas. El gato de monitoreo se desliza debajo de sus pies a tiempo, limpia su bandeja e indica en voz alta cuándo la esposa se desvía del protocolo establecido.
El primer día de Slurm DevOps, conocí a Artyom Galonsky, STO Bureau of the Bureau. Dio una conferencia sobre CI / CD y la introducción a la automatización. Habló sobre las líneas de transporte de ensamblaje de fábrica y su aplicación en TI. Y al mismo tiempo compartió ejemplos prácticos, como la construcción de una tubería "común".
Después del discurso, lo pillé en un descanso para tomar café y me pidió que le contara sobre el lugar de DevOps en su actividad profesional y, al mismo tiempo, qué requisitos ve para el puesto de ingeniero de DevOps. Artyom me sorprendió al decir que los ingenieros de DevOps existen en el mismo universo que los unicornios rosados. Y para él, " no hay ingenieros de DevOps, hay buenos administradores que entienden a Kubernetes ".
Sobre carrera
Has estado en desarrollo durante 11 años. Comenzó en Bureau Bureau?
No Comenzó como freelance en 2008, luego planteó varias startups. "Otfermery" fue una startup. Existió durante 2 años y tomó forma. En 2011, comenzó a participar en sistemas CRM para una agencia de seguros. Había un pequeño equipo: 4 personas. En 11-12 se convirtió en un líder de equipo. Fue un desarrollador líder, jefe del departamento de desarrollo de la compañía. En 2017, se convirtió en el STO de RedStart en Kaliningrado. Y a principios de 2018, me mudé a la Oficina de la Oficina.
¿Qué te atrajo?
El proximo paso. Ofrecieron condiciones interesantes. La oportunidad de armar tu equipo. Más proyectos interesantes. Me mudé de Kaliningrado a Moscú. Trabajó en Moscú durante seis meses. Luego, los directores de la Oficina de la Oficina decidieron que deberíamos abrir una oficina administrativa en Kaliningrado.
Por qué
En primer lugar, yo mismo soy de Kaliningrado. Conozco más profesionales fuertes y de alta calidad en Kaliningrado que en Moscú. El mantenimiento de cualquier necesidad es más barato en Kaliningrado. Y la comunidad de TI es fuerte allí. Y la zona económica libre avanza lentamente.
En Southbridge creemos que el potencial de la provincia aún no se ha desatado por completo. Que hay una gran cantidad de personas talentosas e inteligentes que, por varias razones, psicológicas, sociales, financieras, no pueden mudarse a la capital.
Sí, ni siquiera es psicológico o qué razones ... La gente simplemente no quiere moverse.
Sí, estoy hablando de esto. No todos quieren moverse.
Y este no es un problema, psicológico o financiero. Una persona simplemente no quiere.
Si Estoy de acuerdo "Problema" es una mala palabra. Más bien, "instalación".
Una persona simplemente no quiere. Él se siente cómodo allí. Trabajé durante seis meses en Moscú, reuniendo un equipo. Me fue difícil por la mañana pasar 40 minutos en un viaje al metro. O en atascos en el automóvil aún más. Ahora estoy en Kaliningrado estos cuarenta minutos caminando por lugares pintorescos, pasando por lagos, pasando por hermosas casas. Y estos cuarenta minutos disfruto la vida. Y respirar aire limpio. 20 minutos, y estoy en el mar. 40 minutos, y estoy en Europa. Además, muchos tipos que viven en Kaliningrado cuando se enteraron de que estaba regresando, dijeron: " Está bien, vamos, estaremos encantados de volver a tu equipo y seguir trabajando contigo ". Y desde hace un año, nuestra oficina administrativa (desarrollo, pruebas, análisis, gerentes de soporte) se encuentra en Kaliningrado. Y estamos felices y felices.
¿Y en moscú?
En Moscú, tenemos una oficina principal. Gerentes, gerentes de proyectos, cuentas de directores, diseñadores de interfaces, diseñadores y administradores de sistemas.
¿Y cómo es la interacción?
Nada interfiere. Todo funciona casi a la perfección. Todo depende de cómo lo configure.
Usted mismo, como estación de servicio, ¿a quién prefiere: empleados remotos o en la oficina?
Lo principal es establecer el intercambio correcto de conocimiento. Omito Workflow, porque si el flujo de trabajo no está establecido, no importa cómo se intercambie el conocimiento. Nada funcionará de todos modos. Pero el intercambio de conocimientos para que las personas compartan sus prácticas, lo que inventaron, entendieron, hicieron, es mejor en casa cuando están sentados en la misma oficina. De una forma u otra, comenzarán a comunicarse sobre este tema. Y cuando las personas están remotamente, no pueden compartir. Por lo tanto, es importante crear una base de conocimiento. Es necesario motivar a las personas a compartir esta información. Todos los viernes, la tecnología, es decir, todos los que no tienen un proyecto "en llamas", se dedican a la autoeducación en la segunda mitad del viernes. Y luego comparte con otros.
Sobre el desarrollo
¿Cómo te motivas?
Motivo el desarrollo. Francamente, todo cambia muy rápidamente en la "web", y si no se desarrolla, permanecerá en este nivel para siempre. Y en términos de dinero no crecerás, y en términos de desarrollo.
Una de mis citas favoritas de Lewis Carroll de "Alicia en el país de las maravillas": "Aquí tienes que correr tan rápido solo para permanecer en el mismo lugar, pero para llegar a otro lugar debes correr el doble de rápido".
Tenemos casi lo mismo. En los 11 años que he estado involucrado en la web, la tecnología ha cambiado drásticamente. Hace dos años, relativamente hablando, no sabíamos qué es Kubernetes y cómo implementarlo. Ahora está en todas partes. Y en un año será necesario para todos. Porque la carga aumentará. Si no bombea conocimiento y lo usa en sus proyectos, se quedará atrás. Al comenzar cada proyecto, tratamos de presentar algo nuevo. Trabajando constantemente en un producto, es bastante difícil introducir uno nuevo. Y es un poco más fácil para nosotros: al comenzar un nuevo proyecto, presentamos nuevas tecnologías que hemos estudiado y probado. Y estamos desarrollando de proyecto a proyecto.
¿Qué tecnologías utiliza ahora, cuáles considera relevantes y necesarias?
Tenemos lo que estamos haciendo ahora, la pila es bastante simple: la interfaz react.js, para el backend que usamos PHP parcialmente antes y ahora, ahora estamos tratando de cambiar a Go. Esta es una línea tan recta, donde nos estamos moviendo, para dejar PHP completamente en Go y desarrollar en él. Esta es una tecnología nueva, buena y estable, que proporciona un excelente aumento de la velocidad, tanto en el desarrollo como en la velocidad del producto en sí. Es decir, nuestra pila es React.js, PHP y Go. Esto es para lenguajes de programación. Bueno, así como las tecnologías estándar de Redis, PostgreSQL, RabbitMQ.
Puede recordar tecnologías que ya están desactualizadas. Recientemente hablamos con los chicos, por lo que se burlaron entre ellos porque alguna vez fueron profesionales en Perl.
Si Bueno, probablemente alguien más esté usando Perl. El mismo JS, que está en constante evolución ... Lo que era antes de ES6 está en desuso, o el mismo jpl. El mismo js llegó al "nodo" y se convirtió en node.js. El mismo php, bueno, a alguien no le gusta: la versión 5 era mala, ahora 7.2 se está desarrollando según las tendencias actuales. Para mí no hay uno que esté completamente desactualizado. Moralmente, tal vez sí. O me salgo de la tecnología. Anteriormente, hace 10 años usaba MySQL, ahora para los proyectos que estoy estableciendo, es inútil en casi todas partes. Las tecnologías que tenía ... Lo más probable es que creciera a partir de ellas de lo que estaban desactualizadas.
¿Qué te gusta de Go now?
Velocidad de ejecución, ahorro. Para todos Lo que veo, al comunicarme con mis arquitectos, clientes potenciales y desarrolladores, digamos que lo que estamos acostumbrados a ver en el script php, permanece en Go, además de que se agregan las características de los lenguajes compilados. Goroutines, multicanal. Lo que no estaba en php, y lo hicimos a través de php-fpm, relativamente hablando. Además de una fuerte tipificación de datos. Y también una compilación rápida del binario en sí.
¿Qué es un buen desarrollador para ti?
Para mí, un buen desarrollador es alguien que puede cambiar a un nuevo lenguaje de programación en unos 2-3 meses para comprenderlo. Naturalmente, no hará nada durante 2-3 meses. Él estará en la etapa de "junio", hacer tareas simples. Se bombea rápidamente y comienza a cerrar tareas complejas y buenas.
¿Con qué empresa te relacionas: naranja, turquesa?
No somos turquesas con seguridad. Más bien naranja. Con control vertical. Yo mismo soy un poco autoritario en la gestión. Hacemos esto y aquello, y si no vienen a mí y prueban con ejemplos obvios que es mejor de otra manera, será muy difícil convencerme. Si no se prueba, entonces esto no es necesario. Supongamos que viene un empleado y dice: “Artyom, tenemos que hacer esto. Por esta y esta razón. Usted sugirió una mala idea. Sí, usted es el director y arquitecto. Pero no ofreciste una muy buena idea. Y debemos hacerlo ". Y si no he sido claro y 100% probado, entonces presionaré mi decisión. Así que no es turquesa seguro.
Digamos, relativamente hablando, ha aparecido una nueva tecnología. ¿Y cómo puede un empleado demostrarle que vale la pena usarlo si pocas personas todavía lo usan y no hay ejemplos representativos y casos prácticos? Pero la tecnología es supuestamente prometedora.
Mostrar proyecto de mascota. Bueno, no solo: " Mira, eso es lo que hice ". Esto ya debe estar preparado. Para que una persona haga esto conscientemente, trató de ponerlo en producción, para darle una carga. Se acercó a mí y me dijo: “ Encontré tal característica, lenguaje, tecnología. Creé un pequeño producto completo o microservicio ". Entonces escucho. Todavía hay un problema: cuando se trabaja con un negocio serio, se necesitan tecnologías establecidas. Podemos avanzar y avanzar. Y nuestros clientes, a veces son monstruosos, debido al hecho de que son muy grandes, especialmente los estatales, están listos solo para tecnologías estables y no les gustan los experimentos. Recuerdo que hace dos años sugerí reaccionar ante alguien, y la respuesta aguda es " No. No vamos a trabajar Por qué Este es algún tipo de biblioteca para la interfaz de usuario. No Html, Css, Js, nos conviene ". En las grandes corporaciones, las estructuras estatales resulta que el desarrollo de nuevas tecnologías es un poco tardío. Hasta que la tecnología se estabilice, hasta que encuentren a una persona que conozca esta tecnología y la respalde desde adentro, no se arriesgarán.
Sobre proyectos
¿Cuándo es fácil trabajar con un cliente?
Creo que cuando hay un buen arquitecto por parte del cliente. Entonces se vuelve interesante trabajar. Luego obtenemos un buen orden, buenas tareas y buenas soluciones. Y entienden cómo se implementará esto. Y cuando en el lugar del cliente solo hay una gerencia y un analista de productos que desean algo como esto, entonces es más difícil. Los sistemas son muy grandes. Y entregamos un producto que será parte del sistema. Y nos dicen: “ Ah, y conectan estos dos productos juntos. Para que el usuario haga clic en este botón y tenga esto ... "Y hay muchas cosas ocultas: autorización, transferencia de datos. Y preguntas: " Chicos, está bien, ¿cómo debería suceder dentro? ¿Qué es exactamente lo que quieres? "Y respondieron:" Oh, no lo sabemos. Lo principal es que todo debe ser hermoso. Y lo que hay debajo del capó: usted le dice a nuestra seguridad de la información. Permítales comprobar si funciona bien o no ".
¿Puedes recordar un ejemplo cuando resolviste un problema rápida y originalmente?
Tenemos proyectos en los cuales la autorización es solo de ESIA. Y ESIA a menudo se acuesta. Cuando una persona inicia sesión, verificamos que es él quien inició sesión. Y hay una conciliación de los datos del ESIA de que su pasaporte u otros documentos no se han actualizado. Y entonces ESIA estropeó algo. Y tenemos un grupo de clientes que intentaron iniciar sesión y recibieron el mensaje “ Sus datos han cambiado. Por favor confirme ". ESIA comenzó a emitir un nuevo nombre o segundo nombre o nuevos datos de pasaporte. Y no podemos hacer nada, porque nuestro sistema está tan configurado que ESIA es el centro de la verdad para nosotros. Y detuvimos la autorización por un tiempo. ESIA rápidamente decidió todo. Nuestros administradores en el nivel de equilibrador de usuarios han enviado a la página " Lo siento, temporalmente no funciona ". Y lo terminamos rápidamente para que solo los clientes antiguos pudieran iniciar sesión sin actualizaciones temporalmente. Y no se permitieron nuevos usuarios. Bueno, esta no es realmente nuestra situación, pero nos conectamos allí para encontrar una solución.
Dime, ¿cuál fue el proyecto de desafío más interesante para ti últimamente? ¿De qué obtuviste el placer profesional?
R: Lo disfruté ... Hicimos una cuenta personal para Siemens Finance. Una subsidiaria de Siemens, que se dedica al arrendamiento en Rusia. Junto con ellos desarrollamos una cuenta personal. Aquí el placer es que Siemens nos dio la oportunidad de construir una buena arquitectura, el cliente no intervino y transmitió " Chicos, confiamos en ustedes ". Hicimos una buena UI y UX para ellos. Muy buen trabajo con el cliente. Y eso no fue un desafío o superación. Entonces realmente disfruté el trabajo. Del producto que finalmente se recibe. Y ahora el producto funciona, vive. A todos les gusta, y a mí me gusta. Y así, los desafíos que tenemos son constantemente. Al trabajar con grandes empresas sin esto de ninguna manera. Cada compañía tiene 12 departamentos: hay un departamento de TI, hay un departamento de infraestructura, un departamento de lógica de negocios y algo más. Además, hay muchos vendedores, personas como usted que integran su CRM. Y coordinar cualquier cambio con todos estos departamentos es un desafío. Ofrece su arquitectura, se comunica con el arquitecto de la empresa principal, interactúa con los arquitectos vendedores ...
Pero, ¿no debería lidiar con esto el arquitecto de la empresa cliente?
No siempre Hay un tema tan de moda: la transformación digital. Por ejemplo, la compañía tiene un arquitecto, y él estuvo directamente involucrado en la arquitectura de su solución. Por ejemplo, la facturación o el sector bancario. Pero él, como arquitecto de todo el sistema, no tiene la experiencia y competencia necesarias. Pero un buen especialista comienza a aprender. Y quién no tiene la edad o ya está en edad es un poco más complicado aquí, porque no están atentos a las nuevas tendencias. Y tienen que comunicarse durante mucho tiempo y explicar, dicen, muchachos, intentemos esta solución progresiva. Y en algún lugar hay jóvenes arquitectos que crecieron en la "web" moderna. Ahí es bastante simple: condicionalmente, sincronizamos así, conectamos estos módulos de esa manera. Y ellos dirigen rápida y competente.
¿Entonces ya ves dos generaciones diferentes de desarrolladores?
En la web, sí. Porque ahora todo se está moviendo a la web. Ahora, incluso los sistemas internos se están moviendo gradualmente hacia microservicios que se comunican por API. Y la API suele ser http y https. Los arquitectos deben entender cómo funciona esto. Y la forma más fácil de escuchar a quienes trabajaban en la web. En mi opinion. Muy a menudo ocurre esta situación. El cliente quiere un nuevo sitio genial. Él ve qué sitio tiene un competidor, cómo funciona este sitio. Y él viene, exige que establezcamos toda la historia digital del sitio, hasta CRM. Y solo nos ocupamos del sitio. Estamos listos para integrarnos con el CRM de alguien. Y resulta que nos convertimos en motores de cambios para una empresa en particular.
Acerca de la tecnología
Transformación digital: ¿cuánto crees que se necesita?
Como cualquier tema publicitario, está de moda y es necesario. Tenemos una gran cantidad de pedidos para realizar una descarga de Excel. Un número increíble de empresas trabajan en Excel. Y necesitan hacer que esta carga "sobresaliente", analice, se convierta en una base de datos y luego pueda trabajar con ella y luego descargarla. La transformación digital debería conducir a la transición a sistemas de trabajo normales: CRM, sistemas de contenido, CMS. Y abandone Excel y viva en un mundo web normal. Hay un buen ejemplo. En la empresa anterior, donde trabajé antes de Bureau-Bureau, teníamos dos empresas clientes. Y pudimos rastrear en detalle cómo sucede todo. En una empresa, el servicio al cliente pasó por Excel. Había una gran base de datos. Fue el año 2012-2013. El CRM normal no era adecuado allí: mucho flujo de trabajo y tomó mucho tiempo configurarlo en CRM ordinario. Y una empresa se puso a trabajar en Excel. Y el segundo pasó medio año, y escribió su CRM. Como resultado, la primera compañía seis meses después de alcanzar el pico de ventas, y comenzaron a trabajar con los clientes, colapsaron. Es solo que su servicio de llamadas no pudo proporcionar un servicio bueno y rápido. Y la segunda compañía, con su CRM, por el contrario, rastreó rápidamente con un botón, qué tipo de cliente, cómo llegó a ellos, qué gerentes le respondieron. Sobrevivieron a este pico de crecimiento, y todavía están trabajando. El flujo de trabajo electrónico también es una tendencia. Ahorro de tiempo Quien opera más rápido con información, gana más rápido. Entonces en todo. Si no hay un buen monitoreo ni un buen registro del proyecto, los ingenieros no podrán entender rápidamente cuál es el problema. Y la supervivencia y el éxito del negocio realmente dependen de ello ahora. Por lo tanto, es necesario no solo joder un sitio web hermoso, sino también construir el sitio web correcto y el sistema de registro correcto. Se necesita transformación digital. Es necesario mantenerse al día. Si existen tales tecnologías, debemos intentar introducirlas.
¿Qué tecnologías ves ahora que serán prometedoras en el futuro cercano? Por ejemplo, hace dos años, Kubernetes se consideraba prometedor. Ahora es simplemente necesario.
El futuro es el aprendizaje automático y la inteligencia artificial. En cinco años, esto será relevante. Hace un año, había criptografía y había aprendizaje automático sobre exageración. Ahora todo está tranquilo. Pero aún así, en los próximos cinco años, el aprendizaje automático se disparará, como creo. El trabajo está en marcha: la experiencia y las soluciones se están acumulando.
Se cree que con el aprendizaje automático y la inteligencia artificial, muchas profesiones simplemente desaparecerán. Esto se aplica tanto a los maestros como a los economistas. Y los abogados dicen que la tecnología blockchain moverá ciertas áreas en la jurisprudencia. ¿Qué profesiones en TI, como ves, desaparecerán?
Las cubiertas, como creo, desaparecerán. Me parece en los próximos tres años. Como dice el refrán, recuerda este tweet. (Risas) Lo más probable es que el aprendizaje automático se escriba pronto, lo que será un buen diseño. Se les ocurrirá algo. Y luego, probablemente, los programadores de sistemas simples desaparecerán. Pero aún así, siempre habrá programadores que diseñarán y programarán el núcleo del microchip. Siempre habrá programadores.
Oh devops
Ahora en el mercado hay un cierto déficit de ingenieros de DevOps ...
Escucha, estoy categóricamente en contra de un ingeniero de DevOps.
Por qué
DevOps es una práctica, es una filosofía. Ingeniero DevOps: ¿quién es? ¿Es un administrador bombeado o es un "backend" bien bombeado que puede estar en el administrador? Para mí no hay ingenieros de DevOps, para mí hay buenos administradores que entienden Kubernetes. Pero Kubernetes no es DevOps. Lo único que acepto por mí mismo es el evangelista DevOps. ¿Quién puede venir a la empresa y decir: “ Chicos, tenemos que avanzar en esta dirección. Aprende a comunicarte e interactuar ". Porque DevOps no se trata de tecnología. En general, toda la filosofía de DevOps se trata de la interacción. Para aprender a comunicarse, desarrollo y control de calidad, y soporte adicional. Y todos estos ingenieros de DevOps me recuerdan las exageraciones de los maestros de scrum hace aproximadamente tres años. Todos necesitaban scrum-masters, nadie podría trabajar sin ellos. O hace cinco años, todos necesitaban urgentemente un administrador de configuración de Jira. , «», . , DevOps — .
, - ?
, - . . , — , , «», , . , «». , DevOps. , DevOps-. . — . Kubernetes.
, IT-?
. . . . 90- .
, , ?
. . , . - . — , . , . , , , . . . , . , . , , . — .
Post scriptum
. , , , , - — , , . . , , , , , -. , . ? «Time will tell. Sooner or later time will tell».©