Ao criar feedback rápido e contínuo de Ops para Dev, reduzimos risco e ampliamos os loops de feedback para que possamos ver os problemas à medida que eles ocorrem e irradiamos essas informações para todos no fluxo de valor. Isso nos permite encontrar e corrigir rapidamente problemas no início do ciclo de vida de desenvolvimento de software, idealmente muito antes que eles causem uma falha catastrófica.
Um fato comum nas Ops é a materialização de erros e falhas (incidentes), onde pequenas mudanças podem resultar em muitos resultados inesperados, incluindo interrupções e falhas globais que afetam todos os nossos clientes. Essa é a realidade de operar sistemas complexos; nenhuma pessoa pode ver o sistema inteiro e entender como todas as peças se encaixam.
Podemos até citar a regra geral da famosa história de que quando algo dá errado na produção, apenas reiniciamos o servidor. Se isso não funcionar, reinicie o servidor próximo a ele. Se isso não funcionar, reinicie todos os servidores. Se isso não funcionar, culpe os desenvolvedores, eles estão sempre causando interrupções. Porém quando interrupções de produção e outros problemas ocorrem em nosso trabalho diário, geralmente não temos as informações necessárias para solucionar o problema. Por exemplo, durante uma interrupção, podemos não conseguir determinar se o problema é devido a uma falha na aplicação (defeito no código), no ambiente (um problema de rede, um problema de configuração do servidor) ou algo assim totalmente externo (um ataque maciço de negação de serviço).
Mas o que é telemetria em DevOps?
Telemetria em DevOps
Telemetria em devops: “um processo de comunicação automatizado pelo qual medições e outros dados são coletados em pontos remotos e subsequentemente transmitidos aos equipamentos receptores.” O objetivo é criar telemetria nas aplicações e ambientes, tanto em nossos ambientes de produção e pré-produção quanto em nosso pipeline de implantação.
As organizações de alto desempenho são muito melhores no diagnóstico e correção de incidentes de serviço: “cultura da causalidade” (The Visible Ops Handbook).
As de alto desempenho usaram uma abordagem disciplinada para resolver problemas, usando a telemetria de produção, para entender possíveis fatores contribuintes, para focar na resolução de problemas em oposição aos de baixo desempenho que reinicializariam cegamente os servidores.
É necessário garantir que sempre tenhamos telemetria suficiente para confirmar que nossos serviços estão operando corretamente na produção. Para que quando ocorrerem problemas, permita determinar rapidamente o que está errado e tomar decisões informadas sobre a melhor maneira de corrigi-lo idealmente muito antes de os clientes serem impactados. Além disso, a telemetria é o que nos permite reunir nossa melhor compreensão da realidade e detectar quando nossa compreensão da realidade está incorreta.
Como utilizar a telemetria em DevOps na sua organização?
Criar infraestrutura de telemetria centralizada:
Com monitorações decentralizadas, quando ocorrem eventos inoportunos, ninguém pode determinar por que todo o sistema não está funcionando como projetado, qual componente específico está falhando impedindo nossa capacidade de trazer nosso sistema de volta ao estado de funcionamento.
Para que possamos ver todos os problemas à medida que eles ocorrem, precisamos projetar e desenvolver nossos aplicações e ambientes para que eles gerem telemetria suficiente, permitindo-nos entender como nosso sistema está se comportando como um todo. Quando todos os níveis de nossa pilha de aplicações têm monitoramento e registro, ativamos outros recursos importantes como gráficos, visualização de nossas métricas, detecção de anomalias, alerta e escalação proativos.
Essa arquitetura possui os seguintes componentes:
Coleta de dados na camada de lógica de negócios, aplicações e ambientes
Em cada uma dessas camadas, estamos criando telemetria na forma de eventos, logs e métricas. Os logs podem ser armazenados em arquivos específicos da aplicação em cada servidor (por exemplo, /var/log/httpd-error.log), mas de preferência queremos que todos os nossos logs sejam enviados para um serviço comum que permita fácil centralização, rotação e exclusão.
Um roteador de eventos responsável por armazenar nossos eventos e métricas
Esse recurso potencialmente permite visualização, tendências, alertas, detecção de anomalias etc. Ao coletar, armazenar e agregar toda a nossa telemetria, possibilitamos melhor análises e verificações de integridade. Também é aqui que armazenamos configurações relacionadas aos nossos serviços (e seus aplicações e ambientes de suporte) e é provável que façamos alertas e verificações de integridade com base em limites.
Criar telemetria de registro da aplicação
Telemetria em DevOps
Precisamos garantir que as aplicações que construímos e operamos estejam criando telemetria suficiente. Fazemos isso fazendo com que os engenheiros de Dev e Ops criem telemetria de produção como parte de seu trabalho diário, para serviços novos e existentes.
Nas aplicações que criamos e operamos, todos os recursos devem ser instrumentados – se era importante o suficiente para um engenheiro implementar, certamente é importante gerar a telemetria de produção suficiente para que possamos confirmar se está operando como projetado e se o desejado está alcançados resultados.
Cada membro do fluxo de valor usará a telemetria de várias maneiras:
Dev podem criar temporariamente mais telemetria nas aplicações para diagnosticar melhor os problemas em sua estação de trabalho; Ops podem usar a telemetria para diagnosticar um problema de produção; Infosec e os auditores podem revisar a telemetria para confirmar a eficácia de um controle necessário, e um gerente de produto pode usá-los para rastrear resultados de negócios, uso de recursos ou taxas de conversão.
Níveis de log:
Nível DEBUG
Qualquer coisa que acontece no programa, mais frequentemente usada durante a depuração. Frequentemente, os logs de depuração são desativados na produção, mas temporariamente ativados durante a solução de problemas.
Nível INFO
Consistem em ações orientadas ao usuário ou específicas do sistema (“início da transação com cartão de crédito”).
Nível WARN
Informam sobre condições que podem potencialmente se tornar um erro (uma chamada ao banco de dados demorando mais que um tempo predefinido). Isso provavelmente iniciará um alerta e a solução de problemas, enquanto outras mensagens de log podem nos ajudar a entender melhor o que levou a essa condição.
Nível de erro
Se concentram nas condições de erro (falhas de chamada da API, condições internas de erro).
Nível FATAL
Informam quando devemos terminar (um daemon de rede não pode vincular um socket de rede).
Usando a telemetria em DevOps para resolver problemas
Quando existe uma cultura de culpa em relação a interrupções e problemas, os grupos podem evitar documentar mudanças e exibir telemetria onde todos possam vê-las para evitar serem responsabilizados por interrupções. A telemetria nos permite usar o método científico para formular hipóteses sobre o que está causando um problema específico e o que é necessário para resolvê-lo.
Mas para que isso ocorra, necessitamos de irradiadores de informação da telemetria.
O objetivo dele é irradiar essas informações para o restante da organização, garantindo que qualquer pessoa que deseje informações sobre qualquer um dos serviços que estamos executando, possa obtê-las sem precisar de acesso ao sistema de produção ou contas privilegiadas ou ter que abrir um ticket e aguarde dias para que alguém configure o gráfico para eles.
A telemetria em devops de produção deve ser altamente visível, o que significa colocá-la em áreas centrais onde o Dev e as Ops funcionam, permitindo que todos os interessados vejam o desempenho de nossos serviços.
Ao colocar radiadores de informações em locais de grande visibilidade, promovemos a responsabilidade entre os membros da equipe, demonstrando ativamente os seguintes valores:
- A equipe não tem nada a esconder dos visitantes (clientes, partes interessadas etc.)
- A equipe não tem nada a esconder de si mesma: reconhece e enfrenta problemas
Podemos até ampliar ainda mais essa transparência – em vez de tentar manter em segredo os problemas que afetam os clientes, podemos transmitir essas informações para nossos clientes externos. Isso demonstra que valorizamos a transparência, ajudando assim a criar e conquistar a confiança dos clientes
Métricas da telemetria em DevOps
Telemetria em DevOps
Precisamos de métricas dos seguintes níveis:
- Nível de negócios: exemplos incluem o número de transações de vendas, receita de transações de vendas, inscrições de usuários, taxa de rotatividade, resultados de testes A / B.
- Nível da aplicação: exemplos incluem tempos de transação, tempos de resposta do usuário, falhas de aplicações.
- Nível de infraestrutura (por exemplo, banco de dados, sistema operacional, rede, armazenamento): exemplos incluem tráfego de servidores da Web, carga de CPU, uso de disco.
- Nível de software do cliente (por exemplo, JavaScript no navegador do cliente, aplicação móvel): exemplos incluem erros e falhas do aplicação, tempos de transação medidos pelo usuário.
- Nível do pipeline de implantação: os exemplos incluem o status do pipeline de construção (por exemplo, vermelho ou verde para nossos vários conjuntos de testes automatizados), alterar os prazos de implantação, as frequências de implantação, as promoções do ambiente de teste e o status do ambiente.
