Danças com apoio: tipos e formas de apoio. Sistemas de suporte trabalhando em batalha

Olá pessoal! Meu nome é Alexander Afenov e sou o líder da equipe de processamento de pedidos da Lamoda. Hoje, quero falar sobre como recebemos apoio.

Primeiro, vamos falar sobre como ele está incorporado em nossos processos e como, em geral, planejamos nosso trabalho, sprints e iterações.

Depois, mostrarei de onde o suporte pode vir e em que tipos ele está dividido.
Compartilharei a experiência de como lidamos na equipe com cada tipo de suporte.

No final, consideramos os prós e os contras das práticas que usamos e resumimos.


Minha equipe agora tem dois sistemas. A primeira é uma coisa grande e assustadora chamada Processamento de pedidos . Este é um sistema que automatiza o ciclo de vida de um pedido desde o processo de criação até a entrega (ou devolução).

O serviço está girando no PHP 7, envolto em Docker e Kubernetes orquestrados, mas é implementado na estrutura do Zend1 e em partes do Symfony 2. Aqueles que programam no PHP agora podem ter tremido. Quanto ao resto, explicarei que o Zend1 é uma estrutura que teve um fim de vida há um ano e meio atrás. Ele não é mais suportado e nem possui patches de segurança.

O projeto é grande (mais de 150 mil linhas de código) e não faz muito o seu trabalho. Por exemplo, não apenas processa pedidos, mas, por algum motivo, envia correio, sms, push, transfere dados para outros sistemas. Portanto, estamos cortando-o em microsserviços separados.

A primeira coisa que trouxemos do monólito é a chamada ferramenta Reembolso . Ele é o segundo serviço executado pela minha equipe e é responsável pelo retorno automático de dinheiro ao cliente (mais no relatório do meu colega) .

Apesar de a ferramenta Reembolso ter uma pilha tecnológica moderna, ela ainda gera um monte de suporte devido ao legado do processamento de pedidos.

Isso acontece devido ao fato de termos pegado um determinado processo de negócios, que costumava ser construído em muitos arquivos do Excel, e transferido para um novo sistema que funciona através do Kafka, além de interagir com alguns sistemas. Obviamente, ao introduzir um novo sistema e mudar o processo de negócios, obtivemos suporte. E ao longo de muitos anos trabalhando com isso, adquirimos alguma experiência.

Acredito que as pessoas são divididas em duas categorias: aquelas com um sistema de produção que gera apoio e malditos mentirosos. Portanto, compartilharei experiências que podem ser úteis para otimizar seus processos. Se as soluções propostas (combinadas ou separadamente) forem adequadas a você, mais tempo será exibido para o desenvolvimento da funcionalidade do seu sistema, análise do backlog técnico e não para trabalhar com suporte.

Falar sobre as ferramentas usadas exigirá contexto, portanto, primeiro falaremos sobre as mais básicas.

Processos e funções

Como trabalhamos com suporte e que lugar ocupa em nossos sprints?

Baldes proporcionais é o que eu chamo de baldes .

Tomamos 10% do atraso técnico para que ele não fique estagnado e não se acumule indefinidamente.

Aproximadamente 20% do sprint é usado para estabelecer alguns riscos. Por exemplo, alguém estava fazendo uma tarefa, mas essa pessoa foi "atropelada por um ônibus". O próximo terá que reexaminar o contexto. Como resultado, não entraremos na avaliação e tudo ficará mal.

Em seguida, colocamos o suporte planejado. Ou seja, já sabemos que algo está errado. Isso é algo que não queima muito e vamos consertar.

Mas o mais interessante é um suporte não planejado. Ou seja, assumimos que algo pode quebrar durante o período de iteração e gastaremos tempo em reparos.

Os 30% restantes são projetos.

Você provavelmente percebeu que fica mais de 100%. Isso se deve ao fato de que sempre tentamos fazer mais do que realmente podemos. Às vezes conseguimos, às vezes não muito.

Parâmetros principais de suporte

Avaliamos cada ticket de suporte de acordo com os seguintes parâmetros:

1. Criticidade para os negócios. Quão importante é isso para eles e quanto isso interrompe o processo de negócios?
2. SLA Quanto tempo devemos levar o problema para o trabalho e resolvê-lo?
3. Prioridade

Se algo der errado com os usuários de nossos sistemas, eles relatam isso ao serviço de suporte e esclarecem que um incidente está bloqueando parcial ou completamente o processo de negócios. O suporte traz imediatamente um novo ticket ao sistema responsável e o coloca como prioridade .

