Работать сисадмином - как это

Карта, часть 2/2 Так, CORS есть, данные есть, карта отобразилась. Теперь я захотела потестить изменение данных. Ну, не буду же я укладывать филиал, забанила на сервере прометеуса в iptables пару хостов. Пинга нет, а данные не меняются. Полезла в json - не меняются, полезла в прометеус, а он говорит, что пинг есть. А пинга нет, ну не глюки же уменя. Забанила помимо INPUT ещё OUTPUT - не помогло. Blackbox exporter оказывается, работает от пользователя prometheus. Всем, кто не root запрещены raw сокеты. Экспортер пробует, нет прав, запускает утилиту пинг, она обходит iptables. Мне ещё надо погуглить, чтоб понять почему (да, бывает, пробел знаний). Надо добавить экспортёру права на raw socket, вот так: stcap cap_net_raw+ep /usr/local/bin/blackbox_exporter Ура, данные в json теперь обновляются. А в графане нет, блять. Потому что графана считает json статическим объектом и не видит смысла его обновлять. И всякие добавления к ссылке в конце переменных автообнлвления не изменяют её мнение, она эти переменные не парсит и страницу не презапрашивает. В этом месте я подумала, что может быть, идея написать свой сайт с пинг-понгом и профурсетками для отображения карты не лишена привлекательности. Но мы не ищем лёгких путей. Qwen говорит, а давай добавим панель типа TEXT, в ней выберем html и всадим туда javascript с автообнолвлением станицы каждые 15 секунд! Ну, гулять так гулять, это уже, простите, вызов! Не работает. Я теперь уже умею немного в дебаг веб-страниц даже. В графане запрещён запуск скриптов по безопасности. Да, спасибо, разрешите, перезапуск графаны. Ооо, работает! Круто, зашибись, но 9 мегабайт гонять каждые 15 секунд - ну, не очень. Нужно упростить полигоны. Нашла прогу QGIS, она упрощает отлично. Пару раз тыкнула, если что, в настройках оптимизации 0,2 градуса поставила и меня устроило. 197 килобайт однако. Заодно Чукотку, которая с 2gis почему-то полостатая пришла, перерисовала с того первого json'a. Графана перестала отображать порезанный json. QGIS выпилил мне поле id и забыл добавить точки городов - скрипт не сходился, id везде стал null. Поправила. Дальше небольшая косметика, например, правильно расставить правила раскраски. Никакого встроенного Threshold там не работает. Идут правила "если, то", причем как только правило применилось, дальше они не проверяются. Есть только больше, меньше и равно. Например диапазон типа "больше 0 и меньше 0.5" задать нельзя. Поэтому порядок правил такой: 1) если == 0, то зеленый 2) если == 1, то красный 3) если больше 0.01, то желтый Тогда правильно отрабатывает. Ну и там, карту приблизить, всякое по мелочи. Итог: карта есть, красится правильно, обновляется раз в 15 секунд. Из того, что не хватает - подписи регионов всплывают только при наведении мышкой, как их отображать всегда - пока не разобралась. Автообнлвление средствами графаны бесполезно и на захардкоженные 15 секунд не влияет. В целом, симпатично. Можно задуматься о выводе разных данных и попробовать чего-нить замутить. В графане, оказывается, в бете есть geojson dynamic. И он правда динамик, не нужен костыль с обновлением страницы. Но походу в нём нельзя покрасить области по условию даже так урезанно как раньше - всаживай цвет внутрь json'a видимо. Узнала много нового. Заколебалась, но довольна) По логике, сейчас кто-то должен написать "да всё это было легко сделать вот этим встроенным инструментом в два клика" 😂

Карта, часть 1/2 Значит, задача - отображать на карте все регионы, где у нас есть филиалы. Не точками, а типа вот выделить прям регион РФ и залить краской. Если условное "всё хорошо" - залить зелёным, если средне - жёлтым, если "всё плохо" - красным. Пока что мера хорошо/нет определяется доступностью всего сетевого оборудования. Это не совсем правильно, но методика рассчета не участвует в эпопее (ну, она не главная). Почему не точки? Чтоб красиво и наглядно. Зачем? Чтоб когда рубанули кабель на Камчатку в море, увидеть, что выключилась Камчатка и Чукотка. Чтоб когда у Ростелека "проблемы на трассе до Дальнего Востока" увидеть, что полёг весь ДВ. А не читать простыню алертов (по 5-8 шт. на филиал) и пытаться сгруппировать в мозгах их на карте. Признаюсь, с географией на память у меня не очень. Ну, или когда РКН уронит опять ipsec - смотреть медитативно на красные пятна Сначала я поизучала что там у графаны есть насчет карт и выяснила, что нужен мне geomap с geojson скорее всего. По дефолту у графаны есть страны, аэропорты и штаты США. Штаты почти все от души квадратные и точек там мало. Регионы РФ на диво неровной формы и рисовать координаты мне не улыбалось. Сначала я загуглила "регионы РФ geojson". На гитхабе есть репа с регионами... 51 мегабайт файлик. Меня ничего не смутило, я залила его в графану. Графана крякнула, подумала секунд шесть и отрисовала. Круто, подумала я, дело за малым - менять раскраску. Как же я ошибалась)) Сначала я решила урезать эксперимент до двух филиалов, чтоб вебка не умирала, и порезала json. Графана перестала его отображать. Я пробовала и так и эдак и рестарт графаны. Насоздавала тестовых файлов с одной-двумя точками. Короче, итог наблюдений - графана кэширует загруженный json и либо жди часа два, либо создавай файл с новым именем. Очень удобно. Рестарт графаны кэш не очищает. Потом я сдалась на милость здравого смысла и попробовала поискать geojson поменьше. Нашла на 2gis и там было уже 14 мегабайт. Я сразу решила порезать его до регионов присутствия, добавить location в параметры такой же как в объектах мониторинга у прометея. Оказалось, что 2gis не относит к регионам РФ Байконур и ещё парочку. Загуглила координаты, вписала. Получила Байконур в Архангельской области. Оказалось, у графаны координаты в обратном порядке читаются. Переделала. Получила 9 мегабайт - уже ничего так (я снова ошибалась). Дальше я пыталась разными способами покрасить области. Измучила нейросетку (кстати, я перешла с deepseek на qwen). Каждый раз говорит типа делай это, а "этого" у меня в настройках нет. Чтоб не утомлять вас подробностями - в 8 версии привязать данные к geojson было просто, до 10й было возможно, в 12й нельзя. Вообще никак нельзя, потому что иди нафиг, вот почему. Привязывай координаты к targers в прометее и тогда отобразим. Как бы 4000 строк координат полигона привязывать к таргету мне показалось неуместным. А точки-города не хочу, хочу области, чтоб красивенько. Мозговой штурм совместно с нейросеткой принёс следующее: графана будет красить geojson только из данных этого json. Значит надо туда всаживать данные на лету. А значит, снова поднимаем сервис на питоне. Вгружаем туда наш json, и в цикле опрашиваем прометеус и добавляем в json поле value с процентом упавших устройств. Ну и публикуем на свободном порту. В графане вметсо файла указываем ссылку. Вроде всё круто, по ссылке json вижу, графана отображает ровно нихуя. Спасибо господи, что есть qwen, а то я как-то не специалист по веб-дебагу. Выяснилось, что графана ругается на CORS. Надо доставить пакет Flask-CORS в питон и дописать пару строчек. В этом месте я узнала, что в apt этого пакета нет, а с помощью pip3 теперь нельзя ставить в систему, только в виртуальное окружение питона. Продожение ниже⬇️

