На тему “искусства программирования” написано множество книг. Но я почти не встречал на просторах интернета литературы об “искусстве системного администрирования” (а кто-нибудь встречал?). Почему-то принято считать, что админ - это такой бородатый ленивый чудак, который живет со своим “сервером” в гражданском браке, а спит вот с этим. Люди считают, что админ - это мастер на все руки: он и принтер заправит, и антивирус настроит и сервер поднимет. Только это не админ ни разу, а эникейщик. И таких, имхо, нужно гнать из отрасли и прямиком на биокомпост (отголоски Дани в моем мозгу...).
На самом же деле, грамотное системное администрирование - это такое же искусство как и программирование, в котором есть свои приемы, паттерны, и при этом, они очень часто пересекаются по смыслу с приемами, используемыми программистами. Сегодня речь пойдет о таком важном понятии в администрировании, как “мониторинг” и его связи с unit-тестами.
Как программисты пишут свой код? Нет, неправильный вопрос... Как хорошие программисты пишут свой код? - уже лучше ;-). Хорошие программисты используют unit-тесты. Не важно, пишут ли они их придерживаясь TDD, или делают неполное покрытие, важно лишь то, что тесты есть, и они позволяют безболезненно проводить рефакторинг (что на мой взгляд является ключевой задачей unit-тестов), не говоря уже об отлове багов. Особенно важны unit-тесты при работе в команде, где каждый участник работает над своей частью проекта.
Теперь взглянем на системных администраторов. Их основная задача - поддержка инфраструктуры, обеспечивающей функционирование программных продуктов. Но ведь системные администраторы тоже люди и они, как и все люди, допускают ошибки, как при первичном построении инфраструктуры, так и при ее рефакторинге. Программистам в отлове ошибок, как упоминалось выше, помогают unit-тесты. А что придет на помощь админам? И здесь на сцену выходит мониторинг.
Мониторинг - это не просто механизм слежения за инфраструктурой серверов, но и средство отлова ошибок, допускаемых системными администраторами. И здесь вполне применим прием из программирования, называемый TDD (Test Driven Development), который для администраторов можно перефразировать как MDD (Monitoring Driven Deployment). Т.е. перед тем, как на подконтрольных серверах запустить инстанс сервиса, мы настраиваем мониторинг того, что порт сервиса доступен, что на этом порту запущен нужный нам сервис, и получаем список предупреждений в интерфейсе системы мониторинга. По мере запуска сервисов на серверах список предупреждений должен опустеть. Таким образом мы делаем полное покрытие нашей инфраструктуры. Чем лучше покрытие мониторингом, тем быстрее вы обнаружите проблему.
Самое интересное, что администраторам в плане MDD очень повезло. Большая часть покрытия мониторингом почти всегда однотипна, поэтому она легко и просто реализуется при помощи шаблонов. Здесь я всем хочу порекомендовать Zabbix - очень хорошая система для мониторинга IT-инфраструктуры предприятия. Правда у нее есть один большой недостаток - производительность базы данных. При больших объемах данных (десятки тысяч узлов сети с десятками параметров для отслеживания) происходит падение производительности базы данных. Во многом это связано со структурой запросов к базе данных. Так что при высоконагруженном мониторинге будьте готовы лезть в недра Zabbix для оптимизации, либо выбирать иную систему контроля, заточенную под ваши нужды.
В заключении же хочется добавить, что наиболее хорошей устойчивости инфраструктуры вы добьетесь в том случае, если обзаведетесь отделом мониторинга, который подобно тестировщикам в программировании будут вылавливать баги у админов при помощи средств мониторинга.
Комментариев нет:
Отправить комментарий