O director de Operacións do portal Banki.ru, Andrey Nikolsky, falou na conferencia do ano pasado sobre os servizos orfos: como identificar un orfo na infraestrutura, por que os servizos orfos son malos, que facer con eles e que facer se nada axuda.
Debaixo do corte hai unha versión de texto do informe.
Ola compañeiros! Chámome Andrey, dirixo as operacións en Banki.ru.
Temos servizos grandes, son servizos tan monolíticos, hai servizos nun sentido máis clásico, e hai moi pequenos. Na miña terminoloxía obreira-campesiña, digo que se un servizo é sinxelo e pequeno, entón é micro, e se non é moi sinxelo e pequeno, entón é só un servizo.
Pros dos servizos
Axiña repasarei as vantaxes dos servizos.
O primeiro é a escala. Podes facer algo rapidamente no servizo e comezar a produción. Recibiches tráfico, clonaches o servizo. Tes máis tráfico, clonaches e vives con el. Este é un bo extra, e, en principio, cando comezamos, considerábase o máis importante para nós, por que estamos a facer todo isto.
En segundo lugar, o desenvolvemento illado, cando tes varios equipos de desenvolvemento, varios desenvolvedores diferentes en cada equipo e cada equipo desenvolve o seu propio servizo.
Cos equipos hai un matiz. Os desenvolvedores son diferentes. E hai, por exemplo, . Vin isto por primeira vez con Maxim Dorofeev. Ás veces, a xente de copos de neve está nalgúns equipos e noutros non. Isto fai que os diferentes servizos utilizados na empresa sexan un pouco desiguais.
Mira a imaxe: este é un bo programador, ten mans grandes, pode facer moito. O principal problema é de onde veñen estas mans.
Os servizos permiten utilizar diferentes linguaxes de programación que son máis axeitados para diferentes tarefas. Algúns servizos están en Go, outros en Erlang, outros en Ruby, algo en PHP, algo en Python. En xeral, pódese expandir moito. Aquí tamén hai matices.
A arquitectura orientada a servizos trata principalmente de devops. É dicir, se non tes automatización, non hai proceso de implantación, se o configuras manualmente, as túas configuracións poden cambiar de instancia de servizo a instancia e tes que ir alí para facer algo, entón estás no inferno.
Por exemplo, tes 20 servizos e tes que implementar a man, tes 20 consolas e premes simultaneamente "Enter" como un ninja. Non é moi bo.
Se tes un servizo despois das probas (se hai probas, claro), e aínda tes que rematalo cun ficheiro para que funcione en produción, tamén teño malas noticias para ti.
Se confías en servizos específicos de Amazon e traballas en Rusia, hai dous meses tamén tiñas "Todo está en chamas, estou ben, todo está xenial".
Usamos Ansible para automatizar o despregamento, Puppet para a converxencia, Bamboo para automatizar o despregamento e Confluence para describilo todo dalgún xeito.
Non vou determe nisto en detalle, porque o informe trata máis sobre prácticas de interacción, e non sobre implementación técnica.
Por exemplo, tivemos problemas nos que Puppet no servidor funciona con Ruby 2, pero algunha aplicación está escrita para Ruby 1.8 e non funcionan xuntos. Algo vai mal alí. E cando precisa executar varias versións de Ruby nunha máquina, normalmente comeza a ter problemas.
Por exemplo, dámoslle a cada desenvolvedor unha plataforma na que hai aproximadamente todo o que temos, todos os servizos que se poden desenvolver, para que teña un entorno illado, poida rompelo e construílo como queira.
Acontece que necesitas algún paquete especialmente compilado con soporte para algo alí. É bastante duro. Escoitei un informe onde a imaxe de Docker pesa 45 GB. En Linux, por suposto, é máis sinxelo, todo é máis pequeno alí, pero aínda así, non haberá espazo suficiente.
Ben, hai dependencias conflitivas, cando unha parte do proxecto depende dunha biblioteca dunha versión, outra parte do proxecto depende doutra versión e as bibliotecas non están instaladas xuntas.
Temos sitios e servizos en PHP 5.6, dámonos vergoña deles, pero que podemos facer? Este é o noso único sitio. Hai sitios e servizos en PHP 7, hai máis deles, non nos avergoñamos deles. E cada desenvolvedor ten a súa propia base onde ve felizmente.
Se escribes nunha empresa nun idioma, tres máquinas virtuais por desenvolvedor parecen normais. Se tes diferentes linguaxes de programación, a situación empeora.
Tes sitios e servizos sobre isto, neste, despois outro sitio para Go, un sitio para Ruby e algún outro Redis ao lado. Como resultado, todo isto convértese nun gran campo de apoio, e todo o tempo pode romper algo.
Polo tanto, substituímos os beneficios da linguaxe de programación polo uso de diferentes frameworks, xa que os frameworks PHP son moi diferentes, teñen diferentes capacidades, diferentes comunidades e diferentes soportes. E podes escribir un servizo para que xa teñas algo preparado para iso.
Cada servizo ten o seu propio equipo
A nosa principal vantaxe, que se cristalizou ao longo de varios anos, é que cada servizo ten o seu propio equipo. Isto é conveniente para un proxecto grande, pode aforrar tempo na documentación, os xestores coñecen ben o seu proxecto.
Podes enviar tarefas facilmente desde o soporte. Por exemplo, o servizo de seguros fallou. E inmediatamente o equipo que se ocupa dos seguros vai arranxalo.
As novas funcións estanse creando rapidamente, porque cando tes un servizo atómico, podes enroscar algo rapidamente nel.
E cando rompes o teu servizo, e isto ocorre inevitablemente, non afectaches os servizos doutros equipos e os desenvolvedores doutros equipos non veñen a correr cara a ti e din: "Ai, ai, non o fagas".
Como sempre, hai matices. Temos equipos estables, os directivos están cravados no equipo. Hai documentos claros, os xestores vixían todo de preto. Cada equipo cun xestor ten varios servizos, e hai un punto de competencia específico.
Se os equipos están flotando (tamén ás veces usamos isto), hai un bo método chamado "mapa de estrelas".
Tes unha lista de servizos e persoas. Un asterisco significa que a persoa é un experto neste servizo, un libro significa que a persoa está estudando este servizo. A tarefa da persoa é cambiar o folleto por un asterisco. E se non se escribe nada diante do servizo, comezan os problemas, dos que falarei máis adiante.
Como aparecen os servizos orfos?
O primeiro problema, a primeira forma de conseguir un servizo orfo na túa infraestrutura é despedir persoas. Alguén tivo algunha vez que unha empresa cumprise os prazos antes de avaliar as tarefas? Ás veces ocorre que os prazos son axustados e simplemente non hai tempo suficiente para a documentación. "Necesitamos entregar o servizo á produción, despois engadirémolo".
Se o equipo é pequeno, ocorre que hai un programador que escribe todo, o resto está nas bandas. "Escribín a arquitectura básica, imos engadir as interfaces". Logo, nalgún momento, o xerente, por exemplo, marcha. E durante este período, cando o xestor deixou e aínda non se nomeou un novo, os propios desenvolvedores deciden cara a onde vai o servizo e que está a suceder alí. E como sabemos (volvemos unhas diapositivas), nalgúns equipos hai xente de copos de neve, ás veces un liderado de equipo de copos de neve. Entón el deixa, e temos un servizo orfos.
Ao mesmo tempo, as tarefas de apoio e de negocio non desaparecen, acaban en atraso. Se houbo algún erro arquitectónico durante o desenvolvemento do servizo, tamén acaban atrasados. O servizo vaise deteriorando pouco a pouco.
Como identificar un orfo?
Esta lista describe ben a situación. Quen aprendeu algo sobre a súa infraestrutura?
Sobre as solucións documentadas: hai un servizo e, en xeral, funciona, ten un manual de dúas páxinas sobre como traballar con el, pero ninguén sabe como funciona dentro.
Ou, por exemplo, hai algún tipo de acurtador de ligazóns. Por exemplo, actualmente temos tres acurtadores de ligazóns en uso para diferentes fins en diferentes servizos. Estas son só as consecuencias.
Agora serei o capitán do obvio. Que se debe facer? En primeiro lugar, necesitamos transferir o servizo a outro xestor, outro equipo. Se o xefe do teu equipo aínda non abandonou, neste outro equipo, cando entendes que o servizo é como un orfo, debes incluír alguén que entenda polo menos algo ao respecto.
O principal: debes ter os procedementos de transferencia escritos en sangue. No noso caso, adoito controlar isto, porque necesito que todo funcione. Os xestores necesitan que se entregue rapidamente, e o que lle ocorre despois xa non é tan importante para eles.
A seguinte forma de facer un orfo é "Farémolo subcontratado, será máis rápido, e despois entregarémolo ao equipo". Está claro que todos teñen uns plans no equipo, un turno. Moitas veces un cliente comercial pensa que o subcontratista fará o mesmo que o departamento técnico que ten a empresa. Aínda que os seus motivadores son diferentes. Existen estrañas solucións tecnolóxicas e estrañas solucións algorítmicas na subcontratación.
Por exemplo, tiñamos un servizo que tiña Sphinx en varios lugares inesperados. Xa vos contarei o que tiven que facer.
Os subcontratistas teñen marcos autoescritos. Este é só PHP puro con copiar e pegar dun proxecto anterior, onde podes atopar todo tipo de cousas. Os scripts de implementación son un gran inconveniente cando necesitas usar algúns scripts Bash complexos para cambiar varias liñas nalgún ficheiro, e estes scripts son chamados por algún terceiro script. Como resultado, cambia o sistema de implantación, escolle outra cousa, salta, pero o teu servizo non funciona. Porque alí houbo que poñer 8 ligazóns máis entre diferentes cartafoles. Ou ocorre que mil discos funcionan, pero cen mil xa non funcionan.
Seguirei sendo capitán. A aceptación dun servizo subcontratado é un trámite obrigatorio. Alguén chegou algunha vez a un servizo subcontratado e non foi aceptado en ningún lado? Este non é tan popular, por suposto, como un servizo orfo, pero aínda así.
Hai que comprobar o servizo, revisar o servizo, cambiar os contrasinais. Tivemos un caso no que nos deron un servizo, hai un panel de administración "se login == 'admin' && password == 'admin'...", está escrito xusto no código. Sentámonos e pensamos, e a xente escribe isto en 2018?
Tamén é necesario probar a capacidade de almacenamento. Debes mirar o que sucederá en cen mil rexistros, mesmo antes de poñer este servizo en produción nalgún lugar.
Non debería haber vergoña en enviar un servizo para mellorar. Cando dis: "Non aceptaremos este servizo, temos 20 tarefas, fainos, entón aceptaremos", isto é normal. A túa conciencia non debe ser ferida polo feito de que estás creando un xestor ou que o negocio está a perder cartos. A empresa gastará entón máis.
Tivemos un caso cando decidimos externalizar un proxecto piloto.
Entregouse a tempo, e este foi o único criterio de calidade. Por iso fixemos outro proxecto piloto, que xa non era realmente un piloto. Estes servizos foron aceptados, e por medios administrativos dixeron, aquí está o seu código, aquí está o equipo, aquí está o seu xestor. En realidade, os servizos xa comezaron a obter beneficios. Ao mesmo tempo, de feito, seguen sendo orfos, ninguén entende como traballan e os directivos fan todo o posible por renegar das súas tarefas.
Hai outro gran concepto: o desenvolvemento da guerrilla. Cando algún departamento, xeralmente o departamento de mercadotecnia, quere probar unha hipótese e ordena que se subcontrate todo o servizo. Comeza a verter o tráfico, pechan os documentos, asinan documentos co contratista, entran en funcionamento e din: "Amigos, aquí temos un servizo, xa ten tráfico, tráenos cartos, aceptémolo". Estivemos como: "Oppa, como pode ser iso".
E outra forma de conseguir un servizo orfo: cando de súpeto algún equipo se ve cargado, a dirección di: "Imos transferir o servizo deste equipo a outro equipo, ten unha carga menor". E despois transferirémolo a un terceiro equipo e cambiaremos de director. E ao final volvemos ter orfo.
Cal é o problema dos orfos?
Quen non o sabe, este é o acoirazado Wasa levantado en Suecia, famoso polo feito de que se afundiu 5 minutos despois do lanzamento. E o rei de Suecia, por certo, non executou a ninguén por iso. Foi construído por dúas xeracións de enxeñeiros que non sabían como construír este tipo de barcos. Efecto natural.
O barco puido afundirse, por certo, dun xeito moito peor, por exemplo, cando o rei xa montaba nel nalgún lugar dunha tormenta. E así, afogouse enseguida, segundo Agile é bo fallar cedo.
Se fallamos cedo, normalmente non hai problemas. Por exemplo, durante a aceptación enviouse para revisión. Pero se fallamos xa na produción, cando se inviste o diñeiro, entón pode haber problemas. Consecuencias, como se chaman nos negocios.
Por que os servizos orfos son perigosos:
- O servizo pode romper de súpeto.
- O servizo leva moito tempo en repararse ou non se repara en absoluto.
- Problemas de seguridade.
- Problemas coas melloras e actualizacións.
- Se un servizo importante falla, a reputación da empresa reséntese.
Que facer cos servizos orfos?
Repetirei o que debo facer de novo. En primeiro lugar, debe haber documentación. 7 anos en Banki.ru ensináronme que os probadores non deben tomar a palabra dos desenvolvedores e que as operacións non deben tomar a palabra de todos. Temos que comprobar.
En segundo lugar, cómpre escribir diagramas de interacción, porque ocorre que servizos pouco recibidos conteñen dependencias das que ninguén dixo. Por exemplo, os desenvolvedores instalaron o servizo na súa chave nalgúns Yandex.Maps ou Dadata. Esgotaches o límite libre, está todo roto e non sabes o que pasou. Todos estes rastrillos deben ser descritos: o servizo usa Dadata, SMS, algo máis.
En terceiro lugar, traballar con débeda técnica. Cando fas algún tipo de muletas ou aceptas un servizo e dis que hai que facer algo, tes que asegurarte de que se fai. Porque entón pode resultar que o pequeno burato non é tan pequeno e caerás por el.
Con tarefas arquitectónicas, tivemos unha historia sobre Esfinxe. Un dos servizos utilizou Sphinx para introducir listas. Só unha lista paxinada, pero volveuse a indexar todas as noites. Montábase a partir de dous índices: un grande indexábase todas as noites, e tamén había un pequeno índice que se atornillaba a el. Todos os días, cunha probabilidade do 50% de bombardeo ou non, o índice caeu durante o cálculo e as nosas noticias deixaron de actualizarse na páxina principal. Ao principio tardaron 5 minutos en volver a indexar o índice, despois o índice creceu e, nalgún momento, comezou a tardar 40 minutos en reindexarse. Cando recortamos isto, respiramos aliviados, porque estaba claro que pasaría un pouco máis de tempo e o noso índice volveríase indexar a tempo completo. Este será un fracaso para o noso portal, non hai noticias durante oito horas; iso é todo, o negocio parou.
Planificar o traballo cun servizo orfo
De feito, isto é moi difícil de facer, porque os devops tratan de comunicarse. Queres estar en bos termos cos teus colegas e, cando lle pegas aos teus colegas e xestores pola cabeza con normativas, poden ter sentimentos conflitivos cara ás persoas que fan isto.
Ademais de todos estes puntos, hai outra cousa importante: as persoas concretas deben ser responsables de cada servizo concreto, de cada apartado concreto do procedemento de despregamento. Cando non hai xente e tes que atraer a outras persoas para que estuden todo este asunto, faise difícil.
Se todo isto non axudou e o teu servizo orfo segue sendo orfo, ninguén quere asumilo, a documentación non está escrita, o equipo que foi chamado a este servizo négase a facer nada, hai un xeito sinxelo de refacer todo.
É dicir, tomas de novo os requisitos para o servizo e escribes un servizo novo, mellor, nunha plataforma mellor, sen solucións tecnolóxicas estrañas. E migras a el na batalla.
Tivemos unha situación na que tomamos un servizo en Yii 1 e decatámonos de que non podíamos desenvolvelo máis, porque quedamos sen desenvolvedores que puidesen escribir ben en Yii 1. Todos os desenvolvedores escriben ben en Symfony XNUMX. Que facer? Asignamos tempo, asignamos un equipo, asignamos un xestor, reescribimos o proxecto e cambiamos o tráfico sen problemas.
Despois diso, pódese eliminar o servizo antigo. Este é o meu procedemento favorito, cando necesitas sacar e limpar algún servizo do sistema de xestión de configuración e despois pasar e ver que todos os coches en produción foron desactivados, para que os desenvolvedores non queden ningún rastro. O repositorio permanece en Git.
Isto é todo o que quería falar, estou listo para discutir, o tema é holivar, moitos nadaron nel.
As diapositivas dicían que unificaches as linguas. Un exemplo foi o cambio de tamaño das imaxes. É realmente necesario limitalo estritamente a unha lingua? Porque o cambio de tamaño da imaxe en PHP, ben, realmente podería facerse en Golang.
De feito, é opcional, como todas as prácticas. Quizais, nalgúns casos, incluso sexa indesexable. Pero cómpre entender que se tes un departamento técnico nunha empresa de 50 persoas, 45 deles son especialistas en PHP, outros 3 son devops que coñecen Python, Ansible, Puppet e algo así, e só un deles escribe nalgúns casos. tipo de linguaxe. Algún servizo de cambio de tamaño da imaxe de Go, despois, cando sae, a experiencia vai con el. E ao mesmo tempo, terás que buscar un programador específico do mercado que coñeza este idioma, especialmente se é raro. É dicir, dende o punto de vista organizativo, isto é problemático. Desde o punto de vista de devops, non só necesitarás clonar algúns xogos de playbooks preparados que utilizas para implementar servizos, senón que terás que escribilos de novo.
Actualmente estamos a construír un servizo en Node.js, e esta será só unha plataforma próxima para cada programador cun idioma separado. Pero sentámonos e pensamos que o xogo pagaba a pena a vela. É dicir, esta é unha pregunta na que debes sentarte e pensar.
Como supervisas os teus servizos? Como recolles e supervisas os rexistros?
Recollemos rexistros en Elasticsearch e poñémolos en Kibana e, segundo se trate de ambientes de produción ou de proba, utilízanse alí diferentes colectores. Nun lugar leñador, noutro lugar outra cousa, non me lembro. E aínda hai algúns lugares en certos servizos onde instalamos Telegraf e filmamos noutro lugar por separado.
Como vivir con Puppet e Ansible no mesmo ambiente?
De feito, agora temos dous ambientes, un é Puppet e outro Ansible. Estamos traballando para hibridalos. Ansible é un bo marco para a configuración inicial, Puppet é un mal marco para a configuración inicial porque require un traballo práctico directamente na plataforma e Puppet garante a converxencia da configuración. Isto significa que a plataforma se mantén nun estado actualizado e, para que a máquina ansibilizada se manteña actualizada, cómpre executar libros de xogos nela todo o tempo con certa frecuencia. Esa é a diferenza.
Como mantén a compatibilidade? Tes configuracións tanto en Ansible como en Puppet?
Esta é a nosa gran dor, mantemos a compatibilidade coas nosas mans e pensamos en como pasar de todo isto nalgún lugar agora. Resulta que Puppet lanza paquetes e mantén alí algunhas ligazóns e Ansible, por exemplo, lanza o código e axusta alí as últimas configuracións da aplicación.
A presentación trataba de diferentes versións de Ruby. Que solución?
Atopámonos con isto nun só lugar, e temos que telo na cabeza todo o tempo. Simplemente desactivamos a parte que se executaba no Ruby que era incompatible coas aplicacións e mantímola separada.
A conferencia deste ano terá lugar o 7 de decembro en Technopolis. Aceptamos solicitudes de informes ata o 11 de novembro. connosco se queres falar.
A inscrición para participantes está aberta, acompáñanos!
Fonte: www.habr.com