Вредные привычки при администрировании баз данных

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

«Мы верим в резервную копию»

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

Правила:

• Тестируйте резервные копии несколькими способами. Не доверяйте одному тесту.
• Создавайте копии резервных копий. Администраторы всегда должны использовать не менее двух методов резервного копирования. Например, создайте резервную копию на диске, а затем сохраните её копию на ленту, дополнительно сделайте резервную копию AI-архивов.
• Проверяйте резервные копии. Восстановите резервную копию и накатывайте на неё AI-архивы в течение дня, это докажет, что резервная копия и AI-архивы не повреждены.
• Тестируйте процесс восстановления так часто, как это возможно. Один из признаков того, что администратор перегружен, или его приоритеты выставлены неверно, заключается в том, что в течение квартала не было тестового восстановления. Тестирование процесса восстановления подтвердит, что ваша стратегия резервного копирования и восстановления верна, либо выявит недостатки, которые необходимо исправить. Кроме того, практика восстановления позволит вашей команде без труда справиться с восстановлением, когда это действительно будет необходимо.
• Если вы на 100% не уверены в резервной копии, то никогда не восстанавливайте её поверх своей промышленной базы данных.

«Мы не нуждаемся в After-Imaging. Мы используем надежные диски»

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

Механизм After-Imaging не только защищает базу данных от таких аппаратных сбоев, как сбой дисков. В основном ситуации с потерей данных связаны с человеческим фактором. Администратор может случайно удалить базу данных, программист может создать БАГ, а пользователь сделать серьезную ошибку, всё это в точности в двойном экземпляре воспроизведется в зеркальной дисковой системе. Механизм After-Imaging защищает базу данных от таких ошибок (в том числе аппаратных), записывая заметки обо всех транзакциях базы данных в AI-экстенты, которые впоследствии могут быть воспроизведены на базе данных, восстановленной из основной резервной копии, тем самым позволяя восстанавливать базу на любой момент времени. Наличие этого механизма сохранило немало сил и нервных клеток администраторам баз данных и их руководителям.

Правила:

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

«Будет работать так, как мы ожидаем»

СУБД Progress OpenEdge - это удобная и дружелюбная система, и чем дольше вы работаете с ней, тем вероятнее привыкание к тому, что она всегда «будет работать, как надо». С одной стороны в такой привычке нет ничего плохого, поскольку в большинстве случаев так оно и есть, но с другой, эта привычка одна из самых опасных, т.к. расслабляет ваше внимание.

Правила:

• Внушайте вашей команде (не только администраторам баз данных), что необходимо постоянно практиковаться, практиковаться и еще раз практиковаться. Администраторы баз данных должны оттачивать свои действия в безопасной изолированной тестовой среде, способной максимально имитировать промышленную среду. Для этого руководителям организации необходимо обеспечить их не только временем, но и соответствующими ресурсами.
• Закрепляйте неопытных администраторов за более опытными. Начинающие администраторы бесстрашны, а изучение чьего-либо опыта поможет им не совершать необдуманных действий и стать более осторожными.
• Требуйте от администраторов письменные планы, а так же скрипты для всего, что они делают. Удивительно, как часто администраторы уверено говорят: – «Я делал это много раз, и мне не нужен никакой план». Хорошая память - это хорошо, но на практике, особенно в экстремальной ситуации, никто не застрахован от ошибок, порой достаточно просто отвлечься на минуту и всё перепутать. Если администратор что-то делает, то ему жизненно необходим заранее проверенный и протестированный план действий.

«Мы помним, как это случилось, и помним, что мы сделали, чтобы исправить это»

Покажется невозможной ситуация, когда администратор может забыть о задаче, на решение которой он потратил много недель, и всё же это случается повсеместно. Документирование – это главный способ избежать повторения ошибки и использовать накопленный опыт.

Правила:

• Требуйте от администраторов тщательного ведения документации и дневников своих действий, подробно обосновывая и детально описывая рабочие процессы.
• Предоставьте своей команде программное обеспечение для ведения общей документации (например, Wiki), чтобы эти документы можно было быстро найти в чрезвычайной ситуации.
• Обеспечьте соблюдение администраторами дисциплинированного документирования и периодически проверяйте их, например, задавая такие вопросы: «Когда это было сделано, какими скриптами, кем? Что вы делали в такой-то день? и т.п.». Если они не смогли уверенно ответить, значит, они снова пренебрегли документированием, доверяя только собственной памяти.

«Нам не нужно мониторить систему. Пользователи всегда сообщат нам, когда что-то станет работать не так».

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

Правила:

• Приобретите хорошую систему мониторинга, позволяющую заранее выявлять и решать возможные проблемы прежде, чем они приведут к сбою и вынужденному простою базы данных.
• Старайтесь исключить возможные проблемы из-за обновления системы, активно работая с разработчиками и тестировщиками, чтобы гарантировать, что новое ПО будет работать без ошибок.
• Изучите производительность системы при нормальной её работе, чтобы быстро распознать проблему, когда она произойдет. Когда что-то пошло не так, в первую очередь задайте себе вопрос: «Как это работало?», а затем: «Что изменилось?», это поможет быстрее понять, что произошло.
• Собирайте статистическую информацию по работе системы. Это облегчит планирование ресурсов системы, а также поможет при анализе её производительности.

«Я здесь ни при чём! Если запрос работает неправильно, то это проблема разработчика»

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

Конфронтационные отношения между администраторами и разработчиками существенно замедляют обновление системы и не способствуют повышению её производительности.

Правила:

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

«Я знаю, что я делаю, и я не нуждаюсь в чьей-либо помощи»

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

Правила:

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

«Это работало бы намного лучше, если бы только мы имели…»

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

Правила:

• Никогда не обновляйте аппаратную инфраструктуру без предварительного исчерпания всех возможностей настройки. Помните, не так давно огромные компании без проблем (или почти без проблем) работали на серверах с крошечным (по нынешним меркам) уровнем мощности, а всё благодаря четкому пониманию своих потребностей и квалификации специалистов.
• Не соглашайтесь на использование расширяющих и новых функций, пока не будете осведомлены об обязательствах по обслуживанию и связанными с ними расходами.
• Остерегайтесь программного обеспечения для администраторов баз данных, которые предоставляют дружественный графический интерфейс для решения сложных задач. Этот тип интерфейса при определенных обстоятельствах позволяет администратору-новичку легко управлять базой данных, но одновременно такой интерфейс препятствует получению фактических навыков прямого управления базой данных. Кроме того, такие инструменты, как правило, скрывают реальные риски, связанные с администрированием, позволяя выполнить необратимые действия, которые могут привести к разрушительным последствиям, причем сделать это можно одним простым щелчком мыши.

«Нам не нужны никакие обновления»

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

Правила:

• Регулярно устанавливайте обновления.
• Держите лицензии в актуальном состоянии.
• Не бойтесь требовать исправления ошибок от производителей.

«Он Гуру, а значит он прав…»

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

Правила:

• Относитесь к советам с осторожностью . Не стоит сломя голову сразу приступать к каким-либо действиям.
• Порой важнее понять рассуждения (почему именно так, а не иначе), чем слепо следовать указаниям.
• Тестируйте, тестируйте и ещё раз тестируйте…