Горшочек, не вари!
Данная история произошла несколько лет назад, в самом начале моей карьеры разработчика 1С.
Появился у нас в компании проект по оптимизации работы одной очень высоконагруженной базы одного очень большого и уважаемого клиента. Клиент был с настолько параноидальной службой безопасности, что никакого удаленного доступа к серверам извне не было и быть не могло. Для подключения к базам прямо к нам в офис была проведена отдельная локальная сеть с аппаратным VPN и установлены рабочие станции со строго обговоренным софтом. Разумеется, без прав локального администратора.
Как и любой другой проект подобного рода, начинался он со сбора данных. Предполагалось, что мы сначала в течении месяца будем собирать различные показатели, а потом уже займемся оптимизацией самой информационной базы. Как и сколько времени в этой забюрократизированной обстановке ушло на настройку ЦУП, это материал для отдельной истории. Но вот, в какой-то момент, это свершилось, ЦУП был настроен и запущен. После чего, эксперт, который вел данный проект (Дима, привет!), сел в свою роскошную машину и поехал путешествовать по нашей необъятной Родине, и дальше-больше — в ближнее зарубежье. Я же тогда, на самом деле еще мало что знал и умел, но уже считался вполне ответственным разработчиком. Поэтому перед отъездом Дмитрий поручил мне очень важное и серьезное задание: 2 раза в день, в момент пиковой нагрузки, я должен был подходить к тому самому секретному компьютеру и запускать замеры в ЦУП, а через час выключать их. Инструкции были предельно просты и понятны:
— Смотри, нажимаешь вот эту вот зелененькую кнопочку «плей», побежали разные графики, ждешь час, затем нажимаешь вот эту вот кнопку – «стоп». Все.
Что может быть проще, правда? Зря я что ли 5 лет на матфаке учился?
Всю неделю я строго соблюдал этот ритуал утром и вечером. И все было хорошо, до последнего дня. После обеда, в пятницу, я как обычно запустил сбор данных, а дальше… Ну вы знаете как это бывает… Пятница, вечер, надо доделать какие-то неотложные дела, добить какие-то задачи, после работы отвести жену к теще, по пути заехать в один магазин, второй и т.д. В общем, я уехал с работы, полностью забыв про этот злополучный ЦУП.
Утро субботы началось со звонка. Встали ВСЕ 1С-ные базы у клиента. Ахтунг и катастрофа! Наш эксперт где-то между Джейрахом и Пасанаури, вне зоны доступа сети. Главный админ клиента тоже на какой-то там даче и недоступен. Пытаемся по телефону разобраться, в чем причина? Кое-как выясняется, что кончилось место на диске, поэтому служба агента 1С встала. Вот тут я уже начал кое-что подозревать…
Как вы помните, никакой удаленки нет. Компьютер мало того что изолирован от сети интернет, так еще и вне нашей локальной сети. Делать нечего – еду на работу. Пока собирался и ехал, админы смекнули, что все место занято логами ЦУПа и сделали то, что показалось им наиболее разумным — вырубили его нафиг через диспетчер задач. Идем дальше. Просто так удалить логи с диска нельзя — потеряем данные замеров. Кое-как нашли достаточно места на сетевом ресурсе и скопировали туда файлы. Работа вроде бы возобновилась.
Утро воскресенья началось со звонка. Встали ВСЕ 1С-ные базы у клиента. Ахтунг и катастрофа дубль два! Вся паника по новой – закончилось место. Но как так-то? ЦУП же выключили? В спешке снова еду на работу, перекидываю логи, чтобы высвободить место. А они все растут и растут, черт их подери! Под страхом самых извращенных экзекуций администраторы запретили мне вообще что-либо запускать или что-то настраивать. Весь остаток воскресенья я занимался тем, что сидел у компьютера и копировал логи на шару, чтобы базы опять не встали.
Только поздно ночью на связь вышел Дима и рассказал, что нужно всего лишь удалить один маленький файлик на сервере 1С. Уже потом, пару недель спустя, я прочитал о нем в одной всем известной «настольной» книге, ну а в тот день, без сил, замученный поехал домой отсыпаться.
В понедельник утром нашу учетную запись заблокировали до возвращения Дмитрия из отпуска, а на мой счет было сказано вполне недвусмысленно: «Чтобы больше мы ЕГО у нас не видели!».
Вот так вот для меня закончился мой первый проект по оптимизации.
Два раза в одну воронку
Крупный холдинг. 18 информационных баз с идентичной конфигурацией, расположены по всей стране. Обновление происходит раз в неделю и представляет из себя тот еще ритуал: файл поставки надо заблаговременно подготовить, выложить в облако, убедиться, что во всех филиалах он прогрузился (даже в 2018 году в некоторых регионах интернет работает медленнее, чем типовая 1С:ERP), проверить, что везде создались резервные копии (мы за это вроде как не отвечаем, но горький опыт научил подстраховываться), затем на каждом филиале запустить вручную скрипт обновления и убедиться, что он отработал без ошибок. Часто в последний момент обнаруживается, что в поставку надо включить еще вот эту вот задачку и вот это мелкое исправление, ведь следующее обновление только через неделю.
Так было и в тот раз. Опытный разработчик с многолетним стажем в спешке ошибся в одной строке при переносе задачи на боевой контур. Ошибка оказалось критичная, обнаружилась уже после обновления всех баз.
Ну что ж делать? Разработчик быстро исправляет код. Никому не дает протестировать:
— Да там фигня… Я ведь не могу ошибиться два раза в одной строчке?
Через час обновляли 18 филиалов в третий раз.
Разработчик, который смог
История, рассказанная коллегой в скайпе.
[Коллега]: Жил-был «Разработчик, который смог!». У него был наряд на разработку. Он хотел открыть тестовую, но промахнулся, и открыл продуктив…
[Коллега]: Но разве это могло остановить «Разработчика, который смог»? Нет!
[Я]: А при обновлении он не понял, что там как-бы люди сидят? ))
[Коллега]: Более того, он видит, что конфа на поддержке… Но думаешь это могло остановить «Разработчика который смог»? Нет!
[Коллега]: Он снимает конфигурацию с поддержки (!) и пилит свой модиф в обход всех хранилищ…
[Я]: Это жееееесть! Добей историю, динамическим обновлением )))
[Коллега]: Обновляет… Система говорит: «В базе 18 активных сеансов!». Но разве это могло остановить «Разработчика который смог»? Нет и еще раз нет!
[Коллега]: Он обновляет базу и передает задачу в тест…
[Коллега]: Консультант не может найти наряд… и только потом, спустя долгое время он понимает, что промахнулся.
[Коллега]: Я должен был его отругать…
[Коллега]: Я ему звоню… а сам ржу в трубку…
[Коллега]: Я просто не понимаю… КАК???
Транспортный коллапс
История, рассказанная коллегой и записанная с его слов.
Происходило это в крупной логистической компании. Большинство бизнес-процессов сосредоточены в одной информационной базе. Конкурентных пользователей на 2012 год – около 3000 человек из всех регионов страны.
Поставили простую задачу. По ней сделал свой регистр сведений, в который пишутся данные при проведении некоторых документов. Хоть видов документов и немного, но количество этих документов в день — огромное. По идее, добавленная мною операция записи в регистр не должна сильно нагрузить систему. Но в реализации задачи был один нюанс — при записи набора, свойство «Перезаписывать» устанавливалось в «Ложь». То есть каждое проведение документа добавляло записи в регистр. Это было необходимо по условиям задачи, но практически не влияло на производительность, т.к. по условиям отбора там всегда было 1-10 записей.
Тестирование функционала прошло успешно. Провели несколько десятков документов, убедились, что записи в регистре верные, ничего подозрительного не заметили и отправили в продуктив.
В ту злополучную пятницу утром сделали обновление боевой базы, и пользователи начали работать. 3000 человек бодро набивали документы и регистр стал наполняться данными. Проверив, что всё идёт хорошо, мы через несколько часов отправились домой со спокойной душой (работаем в разных часовых поясах с основными пользователями информационной базы).
Надо отметить, что серверы, на которых работала ИБ – чуть ли не одни из самых мощных в России, используемых под 1С. Но через несколько часов «что-то пошло не так» (с).
Пользователи стали отмечать снижение производительности системы. Все операции стали замедляться. Отклики на любые действия становились всё дольше. Нагрузка на оборудование неуклонно возрастала. Пока ИТ-отдел разбирался в чём дело, работа в системе практически встала. Оборудование не справлялось, очереди на дисках были длиннее, чем в отделениях Почты России. Было бы оборудование слабее, проблема бы обнаружилась почти сразу. Но мощнейшие серверы героически сопротивлялись моим кривым рукам полдня.
«Со слов» MSSQL самым тяжелым запросом внезапно стал запрос на чтение в моём регистре. Хотя я никаких чтений не делал. Довольно быстро обнаружилась и проблема в коде 1С. Я забыл установить отборы на набор записей. Если бы свойство «Перезаписывать» было бы установлено в «Истина», то ошибку я бы сразу обнаружил, т.к. каждая запись чистила бы весь регистр. А в нашем случае этого не происходило. На примере десятка документов, конечно, никаких потерь производительности мы не заметили. Но когда регистр стал наполняться десятками и сотнями тысяч строк — системе каждый раз приходилось проверять весь регистр на совпадение записей.
К тому времени, со слов некоторых пользователей, уже случился транспортный коллапс, т.к. автомобили не получали документы из 1С и не могли покинуть пункты разгрузки.
Вот так, «всего лишь» забыв поставить отбор в наборе записей, я положил одну из крупнейших баз 1С в России.
P. S. Смотрите также:
Комментарии (36)
nerudo
05.10.2019 11:14Вероятно из этого детектива была вырвана пара страниц, и я не понял что за «один маленький файлик на сервере 1С».
MAXXL
05.10.2019 11:26Скорее всего речь шла о технологическом журнале, ну и файлик logcfg.xml соответственно
Tavalik Автор
05.10.2019 11:32Да, конечно же logcfg.xml, который создает ЦУП для начала замеров и удаляет при остановке. В данном случае ЦУП был заврешен некорректно и файл остался, а значит сервер 1С все время продолжал писать логи.
aml
06.10.2019 09:31Да тут весь текст, как мышь погрызла. В настольной книге, сами знаете какой. Файлик, сами знаете какой. База на какой-то поддержке, про которую все всё и так знают — нечего и рассказывать.
Tavalik Автор
06.10.2019 11:50+1Да, писалось для «1С-ников», которые «в теме». В следующий раз постараюсь более понятным языком.
sbnur
05.10.2019 11:23А при чем здесь разработчик, причем который не смог — ожидались истории про разработчика, который смог
Tavalik Автор
05.10.2019 11:36Имелось в виду, что смог побороть свои сомнения и внести изменения в продуктив, несмотря на отсутствие хранилища, конфигурацию на поддержке, активных пользователей и другие «знаки».
dimoff66
05.10.2019 15:37Просто грохнуть базу не интересно, сам это делал несколько раз, интересно это делать в организациях, где последняя копия датируется нулевым годом от рождества христова или просто отсутствует как класс, тогда начинается веселье, а так работа 1с программиста скучная, крайне скучная, скучнее только бесконечные круды вэб разработчиков
EgorZanuda
07.10.2019 05:30Мир погряз в транзакциях. Был случай когда суточный бэкап не спас ситуацию, все сгорело в пожаре. Раз в сутки основной бэкап копировался на территориально удаленное хранилище, но он не сильно спас ситуацию.
Bedal
06.10.2019 00:12+1Надо отдать должное: выставить свои промахи на общий обзор и поругание довольно тяжело.
baxxter
06.10.2019 03:42Мне показалось что ноги у всех описанных случаев факапов растут из того, что инженерная культура 1С сильно отстаёт от мировых стандартов. Что я имею в виду под инженерной культурой? Разработка с использованием систем контроля версий, автотесты, ci/cd, мониторинг. Зачастую типовой проект 1С лишён вообще любого из вышеперечисленных пунктов. И в целом ситуация в мире 1С выглядит так, что нет ни инструментов для внедрения этих практик, ни желания и понимания у разработчиков зачем это вообще необходимо. Почему так происходит и стоит ли ожидать перемен в будущем?
Naves
06.10.2019 10:37Ну началось опять, что адинэсники не программисты. Такая культура, наверное, в 80% лавочек по разработке и саппорту любых систем. От инженерных систем вентиляции и СКУД до стартапов очередного сайта.
И вся система контроля версий в виде общей папке на сервере
\\server\общая папка\проекты\сайт_новый_обновленный2_очень_важного_клиента_20180102.zip
Перемен ждать не стоит, в отрасль приходит очень много людей, генерящих контент уровня индусского кода.
klez
06.10.2019 10:54В ближайшем — очень вряд ли. И проблема в образовании и сертификации разработчиков на «1С». Обучение строится по большому счету на запоминании каких-либо паттернов. Отсюда — нет понимания, почему работает так, а не иначе, а как сделать лучше, что будет, если база увеличится… Для примера: спросите рядового программиста «1С» как у него строится/читается XML (в ответ получите «умное» слово XDTO без какой-либо полезной информации) или что-нибудь о веб-сервисах. Построить правильные индексы? Зачем, итак нормально…
Большинство программистов пишут код «лишь бы как-нибудь» заработало. Никто не думает, а что будет, если этот код завтра выполнится не у 10-ти пользователей, а у 1000 или больше.
Пожалуй, единственный нормальный курс и сертификация — это 1С: Эксперт. Дается комплексное понимание производительности, почему работает так, а не иначе. Экзамен проходит неделю: теория и много практики. Есть люди, которые пытаются его сдать десятки раз и все безуспешно.dimoff66
07.10.2019 07:29В действительности все не так плохо, на недавнем проекте где я работал, тормозил а сильно админская страница, которая должна была выводить данные по 5000 партнёров компании, мне выпала честь это поправить с напутствием от тим лида сделать пагинацию по 10 объектов на странице. Когда посмотрел код увидел что запрос по каждому партнёру делается в цикле, причём не просто в цикле, а суммрованием данных из 4 таблиц, к каждой из которых так же делается один запрос. То есть вместо 1 запроса делается n * 4. В том же проекте цена на услуги просто менялась менеджером вручную без ведения какой — либо истории и даже логов кто поменял и когда. И это серьёзный проект со всеми атрибутами -, автотестаии, тестировщиками и т. д., но вот этой культуры работы с данными, которой учат ещё на курсах 1с специалист, в мире вэб разработки нет.
EfiopReal
06.10.2019 11:12+1Инструменты для всех названных пунктов уже есть, а вот желания для их использования нет. Но все меняется в лучшую сторону, постепенно думаю догоним.
nvv1970
06.10.2019 11:12+1В данном случае это тут совершенно не при чем. А проблема банальна: эксплуатация платформы без ознакомления с документацией. Что делает сервер, какие компоненты задействованы, какое они имеют поведение и т.п. — все изучалось методом тыка и полном игнорировании гугления проблем. Получить ответ "растут логи 1с" — любой нуб осилил бы.
ПС: собирать цупом данные — это жёстко, хоть это и официальный инструмент.
Tavalik Автор
06.10.2019 11:27Вы не совсем правы, все у нас есть: и системы контроля версий, и ci/cd, и мониторинг. С автотестами пока не так все хорошо, но тема активно развивается. Помимо стандартных «1С-ных» аналогов, энтузиасты делают интеграции с сторонними инструментами. И в данных историях все это было (кроме разве что тестов).
А вот на счет того, что инженерная культура слабовата — с сожалением вынужден в сами согласиться. Не знаю, как в других сферах разработки, но в 1С многие пренебрегают даже рекомендованными вендором стандартами. Но ситуация меняется: порог входа увеличивается, проекты дорожают, цена ошибки тоже. Необходимость использовать правильные практики возникает сама собой. Появляются профессиональные сообщества, которые рассказывают о своем опыте и т. д. Я вижу большие сдвиги в этом направлении за последний 3-5 лет.
CrushBy
06.10.2019 13:12А подскажите, пожалуйста, как в 1С работает система контроля версий? Как я понимаю речь идет о связке EDT + git. Как идет мердж логики, если там очень большое количество XML файлов, которые описывают метаданные? Ведь сливать XML файлы — это огромная боль.
Tavalik Автор
06.10.2019 14:20У 1С есть собственная система контроля версий конфигурации — «Хранилище 1С», которая отлично справляется со своими задачами в 99% случаев.
Описанная вами проблема также имеет ряд решений. Но обсуждать их конкретно с вами я не намерен, уж извините.
vasilyevii
06.10.2019 14:08Технологии есть, кое где они даже применяются. Но главная проблема 1С в том, что её вендор позиционирует свой продукт как в первую очередь доступный (дешевые лицензии и легко найти специалиста, способного внедрить/доработать/поддерживать)
То есть, когда потенциальный потребитель делает ставку на 1С, это значит у него задача сэкономить
1С это пример «экономики одноразового стаканчика», купил дёшево, попользовался, со временем система начинает деградировать, купил новую
Tavalik Автор
06.10.2019 14:36«1С» сильно разная — от ведения домашней бухгалтерии и учета продуктов в киоске с шаурмой, до автоматизации крупных производственных предприятий с восьмизначными и девятизначными суммами в стоимости проектов.
Akavi
06.10.2019 11:13Прикольные истории.
ИМХО хорошо иллюстрируют законы Мерфи:
"Закон Мескимена
Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы ее переделать, время находится.
"Расширение закона Мэрфи, сделанное Гаттузо
Нет такой плохой ситуации, которая не могла бы стать еще хуже."
Ждем продолжения. :)
YuriyBychkov
07.10.2019 09:36Оптимизация больших баз и новичок, слова которые не должны встречаться в одном предложении.
Вы явно франч. Благодаря вам и такой работе, у других нет отбоя от клиентов. Для кого-то повредить базу клиента это лютый звездец, для вас повод поржать "каааак?"Tavalik Автор
07.10.2019 09:37Да, вы конечно же правы. Это исключительная ситуация, но скажите, у кого их не бывает?
В свое оправдание добавлю, что после еще пары таких случаев, мы распрощались с данным разработчиком.
msin
Удивительный подход к автоматизации… Как оказалось, критически важнее нажимать стоп — если не нажать старт, то просто пропустишь сеанс записи логов.
Но разработчик этого хозяйства даже не подумал в сторону часового таймера автовыключения, и возложил на слабоотвественное звено (здесь это начинающий разраб) выполнение критически важной функции.
Возможно, я что-то не понимаю и в 1С нельзя остановить процесс по таймеру… но скорее всего это специфическое понимание экспертом процессов автоматизации — если каждый день в 17:00 нужен какой-то отчет, то тебе сделают кнопку и предложат нажимать её каждый день ровно в это время.
Tomasina
Есть ленивый админ, а есть опытный.
Tavalik Автор
Дело в том, что замеры надо было делать в тот момент, когда бухгалтерия запускала некоторые сложные расчеты в базах. А это время было плавающим и они уведомляли нас перед запуском.
Автозавершение можно было бы сделать, тут не спорю. Но мы же все умные задним числом.
koeshiro
А повесить запуск отчёта на старт работы? Прямо в коде?
Tavalik Автор
ЦУП — это отдельный инструмент. Он не связан непосредственно с информационными базами.
koeshiro
И у вас нет никаких отдельных мини-программ, которые можно вызвать из кода, и которые могут служить мостом?
JPEGEC
А валить логи в тот же раздел что и база это не удивительно?