Príbehy vývojárov 1C: správcovské

Všetci vývojári 1C tak či onak úzko spolupracujú so službami IT a priamo so správcami systému. Ale táto interakcia nie je vždy hladká. Rád by som vám o tom povedal niekoľko vtipných príbehov.

Vysokorýchlostný komunikačný kanál

Väčšina našich klientov sú veľké holdingy s vlastnými veľkými IT oddeleniami. A za záložné kópie informačných databáz sú zvyčajne zodpovední klienti špecialisti. Existujú však aj relatívne malé organizácie. Najmä pre nich máme službu, podľa ktorej preberáme na seba všetky záležitosti týkajúce sa zálohovania všetkého 1C. Toto je spoločnosť, o ktorej budeme hovoriť v tomto príbehu.

Na podporu 1C prišiel nový klient a zmluva okrem iného obsahovala klauzulu, že za zálohy sme zodpovední my, hoci mali medzi zamestnancami vlastného správcu systému. Databáza klient-server, MS SQL ako DBMS. Pomerne štandardná situácia, ale stále tu bola jedna nuansa: hlavná základňa bola pomerne veľká, ale mesačný nárast bol veľmi malý. To znamená, že databáza obsahovala množstvo historických údajov. Berúc do úvahy túto funkciu, nastavil som plány údržby záloh nasledovne: každú prvú sobotu v mesiaci sa vytvorila úplná záloha, bola dosť ťažká, potom sa každú noc vytvorila rozdielová kópia - relatívne malý zväzok a kópia denníka transakcií každú hodinu. Navyše, úplné a rozdielové kópie boli nielen skopírované do sieťového zdroja, ale aj dodatočne nahrané na náš FTP server. Toto je povinná požiadavka pri poskytovaní tejto služby.

To všetko bolo úspešne nakonfigurované, uvedené do prevádzky a vo všeobecnosti fungovalo bez porúch.

O niekoľko mesiacov neskôr sa však v tejto organizácii zmenil správca systému. Nový správca systému začal postupne prestavovať IT infraštruktúru spoločnosti v súlade s modernými trendmi. Najmä sa objavila virtualizácia, diskové police, prístup bol zablokovaný všade a všetko atď., Čo sa vo všeobecnom prípade, samozrejme, nemôže radovať. Ale nie vždy išlo všetko hladko, často sa vyskytli problémy s výkonom 1C, čo spôsobilo určité nezhody a nedorozumenia s našou podporou. Tiež treba poznamenať, že náš vzťah s ním bol celkovo dosť chladný a trochu napätý, čo len zvyšovalo mieru napätia v prípade akýchkoľvek problémov.

Jedno ráno sa však ukázalo, že server tohto klienta je nedostupný. Zavolal som správcovi systému, aby som zistil, čo sa stalo, a ako odpoveď som dostal niečo ako „Náš server zlyhal, pracujeme na tom, nie je to na vás.“ No dobre, že fungujú. To znamená, že situácia je pod kontrolou. Po obede opäť volám a namiesto podráždenia už v adminovom hlase cítim únavu a apatiu. Snažím sa prísť na to, čo sa stalo a môžeme s niečím pomôcť? Výsledkom rozhovoru bolo nasledovné:

Presťahoval server do nového úložného systému s novo zostaveným raidom. Niečo sa však pokazilo a o pár dní neskôr sa tento nájazd bezpečne zrútil. Či vyhorel ovládač alebo sa niečo stalo s diskami, presne si nepamätám, ale všetky informácie boli nenávratne stratené. A hlavné bolo, že na rovnakom diskovom poli pri rôznych migráciách skončil aj sieťový zdroj so zálohami. To znamená, že sa stratila samotná produktívna databáza aj všetky jej záložné kópie. A teraz nie je jasné, čo robiť.

Upokoj sa, hovorím. Máme vašu nočnú zálohu. Ako odpoveď nastalo ticho, v ktorom som si uvedomil, že som práve zachránil život človeka. Začneme diskutovať o tom, ako preniesť túto kópiu na nový, novo nasadený server. Ale aj tu nastal problém.

Pamätáte si, keď som povedal, že plná záloha je dosť veľká? Nie nadarmo som to robil raz za mesiac v sobotu. Faktom je, že spoločnosť bola malým závodom, ktorý sa nachádzal ďaleko za mestom a ich internet bol veľmi podobný. V pondelok ráno, teda cez víkend, sa táto kópia ledva podarilo nahrať na náš FTP server. Nedalo sa však čakať deň alebo dva, kým sa naloží v opačnom smere. Po niekoľkých neúspešných pokusoch o prenos súboru administrátor vybral pevný disk priamo z nového servera, niekde našiel auto so šoférom a rýchlo sa ponáhľal do našej kancelárie, našťastie sme stále v tom istom meste.

