Os engenheiros permanentes da Uber facilitam experiências perfeitas para passageiros e motoristas em todo o mundo, mantendo a confiabilidade 24 horas por dia em nossos aplicativos. Para executar essa confiabilidade, no entanto, precisamos garantir que nossas equipes permanentes estejam configuradas para o sucesso.

Até janeiro de 2016, a nossa caixa de ferramentas permanente esteve dispersa em vários sistemas, dificultando que os engenheiros respondessem com alertas de forma rápida e eficiente. Somado a isso, estava a incapacidade da solução de rastreamento que estávamos usando naquele momento – relatórios de e-mail – para efetivamente retransmitir informações contextuais sobre mudanças anteriores para engenheiros permanentes integrados. Precisávamos de uma solução que centralizasse a nossa caixa de ferramentas permanente e providenciasse o próximo engenheiro permanente com uma imagem mais completa do estado do sistema na transferência.

Para arquitetar uma melhor experiência permanente, nossa equipe de Engenharia de Confiabilidade de Site (SRE) criou uma nova e versátil ferramenta para resposta de incidentes em tempo real, manutenção de mudança e análise post mortem – todos componentes principais de um sistema permanente dinâmico e responsivo.

Atualmente utilizado por centenas de equipes em toda a Uber, o Painel Permanente incorpora anotações, runbooks, ações de resposta embutidas e uma pesquisa de taxa de sinal-para-ruído padronizada que facilita a interpretação e atinge alertas importantes. A solução também rastreia e visualiza métricas através de análises detalhadas que permitem que os engenheiros entendam melhor o estado do sistema que estão herdando.

Neste artigo, apresentamos o Painel Permanente, delineando seus recursos emblemáticos e compartilhando como as equipes de engenharia da Uber usam essa ferramenta poderosa.

Todas as coisas permanentes, tudo em uma tela

Ao projetar o nosso novo painel, queríamos melhorar a experiência do usuário para engenheiros permanentes, exibindo todas as informações contextuais necessárias sobre uma determinada mudança em uma tela e eliminando a necessidade de alternar entre muitas ferramentas.

Abaixo, discutimos vários recursos principais deste painel:

• Anotações. Um dos componentes mais valiosos do Painel Permanente é a capacidade de anotar alertas. As anotações permitem que os engenheiros ofereçam contas escritas do contexto de um alerta e ações correspondentes tomadas pelo engenheiro permanente. Anotações são contas não automatizadas do contexto do alerta e ações tomadas; quando constantemente entregues, tornam mais fácil para os futuros engenheiros permanentes resolver alertas recorrentes.
• Runbook. Revisar um runbook sempre que um alerta correspondente se apaga pode ser tedioso. Imagine um mundo perfeito em que cada alerta e seu runbook associado estivessem apenas há um clique de distância! O Painel Permanente torna isso possível.
• Ações de resposta incorporadas. Para atuar de forma mais eficiente nas anotações, também precisamos incorporar ações de resposta incorporadas que reconheçam e resolvam alertas. Uma vez que a fonte de verdade para todos os alertas está fora do Painel Permanente, devemos poder representar as ações em seu estado para seus respectivos serviços. Uma vez representados, podemos realmente melhorar esses serviços. Ao importar informações de propriedade do serviço através de ações de resposta incorporadas, negociamos um mapeamento mais próximo entre os serviços quebrados e as pessoas que podem consertá-los. Isso garante que a equipe responsável pela manutenção do serviço seja notificada independentemente de possíveis transferências de propriedade.

Classificando sinais através do barulho

Alertas ruidosos são uma ferramenta forte para todos que os “ouvem”. Alertas não acionáveis ou mais triviais são distrativos e desperdiçam um valioso tempo de engenharia que poderia ser melhor gasto em outros lugares. Se o padrão para dadas ocorrências de alerta é “isso não é importante”, a possibilidade de erro humano aumenta quando algo realmente sai do trilho.

Como o Painel Permanente incorpora anotações para coletar comentários sobre alertas, também alavancamos isso para indicar o ruído. Precisamos padronizar um único esquema de etiquetagem para todas as equipes, então apresentamos uma pesquisa de taxa de sinal-para-ruído (SNR) de duas perguntas vinculada à anotação para ajudar nossos engenheiros a cortar o ruído.

Depois de pesquisar equipes diferentes, percebemos que a SNR não pode ser contida em uma única dimensão: precisava medir tanto a precisão (por exemplo, se um serviço estava quebrado ou não) quanto a capacidade de ação (por exemplo, um serviço sob a competência de uma equipe específica está quebrado e eles precisam corrigi-lo).

