Como cultivar um produto saudável (exemplo Juno)

Muito foi dito sobre as vantagens de trabalhar em uma empresa de supermercado, e é difícil ser original aqui. Mas longe de todo mundo sabe como manter a “saúde” de um produto e o que é possível fazer em uma empresa de alimentos, além de desenvolver funcionalidades. Informaremos como operamos o produto na Juno e como o departamento de operações e os especialistas técnicos estão envolvidos nisso.

Não declaramos que nosso caminho é o mais correto, tentamos constantemente, cometemos erros e tentamos aprender com nossos erros. Esperamos que nossa experiência seja útil para você.

Sobre nós: O Juno é um serviço de esconderijos que opera no mercado dos EUA e faz parte do grupo de empresas Gett.

Juno escreve código nos idiomas Go, Swift, Kotlin, Python, React.js como parte das equipes de aplicativos móveis, Backend, Frontend, Data Science, Suporte técnico à operação, criando um serviço que se tornou parte do cotidiano de dezenas de milhares de motoristas e centenas de milhares de novos residentes York.

O que é gerenciamento de produtos

Vamos entender o processo de operação no Juno e tentar decompô-lo em suas partes constituintes.
Nós identificamos três componentes principais para nós mesmos:

1. Escritório operacional
   
2. Métricas e monitoramento
   
3. Investigação de incidentes
   

O objetivo de operar o produto é responder em tempo hábil a problemas e mudanças emergentes, independentemente de sua natureza.
Para fazer isso, você precisa:

• Definir indicadores de integridade do sistema
  
• Entenda como as mudanças no sistema afetam as métricas
  
• Entenda como as mudanças do mercado afetam o desempenho
  
• Entenda quando a mudança se torna um problema
  

Com essa abordagem, as decisões de negócios são baseadas em dados. Nossa equipe operacional trabalha em Nova York, pois o serviço Juno atualmente está disponível apenas para os residentes desta metrópole.
A lista de tarefas diárias da equipe fica assim:

• Acompanhe e responda rapidamente às mudanças regulatórias. Mudanças comuns incluem o surgimento de uma nova rodovia com pedágio e a transferência de uma área de espera para os motoristas no aeroporto. Assim que recebermos informações sobre esses eventos, o funcionário sai do local para atualizar corretamente o mapa e analisar a lista de possíveis problemas. Quando a equipe de desenvolvimento atualiza o mapa nos servidores, o funcionário testa as alterações nas "condições de campo" e garante que funcione corretamente.
  
• Realize pesquisas "de campo". Quando lançamos o serviço em Nova York, o plano era primeiro recrutar um certo número de motoristas para a operação estável do serviço em qualquer área da cidade. Por esse motivo, por alguns meses, os motoristas que se juntaram a nós dirigiram primeiro sem passageiros e só ocasionalmente receberam viagens de testadores beta. Essas viagens não foram suficientes para reunir as informações necessárias. Decidimos enviar a equipe de operação aos “campos” para avaliar a qualidade do serviço e descobrir as reclamações dos motoristas sobre o aplicativo. Essa abordagem acabou sendo útil e a usamos constantemente ao liberar alterações significativas ou para testar hipóteses.
  
• Notícias "Calendário de eventos" - uma lista de eventos, feriados e eventos climáticos que podem afetar a quantidade e a qualidade das viagens. Isso ajuda a entender e antecipar alterações nos principais indicadores (por exemplo, o número de viagens ou o número de motoristas on-line) que não são óbvios para a equipe de desenvolvimento de Minsk. Alguns eventos podem ser pesquisados ​​no Google (condições climáticas, finais de SuperBowl, maratonas, corridas de bicicleta etc.), mas há alguns que são mais difíceis. Por exemplo, no primeiro ano de trabalho, surpreendeu-nos o fato de o Ramadã afetar bastante o número de motoristas dispostos a aceitar um pedido. O fato é que, nos EUA, muitos muçulmanos trabalham como motoristas e não vão trabalhar de férias. É difícil levar em conta esse fato enquanto estiver em Minsk.
  
