virrasha

virrasha

Админю сеточки. Поддалась силам зла и завела телеграм с более коротким форматом постов https://t.me/sysadmin_how_it_is
Пикабушница
поставилa 5929 плюсов и 111 минусов
отредактировалa 1 пост
проголосовалa за 2 редактирования
Награды:
С Днем рождения, Пикабу!5 лет на Пикабуболее 1000 подписчиков
19К рейтинг 1508 подписчиков 89 подписок 38 постов 33 в горячем

Как я ваяла bgp шаблон для huawei в zabbix

Эта история входит в серию про описание работы админа и рассказывает не о том, что «вот я сделала шаблон для zabbix – скачивайте», но о том, как всё это происходит.

В пятницу у меня была задача ничего не сломать, наконец-то образовалось свободное время и я занялась шаблонами на zabbix для мониторинга BGP. Есть шаблоны на cisco, а вот на huawei я нашла один какой-то шаблон. Он работал, но меня не устраивал своей малой информативностью и я начала его допиливать.

Я вообще в шаблонах заббикса полный нуб, максимум что делала — пару параметров поправить. Именно поэтому я не пошла создавать свой супер-мега шаблон с нуля, а взяла за основу чей-то. Для начала нам нужны mib от Huawei на CloudEngine 8000. Спасибо хуавею за наше счастливое настоящее — по ним есть онлайн справка.

Что такое mib? Это Management Information Base, с ней работает snmp. Там по цифровому ключу, разделённому точками (типа 1.5.2.4.3.1) можно получить значение, которое будет характеризовать какое-то состояние какого-то компонента системы. Ну типа, у вас интерфейс поднят или нет? Или вентилятор включен или нет? Или «трафика зарегистрировано в такой-то момент столько-то килобит на таком-то интерфейсе в такую-то сторону». У каждого значения есть точный ключ, такая длинная цифровая змея. Если взять ключ и отрезать у него хвостик до какого-то знака — и обратиться по обрезанному ключу — можно получить список значений, объединенных по какому-то признаку. Например, статус всех интерфейсов в системе.

Zabbix работает с сетевыми железками через snmp, соответственно, в шаблонах там указаны mib. Чтоб заббикс мог по ним что-то считывать, он должен ещё о них знать и это своя отдельная тема. Например, на непопулярные железки надо подкладывать ему mib-файлы в определенную папочку на сервере. Но с хуавеем всё хорошо, он о них (ладно, о большинстве) сам знает.

Исходный шаблон показывал соседей BGP (и не было понятно что это пир, только теги смотреть) и статус пира в виде строки с текстом от 1 до 6. Я, во-первых, коды наизусть не особо знаю, во-вторых, хотела бы график с изменением статуса пира, а график - он только для чисел, а не для текста. Также я не поняла зачем на фактически одни и те же пиры делать обнаружение и перетащила всё в одно «обнаружение», но сделала дополнительный «прототип данных» на статус пира.

С представлением в виде чиселок вроде понятно — берем и меняем «текст» на «целое положительное» и получаем то же самое, что было, но уже в цифровом виде.

Как я ваяла bgp шаблон для huawei в zabbix IT, Личный опыт, Системное администрирование, Мониторинг, Длиннопост

Если посмотреть у узла сети «данные», то там и график сам появится.
Теперь про отображение. У прототипа данных есть «предобработка», но если там менять число на его описание, то и выходные данные снова будут текстовые и графика мы не получим. Но я же вижу, что у других шаблонов и график есть и человеческое описание. Я пошла в базовый сетевой шаблон и посмотрела как там сделано. А там у шаблона есть преобразования значений. Пилим по аналогии:

Берём из описания mib 1.3.6.1.4.1.2011.5.25.177.1.1.2.1.5
The status of the remote BGP peer, including:
1: Idle(1)
2: Connect(2)
3: Active(3)
4: Opensent(4)
5: Openconfirm(5)
6: Established(6)

И вписываем в преобразование у самого шаблона.

Как я ваяла bgp шаблон для huawei в zabbix IT, Личный опыт, Системное администрирование, Мониторинг, Длиннопост

Ииии.. ничего не работает. Надо указать, что мы используем это преобразование в прототипе элемента данных (мне пришлось прочитать справку заббикса про преобразование значений, чтоб это найти):

Как я ваяла bgp шаблон для huawei в zabbix IT, Личный опыт, Системное администрирование, Мониторинг, Длиннопост

Внимательный читатель заметит (есть ностальгия по старым книжкам при этих словах, да?), что мы смотрели mib 1.3.6.1.4.1.2011.5.25.177.1.1.2.1.5 а в шаблоне у нас 1.3.6.1.4.1.2011.5.25.177.1.1.2.1.5.0.1.1.1.4 — так откуда взялся 0.1.1.1.4? Я не искала ответ, что именно он означает (мне вообще кажется он про ipv4, но не суть). Главное, что прежде чем мы mib из справки пойдём вставлять в шаблоны заббикса - хорошо бы посмотреть, что он в выводе даёт. Для этого у нас есть утилита snmpwalk. Запускаем с заббикс-сервера команду просмотра mib, указывая ip роутера, и смотрим, что выдаётся.

Как я ваяла bgp шаблон для huawei в zabbix IT, Личный опыт, Системное администрирование, Мониторинг, Длиннопост

Тут поменян community на public и в конце вырезаны белые ip-адреса соседей

Всё в конце, что не войдет в ваш SNMP OID, поселится в #SNMPINDEX, а нам там нужен только ip, соответственно весь нужный хвостик 0.1.1.1.4 включаем в SNMP OID.

Из того, что в шаблоне не было, мне захотелось добавить номер автономной системы соседа hwBgpPeerRemoteAs, MIB 1.3.6.1.4.1.2011.5.25.177.1.1.2.1.2 — сделала по аналогии.
Ну и триггер на изменение статуса пира удалось сделать встроенным мастером. Выглядит он странно, но работает.

В целом, посмотрю, что ещё надо, чтоб видеть, что оно сломалось. Например, есть количество eBGP и iBGP сессий — хорошо бы его тоже отслеживать.

У меня на гитхабе профиля нет, так что кому надо, шаблон по ссылке тут (это yaml, загружать в чужой заббикс не пробовала, уже после публикации нашла, что одно свойство у меня не bgppeer, а pgppeer, но это ни на что не влияет на данном этапе, только на эстетику).

Немного воды в конце: я вообще не вдупляла в начале куда смотреть. На понимание и дабавление пары фич у меня ушла половина рабочего дня неспешного ковыряния и ещё час вечером. Это много. С другой стороны, вы посмотрели как поступает админ в случае "да я вообще х.з. как эту хрень делать".
А ещё у меня в профиле есть телега, где я пишу более короткие и развлекательные посты пару-тройку раз в неделю, вдруг кому будет интересно.

Показать полностью 4

Про подготовку к проведению работ (сисадминское)

Я вообще всю неделю писала пост не про это, но вчера посмотрела митап от селектела и что-то вдохновилась, тема отозвалась живой болью.

Казалось бы, банальность, но я её озвучу: к работам, затрагивающим критическую инфраструктуру компании, нужно готовиться. План работ поможет вам не тупить в экстренной ситуации, а так же правильно рассчитать время и прикинуть риски.

Риски, которые по неопытности можно пропустить:

  • Что будет, если на твоём рабочем месте (или дома) отключится электричество? У тебя заряжен ноутбук? Он может работать от PowerBank?

  • Что будет, если у тебя отключится интернет/удалёнка? В выходные РКН любит тестировать отключение VPN, есть ли у тебя альтернатива? Твой телефон сможет раздать интернет?

  • Что будет если ты потеряешь доступ к оборудованию? Да-да, план нужен в том числе, чтобы доступ к оборудованию не потерять, но все мы люди, так всё же?

    Ты знаешь как дозвониться инженеру в ЦОД? Ты являешься доверенным лицом? Возможно, у тебя спросят ИНН, номер договора и секретный код - они не на той шаре в том ЦОД, к которому ты потерял доступ? Ты знаешь, в каком юните и стойке там оборудование, твой netbox не там же где и номер договора? У тебя самого есть пропуск в ЦОД/офис/серверную, оформленный на даты работ? Охрана офиса в курсе? (например, у меня круглосуточный пропуск на работу, но охрана ночью запирает дверь и уходит спать - без дополнительного предупреждения не попадешь в здание).

    Самые "опасные" работы лучше проводить на месте, однако работы могут казаться безопасными для проведения их удаленно, а случиться может что угодно. Как известно "удалённая правка ACL - к дальней дороге".

Про подготовку к проведению работ (сисадминское) IT, Личный опыт, Факап, Системное администрирование, План, Мат, Длиннопост

Опустим банальщину про то, что нужно сделать бэкапы до начала работ и проверить их корректность.

