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

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

Продолжаем про мониторинг. Серия 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% в час

Продолжаем про мониторинг. Серия 2 из нескольких.Началось всё на самом деле с "поговорить". Пришла к начальнику и попыталась выянить, а какие сервисы у нас важны с точки зрения бизнеса. Ну вот, за что мы денег либо потеряем, либо недоприобретём. А какие просто важные и хотелось бы следить, потому что неприятно, когда падает, а мы (ИТ) узнаём об этом не первыми. Слово за слово, провели пяток совещаний и поняли с чего начать. Начальник ещё посоветовал почитать приказ "об обеспечении непрерывности деятельности" - сто страниц чистого восторга! Там написано примерно всё то, что я хотела делать. Правда, относится он в основном ко всяким пожарам, наводнениям и прочим прорывам дамб, но натягивается на нужную область как родной.Второй момент: я попыталась донести, что мало мониторить сервисы, надо к ним при постановке на мониторинг писать сопроводиловку, где будет указано:- "нормальное" состояние системы (у нас есть сервис, который виснет на ответах каждые несколько минут и это его нормальное состояние - всех устраивает доступность 94% в час)- уровень отклонений, когда работают алерты - уровень критичности (будить ночью ответственного или потерпит)- собственно список ответственных (не по документам, а по факту - кто может диагностировать и починить)- желательно, простые шаги диагностики, которые может выполнить поддержка- желательно, простые шаги для починки, котоые может выполнить поддержка перед эскалацией (типа, выполни скрипт, ребутни службу, ребутни сервер)- ну и путь эскалацииИ вот всё это не на 57 страниц приказа, а понятным языком во внутренней вики и по единой схеме. Ну чтоб люди в момент, когда упало, не читали многотомник канцелярщины, а имели простые и понятные шаги для диагностики и выполнения.Потом, очень потом, сюда добавятся группы реагирования, анализ инцидентов и прочее. В идеале ещё бы иметь схему зависимости сервисов, которая может разворачиваться и углубляться до серверов. Обновляемую.Вообще, задача "а давайте внедрим SRE" выглядит масштабно до одури. Но

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

Вопрос к аудиторииКоллеги, просьба в комментариях поделиться опытом, кто столкнулся с такой проблемой и как решал. Ситуация следующая: компания не айтишная, занимается какой-то своей деятельностью, жила и живет с виндовой инфраструктурой. То есть, 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 в параллель, отслеживаем завершение, потом как один бэкап кончился - запускаем следующий. Всё круто, но появились зависшие процессы, пришлось сделать таймаут и отстреливать.Потом хотелось сделать одну суперфункцию на всё. Но нет, пришла к выводу, что лучше по своей функции на каждый тип устройств, несмотря на большую часть копирования кода.Естественно, нужно было оценить успешность бэкапа. А если ест

Поленись/не поленисьГде-то раз в год возникает задача обновить список почтовых контактов сторонних организаций в 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) держать ш

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. Но только советами 🤯 (я периодически говорила "а что, так можно было?"). Попутно нашла, что делать при делении на ноль (проценты беспощадны!), а также обошла странную штуку при сравнении времени через свойства самой системы отчётности. Развлекалась, короче, на все деньги. Заказчик результатом доволен :)Попутно изучила пару отчётов, к

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

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

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

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