Вот фоточка того, что получилось, для привлечения внимания. Ух, вот это эпопея костылинга у меня случилась с графаной, сейчас расскажу!

И снова мониторинг: prometheus, grafana, alertmanager. Наплывами возвращаюсь к теме мониторинга. Мониторнг работает, нам раздобыли списанный огромный телевизор и теперь там куча цветных табличек и графиков - красиво, можно показать какому-нибудь залётному руководству. Ну и так, быстрее реально стали замечать, что что-то упало. Одни разрабы подкинули задачу - парсить выводимый json со странички и писать статус сервиса в зависимости от выводимого. Ну типа: есть ссылка, у которой динамическая часть - код региона и дата. Каждая ссылка возвращает в json, помимо прочего, количество загруженных в систему данных по указанному региону и на указанную дату. Если данных ноль - это ошибка. Если положительное число, то всё ок. Механизм чуть осложняется тем, что переход по ссылке напрягает систему, которая считает каждый раз точное число (оно нужно для другого). Поэтому состояние нужно проверять раз в сутки. И снова я выбрала писать эспортёр - прокладку. Он ходит и дёргает странички раз в сутки в указанное время и парсит данные. Потом выводит статус по регионам в формате, понятном прометеусу, ну и дату последнего обновления публикует на всякий случай. А прометеус уже смотрит на публикуемые данные и сохраняет раз в 30 минут у себя - да, они одинаковы на протяжении суток, ну и что. Другая задачка тоже прикольная. При срабатывании алерта нужно менять конфиг nginx на другом сервере. Ну, освоила webhook в alertmanager. А на сервере nginx'а сидит служба, слушает порт и разбирает пришедший json. Если пришёл определенный алерт со статусом firing - меняет конфиг определённым образом, проверяет его и делает reload nginx'у. А если resolved, то меняет всё взад. Оттестировано, но в прод пока не запущено, ждём отмашки. Вообще, питон, некоторые навыки программирования, нейросетки и прометеус дают очень гибкий инструмент для всяких таких штук, мне прям нравится. И да, я пишу в нашу вики описание по каждому запущенному экспортёру или скрипту. И складываю код в git.

Сказка со счастливым концом. Было у нас несколько стоек в ЦОД, достались по наследству. А в ЦОДе была сеть на cisco, дорого-богато. А ядром сети был nexus 7000 серии, коммутатор такой, L3, юнитов эдак на 11. И вот, отыгран тендер в стиле "замените вражеское оборудование на дружеское". Вместо nexus'a куплен другой коммутатор, две штуки, дорого-богато, на те же 11 юнитов каждый. Начинает интегратор переключать всё и говорит: "а вот тут не получится". "Вот тут" оказался blade шасси от HP, который включался в тот самый nexus. Забит он был не полностью, но 6 лезвий - это 6 лезвий, убрать их - и сильно просядет производительнось. Ща попробую рассказать по простому, а в конце дам пару ссылок. Подключалось к сети шасси хитрым образом: в нём стоит коммутационная плата, которая при подключении к cisco nexus делает магию и в цисковском коммутаторе появляется виртуальный коммутатор внутри. Ну как будто туда линейку портов ещё засунули. Магия работает только с nexus 7k и 9k. Если воткнуть эту плату в любой другой коммутатор, то линков нет, извините, вжух не работает. А других сетевых портов в HP тоже нет. Платы две - по одной на каждую половинку шасси. И вот у нас стоит высокопроизводительный коммутор размером с холодильник и работает просто L2 свичом. А надо заметить, аренда стоек в цоде не бесплатная и лишние 11 юнитов отнюдь как бы не лишние. Были дела поважнее, но настало время и мы стали думать, а что можно сделать. Если что, вот всё то, что я выше описала, мы не знали. Мы знали "в хуавей воткнуть нельзя". Расследование началось с того, что я вижу в циске 12 портов, подписанных как blade. 12 портов в up. А проводов из шасси 8. Нестыковочка. Найдено было название платы, найден документ с полным описанием. Я закопалась в описание того, как это работает и выяснила вот это всё, что вам рассказала. Нашла плату, которая вроде может быть вставлена вместо этой, подходит по форм-фактору и которая бы работала не как виртуальный коммутатор, а port-to-port. Написала всем знакомым с уточнением, а не знает ли кто, точно ли оно будет работать с любым коммутатором. Все ответили "да х.з., вроде должна". Я облазила весь даташит по этой новой плате и сказала, типа давай попробуем. Нашли у кого заказать такие платы, б/у, чтоб за бюджет не вылезти и не слишком жалко, если не взлетит. Прождали их 3 месяца из Китая. Настал тот день, когда платы пришли. Но чтоб безопасно воткнуть их - надо смигрировать с блейдов виртуалки. А места нет, пока возились кончилось. Прождали ещё три месяца пока приедет новый сервак и начали операцию. И вот мы одну плату вынули, вторую воткнули. Переставили трансиверы со старой на новую. Плата определилась. Прибили порты к лезвиям в управляшке. А линк не горит. Поменяли патч оптический, попробовали все виды трансиверов, какие были под рукой, попробовали насильно прописать скорость на коммутаторе. А линк не горит. Коллега уже закопался в дебри консоли управления шасси, я перечитала первые страницы гугла. И тут мы читаем при очередной инициализации что-то типа "ошибка определения трансивера, не поддерживается". В общем, мы - два умницы - прочитали весь даташит, кроме второй страницы, где черным по белому написано: "поддерживаются трансиверы следующих моделей". И, что характерно, все модели от hp. А в старой плате поддерживались трансиверы cisco, потому что прям на плате написано hp-cisco. Вернули всё как было и пошли искать трансивер от hp. У нас ассортимент китайщины и циски, у знакомых тоже нет дать погонять пару штук (чтоб понять, оно вообще заведётся или нет). Ушли искать, где купить 12 трансиверов от hp, желательно, чтоб по цене не как бюджет скромной африканской страны. Прождали их ещё месяц. И вот наконец сошлись все звёзды: трансиверы есть, плата завелась, линк горит, vlan прописаны, лезвия видятся. Хэппи энд, все дела! И обещанные ссылки: Старая плата Новая плата

