Está morto o seguimento? - Viva o seguimento

Desde 2008, a nosa empresa dedicouse principalmente á xestión de infraestruturas e ao soporte técnico permanente para proxectos web: temos máis de 400 clientes, o que supón preto do 15% do comercio electrónico ruso. En consecuencia, é compatible cunha arquitectura moi diversa. Se algo cae, estamos obrigados a arranxalo nun prazo de 15 minutos. Pero para entender que se produciu un accidente, cómpre supervisar o proxecto e responder ás incidencias. Como facelo?

Creo que hai un problema para organizar un sistema de vixilancia adecuado. Se non houbera problemas, entón o meu discurso consistiría nunha tese: "Por favor, instale Prometheus + Grafana e os complementos 1, 2, 3". Desafortunadamente, xa non funciona así. E o principal problema é que todo o mundo segue crendo en algo que existía en 2008, en canto a compoñentes de software.

En canto á organización do sistema de seguimento, atreveríame a dicir que... non existen proxectos con seguimento competente. E a situación é tan mala que, se algo cae, corre o risco de que pase desapercibido; despois de todo, todos están seguros de que "todo está controlado".
Quizais todo se está vixiando. Pero como?

Todos atopamos unha historia como a seguinte: un certo devops, un determinado administrador está a traballar, un equipo de desenvolvemento achégase a eles e lles di: "estamos liberados, agora monitor". Vixiar que? Cómo funciona?

OK. Seguimos á antiga moda. E xa está a cambiar, e resulta que supervisaches o servizo A, que se converteu no servizo B, que interactúa co servizo C. Pero o equipo de desenvolvemento diche: "Instale o software, debería supervisar todo!"

Entón, que cambiou? - Todo cambiou!

2008 Todo está ben

Hai un par de desenvolvedores, un servidor, un servidor de bases de datos. Todo vai de aquí. Temos algo de información, instalamos zabbix, Nagios, cacti. E entón establecemos alertas claras na CPU, no funcionamento do disco e no espazo do disco. Tamén facemos un par de comprobacións manuais para asegurarnos de que o sitio responde e de que os pedidos chegan á base de datos. E iso é todo: estamos máis ou menos protexidos.

Se comparamos a cantidade de traballo que fixo entón o administrador para proporcionar a monitorización, entón o 98% foi automática: a persoa que realiza a vixilancia debe comprender como instalar Zabbix, como configuralo e configurar alertas. E 2% - para comprobacións externas: que o sitio responde e fai unha solicitude á base de datos, que chegaron novos pedidos.

2010 A carga está crecendo

Estamos comezando a escalar a web, engadindo un buscador. Queremos asegurarnos de que o catálogo de produtos conteña todos os produtos. E esa busca de produtos funciona. Que a base de datos está funcionando, que se están facendo pedidos, que o sitio responde externamente e responde desde dous servidores e que o usuario non é expulsado do sitio mentres se reequilibra a outro servidor, etc. Hai máis entidades.

Ademais, a entidade asociada ás infraestruturas segue sendo a maior na cabeza do xestor. Aínda teño unha idea na miña cabeza de que a persoa que fai o seguimento é a persoa que instalará zabbix e poderá configuralo.

Pero ao mesmo tempo, trabállase na realización de comprobacións externas, na creación dun conxunto de scripts de consulta do indexador de busca, un conxunto de scripts para comprobar que a busca cambia durante o proceso de indexación, un conxunto de scripts que verifican que os bens son transferidos ao servizo de entrega, etc. etcétera.

Nota: escribín "un conxunto de guións" 3 veces. É dicir, o responsable da vixilancia xa non é quen simplemente instala zabbix. Esta é unha persoa que comeza a codificar. Pero aínda non cambiou nada na mente do equipo.

Pero o mundo está cambiando, facéndose cada vez máis complexo. Engádese unha capa de virtualización e varios sistemas novos. Comezan a interactuar entre si. Quen dixo "cheira a microservizos?" Pero cada servizo aínda parece un sitio web individualmente. Podemos recorrer a el e entender que proporciona a información necesaria e funciona por si só. E se es un administrador constantemente implicado nun proxecto que leva 5-7-10 anos desenvolvéndose, estes coñecementos acumúlanse: aparece un novo nivel -decatácheste, aparece outro nivel-, decataches...

Pero poucas veces ninguén acompaña un proxecto durante 10 anos.

Curriculum vitae do monitoringman

