Приче програмера 1Ц: администраторске

Сви програмери 1Ц на овај или онај начин блиско комуницирају са ИТ услугама и директно са администраторима система. Али ова интеракција не иде увек глатко. Желео бих да вам испричам неколико смешних прича о овоме.

Брзи комуникациони канал

Већина наших клијената су велики холдинги са сопственим великим ИТ одељењима. А стручњаци за клијенте обично су одговорни за резервне копије база података. Али постоје и релативно мале организације. Посебно за њих имамо услугу према којој преузимамо на себе сва питања везана за прављење резервних копија свега 1Ц. Ово је компанија о којој ћемо говорити у овој причи.

Дошао је нови клијент да подржи 1Ц и, између осталог, уговор је укључивао клаузулу да смо ми одговорни за прављење резервних копија, иако су они имали свог администратора система. Клијент-сервер база података, МС СКЛ као ДБМС. Прилично стандардна ситуација, али још увек је постојала једна нијанса: главна база је била прилично велика, али месечно повећање је било веома мало. Односно, база података је садржала много историјских података. Узимајући у обзир ову функцију, поставио сам планове одржавања резервних копија на следећи начин: прве суботе сваког месеца је направљена потпуна резервна копија, била је прилично тешка, затим је сваке ноћи направљена диференцијална копија – релативно мали обим и копија дневника трансакција сваког сата. Штавише, пуне и диференцијалне копије нису само копиране на мрежни ресурс, већ су и додатно постављене на наш ФТП сервер. Ово је обавезан услов приликом пружања ове услуге.

Све ово је успешно конфигурисано, пуштено у рад и генерално је радило без кварова.

Али неколико месеци касније, администратор система у овој организацији се променио. Нови систем администратор је почео да постепено обнавља ИТ инфраструктуру компаније у складу са савременим трендовима. Конкретно, појавила се виртуелизација, полице за дискове, блокиран приступ свуда и све, итд., Што у општем случају, наравно, не може а да не радује. Али ствари нису увек ишле глатко за њега, често је долазило до проблема са перформансама 1Ц, што је изазивало нека неслагања и неспоразуме са нашом подршком. Такође, треба напоменути да је наш однос са њим генерално био прилично хладан и донекле затегнут, што је само повећавало степен напетости у случају било каквих проблема.

Али једног јутра се испоставило да сервер овог клијента није доступан. Позвао сам систем администратора да сазнам шта се догодило и добио сам као одговор нешто попут „Наш сервер се срушио, радимо на томе, а не на вама“. Па добро је да раде. То значи да је ситуација под контролом. После ручка поново се јављам и уместо иритације већ осећам умор и апатију у администраторском гласу. Покушавам да схватим шта се десило и да ли можемо нешто да урадимо да помогнемо? Као резултат разговора, испоставило се следеће:

Преместио је сервер на нови систем за складиштење са новосастављеним нападом. Али нешто је пошло наопако и неколико дана касније ова рација је безбедно пропала. Да ли је контролер прегорео или се нешто десило са дисковима, не сећам се тачно, али све информације су неповратно изгубљене. А главна ствар је била да је мрежни ресурс са резервним копијама такође завршио на истом дисковном низу током разних миграција. То јест, изгубљена је и сама продуктивна база података и све њене резервне копије. И није јасно шта да се ради сада.

Смири се, кажем. Имамо вашу ноћну подршку. У одговору је настала тишина, по којој сам схватио да сам управо спасио човеков живот. Почињемо да разговарамо о томе како да пренесемо ову копију на нови, новопостављени сервер. Али и овде је настао проблем.

Сећате се када сам рекао да је пуна резервна копија прилично велика? Није било ништа што сам то радио једном месечно суботом. Чињеница је да је компанија била мала фабрика, која се налазила далеко ван града и да им је интернет био тако-тако. До понедељка ујутру, односно током викенда, ова копија је једва успела да се постави на наш ФТП сервер. Али није било начина да се чека дан или два да се учита у супротном смеру. После неколико неуспешних покушаја да пренесе фајл, администратор је директно извадио хард диск са новог сервера, негде пронашао ауто са возачем и брзо одјурио у нашу канцеларију, срећом смо још увек у истом граду.

