Просмотр Исходного

{toc}

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

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

h1. Мониторинг

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

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

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

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

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

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

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


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

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

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

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

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

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

Наиболее актуальный источник информации - [раздел "блог" на сайте CarbonSoft|https://www.carbonsoft.ru/category/products/reductor/].

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

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



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


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



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

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

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

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

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

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

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

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