Supoña que chegaches a unha nova startup que contratou inmediatamente 20 desenvolvedores, escribiu 15 microservizos e es un administrador ao que se lle di: "Construír CI/CD. Por favor." Construíches CI/CD e de súpeto escoitas: "É difícil para nós traballar coa produción nun "cubo", sen entender como funcionará a aplicación nel. Fainos unha caixa de area no mesmo "cubo".
Fais unha caixa de area neste cubo. Inmediatamente dinche: "Queremos unha base de datos de etapas que se actualice todos os días desde a produción, para que entendamos que funciona na base de datos, pero ao mesmo tempo non estragar a base de datos de produción".

Vives en todo isto. Quedan 2 semanas para o lanzamento, dinche: "Agora imos controlar todo isto..." Ou sexa. supervisar a infraestrutura do clúster, supervisar a arquitectura de microservizos, supervisar o traballo con servizos externos...

E os meus compañeiros quítanlles da cabeza o esquema habitual e din: “¡Aquí está todo claro! Instala un programa que supervisará todo isto". Si, si: Prometheus + Grafana + complementos.
E engaden: "Tes dúas semanas, asegúrate de que todo estea seguro".

En moitos proxectos que vemos, destínase unha persoa para o seguimento. Imaxina que queremos contratar unha persoa para facer un seguimento durante 2 semanas, e redactamos un currículo para el. Que habilidades debería ter esta persoa, tendo en conta todo o que dixemos ata agora?

• Debe comprender o seguimento e as especificidades do funcionamento da infraestrutura de ferro.
• Debe comprender os detalles específicos do seguimento de Kubernetes (e todos queren ir ao "cubo", porque pode abstraerse de todo, esconderse, porque o administrador se ocupará do resto) - en si, a súa infraestrutura e comprender como supervisar as aplicacións. dentro.
• Debe comprender que os servizos se comunican entre si de xeitos especiais e coñecer as particularidades de como interactúan os servizos entre si. É moi posible ver un proxecto onde algúns servizos se comunican de forma sincrónica, porque non hai outro xeito. Por exemplo, o backend vai a través de REST, a través de gRPC ao servizo de catálogo, recibe unha lista de produtos e devólvea. Non podes esperar aquí. E con outros servizos funciona de forma asíncrona. Transferir o pedido ao servizo de entrega, enviar unha carta, etc.
  Probablemente xa nadaches de todo isto? E o administrador, que ten que supervisar isto, quedou aínda máis confuso.
• Debe ser capaz de planificar e planificar correctamente - a medida que o traballo se fai cada vez máis.
• Polo tanto, debe crear unha estratexia a partir do servizo creado para comprender como supervisalo especificamente. Necesita unha comprensión da arquitectura do proxecto e do seu desenvolvemento + unha comprensión das tecnoloxías utilizadas no desenvolvemento.

Lembremos un caso absolutamente normal: algúns servizos están en PHP, algúns en Go, outros en JS. Dalgunha maneira traballan uns cos outros. De aí vén o termo "microservizo": hai tantos sistemas individuais que os desenvolvedores non poden entender o proxecto no seu conxunto. Unha parte do equipo escribe servizos en JS que funcionan por si só e non saben como funciona o resto do sistema. A outra parte escribe servizos en Python e non interfire co funcionamento doutros servizos; están illados na súa propia área. O terceiro é escribir servizos en PHP ou outra cousa.
Todas estas 20 persoas están divididas en 15 servizos, e só hai un administrador que debe entender todo isto. Pare! só dividimos o sistema en 15 microservizos porque 20 persoas non poden entender todo o sistema.

Pero hai que vixiar dalgún xeito...

Cal é o resultado? Como resultado, hai unha persoa á que se lle ocorre todo o que todo o equipo de desenvolvedores non pode entender e, ao mesmo tempo, tamén debe coñecer e ser capaz de facer o que indicamos anteriormente: infraestrutura de hardware, infraestrutura de Kubernetes, etc.

Que podo dicir... Houston, temos problemas.

O seguimento dun proxecto de software moderno é un proxecto de software en si mesmo

