Consciência operacional
Para começarmos a trabalhar no monitoramento de confiabilidade, há um passo antecessor que temos que dar. Em primeiro lugar, temos de nos certificar de que temos 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 na produção, primeiro temos que ter uma compreensão decente desses sistemas e como eles estão funcionando na produção.
Coletar informações sobre a configuração atual
Embora possa parecer peculiar, em muitos ambientes a primeira pergunta que precisamos responder é: "O que exatamente está rodando na produção?" Nossos ambientes de produção nos dias de hoje e os caminhos para implantá-los são suficientemente complexos para que não seja incomum primeiro ter que fazer um pouco de descoberta primeiro. Dada uma aplicação específica, quais são os seus componentes? Quais partes comunicam-se com outras partes? Quais são as dependências óbvias (e não tão óbvias) para esta aplicação?
Coletar informações sobre o desempenho normal e passado
Depois de obter essas informações, podemos tentar obter uma linha de base em torno do desempenho e do comportamento "normal" para o sistema. Há muitas razões pelas quais podemos precisar dessas informações, não a menor das quais é para nos ajudar quando temos que triar um problema com o aplicativo. O meio de uma interrupção é um mau momento para descobrir se os servidores de banco de dados executados a 80% CPU é uma coisa boa ou uma coisa ruim.
Como parte da obtenção dessa linha de base, vamos querer mergulhar na análise do desempenho passado. Embora seja verdade que o desempenho passado não é garantia de resultados futuros, às vezes pode nos ajudar a calibrar nossas expectativas. Da mesma forma, se tivermos acesso a informações sobre interrupções ou problemas pontuais passados com um serviço, isso pode dar-nos pelo menos alguma noção de possíveis modos de falha que precisaremos incorporar na nossa reflexão sobre a fiabilidade.
Coletar informações sobre o contexto
E, finalmente, é útil para nós obter algum conhecimento contextual em torno de um sistema. O contexto pode abranger uma grande variedade de categorias, sendo em grande parte sociotécnica. Por exemplo: no lado sociológico, vamos querer reunir boas informações sobre as partes interessadas associadas a um serviço ou aplicativo.
Você pode pensar ah, é óbvio quem possui ou se preocupa com um determinado aplicativo / serviço, mas em situações empresariais ou outras organizações complexas, isso pode ser muito mais difícil do que parece.
A triste verdade é que não seremos capazes de avançar muito na confiabilidade de um sistema sem uma ideia clara de quem são as partes interessadas (por razões que ficarão claras mais tarde quando discutirmos SLIs e SLOs).
Do ponto de vista técnico da questão de contexto, é realmente útil para nós prestar atenção a questões como , especificamente como esta aplicação entrou em produção? Foi implantada manualmente durante uma implantação "épica" ou foi implantada por meio de um pipeline automatizado de CI/CD com um extenso conjunto de testes unitários?
Esta informação pode ter muitas ramificações, incluindo como será fácil iterar se e quando tivermos que fazer atualizações para melhorar a confiabilidade. Também é possivelmente um indicador útil do trabalho que podemos estar fazendo e que fará uma diferença real.
Ferramentas do Azure para consciência operacional
Obter consciência operacional muitas vezes não é fácil, mas vamos analisar algumas ferramentas que o Azure fornece que podem ajudar no processo. Esta será uma exploração muito rasa; no final deste módulo, incluiremos ponteiros para outros módulos e documentação do Microsoft Learn se você quiser explorar qualquer um deles com mais profundidade.
Informações sobre aplicativos
As primeiras ferramentas que analisaremos podem nos ajudar com a pergunta "o que está realmente funcionando?". Como pessoal de operações, não é incomum ser solicitado a trabalhar com uma aplicação já em funcionamento na produção. Embora idealmente fôssemos parte de todo o ciclo de vida do software, começando na fase de projeto, nem sempre (ou talvez frequentemente) esse é o caso. Quando isso acontece, especialmente com aplicações multicamadas ou baseadas em microsserviços mais complexos, apenas compreender o que todas as partes móveis fazem pode exigir esforço.
Uma ferramenta que pode reduzir esse esforço, além de nos fornecer informações sobre o comportamento do aplicativo na produção, é o Application Insights. Com o mínimo de esforço, os desenvolvedores podem instrumentar seu aplicativo para que ele envie automaticamente informações de telemetria para 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 você ampliar uma das conexões entre componentes, poderá ver o número de chamadas feitas entre componentes e a latência média dessas chamadas. Você também pode ver uma representação do número de chamadas bem-sucedidas e do número de chamadas falhadas. Se você selecionar qualquer um desses elementos de mapa, o Application Insights permitirá que você analise as informações para ver estatísticas detalhadas sobre métricas de desempenho e sucesso/falha para essas chamadas. Esta pode ser uma ótima maneira de ter uma boa noção da visão geral dos componentes do aplicativo e como eles funcionam como uma linha de base. Como lembrete, certifique-se de explorar o mapa do aplicativo e tudo o que o Application Insights pode oferecer antes de você tiver uma interrupção.
Azure Resource Graph (gráfico de recursos do Azure)
O serviço Application Insights é uma ótima maneira de obter algum conhecimento operacional sobre uma aplicação, mas e se quiseres obter uma perspetiva de um nível ainda mais alto e ver todos os recursos que tens ativos no Azure numa subscrição? No passado, você baixava relatórios ou escrevia o PowerShell para coletar essas informações, mas agora há uma maneira muito mais fácil.
O Azure Resource Graph Explorer fornece um ambiente de consulta interativo diretamente do portal do Azure para os dados de 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 você quiser ver todas as VMs que está executando no momento, poderá executar a seguinte consulta:
e você receberá de volta uma lista detalhada completa das VMs que estão sendo usadas em nossa assinatura:
A linguagem de consulta usada neste ambiente é Kusto Query Language (KQL). Discutiremos isso mais detalhadamente mais adiante neste módulo, quando falarmos sobre o Azure Monitor Log Analytics.
Painéis
A ferramenta de operações mais tradicional para a consciência operacional é o venerável painel. Muitas vezes, quando pensamos em pessoas fazendo operações, imaginamo-las sentadas em frente a grandes monitores olhando intensamente para painéis cheios de gráficos, tabelas e contadores. Neste módulo, não vamos explorar como você constrói, edita e usa painéis. Isso é feito, em grande parte, fixando conteúdo de outros lugares no portal e, em seguida, movendo-os como achar melhor.
Em vez disso, vamos examinar dois recursos de painel menos usados que podem ser de benefício real para você. Você pode encontrar esses recursos na parte superior de cada painel.
As duas setas realçadas permitem carregar e exportar representações JSON de painéis.
Primeiro, vamos começar com a funcionalidade de exportação. Se você selecionar Exportare, em seguida, selecione Download, um arquivo JSON que representa o painel atual será baixado para o seu computador. Se desejar, tente agora fazendo login no portal, selecionando Painel no menu do produto e depois escolhendo Exportar >Baixar.
Há pelo menos duas coisas que você pode fazer com este arquivo que você pode achar útil:
Você pode verificar esse arquivo em seu sistema de controle do código-fonte. Isso permite que você acompanhe suas diferentes versões de painéis e também permite que outras pessoas os acessem se quiserem usar seu painel. Alguns podem chamar isto de "painéis em forma de código".
Você pode usar esse arquivo como base de um novo painel. Aqui está um exemplo concreto que revisitaremos mais adiante neste caminho de aprendizagem: digamos que você precise mostrar a um colega como foi um painel específico por uma hora durante uma interrupção que aconteceu na semana passada. Você pode publicar seu painel e pedir que eles selecionem o tempo e o período de tempo precisos. Mas muito mais fácil e menos propenso a erros, você pode baixar seu painel configurado exatamente como você precisa e compartilhar esse arquivo JSON. Se você quiser destacar 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 para a funcionalidade de upload. Além de poder carregar os arquivos editados ou controlados por versão da última seção, você pode usar a funcionalidade de upload para fazer uso do trabalho cuidadoso de outras pessoas ao construir painéis.
Vejamos o exemplo final desta seção que une bem duas das ideias desta unidade. Se você baixar este arquivo JSON:
para o seu computador e, em seguida, carregá-lo para um painel, você verá algo assim:
Agora você tem um painel ao vivo que mostra um inventário bastante compreensível de seus recursos em uso em uma assinatura. Os dados deste painel são provenientes da mesma fonte que o Azure Resource Graph Explorer que examinamos anteriormente. Na verdade, se você selecionar um dos blocos, poderá ver (e editar, se desejar) a consulta exata que está sendo executada para produzir as informações exibidas nesse quadrado. Excelente, não?
Com essa ajuda para nossa consciência operacional, vamos começar a explorar exatamente o que vamos querer monitorar para nos ajudar a melhorar nossa confiabilidade.