• Acompanhe as alterações nas métricas de negócios. No terceiro mês após o lançamento do Juno e o rápido crescimento no número de viagens, descobrimos que não havia motoristas on-line suficientes, o que afetava o tempo de entrega do carro e o desejo dos passageiros de viajarem conosco. Acontece que um concorrente lançou uma campanha garantindo aos motoristas um aumento no pagamento de viagens no horário da manhã e da noite. As informações foram rapidamente transmitidas a Minsk e, em pouco tempo, também tivemos a oportunidade de oferecer tais condições. Esta etapa nos ajudou a recuperar os motoristas e continuar a crescer.
  

Métricas e monitoramento

No Juno, todas as equipes têm métricas, que concordamos em dividir em:

• Métricas de negócios.
  
• Métricas técnicas.
  

As métricas de negócios são uma série de indicadores que medem a "saúde" de um produto. Nós os dividimos condicionalmente em duas partes:

• Em linha Os óbvios são o número de motoristas e passageiros on-line, o número de viagens por status. Menos óbvios são o número de novos usuários, a conversão da tela com o preço preliminar da viagem para reservar uma viagem, o tempo médio de espera de um carro em uma área específica, a velocidade da fila no aeroporto, etc.
  
• Offline Nem todas as informações podem ser obtidas e processadas rapidamente em tempo real, e isso nem sempre é necessário. Quando planejamos promoções para drivers ou novos recursos, estamos interessados ​​em tendências de longo prazo ou reações do usuário ao experimento A / B, seja um novo design, uma nova função ou um desconto adicional.
  

Para criar relatórios analíticos com base nas métricas coletadas, usamos o Tableau. Para esses relatórios, somos responsáveis ​​pela equipe de Business Intelligence (BI). Eles trabalham no escritório de Tel Aviv, ao lado da equipe de compras. Ambas as equipes trabalham em estreita colaboração com colegas em Nova York, o que permite aos analistas baseados em BI avaliar o sucesso das ações tomadas, formular hipóteses para verificação nos “campos” e ajustar o plano de desenvolvimento do produto.

Por outro lado, existem várias métricas técnicas que de alguma forma afetam o sistema como um todo.

Métricas técnicas são uma série de indicadores indicando a operação livre de erros de componentes individuais, com base nos quais é tirada uma conclusão sobre a operação do sistema como um todo. Eles mostram quanto tempo as chamadas entre serviços levam, quanto consomem memória e se há algum erro crítico ao transferir mensagens entre eles. Existem muitas métricas no Juno. Eles são um pouco redundantes, mas em situações críticas, ajuda a encontrar rapidamente a causa do problema. O rastreamento e o uso de métricas técnicas nos ajudam a:

• Painel - exibe sinais vitais significativos do sistema. Cada equipe de desenvolvimento compila seu próprio conjunto de métricas que os ajuda a entender como uma mudança específica afetou os microsserviços que lhes foram confiados. Assim, por exemplo, uma equipe monitora as métricas relacionadas ao pagamento de pagamentos a motoristas e passageiros, e a outra analisa a métrica responsável pelo tempo de pesquisa do motorista ou pelo número de coordenadas recebidas.
  

• Logs Registramos eventos de dispositivos móveis e microsserviços de back-end. Em 2017, eles ocupavam de 400 a 500 gigabytes por semana, até 2018 esse número dobrou. Estamos interessados ​​nos seguintes eventos: chamadas de microsserviços para fontes externas de informação, para outros microsserviços, solicitações de clientes recebidas e enviadas, todo tipo de erro (comercial e técnico). Vale ressaltar que as informações são anonimizadas: dados pessoais, como senhas e informações bancárias, não são registrados.
  

Para monitorar o desempenho, usamos Grafana e Prometheus. Ao desenvolver um novo serviço ou adicionar uma nova função, os desenvolvedores adicionam as métricas necessárias ao serviço e, em seguida, cada equipe configura alertas para si.

Graças a alertas personalizados, a equipe de suporte técnico faz uma análise inicial e encaminha o problema para o desenvolvimento ou para as equipes de negócios, para uma maior resolução.
Se o problema é de natureza técnica e ameaça a operação normal do serviço, a equipe de suporte técnico cria um incidente de produção. Graças ao processo automatizado, as partes interessadas são imediatamente notificadas, incluindo a equipe de suporte ao cliente (Atendimento ao cliente, também conhecido como Helpdesk ou Suporte L1), que está se preparando para um possível fluxo de chamadas.

Investigação de incidentes