A partir da falsa crenza de que a monitorización é software, desenvolvemos unha crenza nos milagres. Pero os milagres, por desgraza, non acontecen. Non pode instalar zabbix e esperar que todo funcione. Non ten sentido instalar Grafana e esperar que todo estea ben. A maior parte do tempo dedicarase a organizar comprobacións do funcionamento dos servizos e da súa interacción entre si, comprobando como funcionan os sistemas externos. De feito, o 90% do tempo dedicarase non a escribir guións, senón a desenvolver software. E debe ser xestionado por un equipo que entenda o traballo do proxecto.
Se nesta situación unha persoa é lanzada á vixilancia, entón ocorrerá un desastre. Que é o que pasa en todas partes.

Por exemplo, hai varios servizos que se comunican entre si a través de Kafka. Chegou o pedido, enviamos unha mensaxe sobre o pedido a Kafka. Hai un servizo que escoita información sobre o pedido e envía a mercadoría. Existe un servizo que escoita información sobre o pedido e envía unha carta ao usuario. E entón aparecen unha morea de servizos máis, e comezamos a confundirnos.

E se tamén dás isto ao administrador e aos desenvolvedores na fase en que queda pouco tempo antes do lanzamento, a persoa terá que entender todo este protocolo. Eses. Un proxecto desta envergadura leva unha cantidade significativa de tempo, e isto debe terse en conta no desenvolvemento do sistema.
Pero con moita frecuencia, sobre todo nas startups, vemos como o seguimento se apraza para máis tarde. "Agora faremos unha Proba de Concepto, lanzarémolo con ela, deixalo caer, estamos preparados para sacrificar. E despois seguirémolo todo". Cando (ou se) o proxecto comeza a gañar cartos, a empresa quere engadir aínda máis funcións, porque comezou a funcionar, polo que é necesario que se lance aínda máis. E estás no punto no que primeiro necesitas supervisar todo o anterior, o que non leva o 1% do tempo, senón moito máis. E, por certo, necesitaranse desenvolvedores para a supervisión, e é máis fácil deixarlles traballar en novas funcións. Como resultado, escríbense novas funcións, todo se estropea e estás nun punto morto infinito.

Entón, como supervisar un proxecto dende o principio e que facer se obtén un proxecto que hai que supervisar, pero non sabe por onde comezar?

En primeiro lugar, cómpre planificar.

Digresión lírica: moitas veces comezan co seguimento da infraestrutura. Por exemplo, temos Kubernetes. Comecemos instalando Prometheus con Grafana, instalando complementos para supervisar o “cubo”. Non só os desenvolvedores, senón tamén os administradores teñen a desafortunada práctica de: "Imos instalar este complemento, pero probablemente o complemento saiba como facelo". Á xente gústalle comezar polo sinxelo e directo, en lugar das accións importantes. E o seguimento da infraestrutura é doado.

Primeiro, decide que e como queres supervisar e, a continuación, selecciona unha ferramenta, porque outras persoas non poden pensar por ti. E deberían? Outras persoas pensaron para si mesmos nun sistema universal, ou non pensaron nada cando se escribiu este complemento. E só porque este complemento teña 5 mil usuarios non significa que sexa de utilidade. Quizais te convertas no número 5001 simplemente porque xa había 5000 persoas alí antes.

Se comezas a supervisar a infraestrutura e o backend da túa aplicación deixa de responder, todos os usuarios perderán a conexión coa aplicación móbil. Aparecerá un erro. Virán a ti e dirán: "A aplicación non funciona, que estás facendo aquí?" - "Estamos vixiando". — "Como supervisas se non ves que a aplicación non funciona?!"

1. Creo que cómpre comezar a supervisar exactamente desde o punto de entrada do usuario. Se o usuario non ve que a aplicación funciona, iso é todo, é un fallo. E o sistema de vixilancia debería advertir sobre isto primeiro.
2. E só así poderemos controlar a infraestrutura. Ou facelo en paralelo. É máis doado coa infraestrutura: aquí por fin podemos instalar zabbix.
3. E agora cómpre ir ás raíces da aplicación para comprender onde non funcionan as cousas.

A miña idea principal é que o seguimento vaia en paralelo co proceso de desenvolvemento. Se distraes o equipo de monitorización para outras tarefas (creación de CI/CD, sandboxing, reorganización da infraestrutura), a monitorización comezará a estar atrasada e é posible que nunca te poñas ao día co desenvolvemento (ou tarde ou cedo terás que detelo).

Todo por niveis

Así vexo a organización dun sistema de vixilancia.

1) Nivel de aplicación:

• vixilancia da lóxica empresarial da aplicación;
• vixilancia das métricas de saúde dos servizos;
• seguimento da integración.