Продолжаем про мониторинг, серия 5 из нескольких. В прошлый раз я обещала рассказать про интересную задачку, которая была в процессе решения. И вот я на прошлой неделе доделала её. Итак, есть задача по мониторингу веб-сервисов. Сервисы представляют собой ссылку вида https://srvNN/otchet?date1=YYYYMMDD где NN код филиала, ну а YYYYMMDD это очевидно дата. Сервисов такого вида штук 20, где-то дата меняется каждый день, где-то ежемесячно, где-то два параметра даты (отдельно год, отдельно число). Ну и филиалов около 60. То есть, нехитрым умножением получаем 1200 ссылок, которые динамически меняются ежедневно и/или ежемесячно. У меня так 😳 глаза вылупились и я пошла разговаривать: а точно ли надо каждый день новую дату проверять, нельзя ли всё в одну ссылку впихнуть, ну или хоть в 60 по количеству филиалов? Оказалось нет, по ссылке на дату строится отчет и сломать могут вот конкретный отчет в конкретную дату.  Всё, что предложил мне интернет: менять cron'ом файл с target'ами, то есть, с объектами мониторинга. И программисты тоже предлагали примерно это. На что я им объяснила: для мониторинга разные ссылки являются разными сервисами. То есть, ночью у вас N сервисов из мониторинга пропадёт, а другие N появялся. Никакого сквозного мониторинга не ждите, это будут разные сервисы. Понятное дело, это никого не устроило. Задачка была отложена в дальний угол. Но после серии 4, где я поковырялась с мониторингом учеток в AD, до меня дошло, что экспортер - просто сервис, публикующий данные в определенном формате на веб страничке. Почему бы мне не написать свой web экспортёр с шахматами и поэтессами, который будет проверять ссылки по определённой схеме, меняя их когда надо, а публиковать данные по обрезанному кусочку ссылки типа https://srvNN/otchet к тому же с добавление каких угодно данных, которые я могу потом пихать в переменные в графане? Когда я смутно понимала задачу, то и дипсик мне решение не выдавал. А вот по ТЗ он мне наваял экспортёр на питоне, который заработал с минимальными правками.  Я влюблённо посмотрела на простыню публикуемых данных и тут поняла, что чёт они медленно обновляются. Каждая ссылка - это отчёт, он формируется прям не мгновенно. От первой до последней ссылки минут 7-8 проходило. Нехорошо. В общем, "deepseek перепиши мне на async/await". И вы знаете, переписал, вообще без вопросов. А вот с дашбордом в гарафане он уже не в первый раз не справился. Пришлось ваять вручную - сводный и подробный.  После чего уже было продолжение в виде "ипать оно нагрузило систему, меняй на раз в 10 минут запросы" и "а добавим вариативности, может не каждый сервис в каждом филиале, а добавим параметров", но это уже другая история.  Давно я не делала что-то такое наглядно-полезное для коллег - добавляет, конечно, дофаминчика))

Продолжаем про мониторинг. Серия 4 из нескольких. С мониторингом простеньких веб сервисов условно разобрались. Временно я переключилась на другие задачи, но тут вылезло интересное возможное место приложения новых знаний.  Итак, есть в домене сервисные учетки. Ну там, для запуска скриптов, для автоинформирования и прочей отправки почты с МФУ. В виду того, что их количество перевалило за пару сотен, а по регламенту им полагается регулярно менять пароли, мы стали пропускать вспышки и пароли стали просрачиваться. Конечно, можно просто запускать проверку powershell скриптом и отсылать инфу на почту. Но у меня тут целый прометеус с графаной и алерт-менеджером есть! Поскольку вся это мониторинговая лабуда у меня под debian и не в домене, а мне не хотелось возиться на линухе с тем, что я могу сделать парой строк на powershell, я решила разделить это всё на две части. Ну, написание скрипта powershell это не интересно - есть специальная группа, по ней рекурсивно проходимся и вычисляем сроки действия паролей у живых учеток, ну и ещё проверяем пару параметров.  Задаём вопрос нейросетке: а как передать это в прометеус? И получаем ответ: есть windows exporter, который делает веб-страничку, где текстом пишет параметры. Экспортер - это служба, у которой есть разные параметры, с чем она может стартовать. И есть там параметр textfile - ну просто читай метрики из файла и публикуй. Пришлось немного поковыряться - параметр работал только если создавать службу из консоли. Но всё заработало.  Всё это требовало оснастки AD, так что скрипт powershell воткнут в шедуллер на виндовом сервере, который специально отведен для всякого такого. Он формирует текстовый файл в формате, который умеет читать прометеус (там такое, чёт среднее между строчками массива и json). Служба берёт этот файл и публикует параметры из него на веб-страничке. Прометеус же стучится по определенному порту на виндовый сервак и считывает данные. Ну дальше уже алерты, красивости в графане, где шкала срока действия пароля и прочее.  Система имеет кучу точек отказа: просрочится учетка, под которой запускается скрипт, удалили скрипт, выключили сервак, не стартовала служба, ну и т.д. Но как быстрый наколеночный способ визуализировать какую-то хрень - просто огонь!  Самое главное: эта возня с виндовым экспортером позволила мне начать решать задачу, которая у меня месяц висела в статусе "да вы ебанько такое требовать". Уже, можно сказать, на стадии отладки решения. Но про это будет следующая история - через недельку или две.

