Olá Habr! Por dez anos, apoio os sistemas de TI Highload. Não vou escrever neste artigo sobre os problemas de configuração do nginx para funcionar no modo 1000 RPS ou outras coisas técnicas. Compartilharei observações sobre problemas nos processos que surgem no suporte e operação de tais sistemas.
Monitoramento
O suporte técnico não espera até que um aplicativo chegue com o conteúdo "
Por que
por que ... o site está inoperante novamente?". O suporte um minuto após a falha do site já deve ver o problema e começar a resolvê-lo.
Mas o site é a ponta do iceberg . Sua disponibilidade é uma das primeiras a ser monitorada.
E a situação em que os restos dos produtos da loja on-line deixaram de vir do sistema ERP? Ou o sistema de CRM que calcula descontos para clientes parou de responder? Ao mesmo tempo, o site está funcionando. O Zabbix condicional recebe sua resposta de 200. A mudança de plantão não recebeu nenhuma notificação do monitoramento e inspeciona com alegria o primeiro episódio da nova temporada de Game of Thrones.
Freqüentemente, o monitoramento é limitado apenas medindo o estado da memória, RAM e a carga dos processadores do servidor. Mas é muito mais importante para uma empresa obter a disponibilidade do produto em um site. Uma queda condicional de uma máquina virtual no cluster fará com que o tráfego pare de fluir para ela e a carga em outros servidores aumentará. A empresa não vai perder dinheiro.
Portanto, além de monitorar os parâmetros técnicos dos sistemas operacionais nos servidores, você precisa configurar as 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 um volume de negócios anual de mais de um bilhão de rublos interage com sistemas externos. Começando pelo mencionado CRM e ERP e terminando com a transferência de dados de vendas para um sistema externo de Big Data para analisar compras e oferecer ao cliente o produto que ele definitivamente 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 você precisa analisá-lo em diferentes sistemas.
Alguns sistemas entregam o telefone ou telegrama aos seus administradores. Em algum lugar, você precisa escrever cartas para os gerentes ou acessar os rastreadores de erros desses sistemas externos. Mesmo no contexto de uma grande empresa, sistemas diferentes geralmente funcionam em diferentes sistemas de contabilidade de aplicativos. Às vezes, torna-se impossível rastrear o status de um aplicativo. Você recebe um aplicativo em um Jira condicional. Em seguida, nos comentários deste primeiro Jira, você coloca um link para a tarefa em outro Jira. No segundo Jira no aplicativo, alguém já escreve um comentário que
você precisa chamar o administrador condicional Andrei para resolver o problema. E assim por diante
A melhor solução para esse problema seria criar um único espaço para comunicação, por exemplo, no Slack. Convite para todos os participantes na operação de sistemas externos. Assim como um único rastreador, para não duplicar aplicativos. Os aplicativos devem ser monitorados em um único local, começando do monitoramento de alertas e exibindo erros nos produtos. Você dirá que isso não é realista e, historicamente, aconteceu que trabalhamos em um rastreador, e eles estão em outro. Apareceram sistemas diferentes, eles tinham suas próprias equipes de TI autônomas. 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
Todo mundo no projeto (ou produto) tem uma pessoa cuja partida de férias causa cãibras nas autoridades? Pode ser um engenheiro, analista ou desenvolvedor de devops. Afinal, apenas um engenheiro de devops sabe quais contêineres estão instalados em quais servidores, como recarregar o contêiner em caso de um problema e, de fato, qualquer problema complexo não pode ser resolvido sem ele. O analista é o único que sabe como seu mecanismo complexo funciona. Quais fluxos de dados vão para onde. Em quais parâmetros de solicitações a quais serviços, quais receberemos respostas.
Quem entenderá rapidamente por que há erros nos logs e corrigirá rapidamente um bug crítico no prod? Claro que o mesmo desenvolvedor. Existem outros, mas, por alguma razão, apenas ele entende como os vários módulos do sistema são organizados.
A raiz desse problema é a falta de documentação . Afinal, se todos os serviços do seu sistema fossem descritos, seria possível lidar com o problema sem um analista. Se os devops selecionarem alguns dias de sua agenda ocupada e descreverem todos os servidores, serviços e instruções para resolver problemas típicos, um problema em sua ausência poderá ser resolvido sem ele. Não há necessidade de férias para terminar rapidamente sua cerveja na praia e procurar wi-fi para resolver o problema.
Competência e responsabilidade da equipe de suporte
Em grandes projetos, as empresas não economizam salários para os desenvolvedores. Eles caçam intermediários ou idosos caros de projetos semelhantes. Com o apoio, a situação é um pouco diferente. Eles estão tentando de todas as formas reduzir esses custos. As empresas estão contratando o enikeyshikov de baixo custo de ontem e corajosamente entram em batalha. Essa estratégia é possível quando se trata de um site de cartões de visita de alguma fábrica em Zelenograd.
Se estamos falando de uma grande loja on-line, cada hora de inatividade custa mais do que o salário mensal de um administrador-enikeik. Tome como ponto de partida 1 bilhão de rublos de faturamento anual. Esta é a rotatividade mínima de qualquer loja on-line da classificação
TOP-100 de 2018 . Divida essa quantidade pelo número de horas por ano e obtenha mais de 100.000 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 é a principal coisa, é? (não, claro que a principal) Ainda há perdas de reputação. A hora do outono da conhecida loja online pode causar uma onda de críticas nas redes sociais e publicações na mídia temática. E as conversas de amigos na cozinha no estilo de "Não compre nada lá, o site delas está constantemente desativado" não se prestam a nenhuma medida.
Agora responsável. Na minha prática, houve um caso em que o administrador de plantão não respondeu a tempo de notificar o sistema de monitoramento sobre a inacessibilidade do site. Em um agradável verão na sexta-feira à noite, o site de uma conhecida loja on-line em Moscou estava em silêncio. Na manhã de sábado, o produto deste site não entendeu por que o site não foi aberto e houve silêncio nas conversas de suporte e alertas urgentes no Slack. Tal erro nos custou uma soma de seis dígitos, e esse oficial de serviço trabalhou.
Responsabilidade é uma habilidade difícil de desenvolver. Uma pessoa tem ou não. Portanto, nas entrevistas, tento identificar sua presença com várias perguntas que indiretamente mostram se uma pessoa está acostumada a assumir responsabilidades. Se uma pessoa responde que escolheu uma universidade porque seus pais o disseram ou muda de emprego porque sua esposa disse que ele não recebe muito, então é melhor não se envolver com essas pessoas.
Interação com a equipe de desenvolvimento
Quando os usuários experimentam problemas simples no produto durante a operação, o suporte os resolve por conta própria. Ele tenta reproduzir o problema, analisa os logs e assim por diante. Mas o que fazer quando um bug aparece no prod? Nesse caso, o suporte inicia a tarefa para os desenvolvedores, e aqui começa a diversão.
Os desenvolvedores estão constantemente sobrecarregados. Eles estão criando novos recursos. Corrija os bugs com uma lição de venda, não diga a mais interessante. Os prazos para a conclusão do próximo sprint estão em vigor. E então pessoas desagradáveis vêm do apoio e dizem: "Urgir tudo, temos problemas". A prioridade de tais tarefas é mínima. Especialmente quando o problema não é o mais crítico e a principal funcionalidade do site funciona, e quando o gerenciador de versões não roda com os olhos esbugalhados e não escreve: "Urgente levar esta tarefa para a próxima versão ou hotfix".
As tarefas com prioridade normal ou baixa passam de release para release. Para a pergunta "Quando a tarefa será concluída?" Você receberá respostas no estilo de: "Sinto muito, agora existem muitas tarefas, pergunte aos líderes da equipe ou a um gerente de lançamento".
Problemas no produto têm uma prioridade mais alta do que a criação de novos recursos. As críticas negativas não o farão esperar se os usuários encontrarem bugs constantemente. É difícil restaurar uma reputação danificada.
Problemas de interação entre desenvolvimento e suporte são resolvidos pelo DevOps. Essa abreviação é frequentemente usada como uma pessoa específica que ajuda a criar ambientes de teste para desenvolvimento, cria pipelines de CI / CD e exibe rapidamente o código testado em produção. O DevOps é uma abordagem para o desenvolvimento de software quando 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.
Suporte e desenvolvimento nessa abordagem não são departamentos diferentes com suas metas e objetivos. O desenvolvimento está envolvido na operação e vice-versa. A famosa frase de equipes distribuídas: “O problema não está do meu lado” não é tão comum nas salas de bate-papo, e os usuários finais ficam um pouco mais felizes.