Что надо иметь в виду помимо "что если":

  • Контрольное время: если до контрольного времени не заработало или не дошли до пункта Х, то откатываемся. И да, конечно же, план отката. Чаще всего, в вашем распоряжении не всё время мира, а "слот с 20 до 00, потому что дальше проснётся Камчатка". Даже если у вас на работы все выходные, нужно понимать контрольную точку отката, так как если вы поймёте в 7 утра понедельника, что работать это не будет - может стать довольно неприятно, когда компания начнет рабочий день. Точка отката у меня обычно находится примерно на 2/3 отведенного времени, конкретно зависит от вашего плана восстановления. Вы должны успеть вернуть инфраструктуру в рабочее состояние к концу отведенного слота.

  • Точка невозврата. Бывает такое, что какой-то этап нельзя прервать (обновление BIOS, например) или после какого-то этапа откатить результат нет возможности (например, обновление прошивки, которая не даунгрейдится). В этом случае нужно прикинуть самые плохие варианты - не прошилось, всё, потеряно оборудование, восстановление или очень долгое или невозможно в текущих условиях - стоит прикинуть альтернативы, чтобы не впасть в панику. Или наоборот, вы успешно прошли точку невозврата - прошилось, но теперь только вперёд, это тот единственный случай, когда нужно настраивать до победного.

  • Критерии того, что работы прошли успешно. У вас должен быть чек-лист (пример будет ниже). Помните, если вам кажется, что всё работает - это не значит, что всё и правда работает.Подумайте также о соответсвующих доступах для проверки сервисов (пусть вам наделают клиентских учеток или для проверки выйдет компетентный пользователь)

  • Что могут затронуть ваши работы - лучше оповестить всех причастных. Например, вы собираетесь колбасить сеть, а программисты вместе с инфраструктурой наметили переезд сервера СУБД и им критично гонять пару-тройку терабайт данных без перерыва именно в это же время. Или вы обновляете сервис А, но уже все давно забыли, что сервис J к нему цеплялся по API, которые изменятся при обновлении. Лучше оповестить непричастных, чем забыть такие вещи.

Из личных примеров: у меня было две попытки перенести сервер колл-центра в ЦОД (он работают круглосуточно).
В первой попытке перенос был неудачный, не заработали исходящие звонки, настроить их в разумное время я не смогла (на тестах ранее вроде работало, а вживую нет). Это помимо кучи более мелких проблем, типа потери интеграции с внутренним софтом. И мной было сказано "откатываем".
Второй перенос был одновременно с обновлением софта колл-центра. Учли, казалось бы, всё. Но вылезли непредвиденные проблемы (непредвиденно было, что нужный оплаченный сторонний специалист их решить не мог и пришлось экстренно разбираться мне). Планировался перерыв связи два раза по 15 минут, а был перерыв 6 часов в итоге (я заранее оповестила, что планируем 30 минут, но может быть до 8 часов). Мы были просто в минутах от часа Х и решении об откате, но прошли контрольную точку и я сказала, что всё, чек-лист по переносу работает, обновляем и жгём по полной. Ух, как я понервничала, но была готова откатить, несмотря на то, что вышло работать в выходной хуева гора связанного народа - от программеров до саппорта первой линии. У меня был план и я его придерживалась)

По поводу проверки результата - например, вы меняете сервер телефонии, минимальный чек-лист может выглядеть так:

  • Телефоны обычные грузятся, получают корректный ip, прошивку на русском языке, высвечивается номер и фамилия

  • Телефоны ТОПов делают всё, что обычный + грузятся доп панели

  • Транки с провайдерами подняты

  • Работают входящие звонки: играет IVR, при наборе внутреннего номера звонит нужный телефон, при отсутствии набора звонит группа секретарей. При подъеме трубки слышно обоих собеседников в обе стороны. При ожидании играется музыка.

  • Работают исходящие: на местный городской, мобильный и междугородний номера. Слышимость также в обе стороны.

  • При исходящем на мобильный мы видим корректный АОН, который светится на мобильном. АОН соответствует ожиданиям (с конкретных номеров нужный АОН, из Воронежа виден Воронежский номер и т.д.).

  • Работают внутренние звонки по короткому номеру, высвечивается фамилия абонента

  • Работает перевод звонка, удержание

  • Работает индикация на доп-панелях и вызов с них

  • Производится запись разговора, файл в корректном формате на сервере, прослушивается

  • Производится запись в лог на сервере, записи похожи на правду

Конечно, этим мы не проверим ВСЕ функции и фичи. Но данных маркеров достаточно, чтобы понять, что более-менее работа организации не встанет колом в начале рабочего дня, клиенты дозвонятся и всё вот это.

Что в итоге? Во взрослых конторах обычно есть регламент внесения изменений в критическую инфраструктуру, который всё это старается учесть. Что не избавляет их от периодических факапов.
Всё предусмотреть невозможно, но здраво прописанный план Б, В и Г сбережет вам много нервных клеток. Не надо бояться откатить всё и сказать "не в этот раз". Ваш героизм "я точно добью к утру понедельника", "надо докатить раз начали", "зря я что ли в ночь вышел" никому не нужен и опасен тем, что вы не добьёте, не успеете и пострадает бизнес.

А ещё я перешла на сторону зла и завела тележку, ссылка в профиле. Там пока нихрена нет, но я хочу попробовать формат коротких постов, отличных от моего формата на пикабу.

Показать полностью 1

Автобэкапы сетевого оборудования Huawei

Ну или привет импортозамещение?

Сегодня в большей степени технический пост про автобэкапы Huawei (AR6120 и S5735). Но я буду разбавлять текст художественными вставками.

Почему не rancid? Все, мне кажется, задают этот вопрос в любом посте про автобэкапы. Во-первых, что-то я быстрым поиском не нашла там поддержку Huawei нужных моделей, во-вторых я хочу прям классический файл бэкапа, который можно раскатать (а rancid снимает вывод консоли, что не одно и то же), в-третьих я хочу гибкий инструмент, которым я смогу позже, например, раскатать всем правило в access-list или выполнить любую команду.
Ну и вообще, я хочу понимать как оно работает, а не использовать сторонний софт, но это уже мои загоны.

Итак, нужно логиниться на Huawei, желательно, по ssh ключу (чтоб не палить пароли в скриптах), выполнять сохранение конфигурации с определенным именем, потом заливать по tftp на сервер тоже с определенным именем, анализировать что слилось, а что нет, коммитить в git и отсылать отчет на почту.

Надо сказать, что энтерпрайзные huawei умеют, как циски, при сохранении конфигурации автоматом отсылать на ftp конфиг. Теоретически, младшие модели это тоже умеют, но практически это нихрена не работает во-первых, а во-вторых оно сливает только zip архив, что просто адски неудобно (про это будет подробнее ниже).

Единственное, что я пропущу - это настройка git. Я подняла gitea чудесно по родной инструкции, справится любой. Да и система контроля версий тут не строго обязательна в принципе.

Первое - логин на Huawei по ssh ключу. И сразу это ввергло меня в поиск. То есть, в документации такая фича есть, но ключ он принимает только в HEX виде и никакие популярные команды преобразования, которые на раз гуглятся, не привели ключ в тот вид, чтобы его сожрал Huawei.

Сначала генерируем ключ на сервере (у меня хуавей принял только 1024 бита, но поскольку ssh открыт только с белого списка адресов, я сочла это приемлемым. вы же можете поэкспериментировать с битностью). На вопрос о парольной фразе просто нажмите enter.

ssh-keygen -f ~/.ssh/id_rsa -t rsa -b 1024

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

ssh-keygen -e -m pem -f ~/.ssh/id_rsa.pub | sed '1d;$d' | tr -d '\n' | base64 -d | xxd -c 24 -g 4 -u | sed -e "s/^.*: //" -e "s/.\{25\}$//g"

на выводе вы получите примерно вот такую простыню, нужно будет сохранить (не переживайте за меня, это тестовый ключ)

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Дальше заводим ключ на Huawei. Ключ надо будет копировать в команды прямо так, как он вам вывелся на предыдущем этапе. На Huawei AR6120 команды следующие (если у вас белый список на логин по ssh не забудьте также разрешить ip вашего сервера логиниться):

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

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

На коммутатор Huawei S5735 команда чуть-чуть отличается, есть по ссылке в конце.

Для обращения к устройствам из скрипта я завела БД на sqlite, но вы можете брать информацию из текстовых файлов или ещё откуда. Поле пароля в базе будет пустым, оно оставлено для устройств, которые не поддерживают логин по ключу (вдруг такие будут)

Структура базы:

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Вставка происходит примерно так:

`insert into netdev (hostname,ip,login,pass,tag,model) values ( 'ufa-ar6120-2', '10.2.100.2','backuper','','huawei','AR6120');`

