“А вы точно DBA?” Что спросить у провайдера перед подключением Managed DBaaS

В крупных компаниях с развитой ИТ-инфраструктурой нередко есть отдельная роль DBA — администратора или архитектора баз данных. Таким компаниям бывает выгоднее держать базы данных у себя и администрировать ресурсы своими силами.  

В компаниях поменьше случается, что зона компетенций DBA остается “ничьей землей”: в лучшем случае эту роль могут отдать в нагрузку кому-то из смежных специалистов. В дальнейшем это грозит проблемами, если инфраструктура резко вырастет или усложнится. И тут как раз поможет внешний DBA: независимый консультант по базам данных или специалист в рамках облачного сервиса управляемых БД, если компании нужны еще и ресурсы в облаке. 

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

Например, нелишне выяснить, что именно специалисты понимают под HA и как ее организуют.
Например, нелишне выяснить, что именно специалисты понимают под HA и как ее организуют.

Когда поможет внешний DBA 

По нашему опыту, внешний аудит и сопровождение БД полезны для таких случаев: 

  1. Запланированная разовая или пиковая нагрузка. Бывает, что ресурсы БД нужны временно, под проект, или на период повышенной нагрузки сервиса. Например, у компании-ритейлера грядет “черная пятница” или планируется разовое мероприятие c большим количеством регистраций на сайте. 

    Если такая ситуация наблюдается один месяц из 12, нанимать еще одного DBA излишне. К тому же может оказаться, что для ограниченного по времени проекта нужны технологии, в которых у штатных специалистов меньше экспертизы. Например, основной штат специалистов использует Microsoft SQL, а для разового проекта нужны хорошие возможности полнотекстового поиска, как в Elasticsearch. 

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

  2. Стихийное развитие системы. Здорово, если рост нагрузки на базу удается спрогнозировать: тогда “запас прочности” можно предусмотреть в архитектуре заранее. Но в реальной жизни всплески нагрузки часто происходят внезапно, например: проект неожиданно выстреливает и привлекает в разы больше пользователей. 

    Бывает и так, что в изначальном проекте планировалась одна бизнес-логика, а потом базу данных стали использовать не совсем по назначению. Например, мы встречали кейсы, когда база данных Microsoft SQL применялась для обработки текстовых файлов. Систему разработали давно, поддерживали и развивали без привлечения DBA и в какой-то момент столкнулись с медленной работой, но не смогли локализовать причину без специалиста. В таких случаях внешний DBA не всегда сможет сам исправить бизнес-логику, но покажет проблемные зоны в архитектуре системы. 

  3. Соблюдение требований безопасности. Если служба ИБ приходит с особыми требованиями к базам данных, не каждая компания может реализовать их самостоятельно и быстро. 

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

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

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

    Также приоритизация проектов может быть инструментом удержания таких высококвалифицированных специалистов, которым неинтересно заниматься рутинной работой с базами данных: обновлением, настройкой бэкапов. В этом случае рутину тоже можно переложить на внешний сервис Managed DBaaS.   

  5. Не сформирован технологический стек решения. Когда компания собирается внедрять новый ИТ-продукт, она может не знать заранее его архитектурные особенности. Например, компания ищет CRM-систему и одновременно выбирает среди продуктов на основе реляционных баз данных и на основе NoSQL-хранилищ. Поддержка выбранного решения может стать проблемой, если в штате нет специалиста по конкретной базе данных. И здесь опять же могут помочь аутсорсеры. 

Как видим, во всех этих случаях с помощью внешнего DBA компания решает минимум одну из трех задач: 

  • усиление компетенций;

  • добавление дефицитных вычислительных ресурсов; 

  • обеспечение требований безопасности.

Если актуальна первая задача, достаточно привлечь независимого специалиста-аутсорсера. А вот вторую и третью задачи часто решает именно облачный провайдер: для поиска ресурсов независимый DBA может выступить только посредником. Качество ресурсов в облаке сильно зависит от уровня обслуживания, который гарантируется в SLA. Поэтому для оценки SLA и его вариантов важно понять, что обычно входит в зону компетенций DBA в сервисе управляемых баз данных.

Что делает DBA в рамках облачного managed-сервиса

Схематично поддержку баз данных в облаке можно разделить на такие сегменты:

Для каждого из уровней нужно обеспечить бесперебойное функционирование. Вот какие работы оно включает: 

  • мониторинг ключевых показателей, для каждого уровня своих;

  • регулярное обновление и поддержание актуального состояния элементов;

  • обеспечение высокой доступности и других метрик по SLA;

  • обеспечение информационной безопасности.

