В крупных компаниях с развитой ИТ-инфраструктурой нередко есть отдельная роль DBA — администратора или архитектора баз данных. Таким компаниям бывает выгоднее держать базы данных у себя и администрировать ресурсы своими силами.
В компаниях поменьше случается, что зона компетенций DBA остается “ничьей землей”: в лучшем случае эту роль могут отдать в нагрузку кому-то из смежных специалистов. В дальнейшем это грозит проблемами, если инфраструктура резко вырастет или усложнится. И тут как раз поможет внешний DBA: независимый консультант по базам данных или специалист в рамках облачного сервиса управляемых БД, если компании нужны еще и ресурсы в облаке.
В этой статье проанализируем, какие задачи компании решают при обращении к сервису Managed DBaaS и какие нюансы возникают при аутсорсинге обслуживания БД. В конце предложим чек-лист, по которому можно оценить такой сервис и его специалистов.
Когда поможет внешний DBA
По нашему опыту, внешний аудит и сопровождение БД полезны для таких случаев:
Запланированная разовая или пиковая нагрузка. Бывает, что ресурсы БД нужны временно, под проект, или на период повышенной нагрузки сервиса. Например, у компании-ритейлера грядет “черная пятница” или планируется разовое мероприятие c большим количеством регистраций на сайте.
Если такая ситуация наблюдается один месяц из 12, нанимать еще одного DBA излишне. К тому же может оказаться, что для ограниченного по времени проекта нужны технологии, в которых у штатных специалистов меньше экспертизы. Например, основной штат специалистов использует Microsoft SQL, а для разового проекта нужны хорошие возможности полнотекстового поиска, как в Elasticsearch.
В этой ситуации внешний DBA подберет инструменты под конкретный проект, возьмет на себя сопровождение дополнительной базы данных, поможет найти узкие места в процессе работы. К его помощи можно прибегать по запросу, только когда дополнительная нагрузка появляется.
Стихийное развитие системы. Здорово, если рост нагрузки на базу удается спрогнозировать: тогда “запас прочности” можно предусмотреть в архитектуре заранее. Но в реальной жизни всплески нагрузки часто происходят внезапно, например: проект неожиданно выстреливает и привлекает в разы больше пользователей.
Бывает и так, что в изначальном проекте планировалась одна бизнес-логика, а потом базу данных стали использовать не совсем по назначению. Например, мы встречали кейсы, когда база данных Microsoft SQL применялась для обработки текстовых файлов. Систему разработали давно, поддерживали и развивали без привлечения DBA и в какой-то момент столкнулись с медленной работой, но не смогли локализовать причину без специалиста. В таких случаях внешний DBA не всегда сможет сам исправить бизнес-логику, но покажет проблемные зоны в архитектуре системы.
Соблюдение требований безопасности. Если служба ИБ приходит с особыми требованиями к базам данных, не каждая компания может реализовать их самостоятельно и быстро.
Яркий пример — хранение персональных данных и соблюдение 152-ФЗ. Когда компания становится оператором персданных, нужно собрать внушительный пакет документов и подобрать соответствующие задачам средства защиты (мы уже писали об этом тут). Облачный провайдер помогает ускорить процесс и обеспечивает соответствие 152-ФЗ на уровне своей инфраструктуры: у него уже есть аттестованные сегменты облака для таких задач. Компании-клиенту остается соблюсти требования закона на уровне базы данных и приложения (некоторые провайдеры могут помочь и с этим).
Менее очевидный пример — необходимость проводить аудиты ИБ для баз с ценной информацией. Допустим, служба ИБ захотела следить за всеми операциями в CRM-системе и поручила разработчикам создать для этого отдельные таблицы аудита. Если решать эту задачу без глубоких знаний БД, можно легко замедлить работу всей базы. В такой ситуации грамотный DBA также поможет найти баланс между производительностью и безопасностью.
Рутина или внутренние проекты. Даже если в компании есть свои DBA, их рабочего времени не всегда хватает на все задачи — приходится расставлять приоритеты. На последнем месте в списке часто оказываются внутренние проекты. Например, это могут быть сервисы для сотрудников, которые сложно оценить в терминах экономической эффективности для бизнеса, в отличие от приложений для клиентов. В этом случае компании может быть выгоднее привлекать собственных высококвалифицированных DBA на внешние проекты, а внутренние отдать аутсорсерам.
Также приоритизация проектов может быть инструментом удержания таких высококвалифицированных специалистов, которым неинтересно заниматься рутинной работой с базами данных: обновлением, настройкой бэкапов. В этом случае рутину тоже можно переложить на внешний сервис Managed DBaaS.
Не сформирован технологический стек решения. Когда компания собирается внедрять новый ИТ-продукт, она может не знать заранее его архитектурные особенности. Например, компания ищет 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
Проверка компетенций. Чаще всего клиенты спрашивают у DBA портфолио кейсов по выбранной базе данных. Но важно проверять не только опыт в продукте, но и опыт решения конкретных задач с выбранной БД. Вот на что советуем обратить внимание:
работа с базами данных определенного объема и под определенной нагрузкой. Объем и нагрузка напрямую влияют на подход к администрированию. Например, объем БД в несколько терабайт накладывает ограничения на резервное копирование и восстановление базы. Если у DBA мало опыта с такими БД и при этом он привык решать все проблемы перезагрузкой, то на больших объемах есть риск столкнуться с неожиданно длительными простоями.
навыки работы с кластерными решениями и/или DRP. Здесь важно знать, насколько хорошо DBA понимает разницу между обеспечением высокой доступности и катастрофоустойчивостью и знаком ли он с инструментами, которые актуальнее для клиента.
Скажем, если компании нужно восстановить базы после массового сбоя на уровне всей площадки, то DBA должен владеть инструментами для обеспечения нужного RPO и RTO. А если нужно обеспечить высокую доступность реляционных баз данных, то лучше сделать это на уровне СУБД. В этом сценарии приветствуется хорошее знание ее ролевой модели. Правильная настройка ролевой модели помогает распределить транзакции перед переключением на реплику БД: какие-то транзакции закоммитить, какие-то откатить.
плюсом будет наличие профильных сертификатов у специалистов.
Проверка ресурсов. Тут помогут тесты, которые можно провести в пробной базе сервис-провайдера:
превышение порога допустимых значений — за какое время отрабатывает тот или иной запрос к базе;
проверка отказоустойчивости;
тесты производительности: TPC-H, TPC-B, TPC-C;
тест Гилева, если это 1С.
Уровень подключения DBA к проверке ресурсов будет сильно отличаться для двух групп клиентов:
опытных компаний, которые отдают аутсорсеру знакомую задачу. Здесь клиенту уже известны метрики, к которым хочется стремиться, и есть возможность провести аналогичные тесты на своих ресурсах. От DBA требуется лишь слегка скорректировать задачи тестирования при необходимости.
компаний, которые решают новую задачу при обращении к DBaaS. Здесь важен опыт DBA в решении аналогичных задач и его компетенции архитектора. Если клиент — это стартап и прогнозировать проблемы сложно, то компании все равно потребуется указать планируемую загрузку. Звучать это может так: на начальном этапе планируем не больше 1000 подключений в секунду, через полгода ожидаем не больше 10 000 подключений в секунду.
Проверка безопасности. Здесь для проверки будет несколько направлений.
Во-первых, удостовериться в защищенности данных можно по формальным и неформальным признакам:
провайдеров формально можно проверить по сертификатам безопасности: смотрим сертификаты соответствия системы управления ИБ требованиям ISO/IEC 27001:2013, результаты аудитов по PCI DSS, аттестаты по 152-ФЗ для хранения персональных данных и так далее. Также на формальном уровне клиента защищают соглашения о неразглашении (NDA). Здесь стоит внимательно проверить, какую именно ответственность и за что несет провайдер по договору.
неформально провайдера и отдельного специалиста можно проверить по используемым инструментам безопасности. Например, что применяется для логирования, мониторинга событий, какая информация будет предоставлена клиенту в случае инцидента. Как минимум, у клиента должна быть возможность просмотреть логи на разных уровнях системы. Как максимум, это могут быть записи сессий привилегированных пользователей с помощью систем класса PAM или других подобных решений.
Во-вторых, клиенту стоит интересоваться используемыми в облачном сервисе инструментами ИБ в зависимости от актуальной модели угроз:
внешние угрозы безопасности — это вредоносное ПО, боты, DDoS-атаки, направленные атаки. Здесь стоит обратить внимание на наличие в рамках DBaaS решений анти-DDoS, NGFW, IPS.
внутренние угрозы безопасности — это риски утечки данных, несанкционированного доступа, превышения полномочий пользователями. Помимо логирования и мониторинга здесь важно обратить внимание на возможности настройки прав доступа и на инструменты защиты от специалистов с повышенными правами. Какие схемы защиты тут могут быть:
1) Модель шифрования данных на стороне SQL — all is encrypted. У компании-клиента хранится сертификат, к которому не имеет доступа даже провайдер. Приложение осуществляет запросы к базе с помощью этого сертификата. Даже если кто-то на стороне сервис-провайдера попытается скопировать данные из базы, то зашифрованные поля все равно будут недоступны.
2) TDE-шифрование для бэкапов, которые хранятся отдельно от базы: восстановить по ним базу не получится, так как сертификаты хранятся отдельно от бэкапов.
Итоговый чек-лист проверки Managed DBaaS
Ответственность DBA в договоре подряда или соглашении об уровне обслуживания (SLA): за что именно отвечает, что произойдет в случае нарушения.
Наличие в портфолио кейсов с базами нужного объема и под выбранной нагрузкой.
Опыт решения задач по обеспечению высокой доступности или DR — в зависимости от того, что актуальнее компании.
Возможность проведения тестов в облаке, если помимо аудита и сопровождения базы клиент арендует ресурсы.
Наличие сертификатов безопасности для облака.
Уровень ответственности в NDA, если нужно защитить конфиденциальную информацию.
Наличие инструментов логирования и контроля привилегированных пользователей.
Наличие инструментов ограничения прав доступа к конфиденциальной информации.
