Операционные данные — это то, что делает бизнес реальным. Заказ переходит из статуса «в ожидании» в «подтвержден». Распределяются запасы. Происходит движение денежных средств. Утверждается заявка. За каждым событием стоят данные, которые должны быть корректными, доступными в нужный момент, восстанавливаемыми в случае сбоя и обслуживаемыми с достаточной производительностью, чтобы окружающие системы могли выполнять свою работу.

Предприятия потратили десятилетия на то, чтобы научиться делать это хорошо. Зрелые базы данных обеспечивают транзакционную корректность. Кластеризация и репликация повышают доступность. Резервное копирование и восстановление защищают от сбоев.

Redgate’s 2026 survey обнаружили, что 84% организаций используют две или более платформы баз данных. Разные приложения появлялись в разное время. Приобретения привносили свои собственные системы. Каждая крупная инфраструктура баз данных кажется уникальной, и на практике, вероятно, так оно и есть. Но за этим разнообразием скрывается общая проблема, которую стоит четко обозначить: инфраструктура стала очень хорошо выполнять конфигурацию и гораздо хуже — непрерывно доказывать, что полученное состояние по-прежнему соответствует изначально заложенному в него замыслу.

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

Корректность конфигурации — это не корректность результата

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

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

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

Замысел принадлежит данным

Причина возникновения этого разрыва проще, чем кажется. Замысел закодирован не в том месте.

Группа защиты, отношение репликации, политика QoS или расписание резервного копирования — это способы удовлетворения требования в конкретный момент времени. Это не само требование. Когда реализация меняется, требование должно сохраняться независимо от нее. Если приложения, инфраструктура и потребители могут меняться, требование должно оставаться привязанным к тому, что эти системы в конечном итоге обслуживают: к данным.

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

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

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

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

Когда замысел находится не на своем месте

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

Рассмотрим два примера:

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

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

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

Рисунок 1: Влияние запроса на изменение.

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

Обязательство живет над отдельным объектом инфраструктуры, на нескольких уровнях стека. Возьмем онлайн-банковский сервис с целевым временем восстановления 30 минут. Это требование транслируется вниз через приложения, базы данных и уровень хранения. Каждый уровень обоснованно отвечает за часть ответа.

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

Учитывая замысел, касающийся данных, за которые я отвечаю, выполняет ли моя часть системы то, что от нее требуется?

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

Everpure снижает трение при изменениях для критически важных бизнес-приложений

В течение десятилетия Everpure поддерживает критически важные бизнес-приложения, поглощая изменения под рабочей нагрузкой, чтобы события в инфраструктуре не превращались автоматически в сбои в работе бизнеса. Лучшие изменения — это часто те, которые рабочая нагрузка даже не замечает.

Мы обеспечиваем запас производительности и емкости баз данных, чтобы их рост не превращался автоматически в проект по миграции. Мы уменьшаем объем и консолидируем данные, позволяя нескольким рабочим нагрузкам использовать общие ресурсы без создания новых изолированных хранилищ.
Мы делаем создание копий настолько быстрым и эффективным с точки зрения хранения, чтобы ваши команды разработки могли проводить тестирование в реальном масштабе без увеличения занимаемого хранилища при каждом запуске. Мы обеспечиваем восстановление данных, соответствующее их реальному текущему объему, а не тому, с которого они начинали. Сейчас это важнее, чем раньше. Согласно отчетам, 57% опрошенных организаций заявили, что их последний крупный сбой обошелся более чем в 100 000 долларов, а каждый пятый сообщил о сумме свыше 1 миллиона долларов. Непрерывность бизнес-процессов — это не второстепенное требование.
Мы обновляем базовую технологию без необходимости перемещения оперативных данных, поэтому событие жизненного цикла инфраструктуры не превращается автоматически в проект по базе данных. Мы предоставляем командам инструменты уровня всего парка систем для применения и поддержания единых политик во всем портфеле сред.
Когда те же оперативные данные становятся ценными для моделей мошенничества, прогнозов, аналитики, векторного поиска и ИИ-агентов, мы делаем их доступными для этих новых сценариев использования, не заставляя исходную базу данных напрямую обрабатывать каждый новый паттерн доступа. Databricks отмечает важное ограничение: CDC сам по себе может создавать дополнительную нагрузку на производственные базы данных, поэтому некоторые команды вместо этого используют рабочие процессы клонирования снимков.

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

Рисунок 2: Everpure отделяет изменения инфраструктуры от изменений в бизнесе.

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

От поглощения изменений к подтверждению результатов

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

Уровень персистентности, обслуживающий базу данных, должен:

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

Все это не является отказом от того, что персистентность делает уже сегодня. Это тот же архитектурный подход, примененный к реальным потребностям базы данных, а не только к настройкам ее базового хранилища.

Приоритет данных для оперативных баз данных

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

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

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

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

Рисунок 3: От инфраструктуры к данным.

Как только целевое состояние становится устойчивым и понятным для машины, реализация хранилища может постепенно исчезнуть из поля зрения владельца рабочей нагрузки. Могут появляться новые потребители, а инфраструктура может меняться без необходимости для владельца рабочей нагрузки перестраивать архитектуру вокруг примитивов хранения. Уровень персистентности может согласовывать эти изменения «под капотом» данных, непрерывно доказывая, что требования к ним по-прежнему выполняются.

Это направление движения, а не конечная точка. Именно это отличает инфраструктуру, которая просто выполняет то, о чем вы попросили, от инфраструктуры, которая постоянно доказывает, что запрошенное вами поведение продолжает реализовываться.

Что должно измениться?

Выберите одну критически важную оперативную базу данных. Не самую новую. Выберите ту, которая работает уже несколько лет и несколько раз менялась с момента запуска.

Задайте вопрос о том, что должно быть актуально для нее сегодня:

Ее RPO
Ее RTO
Ее диапазон производительности
Ее доступность
Период хранения ее данных
Ее требования к защите и отказоустойчивости
Где разрешено существование копий

Затем задайте более сложный вопрос.

Можете ли вы доказать прямо сейчас, что текущее состояние среды по-прежнему удовлетворяет каждому из этих требований?

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

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