Глава 1: Начало истории
Как- то на одном предприятии работал один программист. Новичок только выпустился из ВУЗа и готов был покорять мир. Устроившись на предприятие ООО "Ромашка", он был готов к любым задачам и сложностям.
Но первая задача у него не вызвала энтузиазма, вторая тоже была неинтересной. Его задачи хоть и выполнялись старательно, но из-за недостаточного опыта выполнялись медленно.
И вот, в один прекрасный и солнечный день, нашему энтузиасту прилетела задача: "Обновить 1С:Бухгалтерию".
Но так как обновление конфигурации ему еще не приходилось делать и последствия неправильного обновления еще не коснулись его бестолковой тыквы, радостный, он сначала подумал: "ну наконец-то что-то интересное" - и приступил к работе.
Глава 2: Начало работы
Настал новый день, и программист начал изучать новую информацию по обновлению 1С:Бухгалтерии. На просторах интернета он находил большое множество информации об обновлении типовой конфигурации. Как оказалось, обновление типовой конфигурации не является чем-то сложным.
Необходимо было всего лишь:
- Пройти по следующему пути.
- Выбрать один из подходящих вариантов.
- Если файл, то выбрать файл, скачанный с release1C.ru с расширением .cfu, либо файл подгрузится сам с downloads.v8.1.ru, нужно будет только указать пользователя и пароль.
- Далее также ничего сложного, выбираем версию, объединяем и ждем завершения.
Но конфигурация нашего программиста была типовая, но с большим количеством доработок. Программист начал выполнять вышеописанные действия в тестовой конфигурации, но обновления не произошло. Все действия были выполнены точно по инструкции, но при выборе конфигурации окошко закрывалось и ничего дальше не происходило.
Глава 3: Осознание того, что происходит что-то не то
В начале, ничего не понимая, программист - энтузиаст выполнил типовое обновление несколько раз. После пятого раза было понятно, что инструкция не сработает и нужно искать другие способы обновления. После тщательных поисков в интернете достаточной информации по обновлению не было найдено, но на многих форумах писали, что обновлять нужно будет "вручную".
- "Вручную" - подумал программист. И решил сделать так: "Необходимо было найти обновленную конфигурацию и объединить с той конфигурацией, которую нужно обновить".
И вот теперь снова в поисках, найти уже обновленную конфигурацию не получилось. "Раз не получилось найти, нужно сделать самому." - Подумал программист.
И тут у него появился план: "Можно вытянуть конфигурацию поставщика и обновить ее, так как она то точно является типовой."
Чтобы найти конфигурацию поставщика, ему пришлось последовать следующему пути:
- Открыть окно настройки поддержки.
- Сохранить конфигурацию в файл.
Так программист получил конфигурацию, которую можно обновить типовым способом. Так как конфигурация поставщика не имеет никаких доработок, потому и зовется конфигурацией поставщика, она легко обновилась типовым методом. И вот теперь после обновления у нашего программиста есть обновленная конфигурация, на которую можно наложить доработки, которые есть в конфигурации, которую нужно было обновить.
Глава 4: К слову об испорченной информационной базе
Вот так наш программист получил обновленную конфигурацию, но в чем же была неурядица, о которой мы знаем исходя из названия этой статьи.
А вот у предприятия ООО "Ромашка", на котором работает программист, имеется две базы бухгалтерии, которые необходимо было обновить.
И вот что происходит дальше. Имея на руках две обновленные конфигурации, наш программист с бестолковой тыквой, в рабочей базе делает объединение бухгалтерии с той бухгалтерией, которая не является подходящей обновляемой бухгалтерии.
После объединения с умным видом, ничего не подозревая, нажимает кнопку обновить(F5). Так как это целое обновление, база данных долго обновляется. Ждем... Ждем... Ждем... вот те раз, вылетела. Не выдав ни одного сообщения, просто вылетела. Так как программист все еще не увидел свою ошибку, он ставит обновление еще раз. Но ошибка повторилась. Далее он обращается к коллегам по работе за помощью и получает много подзатыльников и седые волосы начальника отдела ИТ.
Глава 5: Почему нельзя делать так, как сделал наш программист?
За что программист получил по тыкве? И что могло бы произойти, если бы база не вылетела? А ситуация такая, так как конфигурации разные, в одной бухгалтерии есть одни объекты, в другой конфигурации их нет. Куда денутся пользовательские данные, которые принадлежат этому объекту, если при обновлении объект удалится? Ответ будет неприятным: "Данные испарятся, исчезнут, канут в небытие". Даже если предприятие регулярно выполняет резервное копирование, это на длительное время остановило работу предприятия, грозило бы полным матерным словом.
Так вот и делаем вывод: "На сколько сильно провинился программист и почему так делать не стоит? И лучше не повторять ошибок нашего программиста и быть внимательным."
В дополнение к статье
Давайте заглянем немного дальше. Что реально произойдет с молодым специалистом, если эта история не учебная, а рабочая?
День первый: база не поднимается. Начальник отдела ИТ, который поседел не от старости, а от нервов, пытается восстановить базу из резервной копии. Но, а вдруг если копии нет. Программист признается, что «что-то сделал не так». Создается экстренное совещание. Бухгалтерия не работает — это значит, не выставляются счета, не платятся налоги, не начисляется зарплата. Директор звонит владельцу. Владелец звонит начальнику ИТ. Начальник ИТ смотрит на программиста взглядом, который не сулит ничего хорошего.
День второй–третий: привлекаются внешние специалисты — фрилансеры или аутсорсинговые фирмы. Они пытаются вытащить данные из битых индексов, временных таблиц и файлового «мусора». Работа стоит. Предприятие теряет деньги. В малом бизнесе простой бухгалтерии на три дня может означать сорванные контракты, штрафы от налоговой за несданные отчеты и потерянных клиентов.
Итог для программиста: скорее всего, увольнение. Не из-за злобы, а из-за потери доверия. С ним могут даже рассчитаться «по-хорошему», без заявлений, но рекомендации для следующего места работы он уже не получит. Максимум — нейтральная фраза «работал у нас некоторое время». Если повезет, и начнется разбирательство, вскроется еще одна деталь: ни один опытный специалист не взялся бы за обновление такой конфигурации без детального аудита доработок. А наш герой даже не задумался об этом.
Чтобы читатель не подумал, что статья только про ошибки, дадим алгоритм правильных действий. Он длиннее, но безопаснее. Для конфигурации с доработками.
Шаг 0 (за три дня до обновления): успокоиться и понять, что обновление типовой конфигурации с доработками — это мини-проект, а не пятиминутное дело. Составить план.
Шаг 1 (обязательный): сделать резервную копию рабочей базы. Лучше в двух местах: на файловом сервере и на внешнем носителе. Проверить, что копия читается. Сделать выгрузку в DT-файл и отдельно копию файловой базы (если файловый режим). Это займет 15 минут, но спасет жизнь.
Шаг 2: создать точную копию рабочей базы — не «какую-то тестовую конфигурацию», а именно полную копию со всеми доработками и пользовательскими данными (можно обезличенными, но структурно идентичную). Назвать ее «Тест_обновление_дата».
Шаг 3: в тестовой базе провести обновление конфигурации штатным способом — через «Обновление конфигурации» из файла поставки. Никаких объединений разных конфигураций на этом этапе! Только штатное обновление.
Шаг 4: если штатное обновление не проходит (вылетает или пишет ошибку), значит, доработки конфликтуют с новыми объектами типовой конфигурации. Тогда нужно открыть сравнение/объединение, но не для того, чтобы «склеить» конфигурации в лоб, а для ручного разбора конфликтов. Платформа покажет, какие объекты изменены и поставщиком, и вами. Решение по каждому конфликту принимается вручную.
Шаг 5: после успешного обновления тестовой базы — запустить ее. Проверить ключевую отчетность, провести пару документов, посмотреть регистры. Ничего не упало? Данные на месте? Отлично.
Шаг 6: только тогда — повторить процедуру на рабочей базе, предварительно снова сделав резервную копию (на всякий случай — прямо перед обновлением). И в процессе обновления не отходить от компьютера, следить за каждым сообщением.
Шаг 7: после обновления — закрыть день, сформировать регламентированную отчетность и убедиться, что обороты сошлись.
Все действия необходимо делать внимательно и с любовью к своей работе, иначе получится как в истории нашего новичка.
Почему наш программист — не злодей, а жертва системы (и что из этого вынести)
Важно понять: молодой специалист не был дураком или вредителем. Он был жертвой трех факторов:
-
Отсутствия наставничества. На предприятии не было опытного 1С-разработчика, который показал бы правильный путь. «Интернет насоветовал» — классика. Форумчане дают советы под свои конфигурации, не видя ваших доработок.
-
Культуры «сделать быстро». В российских компаниях — особенно в ООО «Ромашка» — не принято закладывать время на тестирование. Задача звучит: «обнови к завтраму». А должна звучать: «запланируй обновление на следующую неделю, предупреди бухгалтерию о возможных перерывах».
-
Самоуверенности. Свежеиспеченный выпускник вуза не знает, чего он не знает. Он думает, что прочитал инструкцию — значит, справится. Настоящие знания приходят только через ушибы и шишки. Но хорошо, если шишки — виртуальные, как в этой статье.
Мораль для всех участников
Для программистов: никогда не беритесь за обновление конфигурации с доработками, если вы не делали это раньше с наставником. Никогда не пропускайте резервное копирование. Всегда тестируйте на копии. И запомните фразу: «Если база вылетела — это полбеды. Беда — если она не вылетела, но данные исчезли».
Для начальников: не бросайте новичков в бой с типовыми конфигурациями, в которые уже влезали другие программисты. У них нет карты подводных камней. Дайте им напарника или оплатите курсы по обновлению 1С. Седые волосы лечатся дорого.
Для бизнеса: информационная система — это не свечка, которую можно воткнуть в розетку и забыть. Это сложный организм. Платите специалистам за регламентные работы, проводите аудиты доработок, делайте резервные копии по расписанию. Экономия на ИТ в итоге выходит дороже, чем прямое попадание в финансовую яму.
А что же наш программист? Эпилог
Статья заканчивается на грустной ноте, но давайте придумаем для героя хороший финал. Итак, после вылета базы и седого начальника программист не уволился (или его не уволили — бывает и такое). Он взял паузу, перечитал документацию, нашел наставника на профильном форуме. Вместе они восстановили базу из битого состояния — частично из временных файлов, частично перепечатывая документы за последние две недели. Это был тяжелый месяц. Но после этого история преподала ему урок, который не даст ни один курс.
Через год он уже сам консультировал новичков и всегда начинал с фразы: «Сначала backup, потом — все остальное. И не трогай объединение, пока не поймешь, что делаешь». Начальник ИТ, хоть и с сединой, стал ему доверять сложные задачи. А ООО «Ромашка» внедрило еженедельное резервное копирование и правило «два тестовых прогона перед боевым обновлением».
Так что история с испорченной информационной базой закончилась не так уж плохо. Хуже было бы, если бы никто не сделал выводов. Надеемся, что читатель этой статьи сделает их без потери рабочих данных.
И помните: программист с бестолковой тыквой — это не приговор. Бестолковой она остается только до тех пор, пока ее владелец не начнет думать, прежде чем нажимать кнопки.
Вступайте в нашу телеграмм-группу Инфостарт