Històries de desenvolupadors 1C: administradors

Tots els desenvolupadors d'1C d'una manera o altra interactuen estretament amb els serveis informàtics i directament amb els administradors del sistema. Però aquesta interacció no sempre va bé. M'agradaria explicar-vos algunes històries divertides sobre això.

Canal de comunicació d'alta velocitat

La majoria dels nostres clients són grans participacions amb els seus propis grans departaments informàtics. I els especialistes en clients solen ser responsables de les còpies de seguretat de les bases de dades d'informació. Però també hi ha organitzacions relativament petites. Sobretot per a ells, disposem d'un servei segons el qual ens encarreguem de tots els problemes relacionats amb la còpia de seguretat de tot 1C. Aquesta és l'empresa de la qual parlarem en aquesta història.

Un nou client va arribar a donar suport a 1C i, entre altres coses, el contracte incloïa una clàusula que ens encarregàvem de les còpies de seguretat, tot i que tenien el seu propi administrador de sistema a la plantilla. Base de dades client-servidor, MS SQL com a SGBD. Una situació bastant estàndard, però encara hi havia un matís: la base principal era bastant gran, però l'augment mensual era molt petit. És a dir, la base de dades contenia moltes dades històriques. Tenint en compte aquesta característica, vaig configurar els plans de manteniment de còpies de seguretat de la següent manera: el primer dissabte de cada mes es feia una còpia de seguretat completa, era bastant pesada, després es feia una còpia diferencial cada nit: un volum relativament petit i una còpia. del registre de transaccions cada hora. A més, les còpies completes i diferencials no només es van copiar a un recurs de xarxa, sinó que també es van penjar al nostre servidor FTP. Aquest és un requisit obligatori a l'hora de prestar aquest servei.

Tot això es va configurar, posar en funcionament i, en general, funcionar sense errors.

Però uns mesos més tard, l'administrador del sistema d'aquesta organització va canviar. El nou administrador del sistema va començar a reconstruir gradualment la infraestructura informàtica de l'empresa d'acord amb les tendències modernes. En particular, va aparèixer la virtualització, les prestatgeries de discs, es va bloquejar l'accés a tot arreu i tot, etc., que en el cas general, és clar, no poden menys que alegrar-se. Però les coses no sempre van anar bé per a ell, sovint hi havia problemes amb el rendiment de l'1C, fet que va provocar alguns desacords i malentesos amb el nostre suport. A més, cal tenir en compte que la nostra relació amb ell va ser generalment força freda i una mica tensa, fet que només augmentava el grau de tensió en cas de sorgir algun problema.

Però un matí va resultar que el servidor d'aquest client no estava disponible. Vaig trucar a l'administrador del sistema per esbrinar què va passar i vaig rebre com a resposta alguna cosa com "El nostre servidor s'ha bloquejat, estem treballant-hi, no depèn de vostè". Bé, està bé que funcionin. Això vol dir que la situació està sota control. Després de dinar, torno a trucar i, en lloc d'irritació, ja sento cansament i apatia en la veu de l'administrador. Estic intentant esbrinar què ha passat i hi podem fer alguna cosa per ajudar-lo? Com a resultat de la conversa, va sorgir el següent:

Va traslladar el servidor a un nou sistema d'emmagatzematge amb una incursió recentment muntada. Però alguna cosa va sortir malament i uns dies després aquesta incursió es va esfondrar amb seguretat. Tant si el controlador es va cremar com si va passar alguna cosa als discs, no ho recordo exactament, però tota la informació es va perdre irremeiablement. I el més important va ser que el recurs de xarxa amb còpies de seguretat també va acabar a la mateixa matriu de discs durant diverses migracions. És a dir, es van perdre tant la pròpia base de dades productiva com totes les seves còpies de seguretat. I ara no està clar què fer.

Tranquil·la, dic. Tenim la teva còpia de seguretat nocturna. En resposta, hi va haver un silenci, pel qual em vaig adonar que acabava de salvar la vida d'un home. Comencem a parlar de com transferir aquesta còpia a un nou servidor recentment desplegat. Però aquí també va sorgir un problema.

