Установка и первичная настройка

1. Устанавливается платформа для Carbon Reductor, сейчас - CentOS 6.
2. Устанавливается пакет Carbon Reductor
3. Запускается мастер настройки
   1. Сервер регистрируется и активируется
   2. Определяются источники списков для блокировки
   3. Выбираются способы фильтрации трафика
   4. Настраивается захват зеркала трафика
4. Изменения настроек применяются, тестируются
5. Фильтрация начинает работать
6. Настраиваются дополнительные опции для более комфортного использования продукта

Мониторинг

Сервер с Carbon Reductor - активный участник обработки трафика пользователей. Поэтому его состояние необходимо отслеживать постоянно.

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

Основная задача - отслеживать состояние сетевых интерфейсов (объём трафика, ошибки обработки пакетов), нагрузку на ядра процессора, состояние HDD, использование оперативной памяти, да и вобщем - доступность сервера с Carbon Reductor'ом.

Возможно использование системы проверки качества фильтрации "Carbon Reductor Satellite" в качестве агента для различных систем мониторинга. Его же можно использовать в качестве "тестовой машины" для воспроизведения проблем при отладке.

По умолчанию на Carbon Reductor включен сбор информации об обнаруженных диагностикой ошибках. Это нужно чтобы мы могли оперативно реагировать на массовые проблемы, в том числе имеющие внешние причины.

Наша система мониторинга автоматически создаёт задачи в HelpDesk об обнаруженных проблемах для пользователей с активной подпиской, но полагаться только на неё - не самая лучшая идея.

Требуется настроить отправку уведомлений от Carbon Reductor на почту системным администраторам (указав их e-mail адреса).

Чем раньше будет выявлена проблема, тем быстрее её можно будет устранить!

Эксплуатация

Мы стараемся изо всех сил, чтобы Carbon Reductor был "чёрным ящиком", который установил и забыл.

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

Также иногда начинает требоваться интеграция Carbon Reductor с другими узлами сети провайдера, например маршрутизаторами или DNS-серверами (зависит от нюансов в схеме сети).

Поэтому необходимо следить за новостями о Carbon Reductor, мы стараемся уведомить о таких требованиях хотя бы за одну неделю.

Наиболее актуальный источник информации - раздел "блог" на сайте CarbonSoft.

Документация, HelpDesk. Решение проблем.

• Имеется обширная документация в которой рассмотрены 95% возникающих проблем.
• Имеется хелпдеск, это основной канал связи с технической поддержкой.
• Для оперативного решения вопросов специалисты Carbon Soft могут использовать телефонные звонки, Skype, ICQ.
• Для решения некоторых вопросов могут привлекаться разработчики.

С какими вопросами обычно сталкивается техническая поддержка:

• Интеграция Carbon Reductor в сеть провайдера, в том числе для демо-версии для тестирования.
• Возникли вопросы по функциональности, настройкам, особенностям итд.
• Перестало фильтроваться вообще или только часть, при этом никаких подозрений системами мониторинга и диагностики не находится.
• Нужна помощь в оптимизации настроек оборудования (или определении его как не подходящего под системные требования).

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

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

Периодические обновления

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

По умолчанию у Carbon Reductor включено автоматическое обновление, противная ситуация чревата пропусками в фильтрации некоторых новых ресурсов из реестра РКН.

Версионность

"мажорная версия" . "релиз" . "минорная версия" - "билд"

1. Билды - небольшие исправления/дополнения, новые утилиты для облегчения работы технической поддержки - обычно раз в 2-3 дня.
2. Минорные версии - исправления/доработки модулей фильтрации, оптимизации - обычно раз в неделю.
3. Релизы - все накопленные изменения, сопровождаются описанием в блоге - раз в месяц.
4. Мажорные версии - крупные изменения существующих подсистем, новые модули - раз в 3-10 месяцев.
5. Критические исправления - обновление необходимое всем в самые короткие сроки. Проверка его наличия включена раз в час.