O fator tempo - a pontualidade da execução de ordens, trabalho, acordos - é importante nos negócios. Clientes e parceiros esperam colaboração previsível e demorada. Em um negócio tradicional, isso é influenciado pelo trabalho dos funcionários, pelas ações dos fornecedores, pela localização geográfica da empresa, pela condição do equipamento e muito mais. Localizar e controlar tudo isso é uma tarefa difícil.
Um pouco mais claro, tudo está no campo da TI. Uma parte significativa dos processos pode ser automatizada e confiada a um programa ou script. Melhor ainda, se o produto for implementado como um serviço da Web - a principal lição é apoiar a disponibilidade e o desenvolvimento do produto.
Um dos principais produtos da nossa empresa é um serviço da web. Tudo começou com a implementação da ideia de duas pessoas, depois a empresa cresceu: PM (ele também é programador da Web), programador de banco de dados, administrador de sistemas (com pouca experiência de desenvolvedor), testador e duas outras pessoas envolvidas em vendas e SEO. O sistema é implementado como uma interface da web e um banco de dados relacionado. A utilização do serviço envolve depositar e retirar dinheiro armazenado em uma "moeda virtual". Por segurança, o servidor da Web e o banco de dados são implantados em seus servidores.
Como o serviço está conectado ao dinheiro, o nível de confiança do usuário no sistema é importante. Antes de tudo, é uma questão de segurança e proteção do sistema contra hackers. No entanto, é difícil para um cliente comum (especialmente não versado nos meandros da TI, protocolos seguros e criptografia) avaliar o nível de segurança do sistema. Se uma situação negativa (hacking) não ocorreu, o trabalho não é visível.
A acessibilidade do sistema é mais óbvia para o cliente: se o usuário transferiu uma certa quantia para a conta virtual e não conseguiu fazer login no site várias vezes, a credibilidade do sistema é prejudicada e o cliente provavelmente está perdido (às vezes várias ao mesmo tempo - o negativo se espalha rapidamente). E é improvável que os usuários envolvidos com grande dificuldade, encontrando um erro em vez da página principal do site, retornem também.
Compreender a seriedade disso não veio imediatamente. No início, o número de usuários era pequeno, as capacidades do servidor e do canal eram abundantes e, portanto, as "falhas" eram raras. Além disso, a princípio, a funcionalidade era frequentemente testada e refinada para fins de otimização, e o próprio desenvolvedor era responsável por monitorar os servidores associados ao serviço durante o horário de trabalho. O número de usuários fora do horário de expediente era relativamente pequeno - os clientes de outros fusos horários estavam praticamente ausentes na época.
Gradualmente, a parte principal do serviço foi concluída. As melhorias ficaram pequenas e, portanto, a atenção principal dos desenvolvedores foi mudada para outro projeto. A responsabilidade de controlar o sistema foi transferida para o administrador do sistema, além de outras responsabilidades. As notificações foram enviadas por email e SMS ao administrador no caso de uma falha no servidor. Tais medidas naquele momento pareciam suficientes.
O produto começou a ganhar impulso e o número de usuários aumentou. Novas idéias surgiram, algumas foram implementadas imediatamente, outras foram adiadas para o futuro. O serviço foi traduzido para outros idiomas e gradualmente entrou em novos mercados, o que, entre outros fatores, levou a um aumento no número de usuários à noite. A carga do servidor estava aumentando gradualmente, embora ainda estivesse longe do limite técnico do ferro.
Uma vez que a calma chegou ao fim. Na noite de sexta a sábado, os usuários começaram a ter problemas para acessar a página principal do site, eles eram frequentemente encontrados pelo erro 503. O problema não foi difícil, mas, como deveria, o administrador não estava disponível na noite de sexta-feira e, portanto, o SMS permaneceu não lido. No entanto, o problema foi resolvido de forma relativamente indolor. O desenvolvedor também recebeu um SMS e conseguiu passar e ativar o administrador e, após 3 horas, o problema foi resolvido. O tempo total de inatividade foi de 5 horas.
Na segunda-feira, houve uma análise do que aconteceu. A análise dos dados de tráfego do site mostrou uma imagem desagradável - em uma sexta-feira “problemática”, o tráfego diminuiu um terço em relação ao ano passado, mas quedas significativas no sábado e domingo foram ainda mais desagradáveis, apesar da ausência de problemas técnicos nos dias de hoje, o tráfego caiu 15%.
Isso reforçou o entendimento da necessidade de monitoramento 24 horas. Do ponto de vista do software, escolhemos o
Zabbix , que deveria ser instalado e configurado pelo administrador do sistema. Demorou cerca de uma semana - o restante das tarefas não foi a lugar nenhum e tudo foi feito em paralelo. Havia uma pergunta organizacional - quem exatamente monitorará?
No começo, eu tive que tomar essa decisão - mudar o horário de trabalho dos funcionários existentes (daqueles que entenderam isso - ou seja, o administrador e o desenvolvedor do sistema) para que um por um alguém controlasse o servidor à noite.
Esta foi uma decisão forçada e não durou muito. Em primeiro lugar, o trabalho de duas pessoas ainda não fornece controle 24 horas por dia - existem lacunas no tempo em que uma falha também é provável. Em segundo lugar, poucas pessoas gostam de trabalhar à noite e a insatisfação aumentou, além disso, a distração do programador quase interrompeu o próprio desenvolvimento. Portanto, depois de uma semana, abandonaram a ideia e começaram a pensar mais.
Contratação de pessoal adicional para monitorarObviamente, essa decisão é a mais intransigente - o controle constante das pessoas selecionadas fornece um bom resultado. Mas trabalhar nesse modo exigiria uma busca por mais 3 administradores de sistema. Além disso, eles devem ser qualificados o suficiente para resolver problemas, mas a maior parte do tempo seria desperdiçada de qualquer maneira - a empresa é pequena, há poucos servidores e não haveria quase nada para ocupá-los. Além disso, muitas pessoas também precisam ser controladas, o que seria uma dor de cabeça adicional.
Ambas as opções não funcionaram. Não foi possível concentrar esforços e meios neles. Mas a necessidade de monitoramento não desapareceu. Esse é um dos problemas do crescimento - existe uma necessidade que não pode ser realizada por conta própria. Como solução, chegamos a uma terceirização.
Durante a transição, surgiram dúvidas, sendo a principal a segurança e a confidencialidade das informações que se tornam disponíveis para outra pessoa e a qualidade do serviço, não será pior, pelo contrário? Mas é mais uma questão de encontrar um executor responsável e assinar um NDA.
Então, seguimos em frente, do lado técnico não foi difícil. Um mês depois, decidimos verificar como as coisas estavam indo - verificando os logs nos servidores. Estamos satisfeitos com os resultados - no mês houve três falhas graves que poderiam "colocar" o servidor novamente, mas os parceiros resolveram os problemas em meia hora. Além disso, todas as falhas ocorreram no intervalo de uma da manhã às quatro da manhã - um crescimento geográfico gradual do produto afetado.
O trabalho do administrador do sistema mudou e ficou mais calmo. Sem se distrair com o monitoramento, ele se concentrou no DevOps. Concentramos nossos esforços e o desenvolvimento acelerado. Acabou por perceber o que foi adiado por um longo tempo, graças ao nosso
parceiro .