Теперь про скрипт. И на цисках, и на микротиках, и на D-Link прекрасно работала следующая схема:

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

На хуавее же логин при такой схеме происходит, в логах это видно, но никакие команды, переданные таким способом, не выполняются. Никакие манипуляции c -i -T -t не работают. Я закопалась в процессе в логи ssh, в переменные окружения и прочее. Примерно понятно, что открытый терминал не считается терминалом и это даже нормально, но никакие опции, которые туда должны впихать команды, не работают. Моего скилла победить эту конструкцию не хватило. Пришлось использовать expect.
Кстати, если кто может нормально описать почему оно не работает и как это побеждать - будет здорово. А то я как собачка - вроде частично понимаю, а нормально написать не могу.

Всего использоваться будут 5 скриптов (напомню, код текстом по ссылке в конце).

Первый скрипт разбирает базу и запускает бэкап для каждого устройства в параллель.

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Сначала у меня был один скрипт expect на все устройства (команды то одинаковые), но на коммутаторах он в 20% случаев не успевал с первой командой, так как на них очень-очень долгая загрузка после логина. А на роутерах наоборот, он завершался, не успев получить вывод от tftp и завершал сессию. Пришлось расставить костыли в виде sleep и разделить на два скрипта.

Для роутеров вот, для коммутаторов по ссылке в конце.

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

У Huawei и cisco немного по-разному сделан текущий конфиг.

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Текущий конфиг (аналог running-config) по команде save сохраняется на Huawei в vrpcfg.zip. Как уже писалось выше, при попытке сохранять это по tftp/ftp это падает всегда zip архивом и при распаковке у конфига внутри архива всегда одно и тоже имя. То есть, на такие автоматические бэкапы всё равно надо накручивать скрипт распаковки и переименования. НО! Конфиг можно сохранить в текстовом виде с любым именем .cfg и уже его сливать.

Если вам нужно добавить дату - можно добавить её в имя конфига, который будет падать по tftp (чтоб на роутере память не занимать - там всегда сохраняем с одинаковым именем). Я не добавляю дату, так как всё падает в git, там версионность поддерживается и так.

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

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Зачем каждый раз выбирать ключ ssh? Huawei сожрал только 1024 бита, а gitea хотела минимум 2048. Так что пришлось завести два и менять - один для логина, другой для коммитов.

Теперь сам анализатор логов analyse_result. Он простой как валенок, тут ваша фантазия может разгуляться. Я просто смотрю что написано success на сохранении и на копировании. Заметьте, у роутеров и коммутаторов строчки вывода разные.

Я в таких вспомогательных скриптах придерживаюсь понятного стиля написания, не гоняясь за умещением всего в одну строчку (чтоб потом вспомнить, что там вообще было), так что стиль такой не просто так)

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Ну и пихаем в cron чтоб выполнялся каждый день:

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Изменения в Gitea выглядят примерно вот так

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Сколько времени на это ушло? Ну вот столько:

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

9 дней работы от 30 минут до 3х часов в день или 19 коммитов. Больше всего я боролась с логином по ключу и с удаленным выполнением команд.

Весь код текстом тут.

Осталось раскатать это на 260 устройств :) Потом можно что угодно раскатывать сразу на все, используя эти наработки. Например, в планах составить рамочный access-list (он как бы есть, но слишком пошли различия от филиала к филиалу, хочется причесать). Ну а пока - залогиниться на каждое устройство ручками и вписать пользователя с ключом.

Занималась я этим чтобы немного размять мозги и проветриться от бумажек с отчетами, что с успехом достигнуто. Ну и для рабочей пользы.

Понятное дело, сейчас Huawei такого типа (малый офис, скажем так) не очень распространены в РФ. Уже не домашний роутер, ещё не энтерпрайз. Однако, он завозится активно, а материалов хрен да нихрена. Надеюсь, кому-то когда-то пригодится.

Показать полностью 12

Про пример принятия решения (сисадминский пост)

Подробный рассказ о преодолении трудностей с жопой в инфраструктуре был в первом посте, уже, видимо, серии.

Сейчас пойдет речь про принятие решения по телефонии - просто показать, что выбор пути, куда двигаться - это сложный процесс, а не 5 минут посовещаться у кулера (хотя и такое бывает).

Как я уже писала, у нас был полный распиздос с телефонией:

  • разная длина номера

  • одинаковые номера в колл центре и во всей присоединенной компании, из-за чего пришлось вводить префикс, чтобы их разделить. То есть, у нас все номера "на 4" это колл центр, а у них вообще номера только на 4 во всей компании.

  • три инсталляции астериска, все разными людьми, 11 cisco CUCME - это который express и лицензии расширяются физическими платами, cisco CUCM с просроченными на 2 года лицухами и отсутствием IVR (а ещё мы им не управляли), kamailio как проба sbc для склейки всего говна и fusionPBX просто как проба, на нём радиотрубки панасоников висели.

  • штук 700 sccp циско-телефонов (которые теоретически можно прошить в sip) пяти разных моделей, 20 топовых цветных цискофонов с панельками, около 1000 cisco 7821 (sip) в использовании, 1200 cisco 7821 на складе, несколько yealink, несколько gigaset и штук 150 радиотрубок с базами panasonic.

  • Каналы от провайдеров тоже любые: аналог, sip, E1

Варианты, что с этим делать были следующие:

  1. тендер на замену этого на одну телефонию

  2. почти своими силами на fusionPBX

  3. своими силами на Asterisk

  4. ничего не делать

Вариант "всё в облако" не рассматривался - мы привыкли управлять своей инфраструктурой (ну и там всякая хтонь по персданным есть, которая, впрочем, при желании обходится).

Fusion - это канадская телефония, распространяется опенсорсно, денежку берут за возможность задать вопросы разрабам, причем типа 5 баксов в месяц, гуманно. По сути это freeswitch с веб-мордой. За фьюжн топил наш чувак, который поддерживал цискофонию по сложным вопросам - говорил, что дико производительная штука, стильно-модно-молодежно. Беда в том, что чувак был в Америке и уезжать обратно к нам не собирался. Понятно, ему не хотелось терять заработок, когда мы уйдем от циски, а также чесались руки раскатать действительно большую инсталляцию этой хрени и потестить. Но:

  • у него была основная работа и мы были по остаточному принципу (надо сказать и за божеский ценник, тут не придраться)

  • фьюжн, что он поставил для теста, постоянно глючил - терял коннекты с провайдерами, у него не сохранялись в веб морде регулярки, регулярки применялись не так, как вроде выглядело бы логично. Периодически внутри него падал freeswitch и его службу надо было ребутать.

  • в России штука малопопулярная, в Америке только набирала популярность. Форумы, сообщество - ну так себе

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

  • Поскольку это веб-морда, то дебаг этой хтони... ну такой себе

  • спеца в России хуй найдёшь, хотя порог входа низкий, типа можно и самому научиться

Почему я сразу не послала его нахер? Он долго рассказывл про плюсы, по полчаса и более звонки, звучало здорово. Также его прогнозы были, что астериск может не вывезти по производительности, а эта штука точно вывезет. А еще у нас приятельские отношения и мне не хотелось слать его нахер нецензурно.

Сначала я решила попробовать быстро отыграть тендер так, чтобы выиграли ребята, которые внедряют и поддерживают астериск пакетно (в РФ такие есть). У нас даже было заложено немножко денег. Но тут включилась головная компания с идеей тендера на все дочерние компании, со своими хотелками и резким непрятием опенсорса. Стало понятно, что это надолго. А без тендера купить мы ничего не можем.

Почему я не орала сразу "давайте астериск внедрим сами, нахуй всех"?

  • Собственно, головная компания нас резко отговаривала, это ж не энтерпрайз, вы что, никто не делает так в больших компаниях! А как же поддержка вендора?!

  • было непонятно, что там с прошивкой sccp телефонов, будут ли они поддерживать все функции?

  • С новыми 7821 понятно только то, что они прошиты в sip - опять же будут ли все функции? А цветные VIP телефоны с панельками как?

  • непонятно, потянет ли по нагрузке астериск. Через всех знакомых и знакомых знакомых - самая большая инсталляция, которую я нашла - это 800 телефонов. Что будет на 2000? На 3000? Не будет ли при этом проблем с ivr, с записью разговоров? Сколько мощностей на это будет надо? Как будет скейлиться? При этом со всем нашим текущим компотом собрать данные по типу "сколько одновременных звонков совершается" не представлялось возможным.

  • Сможем ли мы замутить отказоустойчивость?

  • А что там с безопасностью - мы сможем обеспечить сами?

  • у меня единственный спец по астериску. Я, по сути, ставлю всё на него и на то, что он сможет

  • А ещё его не заставить писать нормальную документацию

  • У нас есть не только sip, куча Е1, которые приходят по цискам на местах, а также несколько филиалов с аналогом. Что со всем этим делать?

  • Мы вообще потянем это параллельно с внедрением сети?

