Каталог решений - Как мы в Авито терабайтную УХ на 29 релизов обновляли

В Авито исторически сложилось так, что релиз “Управления холдингом” не обновляли 3 года. Так как в УХ ведется регламентированный учёт, то для учета изменения законодательства в течение 3 лет делали частичное обновление функционала. Когда переносили функционал прослеживаемости товаров, стало понятно, что из-за изменений БСП делать частичные обновления становится слишком трудоемко. И в будущем на обновление типового функционала может понадобиться неприемлемо много времени. Единственный выход из ситуации — догнать в УХ типовой релиз. Для понимания сложности задачи приведу некоторые характеристики базы:

• размер базы — 1,5 терабайта,
• количество изменений в конфигурации — около 60 тысяч,
• количество хозяйственных операций — около 11 млн в год,
• количество пользователей — около 300 пользователей.

Понятно, что при таких характеристиках базы обновление релиза — это проект. На технические работы по проекту были привлечены 5 специалистов от подрядчика, которые до этого не работали с нашей УХ. Остальные работы выполнялись силами Авито. Проект длился 7,5 месяцев, полгода на подготовку и полтора месяца опытно-промышленной эксплуатации. В процессе проекта в нашу конфигурацию УХ было перенесено 1,4 млн изменений из типового релиза. Организована работа 34 исполнителей. Исправлено около 450 багов.

В итоге на новогодних каникулах 2023 года мы обновили релиз УХ с 3.0.8.5 до 3.1.17.11, то есть на 29 релизов. Это заняло 74 часа (из них 46 часов ушло на обработчики данных, 22 часа — на реструктуризацию базы данных, 3 часа — на прочие технические действия).

Далее я построю статью в формате советов самому себе годичной давности. Что-то было так и сделано. А что-то можно было сделать лучше. Чтобы советы стали понятнее, расскажу общую идею реализации проекта.

1. Обновлялись в 3 шага: с 3.0.8.5 на 3.0.20, с 3.0.20 на 3.1.10, с 3.1.10 на 3.1.17.11. В промежуточных релизах оставляем только доработки, которые необходимы для сохранения данных.
2. Тестирование происходило тремя этапами: два тестирования аналитиками (тестирование по сценариям и более широкое тестирование) и тестирование пользователями.
3. За месяц до обновления рабочей базы УХ объявлялась “заморозка” для доработок УХ. В этот период в целевой релиз УХ переносились доработки, которые были выполнены с момента подготовки целевого релиза для тестирования. На этапе “заморозки” проходило финальное тестирование аналитиками. 
4. Обновление проводили на новогодних каникулах. Для обновления было выделено технологическое окно 4 суток.

Советы по технической части

Про подходы к обновлению

1. При планировании обновления на промежуточные релизы можно не учитывать последовательность, рекомендуемую “Фирмой 1С”. Мы пропустили часть релизов, на которые рекомендует обновляться “Фирма 1С”. За счет этого экономится время на подготовку целевой конфигурации с доработками и экономится немного времени на реструктуризации базы данных при обновлении. Мы  обновлялись в 3 шага — с 3.0.8.5 на 3.0.20, с 3.0.20 на 3.1.10, с 3.1.10 на 3.1.17.11. При этом тестовое обновление с 3.0.8.5 на 3.1.17.11 в один шаг показало, что это тоже рабочий вариант (ошибок при обновлении было не больше, чем при обновлении в 3 шага). Но мы решили не отклоняться настолько от рекомендуемой последовательности, так как особых выгод для нас этот вариант не давал.
2. В промежуточных конфигурациях сохраняй только доработки, которые необходимы для сохранения данных при реструктуризации. Это позволит существенно сэкономить время на этапе подготовки конфигураций. Минус этого решения — при обновлении рабочей базы не будет варианта остановить обновление на промежуточном релиза. Важно во время “заморозки” доработок не забыть перенести все доработки, которые нужны для сохранения данных, в промежуточные конфигурации.
3. Обрати внимание на удаление результатов частичных обновлений. На этом этапе легко можно потерять доработки. Решение проблемы — или обратить внимание программиста на эту функциональность, или усиленно тестировать функциональность на целевом релизе. Лучше и то, и другое.

Про пересечение с другими проектами