Продолжаем про мониторинг, серия 3 из нескольких. Итак, прошлая серия закончилась на том, что я решила начать с веб-сервисов и blackbox exporter. Дальше с помощью deepseek и матерных выражений склеила два шаблона в графане во что-то приличное. Поняла, что сервисы, требующие авторизации, требуют подкручивания. Подкрутила. Дальше черёд был за алертами. Спросила нейросетку: что лучше? Она ответила: алерты графаны типа попроще и есть веб-интерфейс, а алерты от алертменеджера более гибкие в настройке, но только yaml. Честно скажу: от графановских алертов я исплевалась. Про простоту настройки - это им сильно польстили. Через пару часов свернула насилие над собой и поставила алерт-менеджер. Потом с временем реагировния, с уровнями алертов поигралась, пока не пришла к чему-то удобоваримому. Кстати, оффтопик. Как отладить работу алертов доступности (веб странички) без того, чтобы ронять сервис? Просто в hosts на сервере мониторинга прописываете типа 192.168.10.2 myservice.mydomain.ru (Меняете на любой серый адрес, которого нет в вашей сети). И всё, для мониторинга сервис недоступен. А для всех остальных пользователей ничего не поменялось. Это, конечно, не отследит какую там ошибку сервер отдаёт, когда падает, но для первичной настройки - самое то. И вот, когда я показала народу первый результат, на который можно попыриться на большом экране, начались параллельно несколько следующих этапов. Первый - следить за алертами и подкручивать "наживую" - чтоб понять, что есть "нормальная работы системы". Кстати, сразу прям стала видна ненормальная работы одной из систем, на что программеры сказали "знаем, только полностью ререписывать код, ща времени нет, некритично, терпите". Они вот знали, а кто-то и не знал.. Второй этап - написать хоть на какие-то сервисы ту самую "сопроводиловку", определив её формат. Выглядит это примерно так: сервис такой-то, общее название "окошки". Критичность низкая. Нормальные показатели: ответ 200, сертификат сроком действия больше нуля, доступность 98% в час или более 0% за 2 последних минуты. Как проверить: зайти по ссылке, должен мелким текстом показаться json такого-то вида. Валиден любой текст, кроме ошибки. Как лечить: перезапустить iis на сервере Х. Кто может починить, если не помогло? Вася П. Пока я в процессе формирования всего этого, нужно ещё обмазывать табличку в вики регламентом реакции на инциденты. Третий этап - стребовать сопроводиловку на уже заведённые в мониторинг сервисы. Ну, я их добавляла по велению души и начальника. Типа мы прикинули, помимо критичных сервисов, на что нам тут жаловались последнее время - то и загнали. Это прям самый непростой пункт - народ сопротивляется как может. Четвертый этап: эй все, присылайте сервисы с сопроводиловкой. Будем добавлять. Ну и там маленько бюрократии: создать сервис в хэлпдеске под такие заявки, например. Ещё оттестировать алерты на почту. Deepseek прям вообще не может в шаблоны алертменеджера, сразу врёт напропалую. Не сразу догадалась попросить его прямую ссылку на кусок документации - тогда и стронулось дело. На самом деле, из пройденных этапов осталось рассказать ещё про маленькую интересную задачку, ну и может пару слов про шаблоны алерт-менеджера. А потом серия продолжится уже только сильно позже, с новыми результатами.

Продолжаем про мониторинг. Серия 2 из нескольких. Началось всё на самом деле с "поговорить". Пришла к начальнику и попыталась выянить, а какие сервисы у нас важны с точки зрения бизнеса. Ну вот, за что мы денег либо потеряем, либо недоприобретём. А какие просто важные и хотелось бы следить, потому что неприятно, когда падает, а мы (ИТ) узнаём об этом не первыми. Слово за слово, провели пяток совещаний и поняли с чего начать. Начальник ещё посоветовал почитать приказ "об обеспечении непрерывности деятельности" - сто страниц чистого восторга! Там написано примерно всё то, что я хотела делать. Правда, относится он в основном ко всяким пожарам, наводнениям и прочим прорывам дамб, но натягивается на нужную область как родной. Второй момент: я попыталась донести, что мало мониторить сервисы, надо к ним при постановке на мониторинг писать сопроводиловку, где будет указано: - "нормальное" состояние системы (у нас есть сервис, который виснет на ответах каждые несколько минут и это его нормальное состояние - всех устраивает доступность 94% в час) - уровень отклонений, когда работают алерты - уровень критичности (будить ночью ответственного или потерпит) - собственно список ответственных (не по документам, а по факту - кто может диагностировать и починить) - желательно, простые шаги диагностики, которые может выполнить поддержка - желательно, простые шаги для починки, котоые может выполнить поддержка перед эскалацией (типа, выполни скрипт, ребутни службу, ребутни сервер) - ну и путь эскалации И вот всё это не на 57 страниц приказа, а понятным языком во внутренней вики и по единой схеме. Ну чтоб люди в момент, когда упало, не читали многотомник канцелярщины, а имели простые и понятные шаги для диагностики и выполнения. Потом, очень потом, сюда добавятся группы реагирования, анализ инцидентов и прочее. В идеале ещё бы иметь схему зависимости сервисов, которая может разворачиваться и углубляться до серверов. Обновляемую. Вообще, задача "а давайте внедрим SRE" выглядит масштабно до одури. Но у меня есть опыт переваривания больших задач, которые делались годами. Так что послушаем умных людей и примем, что SRE начинается с правильного мониторинга. Заббикс я решила не трогать - мониторить, где там место кончилось, тоже надо. В планах потом сильно уменьшить от него поток оповещений. В общем, заббикс остаётся как низкоуровневый мониторинг и как мониторинг с длительной историей (год). А параллельно поднимаю prometheus, victoriametrics и графану. Это будет оперативный мониторинг. И начала я с blackbox exporter, который проверяет у меня отклик от веб страничкек. Поднять по инструкции - в целом, проблем не вызвало. А вот дальше меня ждало то, что всегда бывает, когда начинаешь изучать что-то прям для себя новое. В yaml я ни в зуб ногой, синтаксис незнакомый, promql тоже как бы. Что там должно подняться, где конфиги и где метрики - тоже надо изучать. Как сделать так, чтобы 401 unauthorized было валидным ответом и т.д. Обычно как: чет гуглишь, настраиваешь, не работает, изучаешь логи, гуглишь ещё и так до победного. А тут я внезапно сходила на ещё одну конфу, где был очень искренний доклад сетевого инженера о том, что нейросети реально могут помочь, и вообще лучше, чем мы, старпёры, думаем. И я пошла общаться с deepseek. Писала ему примерно как ТЗ для тупенького админа, который обязательно твоё ТЗ извратит. Это, чёрт возьми, работает. И очень, прям очень помогает сломать первую стену непонимания работы системы. Да, потом он пошёл врать, уже на шаблонах алертменеджера. Да, надо быть внимательным и перепроверять. Да, он советует китайские дашборды к графане. Да, надо понимать, что нельзя в него копипастить корпоративные данные. Но насколько же это охрененно, когда deepseek мне сократил время до начала работы системы в приемлемом виде раз в семь! Продолжение следует.