Criticidade e prioridade são termos diferentes.

Tipos de prioridade

Blocker - algo quebrou absolutamente tudo, parou o negócio. Os pedidos não são criados, eles não entram na entrega, os pagamentos não são aceitos e assim por diante.

Major é algo menos importante e pode ser reparado por mais tempo, pois existem soluções alternativas, caminhos alternativos.

Trivial Por exemplo, alguém escreve que nossos botões são de cores desagradáveis ​​e devem ser repintados. Há uma alta probabilidade de que tal ingresso nunca seja feito.

Também existe um contrato de nível de serviço , que é estabelecido pelo serviço de suporte juntamente com a equipe e o proprietário da empresa do sistema. Eles examinam qual linha de negócios foi quebrada como parte de uma reclamação específica. Se, por exemplo, os pedidos deixaram de ser criados (o principal pão da loja on-line), esse problema terá uma alta prioridade, que chamamos de P1. P é prioridade, a unidade é a mais importante.

P1 é um tipo de SLA, o que significa que devemos levar o problema para trabalhar dentro de meia hora e resolvê-lo em algumas horas, no máximo.

P2 é algo menos significativo que precisamos levar em algumas horas e decidir durante o dia.

P3-P4 é algo que foi quebrado e não requer reparos urgentes. Um dia você pode fazer isso, levá-lo para a próxima iteração.

E aqui chegamos à prioridade definida pela equipe. Pode ser um especialista técnico, engenheiro sênior de suporte - qualquer pessoa que lide com o problema.

Suponha que atualmente tenhamos 4 tarefas com prioridade de negócios principal. A pessoa da equipe, devido a sua experiência, coloca um certo valor numérico, que chamamos de prioridade detalhada . Com base nisso, a placa de suporte será classificada no futuro. Ou seja, no topo, haverá as tarefas de maior prioridade para os negócios, que ainda são classificadas de acordo com o entendimento da equipe de quão importante isso realmente é e com que rapidez você pode fazê-lo.

Entre os principais parâmetros, parece que um dos mais importantes está faltando - uma descrição normal . Frequentemente, temos tarefas de suporte iniciadas no sistema Sentry, onde erros, exceções etc. caem. Uma pessoa vê que há algum pequeno problema e cria um quebra-cabeça em Jira. Como nossos sistemas são integrados entre si, uma tarefa aparece no rastreador de tarefas, na descrição da qual existe apenas um link para o Sentry e no título há um texto de erro. Só isso.

Como alguém que recebe essa tarefa trabalha com isso? Não é muito claro. Se você incluísse uma boa descrição nessa tarefa, isso ajudaria bastante e economizaria tempo.

Quem vai arrecadar tudo?

E quando tudo isso é feito, surge a pergunta: quem irá arrecadar essa lista de pendências lindamente classificada? A resposta é: engenheiro de suporte.

Você pode ouvir com mais detalhes quem é o engenheiro de suporte e o que ele faz na minha palestra “Hipoteca técnica: o que e quem deve liderar a equipe” com o TeamLeadConf 2018.

Um engenheiro de suporte é um profissional que executa e corrige as tarefas de maior prioridade em uma lista de pendências de suporte. Como tudo é muito bem organizado, acreditamos que no topo é o mais importante, urgente e "assado". Se não houver tarefas, ele poderá fazer backlog técnico.

O que mais ele está fazendo?

1. Tenta isolar e eliminar a causa raiz , ou seja, a causa raiz do suporte. Quando você recebe regularmente bilhetes do mesmo tipo regularmente, vale a pena considerar por que isso acontece. Provavelmente, em algum lugar, existe um problema que pode ser eliminado e, assim, interromper o fluxo de tarefas semelhantes.

2. Ele define as tarefas para correção e monitoramento .
Se o engenheiro de suporte não puder resolver o problema em um dia ou dois, no máximo, ele configurará uma tarefa separada para ele, que entrará no backlog de desenvolvimento. Em seguida, é avaliado pela equipe e entra na iteração como um suporte planejado.

O monitoramento desempenha um papel importante para nós. Penduramos o monitoramento não apenas nas métricas que estamos acostumados a monitorar continuamente, mas também as adicionamos para localizar os problemas mais antigos. Na minha opinião, seria melhor se tivéssemos monitoramento desnecessário, que bebemos então, do que o problema será constantemente repetido na forma de mais e mais tickets.

