mais lidos
Life at Nu
Conheça a sede do Nubank em Pinheiros, São Paulo/Brasil jan 11
Design
A nova aparência do Nubank: conheça nossa nova logo maio 17
Culture & Values
Como os valores e a cultura da Nu moldam os produtos que criamos ago 7
Carreiras
Reunimos grandes mentes de diversas origens que permitem a discussão e o debate e melhoram a resolução de problemas.
Saiba mais sobre nossas carreiras
Escrito por Felipe Almeida
Com contribuições de Caique Lima e Luiz Felix
Aprendizado de Máquina em tempo real refere-se à integração de Aprendizado de Máquina em sistemas que operam continuamente: isso costuma significar modelos que produzem pontuações e previsões sob demanda, quando solicitado.
Como qualquer software, as coisas podem e costumam dar errado de diversas maneiras. É uma máquina bem lubrificada onde uma peça com defeito costuma ter impactos negativos nos estágios posteriores, como:
Além do supracitado, há muitos outros tipos de falhas que se aplicam especificamente para modelos de aprendizado de máquina (ML):
A principal diferença entre softwares regulares e habilitados por aprendizado de máquina (ML) é que modelos de ML podem ter defeitos silenciosos.
Isso quer dizer que sistemas de aprendizado de máquina (ML) podem estar produzindo previsões errôneas mesmo sem haver exceções explícitas ou mensagens de erro.
Nas próximas sessões, analisamos as lições aprendidas e melhores práticas reunidas em anos de aplicação de Aprendizado de Máquina (ML) a problemas da vida real no Nubank.
Alertas x Monitoramento
Monitoramento de modelo refere-se a entender e abordar um comportamento latente, enquanto os alertas normalmente referem-se à detecção de problemas urgentes que devem ser resolvidos urgentemente.
Desta forma, o foco do monitoramento normalmente é detectar problemas para entender e investigar o que está acontecendo.
No entanto, há uma relação próxima entre alertas e monitoramento: a primeira ação realizada por alguém abordando um alerta pode ser precisamente abrir painéis de monitoramento para comparar dados de curto prazo com dados de médio prazo.
O foco dos alertas é deixar o sistema funcionando normalmente o mais rápido possível.
Conheça nossas oportunidades
Monitoramento operacional ainda se aplica
Sistemas habilitados por aprendizado de máquina (ML) também são softwares! Isso significa que todos os problemas comuns e que podem acontecer com qualquer outro sistema também podem e devem acontecer com sistemas movidos a aprendizado de máquina (ML).
Aqui estão alguns pontos do monitoramento de software regular que também se aplicam a sistemas de ML:
Integridade do sistema operacional
Como qualquer outro software de produção em tempo real, você pode querer alertas para métricas regulares e verificações de integridade:
Registros em Log/Rastreamento
Você precisará das ferramentas de rastreamento distribuído e registro em log de sempre para centralizar e habilitar a análise de dados de log.
Isso é essencial para alertas porque a maioria dos alertas verdadeiros geralmente ativarão algum tipo de investigação. É aqui que uma infraestrutura de registro em log consistente é útil.
Algumas ferramentas comuns nesse espaço são Splunk, Datadog e New Relic.
Escalas de plantão
É prática padrão em equipes de engenharia gerais ter escalas de plantão para que sempre tenha alguém disponível para abordar questões urgentes.
Alertas devem ser padronizados quando possível
A padronização ajuda a melhorar a eficiência e a dimensionar seus processos.
Isso também possibilita que você veja uma coleção de coisas como versões diferentes da mesma coisa, reduzindo a carga cognitiva quando interagir com sistemas grandes.
Alertas não são diferentes. Aqui estão alguns exemplos do que pode/deve ser padronizado em relação a isso:
Inclua comportamentos esperados
Quando escrever o texto para o alerta, não diga simplesmente o que está errado, diga o que era esperado, e sempre inclua o período avaliado.
Isso ajuda as pessoas a entender a importância do alerta e a urgência da reação, aumentando a eficiência e reduzindo a chance de falsos positivos.
Alertas devem ser práticos
Sempre que possível, adicione um link ou curso de ação claro para ajudar na reação aos alertas.
Isso é útil tanto para engenheiros experientes quanto novatos que podem nunca ter enfrentado um problema específico antes.
Um jeito ainda melhor de fazer isso é ter manuais padronizados com guias sobre como abordar os problemas mais comuns, onde encontrar ajuda etc. Isso garante processos padronizados e reduz os riscos de erro humano.
Pergunte-se quando criar um alerta: “Qual a primeira informação que o atendente precisará procurar quando abordar o alerta? Como posso facilitar para ele?”
Clique aqui para abrir a Fila de Mensagens Mortas (DLQ) e tentar configurações novamente”
Clique aqui para procurar problemas e soluções comuns no manual.”
Clique aqui para editar as configurações de dimensionamento”
Clique aqui para editar esse feature flag ou entre em contato com engenheiros no canal do Slack #qualquer para obter ajuda.”
Alertas devem ser fáceis de configurar
Os alertas para modelos de aprendizado de máquina eventualmente ficam obsoletos.
Isso pode acontecer por vários motivos: a distribuição subjacente de dados trocados ao longo do tempo, mudança nos requisitos do negócio ou da engenharia ou até mesmo outro alerta que já englobe o atual foi lançado.
Alertas param de funcionar de uma de duas maneiras:
Em outras palavras, a troca entre precisão/reiteração pode precisar de mudanças.
Faça com que todos possam facilmente:
Clique aqui para editar a configuração do alerta”
Clique aqui para editar a configuração do alerta
Clique aqui para adiar este alerta por 6 horas.”
Leve seu público em consideração
Os alertas devem ser escritos com o público desejado em mente. Isso garantirá que a mensagem que você transmitir seja recebida pelo outro lado.
Pessoas diferentes exercem uma função na entrega de um sistema habilitado por aprendizado de máquina (ML) para produção. Elas incluem, por exemplo, equipes de engenharia, profissionais de Ciência de Dados/Aprendizado de Máquina e equipes de produto/negócios.
Dependendo do público, pode ser bom adaptar:
clique aqui para visualizar a integridade de pod e as configurações de dimensionamento.”
clique aqui para visualizar o painel de recuperação de recursos”
clique aqui para visualizar o painel de negócios. Para mais informações, vá para o canal #qualquer no Slack”
Exemplo: o mesmo alerta sendo visualizado por 3 perspectivas diferentes, dependendo do público-alvo
Alertas devem ser confirmáveis e rastreáveis
Alertas, por definição, devem ser “raros”, e a ativação de um alerta, por necessidade, é um evento meio caótico.
Você precisa, no mínimo, de um jeito sólido de sinalizar que um alerta está sendo abordado.
Poder confirmar (ou dar “ACK” para os antigos) ajuda sua equipe a garantir que haja ao menos uma pessoa investigando ativamente o alerta atual. Isso também previne que diversas pessoas interfiram umas com as outras. A maioria das ferramentas de alerta suporta isso (por exemplo, OpsGenie).
Além de serem confirmáveis, os alertas idealmente devem ser rastreáveis. Ou seja, deve haver um log do período do alerta, por exemplo.
Esses logs ajudam engenheiros a encontrar informações no futuro, e provavelmente facilitam e agilizam a abordagem de futuros incidentes.
Eles também possibilitam que você analise dados de alerta e descubra, por exemplo, culpados comuns no sistema e padrões de alerta.
Outras Dicas
Alertas para a ausência de eventos
Normalmente usamos contagens, médias e somas para detectar comportamentos anormais.
No entanto, se um serviço em particular tiver parado de funcionar completamente, talvez não haja logs, o que significa que não haverá médias, contagens e nem somas.
Um jeito de resolver isso é ter alertas de pulsação, pelos quais você deve executar ping em algum API externo para sinalizar que seu serviço/sistema está operando com integridade.
Esses alertas de pulsação normalmente são configurados com um período, e se seu serviço/sistema não enviar um ping nesse período, isso ativará um alerta.
Teste seus alertas antecipadamente
Como qualquer parte de código, você deve testar que o alerta será ativado quando deve.
Um jeito de testar os alertas é deixar os limites de ativação artificialmente baixos, para que o alerta seja mais sensível e fácil de testar:
Esteja ciente da sazonalidade
Dados de recurso para sistemas em tempo real normalmente representam dados do cliente. Desta forma, eles são propensos a ciclos naturais, como dia/noite, dia útil/fim de semana etc.
Isso pode atrapalhar os fluxos de alerta porque a definição de “comportamento normal” costuma depender do horário, do dia da semana etc.
Um jeito de abordar isso é incluir um limite de tamanho de amostragem mínimo para garantir que alguns alertas (por exemplo, taxa de ações) só sejam disparados se houver dados suficientes.
Por exemplo: ativar alerta se a taxa de pontuações acima de 0,9 estiver acima de 20%, mas apenas se o tamanho de amostragem for ao menos 10.000
Em dimensão, os custos serão um problema
Quando operar em dimensões suficientemente grandes (pense em milhões de solicitações a um modelo em tempo real por dia), os custos serão um problema
Os alertas normalmente precisam ser feitos em tempo real (apesar de também haver usos para alertas em lote), então você precisa de ferramentas e infraestrutura robustas e caras para lidar com todos esses eventos.
Um jeito simples de cuidar disso é usar dados de amostragem para alertar, em vez de dados completos.
Em outras palavras, você poderia selecionar uma amostra aleatória de 10% dos seus dados e calcular alertas sobre eles, em vez de usar os dados completos. A maioria das métricas estatísticas será igual, a uma fração do custo. Entretanto, lembre-se que a amostragem dos dados só gera resultados seguros se a distribuição subjacente for grande o suficiente.
Conheça nossas oportunidades