Todos os desenvolvedores 1C, de uma forma ou de outra, interagem estreitamente com os serviços de TI e diretamente com os administradores do sistema. Mas essa interação nem sempre ocorre de maneira tranquila. Eu gostaria de contar algumas histórias engraçadas sobre isso.
Canal de comunicação de alta velocidade
A maioria de nossos clientes são grandes holdings com seus próprios grandes departamentos de TI. E os especialistas do cliente geralmente são responsáveis pelas cópias de backup dos bancos de dados de informações. Mas também existem organizações relativamente pequenas. Especialmente para eles, temos um serviço segundo o qual assumimos todas as questões relacionadas com o backup de tudo 1C. É dessa empresa que falaremos nesta história.
Um novo cliente veio dar suporte a 1C e, entre outras coisas, o contrato incluía uma cláusula de que éramos responsáveis pelos backups, embora eles tivessem seu próprio administrador de sistema na equipe. Banco de dados cliente-servidor, MS SQL como SGBD. Uma situação bastante normal, mas ainda havia uma ressalva: a base principal era bastante grande, mas o aumento mensal era muito pequeno. Ou seja, o banco de dados continha muitos dados históricos. Levando em conta essa característica, montei planos de manutenção de backup da seguinte forma: no primeiro sábado de cada mês era feito um backup completo, era bastante pesado, depois era feita uma cópia diferencial todas as noites - um volume relativamente pequeno, e uma cópia do log de transações a cada hora. Além disso, cópias completas e diferenciais não foram apenas copiadas para um recurso de rede, mas também carregadas adicionalmente em nosso servidor FTP. Este é um requisito obrigatório na prestação deste serviço.
Tudo isso foi configurado com sucesso, colocado em operação e geralmente funcionou sem falhas.
Mas, alguns meses depois, o administrador do sistema nesta organização mudou. O novo administrador de sistema começou a reconstruir gradualmente a infraestrutura de TI da empresa de acordo com as tendências modernas. Em particular, apareceu a virtualização, prateleiras de disco, o acesso foi bloqueado em todos os lugares e em tudo, etc., o que no caso geral, é claro, não pode deixar de alegrar-se. Mas as coisas nem sempre correram bem para ele; muitas vezes havia problemas com o desempenho do 1C, o que causava algumas divergências e mal-entendidos com o nosso suporte. Além disso, deve-se notar que nosso relacionamento com ele era geralmente bastante frio e um tanto tenso, o que só aumentava o grau de tensão no caso de surgir algum problema.
Mas uma manhã descobriu-se que o servidor deste cliente não estava disponível. Liguei para o administrador do sistema para saber o que aconteceu e recebi como resposta algo como “Nosso servidor travou, estamos trabalhando nisso, não depende de você”. Bem, é bom que eles funcionem. Isso significa que a situação está sob controle. Depois do almoço, ligo novamente e, em vez de irritação, já sinto cansaço e apatia na voz do administrador. Estou tentando descobrir o que aconteceu e há algo que possamos fazer para ajudar? Como resultado da conversa, surgiu o seguinte:
Ele mudou o servidor para um novo sistema de armazenamento com um ataque recém-montado. Mas algo deu errado e alguns dias depois esse ataque fracassou com segurança. Se o controlador queimou ou algo aconteceu com os discos, não me lembro exatamente, mas todas as informações foram irremediavelmente perdidas. E o principal é que o recurso de rede com backups também acabou no mesmo array de discos durante várias migrações. Ou seja, tanto o próprio banco de dados produtivo quanto todas as suas cópias de backup foram perdidas. E não está claro o que fazer agora.
Acalme-se, eu digo. Temos seu backup noturno. Em resposta, houve um silêncio, pelo qual percebi que tinha acabado de salvar a vida de um homem. Começamos a discutir como transferir esta cópia para um servidor novo e recém-implantado. Mas também aqui surgiu um problema.
Lembra quando eu disse que o backup completo era bem grande? Não foi à toa que fiz isso uma vez por mês, aos sábados. O fato é que a empresa era uma fábrica pequena, que ficava bem fora da cidade e a Internet deles era muito razoável. Na manhã de segunda-feira, ou seja, no fim de semana, esta cópia mal conseguiu ser carregada em nosso servidor FTP. Mas não havia como esperar um ou dois dias para que carregasse na direção oposta. Após várias tentativas frustradas de transferência do arquivo, o administrador retirou o disco rígido diretamente do novo servidor, encontrou um carro com motorista em algum lugar e rapidamente correu para nosso escritório, felizmente ainda estamos na mesma cidade.
Enquanto eles estavam em nossa sala de servidores esperando a cópia dos arquivos, nos encontramos pela primeira vez, por assim dizer, “pessoalmente”, tomamos uma xícara de café e conversamos em um ambiente informal. Simpatizei com sua dor e mandei-o de volta com uma pilha completa de backups, restaurando às pressas o trabalho interrompido da empresa.
Posteriormente, todos os nossos pedidos ao departamento de TI foram resolvidos muito rapidamente e não surgiram mais divergências.
Entre em contato com o administrador do sistema
Certa vez, por muito tempo, não consegui publicar 1C para acesso web via IIS para um cliente. Parecia uma tarefa comum, mas não havia como fazer tudo funcionar. Os administradores de sistema locais se envolveram e testaram diferentes configurações e arquivos de configuração. 1C na web normalmente não queria funcionar de forma alguma. Algo estava errado, seja com as políticas de segurança de domínio, ou com o sofisticado firewall local, ou Deus sabe o que mais. Na enésima iteração, o administrador me envia um link com as palavras:
- Tente novamente seguindo estas instruções. Tudo está descrito lá com bastante detalhe. Se não funcionar, escreva para o autor deste site, talvez ele possa ajudar.
“Não”, eu digo, “não vai ajudar”.
- Por que não?
— Eu sou o autor deste site... (
Como resultado, lançamos no Apache sem problemas. O IIS nunca foi derrotado.
Um nível mais profundo
Tínhamos um cliente - uma pequena empresa manufatureira. Eles tinham um servidor, uma espécie de 3 em 1 “clássico”: servidor de terminal + servidor de aplicação + servidor de banco de dados. Eles trabalhavam em alguma configuração específica do setor baseada em UPP, havia cerca de 15 a 20 usuários e o desempenho do sistema, em princípio, agradava a todos.
Com o passar do tempo, tudo funcionou de forma mais ou menos estável. Mas então a Europa impôs sanções contra a Rússia, e como resultado os russos começaram a comprar principalmente produtos produzidos internamente, e os negócios desta empresa aumentaram drasticamente. O número de usuários aumentou para 50-60 pessoas, uma nova filial foi aberta e o fluxo de documentos aumentou proporcionalmente. E agora o servidor atual não conseguia mais lidar com o aumento acentuado da carga, e 1C começou, como dizem, a “desacelerar”. Nos horários de pico, os documentos eram processados por vários minutos, ocorriam erros de bloqueio, os formulários demoravam muito para abrir e todo o outro conjunto de serviços relacionados. O administrador do sistema local ignorou todos os problemas, dizendo: “Este é o seu 1C, você vai descobrir”. Propusemos repetidamente a realização de uma auditoria de desempenho do sistema, mas nunca chegou à auditoria em si. O cliente simplesmente pediu recomendações sobre como resolver problemas.
Bem, sentei-me e escrevi uma carta bastante longa sobre a necessidade de separar as funções do servidor de terminal e do servidor de aplicativos com o SGBD (o que, em princípio, já dissemos muitas vezes antes). Escrevi sobre DFSS em servidores de terminal, sobre memória compartilhada, forneci links para fontes confiáveis e até sugeri algumas opções de equipamentos. Esta carta chegou aos detentores do poder na empresa, voltou ao departamento de TI com as resoluções “Implementar” e o gelo foi geralmente quebrado.
Depois de algum tempo, o administrador me envia o endereço IP do novo servidor e as credenciais de login. Ele diz que lá estão implantados componentes do servidor MS SQL e 1C, e os bancos de dados precisam ser transferidos, mas por enquanto apenas para o servidor SGBD, pois surgiram alguns problemas com as chaves 1C.
Entrei, sim, todos os serviços estavam rodando, o servidor não era muito potente, mas ok, acho que é melhor que nada. Vou transferir os bancos de dados por enquanto para aliviar de alguma forma o servidor atual. Concluí todas as transferências no prazo combinado, mas a situação não mudou - continuam os mesmos problemas de desempenho. É estranho, claro, bem, vamos registrar os bancos de dados no cluster 1C e veremos.
Vários dias se passam, as chaves não foram transferidas. Estou me perguntando qual é o problema, tudo parece simples - retire de um servidor, conecte em outro, instale o driver e pronto. O administrador responde agitado e dizendo algo sobre encaminhamento de porta, um servidor virtual e assim por diante.
Hmm... Servidor virtual? Parece que nunca houve virtualização e nunca houve... Lembro-me de um problema bastante conhecido com a impossibilidade de encaminhar uma chave de servidor 1C para uma máquina virtual no Hyper-V no Windows Server 2008. E aqui algumas suspeitas começam a se formar em mim...
Abro o gerenciador do servidor - Funções - uma nova função apareceu - Hyper-V. Vou ao gerenciador do Hyper-V, vejo uma máquina virtual, conecto... E de fato... Nosso novo servidor de banco de dados...
E daí? As instruções das autoridades e as minhas recomendações foram cumpridas, os papéis foram separados. A tarefa pode ser fechada.
Depois de algum tempo, aconteceu a crise agora, a nova filial teve que ser fechada, a carga diminuiu e o desempenho do sistema ficou mais ou menos tolerável.
Bem, é claro, eles não conseguiram encaminhar a chave do servidor para a máquina virtual. Como resultado, tudo ficou como está: servidor de terminal + cluster 1C em uma máquina física, servidor de banco de dados em uma máquina virtual.
E seria bom se este fosse algum tipo de escritório de Sharashkin. Então não. Uma empresa conhecida cujos produtos provavelmente conhece e já viu nos departamentos relevantes de todas as Lentas e Auchans.
Cronograma de férias do disco rígido
Uma grande holding com planos ambiciosos de dominar o mundo comprou mais uma vez uma pequena empresa com o objetivo de incluí-la na sua megacorporação. Em todas as divisões desta holding os utilizadores trabalham em bases de dados próprias, mas com configuração idêntica. E assim iniciamos um pequeno projeto para incluir uma nova unidade neste sistema.
Em primeiro lugar, é necessário implantar bancos de dados de produção e de teste. O desenvolvedor recebeu os dados de conexão, faz login no servidor, vê o MS SQL instalado, servidor 1C, vê 2 unidades lógicas: unidade “C” com capacidade de 250 gigabytes e unidade “D” com capacidade de 1 terabyte. Bem, “C” é o sistema, “D” é para dados, o desenvolvedor decide logicamente e implanta todos os bancos de dados lá. Até configurei planos de manutenção, incluindo backup, só para garantir (mesmo que não sejamos responsáveis por isso). É verdade que os backups foram adicionados aqui em “D”. No futuro, foi planejado reconfigurá-lo para algum recurso de rede separado.
O projeto foi iniciado, os consultores ministraram treinamento sobre como trabalhar no novo sistema, as sobras foram transferidas, algumas pequenas melhorias foram feitas e os usuários começaram a trabalhar na nova base de informações.
Tudo estava indo bem até uma manhã de segunda-feira, quando foi descoberto que o disco do banco de dados estava faltando. Simplesmente não existe “D” no servidor e pronto.
Uma investigação mais aprofundada revelou o seguinte: este “servidor” era na verdade o computador de trabalho de um administrador de sistema local. É verdade que ainda tinha um sistema operacional de servidor. A unidade USB pessoal deste administrador foi conectada ao servidor. E assim o administrador saiu de férias, levando consigo seu parafuso, com o objetivo de colocar filmes nele para a viagem.
Graças a Deus ele não conseguiu deletar os arquivos do banco de dados e conseguiu restaurar o banco de dados produtivo.
Vale ressaltar que em geral todos ficaram satisfeitos com o desempenho do sistema localizado em um drive USB. Ninguém reclamou do desempenho insatisfatório do 1C. Só mais tarde a holding iniciou um megaprojeto para transferir todos os bancos de dados de informações para um único site centralizado com superservidores, sistemas de armazenamento de mais de um milhão de rublos, hipervisores sofisticados e freios 1C insuportáveis em todas as filiais.
Mas essa é uma história completamente diferente ...
Fonte: habr.com