Простая установка обновлений для сложных баз данных: опыт УБРиР

Очень удобно, когда обновление ставится одним нажатием на кнопку, как на смартфоне. Однако добиться такого простого процесса в мире больших корпоративных баз данных мешает ряд факторов:

Расскажем, как инженер из команды Devops и инженер из команды Oracle в УБРиР постарались выстроить процесс подготовки и доставки обновлений баз данных Oracle (CI/CD) максимально прозрачно и просто для разработчиков, проверяющих (reviewers) и тех, кто выполняет установку обновлений на прод.

Как в большинстве крупных организаций, которые работают десятки лет, в УБРиР постепенно новые технические решения заменяют устаревшие. Но не всё и не моментально выводится из эксплуатации. Решения о запуске новых технических решений всегда принимаются с учетом интересов бизнеса. Поэтому остаются системы, которые в данный момент переводить на новые технологии экономически не оправдано. Из-за этого копится зоопарк различных версий СУБД, платформы и тому подобное

В какой-то момент мы решили проанализировать наш процесс подготовки и доставки обновлений для баз Oracle и своими силами улучшить его для всех участников. Было несколько причин, подтверждающих, что изменения в процессе необходимы:

Неавтоматизированные действия в процессе установки значительно ограничивали количество обновлений, которые мы успевали обработать за технологическое окно. Также возникали сложности при отмене обновлений, потому что без полной автоматизации сложно в ограниченные сроки, в правильном порядке выполнить отмену обновления, особенно когда обновление связано сразу с несколькими БД.

До запуска нового CI/CD конвейера не было прозрачной интеграции системы контроля версий с трекером задач. Это приводило к тому, что сложно было связать изменения в объектах БД с задачами, к которым эти изменения относятся. Отсутствие единого канала коммуникаций приводило к тому, что разработчик мог пропустить важную информацию по обновлению, и из-за этого ответственный за установку мог отменить обновление.

На первых этапах проекта была разработана и описана концепция работы нового конвейера для Oracle обновлений. В это время мы выделили особенности, которые исторически проявляются в Oracle базах банка, например, наличие связанности нескольких баз в старых подсистемах. Кроме этого, мы проанализировали опыт других компаний и выбрали стэк технологий для нашего решения. На чем мы остановились?

Остался ключевой компонент для работы всего конвейера - приложение для применения или отмены обновлений и интеграции перечисленных платформ. Его мы решили сделать сами на python.

При написании python автоматизации возникли некоторые проблемы.

Подробнее остановимся на python-модуле для применения обновлений. Системы банка должны быть доступны в режиме 24/7. Обновления для баз данных напрямую влияют на непрерывность работы систем банка. Поэтому очень важно обеспечить несколько ключевых возможностей:

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

Все этапы и особенности работы были подробно описаны в confluence. В результате в confluence было добавлено больше 30 статей. Из них были выделены 2-3 с информацией, необходимой при работе с каждым обновлением. С помощью подробного описания удалось добиться того, что новые разработчики могут легко и быстро познакомиться с процессами подготовки, оформления и установки обновления.

В ходе разработки и запуска нам пришлось решать ряд технических и организационных проблем. На первых этапах было непросто продумать процесс работы с репозиторием так, чтобы он был удобным для всех участников. На этапе разработки столкнулись с большим количеством технических особенностей oracle и взаимодействия с bitbucket через API. На этапе внедрения было необходимо провести работы так, чтобы не остановить установки обновлений на прод.

На сегодня обновление всех важных Oracle БД УБРиР было переведено на описанный подход. Наши ожидания полностью оправдались:

В технологическое окно мы стали успевать ставить гораздо больше обновлений. Поэтому смогли полностью отказаться от ограничения количества обновлений, запланированных на один день. Обработка практически всех обновлений теперь происходит автоматически. Участие человека требуется в очень редких случаях. Стало очень просто находить ответ на вопрос “Для чего был добавлен этот код?”.

Интерфейс получился достаточно простым. Для запуска установки обновления действительно необходимо только указать название обновления и нажать одну кнопку.

Основное python приложение для установки oracle обновлений использует bitbucket api, и изучив его основательно, мы поняли, что мы можем еще больше улучшить work flow процесса установки. На разных этапах работы конвейера мы смогли добавить множество автоматизаций, чтобы снизить затраты времени на поддержку репозитория и подготовку обновлений. Это было необходимо для:

После нескольких итераций установок обновлений мы начали дополнять функционал автоматизации и добавили сюда же:

Как только CI CD конвейер начал использоваться для всех критических Oracle БД УБРиР, сразу появилось желание включить в него и другие этапы, которые раньше не были автоматизированы. В первую очередь, в конвейер была добавлена проверка необходимости передачи обновления (ЦИБ). Проверка ЦИБ стала одним из этапов code review.

Кроме того, появилась возможность автоматизировать процесс выбора проверяющих для code review. Теперь проверяющие для обновлений автоматически выбираются так, чтобы code review был максимально распределенным между разработчиками, а также помогал развиваться и проверяющему, и автору обновления.

В УБРиР мы постоянно изучаем новые возможности для развития наших систем. В процессе работы над CI CD конвейером были ограничения, из-за которых не все известные технические решения были использованы. Например, в бэклоге осталось применение технологии edition-based redefinition. Развитие нашего CI CD конвейера будет продолжаться, поэтому техническое решение, про которое мы рассказали в статье, наверняка еще не раз будет доработано с учетом новых возможностей.