Olá, Habr! Há dez anos eu apoio sistemas de TI Highload. Não vou escrever nesta artigo sobre os problemas de configuração do nginx para operar em modo de 1000+ RPS ou outras questões técnicas. Vou compartilhar observações sobre problemas nos processos que surgem no suporte e na operação de tais sistemas.
Monitoramento
O suporte técnico não espera até que um pedido chegue com o conteúdo "Por que... o site está fora do ar novamente?". O suporte já deve ver o problema um minuto após a queda do site e começar a resolvê-lo. Mas o site é apenas a ponta do iceberg.A sua disponibilidade é monitorada como uma das primeiras.
Como lidar com a situação em que os estoques de produtos de uma loja online deixaram de vir do sistema ERP? Ou o sistema CRM, que calcula descontos para os clientes, parou de responder? O site, por sua vez, parece estar funcionando. O Zabbix recebe sua resposta 200. A equipe de plantão não recebeu notificações de monitoramento e felizmente continua assistindo ao primeiro episódio da nova temporada de "Game of Thrones."
Frequentemente, o monitoramento se limita apenas à medição do estado de memória, RAM e carga dos processadores. servidores. Mas para os negócios, é muito mais importante ter a disponibilidade dos produtos no site. A queda de uma máquina virtual em um cluster levará ao fim do tráfego para ela e aumentará a carga em outros servidores. A empresa não perderá dinheiro.
Portanto, além do monitoramento de parâmetros técnicos dos sistemas operacionais nos servidores, é necessário configurar métricas de negócios. Métricas que impactam diretamente o dinheiro. Diversas interações com sistemas externos (CRM, ERP, entre outros). O número de pedidos em um determinado intervalo de tempo. Autenticações de clientes bem-sucedidas ou não, e outras métricas.
Interação com sistemas externos.
Qualquer site ou aplicativo móvel com um faturamento anual superior a um bilhão de rublos interage com sistemas externos. Começando pelos CRM e ERP mencionados acima, e terminando com a transferência de dados de vendas para um sistema de análise de Big Data externo e a 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. Especialmente quando o problema é global e precisa ser analisado em diferentes sistemas.
Alguns sistemas fornecem o telefone ou o Telegram de seus administradores. Em outros casos, é necessário escrever e-mails para os gerentes ou recorrer a rastreadores de bugs desses sistemas externos. Mesmo dentro de uma grande empresa, diferentes sistemas frequentemente operam em diferentes plataformas de gestão de solicitações. Rastrear o status de uma solicitação às vezes se torna impossível. Você recebe uma solicitação em um Jira hipotético. Depois, nos comentários desse primeiro Jira, coloca um link para a tarefa em outro Jira. No segundo Jira, alguém já escreve um comentário dizendo que é necessário ligar para o administrador hipotético André para resolver a questão. E assim por diante.
A solução ideal para esse problema seria criar um espaço único de comunicação, por exemplo, no Slack. Convidar todos os participantes do processo de operação dos sistemas externos. E também um rastreador único, para evitar a duplicação de solicitações. As solicitações devem ser rastreadas em um único lugar, desde o alerta de monitoramento até a resolução de bugs em produção. Você dirá que isso é irreal e que, historicamente, vocês trabalham em um rastreador enquanto eles trabalham em outro. Surgiram diferentes sistemas, cada um com suas equipes de TI autônomas. Concordo e, portanto, o problema deve ser abordado a nível de CIO ou product owner.
Cada sistema com o qual você interage deve oferecer suporte como um serviço, com um SLA claro para a resolução de problemas por prioridades. E não quando o administrador hipotético André tiver um tempinho para você.
A pessoa-gargalo
Há alguém no projeto (ou produto) cuja ausência temporária causa nervosismo na gestão? Pode ser um engenheiro devops, um analista ou um desenvolvedor. Afinal, apenas o engenheiro devops sabe em quais servidores estão instalados quais contêineres, como reiniciar um contêiner em caso de problemas e, de fato, qualquer problema complexo não é resolvido sem ele. O analista é o único que sabe como funciona o seu mecanismo complexo. Quais fluxos de dados estão indo para onde. Com quais parâmetros as solicitações são feitas a quais serviços, quais respostas receberemos.
Quem entenderá rapidamente por que há erros nos logs e consertará o bug crítico em produção de forma ágil? Certamente, é o desenvolvedor que entende como estão estruturados os diferentes módulos do sistema.
A raiz desse problema é a falta de documentação.Se todos os serviços do seu sistema fossem descritos, seria possível resolver o problema sem um analista. Se o devops liberasse alguns dias de sua agenda lotada e escrevesse sobre todos os servidores, serviços e instruções para resolver problemas comuns, a questão da sua ausência poderia ser solucionada sem ele. Não é necessário correr para terminar sua cerveja na praia durante as férias e procurar wi-fi para resolver um problema.
Competência e responsabilidade dos funcionários de suporte
Em grandes projetos, as empresas não economizam nos salários dos desenvolvedores. Elas recrutam caras profissionais intermediários ou seniores de projetos semelhantes. A situação com o suporte é um pouco diferente. Esses custos são cortados ao máximo. As empresas contratam técnicos inexperientes e vão para a batalha. Essa estratégia é viável se falarmos de um site de visita de alguma fábrica em Zelenograd.
Se falamos de uma grande loja online, cada hora de inatividade custa mais do que o salário mensal de um técnico de suporte. Consideremos como referência um volume de negócios anual de 1 bilhão de rublos. Este é o faturamento mínimo de qualquer loja online no ranking. . Dividindo esse valor pelo número de horas no ano, obtemos mais de 100.000 rublos em perdas líquidas. E se não contarmos as horas noturnas, podemos facilmente dobrar essa quantia.
Mas dinheiro não é o mais importante, certo? (não, claro que é o mais importante) Também existem perdas reputacionais. Uma hora de queda de uma conhecida loja online pode gerar uma onda de comentários nas redes sociais e publicações na mídia especializada. E conversas entre amigos na cozinha do tipo "Não compre nada lá, o site deles está sempre fora do ar" são imensuráveis.
Agora, sobre a responsabilidade. Em minha experiência, houve um caso em que o administrador de plantão não reagiu a tempo ao alerta 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 Moscovo estava inativo. Na manhã de sábado, o gerente desse site não entendeu por que o site não abria, e nos chats de suporte e alertas urgentes no Slack reinava o silêncio. Esse erro nos custou uma quantia de seis dígitos, e ao responsável trabalhos.
Responsabilidade é uma habilidade que é difícil de desenvolver. Ele ou uma pessoa tem, ou não. Portanto, em entrevistas, eu tento identificar a sua presença com várias perguntas que mostram indiretamente se a pessoa está acostumada a assumir responsabilidades. Se a pessoa responde que escolheu a faculdade porque seus pais disseram ou muda de emprego porque a esposa disse que ele ganha pouco, é melhor não se envolver com essas pessoas.
Interação com a equipe de desenvolvimento
Quando surgem problemas simples durante a operação em produção com os usuários, o suporte os resolve por conta própria. Eles tentam reproduzir o problema, analisam os registros e assim por diante. Mas o que fazer quando um bug aparece em produção? Nesse caso, o suporte abre uma tarefa para os desenvolvedores e é aqui que a coisa fica interessante.
Os desenvolvedores estão constantemente sobrecarregados. Eles estão focados na criação de novas funcionalidades. Corrigir bugs em produção não é, digamos, a tarefa mais interessante. Os prazos para concluir mais um sprint estão apertados. E aqui vêm pessoas desagradáveis do suporte e dizem: 'Pare tudo, temos problemas'. A prioridade dessas tarefas é mínima. Especialmente quando o problema não é crítico e a funcionalidade principal do site está operando, e quando o gerente de lançamento não corre com olhos arregalados e não escreve: 'Precisamos incluir essa tarefa no próximo lançamento ou hotfix imediatamente'.
Tarefas com prioridade normal ou baixa são adiadas de lançamento para lançamento. Ao perguntar 'Quando a tarefa estará concluída?', você receberá respostas como: 'Desculpe, agora temos muitas tarefas, pergunte aos líderes de equipe ou ao gerente de lançamento'.
Problemas em produção têm maior prioridade do que a criação de novas funcionalidades. Críticas negativas não tardarão a chegar se os usuários estiverem constantemente encontrando bugs. Reputação arruinada é difícil de recuperar.
A questão da interação entre desenvolvimento e suporte é resolvida pelo DevOps. Essa abreviação é frequentemente usada para se referir a uma pessoa específica que ajuda a criar ambientes de teste para desenvolvimento, constrói pipelines de CICD e rapidamente coloca o código testado em produção. DevOps é uma abordagem ao desenvolvimento de software em que todos os participantes do processo colaboram de perto e ajudam a criar e atualizar produtos e serviços de software mais rapidamente. Refiro-me a analistas, desenvolvedores, testadores e suporte.
O suporte e o desenvolvimento nesse modelo não são departamentos distintos com seus próprios objetivos e metas. O desenvolvimento está integrado à operação e vice-versa. A famosa frase de equipes distribuídas: "O problema não é do meu lado" já não aparece com tanta frequência nos chats, e os usuários finais se tornam um pouco mais felizes.
Fonte: habr.com
