Настал ли конец пути для администратора баз данных? И ваша мечта о спокойном существовании в привычной роли сникла под натиском стремительных изменений в сфере администрирования?

Что если аналитик компании Cisco был прав, и 127 новых устройств подключаются к Интернету каждую секунду (https://www.politico.com/agenda/story/2015/06/internet-of-things-growth-challenges-000098)? Это же 328 млн устройств в месяц! Одна мысль о том, что потребуется для контроля и защиты новых типов данных, вынимает из администратора душу.

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

Конечно, обладатель сертификатов Oracle и SQL Server никогда не останется без работы. Но прочитав несколько статей, вы обнаруживаете, что такие поисковые механизмы, как Elasticsearch и Splunk, и новые платформы вроде MongoDB и PostgreSQL уже завоевывают мир.

«Да, — думаете вы. — Вот где открываются перспективы».

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

  • Устранить неполадки, о которых сообщают пользователи.
  • Найти и устранить неполадки, прежде чем о них сообщат пользователи.
  • Повторить перечисленное выше.

Вы занимались этим от сотворения мира. Неудивительно, что вы чувствуете себя зомби.

В этой ситуации мы решили написать статью, которая помогла бы вам преодолеть стадию зомби в администрировании баз данных. Мы составили настоящее руководство по выживанию в безумном мире баз данных, в основу которого легла веб-трансляция, проведенная нами вместе с Питером О’Коннеллом, «Конец пути для администратора баз данных или подготовка к будущему?» (MSSQLTips, April 2018, https://www.quest.com/webcast-ondemand/is-the-dba-dead-or-alive-and-preparing-for-the-future8131529/).

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

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

Тенденция 1. Вчера администратор базы данных, сегодня — инженер по разработке и эксплуатации (DevOps)

Не так давно у нас провели реорганизацию, и когда было составлено новое штатное расписание, угадайте, что произошло? Наименование моей должности изменилось с администратора базы данных на инженера по разработке и эксплуатации (DevOps). Изменились ли мои обязанности? Очень мало. Большинство выполняемых мною задач не претерпели никаких изменений. Но мое рабочее место стало теперь нулевой отметкой для DevOps, и это первая тенденция, которую я хочу подчеркнуть.

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

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

Путь разработчика

Успех разработчика определяется тем, как быстро и надежно удается внедрить изменения в производство. Его задача — как можно быстрее подготовить программный код и поддерживать неизменный поток усовершенствований. Как инженеры DevOps, мы должны мыслить «непрерывно»: непрерывная разработка, непрерывная интеграция, непрерывное развертывание.

Для приложений такой подход вполне хорош. Хоть он и непрерывен, но последователен, и в процессе переноса в производство вы располагаете относительно стабильными компонентами. Программный код приложения выглядит как коробки на сборочном конвейере (см. рисунок 1).

 

Последовательность разработки
Рисунок 1. Последовательность разработки

 

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

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

Путь инженера по эксплуатации

Позиция инженера по операциям иная. Его задача — обеспечить исправное функционирование систем без постоянного присмотра со стороны персонала. Быстрые и непрерывные изменения не вызывают энтузиазма среди сотрудников. Задача Ops — обеспечить стабильность с использованием диагностики, настроек и администрирования. Единственная непрерывная функция — мониторинг.

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

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

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

DevOps: непрерывная доставка, непрерывная интеграция, непрерывное развертывание

В значительной мере деятельность DevOps характеризует девиз: «Ошибайтесь часто, ошибайтесь быстро». Вносите малые, инкрементные изменения и внедряйте их в производство. Если возникают неполадки или изменения не удовлетворяют клиентов, быстро выполните отмену, внесите исправления и повторите. Как показано на рисунке 2, изменения и усовершенствования непрерывны; они не ограничиваются одним лишь этапом тестирования.

 

Цикл DevOps
Рисунок 2. Цикл DevOps

 

На противоположном краю от непрерывной доставки — непрерывный мониторинг, который является специализацией администраторов баз данных. Поддерживаем ли мы те же стандарты производительности? Все ли функционирует, как задумано? Когда возникает неполадка, насколько быстро удается ее устранить? Успеваем ли мы приспосабливаться к меняющимся сценариям использования приложений? Можем ли мы сопоставить изменение, обнаруженное в производственной сфере, с каким-либо изменением схемы?

Цикл неизбежно возвращается в область разработки, вызывая изменения на этапах проектирования и сборки.

Что значит быть инженером DevOps

По всем перечисленным выше причинам администраторам баз данных принадлежит большая роль в согласовании интересов Dev и Ops. По большому счету, перед администраторами баз данных открывается перспектива вырасти и взять на себя роль инженеров DevOps.

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

Издание DBTA провело опрос специалистов по разработке и развертыванию приложений и ИТ-операциям относительно DevOps (https://www.quest.com/whitepaper/the-current-state-and-adoption-of-devops8116848/). Респондентам был задан вопрос о наиболее сложных моментах интеграции изменений баз данных для DevOps.

Как видно из рисунка 3, автоматизированное регрессионное тестирование — непростая задача; почти половина из нас пытается освоить его эффективное применение.

 

Трудности интеграции изменений баз данных в процесс DevOps
Рисунок 3. Трудности интеграции изменений баз данных в процесс DevOps

 

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

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

Словом, ошибайтесь часто, ошибайтесь быстро и непрерывно совершенствуйтесь.

Тенденция 2. Рост популярности многоплатформенных сред

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

И они не будут ждать, пока вы оживете.

Ландшафт баз данных

Старые, испытанные корпоративные продукты, такие как Oracle и SQL Server, по-прежнему широко используются, и тому, кто их знает, безработица не грозит (рисунок 4). Но кто мог предвидеть такую жизнеспособность MySQL? Почему вы не изучали его долгими вечерами, пока была возможность, вместо того чтобы ночи напролет играть в Minecraft? А теперь вы заглядываете в рейтинги DB-Engines или объявления о вакансиях (конечно, совершенно случайно) и обнаруживаете, что мир баз данных наполнен такими категориями, как хранилища с широким столбцом, поисковые системы, хранилища типа «ключ-значение» (key-value store), системы управления графовыми базами данных и хранилища документов.

 

Востребованы разнообразные платформы баз данных, в том числе Oracle, SQL Server, SAP ASE, DB2, PostgreSQL, MySQL, MongoDB и Cassandra
Рисунок 4. Востребованы разнообразные платформы баз данных, в том числе Oracle, SQL Server, SAP ASE, DB2, PostgreSQL, MySQL, MongoDB и Cassandra

 

В компании Quest многоплатформенности уделяется особое внимание. Мы строим приложение SaaS с использованием базы данных Azure SQL, табличного хранилища, Redis и Document DB. Затем мы планируем перенести некоторые из них в Azure Cosmos DB и задействовать REST API. Выбор технологии зависит от таких факторов, как решаемые задачи, согласованность данных и уровень производительности, необходимый пользователям.

Почему важна многоплатформенность? Потому что одинаковые базы данных больше не удовлетворяют всех пользователей. Oracle и SQL Server по-прежнему популярны для OLTP, планирования ресурсов предприятия (ERP), управления отношениями с клиентами (CRM), хранилищ данных и интерактивных рейтингов. Для веб-приложений востребованы MySQL, MongoDB и Cassandra. Для распределенных, многомодельных баз данных, охватывающих много регионов и их особые нормативы, относящиеся к данным, обратите внимание на Cosmos DB компании Microsoft. Как показано на рисунке 5, находят применение все типы баз данных. А по мере того как число платформ увеличивается, управление ими возлагается на администраторов баз данных. Те же администраторы, кому в прошлом приходилось управлять лишь реляционными базами данных, теперь должны проявлять гибкость и осваивать другие базы данных. Так что отложите геймпад. Вам есть чем заняться по вечерам.

 

Рейтинг баз данных от DB-Engines.com
Рисунок 5. Рейтинг баз данных от DB-Engines.com

 

Несколько платформ: сколько и почему?

Без всякой просьбы с вашей стороны компания направляет вас по пути обслуживания большего количества категорий продуктов и платформ (не говоря уже о числе экземпляров в каждом случае). В другом опросе, проведенном DBTA, около 50% респондентов заявили, что их администраторы баз данных отвечают за систему управления базами данных от двух различных поставщиков, а 26% сообщили, что администраторы баз данных управляют платформами от трех-пяти поставщиков.

Это ответы на вопрос «сколько». Другой вопрос, ответы на который представлены на рисунке 6, — «почему»: что заставляет компании использовать несколько платформ баз данных?

 

Причины для использования нескольких платформ
Рисунок 6. Причины для использования нескольких платформ

 

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

Это означает, что для сохранения своих позиций на рынке труда администраторам баз данных необходимо отслеживать, как выполняются бизнес-задачи, и контролировать соответствие производительности баз данных рабочим нагрузкам, нуждам приложений и групп пользователей (https://www.quest.com/whitepaper/dbas-face-new-challenges-trend-in-database-administration8130482/).

Открытые базы данных: бесплатные, в некотором смысле

В любом разговоре о многоплатформенных базах данных быстро всплывает тема открытого программного обеспечения. Специалисты компании Gartner считают, что к 2022 году более 70% новых собственных приложений будут развернуты на открытых системах управления базами данных, а 50% существующих экземпляров коммерческих реляционных СУБД будут находиться в процессе преобразования. Это значительный импульс для развития открытого программного обеспечения (рисунок 7).

 

Преимущества открытых систем управления базами данных
Рисунок 7. Преимущества открытых систем управления базами данных

 

Иногда дело действительно в деньгах. Компании, которые использовали такие базы данных, как Oracle и SQL Server, начали применять базы данных c открытым исходным кодом, чтобы снизить затраты на лицензирование. Новые компании и молодые администраторы баз данных в первую очередь обращаются к открытым базам данных, таким как MySQL, PostgreSQL и MongoDB. Они никогда не работали с традиционными базами данных и даже никогда не задумывались об этом. В том же исследовании Gartner участники оценивали размер экономии в результате применения открытого программного обеспечения «до 80% стоимости программного обеспечения СУБД» (https://www.gartner.com/doc/3863764/state-opensource-dbms-market-).

У открытого программного обеспечения много преимуществ, в частности оно бесплатно. В некотором смысле (не как бесплатное пиво).

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

Или, как в случае с MySQL (продукт Oracle), вы можете бесплатно использовать Community Edition, но для версий Standard Edition и Enterprise Edition необходимо приобрести лицензию.

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

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

Тенденция 3. «Облако» и база данных как услуга: ваш путь к влиянию

Третья тенденция, оказывающая влияние на администраторов баз данных, — «облачные вычисления», особенно с учетом эволюции базы данных как услуги.

Как отмечалось выше относительно традиционных баз данных, локальным развертываниям не грозит исчезновение; по прогнозам компании IDC, около 80% дохода от реляционных СУБД в 2020 году будет поступать от локальных баз данных. Но IDC также прогнозирует, что оставшиеся 20% доходов будут поступать от общедоступного «облака», и рост в этом секторе рынка составит 41% в год (https://www.idc.com/getdoc.jsp? containerId=US42750117). Это очень весомый результат для «облака».

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

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

Верный путь в «облако»

«Облако» — очевидный выбор. Однако, чтобы прийти к нему, необходимо помочь вашей компании обойти ряд сомнительных вариантов.

Частное, общедоступное или гибридное? Какая модель обеспечивает оптимальный баланс между доступностью, безопасностью и стоимостью? Соответствует ли общедоступное «облако» всем требованиям вашей компании по безопасности? Если выбрать гибридный вариант, какие базы данных будут относиться к общедоступному сегменту, а какие к частному?

База данных как услуга (DBaaS) или инфраструктура как услуга (IaaS)? Большинство поставщиков баз данных как услуги выполняют обновления, резервное копирование, мониторинг, аварийное восстановление и другие типичные задачи администрирования. В случае с IaaS помните, что вы по-прежнему должны управлять базами данных, даже если они размещены в «облачной» инфраструктуре и виртуальных машинах.

Проблемы производительности в «облаке» или локально? Что для вас более комфортно, выполнение аварийного восстановления, мониторинг производительности и диагностика неполадок в «облаке» или в собственной инфраструктуре? Можно ли пользоваться тем же набором инструментов? Где и как учиться, чтобы стать экспертом?

Прежние соглашения об уровне обслуживания (SLA) или новые? Картина SLA, скорее всего, изменится после того, как вы примете в расчет новые компоненты. Сможете ли вы обеспечить выполнение соглашений после того, как будут заданы такие показатели, как целевые точки восстановления (RPO) и цель времени восстановления (RTO)?

Чье «облако»? Помимо всего прочего, предстоит выбрать поставщика. Какие критерии наиболее важны для вашей компании? Репутация? Доля рынка? Согласованность с существующей инфраструктурой?

Какой бы путь к «облаку» ни выбрала ваша компания, будьте готовы выполнить исследование и документируйте свои рекомендации. Ведь вы — эксперт!

Ваши обязанности

Работа описанным выбором не ограничивается. После того как путь в «облако» проложен, нужно задуматься об ответственности.

Выше уже отмечалось, что большинство администраторов баз данных давно стали участниками реализации методов DevOps. Часть Dev — это настройка SQL, создание отчетов и составление SQL-инструкций, а часть Ops — это инфраструктура, с такими задачами, как резервное копирование, мониторинг и аварийное восстановление. При наличии «облака» и DbaaS приготовьтесь, что к этим обязанностям добавится круглосуточный охват глобальных баз данных, чтобы проложить путь к непрерывному развертыванию.

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

Управление производительностью хранилища в «облаке» тесно связано с управлением стоимостью, и теперь, когда плата взимается помесячно, затраты на мониторинг и контроль действительно важны. Например, если скорость выполнения плохо составленного SQL-запроса на 50% ниже оптимальной, то стоимость запроса на 50% выше, так как вы платите непосредственно за использованные ресурсы.

Результат — один из самых высоких уровней ответственности: вашему финансовому директору теперь известно ваше имя. Помимо управления, производительности, мониторинга, аварийного восстановления и всех прочих обязанностей, теперь администратор баз данных отвечает еще и за затраты. Если вы не выполнили «домашнюю работу», выбрав правильный путь к «облаку» и настойчиво следуя ему, то компания несет из-за вас убытки.

А это может убить вашу мечту о стабильной роли администратора баз данных.

Агитируйте за «облако»

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

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

Теперь взгляните на рисунок 8, на котором показаны ответы на основной вопрос в исследовании DBTA: «На каких этапах процесса принятия решения о переносе баз данных в «облако» привлекают администратора баз данных?»

 

Участие администраторов баз данных в «облачных» решениях
Рисунок 8. Участие администраторов баз данных в «облачных» решениях

 

Неудивительно, что администраторы баз данных имеют влияние на этапах исследования, реализации и обслуживания «облачных» решений и DBaaS. Также естественно, что к ним прислушиваются при обучении.

Что же происходит с принятием решений и запуском проектов? Почему компании не всегда полагаются на администраторов баз данных в двух областях, в которых они наиболее опытны? Как было сказано выше, администраторы баз данных указывают верный путь к «облаку» благодаря проводимым исследованиям и собираемым ответам; что происходит после этого? Приходят большие дяди в темных очках и говорят: «Молодец. Отлично сработано, дальше действовать будем мы».

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

Наконец, важная задача относительно «облака» и DBaaS для администраторов баз данных: тратить меньше времени на рутину (развертывание баз данных, резервное копирование, мониторинг производительности, тестирование аварийного восстановления и установка обновлений). Чем больше используется «облако», тем активней эти задачи должны перемещаться из вашего списка дел в список дел вашего «облачного» поставщика.

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

Роль администратора баз данных будет меняться до тех пор, пока развиваются базы данных. Нет ничего плохого в том, чтобы продолжать исполнять те же административные обязанности, что и в прежние годы. Но в конечном итоге такие тенденции, как DevOps, многоплатформенные базы данных и «облако», приведут к изменению этих обязанностей. Чем скорее вы воспользуетесь возможностями, предоставляемыми каждой из тенденций, тем быстрее сможет выйти из состояния зомби и перейти к интересным задачам, которые превращают администраторов баз данных в настоящих партнеров по бизнесу.

Дополнительную информацию о DevOps можно найти в техническом обзоре The Importance of Continuous Monitoring in DevOps Pipeline по адресу: https://www.quest.com/techbrief/the-importance-of-continuous-monitoring-in-a-devops-pipeline8131211/.

Подробнее о многоплатформенных базах данных рассказано в обзоре Managing Cross-Platform Database Environments по адресу: https://www.quest.com/techbrief/managing-crossplatform-database-environments8130491/.

О трудностях, с которыми ежедневно сталкиваются ваши коллеги-администраторы, читайте в отчете DBTA по адресу: https://www.quest.com/whitepaper/dbas-face-new-chal­lenges-trend-in-database-administration8130482/.