Quando os recursos do serviço em nuvem já estão se tornando escassos, e a transição para a versão em caixa é vista como o próximo passo lógico para o desenvolvimento do portal corporativo e do sistema de CRM, surge a pergunta para as empresas: como fazer isso, o que as espera e tudo será preservado após a transferência?
Parece que tudo é bem simples:
- Expanda o host com a caixa;
- Estamos escrevendo suporte técnico;
- Pedimos um backup;
- Estamos ansiosos para recebê-lo;
- Implementamos o backup e desfrutamos das amplas possibilidades da versão em caixa.
Mas a prática mostra que a transição da nuvem para a versão em caixa está longe de ser trivial e requer um plano de ação claro, análise de possíveis riscos e preparação para o fato de que tudo dará errado.
Fomos abordados por um grande desenvolvedor com um sistema CRM altamente carregado, baseado na nuvem Bitrix24. Gerentes de vendas de várias filiais da empresa trabalhavam ativamente no CRM, o portal foi integrado ao telefone IP Asterisk para criar automaticamente leads, gravar conversas com clientes e registrar fatos de chamadas no cartão de um cliente no CRM. Mais de 100 leads foram criados por dia no CRM através de vários canais.
Ficou claro que qualquer tempo simples durante a transferência para a versão em caixa ameaça o cliente com enormes perdas. Depois de conversar com o cliente sobre a seriedade da transição e os possíveis riscos, começamos a trabalhar.
Antes de tudo, analisamos os casos e publicações existentes sobre a transferência da nuvem para a caixa, fizemos uma lista de verificação detalhada dos erros que podemos encontrar:
- Os aplicativos em execução na nuvem não estão na caixa;
- O custo das licenças para aplicativos para a versão em nuvem e a caixa pode variar;
- O risco de perder alguns dados devido a um atraso de tempo durante a transferência;
- Alguns usuários de diferentes filiais continuarão a trabalhar no serviço em nuvem após a transferência e será necessário pesquisar e transferir adicionalmente as entidades que eles criaram no CRM;
- No portal fechado, o aplicativo móvel do serviço não funcionará;
- Após a transferência, alguns usuários não poderão fazer login com sua senha antiga;
- Pode haver problemas nos bots de bate-papo;
- Redefinição de autorização frequente ao trabalhar no portal;
- Somente uma parte dos comentários da tarefa pode ser exibida;
- O banco de dados ficará sem um índice de pesquisa.
Em seguida, foi compilado um algoritmo claro de ações com detalhamento por funções, que teve que ser executado pelo contratado e pelo cliente:
1 fase (meio de urgência)- Implantação do ambiente de Produção (Empreiteiro);
- Testando o ambiente implantado (Empreiteiro);
- Implantação da versão em caixa nos hosts (Contractor);
- Compra e instalação de um certificado SSL para telefonia (compra do cliente, instalação do contratante);
- Testando a versão em caixa - desempenho, parâmetros, testes internos (contratante).
- Implantação do ambiente de pré-produção - uma cópia completa da produção (contratante).
2 fases (urgência alta)- Aplicativo para descarregar backup. Coordenação com o suporte técnico do serviço da data de backup (Cliente);
- Informar os usuários sobre a data do backup e elaborar um plano para o armazenamento temporário de informações do CRM (Cliente);
- Implantação de um backup na Produção (Empreiteiro);
- Configurando o portal após o backup (Empreiteiro);
- Configurando um servidor de telefonia para trabalhar com o portal (Cliente);
- Configurando um módulo de telefonia (contratante);
- Teste inicial de telefonia (Cliente);
- Testes detalhados de CRM, telefonia, processos de negócios de CRM (departamento de vendas ao cliente);
- Declaração de Saúde. Exclusão de dados de teste (Cliente);
- Parando gerentes de vendas no serviço de nuvem (Cliente);
- Transferência de transações, leads, contatos desde o momento da criação do backup da versão em nuvem para a caixa (Empreiteiro);
- Início do trabalho dos gerentes de vendas na versão em caixa (Cliente).
Trifásico (urgência baixa)- Testando a versão em caixa dentro de 2-3 dias (Cliente);
- Aprovação de desempenho total (Cliente);
- Atualização de pré-produção - transferência de uma cópia completa da produção (contratante).
Depois de elaborar esse plano e ter uma lista de verificação com possíveis erros, percebemos que havia muitos riscos devido ao grande número de incertezas:
- Com que rapidez o serviço fornecerá backup?
- Quanto tempo leva para implantar um backup, considerando que o banco de dados do CRM é enorme?
- Com que rapidez posso reconfigurar o módulo e o servidor de telefonia para funcionar corretamente com o CRM?
- Quais erros específicos podem aparecer no portal, qual a importância deles para os usuários trabalharem e quanto tempo pode levar para corrigi-los?
Percebemos que possuímos um intervalo de tempo indeterminado, o que, à medida que aumenta, traria cada vez mais perdas ao cliente. Para minimizar o intervalo de tempo, era necessário entender quanto tempo gastamos em portar e depurar o portal.
Portanto, chegamos à conclusão de que um backup da nuvem não será suficiente e, para minimizar as perdas, é necessário implantar um backup - para identificar todos os riscos possíveis e estimar o tempo decorrido, e depois um segundo backup que poderíamos planejar de forma a minimizar as perdas. .
O Bitrix fornece apenas um backup e apenas uma vez, já que o processo de transferência da nuvem para a caixa é tecnicamente complicado. Voltando ao suporte técnico e conectando o Cliente a esse problema, ainda temos o direito de fornecer dois backups da nuvem em momentos diferentes. A hora do primeiro backup foi acordada e o trabalho de transferência começou.
Volume, velocidade e peças quebradas
Para entender quanto e o que levará tempo, começamos a manter um diário no qual registramos todas as etapas.
Portanto, o portal começou a fazer backup do serviço na quinta-feira à noite, ou seja, o CRM tinha os dados mais recentes no final da quinta-feira e nos forneceu um link para o backup na sexta-feira à tarde. Aqui enfrentamos a primeira dificuldade - o backup pesava cerca de 30 GB e a velocidade de download dos servidores Amazon.com que hospedavam a nuvem estava longe do ideal (uma média de 800 Kb / s). Depois de calcular aproximadamente o tempo durante o qual várias partes do backup foram carregadas, percebemos que, no total, levaria cerca de 10 horas para fazer o download apenas do backup.
O próximo problema foi o aparecimento de erros durante o bombeamento de várias partes do backup, que foram detectados apenas quando implantados. Como regra geral, essas partes também causavam um erro de incompatibilidade de hash, por isso era necessário identificar a parte quebrada do arquivo morto no texto do erro e transferi-la manualmente via SSH, após o que a descompactação foi reiniciada do zero por todo o backup.
Depois de baixar e implantar com êxito um backup em nossos hosts, recebemos uma cópia de trabalho da nuvem na caixa e seguimos para a próxima etapa - testando e depurando o portal.
Erros menores e empurrões e puxões traiçoeiros
Para nossa surpresa, o teste de caixa foi relativamente tranquilo. Testamos o CRM, examinamos todas as ferramentas do serviço, verificamos a funcionalidade do messenger, executamos testes internos e revelamos apenas três erros:
- O ícone de anexo de arquivo no messenger desapareceu e o envio de arquivos no messenger como um todo não funcionou;
- Os links nas notificações tinham um endereço sem domínio, por exemplo: empresa / pessoal / usuário / 1250 / tarefas / tarefa / exibição , respectivamente, não estavam funcionando;
- Alguns usuários não puderam efetuar login no portal com um erro de login / senha incorreto.
Sabíamos da incapacidade de efetuar o login após a transferência com antecedência, o serviço avisa imediatamente sobre isso ao fornecer um backup. Infelizmente, esse problema só pode ser resolvido pelos usuários que recuperam a senha ou alteram manualmente as senhas de cada usuário pelo administrador, uma vez que as senhas do Bitrix24.Network não são armazenadas no portal.
O erro com links nas notificações foi resolvido com bastante rapidez - registrando o domínio do portal nas configurações do site e nas configurações do módulo principal.
Mas o ícone de anexo de arquivo ausente no messenger trouxe algumas preocupações. A tarefa levou mais algumas horas de tentativas frustradas de entender o motivo do ícone ausente. Como resultado, descobrimos que o motivo estava longe de estar no módulo de disco, como era suposto originalmente. O motivo estava no servidor push desconectado nas configurações do módulo push & pull, que desativou automaticamente a transferência de arquivos no messenger.
Teste final
Após testes e depuração bem-sucedidos do portal, um relatório detalhado foi preparado para o Cliente e a próxima etapa foi um teste completo pelo departamento de vendas do Cliente CRM, além de configurar o servidor de telefonia para trabalhar com a caixa e fazer chamadas de teste.
Durante o teste, problemas significativos não foram identificados. Implementamos um host de teste e rolamos nele uma cópia completa do portal de combate, caso tivéssemos uma versão 100% funcional do portal e de acordo com a qual poderíamos fazer uma comparação nas configurações se ocorrerem erros não padrão que não foram detectados ao testar o primeiro backup.
Após a implantação de uma cópia do portal, procedemos à análise do diário, na qual corrigimos os erros e o tempo para resolvê-los. Após analisar a revista em detalhes, atualizamos o plano de transferência do segundo backup, percebemos o quanto podemos perder leads durante a transferência final e reservamos um tempo adicional para a importação manual de leads perdidos da versão em nuvem. Todos os detalhes e riscos também foram discutidos com o Cliente e uma carta foi enviada ao suporte técnico do serviço com uma solicitação para preparar um segundo backup.
Segundo backup e por que tudo pode dar errado?
Depois de concordarmos com o horário de criação do backup também na quinta-feira, preparamos a equipe para ações operacionais às 12 horas de sexta-feira. No período de 12 a 13 horas, recebemos o aguardado link e começamos o download. Poucas horas depois, ficou claro que o arquivo não seria liberado por 10 horas, mas cerca de 14! A largura de banda do canal de nossos provedores e servidores Amazon.com neste dia deixou muito a desejar. Estávamos nos preparando para o trabalho noturno, pois os leads continuavam caindo e o Cliente aguardava um relatório para começar a configurar o servidor de telefonia.
Como costuma acontecer, nem tudo correu conforme o planejado. O próximo passo foi transferir os leads acumulados da versão em nuvem para a caixa - o processo é simples e claro, mas tem suas próprias nuances. Se, na lista de leads, você selecionar os leads que precisam ser exportados e clicar em "Exportar para CSV", todos os leads existentes no CRM serão descarregados, não apenas os selecionados. É lógico que, com um grande banco de dados de leads, a nuvem tenha caído em erro. A solução foi usar um filtro, apenas nesse caso os terminais foram descarregados corretamente.
Mais testes passaram sem surpresas, como já sabíamos: o que não funcionará, como corrigi-lo e onde. Tendo conectado e testado com sucesso a telefonia, na segunda-feira os gerentes de vendas já trabalhavam totalmente com o CRM na versão in a box. E já em funcionamento por uma semana, ajustamos o portal, fizemos backup e fizemos uma cópia final do portal no host de teste.
Todo o processo de transferência levou cerca de uma semana de trabalho desde o momento do planejamento até as configurações finais.
Como resultado, gostaria de observar a importância de planejar projetos tão complexos e arriscados, o envolvimento obrigatório do Cliente no processo e expressar possíveis riscos, embora, como mostra a prática, os desvios do plano não sejam exceção.