Фактически, я колебалась между

  • "оставить как есть года на 2 и ждать тендер",

  • "похуй, внедряем астериск, а там трава не расти",

  • "быстро изучить fusion и внедрять его, не полагаясь на чувака из Америки"

  • "оставить на год и за это время внедрить сеть, понять что там с астериском и выбить ставку на второго спеца".

При этом тендер всё равно идет своим чередом - его уже головная компания играет.

По фьюжену - я множество раз расписывала минусы и говорила себе "нахуй эту херотень". Потом я думала, ну несложно же научиться. А спец говорит точно потянет. А астер не точно. Потом я думала, что нам к внедрению сети только учиться какой-то ботве не хватает, когда спец по астериску уже есть. И дебаг у фьюжена говно. А потом мне звонил чувак из Америки и расписывал как оно классно будет работать, я переставала быть категоричной и снова по кругу.

Бросать всё как есть и ждать у моря погоды тендера не хотелось. Люди реально страдали, говорили, что хоть какая телефония лучше, чем то, что сейчас. Когда коллеге слева надо звонить по номеру из 4 цифр, а коллеге справа по номеру из 9 цифр, когда в один и тот же филиал разным сотрудникам нужно набирать то 6, то 9 цифр - тут у кого угодно башка взорвётся. К тому же, разные сервера телефонии предполагали разные сети, вланы и разные настройки внутри сети, от чего хотелось уйти.

Пока металась - выдала спецу по астериску три модели циско-телефонов. Тест на месяц. Получится завести все основные функции - внедряем астер прям сейчас. Не получится - откладываем и страдаем. У него получилось. Не думайте, что он только этим месяц занимался, у нас как раз внедрение нового сетевого оборудования ЦОД было, а также регулярно ломался тот телефонический и сетевой монстр, что у нас был.

Да, были сложности. Наш главный согласованный контрагент "рутрекер-орг" не смог поставить нам все нужные прошивки телефонов, особенно на blf-панельки. Пршлось поднимать все связи - нас спас тот самый чувак из Америки. Да, страдала русификация. Да, правилось на лету, допиливались модули и были недовольные. Но когда недовольство в том что "вот у меня подсветка горит, а раньше не горела" или "вот у меня 2 мелодии на выбор, а раньше было 30" - это прям неплохой результат.

Итого я приняла решение внедрять Asterisk не смотря на риски, которые я принимаю (и стараюсь уменьшить):

  • я доверяю нашему специалисту, который говорит, что сервер по нагрузке вывезет, а также что он допилит напильником так, чтоб работали телефоны полноценно. (А что ели не вывезет? Тогда клеим астериски модульно по столько, сколько вывезет. А что если не допилит? Значит телефоны будут только звонить - уже лучше чем сейчас)

  • я принимаю риск того, что по первости всё завязано на одном человеке, но стараюсь это исправить в будущем (пинать его с документацией, изучить и писать документацию самой, озадачить администрированием телефонии ещё минимум одного человека)

Кстати, мне как раз в то время рассказали историю:
Настроил человек в фирме астериск. Фирма росла, человек дорос до начальника, а потом уволился. Прошло ещё пару лет. И что-то сломалось - перестали приниматься все междугородние звонки. А никто не помнит что там настроено. Попытались разобраться - не разобрались. Стали искать того человека. А он уехал в буддийский монастырь монахом постигать истины. А фирме очень надо, она бабло килограммами теряет. В общем, вышли на монастырь и вот на ноутбуке настоятеля бывший админ в келье буддийского монастыря правил конфиг. Поправил - заработало. Мораль - не завязывай на одного человека и пиши, сцука, документацию.

  • я принимаю недовольсво людей, которым нужно менять номер телефона и ввожу единый план нумерации, который раньше был на нашей половине компании, на всех

  • я начинаю пилить всех провайдеров на предоставление sip (ну там отдельная история, сейчас у нас уже около 40 филиалов приземляют телефонию в ЦОД в Москве, процесс идёт). Если это возможно только со сменой городского номера - значит надо обсуждать с нашим отделом маркетинга , что нам это правда надо. Где ничего нельзя сделать с аналогом - шлюзы Yeastar сконвертируют. Где ничего нельзя сделать с Е1 - циска остается как преобразователь сигнала и больше ничего.

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

Вот так, оглядываясь назад - это было очевидное решение, а раздумья заняли месяца полтора, не считая попыток с первым тендером (там ещё на два). Мне было довольно страшно обрубать все дискуссии и говорить начальству "мы делаем так, trust me". Через год мне высказали несколько неприятных слов про то "а хуле мы в тендере участвовали, когда всё работает". Ну, чувак, во-первых тенедер я хотела маленький и скромный, а его раздули уже не мы, а во-вторых, у меня на старте тендера было три работающих телефона и прогнозировать 100% успех я всё же не могла.

Сейчас всё работает, сервер с 8ГБ оперативной памяти тянет почти 3000 телефонов (недавно расширили, было 4ГБ памяти). Отдельно сервер sbc (тоже на астере) и отдельно под софтфоны - ждём их наплыва, а также он является резервом на телефоны. Функции почти все работают, плюс куча фич, типа интеграции с AD, справочника, back-call, веб-звонилки сделано. Спец уже не один, в какой-то степени телефонией занимаются 4 человека, что немного (совсем капельку) снимает с меня тревогу про то, что это завязано на одном человеке. Готового второго спеца мы не наняли, предложили мне забрать свободного человека и обучить. Благо, курсы по астеру стоят немного, в бюджете организации денег хватило + самообучение + обучение от нашего спеца. Документация кое-как пишется с моими пинками. В целом, спеца по астериску, случить что, найти не так сложно (в отличие от какого-нить энтерпрайзного РТУ телеком). Также можно на аутсорс отдать хорошим ребятам (не собираемся этого делать, но наличие опции греет душу).

А что если бы не заработало? Скорее всего, делали бы в урезанном виде, но единообразно. Выкраивали бы железо, искали бы спецов. На самом деле, переходный период был месяца четыре - когда непонятно, взлетит или нет. Потом уже было ясно, что всё норм.

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

Показать полностью

Сисадминский пост про успешное преодоление

Речь пойдёт про сеть, про людей и капельку про сервера. Очень длиннопост, специально для пятницы.
Несколько лет назад, я пообещала в комментах, что если разрулю ситуацию в сети организации, то обязательно запилю рассказ.

Итак, начнём.
Было начало 2020 года, ковид ещё не начался, но попа уже ощущалась. В организации работало около 4000 человек, было примерно 32 региона присутствия от Камчатки до Калининграда. Головной офис в Москве. В каждом регионе большой центральный офис и много точек по 1-2 компа на модеме/домашнем роутере с vpn. Сеть была построна между центральными офисами и ГО звездой на site-to-site ipsec на D-Link DFL. И в сети была статическая маршрутизация (тут раздался вопль ужаса). На самом деле, пока держалась какая-никакая структура, всё было не так и плохо. Но к 2020 у нас появилось много сетей разного назначения, всякие сети от безопасников, отдельный шлюз для инета с фильтрацией, каналы с соседней организацией, в общем, понимание того, что нужна динамика, уже настало.

Какие ещё были проблемы:

  • оборудование номинально стало поддерживать динамику в виде ospf в последней прошивке, но по факту поддержка сказала "забудьте, мы случайно добавили, в следующей выпилим"

  • Чаще всего был один провайдер в филиале (без резервного)

  • в 11 филиалах была внедрена IP телефония на цисках, а значит были телефоны и управляемые PoE коммутаторы. В остальных сеть была из говна и палок ( TP-Link, домашние D-Link, в лучшем случае HP1810 - те что 2013 года выпуска)

  • В головном офисе была сеть /16 на всё, кроме телефонии. То есть было деление телефония и "всё остальное", которое вообще не делилось на подсети, прям маска /16 была. Потому что я так решила в 2012 году. Ну аллё, я училась в универе, а компания была в 2 раза меньше, я признаю, что была дура)

  • Ввиду некоторых причин, к нашей компании в конце 2019 присоединилась ещё одна такая же по размеру компания. Их сеть надо было присоединять (а также домен, телефонию, почту, сайт и людей). Мы уже сидели рядом, но каждый в своей сети.

  • Управление сетью присоединяемой компании было на аутсорсе, доступа к управления сетью нам не дали, а аутсорсу платить перестали.

  • Сеть у доставшейся нам компании была не сильно то отделена в плане администрирования от сети их головной компании, а нам фактически отпилили кусок и сказали типа вот вам ЦОД и ещё 25 филиалов, но администрировать не дадим, вдруг вы сломаете? Сами будем. Но вы же понимаете, у нас своих проблем есть, нам нашу компанию надо переварить, вы пишите что вам надо а мы когда-нибудь сделаем. Может быть. Но вам управление не отдадим. Да, взламывать тоже нельзя. И конфиги не покажем. Вот картинка для понимания:

Сисадминский пост про успешное преодоление Системное администрирование, Опыт, Личный опыт, Успех, IT, Сети, Преодоление, Руководство, Мат, Длиннопост
  • У них в филиалах не было интернета, только IPVPN от провайдера и выход в инет был из ЦОДа. И вроде так звучит ничего, но скорости были 2-5 мегабита на филиал (25-60 человек) или 5-12 мегабит на 60-120 человек. И нормальный сценарий, когда филиал не работает "потому что сеть тупит"

  • Нам запретили светить наши сети в ЦОД без NAT, так как ЦОД оказался связан с нашей головной компанией, а у нас одинаковая адресация (в 2011 году мы отделяли сети и нам сказали, что никогда-никогда мы сети не будем сливать. ага-ага). И что? Из-за NAT очень плохо работает голосовой трафик, а также то, что требует коннекта напрямую к машине - центр управления касперского, например, да тот же AD. Картинка для понимания про пересечение сетей ниже

Сисадминский пост про успешное преодоление Системное администрирование, Опыт, Личный опыт, Успех, IT, Сети, Преодоление, Руководство, Мат, Длиннопост
  • Не надо думать, что головная организация нам чем-то помогала в плане людей или компетенций или быстрого согласования бюджета. Какой-накакой диалог в плане ИТ у нас только последние полтора года наладился.

  • У нас не было системы учета заявок в ИТ. Также не было выделенной первой линии поддержки (за первую линию была я и мой коллега)

  • Также сетью глобально управляла я (1 человек). К управлению сетевым оборудование в организации "А" был доступ у админов филиалов (кто хотел - ваял что-то, например, dhcp управлял, а кто-то говорил, что он вообще этим не будет заниматься и тогда всё на мне). Также на мне висела ip телефония (был чувак на аутсорсе по сложным вопросам и как раз свалил в Америку. Классно когда у тебя часовые пояса от -9 мск в Америке до +9 на Камчатке, очень бодрит. Он реагировал, но медленно). Ещё на мне полная поддержка и администрирование колл-центра на Infinity, который стал работать круглосуточно, а, ну и инфраструктура - виртуализация, домен - AD с политиками, DNS, почтовик, бэкапы, всё это в паре с еще одним коллегой. И все *nix, там по мелочи мониторинг, ftp, всякие пробы с автоматизацией. Первую линию поддержки не забываем, картриджи я уже редко меняла, но всякие сбросы пароля, "нет звука" тоже на мне. Также угадайте, кому было не лень писать документацию. Сейчас написала и сама не понимаю, как я не сдохла, читайте что было дальше))

Из хорошего:

  • у нас появился ЦОД и много серверов

  • При съебывании предыдущих арендаторов здания, мы нашли пачку цисок 2960, припорошенных строительной пылью, но живых

  • Также на складе нашли штук 15 cisco asa 5506x

  • Мы под шумок купили 1200 телефонов

  • у нас появилась своя автономка, AS в смысле (блять, я до сих пор в BGP внешний боюсь тыкать палочкой). Которой, впрочем, мы не управляли, так как доступа к оборудованию не было.

  • ю-ху, я побывала в настоящем ЦОДе! Там прикольно.

  • У нас хороший коллектив. С костяком команды мы на данный момент больше 10 лет вместе работаем. Соответственно, ребята пахали не меньше и ко мне прислушивались.

  • ИТ выделили наконец в отдельную оргструктуру и пришел исполнительный директор "из своих", в смысле долго работал у нас в ИТ, знал специфику и в целом болел за нас. До этого мы были вместе с юристами и хозяйственниками в одной структуре, классное же соседство?

  • Нам добавилось 3 инфраструктурщика из другой компании, один из них очень компетентный, это должно было разгрузить меня и коллегу

Проблемы были обозначены и до ковида и даже начинались действия по их решению:

  • Нам нужен сетевик мне в пару (я начала начальнику об этом ныть, пугать как меня переедет самосвал и всё рухнет, а также писать осторожные письма об этом же)

  • Сеть головного офиса надо разделять (я не знала без динамики - как к этому нормально подступиться, там такой клубок был, а ЦОД его ещё добавил)

  • Нам нужна система учета заявок и эникейщики на первую линию (у присоединенной компании была система, выдохнули, стали натягивать на нас. Утвердили 2 ставки на эникеев)

  • Нам нужно заменить сетевое оборудование (роутеры) и нам надо втащить в телефонию все филиалы (там нужны телефоны, коммутаторы) - начали процесс закупочной процедуры.

  • Нам нужна динамическая маршрутизация

  • Нам нужно получить управление сетью (писали пламенные письма)

  • Нам нужно утвердить новый план IP адресации, чтоб никто нигде не пересекался (спойлер - утвердили к 2022)

И тут в апреле грянул ковид. Подробно это отдельный роман надо писать, как мы пережили удаленку (попробуйте спровадить 400 человек на удаленку за 2 недели, когда это не было ещё отработано). В отдельный момент у нас было 6 видов VPN.

Добавились проблемы:

  • Текущее оборудование ко всему дохнет по ЦПУ на шифровании. У младших моделей предел 15 мегабит.

  • План по присоединению инфраструктуры новой компании был к сентябрю. Нам сказали типа "пятилетку за 2 года", мы сделали к июню, насколько помню.

  • Работать 13-16 часов в сутки нихуя не весело

Решились проблемы: наняли двух эникейщиков, но они только начали въезжать в специфику.

Только пробежалась по верхушкам проблем, а уже такой длиннопост, но не делить же историю? Сейчас небольшое отступление и перейдём к действиям!

Я бы с удовольствием в то время прочитала пост на тему "у нас жопа с инфраструктурой, мы из неё выбрались вот так". Да хотя бы просто без подробностей рассказ, что такое возможно. Я искала статьи по теме, но всё, что находила выглядело как

  1. мы делали всё вроде хорошо, но вылезали небольшие проблемки, мы потратили много денег и рабочего времени и их решили

  2. мы делаем с нуля и охеренно хорошо за много денег и крутыми спецами

  3. мы сейчас делаем хорошо, вот смотрите как. А куда делась жопа, которая была, мы не расскажем

  4. да, у нас жопа с инфраструктурой, мы всё переделали. Ах да, у нас в компании 12 человек работает. Не ИТ, всего 12

  5. у нас жопа с инфраструктурой и я уволился, зачем работать в компании, где нет смузи с облаками

Я даже всерьёз рассматривала пункт 5, но решила попробовать разгрести то, что есть. Комменты, конечно, пестрили советами "у вас плохо, а хорошо вот так". Как перейти из одного состояния в другое, не прерывая деятельность организации, силами того кто есть, преодолев бюрократию и вложившись в бюджет - вот вопрос, на который никто не мог дать ответа.

Теперь, к тому, что я/мы делали.
Буду рассказывать то, что делала и видела, в основном со своей стороны. Надо понимать, что во всех отделах наблюдалась жопа той или иной степени и все ебашили как не в себя.

Время начала 2020. Все присоединенные филиалаы пинаем на заключение договоров с провайдерами, чтоб там появился нормальный интеренет (желательно даже два). Все свои филиалы пинаем, чтоб подключали второго провайдера. Срочно расширяем в 2-3 раза имеющийся ipvpn, потому что это изменение текущего договора и гораздо проще согласовать, чем новый договор.

Перерыв на ковидную горячку, в которой мы, помимо прочего, на соплях и изоленте склеиваем инфраструктуру двух компаний. Это были тайные втыкания проводов, ебанистческие конфигурации, прокладки из каких-то промежуточных проксей и всё обмазано статической маршрутизацией. Параллельно начинается перенос инфраструктуры в ЦОД, в частности централизации сервисов из филиалов. Ну а хуле, давно пора. Нагрузка на каналы связи ещё возрастает, оборудование не вывозит, текущие подключения не вывозят.

Из загашника достали коммутаторы, все asa5606, я быстро вкурила как асы примерно настраивать (особый квест был с активацией лицензии на продвинутое шифрование) и пошла раскатывать на новые филиалы, где не было интернета. Помню, водитель привез домой пачку 6 штук, я не рассчитала и еле доволокла до лифта (они вроде маленькие, а коробки сцука тяжелые).

Где-то к июлю мы выдохнули, дендрофекальный монстр как-то работал. За это время два эникейщика втянулись в работу, а инфраструктурщики в нашу инфраструктуру. Мой коллега по первой линии стал руководителем отдела поддержки. Мне тоже отсыпали руководящую должность, правда, без сотрудников. Заработал сервис приема заявок и мы с переменным успехом пинали всех в регламент его использования, типа "нет заявки - нет проблемы".