Про мониторинг и не только. Спасибо всем, кто не отписался! Сегодня поговорим про то, как происходит трансформация подхода к мониторингу. На моём примере. Кто помнит, я в посте "заббикс в первый раз" рассказывала как я когда-то в древности поднимала нам мониторинг. С тех пор прошло много времени. Какие-то попытки прийти к более приемлемой работе с инцидентами у меня были года два назад и тогда они не увенчались успехом. Но попробуем по порядку. Заббикс у нас мониторит серваки и сетевое оборудование. И вроде всё хорошо. Но с ростом инфраструктуры мы получили несколько проблем (помимо того, что параметры запуска его БД надо подкручивать с увеличением базы). Проблема первая: слишком много сообщений. У меня было около 70 тысяч непрочитанных сообщений от заббикса за три месяца. Да, можно подкрутить шаблоны, повыключать алерты, разметить группы, чем я частично и занялась.. Но мы подходим ко второй проблеме: сообщения не информативны для понимания состояния работоспособности инфраструктуры. Ну то есть, сообщение "меньше 5ГБ осталось на диске D сервера s00-db01". Вообще не говорит нам о том, что у нас навернулся или НЕ навернулся корпоративный портал. А такое же сообщение про диск G - это не критично, потому что "не обращайте внимания, это temp db". Или, например, "туннель с Роутером1 Вологды недоступен". Тут сразу вопрос: а с роутером2 доступен? Ну то есть, сеть филиала видна, всё ок, резерв работает. Или, например, недоступны все туннели с Вологдой. Плохо это? Ну как бы да, филиал недоступен. Но, допустим, время сейчас 3 утра субботы, филиал не работает. А может время рабочее, но они прислали письмо "у нас авария на электроподстанции, полгорода без света". Уже сразу критичность инцидента понижается - потому что не нужна связь или сделать со своей стороны ничего не можем. И третья проблема: а непонятно, как определять критичность, как определить ответственных, кто должен добавить там места или посмотреть что с туннелями. И непонятно, что считать за "хорошее состояние системы". Можно начать писать инструкцию на каждый сервер, но сервера прибавляются быстрее, чем ты пишешь инструкции. То есть, есть у нас гора алертов заббикса, есть круглосуточная поддержка в виде одного человека единовременно, который пырится в этот мониторнг и пытается понять, а что с этим делать. И у которого записки "на это не обращать внимания, а вот это важно, писать туда". Я тут сходила в мае на LinkMeetUp, послушала тематические доклады и, наверное, смогла лучше сформулировать то, что нам надо. А может, компания дозрела до перемен. А теперь забываем все перечисленные проблемы. Потому что это такие, ит-шные мелкие проблемки. Ставим вопрос по другому: а что важно для бизнеса? Для бизнеса важно понимать, что не сломался бизнес-процесс. Сайтик крутится, лавэха мутится, как говорится. И приходим к мониторингу сервисов, а не серверов. Тут надо поймать баланс между ИТ-метриками и бизнес-метриками, конечно. А в идеале мониторить и то и другое. Много чего нужно в идеале и я про что-то попробую рассказать в будущих постах. Но мы помним, компания не рождается гуглом и яндексом. Из имеющихся сил - примерно я. А мониторинг - отнюдь не единственная область, которой я занимаюсь в компании. Поэтому я начала с малого: веб сервисы. Это достаточно просто и наглядно, плюс должно сильно уменьшить время реакции на важные инциденты. Да, то, что веб страничка возвращает 200 ОК не означает, что сервис прямо таки работает. Но лучше такой мониторинг, чем "а зайди проверь, говорят, портал чёт упал". Продолжение в следующих сериях. Там будет про написание инструкций, prometheus, grafana, а также поучаствуют нейросети.

Вопрос к аудитории Коллеги, просьба в комментариях поделиться опытом, кто столкнулся с такой проблемой и как решал. Ситуация следующая: компания не айтишная, занимается какой-то своей деятельностью, жила и живет с виндовой инфраструктурой. То есть, AD, Exchange, MSOffice, рабочие места на винде, ну и т.д. Но в связи с событиями последних лет (начиная с ковида) резко возросло число линуховых серверов. То есть, их было типа три, а стало триста. И в полный рост встал вопрос, как их админить централизованно? В основном это debian, есть немного ubuntu и немного centos. То есть, я так понимаю, задачи следующие: 1) выделить какие-то типовые наборы пакетов и типовые конфигурации виртуалок 2) централизованно раздавать и отбирать права 3) централизованно обновлять (ну, есть nexus sonatype, но это немного не то, нужен аналог wsus) 4) завести внутренний репозиторий со своим специчным софтом 5) собирать инфу об установленном софте 6) быстро восстанавливать и/или разворачивать критичные и/или типовые сервисы 7) обеспечить авторегистрацию и автоудаление в DNS В связи с этим вопрос, вводить ли линуксовые сервера в домен? Кто как решал перечисленные вопросы (можно просто названия, которые гуглить)? Путь только к Ansible или есть ещё что? Что я упустила в задачах? Уходить от AD пока не планируется, если что, да и виндовых серверов тоже достаточно. Всем заранее спасибо за ответы)

Автобэкапы На прошлой неделе коллега из дружественной организации тоже заинтересовался моим скриптом автобэкапа сетевого оборудования, так что я собралась с силами и его выложила проектом Я уже кучу раз в постах на пикабу писала почему не "ваше любимое готовое решение". Но повторю: 1) потому что я хочу понимать, что происходит. 2) потому что я на основе своего решения уже имею, например, анализатор занятых портов на свичах в рамках филиала. А в целом имею возможность выполнить любые команды и проанализировать вывод. 3) Ну и вообще: моё решение с шахматами и поэтэссами умеет делать ровно то, что мне надо, таким образом, как мне надо. Плохо что ли? Хорошо! И немного истории: Про то, как я боролась с ключами ssh на хуавее я уже писала, но вспоминаю, что это было непросто. Ну и к идее хранения конфигов в системе контроля версий пришла давно, ещё когда у нас были D-Link DFL, и также давно мы переехали с svn на git (в gitea). Был у меня скрипт на bash, а хотелось его переписать на python. Потому что стильно-модно-молодёжно, понятнее к восприятию и можно накрутить всякого. Первый затык был в параллельность. Ну потому что 300 бэкапов, да по 1 минуте на каждый минимум - это уже 5 часов. Как бы питон это не Си и просто fork-exec это немного не то, что нужно. И не bash, где можно просто в конце амперсанд написать. В результе пришла к subprocess. Но тут как бы... триста питон процессов все разом запускать - мой бедный сервер с одним гигом памяти немного может не справиться. Так что надо запускать их параллельно, но не все. Тут муж немного мне помог с логикой карусели процессов. Запускаем N в параллель, отслеживаем завершение, потом как один бэкап кончился - запускаем следующий. Всё круто, но появились зависшие процессы, пришлось сделать таймаут и отстреливать. Потом хотелось сделать одну суперфункцию на всё. Но нет, пришла к выводу, что лучше по своей функции на каждый тип устройств, несмотря на большую часть копирования кода. Естественно, нужно было оценить успешность бэкапа. А если есть оценка успешности - почему бы не запустить повторный бэкап на неуспешные устройства с увеличенным таймаутом? А, да, пыталась я использовать все эти модули - netmiko, paramiko и чёт там ещё. В результате оставила только paramiko и только в части открытия ssh сессии и то не на все устройства. Потому что это грёбаный пипец - то одно не работает, то второе, то не так считывает, то исключения нет и оно падает с ошибкой. В результате, конечно, не кроссплатформенно, а под debian получилось. Зато работает как надо, а не как бог на душу положил разработчикам, которые сетевые девайсы в глаза не видели и бэкапы с них не делали. Потом нам зарубили отправку почты без авторизации внутри домена. Всё, что я нашла для авторизации на exchange это swaks. Это вообще инструмент тестирования и я немного гвозди микроскопом забиваю, но как есть. После этого, нам пришли новые коммутаторы maipu, но тут, спасибо мне, они включились в систему добавлением одной функции и одного if'a. Сейчас вот пришли новые хуавеи с новой прошивкой (там другая ОС!) И у них изменилось сообщение об успешном бэкапе. Придётся зводить их с новым тегом видимо. Такая вот длинная история. В целом система пару лет работает и очень в жизни помогает. Код по ссылке в начале. Readme я сделала на английском, а комменты остались частично на русском. Ну, переводчиком все пользоваться умеют. Надеюсь, кому-то пригодится. Ну а нет - так нет)