4. Не делай проект обновления во время других IT-проектов, которые существенно изменяют среду работы 1С. Если это условие выполнить невозможно, то нужно заложить в плане проекта существенное время на тестовые обновления в новой среде. Потому что в новой среде вполне возможны неожиданные проблемы. Например, мы при реструктуризации БД на postgre (до этого обновлялись на MS SQL) столкнулись с проблемой, на решение которой ушло 3 недели. Если нет возможности заранее протестировать обновление в новой IT-среде, то надо понимать, что ты вкладываешь в проект существенную вероятность неуспеха.

Про организацию процесса разработки

5. Если у вас сложный процесс разработки, то рекомендую обратить внимание, чтобы конфигурация, которая обновляется, совпадала с конфигурацией рабочей базы. Небольшие различия могут привести к длительным разбирательствам при тестах.
6. Обрати внимание программистов на сохранение комментариев к доработкам. Заранее проговори с ними как действовать в разных случаях.
7. Отдельно веди учёт переноса частичных обновлений из типового релиза, которые будут делаться на старом релизе в процессе обновления. Это важно при переносе доработок, которые выполнялись во время хода проекта.
8. Если для тебя критично важно качество кода, то делай код-ревью во время проекта. Это необходимо учесть при планировании проекта. Если этого не будет, то качество кода в конфигурации снизится.
9. Отдельно планируй как технически будут обновляться внешние отчеты и обработки. Лучше избавиться от них до проекта.

Про тестирование

10. Возможно при подготовке тестовой базы проще переносить данные из рабочей базы вместо обновления копии рабочей базы. Это может существенно сократить время на подготовку базы с актуальными данными и актуальным релизом при тестировании каждой сборки целевой конфигурации.
11. Откладывай бекапы, которые обновляете во время тестирования до целевого релиза. Они пригодятся при исправлении ошибок, которые будут найдены при тестировании.

Про подготовку к обновлению

12. Большая часть времени обновления уходит на обработку данных при переходе с релиза на релиз. У нас на обработку данных ушло 62% от общего времени обновления. Поэтому обработчики данных нужно выполнять на максимально быстрых дисках.
13. Заранее запланируй переведрение подсистем, если это необходимо. На старте проекта проанализируй какие типовые подсистемы сильно изменились. Если рассчитывать, что такое решение будет принято в ходе проекта, то вряд ли перевнедрение произойдет.

Советы по организационной части

Про общую организацию проекта

1. Лучше не пересекать проект обновления с другими проектами изменения IT-ландшафта, в котором работает 1С. Если это невозможно, то руководители проекта обновления должны знать основные вехи других проектов.
2. Раздели на разных людей функции руководителя проекта и технического лидера. Если назначить одного человека, то он может стать узким местом, из-за которого завалится проект.
3. Заранее запланируй подготовку среды разработки на целевом релизе конфигурации во время “заморозки” доработок.

Про тестирование

4. Важно донести до всех участников проекта, что программисты не смогут собрать 100% рабочую конфигурацию на новом релизе. Это можно сделать только вместе с тестированием. Важно при планировании проекта максимально детально спланировать тестирование и подготовиться к нему. Всем участникам проекта надо объяснять, что всё надо тестировать в начале тестирования и не оставлять часть на конец.
5. Учти, что если плохо протестировать, то на старте опытно-промышленной эксплуатации можно утонуть в ошибках.
6. Учти, что тестирование нового релиза конфигурации нужно начинать как можно раньше. Но если тестирование пройдет без ошибок, то не нужно успокаиваться. Разработка не стоит на месте, среда работы конфигурации может меняться. Поэтому финальное тестирование проведи как можно ближе к обновлению рабочей базы на её актуальной копии.
7. Учти, что если в обновляемой конфигурации большое количество доработок, то, наверняка, есть доработки, про которые никто не знает подробностей. Важно выделить такие доработки для более тщательного тестирования. Организуй работу программиста и аналитика таким образом, чтобы программист обратил внимание аналитика на функциональность, которую нужно протестировать особо тщательно. Самый эффективный способ тестирования — аналитик и прикрепленный к нему программист.
8. Запланируй на этап тестирования в команду проекта аналитика для разбора сложных ошибок (например, не закрывается счет 20).

В качестве резюме дам главный совет. Для такого проекта все сложности спрогнозировать невозможно. А ошибки могут привести к неработоспособности критически важного функционала в рабочей базе после обновления и, следовательно, откату на старый релиз. Поэтому важно, чтобы в команде проекта были люди, которые могли брать на себя решения в ситуациях с высокой степенью неопределенности. И решения должны быть верными.