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

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

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

Как всё начиналось

Идея создания сервиса подбора имён и названий — нейминг сервиса — витала у меня в голове достаточно давно, но свободного времени для её реализации всё не находилось и не находилось. Не то что бы это была сверх новая идея, нет. Подобные сервисы представлены в интернете, не сказать, что достаточно широко, но свою малую нишу они прочно заняли. Глядя на аналоги хотелось сделать что-то лучше, и размяться в разработки сайта с нуля на новой платформе.

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

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

Поначалу я хотел придерживаться буквально академической точности в составлении проектной документации, чуть ли не прямого селдования ГОСТ-ам, но вскоре отаказался от этой затеи, и решил не бросаться из крайности в крайности, а сделать всё по уму, но без перегибов. Всё таки для себя делаю.

Приветствую!
Думаю, большинство разработчиков Django слышали о Celery — системе асинхронного выполнения заданий, а многие даже активно её используют.

Около года назад на хабре была довольная хорошая статья, рассказывающая о том, как использовать Celery. Однако, как было упомянуто в заключении, уже вышла Сelery 2.0 (на данный момент стабильной версией является 2.2.7), где интеграция с django была вынесена в отдельный пакет, а также произошли другие изменения.

Данная статья будет полезна прежде всего новичкам, которые начинают работать с Django, и им требутся что-то, способное выполнять асинхронные и/или периодические задания в системе (например очистку устаревших сессий). Я покажу как установить и настроить Сelery для работы с Django от начала до конца, а также расскажу про некоторые другие полезные настройки и подводные камни.

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

В проекте панели управления хостингом, разработкой которой я занимаюсь значительную часть времени своей работы в NetAngels, насчитывается 120 таблиц и при тестировании загружается порядка 500 объектов из fixtures. Нельзя сказать, что это пугающе много, однако создание всех таблиц, добавление индексов и загрузка объектов при каждом запуске теста довольно сильно напрягают, особенно, если запускается всего один или пара тестов.

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