Поленись/не поленись Где-то раз в год возникает задача обновить список почтовых контактов сторонних организаций в AD. Новый список попадает ко мне в виде csv'шки. Задача удалить те контакты, которые не актуальны, залить новые, а те, что остались - поправить (у кого должность сменилась, а у кого-то почта). Просто пачкой удалить всё и залить новое нельзя, потому что тогда при выборе контакта из кэша в outlook полезут ошибки. Контактов около 8 тысяч. Ну понятно, что это powershell. Раньше это было несколько скриптов - сначала просто на компе (где AD обвеска стоит), потом на почтовике, потому что только там есть почтовая оснастка. И много допиливания напильником - тёзки, одинаковая почта (alias'ы) с нашими пользователями, другие ошибки создания. Ну прям человек 200 набегало таких. В этот раз я предстваила страдания и пошла писать скрипты с нормальными проверками, с условиями и прочим таким. Ну потому что надоело страдать. Потом подумала, что я мучаюсь и пошла сразу всё с почтовика делать. Всё равно три прогона получается - один удаление, второй создание, а третий обновление. Потому что в создании почтового контакта нельзя сразу должность впихнуть, а если сразу на него начать делать get-adObject, ад-шка не успевает отсинхронизироваться и в половине случаев говорит, что объект не найден. Поэтому сначала все создать, а потом у старых и новых обновить данные по должностям/почтам. Неплохо получилось, всего 6 контактов с ошибками, требующими ручной доработки. Меньше 0,1%. Лень - двигатель прогресса)) Для новых подписчиков: я стараюсь писать свои впечатления от работы, истории, байки, немного философских мыслей. Каналов типа "приёмы работы bash/linux/windows которые вы не знали" и так много, среди них есть прям хорошие, так что я с ними не конкурирую))

Линукс или сетевая железка? Иногда смотришь на энтерпрайз железки с тоской и думаешь, ну ёпрст, а не взять ли мне говнокомп, вкатить туда debian с iptables и радоваться жизни за ценник на порядки меньше..  Сегодня у нас пятничные размышления, возможно, немного наивные. Давайте выкинем случай с ЦОДом, или очень нагруженной инфраструктурой, где действительно чипы и процессоры в железках, заточенных под маршрутизацию или коммутацию, играют большую роль.  Рассмотрим обычный вариант малого офиса или филиала, где канал 100 мегабит, ну на край гигабит. Пара серваков, сотня компов. Роутер немножк фильтрует трафик между сетями и в инет, держит до пары десятков vpn-каналов, NAT'ит трафик в инет, пробрасывает внутрь пару портов, ну и может dhcp раздаёт. И встаёт выбор: кинетик/микротик/хуавей/циска или комп/сервер/виртуалка на линухе. Считаем, что производительности условного компа хватит на то, что делает роутер. Почему роутер на линухе это плохо: 1) нет единого конфига. Уася поставил рандомный firewall поиграться, сложил конфиги неизвестно куда, обмазал скриптами на питоне и, конечно же, не задокументировал. Уася уволился или его переехала машина и вы получили чёрный ящик. А может он ещё и диск зашифровал, чтоб никто не догадался, что там в конфигах. В сетевых же железках всё структурировано, шаг влево, шаг вправо и уже ничего нельзя сделать иначе. 2) бэкапы из-за пункта 1 могут быть неполными, чтобы вернуть систему в то же самое состояние нужно прям поебаться. Это не раскатать бэкап с одной циски на другую такую же. Это если вообще кто-то подумал про бэкапы. 3) чтоб нанять замену вашему кулибину, нужно найти достаточно компетентного чувака. Это вам не пройти мастер на кинетике в виде далее-далее-готово и даже не поковыряться внутри микротика по менюшкам. Тут нужны какие-то дополнительные знания. 4) если у вас два офиса, привет два абсолютно разных конфига. Даже если написан регламент как надо. 5) размер имеет значение иногда - маленькая коробочка или десктоп куда-то деть. 6) держать штуку, обеспечивающую доступ к инфраструктуре, внутри этой самой инфраструктуры - ну, не особо безопасно. Это примерно как ставить получение адреса по dhcp на хост-машине, при том что dhcp без failover'а крутится виртуалкой на этой же хост-машине. 7) бывает, нужно ставить сертифицированное решение и, обычно, это железка, тут уж никуда не деться. На самом деле, почти все эти пункты можно победить. Об этом в конце. Почему роутер на линухе это хорошо: 1) он правда умеет всё, что вам надо. А если не умеет, вы поставите дополнительный пакет. Или напишете свой. 2) он отлично скриптуется, можно реализовывать самые извращённые сценарии, вроде работы vpn только в будни по производственному календарю с 7 до 16 с отсылкой напоминаний в телеграм. 3) не справляется? Докиньте оперативки. Короче, худо-бедно по производительности можно менять. А можно вообще масштабировать на несколько.. ладно, мы всё еще про маленький офис, не будем об этом. 4) это стоит мало денег. Ну, типа говнокомп или заначенный маленький сервак есть у каждого админа. И быстро! Не надо играть тендер, ждать согласования.. Минусы в плюсы И если лет пять назад я безальтернативно говорила "только сетевые железки, иначе потом не разгребёте", то сейчас я начиталась про автоматизацию и появились варианты. Если у вас единственный офис с единственним админом, всё ещё условный кинетик - ваш выбор.  А вот если у вас много офисов с более-менее едиными условиями и центральным управлением, то можно заняться девопсом: даже без всяких контейнеров грамотно всё загнать в Ansible и вот вы уже получите единое управление, массовую безопасную раскатку изменений, автодокументирование, быструю воспроизводимость и единообразие. И нужно вам не 40 линуксоидов в 40 филиалов, а один сетевик-немножко-девопс (ладно, два). Ну, купить компы в маленьком корпусе (+запас) или обеспечить отказоустойчивый кластер с виртуалками - это уже по деньгам переплюнет маленькие сетевые железки, конечно. Но всё-таки, варианты появляются.

