Будет ли ваша база данных готова, если скорость разработки увеличится в разы?

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

За последнее десятилетие ответом на вопрос “как мы можем двигаться быстрее?” было построение лучших конвейеров, инвестиции в CI/CD и сдвиг влево при тестировании. Эти инвестиции оправдали себя – код приложения движется с замечательной скоростью в зрелых инженерных организациях. Однако эти выгоды не были распределены равномерно по всему технологическому стеку. База данных часто рассматривалась как особый случай; защищенный актив, требующий другого стандарта ухода, более медленных процессов и ручного надзора. Были хорошие причины для развития этого шаблона, поскольку базы данных содержат данные, на которых работает бизнес, и ошибки могут быть катастрофическими. Хотя осторожность когда-то казалась разумной, стоимость этой осторожности изменилась. Увеличивая давление на администраторов баз данных и операционные команды, чтобы вносить изменения в базу данных с той же скоростью, с которой разработчики теперь могут писать код, несоответствие в стеке стало недостатком. Эти команды не могут поспевать, и изменения базы данных теперь убивают скоростное преимущество, обеспечиваемое инструментами, работающими с помощью ИИ. Решение одной проблемы – времени, необходимого для написания кода, – просто подчеркнуло следующую узость в процессе. Это системное мышление, ожившее, и полученная трение становится все более болезненным для предприятия.

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

Традиционная модель управления базой данных была разработана для мира квартальных релизов. Запросы на изменение, комитеты по утверждению, ручные циклы проверки, планы откатов, написанные до развертывания, которые происходили четыре раза в год. Ничего из этого не является по своей сути неправильным. Это был риск-менеджмент, который вырос, чтобы соответствовать времени, доступному в время между развертываниями. Проблема заключается в том, что каданс развертывания изменился, и для большинства организаций подход к управлению не поспевает. Командам приходится доставлять непрерывно, но они все еще направляют изменения базы данных через процессы, построенные для другой эпохи. Результатом не является безопасность. Результатом являются трение, обходные пути и растущий класс “небольших” изменений базы данных, которые обходят управление полностью, потому что формальный процесс слишком медленный, чтобы быть практичным.

Это то место, где живет реальный риск.

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

Ответ не в том, чтобы замедлить конвейер. Это переместить управление внутрь него.

Организации, которые решили эту проблему, не сделали этого, ослабив свои стандарты. Они сделали более трудную работу по созданию управления, достаточно быстрого, чтобы быть путем наименьшего сопротивления. Изменения схемы, находящиеся под контролем версий, автоматическое обнаружение дрейфа, детерминированные проверки политики, встроенные в конвейер CI/CD, а не применяемые как ворота в конце. Хотя инструменты, работающие с помощью ИИ, являются вероятностными – предлагая предложения на основе шаблонов – управление должно оставаться детерминированным, чтобы быть эффективным. Используя предсказуемые и повторяющиеся проверки, вы гарантируете, что каждое изменение является аудиторским и соответствует стандартам безопасности до того, как оно когда-либо достигнет производства. Утверждение все еще происходит. След аудита все еще существует. Но это происходит в том же потоке, что и все остальное, а не как отдельный, более медленный процесс, который находится вне его.

Это имеет значение по причине, выходящей за рамки производительности разработчика. Требования к соблюдению правил не становятся легче. Комбинация GDPR, DORA (Акт ЕС о цифровой операционной устойчивости) и растущего ряда отраслевых правил означает, что управление базой данных все больше является юридическим и нормативным вопросом, а не только операционным. Организации, которые не могут продемонстрировать отслеживаемую, аудиторскую историю изменения базы данных, подвергаются воздействию способов, которые становятся материальными. Аргумент в пользу встраивания управления в конвейер не только в том, что это делает доставку быстрее. Это то, что делает соблюдение правил отслеживаемым в масштабе.

ИИ усугубляет срочность.

Текущая волна инструментов, работающих с помощью ИИ, делает эту проблему более острой, а не менее острой. Когда разработчики могут генерировать и итерировать код приложения на порядок быстрее, чем раньше, база данных становится более очевидной узостью относительно всего, что вокруг нее. Но есть вторичный эффект, который менее широко обсуждается. Инструменты ИИ очень хорошо генерируют логические приложения. Они менее хорошо понимают долгосрочные последствия изменений схемы в сложной, живой производственной базе данных. Комбинация более быстрой скорости разработки приложения и предложений по изменению схемы ИИ без зрелого управления является именно тем давлением, которое производит инциденты. Скорость без структурных ограничений создает условия для ошибок, которые происходят быстрее.

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

Большинство корпоративных поместий делают это труднее, чем должно быть.

Существует усугубляющая реальность, которая сидит рядом с большинством этих наблюдений. Большинство корпоративных баз данных не являются зеленными. Они представляют собой десятилетия накопленных изменений схемы, работающих на нескольких платформах СУБД, некоторых на месте и некоторых в облаке, с различными степенями документации и племенного знания, распределенного по командам, которые перевернулись много раз. Разговор о модернизации часто предполагает чистую начальную точку, которой большинство организаций не имеют. Это то место, где проблема фактически наиболее острая и часто препятствует прогрессу. Будь то поддержка инноваций, очистка и миграция данных для ИИ или улучшение операционной устойчивости; все это сводится к одному и тому же. Вопрос не в том, как построить идеальную практику DevOps для базы данных на новой системе. Вопрос в том, как ввести осмысленное управление на сложном, наследственном поместье без остановки бизнеса, пока вы это делаете.

Постепенное, встроенное в конвейер управление является единственным практическим ответом на этот вопрос. Вам не нужно пере-платформить все поместье, прежде чем вы сможете улучшить свои практики управления изменениями. Современные инструменты, такие как Redgate Flyway, существуют, чтобы облегчить базу данных как узость и начать с изменений, которые делаются сегодня, в конвейерах, которые уже существуют, и построить оттуда.

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

Это проблема, которую стоит решить. И это решаемо.