No entanto, essas métricas não têm sentido se a pesquisa não for obrigatória. Se nossos clientes anotarem alertas em nossa pesquisa SNR na mente, a equipe do Painel Permanente pode acompanhar melhor a eficácia do nosso sistema de monitoramento para cada usuário. Uma vez que temos esses dados, podemos trabalhar com as equipes para melhorar seus resultados SNR avançandos.

A pesquisa SNR ajuda os engenheiros – e, em particular, os gerentes – a acompanhar suas rotações permanentes, além de permitir que nossa equipe construa soluções permanentes que melhor atendam nossos usuários.

Categorizando alertas SNR

Para facilitar os engenheiros permanentes a anotarem, os alertas SNR se dividem em seis categorias com base na capacidade de ação e precisão, delineadas na tabela abaixo:

Não surpreendentemente, as equipes visam seus alertas para cair na zona verde (na interseção de capacidade de ação e precisão) tanto quanto possível e a zona vermelha sólida (precisão sem capacidade de ação e precisão desconhecida, indicando graves problemas de alerta) tão raramente quanto possível. Usamos as seguintes três métricas para julgar o nível de SNR: porcentagem de SNR anotado, porcentagem SNR precisa e porcentagem SNR acionável.

Os resultados da pesquisa SNR são salvos junto com outras propriedades de alerta para análises futuras e são incorporados nas estatísticas do Painel Permanente e nos e-mails de relatório de mudança.

Medição de qualidade de mudança

Outra consideração importante ao projetar o Painel Permanente foi como podemos usar a ferramenta para não apenas monitorar alertas e SNR, mas também garantir que as cargas permanentes fossem distribuídas uniformemente entre as equipes. Para fazer isso com sucesso, tivemos que quantificar e rastrear a opinião atual sobre as responsabilidades permanentes tanto para equipes individuais, quanto para a nossa organização como um todo.

Para abordar isso, desenvolvemos uma equação genérica que engloba várias métricas de mudança permanentes. Para o nosso caso de uso, a saída da função é de dois números, representando a carga de mudança permanente e a qualidade das ações de engenharia permanentes. A carga, a qualidade e as métricas correspondentes destinam-se a serem usadas como KPIs para medir a experiência permanente em busca de metas e avanços ao longo do tempo. A implementação inicial calcula a carga de mudança a partir das seguintes métricas: quantidade de alertas, perturbações, runbooks e anotações, além da taxa sinal-para-ruído e ausência de alertas órfãos. Abaixo, examinamos mais de perto cada uma dessas métricas:

• Alertas. A métrica de Alertas é baseada na contagem de alertas. Por exemplo, os alertas de baixa urgência são considerados menos importantes do que alertas de alta urgência, e os alertas criados manualmente ou escalados requerem mais tempo para resolver. Os primeiros alertas são ignorados, seguidos por um impacto acentuado, mas decadente, para a pontuação geral da carga de mudança.
• Perturbação. A pontuação de Perturbação indica a distribuição de ações permanentes. O efeito de Perturbação aumenta se um engenheiro for alertado continuamente durante a mudança. Para avaliar isso, descontamos quinze minutos para cada alerta do tempo produtivo do engenheiro.
• Runbooks. Cada alerta contém um runbook e uma pontuação de qualidade do runbook atribuída por engenheiros permanentes em mudanças anteriores. A métrica do Runbooks é simplesmente o valor médio das pontuações do runbook subtraído de 100 por cento. Uma métrica Runbooks Pobre de zero por cento significa que todos os resultados do runbook foram cinco estrelas em todos os alertas durante aquela mudança.
• Anotações e SNR. As anotações e métricas SNR representam a fração de alertas com anotações e marcação SNR, respectivamente. Uma alta anotação e taxa de marcação indicam que informações mais completas sobre a mudança são fornecidas hand-off e coletadas para futuras análises.
• Alertas Órfãos. Alertas órfãos, que significam alertas que ainda estão abertos até o final da mudança, mas não estão anotados, indicam o fraco engajamento permanente e o aumento da carga de trabalho durante a próxima mudança. As medidas métricas Alertas Órfãos mudam a qualidade de forma semelhante à métrica Alerta, diminuindo exponencialmente após os primeiros poucos alertas.

Os componentes individuais que compõem os valores de carga e qualidade, junto com as métricas individuais de mudança permanentes, estão incluídos nos relatórios de mudança compartilhados com os próximos engenheiros permanentes. Esses relatórios de mudança são essencialmente um instantâneo da situação permanente no final de uma determinada mudança, incluindo uma linha de tempo de alerta, descrita na Figura 9 abaixo:

Os relatórios incluem a linha de tempo de alerta, uma lista compactada de todos os alertas, suas anotações e uma conta resumo de forma livre do engenheiro deixando o serviço. As estatísticas resumidas e os números de qualidade também estão incluídos neste relatório.