Док су они стајали у нашој сервер соби и чекали да се фајлови копирају, ми смо се први пут срели, да тако кажем, „лично“, попили шољицу кафе и разговарали у неформалном окружењу. Саосећао сам са његовом тугом и послао га назад са пуном резервом, журно враћајући заустављени рад компаније.

Након тога, сви наши захтеви према ИТ одељењу су врло брзо решени и више није било несугласица.

Обратите се администратору система

Једном, веома дуго, нисам могао да објавим 1Ц за веб приступ преко ИИС-а за једног клијента. Чинило се као обичан задатак, али није било начина да се све покрене. Локални системски администратори су се укључили и испробали различита подешавања и конфигурационе датотеке. 1Ц на вебу обично није желео да ради на било који начин. Нешто није у реду, било са политикама безбедности домена, или са локалним софистицираним заштитним зидом, или Бог зна шта још. На Н-ој итерацији, администратор ми шаље линк са речима:

- Покушајте поново користећи ова упутства. Тамо је све врло детаљно описано. Ако не успе, пишите аутору овог сајта, можда он може да помогне.
"Не", кажем, "неће помоћи."
- Зашто?
— Ја сам аутор овог сајта... (

Као резултат тога, покренули смо га на Апацхе-у без икаквих проблема. ИИС никада није поражен.

Један ниво дубље

Имали смо клијента - мало производно предузеће. Имали су сервер, неку врсту „класичног“ 3 у 1: терминал сервер + сервер апликација + сервер базе података. Радили су у некој индустријској конфигурацији заснованој на УПП-у, било је око 15-20 корисника, а перформансе система су, у принципу, свима одговарале.

Како је време пролазило, све је функционисало мање-више стабилно. Али онда је Европа увела санкције Русији, услед чега су Руси почели да купују углавном производе домаће производње, а посао ове компаније нагло је кренуо узбрдо. Број корисника се повећао на 50-60 људи, отворена је нова експозитура, а тиме се повећао и проток докумената. А сада тренутни сервер више није могао да се носи са нагло повећаним оптерећењем, а 1Ц је почео, како кажу, да „успорава“. У вршним сатима, документи су се обрађивали по неколико минута, долазило је до грешака у блокирању, дуго се отварали обрасци и цео други букет повезаних услуга. Локални администратор система је отклонио све проблеме, рекавши: „Ово је ваш 1Ц, ви ћете то схватити. Више пута смо предлагали да се изврши ревизија учинка система, али до саме ревизије то никада није дошло. Клијент је једноставно тражио препоруке како да реши проблеме.

Па, сео сам и написао прилично дугачко писмо о потреби да се одвоје улоге терминалног сервера и сервера апликација са ДБМС-ом (што смо, у принципу, већ много пута раније рекли). Писао сам о ДФСС-у на терминалним серверима, о Заједничкој меморији, давао линкове ка ауторитативним изворима, па чак и предлагао неке опције за опрему. Ово писмо је стигло до оних на власти у компанији, вратило се ИТ одељењу са резолуцијама „Имплементирати“ и лед је генерално пробијен.

Након неког времена, администратор ми шаље ИП адресу новог сервера и акредитиве за пријаву. Он каже да су тамо распоређене компоненте МС СКЛ и 1Ц сервера, а базе података треба пренети, али за сада само на ДБМС сервер, јер су се појавили проблеми са 1Ц кључевима.

Ушао сам, заиста, све услуге су радиле, сервер није био јако моћан, али ок, мислим да је боље него ништа. За сада ћу пренети базе података да бих некако растеретио тренутни сервер. Завршио сам све трансфере у договорено време, али ситуација се није променила - и даље исти проблеми са перформансама. Чудно је, наравно, па хајде да региструјемо базе података у кластер 1Ц па ћемо видети.

Прође неколико дана, кључеви нису пренети. Питам се у чему је проблем, изгледа да је све једноставно - извадите га са једног сервера, прикључите на други, инсталирајте драјвер и готови сте. Администратор одговара тако што се мучи и говори нешто о прослеђивању портова, виртуелном серверу и тако даље.

Хмм... Виртуелни сервер? Изгледа да виртуелизације никада није било и никада није било... Сећам се прилично познатог проблема са немогућношћу прослеђивања кључа 1Ц сервера виртуелној машини на Хипер-В у Виндовс Сервер 2008. И ево неке сумње почињу да се стварају у мени...

Отварам менаџер сервера - Улоге - појавила се нова улога - Хипер-В. Одем до Хипер-В менаџера, видим једну виртуелну машину, повежем се... И заиста... Наш нови сервер базе података...

Па шта? Инструкције надлежних и моје препоруке су спроведене, улоге су раздвојене. Задатак се може затворити.

После неког времена наступила је садашња криза, нова експозитура је морала да се затвори, оптерећење се смањило, а перформансе система су постале мање-више подношљиве.

Па, наравно, нису могли да проследе кључ сервера виртуелној машини. Као резултат, све је остало како јесте: терминал сервер + 1Ц кластер на физичкој машини, сервер базе података тамо на виртуелном.

И било би лепо да је ово нека врста Шарашкинове канцеларије. Дакле не. Позната компанија чије производе вероватно познајете и видели у релевантним одељењима свих Лентаса и Ауцхана.

Распоред одмора за хард диск

Велика холдинг компанија са амбициозним плановима да преузме свет поново је купила малу компанију са циљем да је укључи у своју мега-корпорацију. У свим одељењима овог холдинга, корисници раде у сопственим базама података, али са идентичном конфигурацијом. И тако смо започели мали пројекат укључивања нове јединице у овај систем.

Пре свега, потребно је поставити производне и тестне базе података. Програмер је примио податке о вези, пријављује се на сервер, види инсталиран МС СКЛ, 1Ц сервер, види 2 логичка диска: диск „Ц“ капацитета 250 гигабајта и диск „Д“ капацитета 1 терабајт. Па, „Ц“ је систем, „Д“ је за податке, програмер логично одлучује и поставља све базе података тамо. Чак сам поставио и планове одржавања, укључујући резервну копију, за сваки случај (иако ми нисмо одговорни за ово). Истина, резервне копије су додате овде у „Д“. У будућности је планирано да се поново конфигурише на неки посебан мрежни ресурс.

Пројекат је отпочео, консултанти су пружили обуку о раду у новом систему, пребачени су остаци, направљена су нека мања побољшања, а корисници су почели да раде у новој информационој бази.

Све је ишло добро до једног понедељка ујутру када је откривено да недостаје диск базе података. Једноставно нема „Д“ на серверу и то је то.

Даља истрага је открила ово: овај „сервер“ је заправо био радни рачунар локалног систем администратора. Истина, и даље је имао серверски ОС. Лични УСБ диск овог администратора је прикључен на сервер. И тако је администратор отишао на одмор, поневши свој шраф са собом, са циљем да у њега убаци филмове за пут.

Хвала Богу, није успео да избрише датотеке базе података и успео је да врати продуктивну базу података.

Важно је напоменути да су сви углавном били задовољни перформансама система који се налази на УСБ диску. Нико се није жалио на незадовољавајуће перформансе 1Ц. Тек касније је холдинг започео мега-пројекат преноса свих база података на једну централизовану локацију са супер-серверима, системима за складиштење за милион+ рубаља, софистицираним хипервизорима и неподношљивим 1Ц кочницама у свим гранама.

Али то је сасвим друга прича...

Извор: ввв.хабр.цом

Додај коментар