Com o tempo, chegamos à conclusão de que, após cada incidente grave, ocorre uma espécie de "interrogatório". Estamos fazendo alterações nos processos que nos ajudam a evitar ou lidar melhor com eventos semelhantes no futuro.

Os elementos mencionados acima: métricas, painéis, alerta e logs ajudam a entender o que aconteceu. As equipes se sentam juntas, analisam mudanças nos indicadores técnicos e de negócios, levam em conta os erros e extraem lições para si mesmas.

Temos que lidar com incidentes de produção, bem como com qualquer outra situação em que seja impossível responder rapidamente "o que aconteceu". E aqui a equipe de suporte técnico ajuda (TechSupport, também conhecido como suporte L2).

Quais problemas foram resolvidos no suporte técnico? Acredita-se que este seja um trabalho chato, como na série IT Crowd, onde três nerds no porão fazem o que dizem: "tente desligar e ligar o computador". De fato, questões surgem complexas e controversas.

O primeiro nível de suporte (atendimento ao cliente) é organizado pelo princípio de “siga o sol” (siga o sol). Com essa abordagem, o suporte ao usuário 24 horas por dia é possível sem o turno da noite. Nos tempos europeus, um escritório está localizado em Tel Aviv, e no horário americano - em Portland. A tarefa dessa equipe é ouvir e entender a “dor” do motorista ou passageiro, acalmar-se, ajudar, se possível. Os caras que trabalham lá são responsáveis ​​por perguntas sobre a operação do serviço. Ao mesmo tempo, a equipe não é "técnica" e, assim que chega o momento em que é necessário aprofundar as nuances técnicas, a solicitação é redirecionada para a equipe de suporte técnico. Essa equipe trabalha em Minsk e faz parte do centro de desenvolvimento. Eles resolvem questões exclusivamente técnicas e não se comunicam diretamente com motoristas e passageiros. Tarefa da equipe: investigação de incidentes e automação de processos.

No caso de um incidente de produção, a tarefa da equipe de suporte técnico é a seguinte: um bug foi encontrado ou ocorreu uma falha durante a implantação, notamos um problema, o corrigimos, mas ainda precisamos descobrir como isso afetou o sistema e o que precisa ser restaurado do ponto de vista do gerenciamento de produtos:

• Os dados estão danificados ou a sua integridade é violada?
  
• Como esse incidente afetou os usuários?
  
• Todos os usuários são afetados?
  
• O que pode ser consertado?
  

As perguntas são simples, mas para respondê-las, você precisa entender muito bem como o sistema funciona e como seu comportamento mudou durante o incidente. Ao responder à pergunta, vale a pena considerar o processo de implantação em andamento, como a probabilidade de que algo possa mudar a cada minuto.

Como exemplo, quando foi necessário suporte técnico para o produto funcionar corretamente, considere o caso "Não fiz uma viagem". O motorista pegou outro passageiro e fez uma viagem pela qual nosso passageiro não quer pagar. Nesse caso, é necessário distinguir entre uma solicitação legítima e uma tentativa de fraude quando o usuário tenta não pagar pelos serviços prestados.

Se a solicitação chegar repetidamente, ela será automatizada pela equipe de suporte técnico e fornecida à equipe de suporte ao usuário na forma de um aplicativo da web. Essa abordagem permite reduzir o tempo necessário para processar a solicitação de um usuário e não "inflar" a equipe de suporte técnico. No entanto, a vaga do engenheiro de suporte técnico está sempre aberta para nós, à medida que o pessoal cresce e se muda para outras equipes de desenvolvimento.

Todas as estradas levam a Roma

Uma descrição detalhada do trabalho da equipe de suporte técnico na estrutura deste artigo não é acidental. Aconteceu que se tornou um lugar onde a informação flui de todas as fontes. Um único ponto de contato reduz o número de intérpretes e, portanto, reduz o número de distorções.

Isso não significa que a equipe de suporte técnico seja o principal elo no gerenciamento do produto da operação, porque a empresa do produto é um organismo vivo: todos os órgãos são importantes e necessários. É impossível escolher o que é mais importante para uma pessoa - o cérebro ou coração, pulmões ou sistema circulatório. Somente o desenvolvimento e a interação harmoniosos de todos os órgãos garantem o funcionamento saudável do corpo ou da empresa de TI.

Saúde para você e seus produtos!