2) Nivel de infraestrutura:

• seguimento do nivel de orquestración;
• monitorización do software do sistema;
• monitorización do nivel de ferro.

3) De novo o nivel de aplicación, pero como produto de enxeñería:

• recollendo e supervisando rexistros de aplicacións;
• APM;
• rastrexo.

4) Aviso:

• organización dun sistema de alerta;
• organización dun sistema de deberes;
• organización dunha “base de coñecemento” e fluxo de traballo para o procesamento de incidentes.

É importante: chegamos á alerta non despois, senón de inmediato! Non hai necesidade de iniciar o seguimento e "dalgunha maneira máis tarde" descubrir quen recibirá alertas. Despois de todo, cal é a tarefa da vixilancia: comprender en que punto do sistema algo está a funcionar mal e informar a xente adecuada sobre iso. Se deixas isto ata o final, a xente adecuada saberá que algo está a fallar só chamando "nada funciona para nós".

Capa de aplicación - Monitorización da lóxica empresarial

Aquí estamos a falar de comprobar o feito mesmo de que a aplicación funciona para o usuario.

Este nivel debe realizarse durante a fase de desenvolvemento. Por exemplo, temos un Prometheus condicional: vai ao servidor que fai as comprobacións, tira do punto final e o punto final vai e verifica a API.

Cando se lles pide a miúdo que monitoree a páxina de inicio para asegurarse de que o sitio funciona, os programadores dan un control que se pode tirar cada vez que precisan asegurarse de que a API funciona. E os programadores neste momento aínda toman e escriben /api/test/helloworld
A única forma de asegurarse de que todo funciona? - Non!

• Crear tales comprobacións é esencialmente tarefa dos desenvolvedores. As probas unitarias deben ser escritas polos programadores que escriben o código. Porque se o filtras ao administrador, "Amigo, aquí tes unha lista de protocolos de API para as 25 funcións, monitoriza todo!" - nada vai funcionar.
• Se imprimes "hola mundo", ninguén saberá nunca que a API debería funcionar e funciona. Cada cambio de API debe levar a un cambio nas comprobacións.
• Se xa tes tal problema, detén as funcións e asigna desenvolvedores que escribirán estas comprobacións ou acepten as perdas, acepte que non se comproba nada e fallará.

Consellos técnicos:

• Asegúrate de organizar un servidor externo para organizar comprobacións; debes asegurarte de que o teu proxecto sexa accesible para o mundo exterior.
• Organice comprobacións en todo o protocolo da API, non só en puntos finais individuais.
• Crea un punto final de prometheus cos resultados da proba.

Capa de aplicación: seguimento de métricas de saúde

Agora estamos a falar de métricas sanitarias externas dos servizos.

Decidimos que monitorizamos todos os "controladores" da aplicación mediante verificacións externas, que chamamos desde un sistema de monitorización externo. Pero estes son os "asadores" que o usuario "ve". Queremos estar seguros de que os nosos servizos funcionan. Hai unha historia mellor aquí: K8s ten comprobacións de saúde, polo que polo menos o "cubo" en si pode estar convencido de que o servizo funciona. Pero a metade dos cheques que vin son a mesma letra "hola mundo". Eses. Así que tira unha vez despois do despregamento, respondeu que todo está ben, iso é todo. E o servizo, se ofrece a súa propia API, ten un gran número de puntos de entrada para esa mesma API, que tamén hai que supervisar, porque queremos saber que funciona. E xa o estamos vixiando por dentro.

Como implementar isto tecnicamente correctamente: cada servizo expón un punto final sobre o seu rendemento actual, e nos gráficos de Grafana (ou calquera outra aplicación) vemos o estado de todos os servizos.

• Cada cambio de API debe levar a un cambio nas comprobacións.
• Crea un novo servizo de inmediato con métricas de saúde.
• Un administrador pode acudir aos desenvolvedores e preguntarlle "engádeme un par de funcións para que comprenda todo e engada información sobre isto ao meu sistema de monitorización". Pero os desenvolvedores adoitan responder: "Non engadiremos nada dúas semanas antes do lanzamento".
  Que os xestores de desenvolvemento saiban que haberá tales perdas, que tamén o saiban os xestores de desenvolvemento. Porque cando todo caia, alguén seguirá chamando e esixindo controlar o "servizo en constante caída" (c)
• Por certo, asigna aos desenvolvedores para que escriban complementos para Grafana: esta será unha boa axuda para os administradores.