Recordeu quan vaig dir que la còpia de seguretat completa era bastant gran? No va ser per res que ho feia un cop al mes els dissabtes. El fet és que l'empresa era una planta petita, que es trobava molt fora de la ciutat i la seva Internet era molt tan tan. El dilluns al matí, és a dir, durant el cap de setmana, aquesta còpia amb prou feines s'aconseguia pujar al nostre servidor FTP. Però no hi havia manera d'esperar un dia o dos perquè es carregués en sentit contrari. Després de diversos intents infructuosos de transferir el fitxer, l'administrador va treure el disc dur directament del nou servidor, va trobar un cotxe amb conductor en algun lloc i es va precipitar ràpidament a la nostra oficina, afortunadament encara estem a la mateixa ciutat.

Mentre estaven a la nostra sala de servidors esperant que es copiessin els fitxers, ens vam conèixer per primera vegada, per dir-ho així, "en persona", vam prendre una tassa de cafè i vam parlar en un entorn informal. Vaig simpatitzar amb el seu dolor i el vaig enviar de tornada amb un cargol ple de còpies de seguretat, restaurant precipitadament el treball aturat de l'empresa.

Posteriorment, totes les nostres peticions al departament d'informàtica es van resoldre molt ràpidament i no van sorgir més desacords.

Contacteu amb l'administrador del vostre sistema

Una vegada, durant molt de temps, no vaig poder publicar 1C per a l'accés web mitjançant IIS per a un client. Semblava una tasca normal, però no hi havia manera de posar-ho tot en marxa. Els administradors locals del sistema es van implicar i van provar diferents configuracions i fitxers de configuració. 1C a la web normalment no volia funcionar de cap manera. Alguna cosa no funcionava, ja sigui amb les polítiques de seguretat del domini, o amb el tallafoc local sofisticat, o Déu sap què més. A la iteració enèsima, l'administrador m'envia un enllaç amb les paraules:

- Torna-ho a provar amb aquestes instruccions. S'hi descriu tot amb força detall. Si no funciona, escriviu a l'autor d'aquest lloc, potser us pot ajudar.
"No", dic, "no ajudarà".
- Per què?
— Sóc l'autor d'aquest lloc... (

Com a resultat, el vam llançar a Apache sense cap problema. IIS mai va ser derrotat.

Un nivell més profund

Teníem un client: una petita empresa de fabricació. Tenien un servidor, una mena de "clàssic" 3 en 1: servidor terminal + servidor d'aplicacions + servidor de bases de dades. Van treballar en una configuració específica de la indústria basada en UPP, hi havia uns 15-20 usuaris i el rendiment del sistema, en principi, s'adaptava a tothom.

Amb el pas del temps, tot va funcionar més o menys estable. Però aleshores Europa va imposar sancions a Rússia, com a resultat de les quals els russos van començar a comprar productes produïts principalment a nivell nacional, i el negoci d'aquesta empresa va pujar fortament. El nombre d'usuaris va augmentar a 50-60 persones, es va obrir una nova sucursal i el flux de documents va augmentar en conseqüència. I ara el servidor actual ja no podia fer front a la càrrega fortament augmentada i 1C va començar, com diuen, a "alentir-se". Durant les hores punta, els documents es van processar durant uns quants minuts, es van produir errors de bloqueig, els formularis van trigar molt a obrir-se i tot un altre ram de serveis relacionats. L'administrador del sistema local va eliminar tots els problemes i va dir: "Aquest és el vostre 1C, ho descobrireu". Hem proposat repetidament la realització d'una auditoria de rendiment del sistema, però mai va arribar a l'auditoria en si. El client simplement va demanar recomanacions sobre com solucionar els problemes.

Bé, em vaig asseure i vaig escriure una carta força llarga sobre la necessitat de separar els rols del servidor terminal i el servidor d'aplicacions amb el SGBD (que, en principi, ja hem dit moltes vegades abans). Vaig escriure sobre DFSS als servidors de terminals, sobre la memòria compartida, vaig proporcionar enllaços a fonts autoritzades i, fins i tot, vaig suggerir algunes opcions per als equips. Aquesta carta va arribar als governants de l'empresa, va tornar al departament d'informàtica amb les resolucions "Implementar" i en general es va trencar el gel.

Després d'un temps, l'administrador m'envia l'adreça IP del nou servidor i les credencials d'inici de sessió. Diu que els components del servidor MS SQL i 1C s'hi despleguen i les bases de dades s'han de transferir, però de moment només al servidor DBMS, ja que han sorgit alguns problemes amb les claus 1C.

Vaig entrar, de fet, tots els serveis estaven en funcionament, el servidor no era molt potent, però bé, crec que és millor que res. Transferiré les bases de dades de moment per alleujar d'alguna manera el servidor actual. Vaig completar totes les transferències a l'hora convinguda, però la situació no va canviar, encara els mateixos problemes de rendiment. És estrany, és clar, bé, registrem les bases de dades al clúster 1C i ja veurem.

Passen uns quants dies, les claus no s'han transferit. Em pregunto quin és el problema, sembla que tot és senzill: traieu-lo d'un servidor, connecteu-lo a un altre, instal·leu el controlador i ja està. L'administrador respon quedant-se i dient alguna cosa sobre el reenviament de ports, un servidor virtual, etc.

Hmm... Servidor virtual? Sembla que mai hi ha hagut virtualització i mai no n'hi ha hagut... Recordo un problema força conegut amb la impossibilitat de reenviar una clau de servidor 1C a una màquina virtual en Hyper-V a Windows Server 2008. I aquí comencen a formar-me algunes sospites...

Obro el gestor del servidor - Rols - ha aparegut un nou rol - Hyper-V. Vaig al gestor d'Hyper-V, veig una màquina virtual, em connecto... I de fet... El nostre nou servidor de bases de dades...

I què? Les instruccions de les autoritats i les meves recomanacions s'han dut a terme, els rols s'han separat. La tasca es pot tancar.

Al cap d'un temps, va passar l'actual crisi, es va haver de tancar la nova sucursal, la càrrega va disminuir i el rendiment del sistema es va fer més o menys tolerable.

Bé, per descomptat, no van poder reenviar la clau del servidor a la màquina virtual. Com a resultat, tot es va deixar tal qual: servidor terminal + clúster 1C en una màquina física, servidor de bases de dades allà en una virtual.

I estaria bé que aquesta fos una mena d'oficina de Sharashkin. Així que no. Una empresa coneguda els productes de la qual probablement coneixeu i heu vist als departaments corresponents de totes les Lentas i Auchans.

Calendari de vacances del disc dur

Un gran holding amb plans ambiciosos per fer-se amb el món ha tornat a comprar una petita empresa amb l'objectiu d'incloure-la a la seva megacorporació. A totes les divisions d'aquest holding, els usuaris treballen en les seves pròpies bases de dades, però amb una configuració idèntica. I així vam començar un petit projecte per incloure una nova unitat en aquest sistema.

En primer lloc, cal desplegar bases de dades de producció i proves. El desenvolupador va rebre les dades de connexió, inicia sessió al servidor, veu MS SQL instal·lat, el servidor 1C, veu 2 unitats lògiques: la unitat "C" amb una capacitat de 250 gigabytes i la unitat "D" amb una capacitat d'1 terabyte. Bé, "C" és el sistema, "D" és per a les dades, el desenvolupador decideix lògicament i desplega totes les bases de dades allà. Fins i tot he configurat plans de manteniment, inclosa la còpia de seguretat, per si de cas (tot i que no som responsables d'això). És cert que aquí s'han afegit còpies de seguretat a "D". En el futur, es va planificar reconfigurar-lo a algun recurs de xarxa independent.

El projecte va començar, els consultors van impartir formació sobre com treballar en el nou sistema, es van transferir les restes, es van fer algunes petites millores menors i els usuaris van començar a treballar en la nova base d'informació.

Tot anava bé fins que un dilluns al matí es va descobrir que faltava el disc de la base de dades. Simplement no hi ha cap "D" al servidor i ja està.

Una investigació posterior va revelar això: aquest "servidor" era en realitat l'ordinador de treball d'un administrador del sistema local. És cert que encara tenia un sistema operatiu de servidor. La unitat USB personal d'aquest administrador s'ha connectat al servidor. I així l'administrador se'n va anar de vacances, emportant-se el cargol amb ell, amb l'objectiu de posar-hi pel·lícules per al viatge.

Gràcies a Déu, no va aconseguir esborrar els fitxers de la base de dades i va aconseguir restaurar la base de dades productiva.

Cal destacar que, en general, tothom estava satisfet amb el rendiment del sistema situat en una unitat USB. Ningú es va queixar del rendiment insatisfactori de l'1C. Va ser només més tard que l'explotació va començar un megaprojecte per transferir totes les bases de dades d'informació a un únic lloc centralitzat amb superservidors, sistemes d'emmagatzematge per a més d'un milió de rubles, hipervisors sofisticats i frens 1C insuportables a totes les branques.

Però aquesta és una història completament diferent...

Font: www.habr.com

Afegeix comentari