Порядка 600 операторов в 4 странах, обрабатывающих звонки клиентов на американские (и немного на российские) номера.
Примерно 200 одновременных разговоров в пиковое время.
Примерно 15 000 звонков в день.
Возможность за несколько минут масштабировать это решение в несколько раз (по нашим прикидкам до ~1000 параллельных звонков, прежде чем начнутся проблемы).

Ну и конечно же, плотная интеграция с внутренними системами (CRM, сопровождение покупок, приоритеты операторов и клиентов и много-много других плюшек).

Кому интересно как это это работает и почему именно так — добро пожаловать

В среднем по статистике, в начале каждого месяца у 1-2 клиентов среднего оператора возникает ситуация. К ним приходит понимание — попали на деньги. Почему вначале месяца? В это время операторы печатают и отправляют счета клиентам за прошедший месяц.

Безопасность Asterisk обсуждается всеми, кто знает правильное написание этого слова. Хочется еще раз поднять вопрос безопасности в VoIP сетях, на этот раз со стороны работника SIP оператора, возможно, это близко к истине.

Обычно VRF (Virtual Routing and Forwarding, VPN Routing and Forwarding) используется совместно с MPLS, но без оной в терминологии Cisco называется VRF-Lite. Суть этой технологии в том, что маршрутная информация, принадлежащая различным классам (например, маршруты одного клиента) изолируется друг от друга. Считается, что такие возможности есть только у «взрослых» железных решений, но это не совсем так. Благодаря наличию множественных таблиц маршрутизации, гибких политик маршрутизации всё это можно сделать и в Linux. Кому интересно, добро пожаловать под кат.

Иногда мне приходится сталкиваться с заменой корневой файловой системы. Имея загрузочный диск и доступ к серверу, это не сложно. Однако, я хочу поделиться опытом замены корневой ФС удаленно, через ssh, без перезагрузки.

Причины для замены коневой ФС бывают разные:

• перевод / в LVM
• перевод / в mdraid
• замена типа файловой системы (ext3 => btrfs)
• уменьшение размера ФС (resize2fs)

Дружим между собой Active Directory, сервер IP телефонии Asterisk и Jabber-сервер OpenFire.

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

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

Долго думал в какой блог запостить и решил, что здесь ему наиболее подходящее место. Хотя бы потому, что основная идея топика «sh — может все».

В этом топике задали интересную тему — реализовать IVR для * с использованием синтезатора из Google Translate.

Я в общем то даже не планировал этим заниматься, но мне стало интересно.

Вы наконец-то можете сделать кое-что со своим старым LCD монитором, который завалялся у Вас в гараже. Превратите его в шпионский монитор! Для всех вокруг он будет выглядеть просто белым экраном, но не для Вас, потому что у Вас будут специальные «волшебные» очки.

Всё что Вам нужно – это пара старых очков, нож для бумаги и растворитель для краски.

Большинство системных администраторов в своей корпоративной среде для обеспечения системы идентификации и доступа своих пользователей к ресурсам предприятия используют доменные службы Active Directory, которые смело можно назвать сердцем всей инфраструктуры предприятия. Как многие из вас знают, структура доменных служб в организациях может включать в себя как один, так и несколько лесов (набор доменов, включающих описание сетевой конфигурации и единственный экземпляр каталога), в зависимости от таких факторов как ограничение области доверительных отношений, полное разделение сетевых данных, получение административной изоляции. В свою очередь, каждый большой лес для упрощения администрирования и репликации данных должен разделяться на домены. В каждом домене для управления доменными службами и выполнения таких задач как проверка подлинности, запуск службы «Центр распределения ключей Kerberos» и управления доступом используются контроллеры домена. А для управления сетевым трафиком между офисами разрабатываются сайты.

IP-телефоны от Cisco, например, популярный 7911G (на анигифе именно он) и более старшие модели, поддерживают возможность выполнения http-запросов для создания сервисов, в частности, телефонного справочника организации.

Как всё это работает. Мы настраиваем скрипт на веб-сервере, которых в ответ на GET-запрос от телефона возвращает строго определённый XML, отображаемый телефоном. Для телефонной книги сначала отображается список отделов:

<CiscoIPPhoneMenu>
<MenuItem>
  <Name>Administration</Name>
  <URL>http://webserver/phone/telbook.asp?depid=10</URL>
</MenuItem>
</CiscoIPPhoneMenu>

При выборе отдела телефон делает второй запрос по адресу из URL и отображает уже список сотрудников и их телефонов.
Вот картинка и пример структуры для списка из официального хелпа:

<CiscoIPPhoneDirectory>
  <Title>Заголовок</Title>
  <Prompt>Подсказка/подзаголовок</Prompt>
  <DirectoryEntry>
    <Name>Имя</Name>
    <Telephone>Телефон</Telephone>
  </DirectoryEntry>
</CiscoIPPhoneDirectory>

Со стороны администратора телефонов требуется прописать вызов нашего скрипта при нажатии какой-то из клавиш или выборе пункта меню, конкретно с 7911G мы используем Application->Help.

Перед системным администратором порой стоит задача установить или обновить приложения на множестве ПК. И часто проблема состоит не в выборе средства доставки и автоматической установки — их есть множество на любой вкус, от встроенных в Windows OS (Active Directory) до полноценных Configuration Management систем, таких как MS SCCM, Enteo NetInstall, LanDesk Management Suite, HP Application Deployment Manager, IBM Tivoli Provisioning Manager, ManageEngine Desktop Central и много других…

Идея написать статью о примере реализации связки cisco + tac_plus возникла спонтанно, когда глядя на конфиг tac_plus'а понял, что уже не помню что, а главное зачем, я там писал несколько лет назад. Объединить накопленный опыт, набитые шишки, бессонные ночи и шаманские пляски в эдаком мини-howto, который можно будет доработать до рабочей инструкции обязательной для прочтения новому сотруднику и может оказаться полезен кому-нибудь ещё (по моему мнению наступать на описанные грабли можно либо из практического интереса, либо находясь в глубокой депрессии/приступе мазохизма). Ну и с целью разнообразить число статей в русскоязычной части интернета. Но самое главное – это понять, что выбранное направление ведет/не ведет в тупик, либо уважаемое сообщество может подсказать другие решения и подкрепить их собственными примерами.

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