Всі розробники 1С так чи інакше тісно взаємодіють із IT-службами та безпосередньо з системними адміністраторами. Але не завжди ця взаємодія проходить гладко. Декілька кумедних історій про це я і хотів би Вам розповісти.
Швидкісний канал зв'язку
Більшість наших клієнтів – це великі холдинги зі своїми великими ІТ-підрозділами. І за резервні копії інформаційних баз зазвичай відповідають фахівці клієнта. Але є й щодо невеликі організації. Спеціально для них у нас є послуга, згідно з якою всі питання, пов'язані з резервним копіюванням всього 1С-ного, ми беремо на себе. Про таку ось компанію і йтиметься у цій історії.
Прийшов новий клієнт на підтримку 1С і, серед іншого, у договорі був пункт, що за резервні копії ми відповідаємо, хоча в штаті у них і був свій системний адміністратор. База клієнт-серверна, як СУБД - MS SQL. Досить стандартна ситуація, але все ж таки був один нюанс: основна база була досить великого розміру, але при цьому місячний приріст був зовсім невеликим. Тобто база містила багато історичних даних. Враховуючи цю особливість, я налаштував плани обслуговування резервного копіювання наступним чином: у першу суботу кожного місяця робилася повна резервна копія, вона була досить важкою, далі щоночі робилася різнизна копія щодо невеликого обсягу і щогодини копія журналу транзакцій. Причому повні та різницеві копії, мало того, що копіювалися на мережевий ресурс, ще й додатково завантажувалися на наш FTP-сервер. Це обов'язкова вимога при наданні цієї послуги.
Все це було успішно налаштовано, пущено в експлуатацію і працювало загалом без збоїв.
Але через кілька місяців у цій організації змінився системний адміністратор. Новий сисадмін почав потроху перебудовувати IT-інфраструктуру компанії відповідно до сучасних віянь. Зокрема, з'явилася віртуалізація, дискові полиці, закривався доступ скрізь і т. д., що, звичайно, не може не радувати. Але не завжди у нього все проходило гладко, часто були проблеми з працездатністю 1С, що викликало деякі розбіжності та нерозуміння з нашою підтримкою. Також, слід зазначити, що стосунки з ним у нас взагалі склалися досить холодні та дещо натягнуті, що тільки збільшувало градус напруженості у разі виникнення якихось проблем.
Але якось уранці виявилося, що сервер цього клієнта недоступний. Я зателефонував системному адміністратору, щоб дізнатися, що трапилося і отримав як відповідь щось на кшталт «У нас сервер впав, працюємо над цим, не до вас». Ну, добре, що працюють. Отже, ситуація під контролем. Після обіду передзвонюю знову, в голосі адміна замість роздратування вже відчувається втома та апатія. Намагаюся прояснити, що сталося, і чи можемо ми якось допомогти? В результаті розмови з'ясувалося таке:
Він переніс сервер на нову систему зберігання даних із щойно зібраним рейдом. Але щось пішло не так і за кілька днів цей рейд благополучно розсипався. Толі контролер згорів, чи то з дисками щось трапилося, не пам'ятаю вже точно, але вся інформація виявилася безповоротно втрачена. А головне полягало в тому, що мережевий ресурс з бекапами теж у процесі будь-яких міграцій опинився на цьому ж дисковому масиві. Тобто було втрачено як саму продуктивну базу, так і всі її резервні копії. І що робити, незрозуміло.
Спокійно, говорю. У нас є ваш нічний бекап. У відповідь — тиша, через яку я розумію, що щойно врятував людині життя. Починаємо обговорювати, як перекинути цю копію на новий, щойно розгорнутий сервер. Але тут виникла проблема.
Пам'ятаєте, я казав, що повна резервна копія була досить великого розміру? Я не дарма робив її раз на місяць у суботу. Справа в тому, що компанія являла собою невеликий завод, який знаходився далеко за містом і інтернет у них був дуже собі. На ранок понеділка, тобто за вихідні, ця копія з горем навпіл встигала провантажитися до нас на FTP-сервер. Але чекати день-два, поки вона завантажиться у зворотний бік можливості не було. Після кількох невдалих спроб перетягнути файл, адмін вийняв жорсткий диск прямого з нового сервера, знайшов десь машину з водієм і швиденько помчав до нас в офіс, благо ми все ж таки в одному місті.
Поки стояли у нас у серверній і чекали, коли файли скопіюються, ми вперше познайомилися, так би мовити, наживо, випили по чашці кави, поспілкувалися в неформальній обстановці. Я поспівчував його горю і з повним гвинтом бекапів відправив назад, спішно відновлювати роботу компанії, що зупинилася.
Надалі всі наші заявки в IT-відділ вирішувалися дуже оперативно і розбіжностей більше не виникало.
Зверніться до вашого системного адміністратора
Якось одного клієнта я дуже довго не міг опублікувати 1С для веб-доступу через IIS. Начебто звичайне завдання, але ось тут ніяк не виходило все запустити. Підключилися місцеві системні адміністратори, пробували різні налаштування та конфігураційні файли. 1С у Інтернеті нормально не хотіла працювати ні в яку. Щось було не так чи то з доменними політиками безпеки, чи то місцевим мудрим фаєрволом, чи ще з чорт знає чим. На N-ій ітерації адмін скидає мені посилання зі словами:
— Спробуй ще раз за цією інструкцією. Там усе досить детально розписано. Якщо не вийде, напиши автору цього сайту, може, він допоможе.
- Ні, - кажу, - не допоможе.
- Чому?
— Я і є автором цього сайту… (
Зрештою без особливих проблем запустили на Apache. ІІS перемогти так і не змогли.
На рівень глибше
Був у нас клієнт – невелике виробниче підприємство. Був вони сервер, така своєрідна «класика» 3 в 1: сервер терміналів + сервер додатків + сервер баз даних. Працювали вони в деякій галузевій конфігурації на базі УПП, користувачів було близько 15-20, продуктивність системи в принципі всіх влаштовувала.
Минав час, все працювало більш-менш стабільно. Але Європа ввела проти Росії санкції, внаслідок чого Росіяни почали купувати переважно продукти вітчизняного виробництва, і справи у цієї компанії різко пішли в гору. Кількість користувачів зросла до 50-60 осіб, відкрилася нова філія, відповідно зросла і документообіг. І ось вже поточний сервер перестав справлятися з різко збільшеним навантаженням, і 1С почала, що називається, «гальмувати». У години пікового навантаження документи проводилися по кілька хвилин, сипалися помилки блокувань, довго відкривалися форми, та й інший букет супутніх послуг. Місцевий системний адміністратор відмахувався від усіх проблем, мовляв: «Це ваша 1С, ви й розбирайтеся». Ми неодноразово пропонували провести аудит системи на продуктивність, але до самого аудиту так і не дійшло. Клієнт просто попросив дати рекомендації щодо усунення проблем.
Ну я сів і написав досить об'ємний лист про те, що необхідно розділити ролі термінального сервера та сервера додатків із СУБД (що, в принципі, раніше вже неодноразово нами й так говорилося). Написав про DFSS на термінальних серверах, про Shared Memory, накидав посилання на авторитетні джерела і навіть запропонував деякі варіанти обладнання. Цей лист дійшов до можновладців у компанії, спустився назад до IT-відділу з резолюцій «Виконувати» і лід загалом торкнувся.
Через якийсь час адмін надсилає мені IP-адресу нового сервера та облікові дані для входу. Говорить, що 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