Он оперативен, но в то же время спокоен. Он умен, аналитически мыслит и всегда сосредоточен. Это основные качества, благодаря которым можно достичь успехов специалисту DBA.
В перерывах между докладами, в кулуарах конференции PG Day’16 мы буквально на пару минут отвоевали внимание опытных администраторов и задали вопросы о том, что они думают о своей профессии, какие досадные ошибки они допустили в работе и какие советы дали бы новичкам. Антон Бушмелев, Александр Чистяков, Дмитрий Васильев, Михаил Тюрин и Брюс Момжан вспомнили истории на старте своей карьеры и рассказали, сколь тернист оказался их путь.
Кто такой администратор баз данных, и чем он отличается от других «айтишников»?
Александр Чистяков: Администратор баз данных – это человек, который умеет читать план запросов. В основном, этим он и отличается от других айтишников. На самом деле, человек, который умеет читать план запроса, немного печален, потому что он хотел бы, чтобы другие айтишники тоже так могли, но они такого не могут. Он пытается их сподвигнуть на это, но они не хотят. Возникает некий конфликт. Человек, который не хочет быть тем, кем он является, но вынужден.
Антон Бушмелев: Администратор баз данных – эксперт в своем деле. Это должен быть человек с опытом. Желательно, с background в разработке, чтобы с ходу замечать косяки при “накате” релиза. Администратор должен быть самым квалифицированным человеком в команде. За ним большая ответственность, он один отвечает сразу за много баз. Чем отличается от остальных “айтишников”? Он должен быть фанатом своего дела, любить свою работу!
Дмитрий Васильев: На инженере базы данных лежит максимальная ответственность не только за текущую работу приложений, но и за сохранность данных, в том числе исторических. Подчас, сердцем и кровеносной системой любого типового проекта является база данных. Нет ничего важнее сохранности данных, это очень большая нагрузка на человека.
Михаил Тюрин: Администратор баз данных отличается от других “айтишников” тем, что его сложно найти. Чрезвычайно редкий специалист. К нему повышенные требования. Большая редкость – найти человека, который одновременно понимает, что такое транзакция и bаsh-скрипт.
Брюс Момжан: Администратор работает с запросами, которые пишут разработчики приложений, и настраивает БД таким образом, чтобы производительность не падала, работа была надежной, вовремя происходили обновления. Он также устанавливает дополнительные пакеты, делает резервные копии и т.д. – есть множество задач на бэкенде, которые выполняет администратор баз данных, чтобы помочь разработчикам приложений. Этот человек отвечает за то, чтобы все таблицы были созданы, управляет правами пользователей, контролирует, как всё работает и следит за производительностью.
Что главное в профессии?
Александр Чистяков: Четкость. Я думаю, что необходимо помнить, как мы оказались в текущей ситуации, чтобы не быть виноватым. Хорошая память нужна.
Антон Бушмелев: Спокойствие, без этого очень тяжело. Должна быть нацеленность на результат. Не надо говорить разработчикам: «Ваш софт – г*вно!», для них это не будет составлять интереса. Надо показывать им: «Ребята, если делать так и так, будет быстрее. Давайте попробуем переделать!» – такой подход у хорошего ДБА должен быть.
Дмитрий Васильев: Способность к аналитике, рассудительность, умение избегать принятия быстрых, необдуманных решений.
Михаил Тюрин: Если совсем не философствовать, а говорить о конкретных навыках, это понимание алгоритмов и структур, которые заложены в основу баз данных. И навыки скриптового программирования, как внутри базы данных, так и на языке общего назначения.
Брюс Момжан: Умение честно признать то, кем ты являешься на самом деле, и не пытаться прыгнуть выше своей головы. 19 лет назад я считал себя хорошим разработчиком приложений, пока не начал работать на международном уровне и не познакомился с людьми, которые намного круче меня. Тогда я понял, что это надо принять, и выбрал путь – эмоционально мотивировать людей, создавать такую атмосферу, в которой каждый был бы максимально продуктивен и чувствовал свою принадлежность к чему-то важному.
Расскажите о самой своей досадной ошибке.
Александр Чистяков: Моя самая досадная ошибка была, когда я удалил в режиме реального времени продакшн-базу заказчика. Я приехал из Тверской области, очень мало спал и не то чтобы я перепутал базы… Я не помню, что точно было, но примерно 30% базы заказчика мы не смогли восстановить. Остальные 70% я восстановил, потому что хорошо знал, как работает база. А то он бы потерял 100%. А я бы потерял заказчика, больше ничего. Дело в том, что системный администратор – это такой человек, который может 600 человек оставить без зарплаты и ничего не потерять.
Антон Бушмелев: Это был банк, дело было утром, я делал definition (база Oracle), и все было хорошо. После definition бьются индексы. Я проверил, что индексы отребилдились. Это были глобальные индексы по партициям и субпартициям. Я все проверил, кроме субпартиций. Благополучно уснул.
В 8 часов начались проблемы с блокировками, так как индексы по субпартициям все-таки оказались инвалидными, и банк стоял 2 часа. Минус 20% дали потом. После этого случая очень пристальное внимание уделяю мониторингу, чтобы все это отлавливалось. Ночью можно что-то забыть, а мониторинг работает постоянно.
Дмитрий Васильев: Когда меня только пустили за консоль суперпользователем базы данных, я, не прочитав документации по команде TRUNCATE, выполнил ее для самой большой таблицы с логами, из-за чего продакшн встал на несколько часов.
Михаил Тюрин: Ну, DROP DATABASE я не делал, потому что нельзя сделать DROP DATABASE на нагруженной системе. Коннекты идут, и она не дропнется просто так. Досадные ошибки – это ошибки организации работы: что-то можно было бы сделать более эффективно, если бы я смог с кем-то договориться, заранее что-то решить до внедрения.
Ошибкой также может быть недооценка масштаба катастрофы. То, что очевидно человеку с многолетним опытом работы с данными, может быть абсолютно неочевидно программисту, который переоценивает свои силы и навыки, с высоко поднятым флагом рвется что-то делать, если его вовремя не остановить.
Конкретные примеры ошибок – неинтересные вещи: забыл выключить логирование, забыл закрыть коннект, уехал в отпуск. Ты пятый день лежишь на пляже, и вдруг тебе звонят, что запрос перестал работать. Ты просишь показать stat_activity, а там висит транзакция, которую ты забыл закрыть перед тем, как уехал.
Брюс Момжан: Первые несколько лет оставляли желать лучшего мои способности к оценке трудозатрат. Я говорил: «Сделаю это за день!», а три дня спустя всё ещё работал над той же задачей. Потом понял, что даю оценки, исходя из сценария, где всё идёт идеально. Но ничего никогда не бывает идеально. Поэтому стал удваивать оценку времени и добавлять ещё 10% на форс-мажоры. Так что если раньше я называл 2 дня, то теперь стал говорить 4, 5. Пришлось много времени потратить на то, чтобы вывести эту формулу, но сейчас она отлично работает.
Что бы вы посоветовали тем, кто хочет заниматься базами данных и думает, не стать ли дба?
Александр Чистяков: Ходить на наши конференции и хорошо прислушиваться к тому, что делается в сообществе. Это бизнес, здесь есть свои тренды, и нужно их чувствовать.
Антон Бушмелев: Начать с концептов и азов, не гоняться за «халтурами», не искать серебряную пулю для решения проблем. Когда будет хорошая база, все остальное пойдет быстрее.
Дмитрий Васильев: Я сам не сразу пришел к ДБА. Разное, многое перепробовал. Все вещи интересные, но специфика базы данных заключается в том, что это немножко другой мир, он движется в ином темпе из-за ответственности, которая лежит на инженерах БД. Но это не означает что он не интересный. Приходится знать железо, и как вообще все устроено. Хватает времени, чтобы разобраться досконально, в чем проблема. Словно японский дзен, нужно созерцать и понимать, что же на самом деле там происходит.
Михаил Тюрин: Расширять кругозор. Когда говорят про ДБА, это как в том анекдоте – ты же программист, иди разберись! Все, что касается данных, отправляют к ДБА, а на самом деле ДБА при этом вынужден решать задачи организации и архитектуры широкого стека приложений. Данные вовлечены во все взаимодействия внутри системы, и те решения, которые ДБА примет, скажутся на всех уровнях стека обработки запросов от конечного пользователя. Надо понимать как устроены другие уровни системы, которую поддерживает ДБА. Это поможет ему понять проблемы, возникающие у людей, которые пишут клиентов к базе данных.
Нужно знать классические проблемы computer science. Мы их знаем, как минимум, три: инвалидация кеша, именование объектов и, третья проблема – это проблема потерянной единички. Вообще, основная проблема – все любят распределенную обработку, а в распределенных системах часто бывает так, что одно и тоже повторяется несколько раз.
Брюс Момжан: Если вы любите всё упорядочивать, вам понравится работать с базами данных. Языки программирования и технологии приходят и уходят, а базы данных остаются. Это такая фундаментальная часть разработки, затрагивающая вещи, влияющие на эффективность крупных организаций. Я бы рекомендовал изучать Постгрес. Это не тот проект, который вдруг возник и скоро исчезнет. В США специалисты по Постгресу очень ценятся, и в России тоже, потому что их недостаточно. Они являются кем-то вроде суперзвезд в своих компаниях, и было бы здорово, если бы больше людей это понимали и стремились стать такими специалистами. Те, кто стремится узнавать новое, учиться, обязательно достигнут карьерных высот.
Продолжение следует…
Автор: PG Day'17 Russia
