Pensamos en crear un sistema de seguimento na fase de formación de equipos de produto. Quedou claro que o noso negocio -a explotación- non cae nestes equipos. Por que é iso?
O feito é que todos os nosos equipos están construídos en torno a sistemas de información individuais, microservizos e frontes, polo que os equipos non ven a saúde xeral de todo o sistema no seu conxunto. Por exemplo, poden non saber como afecta algunha pequena parte do backend profundo á parte frontal. O seu ámbito de interese limítase aos sistemas cos que se integra o seu sistema. Se un equipo e o seu servizo A case non teñen conexión co servizo B, entón ese servizo é case invisible para o equipo.
O noso equipo, pola súa banda, traballa con sistemas que están moi fortemente integrados entre si: hai moitas conexións entre eles, esta é unha infraestrutura moi grande. E o funcionamento da tenda en liña depende de todos estes sistemas (dos que temos, por certo, un gran número).
Así resulta que o noso departamento non pertence a ningún equipo, senón que está situado un pouco ao lado. En toda esta historia, a nosa tarefa é comprender de forma exhaustiva como funcionan os sistemas de información, a súa funcionalidade, integracións, software, rede, hardware e como todo isto está conectado entre si.
A plataforma na que operan as nosas tendas en liña é a seguinte:
- fronte
- media oficina
- back office
Por moito que nos gustaría, non ocorre que todos os sistemas funcionen sen problemas. O punto, de novo, é o número de sistemas e integracións: con algo como o noso, algúns incidentes son inevitables, a pesar da calidade das probas. Ademais, tanto dentro dun sistema separado como en canto á súa integración. E cómpre supervisar o estado de toda a plataforma de forma exhaustiva, e non de calquera parte individual dela.
Idealmente, o seguimento da saúde en toda a plataforma debería estar automatizado. E chegamos ao seguimento como parte inevitable deste proceso. Inicialmente, construíuse só para a parte de primeira liña, mentres que os especialistas en redes, os administradores de software e hardware tiñan e aínda teñen os seus propios sistemas de monitorización capa por capa. Todas estas persoas seguiu o seguimento só ao seu propio nivel, ninguén tiña un entendemento completo.
Por exemplo, se falla unha máquina virtual, na maioría dos casos só o saben o administrador responsable do hardware e a máquina virtual. Nestes casos, o equipo de primeira liña viu o feito mesmo da falla da aplicación, pero non tiña datos sobre a falla da máquina virtual. E o administrador pode saber quen é o cliente e ter unha idea aproximada do que se está a executar actualmente nesta máquina virtual, sempre que sexa algún tipo de proxecto grande. O máis probable é que non saiba dos máis pequenos. En calquera caso, o administrador debe dirixirse ao propietario e preguntarlle que había nesta máquina, que hai que restaurar e que hai que cambiar. E se algo realmente grave fallaba, comezaban a correr en círculos, porque ninguén vía o sistema como un todo.
En definitiva, historias tan dispares afectan a todo o frontend, aos usuarios e á nosa función principal de negocio: as vendas en liña. Dado que non formamos parte dun equipo, senón que nos dedicamos ao funcionamento de todas as aplicacións de comercio electrónico como parte dunha tenda en liña, asumimos a tarefa de crear un sistema de seguimento integral para a plataforma de comercio electrónico.
Estrutura e pila do sistema
Comezamos identificando varias capas de monitorización para os nosos sistemas, dentro das cales necesitariamos recoller métricas. E todo isto había que combinalo, que é o que fixemos na primeira etapa. Agora, nesta fase, estamos ultimando a colección de métricas da máis alta calidade en todas as nosas capas para establecer unha correlación e comprender como se inflúen os sistemas entre si.
A falta de seguimento integral nas fases iniciais do lanzamento da aplicación (xa que comezamos a construíla cando a maioría dos sistemas estaban en produción) provocou que tiñamos unha débeda técnica importante para configurar o seguimento de toda a plataforma. Non podíamos permitirnos o luxo de centrarnos en configurar a supervisión dun IS e elaborar a supervisión para el en detalle, xa que o resto dos sistemas quedarían sen supervisión durante algún tempo. Para solucionar este problema, identificamos unha lista das métricas máis necesarias para avaliar o estado do sistema de información por capa e comezamos a implementala.
Por iso, decidiron comer o elefante por partes.
O noso sistema consta de:
- hardware;
- sistema operativo;
- software;
- partes da interface de usuario na aplicación de seguimento;
- métricas de negocio;
- aplicacións de integración;
- seguridade da información;
- redes;
- equilibrador de tráfico.
No centro deste sistema está o propio seguimento. Para comprender xeralmente o estado de todo o sistema, cómpre saber o que está a suceder coas aplicacións en todas estas capas e en todo o conxunto de aplicacións.
Entón, sobre a pila.
Usamos software de código aberto. No centro temos Zabbix, que utilizamos principalmente como sistema de alerta. Todo o mundo sabe que é ideal para a vixilancia de infraestruturas. Que significa isto? Exactamente esas métricas de baixo nivel que ten cada empresa que mantén o seu propio centro de datos (e Sportmaster ten os seus propios centros de datos): temperatura do servidor, estado da memoria, ataque, métricas do dispositivo de rede.
Integramos Zabbix con Telegram messenger e Microsoft Teams, que se usan activamente nos equipos. Zabbix cobre a capa da rede real, hardware e algún software, pero non é unha panacea. Enriquecemos estes datos doutros servizos. Por exemplo, a nivel de hardware, conectámonos directamente mediante API ao noso sistema de virtualización e recompilamos datos.
Que máis. Ademais de Zabbix, usamos Prometheus, que nos permite supervisar métricas nunha aplicación de entorno dinámico. É dicir, podemos recibir métricas da aplicación a través dun punto final HTTP e non preocuparnos por que métricas cargar nel e cales non. A partir destes datos pódense desenvolver consultas analíticas.
As fontes de datos doutras capas, por exemplo, as métricas empresariais, divídense en tres compoñentes.
En primeiro lugar, estes son sistemas comerciais externos, Google Analytics, recollemos métricas dos rexistros. Deles obtemos datos sobre usuarios activos, conversións e todo o relacionado co negocio. En segundo lugar, este é un sistema de seguimento da IU. Debería describirse con máis detalle.
Érase unha vez que comezamos coas probas manuais e convertéronse en probas automáticas de funcionalidades e integracións. A partir diso fixemos un seguimento, deixando só a funcionalidade principal, e confiamos en marcadores que son o máis estables posible e non cambian moitas veces co paso do tempo.
A nova estrutura do equipo significa que todas as actividades das aplicacións están limitadas aos equipos de produtos, polo que deixamos de facer probas puras. Pola contra, fixemos un seguimento da IU a partir das probas, escritas en Java, Selenium e Jenkins (utilizadas como sistema para lanzar e xerar informes).
Tivemos moitas probas, pero ao final decidimos ir á estrada principal, a métrica de primeiro nivel. E se temos moitas probas específicas, será difícil manter os datos actualizados. Cada versión posterior romperá significativamente todo o sistema, e o único que faremos é solucionalo. Polo tanto, centrámonos en cousas moi fundamentais que raramente cambian, e só as vixíamos.
Finalmente, en terceiro lugar, a fonte de datos é un sistema de rexistro centralizado. Usamos Elastic Stack para rexistros e, a continuación, podemos incorporar estes datos ao noso sistema de seguimento para as métricas empresariais. Ademais de todo isto, temos o noso propio servizo de API de monitorización, escrito en Python, que consulta calquera servizo a través da API e recolle datos deles en Zabbix.
Outro atributo indispensable do seguimento é a visualización. O noso está baseado en Grafana. Destaca entre outros sistemas de visualización porque permite visualizar métricas de diferentes fontes de datos no panel. Podemos recoller métricas de nivel superior para unha tenda en liña, por exemplo, o número de pedidos realizados na última hora desde o DBMS, métricas de rendemento para o sistema operativo no que se executa esta tenda en liña desde Zabbix e métricas para as instancias desta aplicación. de Prometeo. E todo isto estará nun mesmo panel. Claro e accesible.
Permítanme notar sobre a seguridade: actualmente estamos ultimando o sistema, que máis tarde integraremos co sistema de vixilancia global. Na miña opinión, os principais problemas aos que se enfronta o comercio electrónico no ámbito da seguridade da información están relacionados cos bots, os analizadores e a forza bruta. Debemos estar atentos a isto, porque todo isto pode afectar de xeito crítico tanto o funcionamento das nosas aplicacións como a nosa reputación dende o punto de vista empresarial. E coa pila escollida cubrimos con éxito estas tarefas.
Outro punto importante é que a capa de aplicación está montada por Prometheus. El mesmo tamén está integrado con Zabbix. E tamén contamos con sitespeed, un servizo que nos permite ver parámetros como a velocidade de carga da nosa páxina, os pescozos de botella, a renderización da páxina, a carga de scripts, etc., ademais está integrada na API. Polo tanto, as nosas métricas recóllense en Zabbix e, en consecuencia, tamén alertamos desde alí. Todas as alertas envíanse actualmente aos principais métodos de envío (polo momento é correo electrónico e telegrama, MS Teams tamén se conectou recentemente). Hai plans para actualizar as alertas a un estado tal que os robots intelixentes funcionan como un servizo e proporcionan información de seguimento a todos os equipos de produtos interesados.
Para nós, as métricas son importantes non só para os sistemas de información individuais, senón tamén para as métricas xerais para toda a infraestrutura que usan as aplicacións: clusters de servidores físicos nos que se executan as máquinas virtuais, equilibradores de tráfico, equilibradores de carga de rede, a propia rede, utilización das canles de comunicación. . Ademais de métricas para os nosos propios centros de datos (temos varios deles e a infraestrutura é bastante grande).
As vantaxes do noso sistema de vixilancia son que coa súa axuda podemos ver o estado de saúde de todos os sistemas e podemos avaliar o seu impacto entre si e nos recursos compartidos. E, en definitiva, permítenos participar na planificación de recursos, que tamén é a nosa responsabilidade. Xestionamos os recursos do servidor: un conxunto dentro do comercio electrónico, comisionamos e retiramos equipos novos, compramos equipos novos adicionais, realizamos unha auditoría de utilización de recursos, etc. Cada ano, os equipos planifican novos proxectos, desenvolven os seus sistemas e é importante que lles proporcionemos recursos.
E coa axuda das métricas, vemos a tendencia no consumo de recursos dos nosos sistemas de información. E en base a eles podemos planificar algo. A nivel de virtualización, recompilamos datos e vemos información sobre a cantidade de recursos dispoñibles por centro de datos. E xa dentro do centro de datos pódese ver a reciclaxe, a distribución real e o consumo dos recursos. Ademais, tanto con servidores autónomos como máquinas virtuais e clusters de servidores físicos nos que todas estas máquinas virtuais están xirando con forza.
Perspectivas
Agora temos o núcleo do sistema no seu conxunto preparado, pero aínda quedan moitas cousas por traballar. Como mínimo, esta é unha capa de seguridade da información, pero tamén é importante chegar á rede, desenvolver alertas e resolver o problema da correlación. Temos moitas capas e sistemas, e en cada capa hai moitas máis métricas. Resulta ser unha matrioshka ao grao de matrioska.
A nosa tarefa é, finalmente, facer as alertas correctas. Por exemplo, se houbo un problema co hardware, de novo, cunha máquina virtual, e había unha aplicación importante, e o servizo non se fixo unha copia de seguranza de ningún xeito. Descubrimos que a máquina virtual morreu. Entón, as métricas empresariais avisarán: os usuarios desapareceron nalgún lugar, non hai conversión, a IU da interface non está dispoñible, o software e os servizos tamén morreron.
Nesta situación, recibiremos spam das alertas, que xa non encaixa no formato dun sistema de vixilancia adecuado. Xorde a cuestión da correlación. Polo tanto, o ideal sería que o noso sistema de vixilancia diga: "Rapaces, a túa máquina física morreu, e xunto con ela esta aplicación e estas métricas", coa axuda dunha alerta, en lugar de bombardearnos furiosamente con cen alertas. Debe informar o principal - a causa, o que axuda a eliminar rapidamente o problema debido á súa localización.
O noso sistema de notificacións e procesamento de alertas está construído arredor dun servizo de liña directa de XNUMX horas. Todas as alertas que se consideran imprescindibles e que están incluídas na lista de verificación envíanse alí. Cada alerta debe ter unha descrición: o que pasou, o que realmente significa, o que afecta. E tamén unha ligazón ao panel e instrucións sobre que facer neste caso.
Isto é todo sobre os requisitos para crear unha alerta. Entón a situación pode desenvolverse en dúas direccións: ou hai un problema e hai que resolver, ou houbo un fallo no sistema de seguimento. Pero en calquera caso, cómpre ir descubrilo.
De media, agora recibimos preto de cen alertas ao día, tendo en conta que a correlación de alertas aínda non está configurada correctamente. E se necesitamos realizar traballos técnicos e apagamos algo pola forza, o seu número aumenta significativamente.
Ademais de supervisar os sistemas que operamos e recoller métricas que se consideran importantes pola nosa parte, o sistema de seguimento permítenos recoller datos para os equipos de produtos. Poden influír na composición das métricas dentro dos sistemas de información que monitorizamos.
Pode que veña o noso compañeiro e solicite engadir algunha métrica que sexa útil tanto para nós como para o equipo. Ou, por exemplo, é posible que o equipo non teña o suficiente das métricas básicas que temos; precisan seguir algunhas específicas. En Grafana, creamos un espazo para cada equipo e concedemos dereitos de administrador. Ademais, se un equipo necesita paneis, pero eles mesmos non poden ou non saben como facelo, axudámoslle.
Dado que estamos fóra do fluxo de creación de valor do equipo, dos seus lanzamentos e da súa planificación, gradualmente estamos chegando á conclusión de que as versións de todos os sistemas son perfectas e pódense lanzar a diario sen coordinación connosco. E é importante para nós supervisar estas versións, porque poden afectar o funcionamento da aplicación e romper algo, e isto é fundamental. Para xestionar as versións, utilizamos Bamboo, desde onde recibimos datos a través da API e podemos ver cales lanzamentos se lanzaron en que sistemas de información e o seu estado. E o máis importante é a que hora. Superpoñemos os marcadores de liberación ás principais métricas críticas, o que é visualmente moi indicativo en caso de problemas.
Deste xeito podemos ver a correlación entre os novos lanzamentos e os problemas emerxentes. A idea principal é comprender como funciona o sistema en todas as capas, localizar rapidamente o problema e solucionalo igual de rápido. Despois de todo, adoita ocorrer que o que leva máis tempo non é resolver o problema, senón buscar a causa.
E neste ámbito no futuro queremos apostar pola proactividade. O ideal é que me gustaría saber con antelación un problema que se achega, e non despois do feito, para poder evitalo en lugar de resolvelo. Ás veces prodúcense falsas alarmas do sistema de vixilancia, tanto por erro humano como por cambios na aplicación, e traballamos nisto, depurámolo e tratamos de avisar diso aos usuarios que o usan connosco antes de calquera manipulación do sistema de vixilancia. , ou realizar estas actividades na ventá técnica.
Entón, o sistema foi lanzado e funciona con éxito dende principios da primavera... e está a mostrar beneficios moi reais. Por suposto, esta non é a súa versión final; iremos introducindo moitas máis funcións útiles. Pero agora mesmo, con tantas integracións e aplicacións, a automatización do seguimento é realmente inevitable.
Se tamén supervisas grandes proxectos cun número importante de integracións, escribe nos comentarios que solución atopaches para isto.
Fonte: www.habr.com