APRENDER. PRATICAR. EVOLUIR.1. Procurar o registo certo
Uma aplicação deixa de funcionar depois de uma alteração de configuração. O Activity Log ajuda a investigar operações do plano de controlo Azure, incluindo alterações feitas através de Resource Manager. Filtra por recurso, período e operação e confirma o detalhe disponível. O facto de existir esse registo não demonstra que todas as leituras de dados ou todos os pedidos da aplicação estejam ali. Antes da passagem para produção, define quais as perguntas que o suporte precisa de responder e onde recolher os sinais correspondentes. Uma retenção insuficiente ou uma fonte não configurada pode impedir investigação posterior. No exercício, distingue claramente uma alteração administrativa de uma falha num pedido de negócio.
2. Correlacionar aplicação e plataforma
Application Insights, integrado em Azure Monitor, apoia a análise de desempenho e comportamento de aplicações com telemetria adequada. Um exemplo é relacionar pedidos falhados com chamadas a dependências numa API instrumentada. Resource Health apresenta uma avaliação de recursos específicos, como uma VM. Estes sinais respondem a perguntas complementares. A saúde de uma instância não prova que um relatório de negócio foi produzido corretamente, tal como uma exceção de aplicação não demonstra uma falha geral da plataforma. Durante um incidente, regista a cronologia, o recurso afetado e o impacto observado. O gestor coordena responsáveis e comunicação; as hipóteses técnicas precisam de evidência, não apenas de coincidência temporal.
3. Ler o estado que determina consumo
Uma VM foi desligada no sistema operativo e aparece como Stopped (Allocated). A equipa já não executa o batch, mas os recursos de computação continuam atribuídos e a utilização da instância continua faturada. Deallocated é um estado diferente: a utilização de computação da instância deixa de ser faturada, embora discos e outros recursos possam conservar custos. Não confundas atividade da aplicação com alocação faturável. Antes de alterar o estado, verifica requisitos de disponibilidade, dependências e capacidade de reinício. Os exemplos desta aula excluem compromissos de utilização e usam custos fictícios fornecidos. Uma decisão real precisa de consultar a configuração e as condições comerciais aplicáveis, além do estado operacional.
4. Comparar quantidade, tempo e custos mantidos
Usa um modelo didático: computação custa duas unidades por hora faturada e armazenamento custa trinta unidades por mês. Para sessenta horas faturadas, o total é 60 × 2 + 30 = 150. Se a computação permanecer faturada durante 720 horas, o total passa a 1470. A diferença de 1320 resulta exclusivamente das horas assumidas; não é uma previsão de poupança real Azure. Se o armazenamento aumentar para cinquenta unidades, o primeiro total sobe para 170. Este pequeno exercício obriga a separar taxa, quantidade e custo mantido. Numa reunião FinOps, confirma a janela de utilização e os requisitos de serviço antes de transformar uma oportunidade num compromisso orçamental.
5. Escolher como a capacidade e os dados mudam
Passar de duas para quatro instâncias iguais é scale out; aumentar CPU ou memória de cada instância é scale up. Nenhuma escolha demonstra, por si só, que a aplicação distribui trabalho corretamente ou que uma dependência comum aguenta a carga. Regista a restrição que motivou a mudança e a forma de a observar. Uma migração de grande volume enfrenta outro limite: a largura de banda disponível. Se a janela não permite transferir dezenas de terabytes e o transporte físico é aprovado, avalia Azure Data Box. Confirma modelo, disponibilidade, logística e validação, sem assumir capacidade universal ou prazo garantido. Uma ferramenta de cópia sobre a mesma ligação não elimina o limite físico.
6. Manter responsabilidade em serviços geridos
A passagem para PaaS reduz tarefas sobre a plataforma subjacente, mas a equipa que desenvolve uma aplicação continua a tratar código, dados e configurações sob a sua responsabilidade. Numa aplicação SaaS, os responsáveis do cliente continuam a decidir sobre os seus dados e acessos. Serverless também exige observação e tratamento de falhas: existem recursos de computação, mesmo quando a gestão dos servidores é abstraída. Azure Functions oferece diferentes opções de alojamento; não deduzas um preço ou uma regra de faturação universal apenas do nome serverless. Conclui a aula relacionando modelo de serviço, evidência operacional e pressupostos de custo. Uma entrega utilizável precisa de responsáveis claros e de confirmação de que a tarefa de negócio funciona.
No modelo fictício, 60 horas a duas unidades e armazenamento de trinta unidades totalizam 150. Manter 720 horas faturadas elevaria o total a 1470, mesmo que a aplicação tivesse pouca atividade.
Armadilhas comuns
Tratar Stopped (Allocated) como Deallocated, somar horas a custos, assumir que todo o log tem o mesmo conteúdo ou que PaaS elimina a responsabilidade pela aplicação.
Tópicos relacionados: Azure Monitor e Resource Health · Modelos de consumo e capacidade · Responsabilidade partilhada
Escolhe a evidência pela pergunta, confirma o estado faturável e mantém responsabilidades explícitas quando a plataforma passa a ser gerida pelo fornecedor.
Referência: Activity Log in Azure Monitor · AZ-900 skills measured July 20, 2026