netbox Пару-тройку лет назад, я ходила и приставала к людям с вопросом: "а что используете для ведения ip адресации и для всякой базы знаний о сети?". И люди достаточно единодушно слали меня в netbox. Netbox у нас пережил первую итерацию, когда им никто не пользовался и туда ничего не заводил (ну ладно, три стойки в цоде по юнитам расписали и даже пару раз обновляли данные). Затем сотрудник, который его поднимал, уволился, а netbox умер в муках. Потом у меня появился раб сотрудник, у которого есть время и желание. У нетбокса появилась доменная авторизация по группе, плагины и новый сервак. Настала итерация 2.1, в которой мы поиграли с правами (пару раз проиграли, но потом пришли к ничьей) и дали доступ другому очень активному человеку, который его затестил по мере сил. Сейчас итерация 2.2 - я туда перетащила ip адресацию и немного ещё всякого, а также призвала им пользоваться. Ну, лучше, чем excel-ка в шаре. Уже неплохой результат: завела все VLANы, посмотрела на них и поняла, что надо чистить конфиг, много хвостов. Потом, надеюсь, дойдём до итерации три: интеграция с чем-нибудь и динамическое обновление данных. Итерация 4 предполагает, что у нас будет автоматическая настройка сетевого оборудования в филиалах до стадии "можно подключиться по ssh". Ну, в отдалённом светлом будущем. До идеологии "netbox - единственный источник правды" пока идти не готовы. Эта идеология предполагает, что все изменения делаются в netbox, а потом разными способами отливаются на прод (изменяются конфиги сетевого оборудования, создаются и удаляются виртуалки и т.д.). В целом, конечно, наша автоматизация пока робко выглядывает из каменного века полностью ручной работы. Это я почитала соответствующие статьи и немного загрустила. С другой стороны, есть к чему стремиться 😁 Ну а к классическому комментарию "во всех нормальных компаниях есть netbox со всеми интеграциями" я уже давно писала пост про это

Про запросы Прошло много времени с моего последнего поста. Я так и не собралась опубликовать код своей бэкапилки сетевого оборудования на питоне, хотя она исправно работает, в том числе с новыми свичами от Maipu. Когда-нибудь, да.. Сегодня про прикольную задачку от моего любимого колл-центра. Нужен им был отчет, чтоб и сводный, и с процентами, и суммировал и показывал много чего. А у них всегда есть два варианта: или отчет делаю я, или они заказывают у вендора доработку системы за немного денежек (кстати, обычно, вменяемо, не как крыло от самолёта). Но к деньгам надо писать 100500 служебок, четыре согласования, адекватное ТЗ и ждать неизвестно сколько. В общем, они любят, когда отчёты делаю я и даже готовы ждать, когда у меня появится время. А я как-то для своих надобностей обычно работаю с базами данных на одну-три таблички, без фанатизма. Ну, знаете, select * from netdev where ip like "10.78%"; обычно мой предел. А тут в одной базе статистики 76 табличек, во второй тоже хватает. Описания структуры БД, конечно, нет (есть, но ооочень лаконичное). Так что я вначале погрузилась в мир текущих отчетов и маленьких селектов в PGAdmin, чтоб понять, откуда вообще тащить данные. Потом попыталась всё это склеить. Получилось, но не то. Дернула нашего гуру sql, он дал совет. Получилось и то, но это была только четверть отчёта. В общем, теперь я умею делать запросы в 4 тблицы в двух разных БД, а также делать LEFT JOIN на FULL JOIN на LEFT JOIN на ещё один LEFT JOIN. Надо просто не жалеть скобочек, оказывается. А ещё узнала, что можно сделать select *, что-то_ещё То есть, выбрать больше, чем звёздочка. Ну ладно-ладно, мне ещё раз помог наш гуру по SQL. Но только советами 🤯 (я периодически говорила "а что, так можно было?"). Попутно нашла, что делать при делении на ноль (проценты беспощадны!), а также обошла странную штуку при сравнении времени через свойства самой системы отчётности. Развлекалась, короче, на все деньги. Заказчик результатом доволен :) Попутно изучила пару отчётов, которые нам писали когда-то сотрудники вендора. Называть промежуточную таблицу просто t в запросе на 300 строк - это надо иметь особую ненависть к тому, кто будет отчеты разбирать после них. Потому что по ctrl+f найти одну английскую буковку t в нужном месте довольно нетривиально. Чтоб они спали спокойно после этого. Спасибо подписавшимся, да и отписавшимся тоже: какая-то движуха тут без меня происходила, прикольно)

Пробую выкладывать код. Так, пара человек сказали выложить код, к предыдущему посту - ну типа, а почему бы и нет. Я пытаюсь освоить github, так что вот ссылка Напоминаю, справочники брать из реестра минцифры Оптимизируются справочники под мои нужды, так что не думаю, что оно кому-нибудь пригодится, но вдруг 🤷🏻

