Consciência operacional
Para começarmos a trabalhar no monitoramento da confiabilidade, há uma etapa preliminar que precisamos seguir. Primeiro, precisamos garantir um nível razoável de consciência operacional.
A maneira mais simples de dizer isso é que, para trabalhar em prol da confiabilidade dos sistemas em produção, primeiro precisamos entender bem esses sistemas e como eles operam na produção.
Coletar informações sobre a configuração atual
Embora pareça peculiar, em muitos ambientes, a primeira pergunta que precisa ser respondida é “O que exatamente está sendo executado na produção?”. Os ambientes de produção hoje em dia e os caminhos para implantação são tão complexos que geralmente é necessário fazer uma pesquisa primeiro. Dado um aplicativo específico, quais as partes que o compõem? Quais partes se comunicam com outras partes? Quais são as dependências óbvias (e não tão óbvias) desse aplicativo?
Coletar informações sobre o desempenho normal e anterior
Com essas informações em mãos, podemos tentar traçar uma linha de base referente ao desempenho e ao comportamento "normal" do sistema. Há muitos motivos pelos quais podemos precisar dessas informações, o não menos importante é para nos ajudar a fazer a triagem de um problema no aplicativo. Durante uma interrupção não é o momento adequado para descobrir se ter os servidores do banco de dados operando em 80% da carga da CPU é algo bom ou ruim.
Como parte da obtenção dessa linha de base, vamos nos aprofundar na observação do desempenho anterior. Embora seja verdade que o desempenho anterior não garante resultados futuros, às vezes nos ajuda a calibrar as expectativas. Da mesma forma, se tivermos acesso a informações sobre interrupções anteriores ou eventuais transtornos em um serviço, isso nos dará pelo menos uma noção de possíveis modos de falha que precisaremos incorporar em nosso raciocínio sobre confiabilidade.
Coletar informações de contexto
E, por fim, é útil obter informações de contexto sobre o sistema em questão. O contexto também pode se enquadrar em uma grande variedade de buckets, muitos deles sociotécnicos. Por exemplo, do lado social, desejaremos reunir informações valiosas sobre os stakeholders associados a um serviço ou a um aplicativo.
Você pode pensar É fácil saber quem é proprietário ou se preocupa com determinado aplicativo/serviço, mas em situações empresariais ou em outras organizações complexas, isso pode ser bem mais difícil do que parece.
A triste realidade é que, por motivos que ficarão claros mais tarde quando discutimos SLIs e SLOs, não vamos conseguir fazer grandes progressos na confiabilidade de um sistema sem uma ideia clara de quem são os stakeholders.
No lado técnico da pergunta de contexto, é realmente útil prestar atenção em perguntas técnicas como Como esse aplicativo entrou em produção? Ele foi implantado manualmente durante uma implantação “épica” ou foi implantado por meio de um pipeline automatizado de CI/CD com um ótimo conjunto de testes de unidade?
Essas informações podem ter muitas ramificações, inclusive como será fácil de iterar sempre que tivermos atualizações de melhora da confiabilidade a serem feitas. Também pode ser um indicador útil do trabalho que poderíamos estar fazendo para realmente fazer uma diferença.
Ferramentas do Azure para consciência operacional
Desenvolver consciência operacional geralmente não é fácil, mas vamos examinar algumas ferramentas fornecidas pelo Azure que podem ajudar nesse processo. Essa será uma exploração muito superficial. Ao final deste módulo, incluiremos algumas indicações de módulos e documentação do Microsoft Learn caso queira explorar algum tópico com mais detalhes.
Application Insights
As primeiras ferramentas que veremos podem nos ajudar a responder à pergunta “O que está realmente em execução?”. Como pessoal de operações, é comum receber pedidos para trabalhar com um aplicativo já em execução na produção. Embora o ideal seja fazer parte do ciclo de vida completo do software, começar com a fase de design nem sempre (ou, talvez, com frequência) será o caso. Quando isso acontece, principalmente com aplicativos mais complexos com base em várias camadas ou em microsserviço, o simples ato de entender quais são as partes móveis pode exigir grandes esforços.
Uma ferramenta que pode reduzir esses esforços e fornecer informações sobre o comportamento do aplicativo em produção é o Application Insights. Com o mínimo de esforços, os desenvolvedores podem instrumentar seus aplicativos para enviar automaticamente informações de telemetria aos coletores em execução no Azure. Com essas informações, o Application Insights pode criar um mapa visual dos componentes do aplicativo e da comunicação entre esses componentes.
Aqui está um exemplo:
Na imagem anterior, você pode ver não apenas os componentes do aplicativo, mas também a comunicação entre esses componentes. Se ampliarmos o zoom em uma das conexões entre os componentes, veremos o número de chamadas realizadas entre esses componentes e a latência média dessas chamadas. Também será possível ver uma representação do número de chamadas bem sucedidas e do número de chamadas com falha. Se selecionar qualquer um dos elementos do mapa, o Application Insights permite analisar informações detalhadas sobre as estatísticas de desempenho e métricas de sucesso/falha dessas chamadas. Essa pode ser uma excelente maneira de obter uma boa noção da visão mais ampla dos componentes do aplicativo e de como eles funcionam enquanto linha de base. Lembre-se: não deixe de explorar o mapa do aplicativo e tudo o que o Application Insights tem a oferecer antes que ocorra uma interrupção.
Gráfico de Recursos do Azure
O Application Insights é uma excelente maneira de desenvolver consciência operacional sobre um aplicativo, mas e se você quiser ter uma visão ainda mais ampla, que inclui todos os recursos em jogo no Azure em uma assinatura? No passado, baixaríamos relatórios ou gravaríamos no PowerShell para reunir essas informações, mas agora há uma forma muito mais fácil.
O Azure Resource Graph Explorer fornece um ambiente de consulta interativo diretamente no portal do Azure para acessar os dados que você precisa. Ele permite executar consultas arbitrárias que retornam respostas em tempo real com base nos recursos atualmente em uso. Por exemplo, se quiser ver todas as VMs em execução no momento, execute a seguinte consulta:
e obter como resultado uma lista detalhada completa das VMs que estão em uso na sua assinatura:
A linguagem de consulta usada nesse ambiente é a KQL (Kusto Query Language). Discutiremos isso com mais detalhes posteriormente neste módulo quando falarmos sobre o Log Analytics do Azure Monitor.
Painéis
A ferramenta de operações mais tradicional para consciência operacional é o painel. Muitas vezes, quando pensamos em pessoas realizando operações, imaginamos elas diante de grandes monitores, olhando intensamente para painéis cheios de grafos, gráficos e contadores. Neste módulo, não vamos explorar como construir, editar e usar painéis. Isso é feito em grande parte anexando conteúdos de outros locais do portal e, em seguida, movendo-os como achar adequado.
Em vez disso, vamos examinar dois recursos de painéis usados com menos frequência que podem trazer benefícios reais para você. Você pode encontrar esses recursos na parte superior de cada painel.
As duas setas realçadas permitem fazer o upload e exportar representações JSON de painéis.
Primeiro, vamos começar com a funcionalidade de exportação. Se você clicar em Exportar, selecione Baixar. Um arquivo JSON que representa o painel atual será baixado no computador. Se quiser, tente isso agora mesmo fazendo logon no portal, clicando em Painel no menu do produto e, em seguida, clicando em Exportar>Download.
Há pelo menos duas coisas que pode fazer com esse arquivo que você pode achar útil:
Você pode inserir esse arquivo no sistema de controle do código-fonte. Isso permite acompanhar as diferentes versões de painéis e também permite que outras pessoas acessem, caso queiram usar o seu painel. Alguns chamam isso de "painéis como código".
Você pode usar esse arquivo como a base de um novo painel. Aqui está um exemplo concreto ao qual voltaremos mais adiante neste roteiro de aprendizagem: digamos que precisemos mostrar a um colega como ficou um painel específico durante uma hora de interrupção na semana anterior. Você poderia publicar o painel e pedir aos colegas que selecionem a hora e o período exatos. Porém, mais fácil e menos sujeito a erros seria baixar o painel configurado exatamente conforme você precisa e compartilhar esse arquivo JSON. Se quiser realçar um segundo período do mesmo painel, digamos uma hora no futuro, é fácil editar o JSON.
Essa é a funcionalidade de exportação. Agora, vamos nos concentrar nos usos da funcionalidade de upload. Além de ser capaz de carregar os arquivos controlados por versão ou editados na última seção, também podemos usar a funcionalidade de upload para aproveitar o trabalho cuidadoso de outras pessoas ao construir painéis.
Vejamos o exemplo final desta seção, que combina perfeitamente duas ideias tratadas nesta unidade. Se você baixar este arquivo JSON:
no computador e carregá-lo em um painel, você verá algo assim:
Agora, você tem um painel ao vivo que mostra um inventário bastante abrangente dos recursos em uso em uma assinatura. Os dados do painel são provenientes da mesma fonte do Azure Resource Graph Explorer que vimos anteriormente. Na verdade, se você selecionar um dos blocos, poderá ver (e editar, se quiser) a consulta exata que está sendo executada para produzir as informações exibidas naquele quadrado. Excelente, não é mesmo?
Com essa ajuda para a nossa consciência operacional, vamos começar a explorar apenas o que queremos monitorar para nos ajudar a melhorar a confiabilidade.