1С на файловой шаре, и почему она тормозит к пятнице

К этому году в почти каждой конторе, куда нас зовут, стоит 1С. Не как «одна из программ», а как то, вокруг чего живёт вся контора: там и накладные, и зарплата, и склад, и отчётность. Она стала для малого бизнеса тем же, чем Word для секретаря, - её просто ставят, потому что так у всех. И вместе с этим к нам пришёл новый жанр звонков: «база тормозит», «база встала», «база сломалась». Три разных беды, а формулировка одна.

Почти всегда история одинаковая. Есть одна машина, которую назначили сервером, - иногда это выделенный блок, а иногда просто самый мощный компьютер, за которым к тому же сидит главбух. На нём лежит папка с базой, к ней открыт общий доступ, и все остальные подключаются к этой папке по сети. Никакой отдельной программы-сервера нет. Каждый клиент 1С сам лезет в файлы базы через шару, сам читает и пишет. То есть «сервером» тут работает не программа, а обычная файловая шара. И ведёт она себя соответственно.

Разберём три жалобы по очереди, потому что причины у них разные.

«База тормозит». Когда работает один человек, всё летает. Добавляется второй, третий, пятый - и начинается вязкость. Дело в блокировках. Пока один проводит документ, кусок базы заперт, чтобы двое не записали поверх друг друга и не устроили кашу из цифр. Это правильно: без блокировок бухгалтерия быстро превратится в фарш. Но в файловом варианте блокировки грубые. Часто запирается не одна строчка, а целая таблица, и остальные просто ждут в очереди. Пять человек в обычный день этого почти не замечают, а вот в конце месяца, когда все разом закрывают период и лезут в одни и те же регистры, очередь становится осязаемой. Люди сидят и смотрят на песочные часы, а по сети в это время ездят мегабайты файлов туда-сюда, потому что клиент вынужден вычитывать данные через шару целыми кусками.

«База встала». Обычно это уже не про 1С, а про сеть или диск. Файловая база живёт на честном слове сетевого соединения. Моргнул коммутатор, кто-то дёрнул патч-корд ногой под столом, у «сервера» на секунду просела сеть от антивируса, который решил проверить как раз эту папку, - и клиент теряет базу на середине операции. Отдельно стоит помянуть Wi-Fi: пара контор притащила беспроводные точки, посадила на них ноутбук с 1С, и мы честно сказали, что для файловой базы это лотерея. Проводу мы верим, воздуху - нет.

«База сломалась к вечеру пятницы». Это самое неприятное и самое частое. У файловой базы есть индексы - служебные файлы, которые помогают быстро находить записи, что-то вроде оглавления у толстой книги. Пока оглавление совпадает с содержимым, всё быстро. Но если клиент оборвался посреди записи (см. предыдущий абзац), содержимое ушло вперёд, а оглавление осталось старым. База начинает врать или падать. И накапливается это как раз к концу недели: за пять дён обрывов набирается достаточно, чтобы в пятницу вечером, на закрытии, всё посыпалось. У 1С есть «Тестирование и исправление», которое перестраивает эти индексы, но гонять его надо на копии и когда никто не работает, а не в панике поверх живой базы под конец рабочего дня.

Что мы с этим делаем на практике. Волшебной кнопки нет, клиент-серверные СУБД малому бизнесу не по карману (дорого и незачем ради пяти человек), так что лечим тем, что есть.

• Первое - выносим базу на отдельную машину, которая занята только этим, а не работает заодно рабочим местом главбуха; когда за «сервером» никто не сидит и не ставит на него игры, обрывов сразу меньше.
• Второе - нормальная проводная сеть и бесперебойник на этой машине, чтобы моргание питания не рвало запись.
• Третье, и главное - бэкап базы каждый день, автоматически, с копией на другой носитель.

Тут всё ровно как со спамом, про который мы писали осенью: пока гром не грянул, никто не хочет тратить на это время, а после первой потерянной за пятницу базы объяснять ничего уже не нужно.

Мы не обещаем, что файловая 1С после этого станет летать. Она не станет - у неё такой предел, и это честно надо проговорить с заказчиком до того, как берёшь его инфраструктуру на сопровождение. Но большую часть боли можно убрать: не техникой, а порядком. Отдельная машина, бэкап, регламент на «Тестирование и исправление» по расписанию, а не по факту катастрофы. Доступность учётной базы для конторы - это не «сервер вроде включён», это «в пятницу вечером мы закрыли месяц и ушли домой». Вот за это и воюем.

Отдельно скажу про ожидания. Часть заказчиков уверена, что раз база тормозит, надо купить машину помощнее, и всё пройдёт. Иногда помогает, но чаще упираемся не в процессор, а в саму механику файлового доступа: сколько железа ни подкладывай, блокировки и сеть никуда не денутся. Так что прежде чем советовать покупку, мы неделю просто смотрим, где именно затык - в диске, в сети или в очереди на блокировках. Обычно виноват не тот, на кого думали.