Я разделила сеть головного офиса, выделив новую сеть /19, только разбив на подсети в этот раз. Таки накрутив статических маршрутов. Но без разделения на vlan (отдельно оставалась только телефония), так как всё было сильно вперемешку. Но, по крайней мере, всё было готово к делению.

Потом я посмотрела на свои распухшие от двух гарнитур уши и в деликатных выражениях вроде "нахуй", "ебись оно конём" и "у тебя три работника есть теперь, отъебись" отказалась от активного участия в жизни инфраструктурщиков (это где виртуализация и сервера, домен, почта, базы данных и прочее добро). Примерно в таких же выражениях сказала, что я перестаю быть за саппорт первой линии. Всем звонящим по старой памяти отвечала "у нас чудесные ребята в поддержке, я обязательно им передам, но быстрее будет если вы оставите заявку или позвоните им напрямую". Это было морально тяжело, потому что сбросить пароль - 5 секунд, настроить звук, подключить вебинар, проверить сайт, показать куда тыкнуть - минута, но это было волевое решение "я этим больше не занимаюсь".

В августе я свалила в отпуск проветрить мозги. Вернулась с четким решением, что с такой сетью жить нельзя. Что там с конкурсной процедурой на сетевое оборудование было непонятно. У головной организации было своё видение общей одновендорной сети и они его активно пихали, закупка длилась уже месяцев 8 и края видно не было. Надо сказать, руководителем направления я себя нихрена не ощущала, но, наверное в сентябре началось моё вживание в должность. Я ультимативно сказала "каждому филиалу надо купить микротик RB1100AHX4, самое позднее в октябре". Выбор был прост, он умел всё, тянул минимум гиг в шифровании, продавался в любой перди и стоил как говеный монитор, то есть покупку не нужно согласовывать с головной организацией. Можно купить по-тихому как расходку. Оглядываясь назад, нужно это было сказать в начале года, а не терпеть столько.

Я вооружилась бумажкой с фломастерами и рисовала план с ебучими стрелочками, чтобы разложить маршруты. На микротах на каждый филиал выделалась серая AS 650xx, чтоб суммировать маршруты на выходе. В результате у меня был кусок новой сети с ospf и кусок старой сети со статикой. На микротах уже более-менее адекватно срабатывал failover на разных провайдеров. Переключение каждого филиала на динамику - это "тут маршруты вычищаем, с трех серверов вычищаем, добавляем общий на микрот. А блин, забыли ещё два сервера специально для них, да ёпрст". Надо понимать, у каждого свои особенности и наследия, хватало там всякого. Был и саботаж с подключением провайдеров, с покупкой микротов. Были свои гуру, которые пихали мнение типа "вот вы нам только работу изобретаете". Я училась работать с людьми.

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

Всё это причесывалось где-то месяцев 5. Стало чуть лучше. Почему чуть? А мы так и не имели управления ни сетью ЦОДа, ни сетями присоединенных филиалов. Да, на местах в старой сети осталась только телефония, которую нам некуда было посадить, но всё же.

25 декабря 2020 нам внезапно привезли оборудование. В том числе, для полной замены сети ЦОД. Головная организация решила, что нахуй циски, везде должен быть хуавей (спойлер - не получилось от цисок полностью уйти). Почему всё тянулось и резко решилось? В конце года надо было потратить денег, что-то там с налогами. Ну что, можно менять? Нет! Теперь тендер на внедрение. Ну, резон был, с сетью ЦОД я ни разу не работала, с хуавеями тоже. Головная организация отыграла себе тендер на внедрение всей сети, а у нас денег было мало, мы договорились, что нам внедрят ЦОД, Москву и 2 филиала в регионах. Дальше мы посмотрим и сами, всё сами. Как вы убедились, тендер процесс не быстрый, я не пожалела, что внедрила микроты.
За прошедшее время в головной организации дважды уволилась команда сетевиков, но в 2021 году там пришел новый руководитель и случилось несколько положительных событий:

  • Сдвинулось с мертвой точки согласование общего плана ip адресации.

  • Нам таки выдали доступ почти ко всему сетевому оборудованию.

  • Никто не стал залупаться и тендер на внедрение отыграли месяцев за 7 (небывалая скорость).

Стало реально полегче. Также на оф сайте хуавея был тогда выложен курс типа ccna, но для хуавея и на английском, абсолютно бесплатно. Я успела прослушать и как-то разобраться в консоли. Освоила взрослую cisco ASA, которая стояла в ЦОДе.

Никогда ранее я не сталкивалась с работой интеграторов (как-то мы всё сами внедряли). Мои ожидания: придут взрослые дяди, скажут как надо, быстро сделают всё красиво, как в лучших домах, напишут хорошую документацию, оставят понятную инструкцию и проведут обучение не хуже вендора.

Реальность: шесть месяцев собирают информацию, спрашивают тебя "что вы хотите?". Без четкого ТЗ результат ХЗ и планируешь в основном ты. Как в лучших домах никто не делает, на вопросы отвечают уклончиво. Выясняешь сам (блять, нам сосватали стеки, сейчас думаю, что с этим делать, разбирать или как). Когда внедряют - как все люди, путают адреса, имена, делают не совсем то, что договаривались. Тесты на отказоустойчивость проводить заставляешь чуть не силой. Итого до сих пор вычищаем хвосты, когда при определенном редком стечении обстоятельств филиал падает. С другой стороны, нам внедрили ЦОД, я бы надорвалась. Там было сложно, например, скрестить ospf с eigrp, причем с фильтрами и чтоб не кольцевалось. BGP опять же. И вообще были отзывчивы, когда я уронила ЦОД в 9 утра понедельника не отказались помочь. Обучение состояло в ответах на вопросы, которые мы успели придумать. Схему зато нарисовали хорошую, хотя и не совсем полную. Инструкции.. какие инструкции, вот вам доки с сайта хуавея. Если что, и обучение и инструкции были в договоре.

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

Так вот, в сентябре 2021 начался процесс по изучению-перед-внедрением. В это же время ставлю вопрос ребром: или ещё один сетевик или внедрение будет года два идти, а я тут сдохну. Причем не абы какой джун-сетевик, а мне нужен конкретный спец из конкретного филиала, который в сетях шарит не хуже меня, а в линуксах получше. В тот момент он менял картриджи в филиале и мышки перетыкал, а на досуге внедряел астериск на соседнем заводе и делаел красиво там, где может. Дожала. Дали мне ставку, уломали отпустить человека директора филиала, он оттуда с радостью сбежал в феврале 2022, как раз к началу активных действий по внедрению. Так у меня появился супер-компетентный специалист, который ебашит как стадо бессмертных поней. Его только притормаживать надо, чтоб спал иногда)

Надо сказать, если по сети забрезжил свет в конце туннеля, то телефония выглядела как сеть пару лет назад. Были в ходу разная длина внутреннего номера, пересекающиеся номера, разделенные префиксом, три отдельных астериска, 11 cisco CUCME нерасширяемых, 1 cisco CUCM с просроченными лицензиями без ivr, которым мы не управляли (последний не павший бастион), kamailio и, простихоспади, вечнолагающий fusionPBX. А, к этому ещё цеплялся колл центр через связку. Трафик мог прийти в филиал, сходить в цод головной организации через наш цод, попасть потом в головной офис, прослушать ivr на фьюжн, опять вернуться в цод и распределиться на внутренний номер филиала. Надёжно, как китайские часы.

Головная организация "С" была окрылена идеей построить единую телефонию для себя и всех дочек, для чего готовила тендер (у вас зашевелились волосы?). Астериск их руководством категорически отметался как не-энтерпрайз решение. Даже если его внедрят единым паком и будут поддерживать. В этот момент я посмотрела на нашу телефонию, на то как страдают люди. Вспомнила как проходил тендер для сетевого оборудования. И озвучила "мы, конечно, готовим с вами документацию на тендер, решение головной компании - закон. Но сейчас мы подумали и я решила, что мы внедряем такой не энтерпрайзный, зато бесплатный и гибкий астериск. Как тендер отыграете, как деньги найдем, так сразу энтерпрайз, но нам вообще прямо сейчас надо как-то жить".

Итак, к внедрению у нас были всего 61 точка (в некоторых регионах несколько больших точек) в каждом из часовых поясов РФ и ЦОД. К июню 2022 силами нас и интеграторов совместно внедрили ЦОД, две точки в Москве и два региона. Оставалось ещё 57 и план "к новому году". Внедрения филиала состояло из собственно замены сетевого оборудования, переключения его туннелей на ЦОД, перекоммутирования по схеме, понижения контроллера домена, смены ip адресации (да, мы утвердили план!), перехода телефонии на астериск (от филиала требовалось сбросить телефоны или расставить новые), а также иногда ещё мы переключали провайдера телефонии в ЦОД, так как начали централизацию и в этом направлении. Также все одинокие точки филиалов в 1-2 компа переключаются напрямую на OpenVPN в ЦОД (которые раньше были зацеплены на филиал по L2TP). В филиале по дефолту есть одн, иногда два админа, которые работают руками на местах, всё. Да, уровень местных админов выше, чем у эникеев, но в массе не сильно. Со стороны головного офиса: я в Москве и наш бессмертный пони со сдвигом на +2 часа.

