Todos nós gostamos de falar sobre nossos sucessos e realmente não gostamos de falar sobre falhas. Mas a experiência de erros é geralmente mais valiosa do que o lucro de um negócio concluído com sucesso. Portanto, gostaria apenas de falar sobre esses casos hoje. Então vamos lá ...
Panela, não cozinhe!
Essa história aconteceu há alguns anos, no começo da minha carreira como desenvolvedor da 1C.
Um projeto apareceu em nossa empresa para otimizar a operação de uma base muito carregada de um cliente muito grande e respeitado. O cliente estava com um serviço de segurança tão paranóico que não havia e não podia haver nenhum acesso remoto aos servidores a partir do exterior. Para conectar-se diretamente às bases de nosso escritório, foi instalada uma rede local separada com VPN de hardware e instaladas estações de trabalho com software estritamente negociado. Claro, sem os direitos de um administrador local.
Como qualquer outro projeto desse tipo, começou com a coleta de dados. Supunha-se que primeiro coletaríamos vários indicadores dentro de um mês e, em seguida, estaríamos envolvidos na otimização da própria base de informações. Quanto e quanto tempo nesse ambiente burocrático levou para montar a MCC, isso é material para uma história separada. Mas agora, em algum momento, o MCC foi configurado e iniciado. Depois disso, o especialista que conduziu esse projeto (Dima, oi!), Entrou no seu carro de luxo e foi viajar pelo nosso vasto país e depois mais pelos países vizinhos. Mas, na verdade, eu ainda sabia pouco e sabia como, mas já era considerado um desenvolvedor responsável. Portanto, antes de partir, Dmitry me encarregou de uma tarefa muito importante e séria: 2 vezes por dia, no horário de pico de carga, tive que ir até o computador secreto e iniciar as medições no CCM e desligá-las depois de uma hora. As instruções eram extremamente simples e claras:
- Olha, você pressiona este pequeno botão verde "play", diferentes gráficos correm, você espera uma hora e depois clica neste botão - "stop". Só isso.
O que poderia ser mais fácil, certo? Em vão, estudei por 5 anos na faculdade de matemática?
Durante toda a semana, observei estritamente esse ritual de manhã e à noite. E estava tudo bem até o último dia. Depois do almoço, na sexta-feira, como sempre, comecei a coletar dados e depois ... Bem, você sabe como isso acontece ... sexta-feira à noite, precisamos terminar algumas coisas urgentes, terminar algumas tarefas, depois do trabalho levar minha esposa para minha sogra, pelo caminho cair em uma loja, uma segunda, etc. Em geral, saí do trabalho, esquecendo completamente esse mal-intencionado MCC.
Sábado de manhã começou com uma ligação. Temos TODA a base 1C no cliente. Achtung e desastre! Nosso especialista está em algum lugar entre Dzheyrakh e Pasanauri, fora da área de acesso à rede. O administrador principal do cliente também está em alguma casa de campo e inacessível. Tentando descobrir por telefone, qual o motivo? De alguma forma, o espaço em disco acabou, então o serviço do agente 1C aumentou. Aqui já comecei a suspeitar de algo ...
Como você se lembra, não há udalenka. O computador não está apenas isolado da Internet, mas também fora da nossa rede local. Nada a fazer - indo trabalhar. Enquanto se preparavam e dirigiam, os administradores perceberam que todo o lugar era ocupado pelos registros da MCC e fizeram o que julgavam mais razoável - eles o interromperam pelo gerenciador de tarefas. Vá em frente. Você não pode simplesmente excluir logs do disco - perderemos os dados de medição. De alguma forma, eles encontraram espaço suficiente no compartilhamento de rede e copiaram os arquivos lá. O trabalho parece ter sido retomado.
A manhã de domingo começou com uma ligação. Temos TODA a base 1C no cliente. Achtung e desastre levam dois! Todo o pânico acabou - o lugar acabou. Mas como assim? MCC desativado? Com pressa, vou trabalhar novamente, jogando os logs para liberar espaço. E todos crescem e crescem, amaldiçoem-nos! Sob o medo das execuções mais perversas, os administradores me proibiram de iniciar qualquer coisa ou configurar qualquer coisa. Durante o resto do domingo, eu estava sentado em frente ao computador e copiando as toras para a bola, para que as bases não se levantassem novamente.
Apenas tarde da noite, Dima entrou em contato e disse que você só precisa excluir um arquivo pequeno no servidor 1C. Mais tarde, algumas semanas depois, li sobre ele em um conhecido livro de "escrivaninha", mas naquele dia, exaustos, os torturados voltaram para casa para dormir.
Na segunda-feira de manhã, nossa conta foi bloqueada até Dmitry voltar das férias, e foi dito claramente na minha conta: "Para que não o vejamos novamente!"
Foi assim que meu primeiro projeto de otimização terminou para mim.
Duas vezes em um funil
Grande exploração. 18 bases de informações com configuração idêntica, localizadas em todo o país. A atualização ocorre uma vez por semana e é o mesmo ritual: o arquivo de entrega deve ser preparado com antecedência, carregado na nuvem, verifique se ele foi baixado em todas as filiais (mesmo em 2018 em algumas regiões a Internet é mais lenta que o típico 1C: ERP), verifique se os backups foram criados em todos os lugares (não parecemos ser responsáveis por isso, mas a experiência amarga nos ensinou a ser seguros) e, em cada filial, execute o script de atualização manualmente e verifique se ele funcionou sem erros. Freqüentemente, no último momento, descobre-se que mais uma tarefa deve ser incluída na entrega e essa é uma correção menor, porque a próxima atualização ocorre apenas em uma semana.
Então era a hora. Um desenvolvedor experiente, com muitos anos de experiência com pressa, cometeu um erro em uma linha ao transferir uma tarefa para um circuito de combate. O erro acabou sendo crítico, foi descoberto após a atualização de todos os bancos de dados.
Bem, o que fazer? O desenvolvedor corrige rapidamente o código. Não deixa ninguém testar:
- Sim, tem lixo ... Não posso errar duas vezes em uma linha?
Uma hora depois, 18 filiais foram atualizadas pela terceira vez.
Desenvolvedor que poderia
A história contada por um colega no Skype.
[Colega]: Era uma vez um desenvolvedor que podia! Ele tinha uma roupa de desenvolvimento. Ele queria abrir um teste, mas errou e abriu um processo produtivo ...
[Colega]: Mas isso poderia parar o “desenvolvedor que poderia”? Não!
[I]: E ao atualizar, ele não entendeu que havia pessoas sentadas lá, por assim dizer? )))
[Colega]: Além disso, ele vê que o konf está apoiando ... Mas você acha que isso poderia parar o “desenvolvedor que poderia”? Não!
[Colega]: Ele remove a configuração do suporte (!) E viu seu mod ignorando todos os repositórios ...
[I]: Não é isso! Termine a história, atualização dinâmica)))
[Colega]: Atualizações ... O sistema diz: “Existem 18 sessões ativas no banco de dados!”. Mas como isso poderia impedir o "desenvolvedor que poderia"? Não e não de novo!
[Colega]: Ele atualiza o banco de dados e passa a tarefa para o teste ...
[Colega]: O consultor não consegue encontrar a roupa ... e só então, depois de um longo tempo, ele percebe que perdeu.
[Colega]: Eu tive que repreendê-lo ...
[Colega]: Eu estou ligando para ele ... e estou rindo no telefone ...
[Colega]: Eu simplesmente não entendo ... COMO ???
Colapso do transporte
A história contada por um colega e registrada a partir de suas palavras.
Isso aconteceu em uma grande empresa de logística. A maioria dos processos de negócios está concentrada em uma base de informações. Usuários competitivos para 2012 - cerca de 3.000 pessoas de todas as regiões do país.
Defina uma tarefa simples. Segundo ele, ele fez seu próprio registro de informações, no qual os dados são gravados quando determinados documentos são lançados. Embora não haja muitos tipos de documentos, o número desses documentos por dia é enorme. Em teoria, a operação de gravação que adicionei ao registro não deve carregar muito o sistema. Mas havia uma nuance na implementação da tarefa - ao gravar um conjunto, a propriedade Substituir foi definida como Falso. Ou seja, cada documento contendo entradas adicionadas ao registro. Isso foi necessário de acordo com as condições do problema, mas praticamente não afetou o desempenho, porque de acordo com as condições de seleção, sempre havia 1 a 10 entradas.
O teste funcional foi bem sucedido. Realizamos várias dezenas de documentos, certificamos que as entradas no registro estavam corretas, não notamos nada de suspeito e as enviamos para o produtivo.
Naquela infeliz manhã de sexta-feira, atualizamos a base de combate e os usuários começaram a trabalhar. 3000 pessoas preencheram alegremente documentos e o registro começou a ser preenchido com dados. Depois de verificar se tudo estava indo bem, algumas horas depois voltamos para casa com uma alma calma (trabalhamos em diferentes fusos horários com os principais usuários da base de informações).
Deve-se notar que os servidores nos quais o IS estava em execução são quase um dos mais poderosos da Rússia usados em 1C. Mas depois de algumas horas "algo deu errado" (c).
Os usuários começaram a notar uma diminuição no desempenho do sistema. Todas as operações começaram a desacelerar. As respostas a quaisquer ações cresceram mais. A carga no equipamento aumentou constantemente. Enquanto o departamento de TI entendia o que estava acontecendo, o trabalho no sistema quase parou. O equipamento não aguentava, as filas nos discos eram mais longas do que nas agências dos correios da Rússia. Se o equipamento fosse mais fraco, o problema seria detectado quase imediatamente. Mas os servidores mais poderosos resistiram heroicamente às minhas mãos tortas por meio dia.
“Das palavras” do MSSQL, a solicitação mais grave de repente se tornou uma solicitação de leitura no meu registro. Embora eu não tenha feito nenhuma leitura. Um problema foi rapidamente descoberto no código 1C. Esqueci de definir seleções em um conjunto de registros. Se a propriedade "Substituir" fosse definida como "Verdadeiro", eu imediatamente encontraria um erro, porque cada entrada limparia o registro inteiro. Mas, no nosso caso, isso não aconteceu. No exemplo de uma dúzia de documentos, é claro, não percebemos nenhuma perda de desempenho. Mas quando o registro começou a se encher de dezenas e centenas de milhares de linhas - o sistema cada vez tinha que verificar o registro inteiro em busca de registros correspondentes.
Naquela época, segundo alguns usuários, já havia ocorrido um colapso no transporte, porque os carros não receberam documentos da 1C e não puderam sair dos pontos de descarga.
Então, “esquecendo” de colocar uma seleção no conjunto de registros, coloquei um dos maiores bancos de dados 1C da Rússia.
PS Veja também: