Сите развивачи на 1C на еден или друг начин тесно комуницираат со ИТ услугите и директно со системските администратори. Но, оваа интеракција не оди секогаш без проблеми. Би сакал да ви кажам неколку смешни приказни за ова.
Канал за комуникација со голема брзина
Повеќето од нашите клиенти се големи стопанства со свои големи ИТ оддели. И специјалистите за клиенти обично се одговорни за резервните копии на базите на податоци на информации. Но, има и релативно мали организации. Специјално за нив, имаме услуга според која ги преземаме на себе сите прашања поврзани со резервна копија на сè 1C. Ова е компанијата за која ќе зборуваме во оваа приказна.
Нов клиент дојде да го поддржи 1C и, меѓу другото, договорот вклучуваше клаузула дека ние сме одговорни за резервните копии, иако тие имаа свој системски администратор во персоналот. Клиент-сервер база на податоци, MS SQL како DBMS. Прилично стандардна ситуација, но сепак имаше една нијанса: главната основа беше доста голема, но месечното зголемување беше многу мало. Односно, базата на податоци содржела многу историски податоци. Земајќи ја предвид оваа функција, ги поставив плановите за одржување резервна копија на следниов начин: во првата сабота од секој месец се правеше целосна резервна копија, беше доста тешка, потоа секоја вечер се правеше диференцијална копија - релативно мал волумен и копија од дневникот на трансакции секој час. Покрај тоа, целосните и диференцијалните копии не само што беа копирани на мрежен ресурс, туку и дополнително беа поставени на нашиот FTP сервер. Ова е задолжително барање при обезбедување на оваа услуга.
Сето ова беше успешно конфигурирано, ставено во функција и генерално работеше без неуспеси.
Но, неколку месеци подоцна, системскиот администратор во оваа организација се смени. Новиот системски администратор почна постепено да ја обновува ИТ инфраструктурата на компанијата во согласност со современите трендови. Конкретно, се појави виртуелизација, полиците на дискот, пристапот беше блокиран насекаде и сè итн., што во општиот случај, се разбира, не може да не се радува. Но, работите не му одеа секогаш мазно; често имаше проблеми со перформансите на 1C, што предизвикуваше некои несогласувања и недоразбирања со нашата поддршка. Исто така, треба да се напомене дека нашиот однос со него генерално беше прилично ладен и донекаде затегнат, што само го зголемуваше степенот на напнатост во случај на појава на какви било проблеми.
Но, едно утро се покажа дека серверот на овој клиент не е достапен. Го повикав администраторот на системот за да дознаам што се случило и добив како одговор нешто како „Нашиот сервер падна, работиме на тоа, не зависи од вас“. Па добро е што работат. Тоа значи дека ситуацијата е под контрола. По ручекот, повторно се јавувам и наместо иритација, веќе чувствувам замор и апатија во гласот на администраторот. Се обидувам да дознаам што се случило и дали можеме да направиме нешто за да помогнеме? Како резултат на разговорот, се појави следново:
Тој го премести серверот во нов систем за складирање со ново склопен рација. Но, нешто тргна наопаку и неколку дена подоцна оваа рација безбедно пропадна. Дали контролорот изгоре или нешто се случи со дисковите, не се сеќавам точно, но сите информации беа неповратно изгубени. И главната работа беше што мрежниот ресурс со резервни копии, исто така, заврши на истата низа на дискови за време на различни миграции. Односно, и самата продуктивна база на податоци и сите нејзини резервни копии беа изгубени. И не е јасно што да се прави сега.
Смири се, велам. Ја имаме вашата ноќна резервна копија. Како одговор, настана тишина, со која сфатив дека штотуку спасив живот на еден човек. Почнуваме да разговараме како да ја пренесеме оваа копија на нов, ново распореден сервер. Но и тука се појави проблем.
Се сеќавате кога реков дека целосната резервна копија е доста голема? Не за џабе тоа го правев еднаш месечно во сабота. Факт е дека компанијата беше мала фабрика, која се наоѓаше далеку надвор од градот и нивниот интернет беше многу таков. До понеделник наутро, односно за време на викендот, оваа копија едвај успеа да биде поставена на нашиот FTP сервер. Но, немаше начин да се чека ден-два за да се вчита во спротивна насока. По неколку неуспешни обиди за префрлање на датотеката, администраторот го извади хард дискот директно од новиот сервер, некаде најде автомобил со возач и брзо се упати кон нашата канцеларија, за среќа се уште сме во истиот град.
Додека тие стоеја во нашата серверска соба и чекаа да се копираат датотеките, ние се сретнавме за прв пат, така да се каже, „лично“, испивме шолја кафе и разговаравме во неформален амбиент. Сочувствував со неговата тага и го вратив назад со полн шраф резервни копии, набрзина враќајќи ја стопираната работа на компанијата.
Последователно, сите наши барања до одделот за ИТ беа решени многу брзо и повеќе не се појавија несогласувања.
Контактирајте со вашиот системски администратор
Еднаш, долго време, не можев да објавам 1C за веб-пристап преку IIS за еден клиент. Изгледаше како обична задача, но немаше начин се да започне. Локалните администратори на системот се вклучија и испробаа различни поставки и датотеки за конфигурација. 1C на веб нормално не сакаше да работи на кој било начин. Нешто не беше во ред, или со безбедносните политики на доменот, или со локалниот софистициран заштитен ѕид, или Бог знае што друго. На N-тата повторување, администраторот ми праќа линк со зборовите:
- Обидете се повторно да ги користите овие упатства. Сè е опишано таму во доста детали. Ако не работи, пишете му на авторот на оваа страница, можеби тој може да помогне.
„Не“, велам, „нема да помогне“.
- Зошто?
— Јас сум автор на оваа страница... (
Како резултат на тоа, го лансиравме на Apache без никакви проблеми. IIS никогаш не бил поразен.
Едно ниво подлабоко
Имавме клиент - мало производствено претпријатие. Имаа сервер, еден вид „класичен“ 3 во 1: терминален сервер + сервер за апликации + сервер за бази на податоци. Тие работеа во некоја конфигурација специфична за индустријата базирана на UPP, имаше околу 15-20 корисници, а перформансите на системот, во принцип, одговараа на сите.
Како што минуваше времето, сè работеше повеќе или помалку стабилно. Но, тогаш Европа воведе санкции против Русија, како резултат на што Русите почнаа да купуваат главно домашно произведени производи, а бизнисот за оваа компанија нагло тргна нагоре. Бројот на корисници се зголеми на 50-60 луѓе, беше отворена нова филијала и соодветно се зголеми протокот на документи. И сега тековниот сервер повеќе не можеше да се справи со нагло зголеменото оптоварување, а 1C почна, како што велат, да „забави“. За време на шпицот, документите се обработуваа неколку минути, се појавија грешки во блокирањето, им требаше долго време да се отворат формуларите и целиот друг букет поврзани услуги. Локалниот системски администратор ги отстрани сите проблеми, велејќи: „Ова е вашиот 1C, ќе го сфатите“. Повеќе пати предлагавме да се изврши ревизија на успешност на системот, но тоа никогаш не дојде до самата ревизија. Клиентот едноставно побарал препораки за тоа како да ги реши проблемите.
Па, седнав и напишав прилично долго писмо за потребата да се одделат улогите на терминалниот сервер и серверот за апликации со DBMS (што, во принцип, веќе го кажавме многу пати порано). Пишував за 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“ е за податоци, развивачот логично одлучува и ги распоредува сите бази на податоци таму. Јас дури и поставив планови за одржување, вклучително и резервна копија, за секој случај (иако ние не сме одговорни за ова). Точно, резервните копии беа додадени овде во „Д“. Во иднина, беше планирано повторно да се конфигурира на некој посебен мрежен ресурс.
Проектот започна, консултантите обезбедија обука за тоа како да се работи во новиот систем, беа префрлени остатоци, беа направени некои помали подобрувања и корисниците почнаа да работат во новата информативна база.
Сè одеше добро до еден понеделник наутро кога беше откриено дека недостасува дискот со базата на податоци. Едноставно нема „Д“ на серверот и тоа е тоа.
Понатамошната истрага го откри ова: овој „сервер“ всушност бил работен компјутер на локален системски администратор. Точно, сè уште имаше оперативен систем на сервер. Личниот USB-диск на овој администратор беше приклучен на серверот. И така, администраторот отиде на одмор, земајќи ја со себе својата завртка, со цел да напумпа филмови во неа за патувањето.
Фала му на Бога, тој не успеа да ги избрише датотеките со базата на податоци и успеа да ја врати продуктивната база на податоци.
Вреди да се одбележи дека сите беа генерално задоволни од перформансите на системот лоциран на USB-уред. Никој не се пожали на некаква незадоволителна изведба на 1C. Дури подоцна, холдингот започна мега-проект за пренос на сите информативни бази на податоци на единствена централизирана локација со супер-сервери, системи за складирање за милион+ рубли, софистицирани хипервизори и неподносливи сопирачки 1C во сите гранки.
Но, тоа е сосема друга приказна...
Извор: www.habr.com