DevOps tiene al menos dos vistas bien establecidas: del lado de los administradores del sistema y del lado de los desarrolladores. Los primeros generalmente se jactan de que han estado usando Chef / Puppet / Ansible / Docker desde 200X, los segundos creen que DevOps ha sobrevivido a sí mismo y conduce a NoOps, o que "envolví todo en un contenedor, y luego cómo funciona".
Al mismo tiempo, el negocio lee sobre DevOps en artículos y espera que los chicos de abajo descubran qué hacer con él. Al mismo tiempo, DevOps en sí no sucede, el negocio no se parece a Google, la compañía no se vuelve turquesa, la gente no crea nuevos enfoques para probar hipótesis en el mundo.
Este artículo trata sobre DevOps como sistema. Cómo ayuda al negocio, qué competencias de los ingenieros deberían aparecer para DevOps, qué tareas comerciales pueden resolverse mediante el método DevOps de producción de software y qué errores son posibles en el camino hacia la producción de DevOps y cómo evitarlos o detenerlos. Cómo, al final, cómo puede un ingeniero convertirse en un Hombre y ser un creador en este mundo, cómo construir una carrera profesional para esto y cómo comenzar a mirar la tecnología humanamente.
El material se basa en la transcripción del
informe de Alexander
osminog Titov de nuestra conferencia DevOops 2017 de octubre.
Para aquellos que están acostumbrados a ver informes de conferencias en grabaciones, adjuntamos un video.Trabajo para Express 42. Mi historia es sobre mi trayectoria profesional, pero le proporcionaré consejos y conclusiones interesantes. Tiene un nombre pegadizo "Del administrador del sistema a la persona". Separo el rol del administrador del sistema de alguna condición humana. DevOps nos mueve a ser no solo artistas, sino creadores de nuevos productos digitales y más.
Como mi historia se basa en mi experiencia, te contaré un poco sobre mí. Comencé como administrador del sistema cuando estaba en la universidad. Trabajó en el turno de noche, luego comenzó a trabajar en el turno de día, luego ascendió al puesto de administrador principal del sistema. Luego trabajé en las redes sociales connectect.ua y fakultet.ru, luego como director técnico en la empresa Oversan-Skalaksi. Este fue uno de los primeros intentos de lanzar hosting en la nube en Rusia, como resultó, un intento muy temprano. La necesidad de alojamiento en la nube en Rusia surgió solo ahora. Simplemente entendimos cómo usarlos, nos dimos cuenta de que estos son recursos flexibles, que necesitan escribir aplicaciones de manera diferente, y así sucesivamente. En aquellos días, nadie entendía esto en absoluto, por lo que venderlo era muy difícil.
Luego trabajé en una startup Qik de Silicon Valley, cuya oficina de desarrollo estaba aquí en Rusia. En Qik, realmente sentí el beneficio del concepto DevOps, porque en dos meses creamos un producto que creció de 0 a 5 millones de usuarios. Si en Oversan-Skalaxi, desde el punto de vista del servicio, sentí que se necesita DevOps y la gente necesita comprender qué es DevOps para usar el alojamiento en la nube, entonces en Qik sentí esto como administrador del sistema y como jefe del departamento de administradores del sistema. Luego fuimos comprados por Skype, y comenzamos a integrarnos allí, y también a integrar los desarrollos en el campo de DevOps allí, porque no estaba en Skype. Y luego Skype compró Microsoft. Parece que llegó a una empresa donde viven unas 40 personas, y después de unos años trabajas en una gran empresa con 100 mil empleados. Fue una experiencia muy interesante.
Como resultado, no encontré dónde avanzar más en estas compañías, y mis colegas y yo abrimos Express 42, que lleva DevOps a las masas. Esta idea se originó en Oversan-Skalaksi, y me impulsa. Entre otras cosas, estoy muy entusiasmado con la comunidad DevOps en Rusia. Soy el organizador de DevOpsDays Moscow y Moscow DevOps-meeting.
Hace tiempo que me preocupa que usar Ansible pueda ser malo o bueno. La herramienta en su conjunto no resuelve nada. Puede usar Docker, Kubernetes, instalar el último Prometheus, pero al mismo tiempo, lo que haga no será diferente de lo que tienen las personas que usan scripts bash. Trataré de responder por qué sucede esto. En muchos sentidos, esta respuesta se encuentra dentro de nosotros, por lo que el artículo se llama así. El administrador del sistema piensa cómo escribir bash-scripts para él, y la persona piensa un poco diferente.
¿Cómo aparece DevOps en la empresa?
Desarrollador DevOps
Hay varias formas en que DevOps puede aparecer en una empresa. Una de estas formas es cuando los desarrolladores, cansados de pedirle a los administradores del sistema que hagan algo, y después de escuchar sobre DevOps, intentan implementarlo. Pero al mismo tiempo tienen una comprensión peculiar de DevOps. Piensan que pueden usar cualquier tecnología, envolver todo en un contenedor Docker y enviarlo a los administradores del sistema, pero no piensan en absoluto sobre cómo funcionará su código en la producción. No han cambiado nada en sus cabezas para cambiar a DevOps, pero al mismo tiempo están comenzando a usar nuevas tecnologías.
He visto muchas de esas compañías. Usted viene a ellos, tienen cuatro departamentos de desarrollo. Cada departamento escribe su propio microservicio, cada departamento tiene su propia base de datos. Alguien Redis, alguien PostgreSQL, alguien PostgreSQL y MySQL al mismo tiempo. Y acompañan esto, hasta que las bases de datos crecen a tal tamaño que ya no pueden.
En este punto, todo comienza a desmoronarse y desmoronarse, y surgen consecuencias aterradoras. Este es un zoológico tecnológico con el que no está claro qué hacer. Además, la peculiaridad del desarrollador es que resuelve el problema arrastrando una nueva biblioteca. Creo que aquellos que trabajan con los desarrolladores de Node.js están familiarizados con esto. Cuando los desarrolladores de Node.js ven que la base de datos no funciona bien, pueden saltar de PostgreSQL a alguna versión, agregar alguna extensión o comenzar a usar algunos JSONB. Como resultado, surge un terrible estado de arquitectura, pero en general están satisfechos con todo. La aplicación es difícil de administrar, no puede darse cuenta de lo que está sucediendo allí, tiene poca estabilidad, se bloquea constantemente. En respuesta a la aplicación bloqueada, los desarrolladores pegan algo más allí, y continúa cayendo aún más, y como resultado, nada se entiende en absoluto.
Sysadmin DevOps
Existe tal cosa como DevOps-sysadmin. Por lo general, estos son tipos muy poderosos que han demostrado ser buenos. Vienen y dicen:
"Chicos, no pueden vivir así, nos cansamos de tirar de este fluido. Ahora estamos automatizando todo, haremos que la tubería de entrega sea tan dulce, maravillosa y que funcione bien. Sabemos muy bien cómo debería funcionar la aplicación en producción. Mucho mejor que estos piqueros escribiendo en Node.js. Y sabemos lo que hay que usar para que todo sea perfecto ".Varias veces me encontré con el hecho de que esas personas construyeron DevOps en FreeBSD. El resultado fue un sistema cerrado, que ellos mismos escribieron, y solo ellos entendieron cómo funciona. A pesar de la experiencia de mi administrador de sistemas, no pude resolverlo, pero si no podía, ¿cómo debería entender el desarrollador cómo implementar a través de este sistema de CI? Como resultado, prohibí administrativamente el uso de FreeBSD en la empresa, a pesar de que sinceramente amo y respeto el sistema en sí mismo, especialmente me encanta OpenBSD. Pero una semana después, entre los servidores Linux, los servidores FreeBSD comenzaron a aparecer nuevamente, como los agáricos de mosca.
Los administradores del sistema DevOps, así como los desarrolladores, piensan que la tecnología es lo más importante, que nada se puede hacer sin ellos. Si les gusta la tecnología, intentan mantenerla en todas partes.
En Oversan-Skalaxi acuñamos el término configuraciones y scripts de solo escritura. Esto es cuando una persona puede escribir, pero nadie puede leer.
Al mismo tiempo, los administradores del sistema continúan reparando algo en el jabón. Vienes a él y le ofreces ayuda, y él te da algo con un tapete de tres pisos. No entiendes nada, porque tienes que descubrir lo que ha hecho. Bueno, si el desarrollador viene y dice, por ejemplo, que necesita una base de datos tolerante a fallas. Se le dará algo con este tapete de tres pisos, se sentará y no entenderá qué hacer con él. Todos navegaron, los desarrolladores y los administradores del sistema no se comunican. Aunque por dentro se utiliza todo lo más moderno, sofisticado.
De aquí surgió la idea tradicional de los administradores de sistemas: se trata de una persona con múltiples brazos que hace algo, pero no entenderá exactamente qué. Por cierto, la mayoría de los recursos humanos ahora están buscando exactamente eso. Puedo decirle que encontrar a esa persona en la empresa no lo salvará al 100% de los problemas.
DevOps para empresas
Otra forma para el surgimiento de DevOps es desde el lado comercial. Algunos de sus principales gerentes fueron a una conferencia de negocios, por ejemplo, al valle, donde le dijeron que si no tiene Docker, alguna integración continua (CI) y algo más, entonces no puede ser considerado empresa de tecnología El gerente regresa, recoge empleados y lee palabras de un cuaderno: DevOps, Docker, Concourse CI. Los chicos comienzan a entender, y luego suceden los escenarios mixtos que se mencionan anteriormente: DevOps-developer, DevOps-sysadmin, y todo esto lleva a un desastre que no se puede entender.
De hecho, constantemente veo tales situaciones. ¿Por qué sucede esto: vienes a la conferencia, todos tienen una visión racional y normal, luego entras a las trincheras, a la producción, y luego hay basura y humos? Es decir, todos entienden todo, pero por alguna razón no funcionan. Tengo la hipótesis de que todos entienden alguna parte, no todas. Y ahora intentaré hablar holísticamente sobre DevOps.
De la empresa a lo ágil
En primer lugar, desde el punto de vista empresarial, estamos experimentando un punto de inflexión: nos estamos alejando de una empresa que está implementando proyectos monumentales para transferir el negocio en sí del punto A al punto B (por ejemplo, una estrategia de cinco años para capturar el 70% del mercado) ...
... y ven al mundo de Agile. El punto de Agile no es ser flexible, pero ese punto A es conocido y B no. Y esto es lo más profundo que puede suceder. Porque ni nosotros ni las empresas estamos acostumbrados a trabajar con esto. Imagine que no sabe lo que sucederá en una o dos semanas, que el líder se acercó a usted y le dijo:
"Entonces, trate de conseguirme algo que no puede ser, escriba su nombre para que no se olvide rápidamente" . Y no sabes qué hacer, pero el mundo y los negocios se están volviendo así, y debes acostumbrarte. Y todas estas prácticas, como Agile, Scrum, Kanban, no tratan sobre cómo vivir con él.
Estamos pasando del camino de las empresas-empresas y corporaciones al camino de la tecnología. Algún software está comenzando a interactuar con nosotros en el mercado. Si las personas anteriores, las empresas interactuaban con nosotros, los vendedores llamaban por teléfono, etc., ahora para llamar a un taxi, pedir pizza, escuchar música, vamos a la aplicación. Y una aplicación es un software que alguien necesita escribir y adaptar continuamente al mercado. Y nosotros, los ingenieros y aquellos que se dedican a los negocios, debemos entender desde la aplicación lo que está sucediendo con el mercado. Y al final, nos mueve hacia DevOps.
DevOps no aparece porque uno de ustedes debería sentirse cómodo, y no porque necesite usar tecnologías más frescas. NoSQL no es más genial que SQL; además, es mucho peor que SQL por el estado hace 3-4 años. Las bases de datos SQL se han desarrollado durante 20 años y las bases de datos NoSQL durante 1 año. Y recordamos el estado deplorable de MongoDB hace 4 años, cuando no era una base de datos en absoluto.
DevOps es igual que antes, solo que ahora estamos haciendo todo al mismo tiempo. Si usted es un desarrollador, escribe código e inmediatamente escribe pruebas, un contenedor para Kubernetes, o simplemente un contenedor Docker, cómo debería funcionar en la producción. Y al hacerlo, debe cumplir una condición mínima: ejecutar este código. Debido a que muchos desarrolladores en la era anterior no hicieron esto: el compilador compiló, y lo que comenzó allí y comenzó a funcionar en el contenedor de la aplicación ya es la décima cosa. Al mismo tiempo, escriba métricas, registros que deben recopilarse. Y luego lo pierdes todo en Delivery Pipeline, Jenkins, TeamCity o algo más. Esta es una diferencia fundamental entre un desarrollador en una corporación y un desarrollador en una compañía de tecnología. Aquí, el desarrollador comienza a escribir no solo algoritmos, sino todo el producto.
Historia de DevOps
Este es el momento de pasar a la historia de DevOps. ¿Cómo sucedió todo esto? Viví esto, leía constantemente las noticias, seguía la cadena histórica, cómo aparecía todo. Y ahora, diferentes personas de diferentes años me dicen diferentes versiones de qué es DevOps y cómo surgió. Y me parece importante volver a las raíces.
En 2003, Ben Trainor en Google creó el equipo SRE. Google es la primera gran empresa digital del mundo. Ya en 2003, se enfrentaron con el problema de que, de la manera clásica a la que están acostumbrados todos los desarrolladores de software, no pueden hacer lo que quieren. E innovaron al presentar al equipo SRE, y desde entonces han desarrollado esta práctica.
En 2009, John Alspaw y Paul Hammond dieron una charla sobre trabajar juntos dentro de Flickr y cómo comparten 10 veces al día. En ese momento fue una sensación y una explosión. Y Patrick Deboit espió este informe y acuñó el término DevOps, organizó la comunidad mundial para desarrollar aún más esta práctica.
Surgieron compañías tecnológicas que necesitaban compartir rápidamente. Los enfoques antiguos no encajaban y comenzaron a surgir otros nuevos. Y sin problemas, naturalmente, se reorganizaron para que tuvieran una nueva práctica de crear software.
Estamos en una situación muy difícil, porque no tuvimos este cambio natural. Dichas tecnologías nos llegan cuando algo ya ha sucedido allí, pero aún no sabemos cómo usarlas. Allí, la gente llegó a esto evolutivamente, y tenemos que hacer una revolución, repensar todo esto y de alguna manera cambiarlo a su propio suelo.
¿Cómo aplicar DevOps?
Al usar DevOps, es muy importante darse cuenta de que está haciendo un producto digital y que el tiempo de comercialización (TTM) es importante para las empresas.
Es importante convertir a todos los equipos en equipos de desarrollo. Ya no hay un administrador de sistemas separado, un desarrollador separado. Porque aquellos a quienes llamamos administradores de sistemas escriben lo que se llama una plataforma de infraestructura, y los desarrolladores escriben lo que se llama un producto, y por lo tanto se brindan mutuamente un servicio.
Otra cosa obvia y muy importante que todos olvidamos es la organización de la acumulación e intercambio de conocimientos dentro del equipo y entre equipos. Tenemos grandes problemas con esto. No nos gusta compartir algo que, por ejemplo, aún no está listo, y esta es la clave para que exista DevOps. Debemos hablar sobre lo que no está listo, probar hipótesis, debemos estar abiertos a que alguien nos diga que no está listo. Debido a que estamos acostumbrados, por ejemplo, si los administradores del sistema probaron algo interesante, vinieron, dijeron, respondieron:
"No, pero ¿cómo funciona en la producción, qué probaron
?"Los administradores de sistemas, al darse cuenta de que en algún lugar no entendieron, en algún lugar que no probaron, se fueron, cerraron, y este conocimiento desaparece, y no damos un paso adelante. Y es correcto decir:
"¡Chicos, miren! Hiciste un trabajo realmente genial, un gran trabajo, pero hay una pregunta que realmente quiero hacerte: ¿cómo funcionará esto en la producción? ¿Has pensado en esto? "¡La próxima vez que nos muestre cómo implementar esta función en producción, será genial!"Ya se están yendo con la tarea. Y en el caso de nuestro enfoque clásico ruso
"sí no no, toda la basura", se van con el pensamiento
"¿por qué deberíamos hacer esto si todos nos rechazaran?" . Y este es un gran problema dentro de la comunidad DevOps. No compartimos entre nosotros, porque no estamos seguros de que esto no sea reconocido como obvio o no tan duro como parece, y así sucesivamente.
Los organizadores de la conferencia ya me han dicho que todos requieren un mega hardcore. Bueno, tal vez no puedas hacer un megahardcore, pero para que una persona comparta una experiencia real y puedas hablar de ello, también es genial.
Desarrollador en DevOps
El desarrollador de DevOps no escribe el código, sino el producto. Y esto no es algo obvio, porque en los institutos, cursos, libros, nosotros, como programadores, se nos enseña a escribir algoritmos, no productos, se nos enseña a resolver no un problema comercial, sino un problema algorítmico. Este es un gran problema. Es muy importante que recuerde en qué momento está resolviendo un problema algorítmico y en qué punto es un problema comercial real.
En una empresa que practica DevOps, el desarrollador piensa inmediatamente cómo se integrará su código con otros componentes. Inmediatamente comienza a comunicarse sobre esto. Por ejemplo, para aclarar en un chat una hoja de ruta de un cambio de API que utiliza para verificar. Este es el comienzo de la cooperación.
El desarrollador tiene una idea sobre la arquitectura de la aplicación; esto es muy importante, ya que sin comprender cómo funciona la arquitectura, cuáles son las capas tecnológicas y cómo interactúan entre sí, es imposible pensar en la integración.
El desarrollador sabe cómo funciona el código en la batalla y comprende lo que está sucediendo con esta aplicación. En mi ejemplo, cuando un desarrollador escribe código y un contenedor Docker y lo supervisa a la vez, debe tener una idea de cómo funciona la arquitectura, cómo funciona el código en la producción y cómo se integra en la aplicación. Aquellos de ustedes que trabajan como administradores de sistemas o ingenieros de infraestructura, piensen en cómo transmitir este conocimiento a los desarrolladores. Tu tarea es contarles al respecto. Puede contratar consultores, pero mejor solo.
Ingeniero de infraestructura
El siguiente rol que tiene DevOps es el ingeniero de infraestructura, que anteriormente se llamaba administrador del sistema. No me gusta mucho el término "ingeniero de DevOps" porque DevOps es una práctica común que cubre el desarrollo, las pruebas y la operación. Como dije antes, puedes tener un ingeniero de DevOps, un equipo de DevOps, la mejor tecnología y no tienes DevOps.
Un ingeniero de infraestructura crea una plataforma principalmente para el desarrollo de productos, pero debería ser conveniente para los desarrolladores. Este equilibrio debe ser tratado para cumplir.
Un ingeniero de infraestructura utiliza varias capas de abstracción para proporcionar servicios. Por ejemplo, hubo un buen
informe de Nikolai Ryzhikov sobre Kubernetes, donde mostró cómo seleccionar y usar varias capas de abstracción. Tenía un modelo ideal allí, que se pone en práctica. Tal modelo se puede cortar en niveles separados de abstracción. Esto se hace para reducir la complejidad de la resolución de problemas y la integración. Cuando tiene niveles comprensibles de abstracción, puede cambiar entre ellos y ver dónde están las discrepancias. No tiene que confiar en las capas de abstracción, pero son muy útiles para hablar de ello. Es decir, no deberían ser una herramienta absoluta, sino útil.
El ingeniero de infraestructura diseña la plataforma como un producto, sabe cómo ser propietario de un producto, qué es el pensamiento de diseño, sabe cómo reunir los requisitos de los desarrolladores. Pero este es un nivel alto, y no estoy seguro de que tales ingenieros estén presentes en el mercado en forma de ingenieros de infraestructura.
Tecnólogo de pruebas
El probador también cambia un poco y se convierte en un tecnólogo que logra la mejora de la calidad del software y convierte este proceso en código.
Release Manager / Estación de servicio
El gerente tiene en cuenta el proceso de entrega continua de software, gestiona las expectativas comerciales y las capacidades técnicas, produce lanzamientos y lanzamientos. Está produciendo, no planeando, porque el proceso de transición del punto A al punto B no es lineal, y en tales circunstancias no puede planificar.Como resultado, todos juntos crean una plataforma de infraestructura, que es una herramienta para todos: ingenieros de infraestructura, desarrolladores y probadores.
Aquí es importante que el código siga el proceso de entrega a la derecha y que quede la información sobre cómo funciona. Constantemente obtiene información sobre cómo pasa su código a través de la canalización de entrega y, utilizando esta información, realiza cambios.Lo principal que debe transmitirse entre sí, a los desarrolladores, a todos es que toda esta infraestructura es una herramienta común (como un git), que está siendo mejorada por todos. No puede decir que esto sea un problema de Petina, ya que estará sobrecargado, no podrá hacer frente a la complejidad de la información que proviene del código y, como resultado, obtendrá una tubería de entrega continua que funciona mal.Dentro de dicho esquema, es necesario dividir no la responsabilidad, sino el conocimiento y la experiencia. Algunas personas (director de lanzamiento o CTO) tienen conocimiento y experiencia sobre todo: tienen la imagen completa. Otros tienen conocimiento y experiencia sobre el sistema de orquestación de recursos, otros tienen conocimiento sobre la base de datos y así sucesivamente, y estos son diferentes equipos, diferentes personas que ocupan un lugar aquí y al mismo tiempo son responsables de toda la plataforma de infraestructura.
En Express 42, llamamos a esta nivelación el concepto de aplicación de servicio base. Hay un cierto nivel básico: el nivel de orquestación (asignación) de recursos y varios servicios de infraestructura de bajo nivel. Los ingenieros de infraestructura tienen más conocimiento y experiencia aquí. Hay un nivel de servicio: diferentes bases de datos, equilibradores de carga, monitoreo, registro, motores CI (TeamCity como motor o Jenkins como motor). Hay un nivel de aplicación que recopila estos niveles juntos a través de todo tipo de API, funciones, etc. Nuevamente, me refiero al informe de Nikolai Ryzhikov, mostró perfectamente cómo funciona todo esto y cómo implementar CI encima de Kubernetes.
Los procesos y las tecnologías son cruciales. Las tecnologías que usa, además de ellas mismas, tienen una forma de usarlo. Por ejemplo, puedes cortar pan con un cuchillo o puedes matar a una persona. Entonces está aquí, solo que en nuestro caso es aún más complicado, incluso más niveles de abstracción. Los procesos que crea en torno a esto son muy importantes. Y estos procesos, en principio, nadie puede crearlos, excepto usted, dentro de la empresa, porque están diseñados especialmente para aplicaciones específicas. Ahora, en principio, es imposible que, como antes, haya contratado a un consultor de ITIL, y él haya implementado todos los procesos para usted. La aplicación de Banca por Internet y Yandex.Music son diferentes como el cielo y la tierra. Hay principios generales, pero el proceso en sí es completamente diferente.Cada una de las capas de tecnología tiene sus propios procesos que deben construirse. Y aquí me refiero a las palabras de Alan Kay, quien una vez dijo en una entrevista a Habru una frase increíble: "Las computadoras se pueden comparar con los instrumentos musicales, su música son ideas" .En consecuencia, las tecnologías que tenemos deben incluirse en los procesos que crean la idea (la idea de mejorar el producto, la idea de cambiar los procesos, la idea de crear un nuevo producto). Esto es muy importante
Las compañías que practican DevOps deben organizar una plataforma dentro de sí mismas y algún sistema de valores que nos permita discutir qué ideas creamos usando las tecnologías que usamos y cuánto usamos estas tecnologías (Kubernetes, Prometheus, Docker, etc.) , para tocar música y no romper la guitarra en la cabeza de un vecino.En principio, el proceso DevOps desde el punto de vista de la persona dentro de la empresa debe organizarse de la siguiente manera. Debe haber unidades organizativas, como comités, que provengan de personas que necesiten discutirlo. Esto no debería ser un departamento de arquitectura o un departamento de integración, o un departamento de entrega continua, o un departamento de calidad; estos deberían ser comités que se reúnen y discuten cómo estamos trabajando y qué nuevas ideas creamos en base a nuestras tecnologías. Crean y cambian las formas de trabajar, y sobre la base de esto crean conocimiento, parte del cual será informal, y esto es normal. En general, los rusos saben bien cómo transferir conocimientos en metáforas, por ejemplo, cuando un mecánico dice "dame esta basura". A través de la cooperación y la comunicación, este conocimiento se crea e integra en las formas de usar las tecnologías y las tecnologías mismas,y este estándar de conocimiento se implementa en tecnología.El momento actual difiere del antiguo momento empresarial en que los estándares fueron clavados allí, y ahora están cambiando continuamente. En los últimos 3-4 años, muchas tecnologías y estándares de uso han cambiado, incluso es inútil arreglarlos en documentos, solo en la cabeza de las personas.Si le gustó este informe, venga a la conferencia DevOops 2018 : allí no solo puede escuchar los informes, sino también chatear con cualquier orador en el área de discusión. La conferencia se llevará a cabo en San Petersburgo el 14 de octubre, a partir del 1 de septiembre, el costo de los boletos aumentará.