DBA, священство больше не

Примечание. Этот инженерный пост был написан нашим администратором баз данных Сильвией Ботрос и впервые появился в блоге Sysadvent в декабре 2016 года.

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

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

Поскольку администраторы баз данных традиционно играют такие уникальные роли, их время в большом почете, становится все труднее мыслить в целом, когда повседневные задачи перегружены. Обычно прибегают к хрупким инструментам, таким как bash, для всех видов оперативных задач в среде администраторов баз данных. Нужна новая настройка БД из чистой установки ОС? Взять, проверить или восстановить резервные копии? Повернуть разделы или устаревшие данные? Когда ваш наиболее часто используемый инструмент — скрипты bash, все выглядит как гвоздь. Я уверен, что многие читатели готовят твиты, чтобы рассказать мне, насколько силен bash, но, пожалуйста, придержите свои комментарии до тех пор, пока не оцените мои рассуждения.

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

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

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

Почему

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

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

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

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

Управление конфигурацией

Это очень важно. Администраторы баз данных, как правило, предпочитают инструменты старой школы, такие как bash, для настройки базы данных. Я упоминал об этом ранее и ничего не имею против использования самого bash. На самом деле я часто его использую. Но это не правильный инструмент для настройки кластера. Особенно, если остальные операторы НЕ используют Bash для управления остальной архитектурой. Это правда, что операционные инженеры тоже знают Bash, но если они управляют остальной инфраструктурой с помощью таких инструментов, как Chef или Puppet, а базы данных управляются в основном вручную написанными сценариями, написанными администратором базы данных, вы создаете препятствие для их предоставления. помощь, когда требуется срочное изменение.

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

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

Runbook

Технически это подмножество документации, которую вы должны написать, но по моему опыту оказалось, что это гораздо полезнее, чем я считаю, что на него нужно указывать отдельно. Когда я говорю о модулях Runbook, я конкретно имею в виду документ, написанный для аудитории, НЕ являющейся администратором баз данных. Администраторы баз данных могут столкнуться со множеством проблем с рабочей БД, которые нам несложно отлаживать и устранять. Мы склонны недооценивать эту мышечную память и попадаем в модель «просто пришлите мне страницу», а мы «позаботимся обо всем».

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

Кроме того, я добавляю ссылку на соответствующий раздел Runbook (используйте привязки!) к описаниям страниц, которые переходят на пейджер. Это невероятно полезно для кого-то, кого хост базы данных вызывает в 3 часа ночи, чтобы найти место для начала. Эти вещи могут показаться незначительными, но, судя по моему опыту, они помогли мне преодолеть психологические барьеры для моей операционной группы, работающей над уровнем базы данных, когда это необходимо.

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

Видимость

Нам нравятся экраны терминалов. Мы любим их. Наиболее популярными инструментами в мире MySQL по-прежнему являются терминальные инструменты, которые находятся непосредственно на хостах базы данных и требуют предварительных знаний о них и о том, как их использовать. Я говорю о таких вещах, как innotop и оболочка MySQL. Это хорошо и по-прежнему полезно, но они созданы для администраторов баз данных. Если вы не хотите отвечать на вопросы типа «есть ли задержка репликации прямо сейчас?» вам нужны более совершенные инструменты, чтобы сделать любое состояние кластера в настоящее время и в прошлом доступным и легко усваиваемым для всех членов команды. У меня есть несколько примеров в этой области:

Оркестратор

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

Графана/графит

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

Производительность запросов

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

Боритесь с усталостью от пейджеров

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

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

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

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