Все мы любим рассказывать о своих успехах и не очень любим распространяться о неудачах. Но опыт ошибок зачастую более ценен, чем профит от удачно завершенного дела. Поэтому как раз о таких случаях я и хотел бы рассказать сегодня. Итак, поехали…
Горшочек, не вари!
Данная история произошла несколько лет назад, в самом начале моей карьеры разработчика 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. Смотрите также:
Автор: Виталий Онянов