Capa de aplicación - Monitorización da integración

A supervisión da integración céntrase en supervisar as comunicacións entre sistemas críticos para a empresa.

Por exemplo, hai 15 servizos que se comunican entre si. Estes xa non son sitios separados. Eses. non podemos tirar o servizo por si só, obter /helloworld e entender que o servizo está funcionando. Dado que o servizo web de pedidos debe enviar información sobre o pedido ao autobús, desde o autobús, o servizo de almacén debe recibir esta mensaxe e seguir traballando con ela. E o servizo de distribución de correo electrónico debe procesar isto dalgún xeito máis, etc.

En consecuencia, non podemos entender, mirando cada servizo individual, que todo funcione. Porque temos un determinado autobús polo que todo se comunica e interactúa.
Polo tanto, esta etapa debería marcar a fase de proba de servizos para a interacción con outros servizos. É imposible organizar o seguimento da comunicación supervisando o corredor de mensaxes. Se hai un servizo que emite datos e un servizo que os recibe, ao supervisar o corredor só veremos datos que voan dun lado a outro. Aínda que dalgún xeito conseguimos supervisar internamente a interacción destes datos (que un determinado produtor publica os datos, alguén os le, este fluxo segue a ir a Kafka), isto aínda non nos dará información se un servizo enviou a mensaxe nunha versión. , pero o outro servizo non esperaba esta versión e omitiuna. Non o saberemos, xa que os servizos nos indicarán que todo funciona.

O que recomendo facer:

• Para a comunicación sincrónica: o punto final realiza solicitudes aos servizos relacionados. Eses. tomamos este punto final, tiramos un script dentro do servizo, que vai a todos os puntos e di "Podo tirar alí, e tirar alí, podo tirar alí..."
• Para a comunicación asíncrona: mensaxes entrantes: o punto final busca mensaxes de proba no bus e mostra o estado de procesamento.
• Para comunicación asíncrona: mensaxes de saída: o punto final envía mensaxes de proba ao bus.

Como adoita suceder: temos un servizo que arroxa datos ao autobús. Acudimos a este servizo e pedímosche que nos fales da súa saúde de integración. E se o servizo precisa producir unha mensaxe nalgún lugar máis lonxe (WebApp), entón producirá esta mensaxe de proba. E se executamos un servizo no lado de OrderProcessing, primeiro publica o que pode publicar independentemente, e se hai algunhas cousas dependentes, entón le un conxunto de mensaxes de proba do bus, entende que pode procesalas, informar e , se é necesario, publícaos máis, e sobre isto di: todo está ben, estou vivo.

Moitas veces escoitamos a pregunta "como podemos probar isto en datos de combate?" Por exemplo, estamos a falar do mesmo servizo de pedidos. O pedido envía mensaxes ao almacén onde se cancelan as mercadorías: non podemos probar isto en datos de combate, porque "a miña mercadoría será cancelada". Solución: planifique toda esta proba desde o principio. Tamén tes probas unitarias que fan burlas. Entón, faino nun nivel máis profundo onde teñas unha canle de comunicación que non prexudique o funcionamento do negocio.

Nivel de infraestrutura

A vixilancia de infraestruturas é algo que durante moito tempo se considerou a propia vixilancia.

• A vixilancia da infraestrutura pode e debe iniciarse como un proceso separado.
• Non deberías comezar co seguimento da infraestrutura nun proxecto en execución, aínda que realmente queiras. Esta é unha dor para todos os devops. "Primeiro controlarei o clúster, supervisarei a infraestrutura" - é dicir. En primeiro lugar, supervisará o que se atopa a continuación, pero non entrará na aplicación. Porque a aplicación é algo incomprensible para os devops. Filtróuselle, e non entende como funciona. Pero entende a infraestrutura e comeza por ela. Pero non - sempre cómpre supervisar a aplicación primeiro.
• Non te exageres co número de alertas. Tendo en conta a complexidade dos sistemas modernos, as alertas están a voar constantemente e, dalgún xeito, hai que vivir con este grupo de alertas. E a persoa de garda, despois de mirar cen das próximas alertas, decidirá "Non quero pensar niso". As alertas só deben notificar sobre cousas críticas.

Nivel de aplicación como unidade de negocio

Puntos clave:

