Olá, Habr! Tenho oferecido suporte a sistemas de TI Highload há dez anos. Não escreverei neste artigo sobre os problemas de configuração do nginx para funcionar no modo 1000+ RPS ou outras questões técnicas. Compartilharei minhas observações sobre os problemas nos processos que surgem no suporte e operação de tais sistemas.
Monitoramento
O suporte técnico não espera até que chegue uma solicitação com o conteúdo “O que, por que... o site não está funcionando novamente?” Um minuto após o site travar, o suporte já deverá ver o problema e começar a resolvê-lo. Mas o site é a ponta do iceberg. Sua disponibilidade é uma das primeiras a ser monitorada.
O que fazer quando os restantes produtos de uma loja online já não chegam do sistema ERP? Ou o sistema CRM que calcula descontos para clientes parou de responder? O site parece estar funcionando. O Zabbix condicional recebe sua resposta 200. O plantonista não recebeu nenhuma notificação do monitoramento e está assistindo com alegria o primeiro episódio da nova temporada de Game of Thrones.
O monitoramento geralmente se limita apenas a medir o estado da memória, da RAM e da carga do processador do servidor. Mas para os negócios é muito mais importante obter a disponibilidade do produto no site. A falha condicional de uma máquina virtual no cluster fará com que o tráfego pare de ir para ela e a carga em outros servidores aumente. A empresa não perderá dinheiro.
Portanto, além de monitorar os parâmetros técnicos dos sistemas operacionais nos servidores, é necessário configurar métricas de negócios. Métricas que afetam diretamente o dinheiro. Diversas interações com sistemas externos (CRM, ERP e outros). O número de pedidos por um determinado período de tempo. Autorizações de clientes bem-sucedidas ou malsucedidas e outras métricas.
Interação com sistemas externos
Qualquer site ou aplicativo móvel com faturamento anual superior a um bilhão de rublos interage com sistemas externos. Começando pelo CRM e ERP citados e terminando com a transferência dos dados de vendas para um sistema externo de Big Data para análise de compras e oferta ao cliente de um produto que ele com certeza comprará (na verdade, não). Cada um desses sistemas tem seu próprio suporte. E muitas vezes a comunicação com esses sistemas causa dor. Principalmente quando o problema é global e é necessário analisá-lo em diferentes sistemas.
Alguns sistemas fornecem um número de telefone ou telegrama para seus administradores. Em algum lugar você precisa escrever cartas aos gerentes ou acessar os rastreadores de bugs desses sistemas externos. Mesmo no contexto de uma grande empresa, diferentes sistemas operam frequentemente em diferentes sistemas de contabilidade de aplicação. Às vezes torna-se impossível acompanhar o status de um aplicativo. Você recebe uma solicitação em um Jira condicional. Aí no comentário desse primeiro Jira você colocou um link para o problema em outro Jira. No segundo Jira do aplicativo, alguém já está escrevendo um comentário que você precisa ligar para o administrador condicional Andrey para resolver o problema. E assim por diante.
A melhor solução para este problema seria criar um espaço único de comunicação, por exemplo no Slack. Convidar todos os participantes do processo de operação de sistemas externos para participar. E também um único rastreador para não duplicar aplicativos. Os aplicativos devem ser rastreados em um só lugar, desde o monitoramento de notificações até a saída de soluções de bugs no futuro. Você dirá que isso não é realista e historicamente acontece que trabalhamos em um rastreador e eles trabalham em outro. Surgiram diferentes sistemas, eles tinham suas próprias equipes de TI autônomas. Eu concordo e, portanto, o problema precisa ser resolvido de cima, no nível do CIO ou do proprietário do produto.
Cada sistema com o qual você interage deve fornecer suporte como serviço com um SLA claro para resolver problemas por prioridade. E não quando o administrador condicional Andrey tem um minuto para você.
Homem Gargalo
Todos em um projeto (ou produto) têm uma pessoa cuja saída de férias causa convulsões entre seus superiores? Pode ser um engenheiro, analista ou desenvolvedor Devops. Afinal, só um engenheiro devops sabe quais servidores possuem quais containers instalados, como reinicializar o container em caso de problema e, em geral, qualquer problema complexo não pode ser resolvido sem ele. O analista é o único que sabe como funciona o seu complexo mecanismo. Quais fluxos de dados vão para onde. Sob quais parâmetros de solicitações, para quais serviços, quais receberemos respostas.
Quem entenderá rapidamente por que há erros nos logs e corrigirá prontamente um bug crítico no produto? Claro, o mesmo desenvolvedor. Existem outros, mas por algum motivo só ele entende como funcionam os diferentes módulos do sistema.
A raiz deste problema é a falta de documentação. Afinal, se todos os serviços do seu sistema fossem descritos, seria possível resolver o problema sem um analista. Se o Devops tirasse alguns dias de sua agenda lotada e descrevesse todos os servidores, serviços e instruções para resolver problemas típicos, então o problema em sua ausência poderia ser resolvido sem ele. Você não precisa terminar rapidamente sua cerveja na praia durante as férias e procurar wi-fi para resolver o problema.
Competência e responsabilidade do pessoal de apoio
Em grandes projetos, as empresas não economizam nos salários dos desenvolvedores. Eles procuram pessoas intermediárias ou seniores caras de projetos semelhantes. Com o apoio a situação é um pouco diferente. Eles estão tentando reduzir esses custos de todas as maneiras possíveis. As empresas contratam trabalhadores baratos da Enikey de ontem e corajosamente vão para a batalha. Essa estratégia é possível se estivermos falando do site de cartão de visita de uma fábrica em Zelenograd.
Se estamos falando de uma grande loja online, cada hora de inatividade custa mais do que o salário mensal de um administrador Enikey. Tomemos como ponto de partida 1 bilhão de rublos de faturamento anual. Este é o faturamento mínimo de qualquer loja online da classificação . Divida esse valor pelo número de horas por ano e obtenha mais de 100 rublos de perdas líquidas. E se você não contar as horas noturnas, poderá dobrar o valor com segurança.
Mas dinheiro não é o principal, certo? (não, claro, o principal) Também há perdas de reputação. A queda de uma conhecida loja online pode causar tanto uma onda de críticas nas redes sociais quanto publicações em mídias temáticas. E as conversas dos amigos na cozinha no estilo “Não compre nada lá, o site deles está sempre fora do ar” não podem ser medidas de forma alguma.
Agora vamos à responsabilidade. Na minha prática, houve um caso em que o administrador de plantão não respondeu a tempo à notificação do sistema de monitoramento sobre a indisponibilidade do site. Em uma agradável noite de sexta-feira de verão, o site de uma conhecida loja online em Moscou estava silencioso. Na manhã de sábado, o gerente de produto deste site não entendeu porque o site não abriu, e houve silêncio nos chats de suporte e notificação urgente no Slack. Tal erro nos custou uma soma de seis dígitos, e este oficial de serviço custou-nos o emprego.
A responsabilidade é uma habilidade difícil de desenvolver. Ou uma pessoa tem ou não. Por isso, durante as entrevistas procuro identificar sua presença com diversas perguntas que mostram indiretamente se uma pessoa está acostumada a assumir responsabilidades. Se uma pessoa responder que escolheu a universidade porque seus pais mandaram ou mudou de emprego porque sua esposa disse que ele não ganha o suficiente, então é melhor não se envolver com essas pessoas.
Interação com a equipe de desenvolvimento
Quando os usuários encontram problemas simples com um produto durante a operação, o suporte os resolve por conta própria. Tenta reproduzir o problema, analisa os logs e assim por diante. Mas o que fazer quando aparece um bug no produto? Nesse caso, o suporte atribui a tarefa aos desenvolvedores e é aí que começa a diversão.
Os desenvolvedores estão constantemente sobrecarregados. Eles estão criando novos recursos. Corrigir bugs com vendas não é a atividade mais interessante. O prazo para conclusão do próximo sprint está se aproximando. E aí chegam pessoas desagradáveis do apoio e dizem: “Desistem de tudo imediatamente, estamos com problemas”. A prioridade de tais tarefas é mínima. Principalmente quando o problema não é o mais crítico e a funcionalidade principal do site funciona, e quando o gerenciador de lançamento não fica correndo com os olhos arregalados e escreve: “Adicione esta tarefa com urgência ao próximo lançamento ou hotfix”.
Problemas com prioridade normal ou baixa são movidos de uma versão para outra. À pergunta “Quando a tarefa será concluída?” você receberá respostas no estilo: “Desculpe, há muitas tarefas no momento, pergunte aos líderes de sua equipe ou ao gerente de lançamento”.
Os problemas de produtividade têm maior prioridade do que a criação de novos recursos. As críticas negativas não tardarão a chegar se os usuários constantemente se depararem com bugs. Uma reputação danificada é difícil de restaurar.
Questões de interação entre desenvolvimento e suporte são resolvidas pelo DevOps. Essa abreviatura é frequentemente usada na forma de uma pessoa específica que ajuda a criar ambientes de teste para desenvolvimento, constrói pipelines CICD e coloca rapidamente o código testado em produção. DevOps é uma abordagem de desenvolvimento de software em que todos os participantes do processo interagem estreitamente entre si e ajudam a criar e atualizar rapidamente produtos e serviços de software. Quero dizer analistas, desenvolvedores, testadores e suporte.
Nesta abordagem, suporte e desenvolvimento não são departamentos diferentes com metas e objetivos próprios. O desenvolvimento está envolvido na operação e vice-versa. A famosa frase das equipes distribuídas: “O problema não está do meu lado” não aparece mais nos chats com tanta frequência e os usuários finais ficam um pouco mais felizes.
Fonte: habr.com