Пройдемся по уровням, начнем сверху.

Бизнес-логика. С зоной ответственности на самом верхнем уровне все более-менее понятно: бизнес-логика системы находится на стыке ИТ и бизнеса и требует глубокого знания процессов компании. Поэтому правильная реализация бизнес-логики — компетенция, скорее, бизнес-аналитика. От DBA чаще всего не требуют решения вопросов на этом уровне, хотя опытный специалист может подсказать, где именно искать проблемы. При этом реализацию бизнес-логики тоже можно аутсорсить, просто в рамках более комплексной услуги, чем Managed DBaaS. 

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

С ответственностью провайдера на уровне managed DBaaS иногда может возникнуть обратная ситуация: клиенту бывает сложно отказаться от обязательных услуг в рамках сервиса. Нам рассказывали историю, как компания столкнулась с проблемами медленной работы базы после очередного обновления СУБД в облачном сервисе. При этом откатиться назад и исключить клиента из плана обновлений не удалось, так как все обновления провайдер делал централизованно.

База данных. А вот с обслуживанием самих баз данных все не так просто: разные провайдеры услуги DBaaS могут включать в администрирование разное количество работ на уровне БД. Какие это могут быть работы:

  • резервное копирование БД;

  • постановка на мониторинг и настройка уведомлений клиенту по выбранным событиям;

  • активный мониторинг ключевых метрик провайдером и реагирование на инциденты в соответствии с приоритетами;

  • настройка индивидуального расписания резервного копирования;

  • настройка плана послеаварийного восстановления (DRP).

Как видим, мониторинг базы данных может быть устроен по-разному. При анализе SLA важно понимать, за какие именно метрики отвечает провайдер, а за какие — сам клиент. Вот основные группы показателей (для разных баз конкретные метрики отличаются): 

  • доступность: в общем случае в SLA она указывается в процентах в месяц (например, 99,98%). Но помимо этого есть частные метрики, которые влияют на доступность, например, метрики работы службы кластеров HA;   

  • производительность и все что на нее влияет, например: как часто выполняются запросы, по которым не хватает индексов, или задержки при обращении к файлам данных на дисках, размер журнала транзакций и процент его заполненности (для Microsoft SQL); 

  • безопасность: например, результаты проверки паролей администраторов по словарю;

  • конфигурация: как именно настроена база данных.

При минимальном варианте сопровождения БД контролируются метрики только из первой группы. При этом провайдер реагирует на самые критичные изменения, из-за которых может нарушиться показатель доступности в SLA. А изменения остальных метрик просто отправляет клиенту уведомлением. Рассчитывать на контроль и корректировку метрик из всех четырех групп можно, только если это входит в условия обслуживания (у многих провайдеров это уже premium-уровень). 

Итак, первым делом в соглашении по сервису важно проверить: 

  • за какие именно метрики отвечает провайдер;

  • какую ответственность несет за невыполнение;

  • как именно реагирует на разные нештатные ситуации: что исправляет сам, кого и каким образом уведомляет, в какой срок.

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

