Горшочек, не вари!
Данная история произошла несколько лет назад, в самом начале моей карьеры разработчика 1С.
Появился у нас в компании проект по оптимизации работы одной очень высоконагруженной базы одного очень большого и уважаемого клиента. Клиент был с настолько параноидальной службой безопасности, что никакого удаленного доступа к серверам извне не было и быть не могло. Для подключения к базам прямо к нам в офис была проведена отдельная локальная сеть с аппаратным VPN и установлены рабочие станции со строго обговоренным софтом. Разумеется, без прав локального администратора.
Как и любой другой проект подобного рода, начинался он со сбора данных. Предполагалось, что мы сначала в течении месяца будем собирать различные показатели, а потом уже займемся оптимизацией самой информационной базы. Как и сколько времени в этой забюрократизированной обстановке ушло на настройку ЦУП, это материал для отдельной истории. Но вот, в какой-то момент, это свершилось, ЦУП был настроен и запущен. После чего, эксперт, который вел данный проект (Дима, привет!), сел в свою роскошную машину и поехал путешествовать по нашей необъятной Родине, и дальше-больше — в ближнее зарубежье. Я же тогда, на самом деле еще мало что знал и умел, но уже считался вполне ответственным разработчиком. Поэтому перед отъездом Дмитрий поручил мне очень важное и серьезное задание: 2 раза в день, в момент пиковой нагрузки, я должен был подходить к тому самому секретному компьютеру и запускать замеры в ЦУП, а через час выключать их. Инструкции были предельно просты и понятны:
— Смотри, нажимаешь вот эту вот зелененькую кнопочку «плей», побежали разные графики, ждешь час, затем нажимаешь вот эту вот кнопку – «стоп». Все.
Что может быть проще, правда? Зря я что ли 5 лет на матфаке учился?
Всю неделю я строго соблюдал этот ритуал утром и вечером. И все было хорошо, до последнего дня. После обеда, в пятницу, я как обычно запустил сбор данных, а дальше… Ну вы знаете как это бывает… Пятница, вечер, надо доделать какие-то неотложные дела, добить какие-то задачи, после работы отвести жену к теще, по пути заехать в один магазин, второй и т.д. В общем, я уехал с работы, полностью забыв про этот злополучный ЦУП.
Утро субботы началось со звонка. Встали ВСЕ 1С-ные базы у клиента. Ахтунг и катастрофа! Наш эксперт где-то между Джейрахом и Пасанаури, вне зоны доступа сети. Главный админ клиента тоже на какой-то там даче и недоступен. Пытаемся по телефону разобраться, в чем причина? Кое-как выясняется, что кончилось место на диске, поэтому служба агента 1С встала. Вот тут я уже начал кое-что подозревать…
Как вы помните, никакой удаленки нет. Компьютер мало того что изолирован от сети интернет, так еще и вне нашей локальной сети. Делать нечего – еду на работу. Пока собирался и ехал, админы смекнули, что все место занято логами ЦУПа и сделали то, что показалось им наиболее разумным — вырубили его нафиг через диспетчер задач. Идем дальше. Просто так удалить логи с диска нельзя — потеряем данные замеров. Кое-как нашли достаточно места на сетевом ресурсе и скопировали туда файлы. Работа вроде бы возобновилась.
Утро воскресенья началось со звонка. Встали ВСЕ 1С-ные базы у клиента. Ахтунг и катастрофа дубль два! Вся паника по новой – закончилось место. Но как так-то? ЦУП же выключили? В спешке снова еду на работу, перекидываю логи, чтобы высвободить место. А они все растут и растут, черт их подери! Под страхом самых извращенных экзекуций администраторы запретили мне вообще что-либо запускать или что-то настраивать. Весь остаток воскресенья я занимался тем, что сидел у компьютера и копировал логи на шару, чтобы базы опять не встали.
Только поздно ночью на связь вышел Дима и рассказал, что нужно всего лишь удалить один маленький файлик на сервере 1С. Уже потом, пару недель спустя, я прочитал о нем в одной всем известной «настольной» книге, ну а в тот день, без сил, замученный поехал домой отсыпаться.
В понедельник утром нашу учетную запись заблокировали до возвращения Дмитрия из отпуска, а на мой счет было сказано вполне недвусмысленно: «Чтобы больше мы ЕГО у нас не видели!».
Вот так вот для меня закончился мой первый проект по оптимизации.
Два раза в одну воронку
Крупный холдинг. 18 информационных баз с идентичной конфигурацией, расположены по всей стране. Обновление происходит раз в неделю и представляет из себя тот еще ритуал: файл поставки надо заблаговременно подготовить, выложить в облако, убедиться, что во всех филиалах он прогрузился (даже в 2024 году в некоторых регионах интернет работает медленнее, чем типовая ERP), проверить, что везде создались резервные копии (мы за это вроде как не отвечаем, но горький опыт научил подстраховываться), затем на каждом филиале запустить вручную скрипт обновления и убедиться, что он отработал без ошибок. Часто в последний момент обнаруживается, что в поставку надо включить еще вот эту вот задачку и вот это мелкое исправление, ведь следующее обновление только через неделю.
Так было и в тот раз. Опытный разработчик с многолетним стажем в спешке ошибся в одной строке при переносе задачи на боевой контур. Ошибка оказалось критичная, обнаружилась уже после обновление всех баз.
Ну что ж делать? Разработчик быстро исправляет код. Никому не дает протестировать:
— Да там фигня… Я ведь не могу ошибиться два раза в одной строчке?
Через час обновляли 18 филиалов в третий раз.
Разработчик, который смог
История, рассказанная коллегой в скайпе.
[Коллега]: Жил-был «Разработчик, который смог!». У него был наряд на разработку. Он хотел открыть тестовую, но промахнулся, и открыл продуктив…
[Коллега]: Но разве это могло остановить «Разработчика, который смог»? Нет!
[Я]: А при обновлении он не понял, что там как-бы люди сидят? ))
[Коллега]: Более того, он видит, что конфа на поддержке… Но думаешь это могло остановить «Разработчика который смог»? Нет!
[Коллега]: Он снимает конфигурацию с поддержки (!) и пилит свой модиф в обход всех хранилищ…
[Я]: Это жееееесть! Добей историю, динамическим обновлением )))
[Коллега]: Обновляет… Система говорит: «В базе 18 активных сеансов!». Но разве это могло остановить «Разработчика который смог»? Нет и еще раз нет!
[Коллега]: Он обновляет базу и передает задачу в тест…
[Коллега]: Консультант не может найти наряд… и только потом, спустя долгое время он понимает, что промахнулся.
[Коллега]: Я должен был его отругать…
[Коллега]: Я ему звоню… а сам ржу в трубку…
[Коллега]: Я просто не понимаю… КАК???
Транспортный коллапс
История, рассказанная коллегой и записанная с его слов.
Происходило это в крупной логистической компании. Большинство бизнес-процессов сосредоточены в одной информационной базе. Конкурентных пользователей на 2012 год – около 3000 человек из всех регионов страны.
Поставили простую задачу. По ней сделал свой регистр сведений, в который пишутся данные при проведении некоторых документов. Хоть видов документов и немного, но количество этих документов в день — огромное. По идее, добавленная мною операция записи в регистр не должна сильно нагрузить систему. Но в реализации задачи был один нюанс — при записи набора, свойство «Перезаписывать» устанавливалось в «Ложь». То есть каждое проведение документа добавляло записи в регистр. Это было необходимо по условиям задачи, но практически не влияло на производительность, т.к. по условиям отборам там всегда было 1-10 записей.
Тестирование функционала прошло успешно. Провели несколько десятков документов, убедились, что записи в регистре верные, ничего подозрительного не заметили и отправили в продуктив.
В ту злополучную пятницу утром сделали обновление боевой базы, и пользователи начали работать. 3000 человек бодро набивали документы и регистр стал наполняться данными. Проверив, что всё идёт хорошо, мы через несколько часов отправились домой со спокойной душой (работаем в разных часовых поясах с основными пользователями информационной базы).
Надо отметить, что серверы, на которых работала ИБ – чуть ли не одни из самых мощных в России, используемых под 1С. Но через несколько часов "что-то пошло не так" (с).
Пользователи стали отмечать снижение производительности системы. Все операции стали замедляться. Отклики на любые действия становились всё дольше. Нагрузка на оборудование неуклонно возрастала. Пока ИТ-отдел разбирался в чём дело, работа в системе практически встала. Оборудование не справлялось, очереди на дисках были длиннее, чем в отделениях Почты России. Было бы оборудование слабее, проблема бы обнаружилась почти сразу. Но мощнейшие серверы героически сопротивлялись моим кривым рукам полдня.
"Со слов" MSSQL самым тяжелым запросом внезапно стал запрос на чтение в моём регистре. Хотя я никаких чтений не делал. Довольно быстро обнаружилась и проблема в коде 1С. Я забыл установить отборы на набор записей. Если бы свойство «Перезаписывать» было бы установлено в «Истина», то ошибку я бы сразу обнаружил, т.к. каждая запись чистила бы весь регистр. А в нашем случае этого не происходило. На примере десятка документов, конечно, никаких потерь производительности мы не заметили. Но когда регистр стал наполняться десятками и сотнями тысяч строк — системе каждый раз приходилось проверять весь регистр на совпадение записей.
К тому времени, со слов некоторых пользователей, уже случился транспортный коллапс, т.к. автомобили не получали документы из 1С и не могли покинуть пункты разгрузки.
Вот так, «всего лишь» забыв поставить отбор в наборе записей, я положил одну из крупнейших баз 1С в России.
P. S. Смотрите также:
- Байки разработчика №1: детективные
- Байки разработчика №2: эпикофейлические
- Байки разработчика №3: страшные истории…
- Байки разработчика №4: админские
Первый вывод, который напрашивается — не ставить дедлайны и внедрения на пятницу)). По поводу последней истории — было что-то похожее) только начинал работать с 1с, надо было в большой базе (около 2000 человек работали с ней на протяжении 8 лет) в регистре сведений поправить значения. Думаю — задачка простая, можно и не тестить. Накидал код, выполнил в рабочей базе через ИР, и только после выполнения увидел, что забыл в коде написать Набор.Прочитать(). Естественно весь регистр почистился. Админ был в отпуске, бэкап накатить некому, у меня доступа нет. В итоге все вернул с помощью универсального обмена выгрузив с тестовой базы данные (благо она каждую ночь обновляется и данные актуальные). Так я понял, что перед выполнением чего-либо в рабочей базе лучше сначала сто раз протестировать все на тестовой платформе (дабы сэкономив лишний час, потом можно все выходные заниматься исправлением косяков)..
Хорошие истории. Последняя еще и познавательная для меня.
Мой самый красивый эпикфеил был в начале моей карьеры с 1с , когда поехал к клиенту обновлять 7. 7 а там было 3 ярлыка с каждой со своей компонентой и зашел я в базу Бух , но с компонентой расчет зарплаты и стал обновлять , предварительно сделав копию. на логичное предупреждение системы об отсутствии компоненты плюнул — в итоге база убита , а архив как назло оказался битый , сижу весь на нервах — делать нечего — говорю — убил вашу базу , не восстановить — клиент задает вопрос — и что база теперь совсем чистая — я говорю да на что клиент выдает фразу — Я всегда мечтала о чистой базе так что ничего страшного можешь идти ))) И когда я обучал своих уже стажеров всегда говорил , что у меня был случай когда я клиенту снес базу , но клиент остался доволен
Молодежь…
Вот в наше время были фейлы!
Я начал общение с Windows 3.1 на рабочем компе , удалив корневой каталог Windows с помощью Волков коммандера из Dos. А комп был один на всю лабораторию.
у РСа надо было «Подчинение регистратору» включить, тогда бы хрен ты его записал без отбора… 🙂
вы все также героически в продакшн по пятницам накатываете? 😀
К сожалению, многие ошибки выявляются спустя несколько лет.
(3)Админы бывают трех типов:
те, кто пока не делает бекапов;
те, кто делает бекапы;
те, кто делает и проверяет бекапы.
(7) я ж тогда во франче работал — приехал — сделал копию — обновил — сделал еще одну копию и уехал
(1)Не раз приходилось править подобные фейлы от коллег, потому как самим им опыта или смекалки не хватало; особо эпичны были фейлы с удалением дублей: 1 — слили «дубли» сотрудников по физлицам, не учли что сотрудники могут быть совместителями и дублей не было; 2 — слили номенклатуру по наименованию, не учли что удаляемые дубли заменяться в документах и они перепроведутся, в закрытом периоде тоже; 3- исправления документов в закрытом периоде, многократно. Всегда спасало наличие бэкапа. За собой особо эпичных фейлов не припомню.
Фейлы:
1. Сотрудник неделю работает над проектом автоматизации ответственного хранения в копии. Ночью накатываю обновление с ИТС в основной базе. Думаю надо и копии для разработчиков на свежие обновить…сотрудник званого начал разработку автоматизации ответственного хранения ))
2. На сервере 10 рейд из 12 штук SAS дисков. Контроллер показывает, что сразу три диска вышли из строя. Горячая замена не отрабатывает — ошибки не сбрасываются. Готовимся к перезагрузке сервера. Даю команду системным администраторам подготовится к перезагрузке: проверить наличие копий всех баз. Отрапортовали что копии сделаны, все перепроверили. Перегружаем сервер, рейд разваливается и не собирается. Что ж, были готовы. Восстанавливаем базы на дублирующем сервере… выясняется из 23 баз 1 база не восстанавливается — битый BAK как последний так и предпоследний.
Нашлась копия на чьем то компьютере от прошлого года только. В нашем городе нет компании, которая могла бы вытащить из рейда другие копии этой базы (основная причина что нет такого объема диска, на который можно скопировать все образы всех дисков рейда и программно пересобрать рейд). Пришлось отправлять диски вместе сервером в Москву. Где за 120 к.деревянных нам вытащили копию базы месячной давности, развёрнутую в SQL одним из программистов 1С для своей работы, т.к. основная база и ее BAK (все 30 штук) были битые (копируются но не восстанавливаются). Мораль, если у вас есть БАКапы, это еще не значит что вы сделали копии базы))
Имхо — единственная резервная копия — это та, которую сделал разработчик для своей работы и что-нибудь разрабатывает .
Скучно живу (((
В основном такое: обновили бухню в отраслевом решении и перестало все работать, ибо в отдельном ядре бухгалтерия не обновлена, и его механизмы еще не знают, что «мудрые» 1С-неги, разрабатывающие типовые решения, решили перенести функции создания временного каталога и его убития в другой модуль. Да, в итоге все сломалось, но внутреннее тестирование не дало выпустить релиз. Короче, скукотища. И только сотрудники Усатого не дают совсем заскучать…
Не.. в пятницу стараюсь ничего и никому не накатывать.. плохая примета — к плохим выходным, а вообще как кто-то сказал, и я с ним согласен «Нет ощущения хуже- чем ощущение только что сделанной глупости»
Если от сделанной глупости ощущаешь счастье, значит ты не адекватен?
(10)
(3) Было дело, франч, обновить 77, приезжаю, запускаю копию и запускаю установку обновы в каталог по умолчанию. После установки обновы, обнаруживаю, что до меня рабочая база была в каталоге куда эта обнова встала, перезаписав все файлы рабочей базы, копирование к сожалению делалось дольше чем установка обновы….. Это наверное самое сильное впечатление за всю карьеру
После переноса данных из ЗУП 2.5 в ЗУП 3.1, обнаружил, что в регистре накопления НачисленияУдержанияПоСотрудникам не заполнена РегистрацияВНалоговомОргане. Написал обработку, которая заполняет этот реквизит из измерения Подразделение. Заполнил. Через пару месяцев обнаружилось, что в движениях расчетных документов начали появляться записи с 15-значными суммами, которые попали в рег. отчетность.
Клевые истории, но самому не хотелось бы в такие попасть.
Эпичные фейлы случаются, к сожалению, не только в начале карьеры) Накатывание даже «простейшего» кода без тестирования даже при большом опыте разработки (а возможно как раз из-за него) — почти 100% ошибка. Отсюда правило — нельзя что-то накатить на рабочую базу и куда-то выдвигаться от компьютера, т.к. иной раз приходится возвращаться и исправлять, даже после тестирования. Перед выходными и каникулами тоже ничего лучше не трогать, если не хотите провести их за работой.
Еще интересная область эпик фейлов — интеграция с другими системами, и логика ее работы. Если архитектура интеграции не достаточно защищена от ошибок — могут возникать проблемы. Например, у нас недавно был случай — в карточку контрагента добавили новый типовой дополнительный реквизит (статус клиента). Безобидная операция вполне. После чего обработкой этот самый статус присвоили (после этого случая в подобных обработках ставим ОбменДанными.Загрузка = Истина). Несколько тысяч карточек контрагентов пометились к изменению в одном из планов обмена, который отвечал за обмен со сторонней системой. В эту систему были заново высланы карточки клиентов, а она в свою очередь по всем этим карточкам выслала клиенту СМС-ки об изменениях.
(0) лайк за тему!
цупы, мупы …. — а в итоге все упирается в в проведение бэкапов, алгоритмы разработки, в попустительство разработчиков из-за нехватки опыта или из-за спешки («и так прокатит»)
Я тоже неоднократно «косячил». Иногда по незнанию механизмов платформы, полагаясь на её «сообразительность», а иногда просто перерабатывал до такой степени, что отключалось логическое мышление напрочь, затем сам себе удивлялся как я мог вообще это сделать, последствия же были очевидны… И базы из бэкапов вытаскивали и сидели по ночам перетаскивая документы пользователей успевших налепить документов за пару часов в количестве нескольких тысяч штук. Вещи малоприятные. И хорошо, когда уже прошел этот путь раза 3 и более менее себе представляешь схему действий по восстановлению и возвращению базы в строй.
У каждого 1Сника наверное есть таике «скелеты в шкафу».. 😉 И меня не минула сия доля 😉
Вывод у меня один: ничего и ничто нельзя делать в спешке и в завале, даже если «срочно, надо вчера!». Жили до этого как-то? жили! Проживут еще 1-2-3 дня/недели.
Здесь недавно была тема страшилок на Хеллоуин, они так не будоражили, как эти истории 🙂
(22)
были все выдуманны, а это суровая правда жизни. Такое не придумаешь )
Комментарии про бэкапы, напомнили мне как когда-то давно работал я во франчайзи, занимался в основном, обновлениями. Обновления нужно было устанавливать с дискеток. Вот и таскаешь с собой комплект тех самых дискеток, на одних программные файлы, на других различные конфигурации и на каждую дискетку по дубликату. А дискетки были не вечными, да и дисководы тоже были далеко не вечные, мало того тогда и сотовые телефоны были далеко не у всех, веселое время было.
(13)ага, то чувство, когда только осознал, что что-то идет не так и комок в горле… нервы надо лечить)
Жизненно )
Тоже история: приехали к клиенту, это было давно правда. А там файловая локальная база, постоянно вылетает с ошибкой SDBL. Сразу определили что проблема в нехватке места на жестком диске где расположена база. Посмотрели — что же можно почистить. Сразу в глаза бросилась «Корзина» просто с колоссальным числом файлов. Да и место она занимала столько, что если ее очистить, то еще баз на 5 таких же места хватит. Ну вот — мы ее и почистили…
Вечером клиент звонит, орет матом….
— Зачем вы корзину почистили, кто вам позволил?
Мы:
— Так это же «Корзина», там обычно то что уже не нужно.
Клиент:
— Как так, корзина — это аналог коробки для документов, вот мы там и хранили все наши важные электронные документы.
Мы в шоке…
А что это за маленький файлик, который нужно было удалить на сервере 1С в первой истории?
(25)Не, самое плохое чувство, когда ты понял что накосячил, это не поправимо и придется объяснять клиенту/начальнику и т.д., одно из самых гадких чувств ))
(27) Подозреваю, что это был конфиг для логов технологического журнала.
(27)
Это файл «logcfg.xml»,
Книга:
Я как-то рано утром решил снять копию базы клиента. Видимо не до конца проснувшись, я вместо «выгрузить» выбрал «загрузить». В итоге загрузил копию недельной давности. Когда понял это сразу связался с админом облака где была база. Оказывается последний бэкап по расписанию был сделан за пять минут до моего косяка. Все оперативно исправили.
Установили клиенту автоматический ночной бэкап базы через Effector Saver, с копированием в облако. Всё много лет работало, всё было нормально.
Пришел накатывать обновления, всех выгнал из базы, запустил ручной бэкап через effector saver.
В процессе накатывания обновления произошло отключение света и база «запоролась».
Восстановил из бэкапа, обновил, всё путём.
И тут оказывается, что в базе данные 2-х летней давности…
Выяснилось, что какое-то время их обслуживал какой-то там мальчик, который перенёс базу в другую папку. И все последние 2 года делался бэкап старой, неработающей базы…
С тех пор делаю резервные копии дважды — через конфигуратор и копированием файла
Расскажу и про свой «косяк».
Делал обновление базы на 1С77. В последний день работы. Ночью, в отведенное на это время с 01:00 до 01:30.
Штатно накатываю изменения. Применяю реструктуризацию и тут 1С падает. Запускаю повторно обновление — все проходит успешно.
Запускаю в режиме предприятия — нет документов!!! O_O Начинаю разбираться, выясняю, что таблица журнала документов пуста.
Ну думаю, фигня-война, администраторы прикрутили же автоматический бекап базы по расписанию — восстановлю и обновлю по новому.
Лезу на сервер и вижу, что последних бекап — за вчерашний день! Е-МАЕ! Ну как же так-то? Почему бекапа за сегодня нет?! (Просто на сервере место для бекапов кончилось.)
Звоню начальнику в начале 3-ого. Бужу с 3-4 звонка, объясняю, что случилось. Принимаем решение восстановить вчерашний бекап. Недостающее сотрудники «забьют с бумажки».
Ближе к 5 утра весь «в нервах», усталый, выпиваю стакан водки и проваливаюсь в тяжелый сон.
В обед проснулся с чувством кислятины во рту и вины. Так «подгадить» в последний день. А нужно были лишь убедиться, что бекап есть…
Файловые базы всегда нужно:
1) Скопировать файл 1Cv8.1CD (можно весь каталог базы)
2) Только потом делать *.dt из конфигуратор
3) потом обновление и т.п.
* В процессе выгрузки DT база как серверная так и файловая может разрушиться
* Выгруженный DT может не загрузиться
* Успешно загруженный DT в файловой базе может не иметь части данных в базе (документы регистры..)
* Сделанная копия базы SQL надежнее DT
* Копия базы SQL может обратно не загрузиться
* Копия mdf и log файлов базы SQL надежнее копии SQL (с восстановлением проблем пока не встречал)
Такой вот опыт))) к счастью без фатальных последствий.
про
Тоже был такой случай, по самоуверенности на проде РС записал без Прочитать(), сначала вспотел, но быстро взял себя в руки, восстановил из копии, пользователи почти не заметили))…
Потом у не опытного коллеги был подобный случай, помог ему, с фразой «Не очкуй, все норм, я сто раз так делал)))» восстановили за 10 мин 🙂
Разрушилась SQL база у клиента. Заметно это стало не сразу, поэтому несколько дней люди еще работали, пока база наконец не перестала открываться. Бэкапы за эти несколько дней делались, но база в них уже была сбойная.
Восстановили последний бэкап без сбоев пятидневной давности как рабочую базу.
Восстановили последний сбойный бэкап.
Универсальной обработкой перетащил документы из сбойной базы в рабочую. По журналу отобрал добавленные за это время справочники, и тоже их перенес.
(31)
Такое у меня раз в пару лет бывает обязательно.
Перед нажатием на кнопку «загрузить» вместо «выгрузить» срабатывает рефлекс «в окне файла ничего не должно быть» и «не должно возникать дополнительных вопросов».
Однажды на 7.7 при каком-то небольшом редактировании (добавление кнопки с обработкой в документ) в журнале налоговых накладных стерлись данные за последний месяц. Я в приступе мании преследования. Поднимаю сделанный бакап, в нем все есть. Копирую выброчно файлы из бакапа в рабочую и запускаю тестирование.
Разбираюсь что могло быть по журналу регистрации. Оказывается, в процессе последней реструктуризации месяц назад (до моего появления там) был сбой (реструктуризация не завершена) и в каталоге NewStru остались файлы налоговых накладных. Последняя реструктуризация почему-то (возможно из-за моих прав) не почистила перед новой реструктуризацией этот каталог и все что там было перенеслось в рабочую базу. Хорошо что бакап делался винраром, а не выгрузкой или сохранением, как обычно.
Восстановить данные можно было бы, а объяснить почему возникла проблема («доказать что ты не верблюд») — нет.
Честно, как то прочитал и не понял. Я только начинал работать и мне дали высоконагруженную систему? это как? Я когда начинал я писал дописки под присмотром программиста. И уж точно меня никто не пускал в продуктив. Да и потом на протяжении 3 лет не было у нас ни одной такой ситуации чтобы кто то что-то запорол клиенту и у него все встало. То ли уровень высокий. То ли везло..Не знаю…
Если работаешь с внешними обработками фейлы это когда ты отвлекся и загрузил не ту версию внешней обработки. Или вместо сохранить нажал загрузить и затер что -то. Народ на местах ничего не заметил, все ушло в производство. На производстве не заметили и ушло на склад) на складе не заметили и ушло к клиенту. Клиент звонит и недоволен и заворачивает партию. Один неверный клик — эпик фейл.
А так чаще всего обновления) Ящик пандоры. Попробуйте делать обновление в день зарплаты или в день закрытия месяца и сделайте что нибудь не так. Эпик фейл когда гл. бухгалтер сидит и после выбора организации в закрытии месяца ждет час. А у нее осталось до конца дня всего ничего. И ты не знаешь что за нафиг….
Ну и самое сладкое) Это когда запускаешь обработку не на той базе))) Думал тестовая оказалось рабочая. А потом пишешь обработку по восстановлению с бекапа.
И никому потом не объяснишь что произошло, потому что косяк твой) Внимательнее надо быть. И плевать что ты всем нужен и 20 задач сразу висят и трубка разрывается. Горшочек Обязан ВАРИТЬ ты ж программист!
Внешний журнал регистрации.
Холдинг разные направления деятельности, используется около 10 разных конфигураций не говоря уже о количестве баз на основе этих конфигураций. Поскольку это провинция и с программистами туго есть свои, есть фрилансеры и есть франчи.
На базах аля УПП стоял самописный журнал регистрации пишущий изменения в базу SQL. Ну и франчи прознали про это все и им тоже захотелось. Ну и я им его дал… ну как дал — хехехе. В общем все счастливы проходит неделя и заканчивается место на сервере
при беглом осмотре выясняем что все место сожрала связка баз УТ, БП, ЗУП и их внешний ЖурналРегистрации, которые обслуживает доблестный франч. Базы выросли просто в разы. Взвешиваем таблицы SQL. Таблица жрущая место это так называемый транзитный справочник Журнала регистрации.
Перед тем как выгрузить в SQL фоновым заданием изменения записывались в это справочник, а потом соответсвенно удалялись при записи. Дык вот в настройках журнала была возможность выбора обектов и реквизитов, по которым мы хотим отлеживать историю, ну
чтобы все подряд не писалось. Ну и франчи не заморачиваясь нажали зеленую галочку, что было бы не сильно критично если бы они убрали галку с транзитного справочника. А тут выходило, что при удалении элемента, который удалялся в фоне при записи в SQL. тут
же создвалась запись об удалении и соотвественно запись на запись об удалении… ну и т.д. Вот такой вот Уроборос получился.
(21) Вот правда истинная. Поддался как-то этому давлению со стороны нескольких начальников. Там серьезная запарка была. В результате написал кривой код, работающий только в текущий на тот момент период отчетности за два раза большее время. Через квартал переделывать пришлось, да еще и удивляться, как в спешке можно так плохо написать.
(30)Вообще по-хорошему, в этом случае надо по шапке надавать именно тому опытному разработчику, который уехал и не поставил в известность молодого бойца об этом файле.
Еще в начале знакомства с 1с (лет 7 назад) произошла «ситуация»:
Юристы пожаловались, что внешние файлы к договорам не присоединяются. Вообще механизм загрузки файлов и их присоединения к договорам был «допиленный», хотя я этого не знал. Файл загружался в базу и потом удалялся из каталога. Но один файл не хотел загружаться и просто удалялся. Не чуя подвоха, я скопировал файл в корень диска D и опять попробовал загрузить. Файл не загрузился, как и следовало бы ожидать, но система как-то странно «задумалась» на минуту. После завершения «операции» диск D оказался чист. Вместе со всей документацией юр. отдела. Я сказал «Ой», а юристы начали пить корвалол.
Все закончилось благополучно, в течении пары часов все файлы были восстановлены программой восстановления (Undelete или что-то похожее). После этого случая появилась привычка сначала смотреть код, а потом запускать механизм, особенно незнакомый 🙂
(8) все равно интересно с чего это только что сделанный бэкап мог бы оказаться битым.
(40) да, согласен, что самое странное и страшное в этой истории — недоступный главный админ и главный ответственный. Нельзя такого допускать, но конечно же нашли крайнего 1с-ника)
(41) а руки этим погромистам потом не оторвали?) Как так можно было написать?)
(42) Хотябы из-за винта внезапно коряво записавшего точку или ноль. Ну вот изношена была головка, что поделать?!
(31) Недавно было, чуть не поседел. Только дело ночью было, глаза уже закрывались, видимо. После того, как загрузка закончилась, проснулся махом. Хорошо база SQL и бэкапы красивые. Все восстановилось.
(32) В файловых базах никогда выгрузкой не пользуюсь. Только архивирую полностью папку + добавляю данные для восстановления. После архивации проверяю архив. Это при обновлении или доработках. А на повседневку тоже Effector Saver.
SQL — только выгрузка + автоматическое архивирование средствами SQL.
Вообще, архивы дело нужное, т.к. бывают случаи, когда говорят «а до обновления такого не было». Приходится восстанавливать копию до и доказывать, что ты не олень.
У меня было давно, «мышка бежала хвостиком махнула», 7чный каталог базы данных на сервере мышкой переместила в другую папку. Рабочий каталог посреди бела дня при работающих пользователях.
1) Первая седина
При обновлении 7ки от руководства была директива, архив делать путем копии папки базы. Пока шло сравнение бух, решил сделать копию зик. Видимо в пылу юношеского раздолбайства, вместо «Ctrl+C» нажал «Ctrl+X». Т.к. сравнение проходило неожиданно долго, решил снять нагрузку с системы путем снятия задачи по копированию через диспетчер. При попытке запуска конфигуратора, по словам бухгалтера, я почему-то побелел. Благо не докопировались (в основном) файлы классификатора адресов. «Восстановил» базу скрестив недокопированный архив и базу недельной давности.
2) Обиженный программист
Сам не видел, рассказывал руководитель консультантов, который подключался по TW. На линию консультации позвонил сторонний клиент. Они плохо расстались со своим штатным программистом. Через неделю после его ухода при открытии формы списка(чего не помню), стали появляться ножницы и вырезать в хоатичном порядке документы и база висла. После перезапуска базы документы из списка пропадали, а регистрах записи оставались, но с битыми ссылками на регистратор.
Сова. Ненавижу просыпаться рано, те вовремя. Уже будучи несколько освоившимся специалистом с хорошим качеством результата начал пользоваться своим положением, те появляться на рабе спустя 2,5 часа официального начала раб дня. Надо отдать должное, что я и задерживался до поздна, мог поработать ночью и на выхах. Кароч, шло все своим чередом, достаточно хорошо.
Тут наступил час Xэ, когда был вынужден прийти на помощь своим товарищам по ИТ. Тот час наступил весьма рано для меня, те за час ранее до оф. начала работы. Коллегам помог, пусть и с закрытыми глазами. Факап почти(!)наступил тогда, когда ГБ попросила развернуть скульный архив на ее тестовой базе. Я, все еще с закрытыми глазами, начал на автомате нажимать кнопки. Случилось божественное вмешательство по Тарантино! Меня буквально холодным потом пробило, когда дошло, что я разворачиваю архив полугодовой старины на продуктивной базе. Ну те флаг отключения действующих сеансов был включен и процесс уже начался! Судорожное нажатие всех кнопок похожих на Отмена и Закрыть позволили не допустить отката учета в доисторическую эпоху. Нормальные спецы подумают, что невелика беда, мол ну откатился бы до последнего архива, да только бекап, за который отвечали те самые ИТ коллеги, последний раз выполнялся как раз по их бестыжей воле ровно полгода назад!
Почитал комментарии… Пойду бекапы проверять!
(6) Да, ошибки в ДНК отдельных персонажей часто десятки лет скрываются 🙂
(19) Из моего опыта самый большой фэйл — это фраза системного архитектора «код — это лучшая документация».
Остальные организационные вопросы — на том же уровне. Результат «экономии» предсказуем.