Рубрика «Admin»

C Днем Системного Администратора!

Сегодня, в последнюю пятницу июля, празднуется День Системного Администратора, с чем я и поздравляю всех причастных! Но кроме “первый тост за localhost”, есть в этот день и другие темы для разговоров и размышлений, и в первую очередь – кто такой системный администратор в современном мире.

На заре своей трудовой деятельности я даже не знал такого словосочетания – “системный администратор”. Были “программисты” и “инженеры-системотехники”, а также “техники”, “лаборанты” и прочая шушера. Системотехники как бы занимались железом, “программисты” – софтом, причем, не только разработкой, но и внедрением, настройкой, поддержкой…

На масс-рынке не было по сути такого понятия, как сервер: даже в очень крупных организациях зачастую инфраструктура строилась из того, что есть под рукой, да большего и не требовалось: интернет был по dialup, ну в лучшем случае какой-нибудь безмерно дорогой xdsl, оптика была только у немногочисленных НИИ… Да чего там говорить – 1с(будь она неладна) умела работать только в файловом режиме, никаких СУБД!

Да, был хостинг. Да, были провайдеры… Но видели бы вы, из какого говна и веток все это собиралось!!!

Время шло, железо дешевело, бизнес требовал все больше и больше сервисов. Инфраструктуры разрастались, иногда модернизировались, появлялись стартапы, хипстеры, облака… Многие пророчили смерть профессии админа, но все оказалось наоборот: если раньше каждый уважающий себя нувориш считал необходимым нанять пару “погромистов”, чтобы написать на Delphi или Visual Basic собственную систему складского учета, сайт на голом html(обязательно с анимированными рамками) и настроить доступ к persik.ru с компьютера хозяина, то теперь как таковые программисты в не-программерских конторах – исключение и пережиток лихих девяностых.

Зато системных администраторов, той или иной специализации и квалификации, можно встретить в любой конторе. Для совсем мелких фирм работают аутсорсеры и фрилансеры, крупные коммерческие структуры выделяют целые ИТ-департаменты.

Сложность новых программных продуктов и используемых технологий, необходимость быстро обновлять и удобно поддерживать продукты привели к формированию спорного подхода DevOps, основной посыл которого – избавиться от отмазки очередного “погромиста”, завалившего продакшн, “а на моем компе работало”. И тут админу, ну или дев-опсу, приходится уже не только разворачивать всякие докеры-куберы-ансиблы, но и периодически лазить в код и тыкать нерадивого разраба носом в кривые запросы. Не стоит забывать и о том, что сегодня ни один админ не может считаться таковым, если не автоматизирует хотя бы часть своей работы некими скриптами – PowerShell, bash, perl, Python стали такими же неотъемлимыми инструментами админа, как в свое время обжимные клещи.

“Ручной” же работы становится все меньше: есть монтажные организации, есть сервисные центры.

Таким образом, происходит естественное эволюционное развитие профессии – от “паяльщика” конденсаторов в БЭСМ к более плотной работе с кодом. Админ сейчас – даже круче, чем “программист” лет 20 назад. А программисты(ну если не считать за программистов писателей обработок для 1с) все больше отдаляются от пользователей, от мыслей о распределении ресурсов, уходят в свои абстрактные миры, и это на самом деле, наверное, хорошо.

Как бы то ни было, куда бы ни повернула кривая развития ИТ, но на сегодняшний день очевидно, что без системных администраторов обойтись в обозримом будущем не удастся. Никуда не пропадут начинающие на позициях эникеев и первой линии техподдержки, не исчезнут админы linux и windows-серверов, не обойдется этот мир без админов активного сетевого оборудования, да и программисты не откажутся от DevOps.

Так пусть каждый из нас каждый свой рабочий день приносит пользу не только конечным пользователям, но и себе: давайте развиваться, осваивать и внедрять новые технологии, использовать новые подходы и методы!

С праздником, Админы!

Как определить максимально дешевый маршрут звонка в Asterisk

Asterisk+Python: два метода определения самого дешевого маршрута для звонка

Недавно у моих коллег возникла задача – распределять исходящие звонки с Asterisk по транкам в соответствии с тем, чьему пулу принадлежит номер. В примитивной реализации достаточно просто добавить шаблоны телефонов по префиксам в маршруты FreePBX(927Х. – мегафон, 906Х. – билайн), однако, например, префикс 999 делят несколько операторов, а вообще в официальной таблице распределения DEF-номеров более 52 тысяч строк!

Основные критерии решения, которым хотелось бы следовать, были таковы:
1. Хочется получить совместимость не только с FreePBX, но и с чистым Asterisk, и любыми другими системами телефонии
2. Не хочется “ломать” логику диалплана FreePBX
3. Нужна простота настройки, так как заказ коммерческий, и нужно написать howto
4. Возможно, в будущем потребуется доработка, например, распределение исходящих звонков на городские номера в соответствии с регионом

Из вышесказанного следует, что:

1. Никакой работы с базой напрямую из диалплана
2. Изменения в диалплане должны быть минимальны, никаких extensions_override_freepbx
3. Кажется, пора расчехлять Python

Были разработаны две схемы: одна с использованием официального реестра распределения таблицы DEF-номеров от РосСвязьНадзора, вторая – с использованием API мегафона(единственный доступный публично), который легко может быть заменен на официальный API от оператора базы данных перенесенных номеров.

Первый вариант технически сложнее в реализации, и не учитывает номера, которые были переведены от оператора к оператору, но более надежный, быстрый и не зависит от проблем с каналом и сторонним API;

Второй, в свою очередь, более точный, учитывает перенесенные номера, но менее надежный и более медленный.

Суть реализации с точки зрения asterisk в разрезе FreePBX такова: в кастомном включении в from-internal вызываем скрипт, который по набранному номеру отдаст префикс, уникальный для каждого оператора, затем передаем звонок обратно на стандартное поведение FreePBX и настраиваем распределение по транкам на основе шаблонов маршрутов по префиксам. Для “чистого” asterisk достаточно просто добавить пару условных операторов для опредения алгоритма звонка по префиксу.

Для первого варианта бэкэнда, если так можно выразиться, связка получилась такая: один скрипт по расписанию стягивает(если получается) csv с сайта РосСвязьНадзора и парсит его в БД. Второй, вызываемый из астера, обращается к БД, находит название оператора по номеру и отдает префикс в соответствии с конфигурационным файлом.

Для второго все гораздо проще – просто обращаемся к API GET-запросом, получаем json, из которого берем код оператора по классификатору MNC, и уже его отдаем в asterisk.

Листинги обоих реализаций и более подробное описание смотрите по ссылкам.

Через CSV

Через API