... # Устанавливается платформа для 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, мы стараемся уведомить о таких требованиях хотя бы за одну неделю.
Наиболее актуальный источник информации - [твиттер-аккаунт|https://twitter.com/carbon_reductor] разработчиков Carbon Reductor.
h1. Документация, HelpDesk. Решение проблем.
* Имеется обширная документация в которой рассмотрены 95% возникающих проблем.
* Имеется хелпдеск, это основной канал связи с технической поддержкой.
* Для оперативного решения вопросов специалисты Carbon Soft могут использовать телефонные звонки, Skype, ICQ.
* Для решения некоторых вопросов могут привлекаться разработчики.
С какими вопросами обычно сталкивается техническая поддержка:
* Интеграция Carbon Reductor в сеть провайдера, в том числе для демо-версии для тестирования.
* Возникли вопросы по функциональности, настройкам, особенностям итд.
* Перестало фильтроваться вообще или только часть, при этом никаких подозрений системами мониторинга и диагностики не находится.
* Нужна помощь в оптимизации настроек оборудования (или определении его как не подходящего под системные требования).
Иногда в ходе поиска источника проблемы оказывается, что он в коде, то есть на нашей стороне.
В таких случаях проблема исправляется и обкатывается совместно с разработчиком, затем исправление попадает в следующую версию продукта.
h1. Периодические обновления
В виду того, что технологии и законодательные требования к провайдерам не стоят на месте, учесть всё заранее невозможно, иногда требуется рефакторинг, мы активно работаем над тем, чтобы фильтрация работала на 100% всегда.
По умолчанию у Carbon Reductor включено автоматическое обновление, противная ситуация чревата пропусками в фильтрации некоторых новых ресурсов из реестра РКН.
h2. Версионность
"мажорная версия" . "релиз" . "минорная версия" - "билд"
# Билды - небольшие исправления/дополнения, новые утилиты для облегчения работы технической поддержки - обычно раз в 2-3 дня.
# Минорные версии - исправления/доработки модулей фильтрации, оптимизации - обычно раз в неделю.
# Релизы - все накопленные изменения, сопровождаются описанием в блоге - раз в месяц.
# Мажорные версии - крупные изменения существующих подсистем, новые модули - раз в 3-10 месяцев.
# Критические исправления - обновление необходимое всем в самые короткие сроки. Проверка его наличия включена раз в час.
|
