В далеком 1986 году братья-программисты из Пакистана Амджат и Базит Алви разработали первую в истории вирусную программу для PC. Вирус назывался The Brain и предназначался для борьбы с местными пиратами, воровавшими написанные братьями программы. В коде The Brain можно было найти имена авторов и их домашний адрес. Отличная традиция тех времен, жаль, что современные вирусописатели от нее отказались....(read more)

Я хочу поделиться с вами моим опытом по настройке системы регистрации и обработки заявок Atlassian JIRA, совместно с Atlassian Confluence в качестве системы тех. поддержки пользователей. Что пишут Atlassian по поводу этого можно почитать тут: http://confluence.atlassian.com/display/JIRA/JIRA+as+a+Support+System

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

На рынке представлено более сотни продуктов для огранизации системы поддержки пользователей. Из известных — OTRS, Request Tracker, Kayako, HP Open View — некоторые уже обсуждались на Хабре. Насколько они подходят именно для ваших задач?

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

А попросту, они готовы раздавать ваш статический контент.
Трафик нужно посылать через ghs.google.com.
Там есть маленькая анкетка (google docs), можно оставить свой е-майл и название домена.
Я пока что никакого ответа не получил.

P.S. у меня по ссылке отрывается только английский вариант.
Документация: http://code.google.com/intl/ru/speed/pss/docs/overview.html

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

Еще в начале 80-х комитет ISO выделил основные компоненты системы управления сетью. Модель получила название FCAPS. По версии ISO, для успешного управления сетью надо уметь управлять отказами (F), конфигурацией оборудования и сервисов (C ), собирать и обрабатывать статистику по потреблению услуг (A), оценивать производительность (P) и централизованно управлять безопасностью (S). Прошедшие три десятка лет не добавили ничего принципиально нового, и все задачи управления сетью так или иначе прыгают вокруг основных составляющих.

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