Собрали Telegram-бота для клиентских чатов поддержки. Какой чат и какая ветка принадлежат клиенту, теперь записано в одном месте — в NetBox, и оттуда раскладывается в мониторинг и в бота. Вне рабочих часов бот регистрирует обращения и зовёт дежурного, а состояние площадок показывает только своему клиенту.
Типовой крон резервных копий 1С на PostgreSQL перезаписывает недельные копии, а месячные весь первый год только добавляет. Через несколько месяцев раздел с базой заполнился, у 1С начали падать запросы, а одна копия оборвалась — и быстрая проверка этого не показала. Разобрали, почему так выходит, и поставили чистку по заполнению диска.
Перенесли всю базу подключений с Royal TS на RDM и перевели доступ к машинам на аппаратные FIDO2-сертификаты YubiKey — то, чего движок Royal не умеет в принципе. Один клиент на все протоколы, единый вход через jump-host, ни одного приватного ключа на диске.
Логи с маршрутизаторов собирались и занимали место, а на вопрос «кто и что менял в конфигурации на прошлой неделе» отвечали неправильно. Перебрали конвейер разбора Logstash целиком: события классифицируются, имена и адреса лежат в своих полях, история пересчитана задним числом, расхождений — 0.
Кто создал, удалил, переименовал и сколько данных прочитал на сетевой шаре — эти события в TrueNAS есть, но в syslog их нет, а API отдаёт всё заново при каждом запросе. Написали поллер, который ходит по WebSocket, помнит позицию и не теряет события, даже когда приёмник недоступен.
Перевели собственную службу поддержки с Яндекс Трекера на OpenProject на своих серверах. Перенесли всю историю — заявки с комментариями, вложениями и исходными датами — со сверкой каждой записи.
Заказчик попросил простой веб-интерфейс, чтобы слушать записи разговоров и смотреть детализацию. Пока разворачивали — обнаружили, что журналы станции пусты, 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.