Analítica

Além de rastrear alertas específicos, SNR e métricas, o Painel Permanente também incorpora analítica detalhada que retrata esses dados permanentes para melhorar os processos e, em última instância, a experiência permanente geral para nossos engenheiros. Nossa solução analítica baseia-se em frameworks Elasticsearch e Kibana (amplamente utilizados em nossa pilha de tecnologia), pois a tabela de Kibana, a linha, as tabelas de colunas e as visualizações de números grandes são uma solução ideal para o nosso tamanho e escala.

Cada alerta é armazenado no Elasticsearch como um documento separado contendo detalhes de alerta, como horários de atendimento de alertas, anotações e fonte de alerta, com um total de mais de setenta atributos. Um documento de mudança contendo vários campos numéricos utilizados para agregação de dados específicos de mudança também é postado no Elasticsearch, imediatamente após o final de cada mudança. Um resumo da atividade de mudança é composto por mais de noventa atributos, incluindo estatísticas de anotação, estatísticas de anotação de SNR e estatísticas de duração de alerta, entre outros. Além dos painéis semanais, mensais e anuais, as equipes permanentes podem criar resumos permanentes personalizados para exibir dados específicos da equipe.

As figuras 10-13, abaixo, descrevem alguns casos de uso de visualização acessíveis através do Painel Permanente:

Agora que introduzimos todos esses recursos, vejamos como o Painel Permanente foi aplicado para melhorar as experiências dos engenheiros permanentes da nossa equipe Schemaless.

Dos dados para a ação: caso de uso Schemaless

O Schemaless é o armazenamento de dados escalável com base em MySQL da Engenharia da Uber que nos permitiu expandir nossa infraestrutura em escala. Dado o escopo completo da Schemaless, os engenheiros permanentes são fundamentais para garantir uma experiência de usuário perfeita para os outros usando o armazenamento de dados.

O acesso a métricas fáceis de interpretar e acionáveis através do Painel Permanente foi a primeira grande vitória para esta equipe. No lado esquerdo do gráfico na Figura 14, abaixo, descrevemos sua colheita inicial das frutas mais fáceis de colher do nosso sistema de monitoramento e relatório permanente completo: medição de alertas:

A segunda grande vantagem para a equipe Schemaless foi a capacidade de anotar esses alertas. Conforme ilustrado na Figura 14, assim que a quantidade de alertas anotada se aproxima de 100 por centro, o número total de alertas começa a diminuir de forma constante, sugerindo que, uma vez que a causa raiz de um alerta (ou grupo de alertas) seja identificada, ela pode ser resolvida. As anotações ajudam a atualização semanal das estatísticas, já que a equipe agora tem acesso a informações detalhadas sobre a causa e as ações correspondentes tomadas em resposta ao alerta.

A equipe Schemaless pode compartilhar essas ideias com outras equipes que podem estar recebendo alertas similares durante a permanência. Além disso, as visualizações de analítica do Painel Permanente também permitem que a equipe identifique alertas que ocorreram mais frequentemente do que outros para que ela possa se concentrar neles.

Para aproveitar ao máximo desta solução, a equipe exibiu o Painel Permanente em um monitor grande visível para todos os membros da equipe durante o dia de trabalho, facilitando o monitoramento da saúde do serviço em tempo real. Ao manter as abas no painel, mesmo durante as horas sem mudança, os membros da equipe tomaram conhecimento do que está acontecendo com o sistema em todas as horas do dia, promovendo maior colaboração e a totalidade da equipe do processo permanente. Essa sensação de colaboração aumentou a empatia entre os membros da equipe que agora entendem a extensão total das demandas permanentes durante horas extras.

Uma experiência permanente perfeita para todos

O Painel Permanente atualmente é usado por centenas de times na Uber para facilitar experiências mais perfeitas para nossos engenheiros permanentes. À medida que os serviços da Uber continuam a crescer em escala, esta nova ferramenta e outras soluções SRE garantirão que esses serviços funcionem como um relógio em todas as horas do dia. Se os sistemas de arquitetura para aumentar a produtividade da engenharia e melhorar a experiência permanente lhe atraem, considere candidatar-se a um cargo em nossa equipe!

Vytautas Saltenis e Marijonas Petrauskas são engenheiros de software e Edvinas Vyzas é gerente de engenharia. Todos os três trabalham no escritório da Uber Vilnius, na Lituânia.

***

Este artigo é do Uber Engineering. Ele foi escrito por Vytautas Saltenis, Edvinas Vyzas e  Marijonas Petrauskas. A tradução foi feita pela Redação iMasters com autorização. Você pode conferir o original em: https://eng.uber.com/on-call-dashboard/