Истории на разработчиците на 1C: администраторски

Всички разработчици на 1C по един или друг начин тясно взаимодействат с ИТ услугите и директно със системните администратори. Но това взаимодействие не винаги протича гладко. Бих искал да ви разкажа няколко забавни истории за това.

Високоскоростен комуникационен канал

Повечето от нашите клиенти са големи холдинги със собствени големи ИТ отдели. И клиентските специалисти обикновено отговарят за резервните копия на информационните бази данни. Но има и сравнително малки организации. Специално за тях имаме услуга, според която поемаме всички въпроси, свързани с архивирането на всичко 1C. Това е компанията, за която ще говорим в тази история.

Нов клиент дойде да поддържа 1C и, наред с други неща, договорът включваше клауза, че ние отговаряме за архивиране, въпреки че те имаха собствен системен администратор в персонала. База данни клиент-сървър, MS SQL като СУБД. Доста стандартна ситуация, но все пак имаше един нюанс: основната база беше доста голяма, но месечното увеличение беше много малко. Тоест базата данни съдържаше много исторически данни. Като взех предвид тази функция, настроих планове за поддръжка на резервно копие, както следва: в първата събота на всеки месец се правеше пълно архивиране, беше доста тежко, след това се правеше различно копие всяка вечер - сравнително малък обем и копие от регистъра на транзакциите на всеки час. Освен това пълните и диференциалните копия бяха не само копирани в мрежов ресурс, но и допълнително качени на нашия FTP сървър. Това е задължително изискване при предоставяне на тази услуга.

Всичко това беше успешно конфигурирано, пуснато в експлоатация и като цяло работеше без повреди.

Но няколко месеца по-късно системният администратор в тази организация се промени. Новият системен администратор започна постепенно да преустройва ИТ инфраструктурата на компанията в съответствие със съвременните тенденции. По-специално се появи виртуализация, дискови рафтове, достъпът беше блокиран навсякъде и всичко и т.н., което в общия случай, разбира се, не може да не се радва. Но нещата не винаги вървяха гладко за него; често имаше проблеми с работата на 1C, което предизвика някои разногласия и недоразумения с нашата поддръжка. Също така трябва да се отбележи, че отношенията ни с него като цяло бяха доста студени и донякъде обтегнати, което само повишаваше градуса на напрежението при евентуални проблеми.

Но една сутрин се оказа, че сървърът на този клиент е недостъпен. Обадих се на системния администратор, за да разбера какво се е случило и получих като отговор нещо като „Сървърът ни се срина, ние работим върху това, не зависи от вас.“ Е, добре че работят. Това означава, че ситуацията е под контрол. След обяд се обаждам отново и вместо раздразнение вече усещам умора и апатия в гласа на администратора. Опитвам се да разбера какво се е случило и можем ли да помогнем с нещо? В резултат на разговора стана следното:

Той премести сървъра на нова система за съхранение с новосглобен рейд. Но нещо се обърка и няколко дни по-късно този набег безопасно се срина. Дали контролерът е изгорял или нещо се е случило с дисковете, не помня точно, но цялата информация беше безвъзвратно загубена. И основното беше, че мрежовият ресурс с резервни копия също се озова на същия дисков масив по време на различни миграции. Тоест както самата продуктивна база данни, така и всички нейни резервни копия бяха загубени. И не е ясно какво да правим сега.

Успокой се, казвам. Имаме вашето нощно резервно копие. В отговор последва мълчание, по което разбрах, че току-що съм спасил живота на един човек. Започваме да обсъждаме как да прехвърлим това копие на нов, току-що внедрен сървър. Но и тук се появи проблем.

Спомняте ли си, когато казах, че пълното архивиране е доста голямо? Не напразно го правех веднъж месечно в събота. Факт е, че компанията беше малък завод, който се намираше далеч извън града и техният интернет беше много толкова. До понеделник сутринта, тоест през уикенда, това копие едва успя да бъде качено на нашия FTP сървър. Но нямаше как да чакам ден-два да се зареди в обратната посока. След няколко неуспешни опита за прехвърляне на файла, администраторът извади харда директно от новия сървър, намери някъде кола с шофьор и бързо се втурна към нашия офис, за щастие все още сме в същия град.

Докато те стояха в нашата сървърна стая и чакаха файловете да бъдат копирани, ние се видяхме за първи път, така да се каже, „лично“, изпихме чаша кафе и поговорихме в неформална обстановка. Съчувствах на мъката му и го изпратих обратно с пълен винт резервни копия, възстановявайки набързо спряната работа на компанията.

Впоследствие всичките ни искания към ИТ отдела бяха решени много бързо и повече разногласия не възникнаха.

Свържете се с вашия системен администратор

Веднъж, за много дълго време, не можах да публикувам 1C за уеб достъп чрез IIS за един клиент. Изглеждаше като обикновена задача, но нямаше начин всичко да работи. Местните системни администратори се включиха и изпробваха различни настройки и конфигурационни файлове. 1C в мрежата обикновено не искаше да работи по никакъв начин. Нещо не беше наред или с правилата за сигурност на домейна, или с локалната сложна защитна стена, или бог знае какво още. На N-тата итерация администраторът ми изпраща линк с думите:

- Опитайте отново, като използвате тези инструкции. Там всичко е описано доста подробно. Ако не работи, пишете на автора на този сайт, може би той може да помогне.
„Не“, казвам, „няма да помогне“.
- Защо?
— Аз съм авторът на този сайт... (

В резултат на това го стартирахме на Apache без никакви проблеми. IIS никога не е бил победен.

Едно ниво по-дълбоко

Имахме клиент - малко производствено предприятие. Имаха сървър, нещо като „класически“ 3 в 1: терминален сървър + сървър на приложения + сървър на база данни. Те работеха в някаква специфична за индустрията конфигурация, базирана на UPP, имаше около 15-20 потребители и производителността на системата по принцип отговаряше на всички.

С течение на времето всичко работеше повече или по-малко стабилно. Но след това Европа наложи санкции срещу Русия, в резултат на което руснаците започнаха да купуват предимно местни продукти и бизнесът на тази компания рязко се покачи. Броят на потребителите се увеличи до 50-60 души, беше открит нов клон и съответно се увеличи документооборотът. И сега текущият сървър вече не можеше да се справи с рязко увеличеното натоварване и 1C започна, както се казва, да се „забави“. В пиковите часове документите се обработваха за няколко минути, възникваха грешки при блокиране, отварянето на формуляри отнемаше много време и целият друг набор от свързани услуги. Местният системен администратор отхвърли всички проблеми, като каза: „Това е вашият 1C, ще го разберете.“ Многократно сме предлагали да се направи одит на ефективността на системата, но до самия одит така и не се стигна. Клиентът просто поиска препоръки как да коригира проблемите.

Е, седнах и написах доста дълго писмо за необходимостта от разделяне на ролите на терминалния сървър и сървъра на приложения с СУБД (което по принцип вече казахме много пъти преди). Писах за DFSS на терминални сървъри, за споделена памет, предоставих връзки към авторитетни източници и дори предложих някои опции за оборудване. Това писмо стигна до управляващите в компанията, върна се в ИТ отдела с решенията „Внедрете” и ледът като цяло беше разчупен.

След известно време администраторът ми изпраща IP адреса на новия сървър и идентификационните данни за вход. Той казва, че там са разположени компоненти на MS SQL и 1C сървър и базите данни трябва да бъдат прехвърлени, но засега само към DBMS сървъра, тъй като са възникнали някои проблеми с ключовете 1C.

Влязох, наистина всички услуги работеха, сървърът не беше много мощен, но добре, мисля, че е по-добре от нищо. Засега ще прехвърля базите данни, за да облекча по някакъв начин текущия сървър. Завърших всички трансфери в уговореното време, но ситуацията не се промени - все още същите проблеми с производителността. Странно е, разбира се, добре, нека регистрираме базите данни в клъстера 1C и ще видим.

Минават няколко дни, ключовете не са прехвърлени. Чудя се какъв е проблема, всичко изглежда просто - извади го от един сървър, включи го в друг, инсталирай драйвера и готово. Администраторът отговаря, като се суети и казва нещо за пренасочване на портове, виртуален сървър и т.н.

Хм... Виртуален сървър? Изглежда, че никога не е имало виртуализация и никога не е имало... Спомням си един доста известен проблем с невъзможността да се препрати ключ на 1C сървър към виртуална машина на Hyper-V в Windows Server 2008. И тук започват да се зараждат някакви съмнения в мен...

Отварям мениджъра на сървъра - Роли - появи се нова роля - Hyper-V. Отивам в мениджъра на Hyper-V, виждам една виртуална машина, свързвам се... И наистина... Нашият нов сървър на база данни...

Какво от това? Указанията на властите и моите препоръки са изпълнени, ролите са разпределени. Задачата може да бъде затворена.

След известно време настъпи сегашната криза, новият клон трябваше да бъде затворен, натоварването намаля и производителността на системата стана повече или по-малко поносима.

Е, разбира се, те не можаха да препратят сървърния ключ към виртуалната машина. В резултат на това всичко остана както е: терминален сървър + 1C клъстер на физическа машина, сървър на база данни там във виртуална.

И би било хубаво, ако това беше някакъв офис на Шарашкин. Така че не. Добре позната компания, чиито продукти вероятно познавате и сте виждали в съответните отдели на всички Lentas и Auchans.

График за почивка на твърдия диск

Голяма холдингова компания с амбициозни планове да превземе света отново купи малка компания с цел да я включи в своята мегакорпорация. Във всички подразделения на този холдинг потребителите работят в собствени бази данни, но с идентична конфигурация. И така започнахме малък проект за включване на нов модул в тази система.

На първо място е необходимо да се внедрят производствени и тестови бази данни. Разработчикът получава данните за връзката, влиза в сървъра, вижда инсталиран MS SQL, 1C сървър, вижда 2 логически устройства: устройство „C“ с капацитет 250 гигабайта и устройство „D“ с капацитет 1 терабайт. Е, „C“ е системата, „D“ е за данни, разработчикът логично решава и разполага всички бази данни там. Дори създадох планове за поддръжка, включително архивиране, за всеки случай (въпреки че не носим отговорност за това). Вярно, резервни копия бяха добавени тук към „D“. В бъдеще беше планирано да го преконфигурирате към някакъв отделен мрежов ресурс.

Проектът стартира, консултантите проведоха обучение за работа в новата система, прехвърлиха се остатъците, направиха някои незначителни подобрения и потребителите започнаха работа в новата информационна база.

Всичко вървеше добре до един понеделник сутрин, когато се установи, че дискът с базата данни липсва. Просто няма „D“ на сървъра и това е.

По-нататъшното разследване разкри следното: този „сървър“ всъщност беше работният компютър на локален системен администратор. Вярно, все още имаше сървърна ОС. Личното USB устройство на този администратор беше включено в сървъра. И така администраторът отиде на почивка, като взе своя винт със себе си, с цел да изпомпва филми в него за пътуването.

Слава Богу, той не успя да изтрие файловете на базата данни и успя да възстанови продуктивната база данни.

Трябва да се отбележи, че като цяло всички бяха доволни от работата на системата, разположена на USB устройство. Никой не се оплаква от незадоволително представяне на 1C. Едва по-късно холдингът започна мегапроект за прехвърляне на всички информационни бази данни в един централизиран сайт със суперсървъри, системи за съхранение за милион+ рубли, сложни хипервайзори и непоносими 1C спирачки във всички клонове.

Но това е съвсем различна история...

Източник: www.habr.com