Kým stáli v našej serverovni a čakali na skopírovanie súborov, prvýkrát sme sa stretli takpovediac „osobne“, vypili sme šálku kávy a porozprávali sa v neformálnom prostredí. Sympatizoval som s jeho smútkom a poslal som ho späť s plnou skrutkou záloh, čím som narýchlo obnovil zastavenú prácu spoločnosti.

Následne boli všetky naše požiadavky na IT oddelenie veľmi rýchlo vyriešené a už nevznikali žiadne nezhody.

Kontaktujte správcu systému

Raz, veľmi dlho, som nemohol publikovať 1C pre webový prístup cez IIS pre jedného klienta. Vyzeralo to ako obyčajná úloha, ale neexistoval spôsob, ako všetko spustiť. Miestni správcovia systému sa zapojili a vyskúšali rôzne nastavenia a konfiguračné súbory. 1C na webe normálne nechcelo nijako fungovať. Niečo nebolo v poriadku, buď s bezpečnostnými politikami domény, alebo s lokálnym sofistikovaným firewallom, alebo bohvie čím ešte. Pri N-tej iterácii mi správca pošle odkaz so slovami:

- Skúste to znova pomocou týchto pokynov. Všetko je tam dosť podrobne popísané. Ak to nefunguje, napíšte autorovi tejto stránky, možno vám pomôže.
"Nie," hovorím, "to nepomôže."
- Prečo?
— Som autorom tejto stránky... (

Vďaka tomu sme ho bez problémov spustili na Apache. IIS nebol nikdy porazený.

O úroveň hlbšie

Mali sme klienta – malý výrobný podnik. Mali server, akýsi „klasický“ 3 v 1: terminálový server + aplikačný server + databázový server. Pracovali v nejakej odvetvovej konfigurácii založenej na UPP, bolo tam asi 15-20 používateľov a výkon systému v zásade vyhovoval každému.

Ako čas plynul, všetko fungovalo viac-menej stabilne. Potom však Európa uvalila sankcie na Rusko, v dôsledku čoho Rusi začali nakupovať najmä domáce produkty a biznis pre túto spoločnosť išiel prudko do kopca. Počet používateľov sa zvýšil na 50-60 ľudí, otvorila sa nová pobočka a zodpovedajúcim spôsobom sa zvýšil tok dokumentov. A teraz sa súčasný server už nedokázal vyrovnať s prudko zvýšeným zaťažením a 1C začal, ako sa hovorí, „spomaliť“. Počas špičky sa dokumenty spracovávali niekoľko minút, vyskytli sa chyby blokovania, dlho sa otvárali formuláre a celá ďalšia séria súvisiacich služieb. Miestny správca systému odstránil všetky problémy a povedal: „Toto je vaše 1C, prídete na to.“ Opakovane sme navrhovali vykonať výkonnostný audit systému, no k samotnému auditu nikdy neprišlo. Klient jednoducho požiadal o odporúčania, ako vyriešiť problémy.

Posadil som sa a napísal som pomerne dlhý list o potrebe oddeliť úlohy terminálového servera a aplikačného servera s DBMS (čo sme v zásade už povedali mnohokrát). Písal som o DFSS na terminálových serveroch, o zdieľanej pamäti, poskytol odkazy na autoritatívne zdroje a dokonca som navrhol niektoré možnosti vybavenia. Tento list sa dostal k tým, ktorí boli v spoločnosti pri moci, vrátil sa späť na IT oddelenie s uzneseniami „Implementovať“ a ľady sa vo všeobecnosti prelomili.

Po určitom čase mi administrátor pošle IP adresu nového servera a prihlasovacie údaje. Hovorí, že tam sú nasadené komponenty servera MS SQL a 1C a databázy je potrebné preniesť, ale zatiaľ iba na server DBMS, pretože sa vyskytli problémy s kľúčmi 1C.

Prišiel som, skutočne, všetky služby boli spustené, server nebol príliš výkonný, ale dobre, myslím, že je to lepšie ako nič. Zatiaľ prenesiem databázy, aby som nejakým spôsobom odľahčil súčasný server. Všetky prestupy som absolvoval v dohodnutom čase, no situácia sa nezmenila – stále rovnaké výkonnostné problémy. Je to, samozrejme, zvláštne, no, registrujme databázy v klastri 1C a uvidíme.

Prešlo niekoľko dní, kľúče neboli prenesené. Zaujímalo by ma, v čom je problém, všetko sa zdá byť jednoduché - vyberte ho z jedného servera, pripojte ho k druhému, nainštalujte ovládač a máte hotovo. Správca odpovedá rozruchom a hovorí niečo o presmerovaní portov, virtuálnom serveri atď.

Hmm... Virtuálny server? Zdá sa, že žiadna virtualizácia nikdy nebola a ani nebola... Spomínam si na pomerne známy problém s nemožnosťou preposielania serverového kľúča 1C na virtuálny stroj na Hyper-V vo Windows Server 2008. A tu začínajú sa vo mne formovať nejaké podozrenia...

Otvorím správcu servera - Roly - objavila sa nová rola - Hyper-V. Idem do správcu Hyper-V, pozriem si jeden virtuálny stroj, pripojím sa... A skutočne... Náš nový databázový server...

No a čo? Pokyny orgánov a moje odporúčania boli splnené, úlohy boli oddelené. Úloha môže byť uzavretá.

Po nejakom čase nastala súčasná kríza, nová pobočka musela byť zatvorená, záťaž sa znížila a výkon systému sa stal viac-menej únosným.

Samozrejme, nemohli poslať kľúč servera virtuálnemu stroju. Výsledkom bolo, že všetko zostalo tak, ako je: terminálový server + klaster 1C na fyzickom stroji, databázový server tam vo virtuálnom.

A bolo by pekné, keby to bola nejaká šarashkinova kancelária. Takže nie. Známa firma, ktorej produkty pravdepodobne poznáte a videli ste ich v príslušných oddeleniach všetkých Lentas a Auchans.

Plán dovolenky na pevnom disku

Veľký holding s ambicióznymi plánmi ovládnuť svet opäť kúpil malú firmu s cieľom zaradiť ju do svojej megakorporácie. Vo všetkých divíziách tohto holdingu užívatelia pracujú vo vlastných databázach, avšak s identickou konfiguráciou. A tak sme odštartovali malý projekt na zaradenie novej jednotky do tohto systému.

V prvom rade je potrebné nasadiť produkčné a testovacie databázy. Vývojár dostal údaje o pripojení, prihlásil sa na server, vidí nainštalovaný MS SQL, server 1C, vidí 2 logické jednotky: jednotku „C“ s kapacitou 250 gigabajtov a jednotku „D“ s kapacitou 1 terabajt. Nuž, „C“ je systém, „D“ je pre dáta, vývojár tam logicky rozhodne a nasadí všetky databázy. Dokonca som pre každý prípad nastavil plány údržby vrátane zálohovania (aj keď za to nezodpovedáme). Je pravda, že zálohy boli pridané tu do „D“. V budúcnosti sa plánovalo jeho prekonfigurovanie na nejaký samostatný sieťový zdroj.

Projekt sa rozbehol, konzultanti poskytli školenie o práci v novom systéme, presunuli sa zvyšky, vykonali sa menšie drobné vylepšenia a používatelia začali pracovať v novej informačnej základni.

Všetko išlo dobre až do jedného pondelkového rána, keď sa zistilo, že databázový disk chýba. Na serveri jednoducho nie je žiadne „D“ a to je všetko.

Ďalšie vyšetrovanie odhalilo toto: tento „server“ bol v skutočnosti pracovným počítačom lokálneho správcu systému. Je pravda, že stále mal serverový OS. Osobný USB disk tohto správcu bol pripojený k serveru. A tak správca odišiel na dovolenku, vzal si so sebou svoju skrutku s cieľom napumpovať do nej filmy na cestu.

Vďakabohu sa mu nepodarilo vymazať databázové súbory a podarilo sa mu obnoviť produktívnu databázu.

Je pozoruhodné, že všetci boli vo všeobecnosti spokojní s výkonom systému umiestneného na USB disku. Nikto sa nesťažoval na nejaký neuspokojivý výkon 1C. Až neskôr holding začal s megaprojektom prenosu všetkých informačných databáz na jediné centralizované miesto so superservermi, úložnými systémami za milión a viac rubľov, sofistikovanými hypervízormi a neznesiteľnými 1C brzdami vo všetkých pobočkách.

Ale to je úplne iný príbeh...

Zdroj: hab.com

Pridať komentár