Глава 1. Введение
Цель этой книги – предоставить руководство по развитию на пути становления настоящим инженером надёжных баз данных (database reliability engineer, DBRE). В названии книги мы специально использовали слово инженер, а не администратор.
Бен Трейнор (инженер Google) охаракеризовал эту деятельность так:
В основном, это работа, которая исторически выполнялась отделом эксплуатации (operations team), но с привлечением инженеров с их опытом в проектировании программного обеспечения, а также желанием и умением автоматизировать человеческий труд.
Сегодня профессиональные DBA должны быть инженерами – не администраторами. Мы строим и создаём. В соответствии с принципом DevOps мы все в одной лодке, и нет «чужой» проблемы. Как инженеры, мы применяем знания и экспертную оценку для проектирования, построения и использования хранилищ данных и структур данных в них. Как DBRE, мы должны применять основные принципы и глубокие знания, которыми мы обладаем больше других.
Если вы посмотрите на сегодняшнюю инфраструктуру, не относящуюся к хранению, вы увидите системы, которые легко создаются, выполняются и разрушаются программно и часто автоматически. Жизненный цикл этих компонентов может исчисляться днями или даже минутами. Когда одна пропадает, на её месте появляются другие для сохранения качества сервиса на требуемом уровне.
Наша следующая цель – это освоение принципов и практик проектирования, построения и управления хранилищами данных в парадигме проектирования надёжных систем и культуре DevOps. Вы можете применять эти знания к любой технологии баз данных, с которой вас попросили работать, в любой стадии развития вашей организации.
Руководящие принципы DBRE
Когда мы начали писать эту книгу, одним из первых вопросов, которые мы задали себе, был: какие принципы лежат в основе новой ступени развития профессии DBA. Если мы переопределяем подход к проектированию и управлению хранилищами данных, то мы должны определить и основы поведения, которые мы поддерживаем.
Защита данных
Традиционно, защита данных всегда была и всё ещё является основным принципом профессии DBA. Обычно цель достигалась за счёт:
- строгое разделение обязанностей между DBA и разработчиками;
- регулярно тестируемые процедуры бэкапа и восстановления;
- процедуры безопасности с регулярным аудитом;
- дорогая СУБД с гарантиями надёжности и устойчивости;
- дорогая система хранения данных (СХД) с отказоустойчивостью всех компонент;
- обширный контроль изменений и административных задач.
В командах, привыкших работать совместно, строгое разделение обязанностей может быть не только в тягость, но ещё и тормозом развития. В Главе 8, Управление релизами, мы обсудим методы создания «защитных сеток» и уменьшения потребности в разделении обязанностей.
Чаще чем когда-либо архитекторы и инженеры выбирают открытые СУБД, которые не могут гарантировать такой же надёжности, как, например, Oracle. Иногда это даёт преимущества в производительности и масштабируемости. Выбор правильной СУБД и понимание последствий этого выбора мы рассматриваем в Главе 11. Понимание, что есть разные инструменты, и умение их эффективно выбирать быстро становится нормой.
Подсистемы хранения так же подвергаются значительным изменениям. В мире, где системы часто виртуализированы, сети и эфемерные СХД находят применение в проектировании СУБД. Это мы обсудим далее в Главе 5.
Боевые БД на эфемерных СХД.
В 2013г. компания Pinterest перенесла свои БД с MySQL на эфемерные СХД Amazon Web Services (AWS). Эфемерные СХД означают, что в случае падения или выключения виртуальной машины всё содержимое диска пропадает. Pinterest выбрала эфемерные СХД из-за стабильно высокой пропускной способности и низких задержек.
Такой выбор требовал как значительных инвестиций в автоматизированный и железобетонный бэкап, так и способность вычислительных узлов кратковременно обходиться без подсистемы хранения. Эфемерные СХД не поддерживают снимков, поэтому единственным методом восстановления было копирование полного бэкапа по сети вместо наката журнала транзакций к снимку.
Этот пример демонстрирует, что можно вполне безопасно управлять данными в эфемерных СХД, если использовать правильные методы и инструменты.
Новые подходы к защите данных могут выглядеть скорее так:
- ответственность за данные поделена между кросс-функциональными командами;
- регламентированные автоматизированные процессы бэкапа и восстановления, применяемые командой DBRE;
- регламентируемые политики безопасности и процедуры безопасности, применяемые командой DBRE и Security;
- все политики применяются автоматически;
- требования к данным и отказоустойчивости определяют выбор СУБД;
- автоматические процессы, общепринятые практики и отказоустойчивость вместо дорогого сложного оборудования;
- изменения встроены в развёртывание с особым вниманием к тестированию, откату и снижению влияния.
Самообслуживаемость для масштабируемости.
Талантливый DBRE, безусловно, более редкий товар, чем инженер надёжности сайта (site reliability engineer, SRE, здесь идёт отсылка к книге «Google’s Site Reliability Engineering»). Большинство компаний не могут позволить себе содержать более одного-двух. Так что мы должны создавать как можно больше ценности, что достигается путём создания самообслуживаемых платформ. Опираясь на стандарты и инструменты, команды могут запускать новые сервисы и вносить изменения с требуемой скоростью, не упираясь в перегруженного работой DBA. Примеры самообслуживаемых методов:
- сбор правильных метрик с хранилища данных;
- создание инструментов резервного копирования и восстановления, которые могут быть развёрнуты для новых хранилищ данных;
- определение эталонных архитектур и конфигураций хранилищ данных;
- совместная работа с отделом безопасности для определения стандартов для хранилищ данных;
- создание методов безопасного применения изменений к БД с их предварительным тестированием.
Другими словами, эффективный DBRE помогает другим, направляя их, а не служит сторожем.
Избавление от тяжкого труда
Команда SRE компании Google часто использует фразу «избавление от тяжкого труда» (Elimination of Toil), которая обсуждается в Главе 5 книги «Google’s Site Reliability Engineering». В этой книге тяжкий труд определяется как работа, связанная с запуском боевого сервиса, которая имеет тенденцию быть ручной, повторяемой, с возможностью автоматизации, лишённой устойчивой ценности, и которая растёт линейно с ростом самого сервиса.
Чтобы избавить команду DBRE от тяжкого труда, необходимо эффективное применение автоматизации и стандартизации. В этой книге мы приведем примеры тяжкого труда, специфичного для DBRE, и метода избавления от него. Тяжкий труд, конечно, расплывчатое понятие со множеством предубеждений, меняющихся от человека к человеку. В этой книге мы определим его как ручной не творческий труд, который повторяется и не требует работы мозга.
Ручные изменения в БД.
У многих клиентов инженеров БД просят посмотреть и применить изменения в БД, что может включать изменения в таблицы и индексы, добавление, модификацию, удаление данных. Все уверены, что DBA применяют эти изменения и следят за последствиями в реальном времени.
У одного клиента таких изменений в БД было очень много. Мы пришли к тому, что 20 часов в неделю занимались их применением. Не стоит и говорить, что несчастный DBA, который проводил половину своего рабочего времени за тупой монотонной работой, задолбался и ушёл.
Столкнувшись с нехваткой рук, руководство наконец-то разрешило команде администраторов БД создать инструмент для разработчиков, автоматизирующий применение пакета изменений после того, как один из администраторов просмотрит и одобрит его. Вскоре, все стали доверять новому инструменту, что дало возможность команде DBRE сфокусироваться на интегрировании этих процессов с процессами развёртывания в целом.
Базы данных – это не какие-то особенные снежинки
Наши системы не более и не менее важны, чем любые другие компоненты, обслуживающие потребности бизнеса. Мы должны бороться за стандартизацию, автоматизацию и гибкость. Важно понимать, что компоненты БД не священны. Мы должны быть способны потерять любой компонент и заменить его без особой сложности. Хрупкие хранилища данных в стеклянной комнате остались в прошлом.
Чтобы показать разницу между особенными снежинками и компонентом сервиса можно сравнить домашних животных с крупнорогатым скотом. Сервер «домашний питомец» это тот, который вы кормите, заботитесь о нём и вынашиваете, когда он болеет. Ещё у него есть имя. В компании
Travelocity в 2000 наши серверы назывались героями из Симпсонов, и наши два Oracle-сервера носили имена Patty и Selma. Я провёл много ночей с этими девчонками. Они были ещё теми содержанками!
«Крупнорогатые» серверы не имеют имён – у них есть номера. Вы не проводите время настраивая серверы, заходя на каждый хост. Когда кто-то подаёт признаки болезни – вы изымаете его из стада и держите неподалёку для судмедэкспертизы.
Хранилища данных – одни из последних домашних питомцев. Всё-таки, они хранят «Данные», и просто не могут быть заменены на коров с коротким жизненным циклом и полной стандартизацией. Что на счёт особых правил репликации нашей реплики для отчётов? Что на счёт особой конфигурации реплики для отказоустойчивости основного узла? У них разные задачи.
Устраняем барьеры между разработкой и эксплуатацией
Ваша инфраструктура, конфигурации, модели данных и сценарии – составные части ПО. Обучайтесь и участвуйте в разработке ПО, как поступал бы любой инженер. Пишите код, тестируйте, интегрируйте, собирайте, тестируйте и разворачивайте. Мы не забыли про тестирование?
Для тех, кто занимался администрированием и писал скрипты для «бекенда», это может быть сложнейшим сдвигом парадигмы. В традиционном окружении процессы проектирования, построения и тестирования продуктов разделены между разработчиками, системными администраторами и DBA. Обсуждаемый сдвиг парадигмы устраняет отличия во взглядах на организацию процесса так, чтобы DBRE и системные администраторы захотели выполнять свою работу похожими методами.
Разработчики должны учиться администрировать!
Администраторам часто говорят учиться программировать или «идти домой». Хотя в целом я с этим согласен, но верным должно быть и обратное. Разработчики, которые не понимают принципов управления инфраструктурой, будут создавать хрупкий, не производительный и потенциально небезопасный код.
DBRE могут интегрироваться непосредственно в команду разработчиков, работать над тем же кодом, проверяя, как код взаимодействует с базами данных, меняя код для быстродействия, функциональности и надёжности.
Устранение этих организационных барьеров увеличивает производительность и скорость разработки по сравнению с традиционными моделями, и DBRE должны адаптироваться к этим новым процессам и культуре.
Эксплуатация (operations)
Одна из основных компетенций DBRE – это эксплуатация (operations). Она включает в себя проектирование, тестирование, сборку и эксплуатацию любых систем с непростыми требованиями к масштабируемости и надёжности. Т.е. если вы хотите быть инженером БД – вам надо знать эти вещи.
На макроуровне эксплуатация – это не роль. Эксплуатация – это сумма всех знаний, навыков и ценностей, которые ваша компания построила вокруг практики управления качественными системами и программными продуктами. Это ваши скрытые ценности, так же, как и явные ценности, привычки, совместный опыт, система вознаграждений. Все от поддержки до CEO участвуют в результатах эксплуатации.
Слишком часто это делается не очень хорошо. Во многих компаниях культура эксплуатации настолько ужасна, что сжигает всякого, кто к ней приблизится. Несмотря на это, ваша культура эксплуатации – это внезапно появившаяся характеристика вашей компании и того, как она относится к своей технической миссии. Таким образом, если вы скажете, что с эксплуатацией у вас не очень – мы просто не пойдём на сделку.
Возможно, вы разработчик или сторонник инфраструктуры «as a service». Может быть вы сомневаетесь, что принципы эксплуатации обязательны для бесстрашного DBA. Думать, что модель облачных вычислений освобождает разработчика от вопросов эксплуатации – ошибочно. На самом деле совершенно наоборот. Это новый бесстрашный мир, где у вас нет подручных администраторов, где для вас эту работу выполняют инженеры Google, Amazon, PagerDuty, DataDog и т.п. В этом мире разработчики должны лучше понимать в администрировании, архитектуре и производительности, чем сейчас.
Иерархия потребностей
Некоторые из вас подошли к этой книге с опытом в корпорациях, а кто-то – в стартапах. Так же, как мы рассматриваем прочие системы, стоит подумать и о том, что вы будете делать в первый же день, когда возьмёте на себя ответственность за базы данных? У вас есть бэкапы? Они рабочие? Вы уверены? Существует ли реплика, на которую можно переключиться? Вы знаете, как это сделать? Она на том же кабеле питания, маршрутизаторе, оборудовании, где и основной узел? Узнаете ли вы, если бэкапы перестанут выполняться? Как вы об этом узнаете?
Другими словами, нам нужно поговорить о потребностях базы данных.
Для людей придумана иерархия потребностей Маслоу – пирамида желаний, которые должны быть удовлетворены, чтобы чувствовать себя успешным: физическое выживание, безопасность, любовь и принадлежность, почтение и самоактуализация. В основе пирамиды самые базовые потребности, такие как выживание. Когда они удовлетворены, мы приходим к самоактуализации, когда мы можем безопасно изучать, играть, создавать и достигать полного раскрытия своего уникального потенциала. Это для людей. Теперь давайте применим такой подход к базам данных.
Выживание и безопасность
Основные потребности вашей базы данных – это бэкапы, реплики и возможность переключиться. У вас есть база данных? Она рабочая? Пингуется? Приложение отвечает? Сделаны резервные копии? Восстановление работает? Как вы узнаете, если перестанет работать?
Ваши данные в безопасности? Существуют ли копии ваших данных? Вы знаете, как переключаться? Копии данных находятся на разном оборудовании с разными подводами питания? Копии консистентны? Можете ли вы восстановиться на какой-то момент времени? Как вы узнаете, если данные будут испорчены?
Мы рассмотрим эти вопросы детальнее в главе про резервное копирование и восстановление.
Так же стоит готовиться и к масштабированию. Масштабировать заранее, конечно, не стоит, но подумать о росте следует так же, как мы определяем идентификаторы для ключевых объектов данных, систем хранения и архитектуры.
Виды масштабирования
Мы будем достаточно часто обсуждать масштабирование. Масштабируемость — это способность системы или сервиса справляться с увеличением работы. Это может быть фактическая способность, если вся система была построена с расчётом на рост, или это потенциальная способность, если архитектура предусматривает добавление ресурсов и компонентов, нужных для роста. Существует четыре общепринятых пути масштабирования:
- вертикальное, за счёт добавления ресурсов (scale up);
- горизонтальное, за счёт дублирования систем или сервисов (scale out);
- разделение нагрузки на небольшие части по функциям, чтобы каждая из них могла масштабироваться независимо (functional partitioning);
- разделение нагрузки на идентичные части, отличающиеся набором данных, над которым идёт работа (sharding).
Конкретные аспекты этих подходов будут рассмотрены в Главе 5, Проектирование инфраструктуры.
Любовь и принадлежность
Любовь и принадлежность — это превратить ваши данные в объекты первого класса (first-class citizen) процесса разработки ПО. Это перестать изолировать базы данных от остальных систем. Это вопрос и технический, и культурный, поэтому его можно назвать «требованиями DevOps». На верхнем уровне это значит, что управление вашими базами данных должно выглядеть и ощущаться (насколько это возможно) как управление всеми остальными системами. Это также означает, что вы поощряете изменчивость и кросс-функциональность. Стадия любви и принадлежности — это когда вы постепенно перестаёте логиниться под рутом и грубо командовать. Это когда вы начинаете использовать тот же самый анализ кода и практики развёртывания.
Инфраструктура БД должна стать частью одного процесса вместе с другими компонентами архитектуры. Работа с данными должна быть согласована со всеми остальными частями приложения, что должно дать почувствовать любому, что он может справиться с поддержкой БД.
Боритесь с желанием внушать страх в разработчиков. Это очень заманчиво – чувствовать, что у вас всё под контролем. На самом деле нет – у вас нет контроля. Намного лучше для всех будет направить энергию в создание «поручней», чтобы было сложно что-то разрушить случайно. Обучайте и давайте возможность любому вносить свои изменения. Смиритесь с тем, что неудачи будут. Другими словами, создавайте эластичную жизнеспособную систему и поощряйте всех работать с базами данных как можно больше.
«Поручни» в Etsy.
Etsy представила инструмент под названием Schemanator для безопасного внесения изменений в БД в их боевом окружении. Чтобы разработчики могли применять свои изменения, было использовано много поручней, таких как:
- эвристический анализ изменений для проверки соответствия стандартам;
- проверка, что скрипты с изменениями успешно выполняются;
- предполётная подготовка, показывающая разработчику текущий статус системы;
- поочередное применение изменений на выведенные из нагрузки серверы;
- разбиение изменений на подзадачи, чтобы можно было остановить процесс в случае непредвиденных проблем.
Подобнее можно прочитать в блоге
Почтение
Почтение – это высшая потребность в пирамиде. Для людей это означает признание мастерства. Для баз данных – это возможность мониторинга, отладки, самоанализа и оснащенность инструментами. Это способность понимать системы хранения сами по себе, а также соотносить события в масштабе всего стека. Есть две стороны этого этапа – ваши сервисы и ваши люди.
Ваши сервисы должны сообщать вам, если они падают, поднимаются или испытывают проблемы. Вы не должны смотреть на графики, чтобы узнать это. В развитой системе скорость изменений снижается, и поведение становится более предсказуемым. В боевом окружении вы каждый день изучаете слабые стороны систем хранения, особенности поведения и условия, приводящие к сбоям. Это можно сравнить с подростковым периодом инфраструктуры данных. Больше всего вам нужно уметь видеть что происходит. Чем более сложный продукт, тем больше в нём подвижных частей и тем больше нужно разработать инструментов мониторинга.
Ещё вам нужны кнопки и рычаги. Вам нужна возможность выборочно понизить качество сервиса вместо того, чтобы вырубить его полностью. Например:
- перевод в режим read-only;
- отключение некоторых функций;
- постановка операций записи в очередь для отложенного выполнения;
- возможность заблокировать выявленных вредителей – источников проблем.
Ваши люди имеют похожие, но не совпадающие потребности. Часто бывает, что люди слишком сильно реагируют, когда дело касается прода. Им не хватает понимания происходящего, и они начинают мониторить всё подряд, доходя до просмотра сотен графиков, большинство из которых бессмыслены. Если среди этого шума нет полезного сигнала, и люди вынуждены угадывать причину, просматривая логи – это так же плохо, как полное отсутствие графиков.
В этом случае вы можете начать «сжигать» своих людей – прерывать, будить, приучать не реагировать на получаемые алерты. На ранней стадии вы ожидаете от всех быть на телефоне. Когда петля затягивается – вы создаёте конференции, выталкивая людей из их зоны комфорта, мало помогая.
Самоактуализация
Так же, как каждый полностью раскрывший свои таланты человек уникален, уникальны и развитые системы хранения в каждой организации. Идеальные теоретические системы хранения для Facebook, Pinterest и Github выглядят по-разному, хотя могут совпадать на стадии стартапа. Но так же, как есть общие черты у здоровых развитых людей (не устраивают истерик в магазинах, питаются здоровой пищей и занимаются спортом), есть и общие черты у здоровых развитых систем хранения.
В этом смысле самоактуализация означает, что ваши хранилища данных помогают вам получить то, что вам нужно, не мешая прогрессу. Они дают возможность разработчикам выполнить свою работу и избежать ошибок. Банальные и распространённые проблемы должны устранять сами себя без вмешательства людей. Это означает, что масштабирование работает и справляется с 10-тикратным ростом каждый год так, что только через три года вы задумываетесь о ёмкости и производительности. Откровенно говоря, вашу систему хранения можно назвать зрелой, когда большую часть времени вы думаете о других интересных вещах, таких как новые продукты или предотвращение будущих проблем, вместо устранения текущих.
Это нормально – двигаться вперёд и назад между уровнями. Уровни, по большей части, нужны, чтобы расставить приоритеты. Например, уверенность в наличии рабочих бэкапов сильно важнее написания скрипта по автоматическому шардингу и добавлению ёмкости. Если у вас всё ещё только одна копия данных онлайн, или вы не знаете, как переключаться на резерв в случае сбоя – вы должны прекратить делать что-то другое и разобраться с этими первоочередными вещами.
Подводя итог
Роль DBRE – это сдвиг парадигмы относительно существующей и всем понятной роли DBA. Эта платформа даёт нам новый подход к функциям управления базами данных в постоянно меняющемся мире. В следующих главах мы рассмотрим эти функции в деталях, расставляя приоритеты между задачами ежедневной работы. С этими словами, мои отважные инженеры, давайте смело двигаться вперёд!