3. Procurando por razões de automação .
Exemplo : transferimos dados para o nosso sistema, o que automatiza o trabalho do serviço de entrega. Às vezes acontece que, mesmo com o uso do canal de mensagens não entregues e encaminhamento, não podemos fornecer informações lá. Como resultado, esses pedidos ficam em algum lugar e precisam ser reenviados.

Este é um suporte típico que ocorre várias vezes por semana. Para resolver esse problema, decidimos criar uma página separada com o botão "reenviar lista de pedidos". Não temos mais esse suporte. Eles pensavam que, automatizado, o entregavam ao serviço de suporte.

O papel de um engenheiro de suporte é transferido toda semana para outra pessoa - isso é um pré-requisito. Fazer esse trabalho por mais tempo é estresse, desmotivação e deterioração, porque você está constantemente reparando algo e não traz nada de novo ao sistema.

Regularidade como fonte de graça

Parece óbvio, mas muitas vezes é esquecido. Para que tudo funcione, é necessário que nossos processos sejam colocados em prática e observados regularmente.

Inspeção de pendências

Onde obteremos uma lista de pendências de suporte muito bem classificada, se ninguém estiver olhando para lá?

De uma maneira boa, você precisa executá-lo uma vez por mês e fechar tarefas com status trivial (ao qual você provavelmente nunca chegará). Seja honesto consigo mesmo e com o cliente. Se o backlog devido a essas tarefas crescer infinitamente, mais tarde você precisará entrar em pânico para tentar fechá-las. Isso não é muito bom.

Aposição prioritária detalhada

Este é o próprio processo no qual avaliamos quão crítica é uma tarefa. Será a classificação correta e o engenheiro de suporte executará a tarefa correta de cima.

Batalha por prioridade

Por exemplo, eles definem uma tarefa para você e dizem: “Pessoal, o relatório mensal não é carregado. Precisamos tê-lo em uma semana, mas não funciona. Por favor, conserte. Prioridade P1. Você precisa decidir dentro de 2 a 3 horas. ”

E você pergunta: “Sério? Do que vocês estão falando? Afinal, há uma semana para consertá-lo. Vamos fazer o downgrade para P2 e teremos alguns dias. ”

Às vezes, as pessoas pensam que não vamos assumir a tarefa, então colocam uma alta prioridade especial. Mas isso acontece e vice-versa. Por exemplo, eles nos escrevem que os pedidos não são criados e colocam a prioridade P2. Esse problema é muito mais sério, portanto vale a pena elevar a prioridade para P1. É útil negociar conscientemente em ambas as direções.

Estabelecimento de novas tarefas

Mencionei anteriormente o sistema Sentry, que inclui tarefas que já estão sendo elaboradas pelos clientes. No entanto, nós mesmos antecipamos os problemas que surgem e lançamos tarefas para esse backlog.

Monitoramento de desempenho do SLA

Para fazer isso, temos agendamentos que mostram que temos tarefas, cujo tempo expirará em breve. Parece que esses quebra-cabeças fazem sentido em primeiro lugar.

Engenheiro de Suporte

Ser um engenheiro de suporte é um processo bastante deprimente, então uma pessoa deve ajudar. Como podemos facilitar a vida dele?

Transferindo a função para o próximo da equipe

Precisamos manter um cronograma de quem fará isso na próxima semana. No entanto, momentos de fronteira ocorrem. Por exemplo, uma pessoa realizou uma tarefa na sexta-feira e não teve tempo para concluí-la. Ele pode passar o tempo na próxima semana, mas é melhor entregar a tarefa a um novo engenheiro de suporte. Se você arrastar a lista de pendências por duas semanas, a pessoa provavelmente ficará bastante desmotivada. Você verá isso na próxima reunião pessoal :)

Ajude a encontrar a fonte do problema

As pessoas gostam apenas de executar tarefas, mas não se concentram em encontrar a causa raiz. Vale a pena fazer a pergunta: “Se você encerrou a tarefa, por que o problema surgiu inicialmente?”. Essa prática ajudará a encontrar a causa, a eliminá-la e, possivelmente, a se livrar do fluxo desse suporte no futuro.

A necessidade de um "visual renovado"

Se uma pessoa por um determinado período de tempo não conseguir um resultado visível, essa tarefa deverá ser transferida para outra. Outra pessoa poderá olhar para o problema do outro lado, o que pode levar à solução do problema de uma maneira diferente.

Mas essa abordagem pode ocultar alguns aspectos psicológicos interessantes. Ou seja, pegar uma tarefa de uma pessoa e entregá-la a outra, você corre o risco de dizer que ele sabe melhor, para que ele aguente. Tais coisas são melhor apresentadas de uma maneira diferente. Concentre-se no fato de que todos precisamos resolver problemas com o sistema e não provar um ao outro qual de nós é mais legal.