Летом я выбила ещё одного человека на саппорт астериска - он во внедрении не участвовал, но уже готовил конфиги по телефонии.

Сначала мы внедряли 3 филиала за выходные. Потом у нас стали падать туннели и мы месяц медитировали на wireshark, откатив филиалы частично обратно. Обратились к интегратору и ещё через 2 недели всё решилось одной строчкой в конфиге. Потом мы набрали опыт, наработали шаблонные конфиги, написали подробные инструкции.

Где-то с августа это выглядело как-то так:

  • Берём 8-10 филиалов. Рассылаем инструкцию.

  • Готовим конфиги и неделю их раскатываем на устройства в Москве.

  • Отсылаем технику и, ели надо, телефоны в филиалы и от недели до двух она едет.

  • В это время готовим телефонию, отвечаем на вопросы, внедряем в будни какой-нибудь маленький и далёкий филиал вроде Чукотки, где админ согласен в его ночь поработать.

  • Раз в 3-4 недели внедрение на оба выходных. Субботу начинает в 6 по Москве коллега, я присодиняюсь в 8, заканчиваем в 18 и 20 соответственно, просто нон-стопом. Воскресенье в лайтс режиме доделывем и проверяем работоспособность, то есть начинаем в 8 и заканчиваем часов в 17, даже обедаем в середине (по-разному было, иногда и второй день активный). При этом, часть оборудования на местах ре-юзалось, к части мы неакуратно теряли доступ и с консолью восстанавливали (вообще по телефону попасть в romon циски не так и быстро - угадать момент по телефону, когда кнопку отпустить, когда break нажать, иногда 3-4 итерации надо).

Последнее внедрение было 11 декабря 2022. Уложились. У меня за год официально 26 отработанных выходных, из них 24 под внедрение. К этому несколько ночей в ЦОДе и пару выходных в начале, где мы не рссчитали и работали 2 дня, хотя планировали один.

Длинные итоги:

  • Сейчас с сетью более-менее хорошо. Да, мы наводим красивости и вычищаем хвосты, но в целом вообще ОК.

  • Телефония единая на астериске, колл-центр остался где был. Тендер головной организации ещё, кажется, не кончился.

  • Коллега мой, бессмертный пони, так обмазал нам астериск сервисами, что никакой энтерпрайз рядом не валялся. Ну штырит человека работать.

  • Сколько мы потратили денег (и сколько сэкономили) я считала и давала начальству в цифрах, там было интересно.

  • За это время, были не только описанные события: была текущая работа, локальные проблемы - у нас сдохло два кондея одновременно в серверной, падал мастерхост, если кто помнит, мы теряли бэкапы, нас DDoS'или, мы перевозили сайт и продолжали централизацию. Дважды у меня увольнялся чувак, поддерживающий колл-центр. Выходили новые требования закона и требования от безопасников. Санкции не обошли стороной тоже. Много чего было.

  • Сейчас я могу себе позволить "не беспокоить" ночью на телефоне (кроме белого списка, но всё же) и полностью отключаю рабочую симку в отпуске. Тележка остаётся для экстренных случаев, но их не было. За последние полгода мне звонили ночью один раз.

  • Да, теперь половину моего рабочего времени составляют ебучие бумажки и совещания. Зато я снова нашла время обновить документацию и наваять статей во внутеннюю вики.

  • У меня теперь группа из 5 человек или 3,8 ставки: из меня; спеца, который шарит в сетях и линухах и астериске как боженька; чувака, который сидит на саппорте астериска, но и к сетям его привлекаем уже; на 0,3 ставки сотрудник филиала с временем +6мск ебашит телефончики ночами в астериске, вот решили его нагрузить экстренным саппортом сети на Дальнем Востоке ещё; и чувак, который на 0,5 ставки поддерживает колл-центр.

  • Что на нас? Сеть филиалов и ЦОД, филиалы теперь не управляют сетью центрального офиса вообще. А мелкие точки тоже в плане забрать к себе на администрирование. Телефония вся, с новыми сервисами. Колл-центр. Ну то, что к сети относится: DNS, DHCP. А также линухи с проксями на nginx, частично мониторинг и мелкие виртуалки под внутренние нужды с линухами. Я по старой памяти могу чего-то помочь с инфраструктурой, которую помню, но редко. В WMVare вот вообще не лезу.

  • Были ли ошибки? Да дохрена. Не ошибается тот, кто ничего не делает.

  • Не я ли была причиной изначальной жопы? Отчасти да, я не самая умная была в 22. И не умела настаивать на своем решении в 26. Ну а начальство могло нанять более копетентных специалистов? Могло, но не стало. Также обстоятельства извне внесли достаточно хаоса, чтобы не считать себя самой плохой.

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

  • Меня неожиданно вштырило быть типа руководитетем. В смысле, принимать решения как будет развиваться та инфраструктура, за которую я отвечаю, и реализовывать это. Даже немного влиять на инфраструктуру в целом. То есть, я этим и раньше занималась, но теперь на новом уровне для себя это открыла. ITIL тут курсы прослушала, интересно было. Куда-то делось моё неумение общаться с людьми, я теперь могу полдня пиздеть по телефону и не ёбнуться. Хотя материться на работе на отучилась.

Я не гонюсь за рейтингом, поэтому одним постом, надеюсь, кому-то было интересно, а кого-то вдохновит или поддержит морально мой опыт.

А, ну и кому мало: бонус в комментариях!

Показать полностью 2

Сисадмин: "секреты профессии которые вам не расскажут"

Ну или расскажут, я вот, например.

Я сисадмин.
Я тоже не знаю как делать эту хрень (но я умею пользоваться поиском).

Я делаю эти три команды на корневом роутере полтора часа не потому что смотрю сериал в процессе, а потому что сначала гуглю возможные последствия и хочу досканально понять что они делают и как повлияют на всё. Потому что пятая точка и большой опыт подсказывают мне, что я могу уронить большой кусок инфраструктуры, если я не предусмотрю чего-то. Хуже того, они же мне подсказывают, что я всегда могу не предусмотреть чего-то и всё равно йобнуть чего-нить (спасибо, что есть commit trial - штука которая всё откатывает если ты потерял контроль врезультате своих действий, но, к сожалению, есть она или её аналоги не везде).

И мне всегда ссыкотно делать большие изменения первый раз, но кто кроме меня то. Иногда зову коллегу и нам ссыкотно вдвоём. Но мы делаем.

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

Иногда самая быстрая диагностика полного пиздеца - выключить всё и включать по одному большому куску. Локализовать кусок, выключить в нем всё и включать по одному устройству. Да, вот так топорно.

Довольно часто я не знаю, сработает ли эта конкретная штука/настройка или нет, потому что я не знаю всю систему наизусть (а документированы некоторые системы тоже.. так себе). Я примерно представляю, что хуже не станет, и просто делаю и смотрю что будет. И так несколько раз. Иногда смотрю разными интсрументами и снимаю лог. И делаю чуть по другому. И так раз за разом, пока не найдется решение или не будет достигнуто понимание, как оно работает. Это тоже часть работы.

Чем больше раз ты сделаешь предыдущий пункт, тем чаще сможешь быстро найти нужную комбинацию настроек, исходя из "чуйки", но на смом деле, это накопленный опыт понимания работы определенных систем.

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

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

Если у вас хороший интуитивно понятный интерфейс в клиенте софта, это не значит, что админка такая же удобная. Часто на админку кладут болт и делают по остаточному принципу. Не работающий копи-паст и не расставленные таб-индексы не редкость, а только вершина айсберга обычно. Страдаем, но жрем кактус ради пользователей. Потому что удобно должно быть не нам, а бизнесу.

В большой системе (компании), которая выросла сама собой в течение многих лет и стала работать круглосуточно нельзя всё сломать и сделать хорошо "как в лучших домах, по регламентам и itil". Вернее, можно попробовать создать рядом копию системы "хорошо" и туда переселить сотрудников, но это ОЧЕНЬ дорого и таких примеров я не знаю. Можно поэтапно улучшать разные куски и двигаться в более хорошую сторону так далеко, сколько ресурсов у компании есть. Всё.

Довольно часто невозможно принять наилучшее решение. Потому что у вас недостёт информации (о системе, о компании, просто опыта и т.д.). Я принимала плохие решения, последствия которых выплывали через много лет. И это нормально, решение продержалось 6 лет и тогда казалось оптимальным. Тот, кто  оглядываясь назад не может сказать "я ошибался", тот не развивается. Обычно, лчучше принять какое-то решение, чем не принимать никакого.

