La directora técnica adjunta de Mail.Ru Group, Tatyana Bakharevskaya, habla sobre el camino del administrador del sistema, las ventajas de trabajar como administrador del sistema y las características de operación en una gran empresa. Tatyana fue responsable y responsable de los servicios de los dos portales más grandes de Rusia.
El anfitrión del programa es Pavel Shcherbinin.
-
Cuéntanos un poco sobre ti.- Ingresé a la profesión hace mucho tiempo. Consiguió un trabajo como administradora de sistemas junior en una pequeña startup que estaba desarrollando su motor de búsqueda y otros proyectos de Internet. Fue Yandex, donde trabajé durante muchos años. Ella creció para ser una administradora seria del sistema, luego dirigió el departamento de administración del sistema. En 2005, 5 personas trabajaban en este departamento, y después de 10 años, 250, era una estructura grande, se formaron varias unidades. Aprendimos a contratar, criar ingenieros, realizamos eventos como Root, CIT. En Yandex, fui responsable de la operación continua ininterrumpida de la compañía, y ahora, ya hace un año, he estado haciendo lo mismo para Mail.Ru Group. Al principio parecía que las tareas eran similares, pero después de un examen más detallado resultó que había mucho en común, pero había suficientes diferencias, y esto fue interesante.
-
Existen muchos términos diferentes para la operación del servicio. Esto es solo explotación, y el administrador del sistema, SRE, SE, DevOps. Cuéntanos más sobre cada uno. ¿O es lo mismo? ¿Cómo se diferencian?- De hecho, un administrador del sistema es un concepto bastante amplio, comenzando con el hecho de que una persona puede ser responsable de una pequeña oficina con una infraestructura de oficina pequeña para varios empleados, y termina con la responsabilidad de la operación continua de un servicio altamente cargado. En algún momento, todavía estaba dividido en diferentes direcciones. En empresas como Mail.Ru Group, Yandex, Google, el administrador del sistema está más cerca de lo que ahora se llama las palabras de moda SRE - Site Reliability Engineer, es decir, la persona responsable de la disponibilidad del sitio.
Nuestro trabajo requiere muchos conocimientos diferentes sobre tecnologías: Linux / Unix, redes, bases de datos, servidores web, tecnologías en la nube, la composición del equipo que utilizamos para construir servicios (procesadores, memoria, discos) y mucho más. Sobre la tecnología, necesita comprender cómo aplicarlas, cómo difieren. Siempre hay mucho trabajo de rutina que necesita ser automatizado. También es necesario escribir código. Los administradores de sistemas / SRE modernos son en su mayoría programadores. Por el momento, el lenguaje principal para la automatización es Python, además, por supuesto, bash. Saber C siempre ha sido una ventaja. Por ejemplo, la mejor documentación de Linux: abra el código del núcleo y vea cómo funciona todo.
También es importante comprender cómo construir sistemas altamente cargados y tolerantes a fallas. Sobre esto, se ha dicho mucho en conferencias y se ha escrito en Internet.
En resumen, para resumir, el ingeniero moderno responsable del servicio altamente cargado necesita poder programar, conocer y aplicar diversas tecnologías, tener una idea de cómo construir servicios confiables y escalables.
-
Volvamos un poco. La etapa inicial es muy interesante. ¿Por qué elegiste la operación?- Eso fue gracioso. En esos años, todas las chicas decentes querían convertirse en contadoras. Yo también quería, así que fui a los cursos. Dijeron que para convertirse en contador, debe dominar los puntajes y el aritmómetro Felix, decidí que era demasiado complicado y que "conocer la computadora" (como escribieron en los anuncios de trabajo) facilitaría mi vida y mi búsqueda de empleo. Como resultado, ella fue "a estudiar informática" en el Instituto de Física de Ingeniería de Moscú más cercano, en la Facultad de Cibernética, en el Departamento de Computadores Electrónicos. Resultó que en esta computadora, además de Word y Excel, todavía hay mucho de todo: el procesador, la memoria, las tuberías, los dispositivos de entrada y salida. Al final de mis estudios, quería ser programador. En los primeros cursos, la programación fue bastante difícil para mí, y al final de mis estudios, fue sencillo escribir código. Podría hacer esto durante días y días. Por la noche se sentó y escribió el código, y a la noche siguiente abrió los ojos. Todo salió bastante bien, los programas funcionaron. Pero me di cuenta de que era una persona entusiasta y decidí elegir algo más simple. Y entró en funcionamiento, pero resultó que aquí tampoco es fácil, pero incluso en lugares es mucho más complicado. Pero me quedé, y durante más de 20 años he estado haciendo esto.
-
Me pregunto en qué momento decides ser programador o administrador.- De diferentes maneras. Durante los últimos años, me he encontrado con estudiantes en Yandex y Mail.Ru. La gente en la universidad viene a probarse tanto en programación como en administración. Alguien permanece en funcionamiento y entiende que esto es suyo. Alguien, después de haber trabajado un poco, entra en desarrollo. Alguien que ha trabajado en el desarrollo comprende que quiere comprender algunos problemas más profundamente, descubrir la pila de lo que está debajo, bajo su programa, cómo se opera, cómo vive y cómo está inmerso en la operación. Hay algunos casos límite que ahora se llaman DevOps de la palabra de moda. Estas personas deberían saber mucho sobre hardware, explotación y código.
Todo depende de la persona, de lo que le gusta y no le gusta. Y estas profesiones son muy similares, se superponen en muchos aspectos.
-
Las leyendas sobre Yandex dicen que en un momento tuviste un interruptor especial que podía apagar un centro de datos en cualquier momento para probar la estabilidad del sistema. Cuéntame más- Esta historia comenzó hace muchos, muchos años con un incidente importante: casi todos los centros de datos desconectados en Yandex. Más precisamente, uno desconectado, pero contenía todos los equipos de red de la empresa. Yandex no trabajó durante varias horas. Después de eso, la tarea se estableció para hacer todo confiable, tolerante a fallas, para que todo funcione en caso de desconexión de uno de los centros de datos. Hoy, este problema no es tan relevante, especialmente para los centros de datos comerciales. La confiabilidad se ha vuelto mucho más alta, hay ejemplos de cómo los centros de datos modernos viven durante varios días en combustible diesel. Pero entonces fue diferente.
Durante varios años, analizamos la arquitectura de todas las aplicaciones, escribimos planes de tareas, cómo y qué se debe hacer para garantizar la tolerancia completa a fallas. Donde era imposible o demasiado difícil, discutimos el SLA (acuerdo de nivel de servicio). La atención principal se centró en servicios populares y altamente cargados. La primera interrupción de la prueba fue muy aterradora. La mitad de los empleados monitorearon los datos de monitoreo. Se desconectaron y se encendieron bastante rápido, anotaron todos los errores y finalizaron varios sistemas. Y así, algunas iteraciones.
Después de un tiempo, llegaron al punto de poder vivir tranquilamente durante una o dos horas, desconectando un centro de datos. Todos entendieron que la habilidad necesitaba ser mantenida, ejercicios regulares para desconectarse. Es como en fontanería: si no abre el grifo durante mucho tiempo y no lo cierra, se vuelve ácido y no lo abrirá en el momento adecuado. Por lo tanto, regularmente abrimos y cerramos los "grifos". Y funcionó. Considero un logro que una vez por la noche me llamaron y me dijeron que el centro de datos se había caído, y les pregunté por qué me habían despertado :-)
-
¿Qué piensas, dónde está la línea entre programadores y administradores de sistemas? En qué momento puede un programador decir que no es responsable de esto, no sabe qué base de datos hay, esto es para los administradores. ¿O no es esta cara?- Me parece que el administrador es responsable de la aplicación "desde la punta de la nariz hasta la punta de la cola". En el buen sentido, puede acceder al código, ver cómo funciona allí, cómo solucionarlo. Él participa en la elección de la tecnología, ya que existen buenas tecnologías para los programadores, es muy conveniente escribir con ellos, pero es imposible vivir con ellos las 24 horas del día, los 7 días de la semana.
Los programadores pueden centrarse más en las características del producto que necesitan: funcionalidad adicional, diseño, código adicional que permite que el proyecto se escale mejor. Es decir, todavía hay una separación. En la práctica internacional, estos son Ingeniero de Software y Confiabilidad del Sitio. Existen diferentes teorías sobre dónde y cómo debería tener lugar la separación de roles. Me parece que el paradigma adoptado por Mail.Ru Group, dentro del cual hay operación y desarrollo, y estas son personas diferentes, funciona bastante bien.
-
Probablemente no todos sepan cómo se organiza ahora en Mail.Ru Group. Cuéntame más- Tenemos un servicio de operación que es responsable de la operación de los servicios. Se compone de varios departamentos. Cada departamento es responsable de un producto específico o grupo de productos, dependiendo de la escala. Por ejemplo, varios departamentos participan en Mail: un repositorio, el otro web. Y hay departamentos que trabajan en varios proyectos, en menor escala.
En nuestro hogar: Correo, Búsqueda, Portal, Club de entrega, "Yula", "Mi mundo", ICQ y muchos otros. Hay proyectos que se han lanzado durante mucho tiempo y son nuestros productos principales, por ejemplo, Mail and Portal. Hay proyectos que hemos comprado que colocamos en nuestra infraestructura, compartimos prácticas operativas con ellos. Y hay quienes nacieron con nosotros y crecieron muy rápidamente, por ejemplo, "Yula". La economía es bastante diversa :-)
-
¿Cómo se ve la arquitectura de un servicio típico de Mail.Ru Group?- Tenemos varios centros de datos. Tenemos nuestros propios centros de datos, tanto propios como comerciales, en equipos y redes comerciales. La capacidad total de los canales en nuestro país se mide en terabits.
Hospedamos servidores de proyectos en varios centros de datos para que deshabilitar uno no afecte la operación del servicio. La mayoría de nuestros proyectos son sitios web. La arquitectura es estándar: un equilibrador de carga, debajo de él un servidor web, luego un servidor de aplicaciones y luego un DBMS y / o almacenamiento.
A continuación, comienzan los detalles.
Básicamente, todos vivimos en servidores de hierro, pero también tenemos nubes. Por ejemplo, para el desarrollo y las pruebas, se utiliza una nube en OpenStack, donde el desarrollo y las pruebas pueden recibir recursos con solo hacer clic en un botón.
Estamos implementando Kubernetes, pero este proceso requiere mucho cambio en los procesos de operación y desarrollo. No va rápido. Intentamos hacer todo con cuidado para no romper nada.
Volvamos a lo que está sucediendo con los usuarios. Primero, el usuario ingresa al equilibrador. Para equilibrar la carga, se utilizan los protocolos de red BGP y RIP, y el software tradicional: ipvs, haproxy y nginx. Después de eso, los servidores web muestran a los usuarios hermosas páginas, principalmente usando nginx y Apache.
Pero detrás de ellos están los servidores de aplicaciones. Como, como dije anteriormente, hay proyectos heredados y bastante nuevos, hay muchos lenguajes de programación en los que todo esto está escrito.
Como DBMS para nuevos proyectos, se utilizan principalmente MySQL, PostgreSQL y nuestro desarrollo interno Tarantool. Los usuarios no deben sentir la pérdida de servidores de ningún almacenamiento o de su parte, tratamos de hacer una copia de seguridad y replicar los datos en los centros de datos vecinos.
Utilizamos principalmente código abierto, ya que tenemos muchos programadores e ingenieros en nuestra empresa que pueden arreglar algo en cualquier momento. También hay algunos desarrollos. Por ejemplo, el repositorio en el que se encuentran las cartas de los usuarios es su propio desarrollo.
-
¿Cuántas personas tienes en sujeción?- Ahora unos 70, pero este número crece regularmente. Nos estamos expandiendo activamente, ahora hay muchas posiciones abiertas.
-
¿Cuántos servidores sirven?- Varias decenas de miles de servidores que se encuentran en nuestros centros de datos. Principalmente en Moscú, pero también tenemos servidores en otras ciudades, en Estados Unidos y Europa. Toda esta flota de servidores necesita ser monitoreada y cuidada, mantenida. Nosotros, por supuesto, no vamos a centros de datos, excepto quizás en excursiones.
-
¿Cuál debería ser el volumen del canal?"Unos pocos terabits". Todo el grupo Mail.Ru tiene una red común, a través de la cual se transmite mucha información. Tome al menos "VK" y "OK", que muestran un montón de videos, pero todavía hay correo, búsqueda, análisis y muchos otros servicios altamente cargados. Por lo tanto, la red es un componente importante.
-
¿Qué necesitas saber para convertirte en un buen administrador del sistema?- Por supuesto, Linux. Muchas compañías comerciales ahora usan este sistema operativo. Básicamente, dentro de las empresas intentan no utilizar diferentes distribuciones, todos quieren que sea uno, es más fácil actualizar y mantener los sistemas. Cada uno tiene sus propias preferencias para la distribución, nosotros usamos CentOS. Entonces, antes que nada, necesita saber Linux, cómo y qué se organiza allí, cómo se organiza la comunicación entre procesos, cómo se carga y funciona todo.
Luego viene la especialización: a quién está más cerca y a lo que se encuentra el alma :-). Alguien se especializa en automatización, alguien en servidores web, alguien en redes, alguien en bases de datos y alguien en tecnología de nube. Por ejemplo, en un momento realmente me gustaron las bases de datos. Debe comprender cómo funcionan las aplicaciones: para poder configurarlas, comprender los pros y los contras de usar una u otra aplicación en una tarea y, por supuesto, poder repararla muy rápidamente en caso de problemas.
Ejemplos de tales especializaciones: los ingenieros de redes entienden los protocolos y saben dónde y cuáles son mejores para usar, pueden configurar el enrutamiento global y local, saben cómo garantizar la confiabilidad y la tolerancia a fallas de la red.
Los especialistas en bases de datos saben cómo fragmentar, replicar y hacer copias de seguridad de una base de datos para guardar información de manera confiable y garantizar una alta velocidad. Estas personas saben cómo mirar los planes de consulta, saben por qué se necesitan índices y cuáles son.
Una tarea típica: para analizar por qué la solicitud se ejecuta durante mucho tiempo, debe mirar el plan y ver si hay problemas con la carga del servidor (memoria, procesador, E / S).
-
En opinión pública, los administradores se presentan como hombres con una gran barba en un suéter estirado. ¿Te resulta difícil trabajar en un equipo masculino?- Una pregunta difícil, porque llevo trabajando muchos años. En primer lugar, estoy acostumbrado. En segundo lugar, si hablamos de la industria en su conjunto, ya había bastantes chicas en funcionamiento.
Tal mito proviene de la antigüedad, cuando se requería mucho trabajo físico. Mi amigo y yo aún recordamos cómo los dos sacamos un servidor grande, pesado y de múltiples unidades y lo pusimos en el piso, porque ya no podíamos llevarlo a un lugar especial para el mantenimiento. Y se sentaron en el suelo en medio del centro de datos con destornilladores, cambiaron las ruedas. Aún no había diapositiva :-)
Ahora no hay tal cosa. Trabajamos en una cómoda oficina en la mesa. Nuestro trabajo hoy no es diferente del trabajo de un programador, que nunca ha sido puramente masculino: las programadoras son una ocurrencia bastante común.
-
Nuestra encuesta de bombardeos. Cual es tu laptop?- manzana.
-
¿Qué es mejor, Bash o Perl?- Bash
- ¿
Startup o gran empresa?- Startup en una gran empresa.
"
¿Cuál fue la última cosa para la que no tenía suficiente dinero?"- Al yate.
-
Gran respuesta. Todos entenderán de inmediato el nivel salarial en Mail.Ru Group.- Exactamente
-
ICQ o TamTam?- ICQ.
-
"VK" o "Compañeros de clase"?- VK.
-
¿Quién es tu ídolo?- No tengo un ídolo. Creo que muchas personas en Internet rusa y extranjera han hecho mucho por esta industria. Gracias a ellos, se está desarrollando a ese ritmo. Tuve suerte, con muchos de ellos los conozco personalmente.
-
Nombra a los grandes rusos.- Mucho; de nuevo, me temo que no enumeraré a todos. Si alguien necesita ser seleccionado personalmente, me alegro de que en la vida logré trabajar con Ilya Segalovich.