Если бы мы были обычной компанией, то вы никогда не услышали бы эту историю. Это то, во что ни один здравомыслящий человек не должен вписываться ни при каких условиях, это тип задачи, который просто невозможен для ИТ по своей сути, но нам нужно было это сделать. Потому что производство ставит реальные задачи. А они пахнут далеко не розами.
Итак, мы 80 лет ремонтируем вагоны, у нас 39 точек на карте: вагоноремонтных депо и участков отцепочного цеха от Белгорода до Белогорска, и раньше мы входили в состав РЖД. Потом вошли в ОМК, и понадобилось переехать из одного ИТ-контура в другой. Мы пользовались для управления производством и для отчётности частями софта РЖД. Софт был понятен, привычен, очень глубоко интегрирован во всё, что у нас есть, и в ландшафт РЖД.
Дальше у нас был простой выбор: либо мы остаёмся вообще без систем, либо внедряем свои. РЖД была не готова держать в своём контуре компанию чужой группы, а переход в DMZ после подсчётов оказался почти таким же по цене, как новое внедрение. С учётом отдельной лицензии SAP — даже дороже.
В итоге мы оказались в ситуации, когда за год нужно было выделиться в отдельный контур, внедрить 1С ERP, запустить на ней управленческий и бухгалтерский учёт, само управление производством, и всё это — без шансов сделать что-то не то.
На всякий случай подскажу, что мы умеем ремонтировать вагоны. Мы не занимаемся внедрением ERP, и вообще на этот проект у нас было всего человек пять айтишников. Сюра в ситуацию добавил тот факт, что подрядчик понял задачу не как «Нужно кровь из носу сделать до дедлайна», а как «Нужно расписать план работ до дедлайна, а там — как пойдёт».
В общем, на начало проекта мы ещё не понимали, что нам придётся повидать.
Не повторяйте такого дома. Никогда!
Особенности производства
Вагоны ремонтируются либо по факту поломки, либо планово. В отличие от автосервиса ремонтный завод несёт ответственность за каждую отремонтированную деталь и гарантирует, что от момента выпуска вагона до следующего планового ТО по его вине ничего не сломается. Если где-то на Дальнем Востоке между перегонами грузовой вагон выйдет из строя из-за нашего брака или неверно выполненной операции — виноваты мы. Кстати, мы — это «ОМК Стальной путь», приятно познакомиться!
В общем, мы как вагоноремонтная компания несём ответственность за качество проведённого ремонта в период эксплуатации. Однако у появления каждой неисправности есть свои причины, и они не всегда относятся к качеству ремонта. Например, если есть ошибки в управлении машинистом тормозами поезда — колёса стачиваются. Эта неисправность — следствие неправильной эксплуатации подвижного состава, а не ремонта.
Но если буксовый узел колёсной пары нагрелся в период эксплуатации вагона, то это может иметь отношение к качеству ремонта. Во всех случаях при появлении неисправностей нужно разбираться предметно и проводить расследование. Определение таких инцидентов, их фиксирование и расследование составляют значительный пласт работы ERP.
Предположим, что между первым и вторым ТО осмотрщик определил на станции, что буксовый узел греется. На этой станции вагон выводится из состава поезда, то есть происходит отцепка. К каждой отцепке нужно знать, какая деталь, каким образом и какие процедуры прошла у нас на производстве. Уметь доказать, что всё было сделано правильно, приложить все документы и данные экспертиз.
Каждая литая деталь на вагоне имеет свой уникальный номер (это требование регулятора) — по нему важно отслеживать весь её путь и связывать с проведёнными ремонтами, заводом-изготовителем, контрольными процедурами на производстве и так далее.
Почему 1С ERP
Шёл далёкий 2019-й — год, когда мы не знали ни ковидных ограничений, ни санкций с уходом зарубежных производителей программного обеспечения из России. После того как нашу компанию купил ОМК, надо было уходить с имеющихся систем. Нам дали период, когда ещё можно было пользоваться всеми внутренними ресурсами, но в конце этого срока просто пришёл бы админ и всё вырубил. Это как закон природы.
Вторая особенность — дедлайн был привязан к новому году, потому что бухгалтерскую отчётность нужно было вести в новой системе с нового же года, чтобы потом не пытаться мержить две бухгалтерии. То есть даже теоретический заезд за дедлайн был невозможен. С нового года нужно было извернуться как угодно, но работать в новом контуре. Без возможности дублирования в исторических системах (что там дублирование данных — не было даже возможности любого доступа к ним!).
Поначалу мы рассмотрели вопрос тиражирования SAP, но довольно быстро отказались от этого из-за цены. SAP железных дорог переписана отечественными разработчиками примерно на 90 %. Собственно, по факту можно сказать, что это полностью отечественная система, сделанная в их фреймворке. Повторить это с нуля близко к невозможному.
Возник нелёгкий выбор между несколькими решениями. В тот год остро не стоял вопрос импортозамещения систем. Но всё же мы с 2017-го присматривались к 1С, потому что есть 1С ERP, где можно в одном контуре вести и управленческий учёт, и бухучёт, а также управлять производством, продажами, закупками и т. д. То есть все данные правильно обрабатывались бы как единое целое, и не приходилось бы регулярно сверять оперативные данные производства и продаж с данными учёта. Нам это было очень давно необходимо для нужд производства. Собственно, были даже требования к внедрению для потребностей управленческого учёта — это что-то вроде эскиза ТЗ, но только на половину задачи — чисто для управленческого контура, не трогая регламентированной отчётности. То есть надо было докрутить бухгалтерскую и налоговую отчётность, и всё должно было стать красиво.
Провели предпроектное обследование
Первым делом мы стряхнули пыль с написанных ещё в далёком 2018 году функциональных требований к системе и пошли искать компанию, готовую их обновить и дополнить теперь ещё и требованиями к бухгалтерскому учёту, формированию регламентированной и налоговой отчётности. От ОМК мы получили крупного интегратора — прекрасных людей, собаку съевших на решении задач металлургической (и не только) сферы. Однако грузовые вагоны они наблюдали лишь со стороны, и, с их точки зрения, на начало проекта вагон был чем-то вроде материальной точки. А мы ещё не знали, чем это может аукнуться, и подозревали, что просто долгими объяснениями принципов ремонта.
Дальше консультанты и архитекторы подрядчика собрали требования: разговаривали с людьми, где-то подключались онлайн, где-то ходили ногами в офис. За пару месяцев — сроки горели — мы вместе зафиксировали новые требования. Забегая вперёд, скажу, что было очень плохой идеей не ходить в депо, а опрашивать только управленческий и бухгалтерский блоки. Но вагоны тогда виделись материальными точками, напомню. Как говорится, «жираф большой — ему видней!», но зачастую процессы в идеальном видении далеко не похожи на реальность, которая творится на местах в глубинке. Фактически мы и не могли успеть выехать во все депо, потому что — дедлайн: даже если бы мы понимали уровень проблемы, то, кажется, смогли бы сделать не очень много. Масштабировать эту часть очень сложно.
Подрядчик подошёл очень основательно. Документ получился фундаментальным и в немного непривычном нам формате. По сути, он представлял собой реестр функциональных требований, описанных до третьего уровня: что именно система должна уметь.
Уже позже, на этапе моделирования, в рамках основного проекта появился реестр функциональных разрывов: под ними понималось отклонение типовой 1С ERP от тех требований, которые у нас были. А типовая 1С не знает, что такое вагон, что такое комплектация вагона, не интегрирована с системами, которые определяют жизненный цикл вагона: это системы РЖД, которые управляют допуском, ремонтами и так далее. Инструменты управления сводной потребности вообще отсутствовали. Какие-то инструменты были, но работали не так. Не хватало работы с исками, анализа расследований отцепок и так далее. Эти модули мы позже писали с нуля. Работа с претензиями тоже была очень странной: в типовой 1С ERP нам надо было переписать модуль рекламаций так, чтобы там были замечания по ремонту от эксплуатантов, и связать это с деталями производства.
Тем не менее подрядчик описал в талмуде, что именно нужно поменять и конкретно — как именно.
Однако появился план. Мы знали: он поменяется, но думали, что речь пойдёт про 3–4 % обычных его изменений.
План внушал уверенность. Нужно было только нарисовать остальную сову. Оставалось восемь месяцев до дедлайна.
Мораль: если на этапе формирования технического задания видно, что разрыв между ожиданиями и реальностью больше, чем вы способны уместить на слайде и объяснить даже бабушке, то в оценке сроков и бюджета точно будут косяки.
Восемь месяцев до 1 января 2021 года — дедлайна
Собранный за предпроект реестр функциональных требований и функциональных разрывов был отдан в закупку. В жёсткой конкурентной борьбе выбора подрядчика победила та самая компания, которая обследовала процессы на предпроектном обследовании, потому что у них было преимущество — они уже были погружены в наши процессы.
Весь год ничего не подозревавшие пользователи спокойно работали в SAP-контуре, а мы готовили 1С ERP.
В апреле 2020-го мы начали проект. Первая очередь — до 1 января 2021 года: нужно было запустить регламентированную отчётность, то есть научиться учитывать все средства производства и сдавать налоги. Во второй очереди были оперативная и управленческая отчётности, то есть аналитика производства и фактически само управление им.
Первая иллюзия о том, что нам в большей части процессов подходит типовое решение, была развеяна после первых же встреч по моделированию ещё на этапе первой очереди проекта. Стало понятно, что бизнес не готов мириться даже с небольшим расхождением новой автоматизации процесса. Зачастую банальной функции (например, сторно документов) просто не было в актуальной на тот момент версии 1С ERP.
Тут ещё бахнул ковид, что добавило нам море радости. Тогда-то мы думали, что это на месяц, а потом мы поднажмём и ворвёмся. Врываться пришлось удалённо — без уточнения требований и их примерки на текущие процессы реальных площадок.
В общем, этапы моделирования и разработки прошли в процессах «Смотрите, будет так», «Нет, так нельзя ни в коем случае, надо нормально». И это мы ещё не рассказываем про миграцию остатков — те ещё радости были!
Пилотное внедрение было в двух депо: в Сасове и Кургане. Конечно, депо было вообще не до «пощупать енту 1С»: у них закрытие года на носу, да и набивать документы полноценно в две системы никто не собрался. Сравнивать отчётность из-за разных подходов хранения и отображения в системах и новой учетной политике, унаследованной уже от ОМК, тоже было сложно. Или даже бессмысленно. Но уже тогда стало понятно, что мы КОЕ-ЧЕГО не учли.
Дальше был выбор: запускаться в бете (точнее, даже в альфе) на всех площадках либо же затягивать переход ещё на год. Только нюанс в том, что второго варианта не было.
Мы многое начинали прощать нашему подрядчику и, несмотря ни на какие проблемы и очень небольшой пилот, приняли решение запускать 1С на всех локациях.
Это абзац
В первый месяц, очевидно, никто даже не понял, что мы запустили новую систему, так как продолжали закрывать год в прошлой.
А вот потом начался цирк с конями. Только цирка было мало, а коней — много.
А это, напомню, боевая инсталляция. Старые системы отключены. Либо учитывать в этой, либо второй вариант, которого не было.
До момента миграции остатков негативы не вылезали на уровень выше пользователей. Просто никто ничего не понимал и делал то, что получается, то есть операции по закупкам. А тут в 1С стало нужно делать вообще всё — по учёту производства, продаж, закупкам, взаимодействию с поставщиками, перемещению материалов, их списанию, реализации услуг и т. д. Самой большой проблемой в первые три месяца стала сдельная заработная плата. Было непросто научить всё депо полностью заносить все данные по сдельной заработной плате в разрезе новых аналитик, а ведь это зарплата производственного персонала. Но мы сделали всё, чтобы выплатить людям зарплату вовремя и не задержать её ни на один день.
Казалось бы, что могло пойти не так?
Напомню, наши депо — это 39 больших площадок. Каждое депо — со своими технологическими особенностями и нюансами. Некоторые — довоенные, и им под сотню лет. Эти депо за все эти годы развивались с учётом ситуации, то есть эволюционно. Вот было паровозное депо, появилась отдельная пристройка для вагонов. Потом эта пристройка стала основной площадкой.
Если проектировать депо с нуля, то у вас будет логичное конвейерное производство, где неисправные запчасти вагона (после его разборки) просто двигаются по этапам, и с ними делаются операции, идущие подряд. Так действительно выглядят новые депо — те, которые создавались на современной платформе стандартов.
А те вагоноремонтные депо, что были организованы из старых паровозных, перестраивали на очень ограниченной территории. Со временем вагоны модернизировались, технологии развивались, появилось новое диагностическое оборудование и возникла необходимость в новых производственных участках. А территория-то оставалась прежней — из-за этого возникали противотоки в технологических цепочках ремонта вагонов, и цепочки получались очень нестандартными.
Стандартная техкарта, где есть операции 1–2–3–4–5, может стать 1–3–2–4–5 в одном месте страны, в другом месте страны операции № 4 вообще не будет, а в третьем месте операций № 3 — целых две, и надо выбирать в зависимости от себестоимости производства. Где-то это 50 человек в цеху, где-то — все 100. И это именно люди из цехов, которые привыкли работать в другой системе: все данные о сделанных операциях они вносили с задержкой дней до пяти, а мы стали требовать день в день или максимум — сутками позже. Потому что операции должны идти последовательно друг за другом, чтобы передавать процессы по цепочке. Тогда в 1С формируется реальная картина, а не отстающая. И та операция, которую отразили в цеху, рождает бухгалтерскую проводку. Если мастер не внёс операцию в систему, то бухгалтер страдает и не может отразить списание со склада или принять к учёту.
Прошлая система была исторически привычной и понятной, хотя и не вполне интегрированной. Собственно, их было две: одна система — оперативного, а другая — управленческого и бухгалтерского учёта SAP ERP. Между собой они были полностью разрозненны, и регулярно приходилось сверять остатки. Интеграции между ними не было. Зато привычно. А всё непривычное встречается с вилами.
А тут мы с новшествами, да такими, что прямо заменяем людям из цехов картинку мира, в которой они работали. Да ещё надо было вносить оперативные данные и в ту, старую систему, и в нашу, новую, но стало куда больше аналитики. Также потребовались новые дополнительные люди, которые руками переколачивали данные в 1С. Это тоже вызывало определённый негатив. Мало того, что надо было вносить в две системы, необходимо было взять ещё и дополнительных людей, а это дополнительные расходы на депо.
У 1С ERP же недостаток в том, что она сделана не для людей. Как и любая универсальная система, она решает задачи всех сразу, но делает это неоптимально для каждого в отдельности. Да, её можно научить правильно готовить, но на это просто не было времени. Нужно было внедрить хотя бы через задницу, но любой ценой до нового года.
Проблема была в том, что 1С ERP позволяет одну и ту же операцию отразить различными способами и даёт многое на выбор пользователя. Где мастер выбирал деталь — открывалось с десяток окон с её параметрами, складами материала, свойствами и атрибутами, метриками, вопросами про тип списания и так далее. Более того, поскольку мы не собрали всех требований из депо, часто система просто не давала возможности проводить другие операции, пока не будет введён результат той, что в цепочке 1–3–2–4–5 не на том месте. А над нашими пользователями в идеале нужен жёсткий пошаговый контроль, которого не было.
Ещё смешнее то, что мы заложили идеальную ролевую модель, собирая требования под идеальное депо. То есть часть данных вводил кладовщик, часть — инженер по труду, часть — инженер по планированию, часть — оператор в цеху после выполнения операции. Если эти данные друг с другом не бились, то это было легко проконтролировать в нашей идеальной модели.
Оказалось, что в маленьких депо многие роли совмещаются, и в лице сурового товарища за станком могут находиться сразу и исполнитель операции, и проверяющий, и контролёр ОТК. Он жамкает на кнопку «Выпустить», и его прав достаточно, чтобы выпустить, невзирая на всякие там красные поля и странные всплывающие окна. Он их последовательно закрывает, говорит: «Я уверен!» — и проводит документ. Ну то есть идея была разделить ответственность за ввод между несколькими людьми, а по факту иногда получилось, что всё вносит один.
Типовая 1С ERP не подразумевает работу в учёте низкоквалифицированного персонала. Пользователь должен думать, какая операция и для чего, какие выбрать аналитики. Наши операторы, естественно, ничего этого не понимали. Им нужен был интерфейс на пять знакомых полей, а не вот это всё. Дальше система должна додумать, что он сделал и как, показать ему результат на проверку. Кроме того, система должна на каждом шагу контролировать, что пользователь вводит и куда. Наша контролировала уже при окончании ремонта или даже закрытии месяца в момент расчёта себестоимости, условно разрешая все без исключения пулл-реквесты в учёт.
О том, что такое закрытие месяца в оперативном учёте, наши пользователи тоже никогда не слышали и привыкли вносить правки в любой документ в любом периоде, когда им необходимо, а тут выясняется, что нельзя! 1С не всегда умеет разделять дату первичного документа и дату его принятия к учёту, а как внести корректировку, например, в ошибочно внесённый номер документа или иной его реквизит, если документ находится в закрытом периоде, — так это вообще фантастика!
Одну и ту же операцию можно сделать разными способами. Списывая материал под вагон, указать статью из группы ИТ и списать на админов несколько колёсных пар. Или сначала оприходовать материал, потом — списать, а затем скорректировать приход на меньшее количество. Та-дам! На складе лежит минус четыре ящика болтов! Отрицательный остаток! Или лучший фокус, который проделали в каждом депо: после расходов, учтённых в себестоимости, взять исходный заказ и пометить на удаление. То есть себестоимость посчитана, но поделена на ноль. Иногда — буквально, потому что если вы думаете, что заменить все числа на «0» в корректировке — это плохой способ удалить заказ, то вы никогда не разговаривали со слесарем, ненавидящим вашу систему.
Но это я забегаю чуть вперёд. Сначала, конечно, ненавидеть начали нас.
Факелы и вилы
Каждый раз, когда мы запускаем новый функционал, начинается факельное шествие, и нас хотят поднять на вилы. Сотрудники депо хотят работать как привыкли, и все эти нововведения им до лампочки. Ну или ещё до чего-нибудь.
Сначала происходит совещание, на которое приходит человек 200 сотрудников со всей страны, и человек 10 из них говорят: «У нас ничего не работает, нам надо либо производством заниматься, либо вашу систему как-то осиливать». Им начинают поддакивать ещё человек 30, которые не могли так точно сформулировать мысль, но чувствуют что-то похожее.
Дальше мы ещё раз объясняем, что происходит. В данном конкретном случае — всё то, что говорили до этого про невозможность работать, как, в принципе, раньше. Физически.
Через несколько циклов начинается конструктив: кто-то спрашивает, можно ли исправить вот такой функционал. Потом — ещё и ещё, и вот у нас образуется очередной список разрывов и замечаний. Мы идём их исправлять до следующего такого совещания.
Второй вариант факельного шествия — это когда сотрудники с мест просто пишут в поддержку. В нашем случае они звонили на вторую линию, которую на старте взял на себя подрядчик. Иногда описывали свои типовые операции на производственном сленге, щедро сдобренном связками из великого и могучего. А подрядчик даже не представлял, что это за слова, как из них можно составить осмысленную конструкцию и тем более чего от него в этом конкретном случае хотят, а также чем помочь. В итоге у нас образовалась привычка кодить прямо на бою в попытках поправить что-то, что мешало людям в депо. Если вы не кодили на проде, то очень советую: опыт незабываемый! Иногда — сразу для всего депо. Но больше — для бухгалтерии. Причём поскольку это 1С, мы ещё кодили в известных местах, в основном — поблизости от интерфейсов: если залезть чуть дальше, то можно покорраптить и всю базу. Причём тоже боевую.
Был как-то случай: в апреле 2021 года при одном из обновлений продуктива, которое прошло успешно, спустя несколько минут после того, как пользователи уже зашли в систему, мы поняли, что с базой что-то не так. База данных прилегла отдохнуть. Это было обновление в пятницу вечером. Все выходные мы, подключив смежные ИТ и тех, кто отвечает за СУБД, занимались восстановлением. Восстанавливали базу из бэкапа на пять минут до обновления или пять минут до краха. С тех пор по пятницам мы не обновляемся ни в коем случае.
Третий вариант факелов с вилами — это когда молчаливое большинство всё поняло, осознало, но борется с системой понятными им способами. Где-то депо сформировало бригаду по принципу той знаменитой Oldman’овской команды слесарей по переклеиванию этикеток. Эта бригада прописывала фиктивные операции, чтобы можно было продвинуться в процессе, а потом корректировала их реальными, когда они проходили. Где-то мастера просто вносили любые левые данные, т. к. заметили, что система после этого формирует документ и можно приступать к другой колёсной паре. Где-то брутфорсом перебирали непонятные им поля — результат такой, как будто били кувалдой по клавиатуре.
Иногда пользователи просто недовольны, но с этим надо жить. Мы пытаемся им объяснить, почему так, для чего лишний клик и что он на самом деле совсем не лишний.
Тем не менее мыши кололись, но продолжали жрать кактус: надо было закрывать отчётность.
В этот самый момент начала появляться ещё одна проблема.
Дело в том, что мы закупили железо по минимальным системным требованиям
Подрядчики — умные и знающие люди с опытом написания книг по техвопросам 1С — дали рекомендуемые требования по железу и минимальные. Мы же умные: взяли минимальные и закупились по ним. Примерно на тысячу пользователей тогда. Так вот, на пилотных внедрениях многие просто не заходили в систему.
А когда начали заходить, система начала виснуть. Где-то это было 30 секунд между экранами, где-то просто закрывались окна (когда канал из глубинки лагал). Каналы связи не тянули: если в прошлой архитектуре многое считалось локально, то тут все данные бегали в центральный ЦОД. Ещё параллельно у нас появилось много видеоконференций в трафике, а приоритетов не было, поэтому ERP работала очень печально.
Дважды за проект мы докупили железа (это казалось сложным, но скажу, что по сравнению с концом 2022-го тогда это было просто легчайшей операцией) и в итоге превзошли все рекомендованные характеристики в разы. И кое-как начали работать.
Как итог текущий продуктивный контур — это почти 2 терабайта ОЗУ, 158 ядер и 12 терабайт SSD.
Про закрытие
Итак, мы остались без системы, не сдавали отчётность в старой версии, нас ненавидели пользователи, у нас были адские лаги по железу и каналам, мало что работало как задумано плюс начали появляться новые критичные требования по мере внедрения. Ну и ещё пару раз мы выстрелили себе в ногу отважными хотфиксами. Да, ещё никто не понимал 1С: ни пользователи, ни мы, ни создатели, а интегратор до кучи не понимал особенностей производства. Пользователи колотили данные от балды, не понимая, что и зачем. Им колесо точить, а не документ делать.
В этой милой умиротворяющей обстановке, полной добра, позитива и взаимоподдержки, надо было всё же вести отчётность. Пока только регламентную, но всё равно.
Бухгалтерия начала собирать бумажные документы и XLS-файлы, чтобы потом внести первичку и нормально всё посчитать, когда ситуация хоть немного исправится.
Сначала мы хотели закрыть январь до конца февраля, но были слишком оптимистичны: закрывали в конце марта. Люди вносили данные, плакали, возмущались, орали. В какой-то момент стало понятно, что надо закрывать январь хотя бы с 70 % документов. В смысле это как запускать компиляцию и получать итоговый отчёт.
Сборка отчётности — это как компиляция проекта. Каждый из мастеров и операторов каждым документом делает пулл-реквест, а нам надо всё это собрать в один большой страшный документ. Для этого нужно, чтобы все цепочки данных были непротиворечивы, более-менее полны, более-менее логичны и правильно собраны.
Ха-ха!
Вот так мы внезапно чуть не влетели на 29 миллиардов рублей, потому что кто-то забил серийный номер в стоимость. И таких примеров много.
В общем, мы закрывали месяцы с отставанием сначала больше чем на три месяца, потом — всё меньше и меньше. В итоге к февралю 2022-го мы получили закрытую отчётность по 2021 году, что смотрелось как подвиг.
Но интересны тут помесячные закрытия. Давайте рассмотрим март, который подарил нам много эмоций. В марте 2021-го мы закрывали январь-2021. Ключевая задача — провести расчёт себестоимости, сформировать бухгалтерскую и налоговую отчётность за январь.
Сначала мы собрались с духом и запустили сборку по тому, что волевым усилием признали консистентными данными.
Первый расчёт взял и упал из-за недостатка ресурсов. Мы добавили железа, чтобы узнать, что ресурсы выделялись на огромные временные таблицы, потому что несколько ошибок могут порождать в десятки и сотни раз больше расчётов, чем ожидается.
Потом расчёт многократно падал из-за ошибок в данных.
Если вы думаете, что в той версии 1С ERP можно было взять и посмотреть, где ошибка, чтобы быстро метнуться и её исправить, — это значит, что вы не в полной мере знакомы с логикой 1С. Уловка-22 состояла в том, что отладочный лог формируется по итогу завершения расчёта. То есть отладочный лог вы получаете только в той ситуации, когда всё закончилось. У нас было 80 операций сборки из разных источников, и первые 77 из них — критичные, где ошибка вела к остановке процесса. То есть лог помог бы только при ошибках на шагах 78–80.
В самом начале для исправления ошибок мы колхозили отчёты, чтобы эти ошибки найти и потом их поправить. На более поздних стадиях надо было дописывать отладочный код.
Вы запускаете процедуру, она длится 60–70 часов. Через сутки она падает, вы приходите:
— Почему?!
Разработчики:
— А хрен знает! Давайте перезапустим!
Перезапускают. То же самое. Или, может, действительно запускает. Но чаще падает.
Добавляют отладочный код. Через три итерации — хлоп, не упала на этом шаге, но упала на следующем. Новый отладочный код. Для поиска каждой ошибки ждём N часов.
В 2.5.6 появилось формирование лога на лету, но в 2.5.4 это было опасным развлечением.
Важно, что отладочный код — нетиповой. И он вносится не обёрткой в гипервизор, а прямо внутрь процедур ядра. Есть, например, процедуры расчёта, где выполняется математический движок для систем линейных управлений, много временных вспомогательных таблиц в памяти. Всё это относится к категории «Не влезай — убьёт!». Лезть туда отказывались даже опытные интеграторы, потому что за годы разработки внутри 1С оно обросло костылями и крайне неправильными строками кода, которые делают что-то неочевидное. Неловкое движение, которое, казалось бы, никак не затрагивает код, ломает это хрупкое равновесие и приводит к падению всего карточного домика, портит данные, и не факт, что получится гладко откатиться. Никто не понимает, как это работает, а нам это ещё и отлаживать.
Ладно, кое-как собрали.
Дальше год
В судорожном тушении пожаров и попытках выстроить работу пользователей пролетела пара месяцев, и подходил к концу март 2021-го. Мы только готовились к запуску первого расчёта себестоимости. 11 апреля 2021 года он наконец-то состоялся. Длился больше 67 часов, но по итогу показал кучу ошибок в данных и то, что его результаты недостаточны для формирования регламентной отчётности.
Хороший внедренец посадил команду поддержки исправлять ошибки в данных, которые система подсвечивала перед сборкой. Это где неправильные даты и неправильные последовательности документов. Вносили исправления и перезапускали расчёт снова и снова вплоть до сентября 2021 года, а первый расчёт с типовым ответом «Расчёт выполнен успешно» мы получили только 7 августа 2021-го. Расчёт был за январь. Впереди были остальные месяцы года.
Тучи сгущаются, все в шоке. Главный вопрос у бухгалтеров и экономистов: «Вы нам хоть год-то закроете? А то отчётность неоткуда формировать». Подрядчик говорит: «Мы вам поможем сделать отчётность в Excel, а так — перевнедряемся».
Поэтому Excel — наше всё! Вплоть до закрытия годовой отчётности. Первый, второй, третий кварталы закрывались чисто в великом и могучем Excel. Выгрузками из системы формировались и напильником отдельно допиливались налоговые декларации. А терпение бизнеса и бухгалтерии закончилось ещё весной.
Мы же всё это время активно ищем, кто возьмётся помочь закрыть год и получить отчётность в текущей системе без перевнедрения.
Находим подрядчика 2, который знаком с ремонтом (локомотивов). Они подтверждают, что смогут закрыть год в текущей системе. Подрядчик 2 выдаёт требования к оборудованию, настройкам кластера, настройке SQL. Договариваемся о погрешностях расчёта, с которыми месяц считается закрытым.
В октябре 2021-го закрываем февраль и март-2021. Время расчёта — 15–20 часов. С ноября 2021 года по февраль 2022-го с подрядчиком 2 закрываем месяц за полторы-две недели, делая два расчёта. Первый — основной, затем правим ошибки, которые нельзя найти до первого расчёта, и сразу запускаем второй.
В конце февраля 2022 года закрываем декабрь и год. Годовая отчётность сформирована из системы. Наконец выходим на приемлемый график закрытия — это 11-й-12-й рабочий день (забегая вперёд, сегодня — на девятый).
Итого
Нам оставалось всего ничего:
- Обучить людей депо правильно работать.
- Дописать примерно 60 % функционала.
- Обновить железо в цехах, а потом ещё и сервера во второй итерации.
- Обновить каналы связи или хотя бы сделать приоритизацию трафика.
- Объяснить разъярённой толпе, что происходит.
- Исправить очень много ошибок в том, что вносили люди из цехов.
- И ещё, и ещё...
В общем, как в том анекдоте: «Что случилось, что случилось? Убили нас!»
Сейчас, пока всё это пишу, я проживаю весь тот период заново, вижу тёмные тучи над нами и понимаю, что тогда это было для меня не историей успеха, а скорее историей сражений. Мы героически рубили драконам головы, а на их месте, казалось, вырастали по три новые (ну ладно, одна-две). Хотя, возможно, я слегка сгущаю краски, и позитивные моменты случались — как та первая микропобеда, когда мы закрыли год. Дальше мы продвигались шаг за шагом и смогли вырулить из всего этого вала — сначала отставая с учётом, а потом плавно нагоняя сроки.
Но про это будет другой пост.
Автор: Леонид Коршак