Показать полностью

Пример маленькой автоматизации zabbix-Mikrotik-ELK

Итак, в прошлом посте читатель узнал, что у меня завелось 55 микротиков. За прошедшее время, по заветам комментаторов, был развернут ELK Stack. Это такая штука для сбора логов со всего, что может эти логи слать. ELK = Elasticsearch + Logstash + Kibana.

Настраивала вот по этим двум статьям, в принципе там всё понятно. Раз и два.


Но помним, что микротиков сильно больше пары штук – это раз. Второе, если прописывать все их в фильтры сборщика логов, то появляется ещё одно место, куда надо что-то писать руками при вводе микротика в эксплуатацию, что не есть хорошо. Да и лень мне было прописывать их все. Короче, во мне стал зарождаться DevOps.


Задача - чтобы в заббиксе мы микротик завели – а логи с него автоматом бы полились и уже с меткой mikrotik.


Я слегка погружусь в теорию, чтобы было понятнее, что мы делаем. Итак, развернут ELK – изначально логи попадают в logstash, где с ними можно что-то сделать. Например, мы отбираем по некоторым критериям логи микротиков и вешаем на них метку «Mikrotik». Этим критерием у меня является IP – то есть «если ip из вот этого перечисления, то это микротик». Если бы у нас был ELK только для микротиков – мы бы просто вешали метку на весь трафик или обошлись без неё, но мы потом хотим добавлять еще логи всякого, например, виндовых серверов. После обработки логи попадают в elasticsearch, где мы их просматриваем с помощью Kibana (это типа веб-морда).


Для начала нам надо получить список микротиков из zabbix. Я использую для этого скриптик на питоне, который получает ip по группе и сразу генерирует кусок конфига, который будет в logstash filter.


Сперва надо установить модули zabix для питона:

apt install python3-pip

pip3 install pyzabbix


Теперь нам надо получить id группы в zabbix – его можно посмотреть в адресной строке браузера на странице группы – там в конце будет что-то типа groupid=65


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

Пример маленькой автоматизации zabbix-Mikrotik-ELK Системное администрирование, DevOps, Zabbix, Mikrotik, Длиннопост

Получается строка вида «if [host] in ["10.1.1.254", “10.2.2.254”]{»


Теперь её надо вставить в правильное место конфига logstash. Чтобы этого добиться, я ставлю метку #MIKMIKMIK туда, куда будет вставлена получившаяся строка.

Вставлять будем с помощью Ansible, один раз вставится, потом будет проверяться на соответствие. Собственно из-за этого и выбран Ansible – он сам будет проверять наш конфиг на соответствие и вносить изменения только, если они есть.


Вот так выглядит /etc/logstash/conf.d/filter.conf до первой работы анзибля

Пример маленькой автоматизации zabbix-Mikrotik-ELK Системное администрирование, DevOps, Zabbix, Mikrotik, Длиннопост

Теперь собираем котлету вместе. Делаем playbook в ansible, который запустит нам скрипт, потом получившийся конфиг вставит в конфиг logstash, и если зафиксированы изменения – перезапустит службу. Со службой я долго не могла понять – почему перезапуска не происходит и ansible отваливается по timeout – ему просто не хватало прав.

write_logstash.yml:

Пример маленькой автоматизации zabbix-Mikrotik-ELK Системное администрирование, DevOps, Zabbix, Mikrotik, Длиннопост

Ну и запихиваем скрипт в крон делаться каждый час.

15  *  *  *  * ansible-playbook /usr/scripts/write_logstash.yml


Опытный читатель спросит – и что же, нам теперь на 55 микротиках настраивать логирование? И мы возвращаемся к предыдущему моему посту (и понимаем, зачем нам это было надо). Вот пример настройки лог-сервера, при этом в команде к каждому микротику указывается его IP в качестве источника данных. Без этого у меня автоматом выбирался служебный ip с интерфейса ip-ip туннеля и это было неудобно.

Пример маленькой автоматизации zabbix-Mikrotik-ELK Системное администрирование, DevOps, Zabbix, Mikrotik, Длиннопост

Ну и уровень логирования настраивается так же, только команду заменить.


В итоге мы получили что хотели – достаточно добавить микротик в заббикс и настроить на нем пересылку логов, а в ELK оно попадёт автоматом с нужной меткой.


Получился маленький кирпичик автоматизации, но путь в DevOps иногда начинается с одного шага..


Код текстом.

Показать полностью 4

Ansible для Mikrotik: бэкапы по identity и псевдо-иммутабельность

Внезапно появилось у меня 50 микротиков по филиалам. Задача – настроить бэкап в систему контроля версий и получить возможность выполнить какую-то настройку на всех микротиках, где этой настройки нет. Вторая задача стояла – научиться что-то делать в ansible. Тут ansible не содержит особых преимуществ перед обычным bash скриптом, кроме, может, скорости работы за счет параллельности выполнения.


Все мануалы, что я нашла, содержали инструкцию по бэкапу в ansible одного микротика и такие типа «экстраполируйте сами». Ну зашибись, вся проблема в том, что имя бэкапа задаётся вручную, а если микротиков много, то как-то сделанные бэкапы надо различать.


В микротике есть поле identity и логично было бы именем из identity и называть бэкап. Но вначале я не нашла как его сохранить в переменную и пошла задавать переменные вручную. Кому интересно про identity – переходите к способу 2.


Я опущу, как ставить ansible, задавать пароли и шифровать их, это как раз легко гуглится.


Способ с заданием имени бэкапа в переменной вручную.

ansible_user должен иметь доступ на микротик full, а сервер, с которого запускаете yml должен иметь доступ по ssh на микротик. При этом либо надо разок законнектиться по ssh до этого и сохранить ключи, либо отключить проверку ssh ключей в ansible.


Пикабу съедает пробелы. Ссылка на код текстом будет в конце

Ansible для Mikrotik: бэкапы по identity и псевдо-иммутабельность Mikrotik, Системное администрирование, Длиннопост

Но всё же меня глодала мысль, что можно использовать identity, а тут удачно работа оплатила курсы по всяким там девопс штукам и мне рассказали про register. Так что нет ничего невозможного, смотрите далее.


Способ с бэкапами микротика по identity

Тут проблема в том, что stdout_lines возвращает штуку типа [[u’name: Kostroma]] и как я ни крутила – как к массиву я к ней обратиться не могу. Так что немного через задницу (буду рада, если подскажете красивое решение) из этой строки выковыривается строка с непосредственно identity.


Теперь убираем в hosts file_name

Ansible для Mikrotik: бэкапы по identity и псевдо-иммутабельность Mikrotik, Системное администрирование, Длиннопост

Про то, как делать текстовый бэкап – в примере 1, скрестить ужа с ежом можете сами.

Мой скрипт по запихиванию в систему контроля версий и отсылки на почту. Вот тут я писала подробнее как настроить SVN


#!/bin/bash

now=$(date +"%d_%m_%Y")

rm /usr/scripts/log.txt

ansible-playbook --vault-password-file /etc/ansible/vault_pass_file /usr/scripts/mik-backup.yml >> /usr/scripts/log.txt

cd /usr/svn_backup_repo/DFL_BACKUPS

svn add mikrotik/* --force -q >> /usr/scripts/log.txt

svn commit -m "added backups $now" >> /usr/scripts/log.txt

/usr/bin/mail it@mydomain.ru < /usr/scripts/log.txt -s "Отчет о бэкапах Mikrotik"


Иммутабельность – это неизменность. То есть если уже, например, в файле есть такие изменения, то второй раз они не делаются. Это то, в чем фишка Ansible и то, что не реализовано для микротиков (так как например в firewall важен порядок применения – это одна из причин, почему в его конфиге не поддерживается иммутабельность).


Теперь сюжет из жизни: мне понадобилось вкатить на все микротики одинаковый фильтр сетей OSPF – оставить только серые сети и фильтрануть по маске 10.0.0.0/8. При этом на каких-то микротиках я это уже делала, но не помню на каких. Прощелкать 50 штук – ну такая себе забава.


Итого сливается бэкап в текстовом виде, идет поиск по нужной строке и если она не найдена, то выполняем команду. А если найдена – ничего не делаем. Такая вот псевдо-иммутабельность получается. Да, один скрипт – одна команда, что не очень удобно, под список команд надо дорабатывать.

Ansible для Mikrotik: бэкапы по identity и псевдо-иммутабельность Mikrotik, Системное администрирование, Длиннопост

Сылка на весь код текстом вот

Ну и я не претендую на гуру, только-только начала щупать Ansible, надеюсь кому-нибудь пригодится.

Показать полностью 3
Отличная работа, все прочитано!