Байки розробника №4: адмінських

Всі розробники 1С так чи інакше тісно взаємодіють з IT-службами і безпосередньо з системними адміністраторами. Але не завжди це взаємодія проходить гладко. Кілька кумедних історій про це я б і хотів розповісти вам сьогодні.

Швидкісний канал зв’язку

Більшість наших клієнтів – це великі холдинги зі своїми великими IT-підрозділами. І за резервні копії інформаційних баз, як правило, відповідають фахівці клієнта. Але є і відносно невеликі організації. Спеціально для них у нас є послуга, згідно з якою всі питання, пов’язані з резервним копіюванням усього 1С-ного ми беремо на себе. Про таку ось компанію і піде мова в даній історії.

Прийшов новий клієнт на підтримку 1С і, серед іншого, в договорі був пункт, що за резервні копії відповідаємо ми, хоча в штаті у них і був свій системний адміністратор. База клієнт-серверна, як СУБД – MS SQL. Досить стандартна ситуація, але все ж був один нюанс: основна база була досить великого розміру, але при цьому місячний приріст був зовсім невеликим. Тобто база містила багато історичних даних. З огляду на цю особливість, я налаштував плани обслуговування резервного копіювання наступним чином: в першу суботу кожного місяця робили повну резервну копію, вона була досить важкою, далі щоночі робилася разностная копія – відносно невеликого обсягу і кожну годину копія журналу транзакцій. Причому повні і різницеві копії, мало того, що копіювалися на мережевий ресурс, так ще і додатково завантажувалися на наш FTP-сервер. Це обов’язкова вимога при наданні даної послуги.

Все це було успішно налаштовано, пущено в експлуатацію і працювало в загальному то без збоїв.

Але кілька місяців по тому в цій організації змінився системний адміністратор. Новий системний адміністратор почав потроху перебудовувати IT-інфраструктуру компанії відповідно до сучасних віянь. Зокрема, з’явилася віртуалізація, дискові полки, закривався доступ скрізь і вся і т. Д., Що в загальному випадку, звичайно, не може не радувати. Але не завжди у нього все проходило гладко, часто були проблеми з працездатністю 1С, що викликало деякі розбіжності і нерозуміння з нашою підтримкою. Також, треба відзначити, що відносини з ним у нас взагалі склалися досить холодні і кілька натягнуті, що тільки збільшувало градус напруженості в разі виникнення якихось проблем.

Але от якось вранці виявилося, що сервер цього клієнта недоступний. Я подзвонив системного адміністратора, щоб дізнатися, що трапилося і отримав в якості відповіді щось на кшталт «У нас сервер впав, працюємо над цим, не до вас». Ну добре, що працюють. Значить ситуація під контролем. Після обіду передзвонюю знову, в голосі адміна замість роздратування вже відчувається втома і апатія. Намагаюся прояснити, що ж сталося, і чи можемо ми якось допомогти? В результаті розмови з’ясувалося наступне:

Він переніс сервер на нову систему зберігання даних з тільки що зібраних рейдом. Але щось пішло не так і через кілька днів цей рейд благополучно розсипався. Толі контролер згорів, толі з дисками щось трапилося, не пам’ятаю вже точно, але вся інформація виявилася безповоротно загублена. А головне полягало в тому, що мережевий ресурс з резервних копій теж в процесі будь-яких міграцій виявився на цьому ж дисковому масиві. Тобто була загублена як сама продуктивна база, так і всі її резервні копії. І що тепер робити, незрозуміло.

Спокійно, кажу. У нас є ваш нічний бекап. У відповідь – тиша, по якій я розумію, що тільки що врятував людині життя. Починаємо обговорювати, як перекинути цю копію на новий, тільки що розгорнутий сервер. Але і тут виникла проблема.

Пам’ятаєте, я казав, що повна резервна копія була досить великого розміру? Я не дарма робив її раз на місяць по суботах. Справа в тому, що компанія представляла із себе невеликий завод, який знаходився далеко за містом і інтернет у них був сильно так собі. До ранку понеділка, тобто за вихідні, ця копія з горем навпіл встигала прогрузити до нас на FTP-сервер. Але чекати день-два поки вона завантажиться в зворотну сторону можливості не було. Після кількох невдалих спроб перетягнути файл, адмін вийняв жорсткий диск прямого з нового сервера, знайшов десь машину з водієм і швиденько помчав до нас в офіс, благо знаходимося ми все ж в одному місті.

Поки стояли у нас в серверній і чекали, коли файли скопійовано, ми вперше познайомилися, так би мовити, «вживу», випили по чашці кави, поспілкувалися в неформальній обстановці. Я поспівчував його горю і з повним гвинтом бекапов відправив назад, спішно відновлювати зупинилася роботу компанії.

В подальшому, всі наші заявки в IT-відділ вирішувалися дуже оперативно і розбіжностей більш не виникало.

Зверніться до вашого системного адміністратора

Якось раз у одного клієнта я дуже довго не міг опублікувати 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С у всіх філіях.

Ссылка на основную публикацию