Я хотел бы обратить внимание коллег сисадминов, а также тех, кто принимает их на работу, на два диаметрально противоположных подхода к системному администрированию. Мне кажется, понимание разницы между этими подходами может значительно уменьшить взаимное разочарование обеих сторон.

Вроде бы ничего нового, но за те почти 15 лет, что я связан с этой темой, я столько раз был свидетелем проблем, недоразумений и даже конфликтов, связанных с непониманием или нежеланием понимать разницу между этими двумя подходами, что похоже стоит лишний раз поднять тему. Если вы сисадмин и на работе вы не в своей тарелке или если вы руководитель, берущий на работу сисадмина — возможно эта статья как раз для вас.

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

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

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

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

Возможно очередной велосипед, но раньше не попадалось. Если идея окажтся жизнеспособной, может кто и реализует — тогда не пропадёт впустую, самому, к сожалению, некогда, хоть и очень хочется попробовать. Если это уже где-то реализовано — прошу строго не судить: сам на вскидку не нашёл, а на долгие поиски сейчас ну совсем времени нету.

Итак, в кратце:

Стояла задача: в цикле, из скрипта на php5 зайти по ssh на Mikrotik, сгенерировать скрипт с текущим конфигом, забрать скрипт на некое локальное хранилище. И так для ~500 роутеров. Так как в провайдерских кругах микротик весьма нередкий зверь — думаю кому-то ещё может пригодиться.

Так как глубоких познаний в тонкостях реализации ssh2 на микротике, в пхп, да и вообще — не имею, а сроки сильно ограничены, встретившиеся проблемы решал подручными средствами и инструментами, особо не заботясь об «элегантности».

В процессе обнаружилось следущее:

Вот уже пару лет читаю хабр. Почти полтора месяца являюсь полноправным хабравчанином. И вот на днях я задумался: За что я ставлю плюсы? За что ставлю минусы? За что плюсую/минусую карму? Когда коментирую? Что мной движет? А как это делают другие? Почему? Стал наблюдать, спрашивать друзей и знакомых. У двоих знакомых спросил, почему ничего почти не пишут на хабре — у них шикарные статьи в собственных блогах. Постепенно стала вырисовываться картинка, на мой взгляд не очень радужная, но такова уж жизнь. Возможно эта статья — хабрасуицид. Если так и окажется — хочу сразу поблагодарить тех, кто писал дельные коментарии к моим топикам (их не так уж и много), а особенно Cryptochild, за то что прочёл мою статью в песочнице, поверил в меня и дал инвайт.

Вопросы, вопросы, ответов нет, но есть размышления. Может уважаемые хабраземляки смогут ответить на них, может хотя бы задумаются сами, а может кто-то что-то поменяет. Если хоть пара человек задумается — уже хорошо.

Итак:

Наткнулся на такое вот видео:

Не очень понимаю суть процесса, но выглядит прелюбопытно. Особенно тот факт, что человеческое тело весьма сильно влияет на показания прибора. Кто-нибудь может просто на пальцах пояснить как это работает?

Понадобилось реализовать управление выдачей IP в сети одного провайдера, увязав его с системой учёта и прочими «фишками». В качестве DHCP сервера стоял ISC DHCP 4.x на 9-м Ubuntu Server'е.

Для DHCPd нужно было реализовать:

1. добавление новой статичной резервации (по маку либо порту свитча — опция 82),
2. «привязка» юзера с IP выданным динамически (то есть из пула свободных IP) в статичную резервацию
3. удаление статичной резервации
4. удаление динамической лизы до истечения срока резервации
5. Различные отчёты по подсетям, мак-адресам, свободным и занятым аресам

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

Искал способ быстрого поиска строки по нескольким подстрочкам. Наткнулся на сайт с подборкой описаний алгоритмов. Спешу поделиться — думаю многим может пригодиться. Сам завис там на пару часов.

Заодно вопрос к уважаемым Хабражителям: какой бы алгоритм Вы посоветовали бы для быстрого поиска записи (название) по нескольким фрагментам (отрывки слов в названии) расположенным в случайном порядке не так как в искомой записи.
Массив информации — около 1.5 миллионов записей, требуемая скорость — 300-1000 одновременных запросов в секунду на простом железе (не-супер-пупер-многопроцессорный вычислительный комплекс).

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

Может пригодится кому-то из сисадминов/сетевиков. Понадобилось замерить характеристики загруженного канала от провайдера, понять где проблема и, если действительно в канале, предоставить объективные данные для дальнейших разговоров с провайдером.

Канал гигабитный. Пиковые нагрузки, если верить роутеру, около 480Мбит / 70 000 пакетов/с. Пользователи жалуются что «подтормаживает» и что всяческие замерялки скорости доступные онлайн регулярно дают всякие ужасающие результаты.

Сделал пачку тестов разными онлайн Bandwidth Meter'ами и всякими утилитами. Первое, что бросилось в глаза — совершенно неправдоподобный разброс результатов. Мало того, что каждый инструмент давал свои «уникальные» результаты, так ещё и запуск одного и того же инструмента давал в корне различные результаты в течение нескольким минут. Как следствие — единственный вывод, который удалось сделать из этих замеров: все они врут, при чём врут не чуть-чуть, а на сотни процентов в плюс или минус.