Как проверить сервис Managed DBaaS 

  1. Проверка компетенций. Чаще всего клиенты спрашивают у DBA портфолио кейсов по выбранной базе данных. Но важно проверять не только опыт в продукте, но и опыт решения конкретных задач с выбранной БД. Вот на что советуем обратить внимание:

    • работа с базами данных определенного объема и под определенной нагрузкой. Объем и нагрузка напрямую влияют на подход к администрированию. Например, объем БД в несколько терабайт накладывает ограничения на резервное копирование и восстановление базы. Если у DBA мало опыта с такими БД и при этом он привык решать все проблемы перезагрузкой, то на больших объемах есть риск столкнуться с неожиданно длительными простоями.  

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

      Скажем, если компании нужно восстановить базы после массового сбоя на уровне всей площадки, то DBA должен владеть инструментами для обеспечения нужного RPO и RTO. А если нужно обеспечить высокую доступность реляционных баз данных, то лучше сделать это на уровне СУБД. В этом сценарии приветствуется хорошее знание ее ролевой модели. Правильная настройка ролевой модели помогает распределить транзакции перед переключением на реплику БД: какие-то транзакции закоммитить, какие-то откатить.    

    • плюсом будет наличие профильных сертификатов у специалистов.

  2. Проверка ресурсов. Тут помогут тесты, которые можно провести в пробной базе сервис-провайдера:

    • превышение порога допустимых значений — за какое время отрабатывает тот или иной запрос к базе;

    • проверка отказоустойчивости;

    • тесты производительности: TPC-H, TPC-B, TPC-C;

    • тест Гилева, если это 1С.

    Уровень подключения DBA к проверке ресурсов будет сильно отличаться для двух групп клиентов:

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

    • компаний, которые решают новую задачу при обращении к DBaaS. Здесь важен опыт DBA в решении аналогичных задач и его компетенции архитектора. Если клиент — это стартап и прогнозировать проблемы сложно, то компании все равно потребуется указать планируемую загрузку. Звучать это может так: на начальном этапе планируем не больше 1000 подключений в секунду, через полгода ожидаем не больше 10 000 подключений в секунду.  

  3. Проверка безопасности. Здесь для проверки будет несколько направлений. 

    Во-первых, удостовериться в защищенности данных можно по формальным и неформальным признакам:  

    • провайдеров формально можно проверить по сертификатам безопасности: смотрим сертификаты соответствия системы управления ИБ требованиям ISO/IEC 27001:2013, результаты аудитов по PCI DSS, аттестаты по 152-ФЗ для хранения персональных данных и так далее. Также на формальном уровне клиента защищают соглашения о неразглашении (NDA). Здесь стоит внимательно проверить, какую именно ответственность и за что несет провайдер по договору.  

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

    Во-вторых, клиенту стоит интересоваться используемыми в облачном сервисе инструментами ИБ в зависимости от актуальной модели угроз:

    • внешние угрозы безопасности — это вредоносное ПО, боты, DDoS-атаки, направленные атаки. Здесь стоит обратить внимание на наличие в рамках DBaaS решений анти-DDoS, NGFW, IPS. 

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

      1) Модель шифрования данных на стороне SQL — all is encrypted. У компании-клиента хранится сертификат, к которому не имеет доступа даже провайдер. Приложение осуществляет запросы к базе с помощью этого сертификата. Даже если кто-то на стороне сервис-провайдера попытается скопировать данные из базы, то зашифрованные поля все равно будут недоступны. 

      2) TDE-шифрование для бэкапов, которые хранятся отдельно от базы: восстановить по ним базу не получится, так как сертификаты хранятся отдельно от бэкапов. 

Итоговый чек-лист проверки Managed DBaaS

  1. Ответственность DBA в договоре подряда или соглашении об уровне обслуживания (SLA): за что именно отвечает, что произойдет в случае нарушения.

  2. Наличие в портфолио кейсов с базами нужного объема и под выбранной нагрузкой.

  3. Опыт решения задач по обеспечению высокой доступности или DR — в зависимости от того, что актуальнее компании.

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

  5. Наличие сертификатов безопасности для облака.

  6. Уровень ответственности в NDA, если нужно защитить конфиденциальную информацию.

  7. Наличие инструментов логирования и контроля привилегированных пользователей.

  8. Наличие инструментов ограничения прав доступа к конфиденциальной информации.

Читайте так же:

  • Роскосмос составил план полётов к МКС на 2022 год: два «Союза», три «Прогресса»Роскосмос составил план полётов к МКС на 2022 год: два «Союза», три «Прогресса» Роскосмос передал изданию «РИА Новости» программу полётов к МКС на 2022 год и список запусков до конца этого года. По программе в марте, феврале, июне, сентябре и октябре запланированы пять запусков — два «Союза» и три «Прогресса».Пуск ракеты-носителя «Союз-2.1б» в феврале 2021 […]
  • Учёные придумали простой способ определять поддельную колбасуУчёные придумали простой способ определять поддельную колбасу Учёные ФИЦ Биотехнологии РАН предложили новый экспресс-тест, который поможет выявлять фальсификат в мясном изделии. Уникальность подхода состоит в том, что он не требует отправки продукции в лабораторию и использования дорогостоящего оборудования.Часто дорогие виды мяса, например, […]
  • Google: что лучше – абсолютные или относительные URLGoogle: что лучше – абсолютные или относительные URL В новом эпизоде #AskGooglebot сотрудник Google Джон Мюллер объяснил разницу между абсолютными и относительными URL, а также рассказал, есть ли у поисковой системы предпочтения касательно формата – с точки зрения сканирования и индексирования. 🔗⚡️ Absolute or […]
  • По пути Xiaomi Mi Mix Fold. Huawei P50 Pro+ тоже получит объектив-«хрусталик»По пути Xiaomi Mi Mix Fold. Huawei P50 Pro+ тоже получит объектив-«хрусталик» Больше году тому назад инсайдеры говорили о том. Что в одной из моделей новой флагманской линейки Huawei (на тот момент это была P40) будет использоваться так называемый «жидкий объектив». Однако этого не случилось. Вероятно, компании просто потребовалось время на доработку технологии. И […]