• ELK. Este é o estándar da industria. Se por algún motivo non estás agregando rexistros, comeza a facelo inmediatamente.
• APM. APM externos como forma de pechar rapidamente o seguimento das aplicacións (NewRelic, BlackFire, Datadog). Podes instalar esta cousa temporalmente para, polo menos, entender dalgunha maneira o que está a pasar contigo.
• Rastreo. En decenas de microservizos, tes que rastrexar todo, porque a solicitude xa non vive por si só. É moi difícil engadir máis tarde, polo que é mellor programar inmediatamente o rastrexo no desenvolvemento: este é o traballo e a utilidade dos desenvolvedores. Se aínda non o implementou, aplícalo! Ver Jaeger/Zipkin

Alerta

• Organización dun sistema de notificacións: en condicións de vixilancia dunha morea de cousas, debería haber un sistema unificado para o envío de notificacións. Podes en Grafana. En Occidente, todos usan PagerDuty. As alertas deben estar claras (por exemplo, de onde veñen...). E é recomendable controlar que as notificacións se reciban
• Organización dun sistema de deberes: non se deben enviar alertas a todos (ou todos reaccionarán entre multitude, ou ninguén reaccionará). Os desenvolvedores tamén deben estar atentos: asegúrate de definir as áreas de responsabilidade, de dar instrucións claras e de escribir nela a quen chamar exactamente o luns e o mércores e a quen chamar o martes e o venres (se non, non chamarán a ninguén nin sequera no caso dun gran problema: terán medo de espertar ou molestar: a xente xeralmente non lle gusta chamar e espertar a outras persoas, especialmente pola noite). E explicar que pedir axuda non é un indicador de incompetencia (“Pido axuda, iso significa que son un mal traballador”), fomente as solicitudes de axuda.
• Organización dunha “base de coñecemento” e fluxo de traballo para o tratamento de incidencias: para cada incidente grave débese planificar unha autopsia e, como medida temporal, rexistrarse as actuacións que resolvan a incidencia. E fai unha práctica que as alertas repetidas son un pecado; deben ser arranxados en código ou traballo de infraestrutura.

Pila de tecnoloxía

Imaxinemos que a nosa pila é a seguinte:

• recollida de datos - Prometheus + Grafana;
• análise de rexistro - ELK;
• para APM ou Tracing - Jaeger (Zipkin).

A elección das opcións non é crítica. Porque se ao principio entendes como supervisar o sistema e escribiu un plan, entón comezas a elixir ferramentas que se adapten aos teus requisitos. A pregunta é o que escolleu supervisar en primeiro lugar. Porque quizais a ferramenta que escolleches ao principio non se adapte en absoluto aos teus requisitos.

Algúns puntos técnicos que vexo en todas partes ultimamente:

Prometheus está a ser empuxado dentro de Kubernetes: a quen se lle ocorreu isto? Se o teu clúster falla, que farás? Se tes un clúster complexo dentro, debería haber algún tipo de sistema de vixilancia dentro do clúster e outro fóra, que recompilará datos do clúster.

Dentro do clúster recollemos rexistros e todo o demais. Pero o sistema de vixilancia debe estar fóra. Moitas veces, nun clúster onde hai Promtheus instalado internamente, tamén hai sistemas que realizan comprobacións externas do funcionamento do sitio. E se as túas conexións co mundo exterior caeron e a aplicación non funciona? Resulta que todo está ben por dentro, pero non facilita as cousas aos usuarios.

Descubrimentos

• O seguimento do desenvolvemento non é a instalación de utilidades, senón o desenvolvemento dun produto de software. O 98% do seguimento actual é codificación. Codificación de servizos, codificación de comprobacións externas, comprobación de servizos externos e iso é todo.
• Non perdas o tempo dos teus desenvolvedores na supervisión: pode ocupar ata o 30% do seu traballo, pero paga a pena.
• Devops, non te preocupes que non podes supervisar algo, porque algunhas cousas son unha forma de pensar completamente diferente. Non eras un programador, e supervisar o traballo é exactamente o seu traballo.
• Se o proxecto xa está en execución e non está supervisado (e vostede é un xestor), destine recursos para o seguimento.
• Se o produto xa está en produción e es un devop ao que se lle dixo que "configure a supervisión", tenta explicar á dirección sobre o que escribín todo isto.

Esta é unha versión ampliada do informe na conferencia Saint Highload++.

Se estás interesado nas miñas ideas e pensamentos sobre el e temas relacionados, aquí podes ler a canle 🙂

Fonte: www.habr.com