Alla 1C-utvecklare har på ett eller annat sätt ett nära samarbete med IT-tjänster och direkt med systemadministratörer. Men denna interaktion går inte alltid smidigt. Jag skulle vilja berätta några roliga historier om detta.
Höghastighetskommunikationskanal
De flesta av våra kunder är stora innehav med egna stora IT-avdelningar. Och klientspecialister är vanligtvis ansvariga för säkerhetskopior av informationsdatabaser. Men det finns också relativt små organisationer. Speciellt för dem har vi en tjänst enligt vilken vi tar på oss alla frågor relaterade till backup av allt 1C. Det här är företaget vi kommer att prata om i den här historien.
En ny kund kom för att stödja 1C och i kontraktet ingick bland annat en klausul om att vi ansvarade för säkerhetskopiering, fast de hade en egen systemadministratör i personalen. Klient-server-databas, MS SQL som DBMS. En ganska standardsituation, men det fanns fortfarande en nyans: huvudbasen var ganska stor, men den månatliga ökningen var mycket liten. Det vill säga att databasen innehöll mycket historisk data. Med hänsyn till den här funktionen satte jag upp backupunderhållsplaner enligt följande: den första lördagen i varje månad gjordes en fullständig säkerhetskopia, den var ganska tung, sedan gjordes en differentiell kopia varje natt - en relativt liten volym och en kopia av transaktionsloggen varje timme. Dessutom kopierades fullständiga och differentiella kopior inte bara till en nätverksresurs, utan laddades också upp till vår FTP-server. Detta är ett obligatoriskt krav när du tillhandahåller denna tjänst.
Allt detta konfigurerades framgångsrikt, togs i drift och fungerade i allmänhet utan fel.
Men några månader senare ändrades systemadministratören i denna organisation. Den nya systemadministratören började gradvis bygga om företagets IT-infrastruktur i enlighet med moderna trender. I synnerhet dök virtualisering upp, diskhyllor, åtkomst blockerades överallt och allt, etc., vilket i det allmänna fallet naturligtvis inte kan annat än att glädjas. Men saker och ting gick inte alltid smidigt för honom; det var ofta problem med 1C:s prestanda, vilket orsakade vissa oenigheter och missförstånd med vårt stöd. Det bör också noteras att vårt förhållande till honom i allmänhet var ganska kallt och något ansträngt, vilket bara ökade graden av spänning i händelse av att några problem uppstod.
Men en morgon visade det sig att denna klients server inte var tillgänglig. Jag ringde systemadministratören för att ta reda på vad som hände och fick som ett svar något i stil med "Vår server har kraschat, vi jobbar på det, inte upp till dig." Jo, det är bra att de fungerar. Det betyder att situationen är under kontroll. Efter lunch ringer jag tillbaka igen, och istället för irritation kan jag redan känna trötthet och apati i administratörens röst. Jag försöker ta reda på vad som hände och finns det något vi kan göra för att hjälpa? Som ett resultat av samtalet kom följande fram:
Han flyttade servern till ett nytt lagringssystem med en nymonterad raid. Men något gick fel och några dagar senare kollapsade denna razzia säkert. Om kontrollenheten brann ut eller något hände med diskarna minns jag inte exakt, men all information gick oåterkalleligt förlorad. Och huvudsaken var att nätverksresursen med säkerhetskopior också hamnade på samma diskarray vid olika migrering. Det vill säga att både själva den produktiva databasen och alla dess säkerhetskopior gick förlorade. Och det är oklart vad man ska göra nu.
Lugna dig, säger jag. Vi har din nattliga backup. Som svar blev det tyst, genom vilken jag insåg att jag just hade räddat en mans liv. Vi börjar diskutera hur man överför denna kopia till en ny, nyligen distribuerad server. Men även här uppstod ett problem.
Kommer du ihåg när jag sa att den fullständiga säkerhetskopian var ganska stor? Det var inte för inte som jag gjorde det en gång i månaden på lördagar. Faktum är att företaget var en liten anläggning, som låg långt utanför staden och deras internet var väldigt so-so. På måndagsmorgonen, det vill säga under helgen, lyckades denna kopia knappt laddas upp till vår FTP-server. Men det fanns inget sätt att vänta en dag eller två på att den skulle laddas i motsatt riktning. Efter flera misslyckade försök att överföra filen tog administratören ut hårddisken direkt från den nya servern, hittade en bil med en förare någonstans och rusade snabbt till vårt kontor, som tur är är vi fortfarande i samma stad.
Medan de stod i vårt serverrum och väntade på att filerna skulle kopieras träffades vi för första gången så att säga "personligen", drack en kopp kaffe och pratade i en informell miljö. Jag sympatiserade med hans sorg och skickade tillbaka honom med en hel skruv av säkerhetskopior, och snabbt återställde företagets stoppade arbete.
Därefter löstes alla våra förfrågningar till IT-avdelningen mycket snabbt och inga fler oenigheter uppstod.
Kontakta din systemadministratör
En gång, under väldigt lång tid, kunde jag inte publicera 1C för webbåtkomst via IIS för en klient. Det verkade som en vanlig uppgift, men det fanns inget sätt att få igång allt. Lokala systemadministratörer engagerade sig och provade olika inställningar och konfigurationsfiler. 1C på webben ville normalt inte fungera på något sätt. Något var fel, antingen med domänsäkerhetspolicyer eller med den lokala sofistikerade brandväggen, eller gud vet vad mer. I den N:te iterationen skickar administratören mig en länk med orden:
- Försök igen med hjälp av dessa instruktioner. Allt beskrivs där ganska detaljerat. Om det inte fungerar, skriv till författaren till denna webbplats, han kanske kan hjälpa till.
"Nej", säger jag, "det hjälper inte."
- Varför?
– Jag är författaren till den här webbplatsen... (
Som ett resultat lanserade vi det på Apache utan några problem. IIS besegrades aldrig.
En nivå djupare
Vi hade en kund - ett litet tillverkningsföretag. De hade en server, en slags "klassisk" 3 i 1: terminalserver + applikationsserver + databasserver. De arbetade i någon branschspecifik konfiguration baserad på UPP, det var cirka 15-20 användare, och systemets prestanda passade i princip alla.
Allt eftersom tiden gick fungerade allt mer eller mindre stabilt. Men sedan införde Europa sanktioner mot Ryssland, som ett resultat av vilka ryssarna började köpa huvudsakligen inhemskt producerade produkter, och affärerna för detta företag gick kraftigt uppåt. Antalet användare ökade till 50-60 personer, en ny filial öppnades och dokumentflödet ökade därefter. Och nu kunde den nuvarande servern inte längre klara av den kraftigt ökade belastningen, och 1C började, som de säger, "sakta ner". Under rusningstid behandlades dokument i flera minuter, blockeringsfel uppstod, formulär tog lång tid att öppna och hela den andra buketten av relaterade tjänster. Den lokala systemadministratören borstade bort alla problem och sa: "Det här är din 1C, du kommer att reda ut det." Vi har upprepade gånger föreslagit att göra en effektivitetsrevision av systemet, men det kom aldrig till själva revisionen. Kunden bad helt enkelt om rekommendationer om hur man åtgärdar problem.
Nåväl, jag satte mig ner och skrev ett ganska långt brev om behovet av att separera rollerna för terminalservern och applikationsservern med DBMS (vilket vi i princip redan har sagt många gånger tidigare). Jag skrev om DFSS på terminalservrar, om delat minne, gav länkar till auktoritativa källor och föreslog till och med några alternativ för utrustning. Detta brev nådde makthavarna i företaget, gick tillbaka till IT-avdelningen med resolutionerna ”Implementera” och isen var generellt bruten.
Efter en tid skickar administratören mig IP-adressen för den nya servern och inloggningsuppgifter. Han säger att MS SQL- och 1C-serverkomponenter är utplacerade där, och databaserna behöver överföras, men för närvarande bara till DBMS-servern, eftersom det har uppstått problem med 1C-nycklarna.
Jag kom in, verkligen, alla tjänster körde, servern var inte särskilt kraftfull, men ok, jag tror att det är bättre än ingenting. Jag kommer att överföra databaserna för nu för att på något sätt avlasta den nuvarande servern. Jag genomförde alla överföringar vid överenskommen tidpunkt, men situationen förändrades inte - fortfarande samma prestationsproblem. Det är förstås konstigt, ja, låt oss registrera databaserna i 1C-klustret så får vi se.
Det går flera dagar, nycklarna har inte överförts. Jag undrar vad problemet är, allt verkar vara enkelt - ta ut den från en server, koppla in den till en annan, installera drivrutinen och du är klar. Administratören svarar med att krångla och säga något om portvidarebefordran, en virtuell server och så vidare.
Hmm... Virtuell server? Det verkar som att det aldrig har funnits någon virtualisering och det har aldrig funnits någon... Jag minns ett ganska välkänt problem med omöjligheten att vidarebefordra en 1C-servernyckel till en virtuell maskin på Hyper-V i Windows Server 2008. Och här vissa misstankar börjar bildas hos mig...
Jag öppnar serverhanteraren - Roller - en ny roll har dykt upp - Hyper-V. Jag går till Hyper-V-hanteraren, ser en virtuell maskin, ansluter... Och verkligen... Vår nya databasserver...
Än sen då? Myndigheternas instruktioner och mina rekommendationer har genomförts, rollerna är åtskilda. Uppgiften kan stängas.
Efter en tid inträffade den nu krisen, den nya filialen måste stängas, belastningen minskade och systemets prestanda blev mer eller mindre acceptabel.
Jo, naturligtvis kunde de inte vidarebefordra servernyckeln till den virtuella maskinen. Som ett resultat lämnades allt som det är: terminalserver + 1C-kluster på en fysisk maskin, databasserver där i en virtuell.
Och det skulle vara trevligt om detta var något slags sharashkins kontor. Så nej. Ett välkänt företag vars produkter du säkert känner till och har sett på relevanta avdelningar på alla Lentas och Auchans.
Semesterschema för hårddisk
Ett stort holdingbolag med ambitiösa planer på att ta över världen har återigen köpt ett litet bolag med målet att inkludera det i sitt megabolag. I alla divisioner av detta innehav arbetar användare i sina egna databaser, men med en identisk konfiguration. Och så startade vi ett litet projekt för att inkludera en ny enhet i det här systemet.
Först och främst är det nödvändigt att distribuera produktions- och testdatabaser. Utvecklaren tog emot anslutningsdata, loggar in på servern, ser MS SQL installerad, 1C-server, ser 2 logiska enheter: enhet "C" med en kapacitet på 250 gigabyte och enhet "D" med en kapacitet på 1 terabyte. Tja, "C" är systemet, "D" är för data, utvecklaren bestämmer logiskt och distribuerar alla databaser där. Jag satte till och med upp underhållsplaner, inklusive backup, för säkerhets skull (även om vi inte är ansvariga för detta). Det är sant att säkerhetskopior lades till här i "D". I framtiden var det planerat att konfigurera om det till någon separat nätverksresurs.
Projektet startade, konsulter gav utbildning i hur man arbetar i det nya systemet, rester överfördes, några mindre mindre förbättringar gjordes och användare började arbeta i den nya informationsbasen.
Allt flöt på bra tills det en måndagsmorgon upptäcktes att databasskivan saknades. Det finns helt enkelt inget "D" på servern och det är allt.
Ytterligare undersökningar visade detta: denna "server" var faktiskt en lokal systemadministratörs arbetsdator. Det var sant att det fortfarande hade ett serveroperativsystem. Den här administratörens personliga USB-enhet var ansluten till servern. Och så åkte administratören på semester och tog med sig sin skruv, med målet att pumpa in filmer för resan.
Gudskelov lyckades han inte radera databasfilerna och lyckades återställa den produktiva databasen.
Det är anmärkningsvärt att alla i allmänhet var nöjda med prestandan för systemet som finns på en USB-enhet. Ingen klagade på otillfredsställande prestanda hos 1C. Det var först senare som innehavet startade ett megaprojekt för att överföra alla informationsdatabaser till en enda centraliserad plats med superservrar, lagringssystem för en miljon+ rubel, sofistikerade hypervisorer och outhärdliga 1C-bromsar i alla grenar.
Men det är en helt annan historia...
Källa: will.com