El director de operaciones del portal de Banki.ru, Andrei Nikolsky, dijo en la conferencia
DevOpsDays Moscow del año pasado sobre los servicios huérfanos: cómo identificar a un huérfano en la infraestructura, qué servicios malos son, qué hacer con ellos y cómo ser si nada ayuda.
Debajo del corte está la versión de texto del informe.
Hola colegas Mi nombre es Andrey, lidero la operación en Banki.ru.
Tenemos excelentes servicios, estos son servicios monolíticos, hay servicios en un sentido más clásico, hay servicios muy pequeños. En la terminología de mis trabajadores y campesinos, digo que si el servicio es simple y pequeño, entonces es micro, y si no es muy simple y no pequeño, entonces es solo un servicio.
Servicio Pros
Revisaré rápidamente las ventajas de los servicios.
El primero es escalar. Puede hacer algo rápidamente en el servicio y comenzar la producción. Has llegado tráfico, has clonado el servicio. Todavía tienes tráfico, todavía clonaste y vives con él. Este es un buen bono y, en principio, cuando comenzamos, se consideraba el más importante entre nosotros, ¿por qué hacemos todo esto?
En segundo lugar, el desarrollo aislado, cuando tiene varios equipos de desarrollo, varios desarrolladores diferentes en cada equipo, y cada equipo detecta algún tipo de servicio.
Hay un matiz con los equipos. Los desarrolladores son diferentes. Y hay, por ejemplo,
personas-copos de nieve . La primera vez que vi esto con Maxim Dorofeev. A veces la gente tiene copos de nieve en algunos equipos, y otros no. Esto hace que los diferentes servicios que se utilizan en la empresa sean un poco desiguales.
Mira la foto: es un buen desarrollador, tiene grandes manos, puede hacer mucho. El principal problema es de dónde crecen estas manos.
Los servicios permiten utilizar diferentes lenguajes de programación que son más adecuados para diferentes tareas. Algunos servicios en Go, algunos en Erlang, algunos en Ruby, algunos en PHP, algunos en Python. En general, puede dar una vuelta muy amplia. También hay matices aquí.
La arquitectura orientada a servicios se trata principalmente de devops. Es decir, si no tiene automatización, no hay un proceso de implementación, si configura con sus manos, sus configuraciones pueden cambiar de una instancia de servicio a una instancia, y tiene que ir allí para hacer algo, entonces está en el infierno.
Por ejemplo, tiene 20 servicios y necesita implementar con sus manos, tiene 20 consolas y simultáneamente presiona "enter", como un ninja. Esto no es muy bueno.
Si tiene un servicio después de la prueba (si hay pruebas, por supuesto), y también necesita terminarlo con un archivo para que funcione en producción, también tengo malas noticias para usted.
Si confía en los servicios específicos de Amazon y trabaja en Rusia, hace dos meses también tenía "Todo está en llamas, estoy bien, todo está bien".
Utilizamos Ansible para la automatización de la implementación, Puppet para la convergencia, Bamboo para la automatización de la implementación, Confluence para describirlo de alguna manera.
No me detendré en esto en detalle, porque el informe trata más sobre la práctica de las interacciones y no sobre la implementación técnica.
Por ejemplo, tuvimos problemas de que Puppet en el servidor funciona con Ruby 2, y algunas aplicaciones se escribieron bajo Ruby 1.8, y juntas no funcionan. Allí ocurre algún tipo de jamba. Y cuando necesita mantener varias versiones de Ruby en la misma máquina, generalmente tiene problemas.
Por ejemplo, le damos a cada desarrollador una plataforma en la que hay casi todo lo que tenemos, todos los servicios que se pueden desarrollar para que tenga un entorno aislado, pueda descomponerlo y construirlo como quiera.
Sucede que necesita algún tipo de paquete especialmente compilado con soporte para algo allí. Esto es lo suficientemente duro. He escuchado un informe donde la imagen de la ventana acoplable pesa 45 GB. En Linux, por supuesto, es más simple, todo es más pequeño allí, pero de todos modos, no habrá suficientes lugares.
Bueno, hay dependencias conflictivas cuando tienes una parte de un proyecto dependiendo de la biblioteca de una versión, otra parte del proyecto en una versión diferente y las bibliotecas no se agrupan en absoluto.
Tenemos sitios y servicios en PHP 5.6, nos avergonzamos de ellos, pero qué hacer. Este es nuestro único sitio. Hay sitios y servicios en PHP 7, hay más, no nos avergonzamos. Y cada desarrollador tiene su propia base, donde felizmente corta.
Si escribe en la empresa en un idioma, entonces tres máquinas virtuales por desarrollador, suena normal. Si tiene diferentes lenguajes de programación, la situación empeora.
Tiene sitios y servicios sobre esto, sobre esto, luego otra plataforma para Go, una plataforma para Ruby, otra Redis en el lateral. Como resultado, todo esto se convierte en un gran campo de apoyo, y todo el tiempo, algo de esto puede romperse.
Por lo tanto, reemplazamos los bollos del lenguaje de programación con el uso de diferentes marcos, ya que los marcos en PHP son bastante diferentes, tienen capacidades diferentes, comunidades diferentes y soporte diferente. Y puede escribir un servicio para que ya tenga algo listo.
Cada servicio tiene su propio equipo.
Nuestra principal ventaja, que cristalizó durante varios años, es que cada servicio tiene su propio equipo. Esto es conveniente para un proyecto grande, puede ahorrar tiempo en la documentación, los gerentes conocen bien su proyecto.
Las tareas de soporte se pueden lanzar perfectamente. Por ejemplo, el servicio de seguros se averió. E inmediatamente el equipo de seguros va a reparar.
Las nuevas funciones se crean rápidamente, porque cuando tiene un servicio atómico, puede atornillar algo rápidamente.
Y cuando interrumpió su servicio, y esto sucede inevitablemente, no lastimó los servicios de otra persona, y los desarrolladores con partes de otros equipos no recurren a usted y no dicen: "Aw, no hagas eso.
Como siempre, hay matices. Tenemos equipos estables, los gerentes están clavados en el equipo. Hay documentos claros, los gerentes vigilan de cerca todo esto. Cada equipo con un gerente tiene varios servicios, y hay un punto específico de competencia.
Si los equipos están flotando (esto también se usa a veces con nosotros), existe un buen método llamado mapa estelar.
Tienes una lista de servicios y personas. Un asterisco significa que una persona es experta en este servicio, un libro significa que una persona está estudiando este servicio. La tarea del hombre es cambiar un pequeño libro por un asterisco. Y si no hay nada escrito enfrente del servicio, entonces comienzan los problemas, de los cuales continuaré hablando.
¿Cómo aparecen los servicios huérfanos?
El primer problema, la primera forma, para obtener un servicio huérfano en su infraestructura es despedir personas. ¿Alguien ha sucedido cuando llegan los plazos de las empresas antes de evaluar las tareas? A veces sucede que los plazos son ajustados y simplemente no hay tiempo suficiente para la documentación. "Debemos entregar el servicio a la producción, luego lo agregaremos".
Si el equipo es pequeño, sucede que hay un desarrollador que escribe todo, el resto está en las alas. "Escribí la arquitectura básica, me das las interfaces". Luego, en algún momento, el gerente, por ejemplo, se va. Y durante este período, cuando el gerente se ha ido, y aún no se ha designado uno nuevo, los propios desarrolladores deciden hacia dónde se está moviendo el servicio, qué está pasando allí. Y como sabemos (volvamos unas diapositivas), en algunos equipos hay personas con copos de nieve, a veces un copo de nieve. Luego renuncia, y recibimos un servicio huérfano.
Al mismo tiempo, las tareas de soporte y de negocios no desaparecen, sino que se instalan en la cartera de pedidos. Si hubo errores arquitectónicos durante el desarrollo del servicio, también se resuelven en el trabajo atrasado. El servicio se degrada lentamente.
¿Cómo identificar a un huérfano?
Esta lista describe bien la situación. ¿Quién aprendió algo en la infraestructura?
Acerca de las soluciones documentadas: hay un servicio y, en general, funciona, tiene un manual de dos páginas, cómo trabajar con él, pero nadie sabe cómo funciona en su interior.
O, por ejemplo, hay algún tipo de acortador de enlaces. Por ejemplo, ahora usamos tres acortadores de enlaces para diferentes propósitos en diferentes servicios. Estas son las consecuencias.
Ahora seré el capitán de la evidencia. ¿Qué hay que hacer? Primero, debe transferir el servicio a otro gerente, a otro equipo. Si el líder de su equipo aún no ha renunciado, entonces en este otro equipo, cuando comprenda que el servicio es como un huérfano, debe incluir a alguien que entienda al menos algo sobre él.
Lo principal: debe tener procedimientos de transmisión escritos en sangre. En nuestro caso, generalmente sigo esto, porque necesito que esto funcione. Los gerentes necesitan que esto se entregue rápidamente, y lo que le sucederá más tarde no es tan importante para ellos.
La siguiente forma de hacer un huérfano es "Hagámoslo de forma externa, será más rápido y luego lo transferiremos al equipo". Está claro que todos tienen algunos planes en el equipo, la cola. A menudo, un cliente comercial piensa que un proveedor externo hará lo mismo que el departamento técnico de la empresa. Aunque sus motivadores son diferentes. El outsourcing tiene soluciones tecnológicas extrañas y soluciones algorítmicas extrañas.
Por ejemplo, teníamos un servicio en el que Sphinx estaba en varios lugares inesperados. Más tarde te contaré lo que tenía que hacer.
Los subcontratistas tienen marcos auto-escritos. Esto es solo PHP desnudo con copiar y pegar del proyecto anterior, donde puedes encontrar todo. Muletas grandes en los scripts de despliegue, cuando necesita cambiar varias líneas en algún archivo con algunos scripts de Bash complejos, mientras que estos scripts de despliegue son llamados por un tercer script. Como resultado, cambia el sistema de implementación, elige otra cosa, salta y su servicio no funciona. Porque había 8 enlaces más para poner entre diferentes carpetas. O sucede que mil registros funcionan, pero cien mil se han ido.
Continuaré al capitán. Aceptar un servicio de outsourcing es un procedimiento que se requiere. ¿Quién ha pasado que llega un servicio de un proveedor externo, pero no se acepta en ningún lado? Esto no es, por supuesto, tan popular como un servicio huérfano, pero aún así.
El servicio debe ser verificado, el servicio debe ser revisado, las contraseñas deben ser cambiadas. Tuvimos un caso cuando el servicio nos arrojó, allí el panel de administración "if login == 'admin' && password == 'admin' ..." está escrito directamente en el código. ¿Nos sentamos y pensamos, y la gente escribe esto en 2018?
Probar el volumen de almacenamiento también es imprescindible. Debe ver lo que sucederá en cien mil registros, incluso antes de comenzar este servicio en algún lugar de la producción.
Enviar el servicio para su revisión no debe avergonzarse. Cuando dice: "No aceptaremos este servicio, tenemos 20 tareas, hágalas, luego aceptaremos", esto es normal. La conciencia no debe doler por el hecho de que sustituye a un gerente o que una empresa gasta dinero. El negocio gastará más.
Tuvimos un caso cuando decidimos hacer un proyecto piloto sobre outsourcing.
Se entregó a tiempo, y este fue el único criterio de calidad. Por lo tanto, hicieron otro proyecto piloto, ni siquiera uno piloto. Estos servicios fueron aceptados, dijeron de manera administrativa, aquí está su código, aquí hay un equipo, aquí está su gerente. Los servicios realmente ya han comenzado a obtener ganancias. Además, de hecho, se quedaron huérfanos, nadie comprende cómo funcionan y los gerentes, de todas las formas posibles, rechazan sus tareas.
Existe otro concepto excelente: el desarrollo partidista. Cuando un departamento, por regla general, es un departamento de marketing, quieren probar una hipótesis y ordenar la subcontratación de todo el servicio. El tráfico comienza a derramarse sobre él, cierran documentos, firman actos con el contratista, entran en funcionamiento y dicen: "Dudes, tenemos un servicio aquí, ya tiene tráfico, nos trae dinero, vamos a tomarlo". Somos: "Oppa, cómo es eso".
Y una forma más de obtener un servicio huérfano: cuando un equipo se carga repentinamente, la gerencia dice: "Transmidamos el servicio de este equipo a otro equipo, tiene menos carga". Y luego nos transferiremos al tercer equipo, y cambiaremos al gerente. Y al final, nuevamente tenemos un huérfano.
¿Cuál es el problema con los huérfanos?
Quién no sabe, este fue el barco de la línea que Wasa crió en Suecia, famoso por el hecho de que se hundió 5 minutos después del lanzamiento. Y el rey de Suecia, por cierto, no ejecutó a nadie por esto. Fue construido por dos generaciones de ingenieros que no pudieron construir tales barcos. El efecto natural.
El barco podría hundirse, por cierto, mucho peor, por ejemplo, cuando el rey lo montara en algún lugar en una tormenta. Y entonces, se ahogó de inmediato, de acuerdo con la cárcel, es bueno fallar temprano.
Si fallamos temprano, generalmente no hay problemas. Por ejemplo, durante la aceptación enviaron para su revisión. Y si ya hemos fallado en la producción, cuando se invierte el dinero, puede haber problemas. Las consecuencias, como se les llama en los negocios.
Por qué servicios huérfanos peligrosos:
- El servicio puede romperse de repente.
- El servicio se repara durante mucho tiempo o no se repara en absoluto.
- Problemas de seguridad.
- Problemas con mejoras y actualizaciones.
- Si se rompe un servicio importante, la reputación de la empresa se ve afectada.
¿Qué hacer con los servicios para huérfanos?
Una vez más, qué hacer. En primer lugar, debe haber documentación. Durante 7 años en Banki.ru me enseñaron que los evaluadores no deberían hablar con los desarrolladores, y la operación no debería hablar con todos. Es necesario verificar.
En segundo lugar, es necesario escribir esquemas de interacción, porque sucede que los servicios que no son bien recibidos contienen dependencias de las que nadie habló. Por ejemplo, los desarrolladores ponen el servicio en su clave para algunos Yandex.Maps o Dadata. Te has quedado sin límite, todo se ha roto y no sabes lo que sucedió en absoluto. Todos estos rastrillos deben describirse: el servicio utiliza Dadata, Sms, algo más.
En tercer lugar, trabajar con la deuda técnica. Cuando haces muletas o aceptas el servicio y dices que hay que hacer algo, debes asegurarte de que lo hagan. Porque entonces puede resultar que el pequeño agujero no sea tan pequeño y que caigas allí.
Con las tareas arquitectónicas, tuvimos una historia sobre Sphinx. En uno de los servicios, Sphinx se utilizó para ingresar a las listas. Solo una lista de paginación, pero se reindexó todas las noches. Se compiló a partir de dos índices: uno se indexó todas las noches en grande, y todavía había un pequeño índice que se atornillaba. Todos los días, con una probabilidad del 50%, bombardeará o no, durante el cálculo, el índice estaba latiendo y las noticias dejaron de actualizarse en la página principal. Al principio fueron 5 minutos, mientras el índice se volvió a indexar, luego el índice creció y, en algún momento, comenzó a volver a indexarse 40 minutos. Cuando lo cortamos, soltamos un suspiro de alivio, porque estaba claro que pasaría un poco más de tiempo, y nuestro índice se volvería a indexar a tiempo completo. Será un archivo para nuestro portal, ocho horas no hay noticias, eso es todo, el negocio se ha mantenido.
Plan de trabajo con servicio huérfano.
De hecho, es muy difícil de hacer, porque devops se trata de comunicación. Quiero estar en buenas relaciones con mis colegas, y cuando golpeas a colegas y gerentes con regulaciones en la cabeza, pueden tener sentimientos contradictorios por las personas que hacen esto.
Además de todos estos puntos, hay otra cosa importante: para cada servicio específico, para cada sección específica del procedimiento de implementación, las personas específicas deben ser responsables. Cuando no hay personas y tienes que atraer a otras personas, para estudiar todo, se vuelve difícil.
Si todo esto no ayuda, y el servicio huérfano sigue siendo huérfano, nadie quiere llevárselo, la documentación no está escrita, el equipo que fue llamado a este servicio se niega a hacer algo, hay una manera fácil de rehacer todo .
Es decir, toma los requisitos del servicio de nuevo y escribe un nuevo servicio, mejor, en una mejor plataforma, sin soluciones tecnológicas extrañas. Y migrar a él en la batalla.
Tuvimos una situación cuando tomamos el servicio en Yii 1 y nos dimos cuenta de que no podíamos desarrollarlo más, porque nos habíamos quedado sin desarrolladores que pueden escribir bien en Yii 1. Todos los desarrolladores escriben bien en la tercera Symfony. Que hacer Nos tomamos el tiempo, asignamos el equipo, asignamos el gerente, reescribimos el proyecto y cambiamos el tráfico sin problemas.
Después de eso, el antiguo servicio se puede eliminar. Este es mi procedimiento favorito, cuando necesita tomar y limpiar algún servicio del sistema de administración de configuración y luego ir a ver que todos los autos en la producción han sido reembolsados, para que los desarrolladores no tengan rastros. El repositorio en el git permanece.
Esto es todo de lo que quería hablar, estoy listo para discutir, el tema es holístico, muchos flotaron en él.
En las diapositivas se trataba del hecho de que unificaste los idiomas. Un ejemplo fue el cambio de tamaño de las imágenes. Pero, ¿es realmente necesario tener un idioma difícil? Porque cambiar el tamaño de las imágenes en PHP, bueno, realmente podrías hacerlo en Golang.De hecho, esto no es necesario, como todas las prácticas. Quizás, en algunos casos, incluso indeseable. Pero debe comprender que si tiene 50 personas en el departamento técnico, 45 de ellos son desarrolladores de PHP, otros 3 son devops que pueden hacer Python, Ansible, Puppet y algo así, y solo uno de ellos escribe en algunos Vaya al servicio para cambiar el tamaño de las imágenes, luego cuando se vaya, el examen se irá con él. Y al mismo tiempo, deberá buscar un desarrollador específico del mercado que conozca este idioma, especialmente si es raro. Es decir, desde un punto de vista organizativo, esto es problemático. Desde el punto de vista de los desarrolladores, no solo necesitará clonar un conjunto de libros de jugadas ya listos para usar para implementar servicios, sino que deberá volver a escribirlos.
Ahora estamos viendo el servicio en Node.js, y será solo una plataforma cercana para cada desarrollador con un idioma separado. Pero nos sentamos pensando que el juego valía la pena. Es decir, la pregunta aquí es sentarse y pensar.
¿Cómo monitorea sus servicios? ¿Cómo recolecta y rastrea los registros?Elasticsearch Kibana, , , . - Lumberjack, - -, . , Telegraf - .
Puppet Ansible ?, , — Puppet, Ansible. , . Ansible — , Puppet — , , Puppet . , , , , - . .
? Ansible, Puppet?, , - . , Puppet - , Ansible , , .
Ruby. ?, . , Ruby, , .
Este año, la conferencia DevOpsDays Moscú se llevará a cabo el 7 de diciembre en Technopolis. Hasta el 11 de noviembre, aceptamos solicitudes de informes. Envíenos un correo electrónico si quiere hablar.
La inscripción para los participantes está abierta, ¡únete!