Desenvolvimento de ferramentas para automação

Aqueles que são frequentemente engenheiros de suporte entendem que já estão “assando” por realizar as mesmas tarefas típicas. Recentemente, um de nossos desenvolvedores possui seu próprio mini framework no Go. Ele vai a diferentes bancos de dados, coleta dados, envia algo para Kafka. Assim, ele conseguiu automatizar essa tarefa o máximo possível e facilitar a vida dos outros.

Fontes de Suporte

Há tantos apoios que às vezes não pensamos de onde vem com tanta frequência?

Estabilização de novos sistemas e processos

Se você trouxe algo novo, provavelmente será usado incorretamente. Você terá novos problemas e sua lista de pendências de suporte será imediatamente reabastecida com tickets ou tickets.

Suporte para sistemas mais antigos

Por exemplo, nosso monólito. Ele não pode ficar parado, como sempre adicionamos, reescrevemos algo nele. Obviamente, isso leva à criação de um novo suporte.

Falha técnica

Por exemplo, a rede desconectada. Você parece não ser o culpado, mas eles certamente o procurarão e perguntarão por que os pedidos não foram criados. Será necessário reparar, consertar, modificar alguma coisa. A intervenção manual será necessária e, portanto, novos tickets na lista de pendências serão fornecidos.

Fator humano

Tivemos um caso em que alguém foi capaz de produzir uma mensagem no RabbitMQ dizendo que nosso consumidor desligou e tudo parou de funcionar. Isso nunca aconteceu nos últimos 7 anos, mas aqui de alguma forma conseguiu :)

O fator humano que levou ao fracasso

Alguém com as palavras "eu vou consertar agora" retirou o disco rígido do servidor no qual o faturamento estava girando. Como resultado, conseguimos o que conseguimos. Esta não é a experiência Lmoda, mas um caso real da minha prática.

Tipos de suporte

Solicitação de análise

Quando perguntam regularmente sobre o status de algo no banco de dados, solicitam o upload, coletam um relatório por um determinado período e assim por diante. Isso é um pouco chato, então você tem um bom motivo para pensar em automação e apenas fornecer uma interface com o usuário ou estudar a estrutura da empresa.

Por exemplo, não descobri imediatamente que a maioria dos dados de pedidos que temos são armazenados no banco de dados Oracle do departamento de D&A e tudo pode ser obtido a partir daí. Esse suporte é automatizado por meio de interfaces ou transferido para o departamento de análise.


Solicitações de alteração de dados

As situações são diferentes e imprevisíveis. Digamos que nosso cliente pagaria seu pedido com um cartão. Quando o correio chegou, ele mudou de idéia e decidiu fazer isso em dinheiro. Ou, por exemplo, em algum lugar houve um problema automatizado que precisa ser alterado manualmente.Precisamos corrigir esses dados.

Para fazer isso, tentamos criar novos identificadores de API, criar interfaces e, ao máximo, eliminar essas tarefas do desenvolvimento e da nossa equipe de Operações. Essa é uma prática perigosa, e nos livramos dela através das melhorias na interface e na API.

Reparação de processos de negócios

Se houver uma necessidade direta de editar algo no banco de dados, haverá um processo de negócios com erros. Isso pode acontecer devido a um motivo relacionado à TI ou se algo der errado nos negócios. Lá e há ajustes necessários. Nesse caso, você precisa ir ao cliente comercial e discutir se isso pode ser feito de maneira diferente ou solicitar o desenvolvimento para reparar o processo comercial.


O recurso X parou de funcionar

Este é o meu tipo de suporte favorito, porque é o mais compreensível. Ou seja, tínhamos algum tipo de coisa no prod, mas ele quebrou e precisa ser corrigido. Descubra em qual versão morreu e por que motivo. Repare e feche o ticket. Tudo é simples.

Mas há outro suporte - o recurso X não funciona . Pode parecer a mesma coisa, mas dito em outras palavras. No entanto, isso não é verdade.

Nesta situação, eles vêm até você e dizem que isso não funciona. Você passa um dia ou dois resolvendo o problema. Só mais tarde você percebeu que isso nunca funcionou aqui . Simplesmente não estava no seu sistema.

