Усе распрацоўшчыкі 1С так ці інакш цесна ўзаемадзейнічаюць з IT-службамі і непасрэдна з сістэмнымі адміністратарамі. Але не заўсёды гэтае ўзаемадзеянне праходзіць гладка. Некалькі забаўных гісторый пра гэта я і хацеў бы Вам расказаць.
Хуткасны канал сувязі
Большасць нашых кліентаў - гэта буйныя холдынгі са сваімі вялікімі IT-падраздзяленнямі. І за рэзервовыя копіі інфармацыйных баз, як правіла, адказваюць спецыялісты кліента. Але ёсць і адносна невялікія арганізацыі. Адмыслова для іх у нас ёсць паслуга, паводле якой усе пытанні, злучаныя з рэзервовым капіяваннем усяго 1С-нага мы бярэм на сябе. Пра такую вось кампанію і пайдзе прамову ў дадзенай гісторыі.
Прыйшоў новы кліент у падтрымку 1С і, сярод іншага, у дамове быў пункт, што за рэзервовыя копіі адказваем мы, хаця ў штаце ў іх і быў свой сістэмны адміністратар. База кліент-серверная, у якасці СКБД - MS SQL. Даволі стандартная сітуацыя, але ўсё ж быў адзін нюанс: асноўная база была дастаткова вялікага памеру, але пры гэтым месячны прырост быў зусім невялікім. Гэта значыць база змяшчала шмат гістарычных дадзеных. Улічваючы гэтую асаблівасць, я наладзіў планы абслугоўвання рэзервовага капіявання наступным чынам: у першую суботу кожнага месяца рабілася поўная рэзервовая копія, яна была даволі важкай, далей кожную ноч рабілася рознасная копія - адносна невялікага аб'ёму і кожную гадзіну копія часопіса транзакцый. Прычым поўныя і рознасныя копіі, мала таго, што капіяваліся на сеткавы рэсурс, дык яшчэ і дадаткова загружаліся на наш FTP-сервер. Гэта абавязковае патрабаванне пры аказанні дадзенай паслугі.
Усё гэта было паспяхова наладжана, пушчана ў эксплуатацыю і працавала ўвогуле тое без збояў.
Але праз некалькі месяцаў у гэтай арганізацыі памяняўся сістэмны адміністратар. Новы сісадмін пачаў патроху перабудоўваць IT-інфраструктуру кампаніі ў адпаведнасці з сучаснымі павевамі. У прыватнасці, з'явілася віртуалізацыя, дыскавыя паліцы, зачыняўся доступ усюды і ўся і т. д., што ў агульным выпадку, вядома, не можа не цешыць. Але не заўсёды ў яго ўсё праходзіла гладка, часта былі праблемы з працаздольнасцю 1С, што выклікала некаторыя рознагалоссі і неразуменні з нашай падтрымкай. Таксама, трэба адзначыць, што адносіны з ім у нас увогуле склаліся дастаткова халодныя і некалькі нацягнутыя, што толькі павялічвала градус напружанасці ў выпадку ўзнікнення нейкіх праблем.
Але вось неяк раніцай выявілася, што сервер гэтага кліента недаступны. Я патэлефанаваў сістэмнаму адміністратару, каб даведацца, што здарылася і атрымаў у якасці адказу нешта накшталт "У нас сервер упаў, працуем над гэтым, не да вас". Ну, добра, што працуюць. Значыць сітуацыя пад кантролем. Пасля абеду ператэлефаноўваю зноў, у голасе адміна замест раздражнення ўжо адчуваецца стомленасць і апатыя. Спрабую растлумачыць, што ж здарылася, і ці можам мы неяк дапамагчы? У выніку размовы высветлілася наступнае:
Ён перанёс сервер на новую сістэму захоўвання дадзеных з толькі што сабраным рэйдам. Але нешта пайшло не так і праз некалькі дзён гэты рэйд рассыпаўся. Толі кантролер згарэў, толі з дыскамі нешта здарылася, не памятаю ўжо дакладна, але ўся інфармацыя аказалася незваротна страчана. А галоўнае складалася ў тым, што сеткавы рэсурс з бэкапамі таксама падчас усякіх міграцый апынуўся на гэтым жа дыскавым масіве. Гэта значыць, была страчана як сама прадуктыўная база, так і ўсе яе рэзервовыя копіі. І што зараз рабіць, незразумела.
Спакойна, кажу. У нас ёсць ваш начны бэкап. У адказ - цішыня, па якой я разумею, што толькі што выратаваў чалавеку жыццё. Пачынаем абмаўляць, як перакінуць гэтую копію на новы, толькі што разгорнуты сервер. Але і тут узнікла праблема.
Памятайце, я казаў, што поўная рэзервовая копія была даволі вялікага памеру? Я не дарма рабіў яе раз у месяц па суботах. Справа ў тым, што кампанія ўяўляла сабой невялікі завод, які знаходзіўся далёка за горадам і інтэрнэт у іх быў моцна так сабе. Да раніцы панядзелка, гэта значыць за выходныя, гэтая копія з горам напалову паспявала прагрузіцца да нас на FTP-сервер. Але чакаць дзень-два пакуль яна загрузіцца ў адваротны бок магчымасці не было. Пасля некалькіх няўдалых спроб перацягнуць файл, адмін дастаў цвёрдую кружэлку прамога з новага сервера, знайшоў дзесьці машыну з кіроўцам і хуценька памчаўся да нас у офіс, балазе знаходзімся мы ўсё жа ў адным горадзе.
Пакуль стаялі ў нас у сервернай і чакалі, калі файлы скапіююцца, мы ўпершыню пазнаёміліся, так бы мовіць, "ужывую", выпілі па кубку кавы, пагутарылі ў нефармальнай абстаноўцы. Я паспачуваў яго гору і з поўным вінтом бэкапаў адправіў назад, спешна аднаўляць спыненую працу кампаніі.
У наступным, усе нашы заяўкі ў ІТ-аддзел вырашаліся вельмі аператыўна і рознагалоссяў больш не ўзнікала.
Звярніцеся да вашага сістэмнага адміністратара
Неяк раз у аднаго кліента я вельмі доўга не мог апублікаваць 1С для вэба-доступу праз IIS. Быццам бы радавая задача, але вось тут ніяк не атрымлівалася ўсё запусціць. Падключыліся мясцовыя сістэмныя адміністратары, спрабавалі розныя наладкі і канфігурацыйныя файлы. 1С у інтэрнэце звычайна не жадала працаваць ні ў якую. Нешта было не так ці то з даменнымі палітыкамі бяспекі, ці то мясцовым мудрагелістым фаервалам, ці яшчэ з чорт ведае чым. На N-ай ітэрацыі адмін скідае мне спасылку са словамі:
- Паспрабуй яшчэ раз па гэтай вось інструкцыі. Там усё даволі падрабязна распісана. Калі не атрымаецца, напішы аўтару гэтага сайта, можа ён дапаможа.
- Не, - кажу, - не дапаможа.
- Чаму?
- Я і ёсць аўтар гэтага сайта ... (
У выніку без асаблівых праблем запусцілі на Apache. IIS перамагчы так і не змаглі.
На ўзровень глыбей
Быў у нас кліент - невялікае вытворчае прадпрыемства. Быў у іх сервер, такая своеасаблівая "класіка" 3 у 1: сервер тэрміналаў + сервер прыкладанняў + сервер баз дадзеных. Працавалі яны ў некаторай галіновай канфігурацыі на базе УПП, карыстачоў было ў раёне 15-20, прадукцыйнасць сістэмы ў прынцыпе ўсіх уладкоўвала.
Ішоў час, усё працавала больш-менш стабільна. Але вось Еўропа ўвяла супраць Расіі санкцыі, з прычыны чаго Расіяне пачалі купляць пераважна прадукты айчыннай вытворчасці, і справы ў гэтай кампаніі рэзка пайшлі ў гару. Колькасць карыстальнікаў вырасла да 50-60 чалавек, адкрыўся новы філіял, адпаведна вырас і дакументаабарот. І вось ужо бягучы сервер перастаў спраўляцца з рэзка ўзрослай нагрузкай, і 1С пачатку, што называецца, "тармазіць". У гадзіны пікавай нагрузкі дакументы праводзіліся па некалькі хвілін, сыпаліся памылкі блакіровак, доўга адкрываліся формы, ну і ўвесь іншы букет спадарожных паслуг. Мясцовы сістэмны адміністратар адмахваўся ад усіх праблем, маўляў "Гэта ваша 1С, вы і разбірайцеся". Мы неаднаразова прапаноўвалі правесці аўдыт сістэмы на прадукцыйнасць, але да самага аўдыту так справа і не дайшло. Кліент проста папрасіў даць рэкамендацыі па ўхіленні праблем.
Ну я сеў і напісаў даволі аб'ёмны ліст аб тым, што неабходна падзяліць ролі тэрмінальнага сервера і сервера прыкладанняў з СКБД (што, у прынцыпе, раней ужо неаднаразова намі і так гаварылася). Напісаў пра DFSS на тэрмінальных серверах, пра Shared Memory, накідаў спасылак на аўтарытэтныя крыніцы і нават прапанаваў некаторыя варыянты па абсталяванні. Гэты ліст дайшоў да ўлада заможных у кампаніі, спусцілася назад у IT-аддзел з рэзалюцый "Выконваць" і лёд увогуле тое крануўся.
Праз нейкі час адмін дасылае мне айпішнік новага сервера і ўліковыя дадзеныя для ўваходу. Кажа, што MS SQL і кампаненты сервера 1С тамака разгорнутыя, і трэба перанесці базы, але пакуль толькі на сервер СКБД, бо ўзніклі нейкія праблемы з ключамі 1С.
Зайшоў сапраўды запушчаныя ўсе службы, сервер не вельмі магутны, ну добра, думаю, лепш, чым нічога. Перанясу пакуль базы дадзеных, каб хоць неяк разгрузіць бягучы сервер. У абумоўлены час выканаў усе пераносы, але сітуацыя не змянілася - усё тыя ж праблемы прадукцыйнасці. Дзіўна, вядома, ну што ж, зарэгіструем базы ў кластары 1С, там паглядзім.
Праходзіць некалькі дзён, ключы так і не перанесены. Цікаўлюся, у чым праблема, быццам бы там усё проста - дастаў з аднаго сервера, уторкнуў у іншы, паставіў драйвер і гатова. Адмін у адказ юліт, кажа нешта пра пракід партоў, віртуальны сервер і іншае.
Хм... Віртуальны сервер? Нібыта ніколі ніякай віртуалізацыі і іх не было… Успамінаю пра даволі вядомую праблему з немагчымасцю пракіду сервернага ключа 1С у віртуальную машыну на Hyper-V у Windows Server 2008. І тут у мяне пачынаюць закладвацца некаторыя падазроны…
Адкрываю дыспетчар сервера – Ролі – з'явілася новая роля – Hyper-V. Заходжу ў дыспетчар Hyper-V, бачу адну віртуальную машыну, падключаюся… І сапраўды… Наш новы сервер баз дадзеных…
Ну а што? Указанні начальства і мае рэкамендацыі выкананы, ролі разнесены. Задачу можна зачыняць.
Праз некаторы час здарыўся зараз ужо крызіс, новы філіял прыйшлося закрыць, нагрузка знізілася, прадукцыйнасць сістэмы стала больш-менш ніштаватай.
Ну а серверны ключ, вядома ж, пракінуць у віртуальную машыну так і не змаглі. У выніку ўсё як ёсць і пакінулі: сервер тэрміналаў + кластар 1С на фізічнай машыне, сервер баз дадзеных тамака жа ў віртуальнай.
І добра было б гэта якая-небудзь шарашкіна кантора. Дык не. Вядомая кампанія, прадукцыю якой вы напэўна ведаеце і бачылі ў адпаведных аддзелах усялякіх Стужак і Ашанаў.
Графік водпускаў жорсткіх дыскаў
Адзін буйны холдынг з амбіцыйнымі планамі захапіць мір у чарговы раз купіў невялікую кампанію з мэтай уключыць яе ў сваю мегакарпарацыю. Ва ўсіх падраздзяленнях гэтага холдынгу карыстачы працуюць у сваіх базах, але з ідэнтычнай канфігурацыяй. І вось у нас пачаўся невялікі праект па ўключэнні новага падраздзялення ў гэтую сістэму.
Перш за ўсё неабходна разгарнуць прадуктыўную і тэставыя базы. Распрацоўнік атрымаў дадзеныя для падлучэння, заходзіць на сервер, бачыць усталяваны MS SQL, сервер 1С, бачыць 2 лагічных дыска: дыск "З" на 250 гігабайт і дыск "D" аб'ёмам 1 тэрабайт. Ну "C" - гэта сістэма, "D" для дадзеных, лагічна вырашае распрацоўшчык і разгортвае ўсе базы менавіта там. Нават планы абслугоўвання, у тым ліку рэзервовае капіраванне, на ўсялякі выпадак наладзіў (хоць мы за гэта і не адказваем). Праўда бэкапы складаліся тутака ж на «D». У далейшым планавалася пераналадзіць ужо на які-небудзь асобны сеткавы рэсурс.
Праект стартаваў, кансультанты правялі навучанне па працы ў новай сістэме, былі перанесены рэшткі, выкананы нейкія невялікія кропкавыя дапрацоўкі і карыстальнікі пачалі працаваць ужо ў новай інфармацыйнай базе.
Усё ішло добра, пакуль аднойчы раніцай у панядзелак не выявілася, што кружэлка з базамі дадзеных знікла. Проста няма "D" на серверы і ўсё.
Далейшае расследаванне выявіла вось што: насамрэч гэты "сервер" быў працоўным кампутарам мясцовага сістэмнага адміністратара. Праўда стаяла на ім усё ж серверная АС. У сервер быў уваткнуты асабісты USB-дыск гэтага адміна. І вось адміністратар з'ехаў у водпуск прыхапіўшы з сабой і сваю шрубу, з мэтай напампаваць на яго фільмаў у дарогу.
Дзякуй Богу, файлы баз дадзеных ён выдаліць не паспеў і прадуктыўную базу ўдалося аднавіць.
Характэрна тое, што ўсіх, увогуле тое, уладкоўвала прадукцыйнасць сістэмы, размешчанай на USB-дыску. На нейкую нездавальняючую працу 1С ніхто не скардзіўся. Гэта ўжо пазней у холдынгу пачаўся мегапраект па пераносе ўсіх інфармацыйных баз на адзіную цэнтралізаваную пляцоўку з супер-серверамі, СГД за мільён+ рублёў, наварочанымі гіпервізарамі і невыноснымі тормазамі 1С ва ўсіх філіялах.
Але гэта ўжо зусім іншая гісторыя…
Крыніца: habr.com