декабрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

показать все 

13.12.2024

Рынку индустриального ПО нужна стратегия развития Итоги III Конференции по матмоделированию

Читать далее 

07.12.2024

Avanpost FAM/MFA+ стали еще безопаснее: вышла обновленная версия системы аутентификации

Читать далее 

07.12.2024

M1Cloud: Итоги 2024 года на российском облачном рынке

Читать далее 

06.12.2024

Действия сотрудников назвали главной причиной утечек информации

Читать далее 

06.12.2024

САТЕЛ представляет систему записи разговоров СИЗАР

Читать далее 

показать все 

12.12.2024

Что следует учитывать ИТ-директорам, прежде чем претендовать на должность генерального директора?

Читать далее 

11.12.2024

Сетевая инфраструктура, сетевые технологии: что лучше – самостоятельная поддержка или внешнее обслуживание?

Читать далее 

22.11.2024

Тандем технологий – драйвер инноваций.

Читать далее 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

показать все 

Главная / Архив номеров / 2011 / Выпуск №7 (10) / Поддержка системы 24х7. Организация круглосуточной работы ИТ-отдела

Рубрика: ИТ-инфраструктура

 Константин Кондаков, работает старшим директором по ИТ в сан-францисской фирме Certain Software, обеспечивает бесперебойную работу центров данных и руководит системными администраторами в США, Великобритании и Австралии

Поддержка системы 24х7
Организация круглосуточной работы ИТ-отдела

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

В наше время становятся редкостью фирмы, где информационные системы работают лишь в «часы работы банка», то есть с 9.00 до 18.00. С каждым днем растет число организаций, которые выходят в «онлайн» или (и) занимаются круглосуточной обработкой данных, часто в высоконагруженном режиме, а это значит, что ИТ-подразделения должны обеспечивать бесперебойную работу 24 часа в сутки, 7 дней в неделю, 365 дней в году без перерывов на Новый год или 9 Мая.

На Западе практикуется использование числа «девяток» для оценки доступности информационных систем [1], непрерывно работающих в течение календарного года.

Например:

• одна девятка – 90% – допускается недоступность систем 36,5 дня в году;
• две девятки – 99% – допускается недоступность систем 3,65 дня в году;
• три девятки – 99,9% – допускается недоступность систем 8,76 часа в году;
• четыре девятки – 99,99% – допускается недоступность систем 52 минуты в году;
• пять девяток – 99,999% – допускается недоступность систем 5 минут в году;
• шесть девяток – 99,9999% – допускается недоступность систем 31 секунду (!!!) в течение года, то есть на все профилактические работы требуется всего 31 секунда.

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

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

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

Общие архитектурные принципы бесперебойной системы

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

Самое общее правило здесь: в системе не должно быть ни одного «узкого места», неработоспособность которого означала бы отказ в обслуживании информационных систем.

Взять, к примеру, обычный бытовой компьютер. Может ли у него сгореть блок питания? Может! А может случайно выйти из строя сетевой адаптер? Тоже может! Про единственный жесткий диск говорить не будем – это, пожалуй, первый кандидат на выход. Понятно, что бытовые компьютеры для выполнения задач в круглосуточном и бесперебойном режиме использовать нельзя, хотя в некоторых фирмах они по каким-то причинам применяются именно для этого. К счастью, есть готовые решения для этой проблемы [2]. Как правило, надо закупать и конфигурировать должным образом две (а то и больше!) копии любого сетевого оборудования, ставить двойные базы данных, на каждом сервере должно быть больше одного источника питания. Причем важен не только факт физического наличия всего этого, но и правильная конфигурация, обеспечивающая бесперебойную работу. Например, сетевые адаптеры должны работать в режиме bonding (см. врезку).  Если используется SAN, надо установить как минимум два HBA-адаптера и настроить на них multipathing. Вся цепочка передачи информации «в» и «из» онлайна должна быть продублирована.

Вот, например, как это можно сделать на уровне «вход в сеть» (см. рис. 1) – при такой топологии, подсистема сообщения с Интернетом, спроектированная архитектором сетевых служб, сможет функционировать в случае выхода из строя любого элемента «цепочки».

Рисунок 1. Провайдер – Маршрутизатор – Брандмауэр – Свитч

Разумеется, что и все другие элементы информационной системы тоже должны иметь двойные или даже тройные «узлы» – например, подсистему хранения данных можно организовать, как показано на рис 2.

Рисунок 2. Организация подсистемы хранения данных

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

Что такое «сертификация промышленного уровня» для оборудования?

При выборе оборудования следует учитывать различные классы надежности. Если существует специальная сертификация на оборудование, способное бесперебойно работать длительное время в высоконагруженном режиме или хотя бы таблица от производителя [3], то их надо обязательно принять во внимание во время проектирования бесперебойной системы.

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

