«Ночные кошмары» администраторов СУБД. Как их избежать?

width:200px

04.05.11, Ср, 16:12, Мск,

Эксперты, опрошенные TAdviser считают, что наиболее часто администраторы баз данных (БД) или систем управления базами данных (СУБД) сталкиваются с одними и теми же трудностями, большинство из которых объясняется либо разгильдяйством, либо отсутствием бюджета на совершенствование программно-аппаратной платформы.

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

Несанкционированный доступ

Главный эксперт компании «Компас» Игорь Якобсон считает, что очень часто у администраторов БД появляется необходимость управления несанкционированными изменениями в базах. Обычно это происходит тогда, когда права доступа в БД не разграничены по той причине, что разграничение не поддерживают используемые клиентские программные средства. Выход здесь, конечно, только один – создавать условия для создания иерархии доступа к данным.

Ограниченные технические ресурсы

По словам Игоря Якобсона, другой частой проблемой администратора баз данных является несоответствие мощности «железа» программной части. У этой медали есть две стороны. Первая, когда невозможно оптимизировать быстродействие БД при ограниченных вычислительных ресурсах, то есть приходится «выжимать максимум на том, что есть». Вторая проблема заключается в настройке новых версий серверов БД под устаревшие клиентские технологии, модернизация которых не планируется из-за существенных трудозатрат на это. Рынок ИТ-услуг в России: оценки, тренды, крупнейшие участники. Обзор и рейтинг TAdviser 298.4 т

Безопасность

По оценке компании Forrester Research, на проблемы безопасности администраторы баз данных тратят лишь 7% своего рабочего времени. Базы данных оказались не защищены именно сегодня, когда хакеры в основном сосредоточили свои усилия не на дезорганизации корпоративных сетей и деловых операций компаний, а на краже конфиденциальных сведений. Ответственность за это несут все и в то же время никто. Хакеры всегда будут находить всё новые способы обойти системы безопасности..

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

Отсутствие контроля за резервным копированием

Предприятия тратят огромные средства на защиту своих наиболее важные БД. Однако часто можно видеть, что основная рабочая база данных сброшена на ленту, которая валяется на полу в комнате администратора. Выход здесь только один: строгий контроль со стороны ИТ-менеджера за соблюдением всех процедур и протоколов резервного копирования данных.

Отсутствие нагрузочных тестов

Ещё одна проблема состоит в том, что часто администратор промышленной системы не имеет возможности организовать полноценное нагрузочное и функциональное тестирование работы СУБД после внесения изменений в программно-аппаратную конфигурацию системы. Об этом рассказал Александр Циолковский, технический директор центра технической поддержки компании IBS Borlas.

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

Single point of failure

Есть и другие трудности, когда, например, администратор СУБД вынужден работать на системе, в которой есть известные «критические точки отказа» (single point of failure). Практика показывает, что если такое «узкое место» существует, то рано или поздно оно себя проявит, причём в самый неподходящий для бизнеса момент. Типичные примеры подобной проблемы - выход из строя «сверхнадёжного» RAID-контроллера единственной системы хранения или одновременная утрата основного дискового массива и комплекта резервных копий системы из-за протечки в системе кондиционирования.

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

Отсутствие взаимодействия с другими службами

Иногда производственная система эксплуатируется в условиях, когда не существует чётких регламентов взаимодействия между администраторами СУБД и смежных эксплуатационных подразделений, таких как отдел сетевой инфраструктуры, отдел разработчиков бизнес-приложений или отдел, отвечающий за эксплуатацию аппаратного обеспечения. «Мне приходилось наблюдать случаи длительного выхода из строя «идеальных» и многократно проверенных систем, которые произошли из-за подобной несогласованности», - говорит Александр Циолковский.

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