Опять про собеседования Долго думала, как бы покультурнее написать и никого не обидеть. Искала я тут себе сотрудника, прособеседовала человек 15, что, кстати, не особо и много. Искала эникейщика на asterisk и сеть (базовые заявки по инструкции), в описании вакансии были требования (DNS, DHCP, NAT, понимание, что такое IP, маска, маршрут). Ну как бы, астеру мы обучим, а вот базовое понимание сети - не каждому даётся. А также от меня было требование: "общая адекватность и минимальная самостоятельность, и чтоб какую-нибудь консоль в глаза видел (линуксовую, сетевого оборудования - не важно)". Эти дополнительные требования как-то облагородили для публицакии и они были указаны неявно. 40+ кандидаты поголовно "у меня свой бизнес". Хотя какое-то базовое понимание основ там было. Просто людям не интересно (я их понимаю, сидеть и закрывать базовые заявки - не самая интересная штука, когда у тебя свой бизнес). К слову, не так давно собесила админа 60+ и он у меня согласование прошёл, дядька был старой закалки. Молодёжь 20-25 лет - на неё была вся надежда. По деньгам мы под их хотелки проходили с запасом. Но это трындец. У нас в вакансии шесть незнакомых слов: ну хоть википедию открой, хоть покажи, что ты её читал и пытался понять! Мне не надо глубоких знаний, но с тобой за сутки-двое договорились о собеседовании, ну покажи, что ты можешь освоить минимальную информацию, погуглив! Просто по нулям. Причём образование профильное у всех, опыт работы какой-никакой обычно указан. Спрашиваем, почему работу меняете? Говорит, скучно, не дают делать сложные вещи, мало заявок, сидишь на работе скучаешь. Ок, спрашиваем, инетом запрещено было пользоваться? Нет, говорит, самообразованием занимались все N месяцев работы. В резюме указно "работал с оборудованием cisco". Что делали именно? Vlan'ы прописывали. Ок, зачем vlan'ы нужны? - "Чтоб был доступ в интернет". И всё, стена! На все наводящие вопросы, вроде, "а будет ли интернет без вланов работать? А что будет, если у вас неуправляемый коммутатор? А что нужно ещё, чтоб интернет работал?" - тишина. То есть, человек N месяцев клепал вланы на цисках, у него была куча свободного времени на самообразование, а он даже не погуглил, нафиг вланы нужны.. Причём от пола кандидата не зависит - у меня то вроде как предрассудков по полу нет, но глухо одинаково и у девушек и у юношей. Всё! Всё, что я спрашивала, мне рассказывали в университете! У меня, конечно, хорошее образование, но не думала, что всё настолько скатилось. В результате получилось два адекватных кандидата, оба 30+, примерно равные по знаниям (смогли прочитать википедию и пересказать своими словами хотя бы общие принципы, видели консоль и даже имели какой-то опыт работы в линухе). Победил один по личным качествам. Вопросы на всякие софт скиллз задают у нас кадры. И вопрос был типа "расскажите про ваши отношения с коллегами и начальством". И если в 23 условных года я могу понять максимализм, то в 30+ яростно и со злобой рассказывть как кто-то из коллег ничего не понимает в айти - ну такое. В этом возрасте уже должен быть опыт работы с людьми и постигнуты простые истины: 1) сотрурудник может быть ценен тем, что разбирается в какой-то другой области, а в айти он дуб-дубом, так бывает 2) даже айтишник не обязан разбираться во всех областях айти 3) люди ленятся, врут, творят хуйню - это нормальное состояние человечества. Где-то можно нести свет знаний, где-то смириться, но в целом не нужно думать, что в другой конторе есть другие волшебные люди, которые не ленятся, не врут и не творят хуйни Там ещё, конечно, были моменты, но это прям красный флаг для работы в поддержке. Зато второй кандидат имел за плечами профессию, не связанную с айтишечкой, но где он познал дзен и успел понять, что мир неидеален. Вот такая история. В целом, кандидаты в адеквате есть. Надо искать, да. Москва, что уж, имели возможность перебирать. Куча народа хочет удалёнку, но мы, поимев опыт с двумя удалёнщиками, разочаровались в таком формате работы на этой должности

Нудненько про решение проблемы определения региона звонка по номеру Выдалось у меня время как-то для покодить. Задача стояла давно и всё нарастала. Обычно, нам в контакт-центр поступают звонки таким образом, что мы в курсе, в какой регион РФ направить звонок. Но был один источник телефонного трафика, где определение региона отсутствовало. Скажем так, попадали такие звонки на служебный внутренний номер. От звонка есть только АОН - номер абонента. Когда звонок с городского, казалось бы всё ясно - у нас не так много кодов (хотя и нужно собирать звонки по городам региона в одно место). Это потом я узнала, сколько реально городов есть. Но кто в наше время звонит с городского? Одни мобильные кругом. Ремарка: даже для внешних звонков определение условной геопозиции (или вышки), по ней региона и передача такой информации для бизнеса - нет, такого не делает, насколько я знаю, никто. Это вам не звонки на 112. Все онлайн-сервисы это медленно, ненадёжно и сложнореализуемо моими средствами. Так что выбор пал на справочники из реестра минцифры Вообще, у нас в стране оказывается есть номера только на 3, на 4, на 8 и на 9. Собственно, по ссылке и лежат 4 справочника. Там указан DEF номер (первые 3 цифры) и диапазон ОТ и ДО с указанием какому оператору в каком регионе диапазон отпилен. Ну в принципе, бери справочники, грузи себе в таблицу и делай каждый звонок запрос. Но справочник на 4, например, больше 30 мегабайт csv-шка. А система у меня не самая быстрая на свете. Я как предствила, что на каждый звонок пойдёт поиск, так мне немного плохо стало. А также мне надо было указать системе что условные "г. Калининград" и "г.Советск Калининградкой области" - для меня один и тот же регион "Калининград". Поэтому я взяла питончик и написала абсолютно ужасный, но рабочий скрипт оптимизации, который прогнала в несколько итераций над файлами. Итого справочник на 3,4 и 8 ужался в 135 строчек. Ну и мобильники немного тоже ужались, но не сильно. Первая функция выпиливала всё лишнее и склеивала одинаковые регионы, где диапазоны идут подряд. Вторая функция только для городских телефонов склеивала "дырки" в диапазонах у регионов. Ну типа номера на 100-155 и номера на 158-199 это Н-ская область, а номера на 156-157 никому не выданы. Я считатала оптом 100-199: Н-ская область. Если в мобильных номерах такие дырки разлетаются быстро и регион там рандомный, то в городских новые диапазоны раздают не так часто и стараются попасть регионом в старый диапазон или рядом. Отдельная функция оптимизировала Москву, Мособласть, Питер и Ленобласть и выпиливала все номера на 800-809, так как там нет привязки к региону или она условна. И финальная функция собирала мне два справочника: городские и мобильные. Потом пришлось написать вручную таблицу соответствия: название региона и название скрипта очереди в нашей системе телефонии. Это была самая печальная часть) Ну и всё: таблицы в постгрес. В колл-центре скрипт, который по табличкам определяет регион и по нему выбирает следующий скрипт. Месяца три как работает, полёт нормальный. Определение достаточно точное, не смотря на то, что народ с мобильными номерами переезжает в другие регионы. +/- в 95% случаев регион определяется нормально (если пиходит АОН не пустой). Я х.з., сам скрипт вообще нужен ? Могу выложить, там лютый говнокод и просто разбор строчек, считайте, я на нём питон училась применять)

Как мы мониторим температуру в серверной. В давние времена мониторинг был простой: прокся в инет на десктопном сервере умирала первой, не пропустишь. Далее идёшь и щупаешь металлическую дверь в серверную: если можно касаться - ещё норм, а если горячо дотронуться, то надо срочно гасить остальные сервера. Потом мы купили чудо техники: термометр с gsm. И с тех пор он с нами ездит по офисам и шлёт смс-ки счастья, если что случится. Если он прислал 'температура больше 27 градусов', то идём и смотрим, что там с кондеями. Это если рабочий день. Если вечер/ночь/выходной, то ждём минут 20 и шлём запрос температуры. Если поднимается, то пытаемся вызвонить охрану, чтоб во-первых сами глянули что там и как (может электричество рубанули конкретно по линии кондеев), а во-вторых нас пустили на территорию офиса. В прошлом здании были круглосуточные пропуска. В этом вроде как тоже есть, но без звонка в само здание не пустят.