Байки разработчика №2: эпикофейлические
Горшочек, не вари!
Данная история произошла несколько лет назад, в самом начале моей карьеры разработчика 1С.
Появился у нас в компании проект по оптимизации работы одной очень высоконагруженной базы одного очень большого и уважаемого клиента. Клиент был с настолько параноидальной службой безопасности, что никакого удаленного доступа к серверам извне не было и быть не могло. Для подключения к базам прямо к нам в офис была проведена отдельная локальная сеть с аппаратным VPN и установлены рабочие станции со строго обговоренным софтом. Разумеется, без прав локального администратора.
Как и любой другой проект подобного рода, начинался он со сбора данных. Предполагалось, что мы сначала в течении месяца будем собирать различные показатели, а потом уже займемся оптимизацией самой информационной базы. Как и сколько времени в этой забюрократизированной обстановке ушло на настройку ЦУП, это материал для отдельной истории. Но вот, в какой-то момент, это свершилось, ЦУП был настроен и запущен. После чего, эксперт, который вел данный проект (Дима, привет!), сел в свою роскошную машину и поехал путешествовать по нашей необъятной Родине, и дальше-больше - в ближнее зарубежье. Я же тогда, на самом деле еще мало что знал и умел, но уже считался вполне ответственным разработчиком. Поэтому перед отъездом Дмитрий поручил мне очень важное и серьезное задание: 2 раза в день, в момент пиковой нагрузки, я должен был подходить к тому самому секретному компьютеру и запускать замеры в ЦУП, а через час выключать их. Инструкции были предельно просты и понятны:
- Смотри, нажимаешь вот эту вот зелененькую кнопочку «плей», побежали разные графики, ждешь час, затем нажимаешь вот эту вот кнопку – «стоп». Все.
Что может быть проще, правда? Зря я что ли 5 лет на матфаке учился?
Всю неделю я строго соблюдал этот ритуал утром и вечером. И все было хорошо, до последнего дня. После обеда, в пятницу, я как обычно запустил сбор данных, а дальше… Ну вы знаете как это бывает… Пятница, вечер, надо доделать какие-то неотложные дела, добить какие-то задачи, после работы отвести жену к теще, по пути заехать в один магазин, второй и т.д. В общем, я уехал с работы, полностью забыв про этот злополучный ЦУП.
Утро субботы началось со звонка. Встали ВСЕ 1С-ные базы у клиента. Ахтунг и катастрофа! Наш эксперт где-то между Джейрахом и Пасанаури, вне зоны доступа сети. Главный админ клиента тоже на какой-то там даче и недоступен. Пытаемся по телефону разобраться, в чем причина? Кое-как выясняется, что кончилось место на диске, поэтому служба агента 1С встала. Вот тут я уже начал кое-что подозревать…
Как вы помните, никакой удаленки нет. Компьютер мало того что изолирован от сети интернет, так еще и вне нашей локальной сети. Делать нечего – еду на работу. Пока собирался и ехал, админы смекнули, что все место занято логами ЦУПа и сделали то, что показалось им наиболее разумным - вырубили его нафиг через диспетчер задач. Идем дальше. Просто так удалить логи с диска нельзя - потеряем данные замеров. Кое-как нашли достаточно места на сетевом ресурсе и скопировали туда файлы. Работа вроде бы возобновилась.
Утро воскресенья началось со звонка. Встали ВСЕ 1С-ные базы у клиента. Ахтунг и катастрофа дубль два! Вся паника по новой – закончилось место. Но как так-то? ЦУП же выключили? В спешке снова еду на работу, перекидываю логи, чтобы высвободить место. А они все растут и растут, черт их подери! Под страхом самых извращенных экзекуций администраторы запретили мне вообще что-либо запускать или что-то настраивать. Весь остаток воскресенья я занимался тем, что сидел у компьютера и копировал логи на шару, чтобы базы опять не встали.
Только поздно ночью на связь вышел Дима и рассказал, что нужно всего лишь удалить один маленький файлик на сервере 1С. Уже потом, пару недель спустя, я прочитал о нем в одной всем известной «настольной» книге, ну а в тот день, без сил, замученный поехал домой отсыпаться.
В понедельник утром нашу учетную запись заблокировали до возвращения Дмитрия из отпуска, а на мой счет было сказано вполне недвусмысленно: «Чтобы больше мы ЕГО у нас не видели!».
Вот так вот для меня закончился мой первый проект по оптимизации.
Два раза в одну воронку
Крупный холдинг. 18 информационных баз с идентичной конфигурацией, расположены по всей стране. Обновление происходит раз в неделю и представляет из себя тот еще ритуал: файл поставки надо заблаговременно подготовить, выложить в облако, убедиться, что во всех филиалах он прогрузился (даже в 2018 году в некоторых регионах интернет работает медленнее, чем типовая ERP), проверить, что везде создались резервные копии (мы за это вроде как не отвечаем, но горький опыт научил подстраховываться), затем на каждом филиале запустить вручную скрипт обновления и убедиться, что он отработал без ошибок. Часто в последний момент обнаруживается, что в поставку надо включить еще вот эту вот задачку и вот это мелкое исправление, ведь следующее обновление только через неделю.
Так было и в тот раз. Опытный разработчик с многолетним стажем в спешке ошибся в одной строке при переносе задачи на боевой контур. Ошибка оказалось критичная, обнаружилась уже после обновление всех баз.
Ну что ж делать? Разработчик быстро исправляет код. Никому не дает протестировать:
- Да там фигня... Я ведь не могу ошибиться два раза в одной строчке?
Через час обновляли 18 филиалов в третий раз.
Разработчик, который смог
История, рассказанная коллегой в скайпе.
[Коллега]: Жил-был «Разработчик, который смог!». У него был наряд на разработку. Он хотел открыть тестовую, но промахнулся, и открыл продуктив...
[Коллега]: Но разве это могло остановить «Разработчика, который смог»? Нет!
[Я]: А при обновлении он не понял, что там как-бы люди сидят? ))
[Коллега]: Более того, он видит, что конфа на поддержке... Но думаешь это могло остановить «Разработчика который смог»? Нет!
[Коллега]: Он снимает конфигурацию с поддержки (!) и пилит свой модиф в обход всех хранилищ...
[Я]: Это жееееесть! Добей историю, динамическим обновлением )))
[Коллега]: Обновляет... Система говорит: «В базе 18 активных сеансов!». Но разве это могло остановить «Разработчика который смог»? Нет и еще раз нет!
[Коллега]: Он обновляет базу и передает задачу в тест...
[Коллега]: Консультант не может найти наряд... и только потом, спустя долгое время он понимает, что промахнулся.
[Коллега]: Я должен был его отругать...
[Коллега]: Я ему звоню... а сам ржу в трубку...
[Коллега]: Я просто не понимаю... КАК???
Транспортный коллапс
История, рассказанная коллегой и записанная с его слов.
Происходило это в крупной логистической компании. Большинство бизнес-процессов сосредоточены в одной информационной базе. Конкурентных пользователей на 2012 год – около 3000 человек из всех регионов страны.
Поставили простую задачу. По ней сделал свой регистр сведений, в который пишутся данные при проведении некоторых документов. Хоть видов документов и немного, но количество этих документов в день - огромное. По идее, добавленная мною операция записи в регистр не должна сильно нагрузить систему. Но в реализации задачи был один нюанс - при записи набора, свойство «Перезаписывать» устанавливалось в «Ложь». То есть каждое проведение документа добавляло записи в регистр. Это было необходимо по условиям задачи, но практически не влияло на производительность, т.к. по условиям отборам там всегда было 1-10 записей.
Тестирование функционала прошло успешно. Провели несколько десятков документов, убедились, что записи в регистре верные, ничего подозрительного не заметили и отправили в продуктив.
В ту злополучную пятницу утром сделали обновление боевой базы, и пользователи начали работать. 3000 человек бодро набивали документы и регистр стал наполняться данными. Проверив, что всё идёт хорошо, мы через несколько часов отправились домой со спокойной душой (работаем в разных часовых поясах с основными пользователями информационной базы).
Надо отметить, что серверы, на которых работала ИБ – чуть ли не одни из самых мощных в России, используемых под 1С. Но через несколько часов "что-то пошло не так" (с).
Пользователи стали отмечать снижение производительности системы. Все операции стали замедляться. Отклики на любые действия становились всё дольше. Нагрузка на оборудование неуклонно возрастала. Пока ИТ-отдел разбирался в чём дело, работа в системе практически встала. Оборудование не справлялось, очереди на дисках были длиннее, чем в отделениях Почты России. Было бы оборудование слабее, проблема бы обнаружилась почти сразу. Но мощнейшие серверы героически сопротивлялись моим кривым рукам полдня.
"Со слов" MSSQL самым тяжелым запросом внезапно стал запрос на чтение в моём регистре. Хотя я никаких чтений не делал. Довольно быстро обнаружилась и проблема в коде 1С. Я забыл установить отборы на набор записей. Если бы свойство «Перезаписывать» было бы установлено в «Истина», то ошибку я бы сразу обнаружил, т.к. каждая запись чистила бы весь регистр. А в нашем случае этого не происходило. На примере десятка документов, конечно, никаких потерь производительности мы не заметили. Но когда регистр стал наполняться десятками и сотнями тысяч строк - системе каждый раз приходилось проверять весь регистр на совпадение записей.
К тому времени, со слов некоторых пользователей, уже случился транспортный коллапс, т.к. автомобили не получали документы из 1С и не могли покинуть пункты разгрузки.
Вот так, «всего лишь» забыв поставить отбор в наборе записей, я положил одну из крупнейших баз 1С в России.
P. S. Смотрите также:
- Байки разработчика №1: детективные
- Байки разработчика №2: эпикофейлические
- Байки разработчика №3: страшные истории...
- Байки разработчика №4: админские
Вступайте в нашу телеграмм-группу Инфостарт
Байки разработчика 1С Эпик фейл
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
С 1998 года я писал код в 1С сам, руками, от первой строки до последней. В марте 2026 я рассказывал, как проект на пять месяцев ИИ воспроизвёл за час. Прошло полгода, и теперь я не пишу код совсем, я даже не проверяю его и при этом закрываю 30-40 задач в месяц. Это история о том, что осталось от программиста, когда из его работы ушёл код, почему у одних коллег этот переход получается за месяц, а у других не получается вообще и почему ИИ без опыта за плечами это умножение на ноль.
20.10.2026 5185 GarriSoft 377
О жизни 1C:Бухгалтерия Бесплатно (free)
Как я считаю стоимость своего часа, почему не извиняюсь за цену и что отвечаю на «дорого». Без теории — только то, что работает в разговоре с заказчиком.
11.09.2026 4402 qwerty1414 73
О жизни Россия Бесплатно (free)
Расскажу, как это было у меня. Собеседования я не умею проходить от слова совсем, особенно когда начинают задавать вопросы типа: • Что такое структура? • Что такое соответствие? • Чем соответствие отличается от структуры? • Как обратиться к общему модулю из формы документа? • Как надо обновлять доработанную конфигурацию?
28.07.2026 6095 chuevsf 169
О жизни Россия Бесплатно (free)
Моё личное мнение о перспективах ИИ в среде 1С.
23.06.2026 5317 1c-intelligence 114
30 лет в 1С, 51 год, жёсткие требования к формату работы. За 1.5 месяца нашёл работу, используя DeepSeek как персонального HR-ассистента. Один раз настроил, отправил три своих резюме - дальше просто скидывал вакансии в чат и наговаривал ощущения через микрофон. ИИ анализировал, отсеивал фейки, писал сопроводительные письма, готовил к собеседованиям и разбирал ошибки. Результат: 127 откликов, 2 оффера, выход на работу 1 июня с достойной зарплатой (гибрид, к сожалению, мы с ним не нашли)
20.05.2026 9262 GarriSoft 227
О жизни Россия Бесплатно (free)
В далеком 2007 году я услышал впервые слово «Инфостарт» от своих коллег по работе и нашел этот сайт в Интернете, а 29.06.2007г. успешно зарегистрировался на нем. В течение долгих лет я был «молчуном»: не выкладывал никаких наработок и не писал статей. Просто читал, время от времени, и получал на сайте информацию.
14.05.2026 6073 chuevsf 207
О жизни Россия Бесплатно (free)
Еще совсем недавно у программистов 1С было всё хорошо. Задачи на выполнение сыпались, как из рога изобилия. Счетчик времени зашкаливало от быстроты их выполнения. Чуть ли не каждый месяц был новый рекорд. Новые идеи генерировались бизнесом одна за другой. Но общее состояние экономики в России в 2026 году уже давали о себе знать, и группу компаний также стало лихорадить.
17.04.2026 12020 chuevsf 244
Личные заметки о том, как 1С-разработка столкнулась с вызовом времени. От FoxPro до "гаражной инженерии" - тридцать лет по одним и тем же граблям.
02.04.2026 12949 GarriSoft 280
те, кто пока не делает бекапов;
те, кто делает бекапы;
те, кто делает и проверяет бекапы.
Восстановили последний бэкап без сбоев пятидневной давности как рабочую базу.
Восстановили последний сбойный бэкап.
Универсальной обработкой перетащил документы из сбойной базы в рабочую. По журналу отобрал добавленные за это время справочники, и тоже их перенес.
Вот в наше время были фейлы!
Я начал общение с Windows 3.1 на рабочем компе , удалив корневой каталог Windows с помощью Волков коммандера из Dos. А комп был один на всю лабораторию.
1. Сотрудник неделю работает над проектом автоматизации ответственного хранения в копии. Ночью накатываю обновление с ИТС в основной базе. Думаю надо и копии для разработчиков на свежие обновить...сотрудник званого начал разработку автоматизации ответственного хранения ))
2. На сервере 10 рейд из 12 штук SAS дисков. Контроллер показывает, что сразу три диска вышли из строя. Горячая замена не отрабатывает - ошибки не сбрасываются. Готовимся к перезагрузке сервера. Даю команду системным администраторам подготовится к перезагрузке: проверить наличие копий всех баз. Отрапортовали что копии сделаны, все перепроверили. Перегружаем сервер, рейд разваливается и не собирается. Что ж, были готовы. Восстанавливаем базы на дублирующем сервере... выясняется из 23 баз 1 база не восстанавливается - битый BAK как последний так и предпоследний.
Нашлась копия на чьем то компьютере от прошлого года только. В нашем городе нет компании, которая могла бы вытащить из рейда другие копии этой базы (основная причина что нет такого объема диска, на который можно скопировать все образы всех дисков рейда и программно пересобрать рейд). Пришлось отправлять диски вместе сервером в Москву. Где за 120 к.деревянных нам вытащили копию базы месячной давности, развёрнутую в SQL одним из программистов 1С для своей работы, т.к. основная база и ее BAK (все 30 штук) были битые (копируются но не восстанавливаются). Мораль, если у вас есть БАКапы, это еще не значит что вы сделали копии базы))
(3) Было дело, франч, обновить 77, приезжаю, запускаю копию и запускаю установку обновы в каталог по умолчанию. После установки обновы, обнаруживаю, что до меня рабочая база была в каталоге куда эта обнова встала, перезаписав все файлы рабочей базы, копирование к сожалению делалось дольше чем установка обновы..... Это наверное самое сильное впечатление за всю карьеру
В основном такое: обновили бухню в отраслевом решении и перестало все работать, ибо в отдельном ядре бухгалтерия не обновлена, и его механизмы еще не знают, что "мудрые" 1С-неги, разрабатывающие типовые решения, решили перенести функции создания временного каталога и его убития в другой модуль. Да, в итоге все сломалось, но внутреннее тестирование не дало выпустить релиз. Короче, скукотища. И только сотрудники Усатого не дают совсем заскучать...
Еще интересная область эпик фейлов - интеграция с другими системами, и логика ее работы. Если архитектура интеграции не достаточно защищена от ошибок - могут возникать проблемы. Например, у нас недавно был случай - в карточку контрагента добавили новый типовой дополнительный реквизит (статус клиента). Безобидная операция вполне. После чего обработкой этот самый статус присвоили (после этого случая в подобных обработках ставим ОбменДанными.Загрузка = Истина). Несколько тысяч карточек контрагентов пометились к изменению в одном из планов обмена, который отвечал за обмен со сторонней системой. В эту систему были заново высланы карточки клиентов, а она в свою очередь по всем этим карточкам выслала клиенту СМС-ки об изменениях.
Вывод у меня один: ничего и ничто нельзя делать в спешке и в завале, даже если "срочно, надо вчера!". Жили до этого как-то? жили! Проживут еще 1-2-3 дня/недели.
Тоже история: приехали к клиенту, это было давно правда. А там файловая локальная база, постоянно вылетает с ошибкой SDBL. Сразу определили что проблема в нехватке места на жестком диске где расположена база. Посмотрели - что же можно почистить. Сразу в глаза бросилась "Корзина" просто с колоссальным числом файлов. Да и место она занимала столько, что если ее очистить, то еще баз на 5 таких же места хватит. Ну вот - мы ее и почистили...
Вечером клиент звонит, орет матом....
- Зачем вы корзину почистили, кто вам позволил?
Мы:
- Так это же "Корзина", там обычно то что уже не нужно.
Клиент:
- Как так, корзина - это аналог коробки для документов, вот мы там и хранили все наши важные электронные документы.
Мы в шоке...
Такое у меня раз в пару лет бывает обязательно.
Перед нажатием на кнопку "загрузить" вместо "выгрузить" срабатывает рефлекс "в окне файла ничего не должно быть" и "не должно возникать дополнительных вопросов".
Однажды на 7.7 при каком-то небольшом редактировании (добавление кнопки с обработкой в документ) в журнале налоговых накладных стерлись данные за последний месяц. Я в приступе мании преследования. Поднимаю сделанный бакап, в нем все есть. Копирую выброчно файлы из бакапа в рабочую и запускаю тестирование.
Разбираюсь что могло быть по журналу регистрации. Оказывается, в процессе последней реструктуризации месяц назад (до моего появления там) был сбой (реструктуризация не завершена) и в каталоге NewStru остались файлы налоговых накладных. Последняя реструктуризация почему-то (возможно из-за моих прав) не почистила перед новой реструктуризацией этот каталог и все что там было перенеслось в рабочую базу. Хорошо что бакап делался винраром, а не выгрузкой или сохранением, как обычно.
Восстановить данные можно было бы, а объяснить почему возникла проблема ("доказать что ты не верблюд") - нет.
Пришел накатывать обновления, всех выгнал из базы, запустил ручной бэкап через effector saver.
В процессе накатывания обновления произошло отключение света и база "запоролась".
Восстановил из бэкапа, обновил, всё путём.
И тут оказывается, что в базе данные 2-х летней давности...
Выяснилось, что какое-то время их обслуживал какой-то там мальчик, который перенёс базу в другую папку. И все последние 2 года делался бэкап старой, неработающей базы...
С тех пор делаю резервные копии дважды - через конфигуратор и копированием файла
Файловые базы всегда нужно:
1) Скопировать файл 1Cv8.1CD (можно весь каталог базы)
2) Только потом делать *.dt из конфигуратор
3) потом обновление и т.п.
* В процессе выгрузки DT база как серверная так и файловая может разрушиться
* Выгруженный DT может не загрузиться
* Успешно загруженный DT в файловой базе может не иметь части данных в базе (документы регистры..)
* Сделанная копия базы SQL надежнее DT
* Копия базы SQL может обратно не загрузиться
* Копия mdf и log файлов базы SQL надежнее копии SQL (с восстановлением проблем пока не встречал)
Такой вот опыт))) к счастью без фатальных последствий.
про
Тоже был такой случай, по самоуверенности на проде РС записал без Прочитать(), сначала вспотел, но быстро взял себя в руки, восстановил из копии, пользователи почти не заметили))...
Потом у не опытного коллеги был подобный случай, помог ему, с фразой "Не очкуй, все норм, я сто раз так делал)))" восстановили за 10 мин :-)
SQL - только выгрузка + автоматическое архивирование средствами SQL.
Вообще, архивы дело нужное, т.к. бывают случаи, когда говорят "а до обновления такого не было". Приходится восстанавливать копию до и доказывать, что ты не олень.
Делал обновление базы на 1С77. В последний день работы. Ночью, в отведенное на это время с 01:00 до 01:30.
Штатно накатываю изменения. Применяю реструктуризацию и тут 1С падает. Запускаю повторно обновление - все проходит успешно.
Запускаю в режиме предприятия - нет документов!!! O_O Начинаю разбираться, выясняю, что таблица журнала документов пуста.
Ну думаю, фигня-война, администраторы прикрутили же автоматический бекап базы по расписанию - восстановлю и обновлю по новому.
Лезу на сервер и вижу, что последних бекап - за вчерашний день! Е-МАЕ! Ну как же так-то? Почему бекапа за сегодня нет?! (Просто на сервере место для бекапов кончилось.)
Звоню начальнику в начале 3-ого. Бужу с 3-4 звонка, объясняю, что случилось. Принимаем решение восстановить вчерашний бекап. Недостающее сотрудники "забьют с бумажки".
Ближе к 5 утра весь "в нервах", усталый, выпиваю стакан водки и проваливаюсь в тяжелый сон.
В обед проснулся с чувством кислятины во рту и вины. Так "подгадить" в последний день. А нужно были лишь убедиться, что бекап есть...
Если работаешь с внешними обработками фейлы это когда ты отвлекся и загрузил не ту версию внешней обработки. Или вместо сохранить нажал загрузить и затер что -то. Народ на местах ничего не заметил, все ушло в производство. На производстве не заметили и ушло на склад) на складе не заметили и ушло к клиенту. Клиент звонит и недоволен и заворачивает партию. Один неверный клик - эпик фейл.
А так чаще всего обновления) Ящик пандоры. Попробуйте делать обновление в день зарплаты или в день закрытия месяца и сделайте что нибудь не так. Эпик фейл когда гл. бухгалтер сидит и после выбора организации в закрытии месяца ждет час. А у нее осталось до конца дня всего ничего. И ты не знаешь что за нафиг....
Ну и самое сладкое) Это когда запускаешь обработку не на той базе))) Думал тестовая оказалось рабочая. А потом пишешь обработку по восстановлению с бекапа.
И никому потом не объяснишь что произошло, потому что косяк твой) Внимательнее надо быть. И плевать что ты всем нужен и 20 задач сразу висят и трубка разрывается. Горшочек Обязан ВАРИТЬ ты ж программист!
Холдинг разные направления деятельности, используется около 10 разных конфигураций не говоря уже о количестве баз на основе этих конфигураций. Поскольку это провинция и с программистами туго есть свои, есть фрилансеры и есть франчи.
На базах аля УПП стоял самописный журнал регистрации пишущий изменения в базу SQL. Ну и франчи прознали про это все и им тоже захотелось. Ну и я им его дал... ну как дал - хехехе. В общем все счастливы проходит неделя и заканчивается место на сервере
при беглом осмотре выясняем что все место сожрала связка баз УТ, БП, ЗУП и их внешний ЖурналРегистрации, которые обслуживает доблестный франч. Базы выросли просто в разы. Взвешиваем таблицы SQL. Таблица жрущая место это так называемый транзитный справочник Журнала регистрации.
Перед тем как выгрузить в SQL фоновым заданием изменения записывались в это справочник, а потом соответсвенно удалялись при записи. Дык вот в настройках журнала была возможность выбора обектов и реквизитов, по которым мы хотим отлеживать историю, ну
чтобы все подряд не писалось. Ну и франчи не заморачиваясь нажали зеленую галочку, что было бы не сильно критично если бы они убрали галку с транзитного справочника. А тут выходило, что при удалении элемента, который удалялся в фоне при записи в SQL. тут
же создвалась запись об удалении и соотвественно запись на запись об удалении... ну и т.д. Вот такой вот Уроборос получился.
Юристы пожаловались, что внешние файлы к договорам не присоединяются. Вообще механизм загрузки файлов и их присоединения к договорам был "допиленный", хотя я этого не знал. Файл загружался в базу и потом удалялся из каталога. Но один файл не хотел загружаться и просто удалялся. Не чуя подвоха, я скопировал файл в корень диска D и опять попробовал загрузить. Файл не загрузился, как и следовало бы ожидать, но система как-то странно "задумалась" на минуту. После завершения "операции" диск D оказался чист. Вместе со всей документацией юр. отдела. Я сказал "Ой", а юристы начали пить корвалол.
Все закончилось благополучно, в течении пары часов все файлы были восстановлены программой восстановления (Undelete или что-то похожее). После этого случая появилась привычка сначала смотреть код, а потом запускать механизм, особенно незнакомый :)
При обновлении 7ки от руководства была директива, архив делать путем копии папки базы. Пока шло сравнение бух, решил сделать копию зик. Видимо в пылу юношеского раздолбайства, вместо "Ctrl+C" нажал "Ctrl+X". Т.к. сравнение проходило неожиданно долго, решил снять нагрузку с системы путем снятия задачи по копированию через диспетчер. При попытке запуска конфигуратора, по словам бухгалтера, я почему-то побелел. Благо не докопировались (в основном) файлы классификатора адресов. "Восстановил" базу скрестив недокопированный архив и базу недельной давности.
2) Обиженный программист
Сам не видел, рассказывал руководитель консультантов, который подключался по TW. На линию консультации позвонил сторонний клиент. Они плохо расстались со своим штатным программистом. Через неделю после его ухода при открытии формы списка(чего не помню), стали появляться ножницы и вырезать в хоатичном порядке документы и база висла. После перезапуска базы документы из списка пропадали, а регистрах записи оставались, но с битыми ссылками на регистратор.
Тут наступил час Xэ, когда был вынужден прийти на помощь своим товарищам по ИТ. Тот час наступил весьма рано для меня, те за час ранее до оф. начала работы. Коллегам помог, пусть и с закрытыми глазами. Факап почти(!)наступил тогда, когда ГБ попросила развернуть скульный архив на ее тестовой базе. Я, все еще с закрытыми глазами, начал на автомате нажимать кнопки. Случилось божественное вмешательство по Тарантино! Меня буквально холодным потом пробило, когда дошло, что я разворачиваю архив полугодовой старины на продуктивной базе. Ну те флаг отключения действующих сеансов был включен и процесс уже начался! Судорожное нажатие всех кнопок похожих на Отмена и Закрыть позволили не допустить отката учета в доисторическую эпоху. Нормальные спецы подумают, что невелика беда, мол ну откатился бы до последнего архива, да только бекап, за который отвечали те самые ИТ коллеги, последний раз выполнялся как раз по их бестыжей воле ровно полгода назад!
- я не восьмерочник (но с сжиранием метса всяками восьмерочными логами дело имели с админом), поэтоу - для меня фраза эта - темный лес. за интерс чисто - можно чуть подробнее что за "маленький файлик и зачем/почему и почему логи росли когда ЦУП не работал..? Спасибо.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 937915
Создание 07.11.18 10:24
Обновление 21.12.18 08:20
Просмотры 13961
Загрузки 0
Рейтинг
34
Комментарии 60
Код открыт Да
Рубрики О жизни
Кому Для всех
Тип файла Нет файла
Платформа Не имеет значения
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
