En vísperas de DevOps Conf Russia 2018, hablamos con el director técnico de Uchi.ru, Alexei Vakhov, sobre las etapas del desarrollo de la plataforma, qué herramientas usan y cuánto hay de DevOps ovo.
Alexey Vakhov - Director técnico de Uchi.ru. Trabajó como desarrollador de C ++ en sistemas enormes (decenas de millones de líneas de código). Tecnología de servidor favorita: Ruby on Rails, se encuentra entre los 100 principales contribuyentes. Es aficionado a la organización de la producción de TI, operación, arquitectura de aplicaciones web.
Uchi.ru es una plataforma educativa rusa donde los estudiantes en los grados 1-11 estudian materias escolares de una manera divertida y entretenida. La plataforma es utilizada por más de 2.5 millones de estudiantes y 220 mil profesores en Rusia, Estados Unidos, Brasil, India, Sudáfrica y China. Ocupa el puesto 36 en el ranking mundial de plataformas de e-learning. La compañía tiene más de 400 empleados.- ¿Cómo empezó todo? ¿Cuántas personas había en la compañía cuando llegaste?- Fui invitado a la compañía en 2012, es decir, hace seis años. En ese momento yo era el quinto o sexto empleado, y el único desarrollador. Escribí e hice el desarrollo del servidor. Hicimos la primera aplicación web y la publicamos en Heroku.
"¿Cómo están las cosas ahora?" ¿Cuántos equipos y de qué tamaños? Que tan independiente ¿Cómo interactúan entre ellos?- Hoy tenemos más de 400 personas, de las cuales aproximadamente 100 son ingenieros que están unidos en unos 20 equipos separados. Tenemos dos grandes direcciones: desarrollo de producción y desarrollo de tareas interactivas.
Los equipos separados tienen su propio entorno aislado, sistemas especiales de construcción, mejorados para las tareas que realiza el equipo, sus propios servidores, códigos fuente. Se comunican entre sí solo cuando es necesario.
- Con esta tasa de crecimiento de la empresa, ¿logras hacer tu propia wiki? ¿Cómo la apoyas?- Tenemos varias bases de conocimiento. Hay una wiki en forma de confluencia, donde hay secciones generales y temáticas, y cada equipo tiene su propia sección. En cada repositorio, admitimos el archivo Léame y documentos técnicos adicionales. En cualquier caso, a cada equipo se le asigna su propio espacio, su propia pieza en jira, en confluencia, todo esto se organiza de acuerdo a los deseos del equipo. No tenemos un dictado y estandarización en el diseño.
- Un fuerte aumento está plagado de una pérdida de control. ¿Cómo lidias con esto? ¿Cómo coordinas el trabajo de tantos equipos?- La coordinación general se logra mediante la construcción de una jerarquía de gestión. Tenemos coordinadores de referencia y cada equipo tiene su propio líder. Todo es simple aquí.
Si responde esta pregunta desde el punto de vista de la tecnología, entonces los equipos se adhieren a las reglas generales, por ejemplo, las pruebas están conectadas a cada repositorio, todo el desarrollo pasa a nuevas ramas, que se verifican, se implementan en el entorno de prueba y luego a la producción.
- ¿Qué etapas de la formación de la empresa te distinguen?- Me gusta el enfoque sobre el que leí en un libro interesante, según el cual la crisis es cuando el sistema habitual de valores colapsa. En nuestro caso, hubo muchas crisis debido a un crecimiento tan rápido, y cada una de ellas determina el movimiento adicional.
La primera crisis vino cuando nos quedamos apretados en una habitación y tuvimos que expandirnos a dos. En esta etapa, apareció información que dejó de ser conocida por todos. La segunda y posteriores crisis se produjeron cuando los desarrolladores tuvieron que dividirse en equipos de productos. Una vez más, nuestro equipo grande y amigable se vio obligado a separarse y separarse en diferentes ángulos.
Cualquier cambio que tuvo lugar con nosotros fue necesariamente respaldado por innovaciones tecnológicas oportunas y relevantes. Lo mismo ocurre con la metodología DevOps. Podemos decir que yo mismo recientemente comencé a entender qué son los valores culturales y por qué son importantes en los equipos grandes. Por ejemplo, hubo un momento en que nadie tenía una pregunta sobre quién es responsable de la estabilidad del sitio. Todos entendieron que quien lanzó el servicio fue el responsable de él. Contratamos a una persona que se suponía que era responsable solo del servidor, y la confrontación "desarrolladores contra administradores" comenzó el mismo día. Fue asombroso, como un libro.
- Cuéntame más sobre cada una de las etapas. ¿Qué herramientas tomaste para ti, cuáles tuviste que abandonar? Según tengo entendido por el anuncio de su desempeño en DevOpsConf 2018, toda su infraestructura se implementa en las nubes en contenedores acoplables. ¿Por qué tomaste tal decisión? ¿Desde cuándo no podrías vivir sin contenedores?- Al principio no había nada, ni siquiera un rastreador. Solo despliegue a Heroku: git push, y todos están felices. Pero Heroku rápidamente dejó de satisfacernos, ya que había mucho ping antes, y no toleraban la carga. Nos mudamos a servidores de hierro regulares y consultores contratados. Con el tiempo, el servidor está muy lleno de basura. En este momento, hemos aumentado considerablemente el tráfico, la cantidad de producción, los servicios internos y externos. Configuramos servidores a través de Chef. Un buen día, caímos bajo carga y al anochecer nos mudamos a la nube usando Ansible. La sensación de cambiar a Ansible era simplemente cósmica. Resultó ser simple y comprensible, especialmente en el caso de infraestructuras tan pequeñas.
Comenzando con aproximadamente 60 aplicaciones, nuestra infraestructura se ha convertido en algo separado, como los llamamos, "sitios". Estas son nubes aisladas con sus propias subredes, con su propia terraforma y configuraciones ansibles.
Con el creciente número de aplicaciones y servidores, nuestra configuración comenzó a flotar, ya que hay muchas cosas que considerar antes de comenzar una aplicación simple en RoR. Además, parte de la configuración de despliegue estaba en el repositorio con la aplicación, parte en recetas de conjunto, los desarrolladores comenzaron a usar magia secreta, crear enlaces a carpetas, algún tipo de sincronización. Como resultado, se volvió completamente imposible de mantener.
Cuando tuvimos alrededor de un centenar de aplicaciones en diferentes nubes, comenzamos a mirar más de cerca a Docker. Eso fue el verano pasado. En aproximadamente 10 meses, transferimos todas nuestras aplicaciones, y para entonces había alrededor de 150 de ellas, en clústeres de acopladores. Esto se ha convertido en una verdadera salvación para nosotros. Nos ahorramos el monitoreo de versiones y fragmentos de entornos en servidores. Todo se volvió mucho más conveniente y simple: la aplicación podía colocarse fácilmente en un clúster de acopladores, eliminarse fácilmente de allí, tenía su propia metainformación, de la que queda claro en qué servicios consiste la aplicación, qué coronas, trabajos en segundo plano, etc.
- ¿Qué tan firme se mantiene en el enfoque original de DevOps? ¿Te conviene todo o cambiaste algo por ti mismo? ¿Fue difícil reconstruir el equipo?- Yo mismo no tengo una respuesta exacta a la pregunta sobre qué es DevOps. En el trabajo, siempre procedo del simple sentido común. Y la gente dice que resulta que aquí DevOps ha crecido. De hecho, casi no necesito la parte teórica de DevOps, porque el negocio me pide resultados. En otras palabras, si les digo bellamente y no hago nada, será muy malo, y si lo hago, pero no cuento sobre belleza, será bueno de todos modos.
Mi comprensión de DevOps es la siguiente. Por ejemplo, hay una gran empresa que quiere hacer o ya está haciendo productos digitales. Los productos digitales son siempre comentarios rápidos del mercado. La entrega continua se produce automáticamente, los límites entre el desarrollo y el soporte se desdibujan, la cultura DevOps se está reforzando, lo que interpreta las reglas de buena forma entre las personas responsables de la implementación, las pruebas y el soporte. Como resultado, tales relaciones les permiten ponerse de acuerdo entre ellos para alcanzar un objetivo común, así como cambiar el enfoque de sus responsabilidades personales a un resultado común. En una empresa grande y bien establecida, se producen cambios en los procesos, su ruptura.
Como no teníamos una empresa bien establecida, crecimos principios de funcionamiento muy rápidamente. Además, el negocio constantemente nos lanzó nuevas tareas, por lo que construimos nuestra infraestructura principalmente sobre la base del sentido común y los requisitos internos.
La palabra DevOps significaba poco para mí. Pero ahora, cuando pasamos por todo esto, cuando vi la aparición de puntos de conflicto, la confusión de las responsabilidades, me di cuenta de que DevOps es como un aspecto cultural de la interacción entre las personas para un objetivo común. Y los objetivos comunes en los productos digitales son crear nuevas funciones y desplegarlas lo más rápido posible.
- Sería interesante saber qué tan difícil es para los principiantes unir tu trabajo con tantas herramientas modernas. ¿Cómo se organiza tu trabajo con las personas?- Tenemos programas de adaptación. Le contamos al nuevo empleado cómo nos desarrollamos y cómo está todo organizado ahora, le asignamos un mentor. El primer día, lo ayudamos a configurar el entorno y emitir un combate, pero no es una tarea muy difícil. El mentor lo acompaña durante varios meses, ayuda con la adaptación.
- Cuéntanos sobre los planes de la empresa. ¿Dónde planeas crecer y qué áreas desarrollar? ¿La pila de tecnología actual proporciona las bases para un mayor crecimiento, o tendrá que cambiarla nuevamente?- Los planes de negocios son ambiciosos. Hoy, más de dos millones de escolares asisten regularmente a Uchi.ru, que es aproximadamente el 30% de todos los estudiantes de primaria en todo el país. Continuaremos atrayendo nuevos usuarios a la plataforma en Rusia y participaremos en el desarrollo internacional.
Técnicamente, tenemos 15 clústeres de acopladores aislados, y se pasa mucho tiempo cambiando de uno a otro, se ha vuelto difícil de mantener y actualizar. Los requisitos de velocidad de cambio y confiabilidad solo están creciendo. Por lo tanto, hay una reserva, pero también actualizaremos.
Amigos, si están interesados en la experiencia de Alexey, nos apresuramos a invitar a nuestra
DevOps Conf Russia 2018 , que se llevará a cabo del 1 al 2 de octubre. En su informe, hablará sobre la experiencia de usar nubes, la aplicación de la metodología DevOps, los valores y principios de su equipo.
Suscríbase al boletín temático Ontiko DevOps para recibir actualizaciones del programa tan pronto como estén disponibles. Intentamos que las cartas sean útiles y no intrusivas, enviamos noticias de la conferencia, transcripciones de informes y videos nuevos.
Por cierto, el video se puede monitorear por separado en el canal de YouTube : hay todos los videos recopilados en los últimos años y la lista se actualiza constantemente.