Такие системы никогда и никто не проектировал, не тестировал и не использовал для бесперебойной работы в 24-часовом режиме.

Например, бытовой маршрутизатор Cisco WN610 демонстрирует неплохие показатели для домашней компьютерной сети. Но я ни при каких обстоятельствах не стану его использовать в центре данных. Для этого предназначены устройства совсем другого класса: VXR 7206, ASR1001 и более дешевые модели, в которых есть как минимум возможность управления не из cистемной консоли, а из удаленного администрирования по резервной сети (Out of Band network). Понятно, что все подобного типа устройства имеют двойные источники питания.

Как организовать мониторинг?

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

• понять, какие системные параметры нужно мониторить;
• организовать процесс так, чтобы мониторинг и системы оповещения были доступны системным администраторам и чтобы кто-то правильно и своевременно реагировал на все «предупреждения», уж не говоря о ЧП.

Что же нужно мониторить? Это решается для каждого сервера и сервиса индивидуально, но правило простое: минимальный набор параметров, по которым можно понять, работоспособен ли сервер, и если нет, то что конкретно вышло из строя. Например, вот используемый мной (не претендую на истину в последней инстанции) список параметров (см. рис. 3) для мониторинга запасного сервера баз данных Oracle:

• Доступность по сети – ping.
• Доступность по сети – ssh.
• Состояние лог-файлов – NRPE log file check.
• Состояние подсистемы Oracle – NRPE – Oracle CPU.
• Общее «здоровье» сервера – memory, cpu, disk space.
• Сервис – NRPE.

Рисунок 3. Список параметров для мониторинга запасного сервера баз данных Oracle

Понятно, что мало просто «облепить датчиками» все нужные серверы, необходимо еще сделать так, чтобы кто-то постоянно следил и действовал в случае каких-нибудь отклонений от нормы. Если в будни системные администраторы могут «посматривать» на вверенные им системы мониторинга – Nagios [4] , Cacti [5], Ganglia, Munin, то что делать в 4 часа утра? Есть несколько решений, имеющих свои доводы «за» и «против».

Решение 1

Организовать службы «автоперезапуска» и «действия по условию», используя известные возможности cfengine, Daemontools [6], Nagios event-handler [7].

Например, Nagios event-handler – самостоятельно запускает команды в случае обнаружения каких-то условий (events). Daemon tools – инструментарий для работы с сервисами Линукс, которые всегда должны функционировать. Он будет перезапускать, например, «случайно остановившийся» Apache веб-сервер столько, сколько нужно:

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

Решение 2

Организовать работу сисадминов в три смены:

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

Решение 3

Аутсорсинг. Большое количество фирм специализируется на оказании услуг по круглосуточному мониторингу систем клиента. В случае ЧП они могут не просто оповестить системных администраторов (Kailea Networks), но и сделать какие-то согласованные с ними восстановительные работы (OpSource) исходя из оговоренных правил реагирования на предупреждения.

Например, если на запасном сервере баз данных Server2 индикатор загрузки Oracle начал выдавать предупреждения в субботу в 3 часа утра, временно выключить этот индикатор до 8.00 понедельника. Это не критично. Администратор посмотрит, что там произошло, в рабочее время. Если же сервер Server2 перестал отвечать по сети, срочно связаться с дежурным системным администратором в любое время дня или ночи. В случае недоступности дежурного системного администратора оставить сообщения, но продолжать звонить ВСЕМ системным администраторам в списке до тех пор, пока кто-то из них не ответит:

«За» – подобные решения универсальны и повсеместно применяются в США. Заключается договор с аутсорсером, в котором оговариваются способы и механизмы реагирования на те или иные системные ошибки и предупреждения. Иногда фирма-аутсорсер приносит свое устройство для мониторинга систем заказчика и просит выделить единственный внешний IP-адрес и разрешить трафик наружу с него. В других случаях для сторонних админов делают ограниченный набор команд, которым управляют из /etc/sudoers.

В частном случае это может выглядеть примерно так:

User_Alias OPSOURCE_USERS=jcustodi,vrangappa,ddeb,dtran
# things that are ok on any box
OPSOURCE_USERS ALL = (root) /usr/pkg/adm/sbin/*
OPSOURCE_USERS ALL = (lksm) /usr/pkg/adm/sbin/*
OPSOURCE_USERS ALL = (root) /etc/init.d/* *
OPSOURCE_USERS ALL = (root) /etc/rc?.d/*
OPSOURCE_USERS ALL = (root) /prod/common/psr-lite/bin/*
OPSOURCE_USERS ALL = (root) /prod/pagecomp/bin/*
OPSOURCE_USERS ALL = (root) /prod/common/prodScripts/bin/*
OPSOURCE_USERS ALL = (root) /bin/ls
OPSOURCE_USERS ALL = (root) /bin/touch
OPSOURCE_USERS ALL = (root) /sbin/mount
OPSOURCE_USERS ALL = (root) /sbin/umount
OPSOURCE_USERS ALL = (root) /usr/sbin/cfrun
OPSOURCE_USERS ALL = (root) /usr/pkg/cfengine/sbin/cfrun
OPSOURCE_USERS ALL = (root) /usr/sbin/cfagent
OPSOURCE_USERS ALL = (root) /var/cfengine/bin/cfagent
OPSOURCE_USERS ALL = (root) /usr/pkg/cfengine/sbin/cfagent
OPSOURCE_USERS ALL = (root) /usr/local/bin/lmutil
OPSOURCE_USERS ALL = (root) /usr/bin/kill
OPSOURCE_USERS ALL = (root) /bin/kill
OPSOURCE_USERS ALL = (root) /usr/bin/pkill
OPSOURCE_USERS ALL = (root) /usr/local/bin/svstat
OPSOURCE_USERS ALL = (root) /usr/local/bin/svc
OPSOURCE_USERS ALL = (root) /bin/rm /var/cfengine/cfengine_lock_db
OPSOURCE_USERS ALL = (root) /bin/rm /var/cfengine/ppkeys/root-*.pub
OPSOURCE_USERS ALL = (root) /bin/rm /usr/pkg/snmp/var/msg/*
OPSOURCE_USERS ALL = (root) /bin/rm /usr/pkg/nagios-plugins/var/msg/*
OPSOURCE_USERS ALL = (root) /bin/mv /usr/pkg/snmp/var/msg/*/tmp/
OPSOURCE_USERS ALL = (root) /bin/mv /usr/pkg/nagios-plugins/var/msg/* /tmp/
OPSOURCE_USERS ALL = (root) /usr/bin/rm /usr/pkg/snmp/var/msg/*
OPSOURCE_USERS ALL = (root) /usr/bin/rm /usr/pkg/nagios-plugins/var/msg/*
OPSOURCE_USERS ALL = (root) /bin/cat /var/log/*
OPSOURCE_USERS ALL = (root) /bin/cat /usr/pkg/snmp/var/msg/*
OPSOURCE_USERS ALL = (root) /bin/cat /var/adm/*
OPSOURCE_USERS ALL = (root) /bin/cat /var/adm/syslog/*
OPSOURCE_USERS ALL = (root) /bin/cat /var/cfengine/

Но самое большое преимущество подобного решения – «аутсорсинг круглосуточной поддержки» – это то, что ИТ-директору не нужно думать, сколько человек нанять для 24х7 поддержки, как организовать их отпуска, что делать с больничными и т.д. Покупается решение «под ключ», а как оно организовано изнутри – это уже проблемы аутсорсера;

«Минусы» – самым большим минусом подобного подхода, как, впрочем, и общим минусом при работе с любыми аутсорсерами [8], является то, что они не являются штатными сотрудниками фирмы.

Обычно подобные 24х7 «диспетчеры» обслуживают несколько десятков фирм, реагируя тем или иным образом на все отклонения от «статус-кво» функционирования сервисов. Понятно, что разбираться в архитектуре системы, не говоря уже о каких-то тонкостях, у подобных служб нет ни времени, ни возможностей. Соответственно и реагирование на ситуацию происходит медленнее, ведь некоторое время диспетчеру придется потратить на то, чтобы оценить ситуацию.

Отсюда следует, что при работе с подобными службами надо обязательно четко прописать, когда и при каких условиях звонить дежурному системному администратору.

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

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

С другой стороны, если почему-то забарахлила подсистема почты, то можно просто удаленно перестартовать этот сервис, отметив сбой в журнале и послав уведомление о проделанной операции.

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

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

О человеческом факторе

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

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

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

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

Вот примерные вопросы, на которые ИТ-руководитель должен дать честные и развернутые ответы (а не выдавать желаемое за действительное):

• Какая общая архитектура системы, и насколько она соответствует бизнес-задачам фирмы?
• Какие стоят текущие и стратегические задачи?
• Какие случались (случаются) авралы и внеплановая работа?
• Каков в среднем объем работы у отдела и ИТ-руководителя в течение дня, недели? (Например, первое срочное письмо приходит в 6 часов утра, а последнее в 23.45.)
• Какими человеческими ресурсами располагает отдел?
• Каков ИТ-бюджет?
• Какие сроки на различные проекты?
• Какие есть сильные и слабые стороны системы?
• Какие существуют угрозы и надвигающиеся аварии? (Например, если не заменить сервер баз данных в течение месяца, то «все рухнет».)
• Какие возможности можно и нужно использовать для развития?
• Что покажет успех или неудачу?

Более-менее надо определиться и со штатным расписанием. К сожалению, тут нет и вряд ли будет какое-то точное соответствие количеству ИТ-систем, а также их сложности необходимому числу сотрудников. Но какие-то самые общие принципы все же существуют.

Например, если есть более 5-10 серверов баз данных и репликация, а также запасной сервер базы банных, то требуется администратор баз данных как штатная единица. При сетевой архитектуре, в которой задействовано свыше 10?20 коммуникационных устройств (брандмауэры, маршрутизаторы и т.п.), в которых требуется делать более-менее регулярные конфигурационные изменения (сменить права доступа ACL, поменять VLAN), нужен инженер по сетевому оборудованию. Есть мнение, что требуется выделенный системный администратор в расчете один человек на 50 серверов, но это достаточно условное предположение. Я сталкивался с ситуациями, когда четыре администратора едва справлялись с проблемами в организации, где было всего 40 серверов. А при правильно организованной политике автоконфигурации средствами (Red Hat/CentOS kickstart, Solaris/Jumpstart, Linux Debian /FAI) и использовании средств типа CFEngine, Puppet, Chef можно организовать работу нескольких сотен, даже тысяч серверов усилиями трех – пяти штатных системных администраторов.

Есть и еще один момент. Нельзя забывать о том, что системные администраторы – это тоже люди, у которых есть жизнь за пределами работы и которые в отличие от программ, работающих на серверах, могут совершать ошибки, делать неверные выводы и нуждаются в отдыхе, сне, а также в элементарном уважении. Поэтому, когда ИТ-директор по привычке назначает «сегодняшние профилактические работы на 20.00», забывая, что подчиненная ему команда находится на работе с 8.00, а старший системный администратор еще и должен дежурить в ночную смену, то он, мягко говоря, поступает недальновидно.

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

Понятно, что этот вопрос как ИТ-руководитель, так и системный администратор решают строго индивидуально исходя из своих текущих приоритетов. «Системный администратор» в 2010 году опубликовал целый ряд статей в цикле «Уйти или остаться?» [9] , поэтому здесь повторяться я не буду.

В конце хотелось бы сопоставить проблему ненормированного рабочего дня системных администраторов и круглосуточной поддержки вверенной информационной системы.

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

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

Обычно считается допустимым пределом, если дежурный системный администратор отвечает за ночные авралы одну неделю в течение месяца, а то и реже.

То есть в эту «черную неделю» он должен быть доступен 24х7 – ни ночных сеансов, ни вечерних посиделок с друзьями, мобильный телефон вечером под рукой, а ночью возле подушки. Поэтому, если у клиента или на потенциальной новой работе я вижу, что требуется поддержка системы 24х7, обязательно досконально выясняю, что конкретно за этим стоит, насколько все стабильно, сколько людей (и кто) поставлены на эту задачу, а также какие были внеплановые ЧП за последний месяц. Это особенно важно, так как в одних местах ЧП случаются раз в год, когда оказывается перерезанным оптико-волоконный кабель по вине строительной компании, а в других ночные авралы с полной потерей обрабатываемых файлов могут происходить разок-другой в неделю.

Никогда не следует забывать, что потерянное личное время, а часто и здоровье из-за того, что база Oracle накрылась медным тазом в пятницу в половине первого ночи, вам никто не вернет.

***

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

• John Allspaw, Jessie Robins. Web Operations. – O’Reilly, 2010.
• Mauricio Arregoces, Data Center Fundamentals. – Cisco Press, 2003.
• Список «сертифицированных» жестких дисков от фирмы Coraid – http://support.coraid.com/support/sr/disks.html.
• Бешков А. Осваиваем Nagios. //«Системный администратор», №12, 2003 г. – С. 48-61 (http://samag.ru/archive/article/218).
• Яремчук C. Cacti – простой и удобный инструмент для мониторинга и анализа сети. //«Системный администратор», №4, 2007 г. – С. 22-27 (http://samag.ru/archive/article/1770).
• Daemon Tools – http://cr.yp.to/daemontools.html.
• Обработчик событий (event handler) Nagios – http://nagios.sourceforge.net/docs/3_0/eventhandlers.html.
• Кондаков К. Что выгоднее: аутсорсер или свой специалист? //«Системный администратор», №12, 2010 г. – С. 106-109 (http://samag.ru/archive/article/1043).
• Мышкин Л. Уйти или остаться? Закулисные проблемы системных администраторов. //«Системный администратор», №4-6, 2010 г. (цикл статей).

В начало⇑

Комментарии отсутствуют

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