De outra maneira, chamo esse tipo de suporte de "raposa" quando alguém astuto deseja ignorar uma solicitação de recurso sob o pretexto de uma tarefa de suporte. Esta é uma história regular que é muito dolorosa. Se você não parar esses momentos, o engenheiro de suporte ou você está apresentando uma nova funcionalidade e os problemas reais da lista de pendências de suporte permanecem sem solução.

Incidente grave

Esta é apenas a história do caixão e da turfa, quando algo quebrou tanto nos sistemas de TI que surgiu um processo comercial específico.

Estudo de caso de nossa prática: nós, devido a um erro no código e nos testes automáticos imperfeitos, começamos a enviar uma certa nota sobre o status do pedido ao serviço de correio externo, por causa do qual as pessoas não podiam receber o pedido no ponto de coleta. Isso afetou milhares de clientes. Tivemos que retirar todos os pedidos, gastar dinheiro com isso. Não podíamos vendê-los e a fidelidade do cliente foi perdida. Este é um grande incidente que prejudicou os negócios.

Vale a pena trabalhar com essas coisas de uma maneira especial, e vou lhe dizer como fazemos.

Como descobrir que algo está acontecendo?

A opção mais comum no setor é aprender com os usuários . Ele, é claro, é o pior, porque significa que eles já “assam”. , , .

, , .

— . , . , - , , , Rabbit.

, , , . , . Tivemos um caso assim quando notamos no monitor que pela manhã o consumo de memória no cluster Rabbit MQ começou a aumentar. Entendemos que possuímos apenas 16 gigabytes lá e, com essa dinâmica em poucas horas, a memória terminará e tudo cairá.



Como vimos essa tendência, ficamos alarmados com o tempo. Descobrimos que tínhamos um plugin de pá pendurado e a memória estava fluindo. O problema foi resolvido, enquanto o principal foi evitado.

Se algo já aconteceu, e você descobre, precisa localizar e divulgar de alguma forma . Obviamente, dependendo do tamanho da equipe e do que ela está fazendo, você pode fazer coisas diferentes. Mas acredito que a mobilização é muito importante .

Suponha que você tenha 5 pessoas em uma equipe. Um deles entrou na análise de por que nada está funcionando agora, enquanto os quatro restantes continuam cortando seus recursos. Como resultado, você possui sistemas quebrados e vários novos recursos. É legal, mas às vezes vale a pena mobilizar e organizar um brainstorm. O exame de cada membro da equipe pode reduzir o tempo durante o qual nada funciona.

E depois que eles conseguiram divulgar tudo, o estágio retrospectivo começa.

Retrospectiva

Em Lamoda, nesta reunião, temos uma pessoa encarregada de todos os sistemas envolvidos no incidente. Se necessário, alguém da empresa está presente, às vezes o CTO chega. E nesta reunião, fazemos uma descrição do que exatamente aconteceu e em qual sistema ele brilhou.

Depois, chega o momento mais divertido - a análise da sequência de ações. Ou seja, o que fizemos entre a detecção e a extinção para o minuto mais próximo, se possível.



Vimos que, às 13h05, uma reclamação foi recebida no call center. Por volta das 13.13, ficou claro que era enorme. E somente às 14h50 a equipe assumiu a tarefa de trabalhar. Antes disso, por algum motivo, 1,5 horas era simples, embora a tarefa estivesse definida e a equipe fosse notificada. Parece que essa diferença em 1,5 horas poderia ser reduzida e, assim, economizar milhões de rublos nesse incidente.

?

, , . , - . , , , .

, 16.55, , 40 . , , .

?

, . , . , . , - CI/CD , . , , , , , , .

— . Impacto é o impacto desse incidente nos negócios. Ou seja, quanto a empresa perdeu em pedidos, em rublos, em papagaios - isso não importa. Esta é a figura com a qual você pode entrar em negócios e mostrar o que acontece se a TI não der tempo para estabilização, automação de testes e similares.

Em seguida, a redação das ações preventivas . Isso é importante porque você precisa garantir, de alguma forma, a si mesmo, à gerência e a qualquer outra pessoa, que essa mesma coisa não será acionada hoje à noite, amanhã e assim por diante. Ou seja, você não precisa repetir o mesmo incidente. Para isso, formulamos ações preventivas. Ou seja, como você conseguirá isso, como se proteger ou se antecipar.

Também é necessário estabelecer prazos / corrigir versões .

E então . — , — .

, , Major Incident. , , , , , . , , Major Incident.

. , , , . , .

, , , , -. .

?

— . , .

Lamoda , IT. , , - - , , IT-. , 80% , , , . .

, . , , , - , IT .

Sweet spot

, , , , . , . , , , , . , .