Работы из эксплуатации, описанные по одной схеме: исходное состояние, что было сделано, измеримый результат. Клиенты не называются, имена узлов и номера в публикацию не выносятся.
Числа в кейсах взяты из систем заказчиков и приведены к агрегатам. Графики и схемы построены на этих же данных.
Заказчик попросил простой веб-интерфейс, чтобы слушать записи разговоров и смотреть детализацию. Пока разворачивали — обнаружили, что на станции четыре месяца не пишутся журналы, 10 ГБ диска заняты невидимым файлом, защита SSH от подбора паролей не срабатывала ни разу, а средства автоматизации вообще не могли зайти. Ни один из отказов не сообщал об ошибке.
На АТС кончалось место: df показывал 27 ГБ занято из 30, а подсчёт всех файлов давал только 17 ГБ. Разбираем, почему возникает такое расхождение, как найти виновника через lsof и как невидимая опечатка в настройке ротации логов на четыре месяца лишила сервер и места, и журналов.
Разбор CDR колл-центра заказчика: почему статус «отвечено» вводит в заблуждение, как по длительности звонка отсечь «ложные» отвеченные (эхо автосекретаря), стоит ли выводить смену на выходные и как в цифрах видна отдача от второго оператора. Управленческие выводы из данных, которые АТС пишет и так.
Центральный rsyslog пересылал логи сетевого парка в ELK по UDP и не замечал недоступность приёмника. Переходим на TCP с disk-assisted очередью: во время сбоя строки копятся в пределах выделенного места, а после восстановления досылаются в порядке поступления.
Одна VM занимала половину репозитория Veeam: цепочка на 1,9 ТБ при ~20 ГБ занятых данных. Почему оборот записи NetFlow давал инкременты по 80 ГБ в сутки и как отдельный vmdk сократил новый полный бэкап до ~30 ГБ.
Как связать источник истины по контактам (NetBox) с АТС на Asterisk, которая не умеет ходить в REST из диалплана: реверс-поиск номер→имя через локальный кэш astdb, нормализация 8xx/+7xxx/7xxx к последним 10 цифрам и обогащение CDR-уведомлений в Telegram кликабельными ссылками на объекты NetBox.
Выгрузили весь архив своего канала и посчитали. Оказалось: постим в 20 раз реже, а читают не меньше. И выигрывает совсем не то, что мы постили чаще всего.
Перенесли Zabbix 4.2 с MySQL на Zabbix 7.0/PostgreSQL, сохранив более полумиллиарда строк истории. Двухфазная миграция, сверка 203 таблиц и переключение без остановки мониторинга.
Ekahau Site Survey в режиме Planning: план этажа плюс модель затухания сигнала через стены сразу показывает мёртвую зону Wi-Fi — без физического обхода объекта с анализатором.
Полгода мониторинга бортового термодатчика MikroTik hEX на чердаке в Zabbix: от 0°C зимой до 74°C летом. Суточные качели, сезонный размах и что это значит для ресурса оборудования.
Контрольный замер пропускной способности Wi-Fi 5 ГГц на MikroTik hAP ac2: 2 метра, прямая видимость, минимум помех. Не рекорд, а опорная точка — с чем сравнивать скорость на реальных объектах.
Один и тот же IPsec-поток ~100–110 Мбит/с (реальный бэкап Veeam) через два MikroTik. На RB4011iGS — до 19% CPU одного ядра. На hAP ac2 — то же ядро упирается в 99%. Разница — не в модели, а в аппаратном ускорении шифрования.
IPsec не прозрачен для MTU: GRE, ESP и NAT-T добавляют реальный overhead к каждому пакету. Считаем его на конкретном примере и настраиваем MTU/MSS на MikroTik, а не гадаем методом тыка.
Разбираем реальный инцидент: SYN-флуд на нестандартный SSH-порт с подменой исходного IP на каждом пакете. Показываем профиль CPU, address-list на 7756 адресов и почему помогает не блок-лист, а RPF.
Исторический кейс 2019 года: перенесли NAT ~1 Гбит/с клиентского трафика с FreeBSD-сервера на CCR1009. Пропускная способность сохранилась, а роутер начал учитывать до 70 тысяч соединений.
Находим MikroTik в локальном L2-сегменте через MNDP или LLDP и подключаемся к RouterOS по MAC-адресу — без Winbox, Wine и заранее известного IP.