Todos os desenvolvedores de 1C dunha forma ou doutra interactúan estreitamente cos servizos de TI e directamente cos administradores do sistema. Pero esta interacción non sempre vai sen problemas. Gustaríame contarche algunhas historias divertidas sobre isto.
Canle de comunicación de alta velocidade
A maioría dos nosos clientes son grandes holdings cos seus propios grandes departamentos de TI. E os especialistas en clientes adoitan ser responsables das copias de seguridade das bases de datos de información. Pero tamén hai organizacións relativamente pequenas. Especialmente para eles, temos un servizo segundo o cal asumimos todos os asuntos relacionados coa copia de seguridade de todo 1C. Esta é a empresa da que falaremos nesta historia.
Un novo cliente chegou a dar soporte a 1C e, entre outras cousas, o contrato incluía unha cláusula que nos encargabamos das copias de seguridade, aínda que tiñan o seu propio administrador de sistema no persoal. Base de datos cliente-servidor, MS SQL como DBMS. Unha situación bastante estándar, pero aínda había un matiz: a base principal era bastante grande, pero o aumento mensual era moi pequeno. É dicir, a base de datos contiña moitos datos históricos. Tendo en conta esta función, configurei os plans de mantemento de copia de seguridade do seguinte xeito: o primeiro sábado de cada mes fíxose unha copia de seguridade completa, era bastante pesada, despois facíase unha copia diferencial todas as noites: un volume relativamente pequeno e unha copia. do rexistro de transaccións cada hora. Ademais, as copias completas e diferenciais non só se copiaron nun recurso de rede, senón que tamén se cargaron no noso servidor FTP. Este é un requisito obrigatorio á hora de prestar este servizo.
Todo isto foi configurado con éxito, posto en funcionamento e, en xeral, funcionou sen fallos.
Pero uns meses despois, o administrador do sistema desta organización cambiou. O novo administrador do sistema comezou a reconstruír gradualmente a infraestrutura de TI da empresa de acordo coas tendencias modernas. En particular, apareceu a virtualización, os estantes de discos, o acceso bloqueouse en todas partes e todo, etc., que no caso xeral, por suposto, non poden menos que alegrarse. Pero as cousas non sempre lle saíron ben; moitas veces houbo problemas co rendemento de 1C, o que provocou algúns desacordos e malentendidos co noso apoio. Ademais, hai que ter en conta que a nosa relación con el foi en xeral bastante fría e algo tensa, o que só aumentaba o grao de tensión no caso de que xurdise algún problema.
Pero unha mañá descubriuse que o servidor deste cliente non estaba dispoñible. Chamei ao administrador do sistema para saber o que pasou e recibín como resposta algo como "O noso servidor fallou, estamos traballando niso, non depende de ti". Ben, é bo que funcionen. Isto significa que a situación está baixo control. Despois do xantar, chamo de novo e, en lugar de irritación, xa podo sentir cansazo e apatía na voz do administrador. Estou tentando descubrir o que pasou e hai algo que poidamos facer para axudar? Como resultado da conversación, xurdiu o seguinte:
Trasladou o servidor a un novo sistema de almacenamento cunha incursión recentemente montada. Pero algo saíu mal e uns días despois esta incursión colapsou con seguridade. Se o controlador queimou ou se pasou algo cos discos, non lembro exactamente, pero toda a información perdeuse irremediablemente. E o principal foi que o recurso de rede con copias de seguridade tamén terminou na mesma matriz de discos durante varias migracións. É dicir, perderonse tanto a propia base de datos produtiva como todas as súas copias de seguridade. E non está claro que facer agora.
Tranquila, digo. Temos a túa copia de seguridade nocturna. En resposta, houbo un silencio, polo que me decatei de que acababa de salvar a vida dun home. Comezamos a discutir como transferir esta copia a un servidor novo e recentemente implantado. Pero aquí tamén xurdiu un problema.
Lembras cando dixen que a copia de seguranza completa era bastante grande? Non por nada o facía unha vez ao mes os sábados. O caso é que a empresa era unha pequena planta, que estaba situada moi fóra da cidade e a súa Internet era moi así. Para o luns pola mañá, é dicir, durante a fin de semana, esta copia apenas conseguiu subirse ao noso servidor FTP. Pero non había forma de esperar un día ou dous para que cargase na dirección contraria. Despois de varios intentos infructuosos de transferir o ficheiro, o administrador sacou o disco duro directamente do novo servidor, atopou un coche cun condutor nalgún lugar e correu rapidamente á nosa oficina, afortunadamente aínda estamos na mesma cidade.
Mentres estaban parados na nosa sala de servidores agardando a que se copiaran os ficheiros, coñecémonos por primeira vez, por así dicilo, "en persoa", tomamos unha cunca de café e falamos nun ambiente informal. Simpaticei coa súa dor e mandeino de volta cun parafuso cheo de copias de seguridade, restaurando apresuradamente o traballo parado da empresa.
Posteriormente, todas as nosas solicitudes ao departamento de TI foron resoltas moi rapidamente e non xurdiron máis desacordos.
Contacte co administrador do sistema
Unha vez, durante moito tempo, non puiden publicar 1C para o acceso web a través de IIS para un cliente. Parecía unha tarefa común, pero non había forma de poñer todo en marcha. Os administradores locais do sistema implicáronse e probaron diferentes axustes e ficheiros de configuración. 1C na web normalmente non quería funcionar de ningún xeito. Algo andaba mal, ben coas políticas de seguridade do dominio, ben co sofisticado firewall local, ou Deus sabe que máis. Na enésima iteración, o administrador envíame unha ligazón coas palabras:
- Téntao de novo usando estas instrucións. Todo está descrito alí con bastante detalle. Se non funciona, escribe ao autor deste sitio, quizais poida axudar.
"Non", digo, "non servirá de nada".
- Por que?
— Son o autor deste sitio... (
Como resultado, lanzámolo en Apache sen ningún problema. IIS nunca foi derrotado.
Un nivel máis profundo
Tiñamos un cliente - unha pequena empresa de fabricación. Tiñan un servidor, unha especie de “clásico” 3 en 1: servidor terminal + servidor de aplicacións + servidor de bases de datos. Traballaron nalgunha configuración específica da industria baseada en UPP, había uns 15-20 usuarios e o rendemento do sistema, en principio, era adecuado para todos.
Co paso do tempo, todo funcionaba de forma máis ou menos estable. Pero entón Europa impuxo sancións contra Rusia, como resultado das cales os rusos comezaron a comprar principalmente produtos de produción nacional, e o negocio desta empresa subiu bruscamente. O número de usuarios aumentou a 50-60 persoas, abriuse unha nova sucursal e o fluxo de documentos aumentou en consecuencia. E agora o servidor actual xa non podía facer fronte ao aumento da carga e 1C comezou, como din, a "acelerar". Durante as horas punta, os documentos procesáronse durante varios minutos, producíronse erros de bloqueo, os formularios tardaron moito en abrirse e todo o outro bouquet de servizos relacionados. O administrador do sistema local despexou todos os problemas, dicindo: "Este é o teu 1C, resolverao". Propuxemos repetidamente a realización dunha auditoría de rendemento do sistema, pero nunca chegou á propia auditoría. O cliente simplemente pediu recomendacións sobre como solucionar os problemas.
Pois sentín e escribín unha carta bastante longa sobre a necesidade de separar os roles do servidor de terminal e do servidor de aplicacións co DBMS (que, en principio, xa dixemos moitas veces antes). Escribín sobre DFSS en servidores de terminais, sobre Memoria compartida, proporcionei ligazóns a fontes autorizadas e mesmo suxerín algunhas opcións para o equipo. Esta carta chegou aos gobernantes da empresa, volveu ao departamento de informática coas resolucións "Implementar" e en xeral rompeuse o xeo.
Despois dun tempo, o administrador envíame o enderezo IP do novo servidor e as credenciais de inicio de sesión. Di que alí se despregan os compoñentes do servidor MS SQL e 1C e que hai que transferir as bases de datos, pero polo momento só ao servidor DBMS, xa que xurdiron algúns problemas coas claves 1C.
Entrei, de feito, todos os servizos estaban funcionando, o servidor non era moi potente, pero está ben, creo que é mellor que nada. Vou transferir as bases de datos por agora para aliviar dalgún xeito o servidor actual. Completei todas as transferencias no momento acordado, pero a situación non cambiou - aínda os mesmos problemas de rendemento. É estraño, claro, ben, imos rexistrar as bases de datos no clúster 1C e xa veremos.
Pasan varios días, as chaves non foron transferidas. Pregúntome cal é o problema, todo parece ser sinxelo: sácao dun servidor, conéctao a outro, instala o controlador e xa está. O administrador responde queixándose e dicindo algo sobre o reenvío de portos, un servidor virtual, etc.
Hmm... Servidor virtual? Parece que nunca houbo virtualización e nunca houbo... Recordo un problema bastante coñecido coa imposibilidade de reenviar unha clave de servidor 1C a unha máquina virtual en Hyper-V en Windows Server 2008. E aquí comezan a formarse en min algunhas sospeitas...
Abro o xestor do servidor - Roles - apareceu un novo rol - Hyper-V. Vou ao xestor de Hyper-V, vexo unha máquina virtual, conecto... E de feito... O noso novo servidor de bases de datos...
Entón, que? Leváronse a cabo as instrucións das autoridades e as miñas recomendacións, separáronse os papeis. A tarefa pódese pechar.
Despois dun tempo, pasou a crise agora, a nova sucursal tivo que pecharse, a carga diminuíu e o rendemento do sistema fíxose máis ou menos tolerable.
Ben, por suposto, non puideron reenviar a chave do servidor á máquina virtual. Como resultado, todo quedou como está: servidor terminal + clúster 1C nunha máquina física, servidor de base de datos alí nunha virtual.
E sería bo que este fose algún tipo de oficina de sharashkin. Entón non. Unha empresa coñecida cuxos produtos probablemente coñeces e xa viu nos departamentos relevantes de todas as Lentas e Auchans.
Horario de vacacións do disco duro
Un gran holding con ambiciosos plans de apoderarse do mundo volveu comprar unha pequena empresa co obxectivo de incluíla na súa megacorporación. En todas as divisións deste holding, os usuarios traballan nas súas propias bases de datos, pero cunha configuración idéntica. E así comezamos un pequeno proxecto para incluír unha nova unidade neste sistema.
En primeiro lugar, é necesario despregar bases de datos de produción e probas. O programador recibiu os datos de conexión, inicia sesión no servidor, ve MS SQL instalado, o servidor 1C, ve 2 unidades lóxicas: a unidade "C" cunha capacidade de 250 gigabytes e a unidade "D" cunha capacidade de 1 terabyte. Ben, "C" é o sistema, "D" é para os datos, o desenvolvedor decide loxicamente e desprega todas as bases de datos alí. Incluso configurei plans de mantemento, incluída a copia de seguridade, por se acaso (aínda que non somos responsables disto). É certo que aquí engadíronse copias de seguranza a "D". No futuro, planeouse reconfiguralo nalgún recurso de rede separado.
O proxecto comezou, os consultores impartiron formación sobre como traballar no novo sistema, trasladáronse os restos, fixéronse algunhas pequenas melloras e os usuarios comezaron a traballar na nova base de información.
Todo ía ben ata que un luns pola mañá se descubriu que faltaba o disco da base de datos. Simplemente non hai "D" no servidor e xa está.
Unha investigación posterior revelou isto: este "servidor" era en realidade o ordenador de traballo dun administrador do sistema local. É certo, aínda tiña un sistema operativo de servidor. A unidade USB persoal deste administrador conectouse ao servidor. E así o administrador marchou de vacacións, levando o parafuso consigo, co obxectivo de botarlle películas para a viaxe.
Grazas a Deus, non conseguiu eliminar os ficheiros da base de datos e conseguiu restaurar a base de datos produtiva.
Cabe destacar que todos estaban satisfeitos co rendemento do sistema situado nunha unidade USB. Ninguén se queixou dun rendemento insatisfactorio de 1C. Foi só máis tarde cando o holding comezou un megaproxecto para transferir todas as bases de datos de información a un único sitio centralizado con superservidores, sistemas de almacenamento por máis dun millón de rublos, hipervisores sofisticados e freos 1C insoportables en todas as ramas.
Pero esa é unha historia completamente diferente...
Fonte: www.habr.com