“А вы точно 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-сервиса

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

image-loader.svg

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

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

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

  • обеспечение высокой доступности и других метрик по 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. Наличие инструментов ограничения прав доступа к конфиденциальной информации.

© Habrahabr.ru