Результат вроде тот же, а звучит совсем иначе
Сегодня опять столунулась с незнанием ИТ филиала базы по сетям. Злая была жутко 🤬
Сначала хотела написать в общий чат сообщение в стиле:
"Коллеги, если продолжится ситуация, в которой некоторые из вас не могут набрать в яндексе "калькулятор сетей онлайн" и понять результат того, что калькулятор выдаёт, то всех будет ждать принудительный вебинар про основы сетевой адресации, где будем долго изучать и считать маски, вспомним про бинарные логические операции и т.д."
Потом посмотрела на это и всё стёрла, не стала отправлять. Наезды на людей не особо работают, да и сами мы их на работу приняли с такими знаниями. Запустила в чате анонимный опрос "нужен ли вебинар по основам сетей?". Внезапно получила 74% голосов, что нужен. Вебинар уже запланирован, вроде и на людей не сорвалась, и может даже ситуация улучшится. Маленькая победа.
Хотела вернуться к вам с каким-нибудь большим постом, но пока так.
Всем большое спасибо, что не отписались, а кто-то даже подписался).
В комментах бонус история не про ИТ
Сегодня опять столунулась с незнанием ИТ филиала базы по сетям. Злая была жутко 🤬
Сначала хотела написать в общий чат сообщение в стиле:
"Коллеги, если продолжится ситуация, в которой некоторые из вас не могут набрать в яндексе "калькулятор сетей онлайн" и понять результат того, что калькулятор выдаёт, то всех будет ждать принудительный вебинар про основы сетевой адресации, где будем долго изучать и считать маски, вспомним про бинарные логические операции и т.д."
Потом посмотрела на это и всё стёрла, не стала отправлять. Наезды на людей не особо работают, да и сами мы их на работу приняли с такими знаниями. Запустила в чате анонимный опрос "нужен ли вебинар по основам сетей?". Внезапно получила 74% голосов, что нужен. Вебинар уже запланирован, вроде и на людей не сорвалась, и может даже ситуация улучшится. Маленькая победа.
Хотела вернуться к вам с каким-нибудь большим постом, но пока так.
Всем большое спасибо, что не отписались, а кто-то даже подписался).
В комментах бонус история не про ИТ
👍21👏2
Маленький грязный лайфхак
Случается так, что нужно выполнить много однотипных команд. Может, набить ACL на сетевом устройстве, может в iptables поблочить десятка три сетей, может забить пару сотен строк в БД, может завести резко много учеток openvpn.
То есть, у нас есть набор данных в столбцах и надо сделать с этим набором однотипные текстовые команды.
Понятно, что пяток таких команд скорее всего все выполнят вручную, меняя параметры.
Понятно, что если вы мастер скриптов, то вы быстренько накидаете скрипт, который или команды выполнит, или выдаст вам тестовый файл, откуда их можно скопипастить.
Когда данных прям тысячи строк, то тоже без скриптов сложновато.
Но когда данных вроде и не много, но и не мало, когда мастером скриптования вы не являетесь, а задача срочная, то получается ловушка. Вручную будет быстрее, но будут ошибки и просто захочется повеситься. А изучать питон/bash/powershell с нуля нет времени: задача срочная.
На помощь вам выезжает excel и функция СЦЕП(). Как это работает: бьёте команду на блоки и разносите их по столбцам.
Например:
Первый столбец
insert into "test_table" ("name","mail") values ("
Второй столбец пропустить под данные с именами
Третий столбец кавычка-запятая-кавычка
","
Четвертый столбец пропустить под данные e-mail
Пятый столбец
");
И финалочка - в шестом столбце функция СЦЕП с первого по пятый. В шестом столбце у вас соберётся полная команда вроде
insert into "test_table" ("name","mail") values ("ivanov.ivan","ivanov@domain.ru");
Потом собственно вставить данные и растянуть все команды на весь столбец. Всё, что нужно: не забыть про кавычки, запятые и пробелы при разбиении на блоки команды.
Все, кому показываю, делают глаза какающего кота и такие "а что, так можно было?". Ну ёлки, если ты не умеешьпрограммировать писать скрипты, то включи хоть немного смекалки! А то больно смотреть иногда на мучения.
Дополнительный грязный приёмчик: если у вас excel жрёт спецсимволы или "+" пытается перерасти в формулу и вы не знаете что с этим делать - выделяете под проблемный знак столбец, ставите туда сочетание, не встречающееся в командах, типа "ЖЖЖ". Потом итоговый список команд копируете в блокнот и делаете поиск-и-замена "ЖЖЖ"-> "+" или что там вам надо. Всё.
Скрипты, автоматизация, это конечно нужно и важно. Но иногда быстренько набить команды и не сойти с ума нужнее в моменте. Надеюсь, кому-то поможет.
Случается так, что нужно выполнить много однотипных команд. Может, набить ACL на сетевом устройстве, может в iptables поблочить десятка три сетей, может забить пару сотен строк в БД, может завести резко много учеток openvpn.
То есть, у нас есть набор данных в столбцах и надо сделать с этим набором однотипные текстовые команды.
Понятно, что пяток таких команд скорее всего все выполнят вручную, меняя параметры.
Понятно, что если вы мастер скриптов, то вы быстренько накидаете скрипт, который или команды выполнит, или выдаст вам тестовый файл, откуда их можно скопипастить.
Когда данных прям тысячи строк, то тоже без скриптов сложновато.
Но когда данных вроде и не много, но и не мало, когда мастером скриптования вы не являетесь, а задача срочная, то получается ловушка. Вручную будет быстрее, но будут ошибки и просто захочется повеситься. А изучать питон/bash/powershell с нуля нет времени: задача срочная.
На помощь вам выезжает excel и функция СЦЕП(). Как это работает: бьёте команду на блоки и разносите их по столбцам.
Например:
Первый столбец
insert into "test_table" ("name","mail") values ("
Второй столбец пропустить под данные с именами
Третий столбец кавычка-запятая-кавычка
","
Четвертый столбец пропустить под данные e-mail
Пятый столбец
");
И финалочка - в шестом столбце функция СЦЕП с первого по пятый. В шестом столбце у вас соберётся полная команда вроде
insert into "test_table" ("name","mail") values ("ivanov.ivan","ivanov@domain.ru");
Потом собственно вставить данные и растянуть все команды на весь столбец. Всё, что нужно: не забыть про кавычки, запятые и пробелы при разбиении на блоки команды.
Все, кому показываю, делают глаза какающего кота и такие "а что, так можно было?". Ну ёлки, если ты не умеешь
Дополнительный грязный приёмчик: если у вас excel жрёт спецсимволы или "+" пытается перерасти в формулу и вы не знаете что с этим делать - выделяете под проблемный знак столбец, ставите туда сочетание, не встречающееся в командах, типа "ЖЖЖ". Потом итоговый список команд копируете в блокнот и делаете поиск-и-замена "ЖЖЖ"-> "+" или что там вам надо. Всё.
Скрипты, автоматизация, это конечно нужно и важно. Но иногда быстренько набить команды и не сойти с ума нужнее в моменте. Надеюсь, кому-то поможет.
👍7👏3🤔2
Пост-ответ
Мне к посту про вебинар прилетел комментарий, на который бы хотелось ответить постом.
Вот он:
Я тут подумал над этим постом... Вначале понравилось, очень мило. Потом понял, что ситуацию надо шире рассматривать. В бытность руководства ИТ поддержкой, я сам собеседовал кандидатов. Если бы я искал сисадминов, базовые знания сетей были бы обязательны. Это ошибка ваша либо HR - у вас не компетентный сотрудник. Навешивать на вас (главный админ организации?) обязанность обучать некомпетентных сотрудников - трата вашего драгоценного времени.
С одной стороны, человек на 100% прав - ошибка менеджмента или hr. Вот без шуток, если абстрагироваться, то и не поспоришь.
Я, лет в 25, когда узнала про всякие такие штуки, тоже любила так рассуждать. А в 29 уже считала себя достаточно познавшей жизнь, чтоб раздавать такие комменты в интернете (это про меня, без желания как-то принизить автора комментария). А потом уяснила, что реальность - это немного сложнее, чемрозовые пони идеальный мир в моей голове. Сейчас мне 33 и чую, это была не последняя перестановка у меня в сознании.
Я попытаюсь не превратить пост в оправдания.
Вот пара причин, по которым такой сотрудник мог оказаться на своём месте:
Компания купила другую компанию вместе с производством и людьми. Люди, внезапно, остались работать, где работали, потому, что производство не должно останавливаться. Раньше они как-то работали? Работали. Раньше были другие процессы, другие kpi, всё-таки производство будет перестраиваться под процессы нового владельца. Поверьте, в процессе интеграции не до переаттестации людей и не до поиска новых айтишников.
В некоторых местах зарплата соответствует средней по региону. В связи с последними веяниями, все айтишники, у кого в порядке мозги и самодисциплина, уже прошли курсы (питон/администратор линуха/сотрудник ТП за 2 месяца) и удалённо работают на Москву с зарплатой х2 от среднего по региону (минимум). И вот вам нужен эникейщик в каком-нибудь отдалённом регионе РФ. Вы берёте весь хэдхантер, авито, "подслушано Усть-пердюйск" и получаете 20 соискателей, которые хоть каким-то боком ищут работу в сфере админства, поддержки и т.д. Из них 10 согласны на ваши условия работы. Собеседуете, остаётся 6, кто ответил на что-то айтишное хотя бы как-то. И вот выбираете из кандидатов. Пул ответов на вопрос "зачем нужен DNS?"
1. Чтоб авторизовать пользователей
2. Это настройка от провайдера
3. Чтоб работал интернет
4. Не знаю, но я обучаемый
5. Этим я не занимался
6. Чтоб работал сайт
Очевидно, что 2,3 и 6 более перспективны, задаём наводящие вопросы. Потом смотрим на ответы "зачем нужен DHCP?" И получаем примерно ту же картину. Не надо думать, что я прошу что-то сложное, но хоть статью в вики можно прочитать перед собесом? Это у всех опыт работы ещё релевантный указан.
И вот тебе надо выбрать сотрудника или ехать самому работать в Усть-пердюйск за среднюю зарплату по региону. Кончились кандидаты, физически. На сколько нужно поднять зарплату по таким регионам, чтоб пришли компетентные сотрудники? А сколько стоит то, что я проведу вебинар на 30 таких сотрудников? Вопрос открытый, но второе видится мне более дешевым.
А ещё в некоторых случаях тебя могут и не спросить, берем ли кандидата. Или не прислушаться к твоему мнению. Или тебе такие в наследство достались сотрудники и не ты их нанимал. А может ты им вообще не начальник, но дело с ними иметь надо по работе. Бесусловно, нужно пытаться сделать ситуацию лучше там, где можешь. Не без этого. Обучение, кстати, это тоже исправление ситуации.
А самое страшное для осознания то, что большая компания от этого всего не развалится. Ну или, по крайней мере, сильно не сразу. Да, возможно будет пострадывать, но кого-то переварит, кого-то выплюнет и будет работать дальше)
Мне к посту про вебинар прилетел комментарий, на который бы хотелось ответить постом.
Вот он:
Я тут подумал над этим постом... Вначале понравилось, очень мило. Потом понял, что ситуацию надо шире рассматривать. В бытность руководства ИТ поддержкой, я сам собеседовал кандидатов. Если бы я искал сисадминов, базовые знания сетей были бы обязательны. Это ошибка ваша либо HR - у вас не компетентный сотрудник. Навешивать на вас (главный админ организации?) обязанность обучать некомпетентных сотрудников - трата вашего драгоценного времени.
С одной стороны, человек на 100% прав - ошибка менеджмента или hr. Вот без шуток, если абстрагироваться, то и не поспоришь.
Я, лет в 25, когда узнала про всякие такие штуки, тоже любила так рассуждать. А в 29 уже считала себя достаточно познавшей жизнь, чтоб раздавать такие комменты в интернете (это про меня, без желания как-то принизить автора комментария). А потом уяснила, что реальность - это немного сложнее, чем
Я попытаюсь не превратить пост в оправдания.
Вот пара причин, по которым такой сотрудник мог оказаться на своём месте:
Компания купила другую компанию вместе с производством и людьми. Люди, внезапно, остались работать, где работали, потому, что производство не должно останавливаться. Раньше они как-то работали? Работали. Раньше были другие процессы, другие kpi, всё-таки производство будет перестраиваться под процессы нового владельца. Поверьте, в процессе интеграции не до переаттестации людей и не до поиска новых айтишников.
В некоторых местах зарплата соответствует средней по региону. В связи с последними веяниями, все айтишники, у кого в порядке мозги и самодисциплина, уже прошли курсы (питон/администратор линуха/сотрудник ТП за 2 месяца) и удалённо работают на Москву с зарплатой х2 от среднего по региону (минимум). И вот вам нужен эникейщик в каком-нибудь отдалённом регионе РФ. Вы берёте весь хэдхантер, авито, "подслушано Усть-пердюйск" и получаете 20 соискателей, которые хоть каким-то боком ищут работу в сфере админства, поддержки и т.д. Из них 10 согласны на ваши условия работы. Собеседуете, остаётся 6, кто ответил на что-то айтишное хотя бы как-то. И вот выбираете из кандидатов. Пул ответов на вопрос "зачем нужен DNS?"
1. Чтоб авторизовать пользователей
2. Это настройка от провайдера
3. Чтоб работал интернет
4. Не знаю, но я обучаемый
5. Этим я не занимался
6. Чтоб работал сайт
Очевидно, что 2,3 и 6 более перспективны, задаём наводящие вопросы. Потом смотрим на ответы "зачем нужен DHCP?" И получаем примерно ту же картину. Не надо думать, что я прошу что-то сложное, но хоть статью в вики можно прочитать перед собесом? Это у всех опыт работы ещё релевантный указан.
И вот тебе надо выбрать сотрудника или ехать самому работать в Усть-пердюйск за среднюю зарплату по региону. Кончились кандидаты, физически. На сколько нужно поднять зарплату по таким регионам, чтоб пришли компетентные сотрудники? А сколько стоит то, что я проведу вебинар на 30 таких сотрудников? Вопрос открытый, но второе видится мне более дешевым.
А ещё в некоторых случаях тебя могут и не спросить, берем ли кандидата. Или не прислушаться к твоему мнению. Или тебе такие в наследство достались сотрудники и не ты их нанимал. А может ты им вообще не начальник, но дело с ними иметь надо по работе. Бесусловно, нужно пытаться сделать ситуацию лучше там, где можешь. Не без этого. Обучение, кстати, это тоже исправление ситуации.
А самое страшное для осознания то, что большая компания от этого всего не развалится. Ну или, по крайней мере, сильно не сразу. Да, возможно будет пострадывать, но кого-то переварит, кого-то выплюнет и будет работать дальше)
👏5👍3🤔1
И к посту выше аналогия.
Вот купили вы дачу, 6 соток. Ночами не спали, читали технологию отсыпки и отливки дорожек. Сами сделали на даче самые заебатые дорожки! Не раскисают, с подогревом зимой и не скользкие. Вы гуру строительства!
И теперь решили, что хотите классную дорогу себе от трассы в СНТ. Снова изучаете технологии. Влепились в поиск спонсора, выбивание денег, согласование кучи штук, поиск подрядчика, который делает по технологии, надзор за подрядчиком и т.д. потратили три года и вот у вас заебатая дорога на вашу дачу, аж 17 километров! Да вы мастер менеджмента! И гуру строительства дорог.
И тут вам поручают построить трассу Санкт-Петребург - Мурманск, и чтоб качеством такая же лакшери, как у вас до дачи. Вот бюджет и выйти за него нельзя. Вот вам сотрудники, можно уволить 10% и нанять 10%, остальных трогать нельзя. И вот этих по списку трогать нельзя. И тут вам в рожу прилетает: дизайн-код города, расселение жителей из домов, наследие Юнеско посередине, реликтовый лес нельзя вырубить, 300км болота, вечная мерзлота на севере, строителям надо обеспечить доставку-питание-проживание, надзор не хочет ехать в эту пердь, на двух складах спиздили материалы, по тенедру продали какую-то шнягу вместо битума, в Городе Н мэр требует откат, а ваши сотрудники хер клали на все ваши решения. И хрен знает какие ещё трудности.
И вот прошло пять лет, потрачен весь бюджет, сделана одна десятая часть работ и ты такой оглядываешься "ебать блять, кто-то построил другие трассы и по ним ездят машины - это ЧУДО!"
Нет ничего невозможного: очень-очень хороший менеджемент плюс охуллиард бабла и дорога будет. Или просто хороший менеджмент и 3 раза по охуллиард бабала. А вот когда работаешь с чем есть, с тем бюджетом что есть, с теми сотрудниками, что дали, то вот это уже реальная жизнь.
😅 такая вот аналогия))
Вот купили вы дачу, 6 соток. Ночами не спали, читали технологию отсыпки и отливки дорожек. Сами сделали на даче самые заебатые дорожки! Не раскисают, с подогревом зимой и не скользкие. Вы гуру строительства!
И теперь решили, что хотите классную дорогу себе от трассы в СНТ. Снова изучаете технологии. Влепились в поиск спонсора, выбивание денег, согласование кучи штук, поиск подрядчика, который делает по технологии, надзор за подрядчиком и т.д. потратили три года и вот у вас заебатая дорога на вашу дачу, аж 17 километров! Да вы мастер менеджмента! И гуру строительства дорог.
И тут вам поручают построить трассу Санкт-Петребург - Мурманск, и чтоб качеством такая же лакшери, как у вас до дачи. Вот бюджет и выйти за него нельзя. Вот вам сотрудники, можно уволить 10% и нанять 10%, остальных трогать нельзя. И вот этих по списку трогать нельзя. И тут вам в рожу прилетает: дизайн-код города, расселение жителей из домов, наследие Юнеско посередине, реликтовый лес нельзя вырубить, 300км болота, вечная мерзлота на севере, строителям надо обеспечить доставку-питание-проживание, надзор не хочет ехать в эту пердь, на двух складах спиздили материалы, по тенедру продали какую-то шнягу вместо битума, в Городе Н мэр требует откат, а ваши сотрудники хер клали на все ваши решения. И хрен знает какие ещё трудности.
И вот прошло пять лет, потрачен весь бюджет, сделана одна десятая часть работ и ты такой оглядываешься "ебать блять, кто-то построил другие трассы и по ним ездят машины - это ЧУДО!"
Нет ничего невозможного: очень-очень хороший менеджемент плюс охуллиард бабла и дорога будет. Или просто хороший менеджмент и 3 раза по охуллиард бабала. А вот когда работаешь с чем есть, с тем бюджетом что есть, с теми сотрудниками, что дали, то вот это уже реальная жизнь.
😅 такая вот аналогия))
👏7🤣4
Результаты проведенного обучения
Обучение по основам сетей на работе провела на прошлой неделе. Сначала думала, как обычно: 10-15 слайдиков, не сильно погружаясь. Но потом чего-то увлеклась и замутила лекцию на полтора часа и 42 слайда. Впихнула по ощущениям половину семестра из университетского курса. Немного погрузила народ вглубь кроличей норы. Отвыкла столько болтать, потом полдня хрипела))
Конечно, люди не могут удерживать внимание так долго. Конечно, не все могли отвлечься от работы на полтора часа. У кого-то вообще уже вечер был. Но, надеюсь, запись потом кто-то да посмотрит. Эффект будем оценивать месяца через три. Плохо, что было мало вопросов - значит слишком сложно и непонятно рассказывала.
Решила идти в ногу со временем и замутила после вебинара квиз в телеграме. Получила прям-таки неожиданные результаты: классно прошли тест те, от кого вообще не ожидала, а некоторые из тех, от кого ждала результатов, ответили менее, чем на половину вопросов.
Ну а если вам хочется побаловаться в пятницу, то ссылка на квиз внизу. Есть вопросы, где можно придраться к формулировкам, но тут уж извините, писалось на коленке за полчаса в метро 🤷🏼
Можно подискутировать в комментариях :)
http://t.me/QuizBot?start=kfg1ClDv
Обучение по основам сетей на работе провела на прошлой неделе. Сначала думала, как обычно: 10-15 слайдиков, не сильно погружаясь. Но потом чего-то увлеклась и замутила лекцию на полтора часа и 42 слайда. Впихнула по ощущениям половину семестра из университетского курса. Немного погрузила народ вглубь кроличей норы. Отвыкла столько болтать, потом полдня хрипела))
Конечно, люди не могут удерживать внимание так долго. Конечно, не все могли отвлечься от работы на полтора часа. У кого-то вообще уже вечер был. Но, надеюсь, запись потом кто-то да посмотрит. Эффект будем оценивать месяца через три. Плохо, что было мало вопросов - значит слишком сложно и непонятно рассказывала.
Решила идти в ногу со временем и замутила после вебинара квиз в телеграме. Получила прям-таки неожиданные результаты: классно прошли тест те, от кого вообще не ожидала, а некоторые из тех, от кого ждала результатов, ответили менее, чем на половину вопросов.
Ну а если вам хочется побаловаться в пятницу, то ссылка на квиз внизу. Есть вопросы, где можно придраться к формулировкам, но тут уж извините, писалось на коленке за полчаса в метро 🤷🏼
Можно подискутировать в комментариях :)
http://t.me/QuizBot?start=kfg1ClDv
Quiz Directory
База по сетям - тест 2024
15 questions
🔥10👍4❤1
Встречайте видео про сети!
Я тут в прошлом посте в комментах обещала запилить вам видео про какие-то базовые штуки в сетях. И вчера взяла и запилила. Залила на несвободный ютуб, надеюсь, вы освоите vpn 🤷
Видео вообще не редактировалось, кучу вещей я сказать забыла, но в целом норм. Может кому-то будет полезно. На лавры курса "сети для самых маленьких" не претендую. Видео ориентировано на эникейщиков и повторяет примерно семестр университетского курса по сетям. Ну, может самую чуточку меньше. Скачу с темы на тему, если буду продолжать, надо как-то поскромнее выбирать тему для каждого видео))
Если вам понравилось - напишите что-нибудь, что ли. Если не понравилось - тоже можете написать)
Ссылка:
https://youtu.be/RxQej4PwSPM
Я тут в прошлом посте в комментах обещала запилить вам видео про какие-то базовые штуки в сетях. И вчера взяла и запилила. Залила на несвободный ютуб, надеюсь, вы освоите vpn 🤷
Видео вообще не редактировалось, кучу вещей я сказать забыла, но в целом норм. Может кому-то будет полезно. На лавры курса "сети для самых маленьких" не претендую. Видео ориентировано на эникейщиков и повторяет примерно семестр университетского курса по сетям. Ну, может самую чуточку меньше. Скачу с темы на тему, если буду продолжать, надо как-то поскромнее выбирать тему для каждого видео))
Если вам понравилось - напишите что-нибудь, что ли. Если не понравилось - тоже можете написать)
Ссылка:
https://youtu.be/RxQej4PwSPM
YouTube
Немного базовых вещей про сети для эникейщика
Рассказ про базовые сетевые штуки для эникейщика: хост, IP, маска, шлюз, VLAN, NAT, DNS, DHCP.
Ссылки ютуб мне не доверил приложить, попробую в комментариях дать.
Ссылки ютуб мне не доверил приложить, попробую в комментариях дать.
👍19
Про ЦОДы
По работе ездила смотрела на ЦОДы, выбираем, где наши стойки будут стоять.
Узнала много новых для себя вещей про инженерку ЦОДов. Прикольное нововведение "холодная стена" - это такая решетка во всю стену типа 3 на 3 метра, оттуда дуют вентиляторы через хладагент. За счет того, что площадь большая, можно дуть медленнее, чем обычно через фальшпол или из обычных кондеев. А если медленнее, то и не сдувает, потом админы сопли на кулак не наматывают. А также за счет меньшей скорости потока воздух дольше контактирует с хладагентом и его можно делать более высокой температуры - то есть меньше охлаждать носитель и тратить на это меньше энергии. Горячий коридор у них закрывается дверками, а сверху там такие типа мини-всасываетели забирают горячий воздух.
Новое веяние: всю наружку обвешивать антидрон сетками или ламелями.
Ещё видела аккумуляторный зал ЦОДа: батарейки размером с системный блок стоят на стеллажах, соединены в цепь, а стеллажи уходят в даль. Масштабно.
Ещё там было про пожарку, про линии электричества от подстанций, про дизеля и контракты на подвоз топлива. Кто-то отапливает баки, у кого-то под землёй они, а кто-то с первыми холодами ультимативно меняет топливо на зимний "арктик", говорят в минус 30 с ним заводились норм.
У одних при пропадании электричества по одному вводу, на второй линии переключатели становятся в такое положение, что их нельзя отключить, типа, чтоб в панике случайно не дёрнули вторую линию.
У других двойной запас баллонов пожаротушения и специальная инструкция их ввода в общую систему. Это если случайно потушили не тот зал, опять же в запарке.
Узнала, что есть такая штука как meet-me-room - это такой мини маш-зал, там стоят стойки провайдеров и они делают свою расшивку после входа в ЦОД, если надо, то и между собой передачу данных настраивают.
Одна компания интересно строит: в серединке здания будут телестудии, а по бокам машзалы ЦОДа делают, типа чего место пропадает.
По работе ездила смотрела на ЦОДы, выбираем, где наши стойки будут стоять.
Узнала много новых для себя вещей про инженерку ЦОДов. Прикольное нововведение "холодная стена" - это такая решетка во всю стену типа 3 на 3 метра, оттуда дуют вентиляторы через хладагент. За счет того, что площадь большая, можно дуть медленнее, чем обычно через фальшпол или из обычных кондеев. А если медленнее, то и не сдувает, потом админы сопли на кулак не наматывают. А также за счет меньшей скорости потока воздух дольше контактирует с хладагентом и его можно делать более высокой температуры - то есть меньше охлаждать носитель и тратить на это меньше энергии. Горячий коридор у них закрывается дверками, а сверху там такие типа мини-всасываетели забирают горячий воздух.
Новое веяние: всю наружку обвешивать антидрон сетками или ламелями.
Ещё видела аккумуляторный зал ЦОДа: батарейки размером с системный блок стоят на стеллажах, соединены в цепь, а стеллажи уходят в даль. Масштабно.
Ещё там было про пожарку, про линии электричества от подстанций, про дизеля и контракты на подвоз топлива. Кто-то отапливает баки, у кого-то под землёй они, а кто-то с первыми холодами ультимативно меняет топливо на зимний "арктик", говорят в минус 30 с ним заводились норм.
У одних при пропадании электричества по одному вводу, на второй линии переключатели становятся в такое положение, что их нельзя отключить, типа, чтоб в панике случайно не дёрнули вторую линию.
У других двойной запас баллонов пожаротушения и специальная инструкция их ввода в общую систему. Это если случайно потушили не тот зал, опять же в запарке.
Узнала, что есть такая штука как meet-me-room - это такой мини маш-зал, там стоят стойки провайдеров и они делают свою расшивку после входа в ЦОД, если надо, то и между собой передачу данных настраивают.
Одна компания интересно строит: в серединке здания будут телестудии, а по бокам машзалы ЦОДа делают, типа чего место пропадает.
👍12
Как мы мониторим температуру в серверной.
В давние времена мониторинг был простой: прокся в инет на десктопном сервере умирала первой, не пропустишь. Далее идёшь и щупаешь металлическую дверь в серверную: если можно касаться - ещё норм, а если горячо дотронуться, то надо срочно гасить остальные сервера.
Потом мы купили чудо техники: термометр с gsm. И с тех пор он с нами ездит по офисам и шлёт смс-ки счастья, если что случится. Если он прислал 'температура больше 27 градусов', то идём и смотрим, что там с кондеями. Это если рабочий день. Если вечер/ночь/выходной, то ждём минут 20 и шлём запрос температуры. Если поднимается, то пытаемся вызвонить охрану, чтоб во-первых сами глянули что там и как (может электричество рубанули конкретно по линии кондеев), а во-вторых нас пустили на территорию офиса. В прошлом здании были круглосуточные пропуска. В этом вроде как тоже есть, но без звонка в само здание не пустят.
В давние времена мониторинг был простой: прокся в инет на десктопном сервере умирала первой, не пропустишь. Далее идёшь и щупаешь металлическую дверь в серверную: если можно касаться - ещё норм, а если горячо дотронуться, то надо срочно гасить остальные сервера.
Потом мы купили чудо техники: термометр с gsm. И с тех пор он с нами ездит по офисам и шлёт смс-ки счастья, если что случится. Если он прислал 'температура больше 27 градусов', то идём и смотрим, что там с кондеями. Это если рабочий день. Если вечер/ночь/выходной, то ждём минут 20 и шлём запрос температуры. Если поднимается, то пытаемся вызвонить охрану, чтоб во-первых сами глянули что там и как (может электричество рубанули конкретно по линии кондеев), а во-вторых нас пустили на территорию офиса. В прошлом здании были круглосуточные пропуска. В этом вроде как тоже есть, но без звонка в само здание не пустят.
👍9
Нудненько про решение проблемы определения региона звонка по номеру
Выдалось у меня время как-то для покодить.
Задача стояла давно и всё нарастала. Обычно, нам в контакт-центр поступают звонки таким образом, что мы в курсе, в какой регион РФ направить звонок.
Но был один источник телефонного трафика, где определение региона отсутствовало. Скажем так, попадали такие звонки на служебный внутренний номер. От звонка есть только АОН - номер абонента. Когда звонок с городского, казалось бы всё ясно - у нас не так много кодов (хотя и нужно собирать звонки по городам региона в одно место). Это потом я узнала, сколько реально городов есть. Но кто в наше время звонит с городского? Одни мобильные кругом.
Ремарка: даже для внешних звонков определение условной геопозиции (или вышки), по ней региона и передача такой информации для бизнеса - нет, такого не делает, насколько я знаю, никто. Это вам не звонки на 112.
Все онлайн-сервисы это медленно, ненадёжно и сложнореализуемо моими средствами. Так что выбор пал на справочники из реестра минцифры
Вообще, у нас в стране оказывается есть номера только на 3, на 4, на 8 и на 9. Собственно, по ссылке и лежат 4 справочника. Там указан DEF номер (первые 3 цифры) и диапазон ОТ и ДО с указанием какому оператору в каком регионе диапазон отпилен.
Ну в принципе, бери справочники, грузи себе в таблицу и делай каждый звонок запрос. Но справочник на 4, например, больше 30 мегабайт csv-шка. А система у меня не самая быстрая на свете. Я как предствила, что на каждый звонок пойдёт поиск, так мне немного плохо стало. А также мне надо было указать системе что условные "г. Калининград" и "г.Советск Калининградкой области" - для меня один и тот же регион "Калининград".
Поэтому я взяла питончик и написала абсолютно ужасный, но рабочий скрипт оптимизации, который прогнала в несколько итераций над файлами. Итого справочник на 3,4 и 8 ужался в 135 строчек. Ну и мобильники немного тоже ужались, но не сильно.
Первая функция выпиливала всё лишнее и склеивала одинаковые регионы, где диапазоны идут подряд. Вторая функция только для городских телефонов склеивала "дырки" в диапазонах у регионов. Ну типа номера на 100-155 и номера на 158-199 это Н-ская область, а номера на 156-157 никому не выданы. Я считатала оптом 100-199: Н-ская область. Если в мобильных номерах такие дырки разлетаются быстро и регион там рандомный, то в городских новые диапазоны раздают не так часто и стараются попасть регионом в старый диапазон или рядом. Отдельная функция оптимизировала Москву, Мособласть, Питер и Ленобласть и выпиливала все номера на 800-809, так как там нет привязки к региону или она условна. И финальная функция собирала мне два справочника: городские и мобильные.
Потом пришлось написать вручную таблицу соответствия: название региона и название скрипта очереди в нашей системе телефонии. Это была самая печальная часть) Ну и всё: таблицы в постгрес. В колл-центре скрипт, который по табличкам определяет регион и по нему выбирает следующий скрипт. Месяца три как работает, полёт нормальный. Определение достаточно точное, не смотря на то, что народ с мобильными номерами переезжает в другие регионы. +/- в 95% случаев регион определяется нормально (если пиходит АОН не пустой).
Я х.з., сам скрипт вообще нужен ? Могу выложить, там лютый говнокод и просто разбор строчек, считайте, я на нём питон училась применять)
Выдалось у меня время как-то для покодить.
Задача стояла давно и всё нарастала. Обычно, нам в контакт-центр поступают звонки таким образом, что мы в курсе, в какой регион РФ направить звонок.
Но был один источник телефонного трафика, где определение региона отсутствовало. Скажем так, попадали такие звонки на служебный внутренний номер. От звонка есть только АОН - номер абонента. Когда звонок с городского, казалось бы всё ясно - у нас не так много кодов (хотя и нужно собирать звонки по городам региона в одно место). Это потом я узнала, сколько реально городов есть. Но кто в наше время звонит с городского? Одни мобильные кругом.
Ремарка: даже для внешних звонков определение условной геопозиции (или вышки), по ней региона и передача такой информации для бизнеса - нет, такого не делает, насколько я знаю, никто. Это вам не звонки на 112.
Все онлайн-сервисы это медленно, ненадёжно и сложнореализуемо моими средствами. Так что выбор пал на справочники из реестра минцифры
Вообще, у нас в стране оказывается есть номера только на 3, на 4, на 8 и на 9. Собственно, по ссылке и лежат 4 справочника. Там указан DEF номер (первые 3 цифры) и диапазон ОТ и ДО с указанием какому оператору в каком регионе диапазон отпилен.
Ну в принципе, бери справочники, грузи себе в таблицу и делай каждый звонок запрос. Но справочник на 4, например, больше 30 мегабайт csv-шка. А система у меня не самая быстрая на свете. Я как предствила, что на каждый звонок пойдёт поиск, так мне немного плохо стало. А также мне надо было указать системе что условные "г. Калининград" и "г.Советск Калининградкой области" - для меня один и тот же регион "Калининград".
Поэтому я взяла питончик и написала абсолютно ужасный, но рабочий скрипт оптимизации, который прогнала в несколько итераций над файлами. Итого справочник на 3,4 и 8 ужался в 135 строчек. Ну и мобильники немного тоже ужались, но не сильно.
Первая функция выпиливала всё лишнее и склеивала одинаковые регионы, где диапазоны идут подряд. Вторая функция только для городских телефонов склеивала "дырки" в диапазонах у регионов. Ну типа номера на 100-155 и номера на 158-199 это Н-ская область, а номера на 156-157 никому не выданы. Я считатала оптом 100-199: Н-ская область. Если в мобильных номерах такие дырки разлетаются быстро и регион там рандомный, то в городских новые диапазоны раздают не так часто и стараются попасть регионом в старый диапазон или рядом. Отдельная функция оптимизировала Москву, Мособласть, Питер и Ленобласть и выпиливала все номера на 800-809, так как там нет привязки к региону или она условна. И финальная функция собирала мне два справочника: городские и мобильные.
Потом пришлось написать вручную таблицу соответствия: название региона и название скрипта очереди в нашей системе телефонии. Это была самая печальная часть) Ну и всё: таблицы в постгрес. В колл-центре скрипт, который по табличкам определяет регион и по нему выбирает следующий скрипт. Месяца три как работает, полёт нормальный. Определение достаточно точное, не смотря на то, что народ с мобильными номерами переезжает в другие регионы. +/- в 95% случаев регион определяется нормально (если пиходит АОН не пустой).
Я х.з., сам скрипт вообще нужен ? Могу выложить, там лютый говнокод и просто разбор строчек, считайте, я на нём питон училась применять)
👍10
Опять про собеседования
Долго думала, как бы покультурнее написать и никого не обидеть.
Искала я тут себе сотрудника, прособеседовала человек 15, что, кстати, не особо и много.
Искала эникейщика на asterisk и сеть (базовые заявки по инструкции), в описании вакансии были требования (DNS, DHCP, NAT, понимание, что такое IP, маска, маршрут). Ну как бы, астеру мы обучим, а вот базовое понимание сети - не каждому даётся. А также от меня было требование: "общая адекватность и минимальная самостоятельность, и чтоб какую-нибудь консоль в глаза видел (линуксовую, сетевого оборудования - не важно)". Эти дополнительные требования как-то облагородили для публицакии и они были указаны неявно.
40+ кандидаты поголовно "у меня свой бизнес". Хотя какое-то базовое понимание основ там было. Просто людям не интересно (я их понимаю, сидеть и закрывать базовые заявки - не самая интересная штука, когда у тебя свой бизнес).
К слову, не так давно собесила админа 60+ и он у меня согласование прошёл, дядька был старой закалки.
Молодёжь 20-25 лет - на неё была вся надежда. По деньгам мы под их хотелки проходили с запасом. Но это трындец. У нас в вакансии шесть незнакомых слов: ну хоть википедию открой, хоть покажи, что ты её читал и пытался понять! Мне не надо глубоких знаний, но с тобой за сутки-двое договорились о собеседовании, ну покажи, что ты можешь освоить минимальную информацию, погуглив! Просто по нулям. Причём образование профильное у всех, опыт работы какой-никакой обычно указан.
Спрашиваем, почему работу меняете? Говорит, скучно, не дают делать сложные вещи, мало заявок, сидишь на работе скучаешь. Ок, спрашиваем, инетом запрещено было пользоваться? Нет, говорит, самообразованием занимались все N месяцев работы. В резюме указно "работал с оборудованием cisco". Что делали именно? Vlan'ы прописывали. Ок, зачем vlan'ы нужны? - "Чтоб был доступ в интернет". И всё, стена! На все наводящие вопросы, вроде, "а будет ли интернет без вланов работать? А что будет, если у вас неуправляемый коммутатор? А что нужно ещё, чтоб интернет работал?" - тишина. То есть, человек N месяцев клепал вланы на цисках, у него была куча свободного времени на самообразование, а он даже не погуглил, нафиг вланы нужны.. Причём от пола кандидата не зависит - у меня то вроде как предрассудков по полу нет, но глухо одинаково и у девушек и у юношей.
Всё! Всё, что я спрашивала, мне рассказывали в университете! У меня, конечно, хорошее образование, но не думала, что всё настолько скатилось.
В результате получилось два адекватных кандидата, оба 30+, примерно равные по знаниям (смогли прочитать википедию и пересказать своими словами хотя бы общие принципы, видели консоль и даже имели какой-то опыт работы в линухе). Победил один по личным качествам. Вопросы на всякие софт скиллз задают у нас кадры. И вопрос был типа "расскажите про ваши отношения с коллегами и начальством".
И если в 23 условных года я могу понять максимализм, то в 30+ яростно и со злобой рассказывть как кто-то из коллег ничего не понимает в айти - ну такое. В этом возрасте уже должен быть опыт работы с людьми и постигнуты простые истины:
1) сотрурудник может быть ценен тем, что разбирается в какой-то другой области, а в айти он дуб-дубом, так бывает
2) даже айтишник не обязан разбираться во всех областях айти
3) люди ленятся, врут, творят хуйню - это нормальное состояние человечества. Где-то можно нести свет знаний, где-то смириться, но в целом не нужно думать, что в другой конторе есть другие волшебные люди, которые не ленятся, не врут и не творят хуйни
Там ещё, конечно, были моменты, но это прям красный флаг для работы в поддержке. Зато второй кандидат имел за плечами профессию, не связанную с айтишечкой, но где он познал дзен и успел понять, что мир неидеален.
Вот такая история. В целом, кандидаты в адеквате есть. Надо искать, да. Москва, что уж, имели возможность перебирать. Куча народа хочет удалёнку, но мы, поимев опыт с двумя удалёнщиками, разочаровались в таком формате работы на этой должности
Долго думала, как бы покультурнее написать и никого не обидеть.
Искала я тут себе сотрудника, прособеседовала человек 15, что, кстати, не особо и много.
Искала эникейщика на asterisk и сеть (базовые заявки по инструкции), в описании вакансии были требования (DNS, DHCP, NAT, понимание, что такое IP, маска, маршрут). Ну как бы, астеру мы обучим, а вот базовое понимание сети - не каждому даётся. А также от меня было требование: "общая адекватность и минимальная самостоятельность, и чтоб какую-нибудь консоль в глаза видел (линуксовую, сетевого оборудования - не важно)". Эти дополнительные требования как-то облагородили для публицакии и они были указаны неявно.
40+ кандидаты поголовно "у меня свой бизнес". Хотя какое-то базовое понимание основ там было. Просто людям не интересно (я их понимаю, сидеть и закрывать базовые заявки - не самая интересная штука, когда у тебя свой бизнес).
К слову, не так давно собесила админа 60+ и он у меня согласование прошёл, дядька был старой закалки.
Молодёжь 20-25 лет - на неё была вся надежда. По деньгам мы под их хотелки проходили с запасом. Но это трындец. У нас в вакансии шесть незнакомых слов: ну хоть википедию открой, хоть покажи, что ты её читал и пытался понять! Мне не надо глубоких знаний, но с тобой за сутки-двое договорились о собеседовании, ну покажи, что ты можешь освоить минимальную информацию, погуглив! Просто по нулям. Причём образование профильное у всех, опыт работы какой-никакой обычно указан.
Спрашиваем, почему работу меняете? Говорит, скучно, не дают делать сложные вещи, мало заявок, сидишь на работе скучаешь. Ок, спрашиваем, инетом запрещено было пользоваться? Нет, говорит, самообразованием занимались все N месяцев работы. В резюме указно "работал с оборудованием cisco". Что делали именно? Vlan'ы прописывали. Ок, зачем vlan'ы нужны? - "Чтоб был доступ в интернет". И всё, стена! На все наводящие вопросы, вроде, "а будет ли интернет без вланов работать? А что будет, если у вас неуправляемый коммутатор? А что нужно ещё, чтоб интернет работал?" - тишина. То есть, человек N месяцев клепал вланы на цисках, у него была куча свободного времени на самообразование, а он даже не погуглил, нафиг вланы нужны.. Причём от пола кандидата не зависит - у меня то вроде как предрассудков по полу нет, но глухо одинаково и у девушек и у юношей.
Всё! Всё, что я спрашивала, мне рассказывали в университете! У меня, конечно, хорошее образование, но не думала, что всё настолько скатилось.
В результате получилось два адекватных кандидата, оба 30+, примерно равные по знаниям (смогли прочитать википедию и пересказать своими словами хотя бы общие принципы, видели консоль и даже имели какой-то опыт работы в линухе). Победил один по личным качествам. Вопросы на всякие софт скиллз задают у нас кадры. И вопрос был типа "расскажите про ваши отношения с коллегами и начальством".
И если в 23 условных года я могу понять максимализм, то в 30+ яростно и со злобой рассказывть как кто-то из коллег ничего не понимает в айти - ну такое. В этом возрасте уже должен быть опыт работы с людьми и постигнуты простые истины:
1) сотрурудник может быть ценен тем, что разбирается в какой-то другой области, а в айти он дуб-дубом, так бывает
2) даже айтишник не обязан разбираться во всех областях айти
3) люди ленятся, врут, творят хуйню - это нормальное состояние человечества. Где-то можно нести свет знаний, где-то смириться, но в целом не нужно думать, что в другой конторе есть другие волшебные люди, которые не ленятся, не врут и не творят хуйни
Там ещё, конечно, были моменты, но это прям красный флаг для работы в поддержке. Зато второй кандидат имел за плечами профессию, не связанную с айтишечкой, но где он познал дзен и успел понять, что мир неидеален.
Вот такая история. В целом, кандидаты в адеквате есть. Надо искать, да. Москва, что уж, имели возможность перебирать. Куча народа хочет удалёнку, но мы, поимев опыт с двумя удалёнщиками, разочаровались в таком формате работы на этой должности
👍8🔥4
Пробую выкладывать код.
Так, пара человек сказали выложить код, к предыдущему посту - ну типа, а почему бы и нет.
Я пытаюсь освоить github, так что вот ссылка
Напоминаю, справочники брать из реестра минцифры
Оптимизируются справочники под мои нужды, так что не думаю, что оно кому-нибудь пригодится, но вдруг 🤷🏻
Так, пара человек сказали выложить код, к предыдущему посту - ну типа, а почему бы и нет.
Я пытаюсь освоить github, так что вот ссылка
Напоминаю, справочники брать из реестра минцифры
Оптимизируются справочники под мои нужды, так что не думаю, что оно кому-нибудь пригодится, но вдруг 🤷🏻
👍1
Про запросы
Прошло много времени с моего последнего поста. Я так и не собралась опубликовать код своей бэкапилки сетевого оборудования на питоне, хотя она исправно работает, в том числе с новыми свичами от Maipu. Когда-нибудь, да..
Сегодня про прикольную задачку от моего любимого колл-центра. Нужен им был отчет, чтоб и сводный, и с процентами, и суммировал и показывал много чего. А у них всегда есть два варианта: или отчет делаю я, или они заказывают у вендора доработку системы за немного денежек (кстати, обычно, вменяемо, не как крыло от самолёта). Но к деньгам надо писать 100500 служебок, четыре согласования, адекватное ТЗ и ждать неизвестно сколько. В общем, они любят, когда отчёты делаю я и даже готовы ждать, когда у меня появится время.
А я как-то для своих надобностей обычно работаю с базами данных на одну-три таблички, без фанатизма. Ну, знаете,
обычно мой предел. А тут в одной базе статистики 76 табличек, во второй тоже хватает.
Описания структуры БД, конечно, нет (есть, но ооочень лаконичное). Так что я вначале погрузилась в мир текущих отчетов и маленьких селектов в PGAdmin, чтоб понять, откуда вообще тащить данные. Потом попыталась всё это склеить. Получилось, но не то. Дернула нашего гуру sql, он дал совет. Получилось и то, но это была только четверть отчёта. В общем, теперь я умею делать запросы в 4 тблицы в двух разных БД, а также делать LEFT JOIN на FULL JOIN на LEFT JOIN на ещё один LEFT JOIN. Надо просто не жалеть скобочек, оказывается. А ещё узнала, что можно сделать
То есть, выбрать больше, чем звёздочка. Ну ладно-ладно, мне ещё раз помог наш гуру по SQL. Но только советами 🤯 (я периодически говорила "а что, так можно было?"). Попутно нашла, что делать при делении на ноль (проценты беспощадны!), а также обошла странную штуку при сравнении времени через свойства самой системы отчётности. Развлекалась, короче, на все деньги. Заказчик результатом доволен :)
Попутно изучила пару отчётов, которые нам писали когда-то сотрудники вендора. Называть промежуточную таблицу просто t в запросе на 300 строк - это надо иметь особую ненависть к тому, кто будет отчеты разбирать после них. Потому что по ctrl+f найти одну английскую буковку t в нужном месте довольно нетривиально. Чтоб они спали спокойно после этого.
Спасибо подписавшимся, да и отписавшимся тоже: какая-то движуха тут без меня происходила, прикольно)
Прошло много времени с моего последнего поста. Я так и не собралась опубликовать код своей бэкапилки сетевого оборудования на питоне, хотя она исправно работает, в том числе с новыми свичами от Maipu. Когда-нибудь, да..
Сегодня про прикольную задачку от моего любимого колл-центра. Нужен им был отчет, чтоб и сводный, и с процентами, и суммировал и показывал много чего. А у них всегда есть два варианта: или отчет делаю я, или они заказывают у вендора доработку системы за немного денежек (кстати, обычно, вменяемо, не как крыло от самолёта). Но к деньгам надо писать 100500 служебок, четыре согласования, адекватное ТЗ и ждать неизвестно сколько. В общем, они любят, когда отчёты делаю я и даже готовы ждать, когда у меня появится время.
А я как-то для своих надобностей обычно работаю с базами данных на одну-три таблички, без фанатизма. Ну, знаете,
select * from netdev where ip like "10.78%"; обычно мой предел. А тут в одной базе статистики 76 табличек, во второй тоже хватает.
Описания структуры БД, конечно, нет (есть, но ооочень лаконичное). Так что я вначале погрузилась в мир текущих отчетов и маленьких селектов в PGAdmin, чтоб понять, откуда вообще тащить данные. Потом попыталась всё это склеить. Получилось, но не то. Дернула нашего гуру sql, он дал совет. Получилось и то, но это была только четверть отчёта. В общем, теперь я умею делать запросы в 4 тблицы в двух разных БД, а также делать LEFT JOIN на FULL JOIN на LEFT JOIN на ещё один LEFT JOIN. Надо просто не жалеть скобочек, оказывается. А ещё узнала, что можно сделать
select *, что-то_ещёТо есть, выбрать больше, чем звёздочка. Ну ладно-ладно, мне ещё раз помог наш гуру по SQL. Но только советами 🤯 (я периодически говорила "а что, так можно было?"). Попутно нашла, что делать при делении на ноль (проценты беспощадны!), а также обошла странную штуку при сравнении времени через свойства самой системы отчётности. Развлекалась, короче, на все деньги. Заказчик результатом доволен :)
Попутно изучила пару отчётов, которые нам писали когда-то сотрудники вендора. Называть промежуточную таблицу просто t в запросе на 300 строк - это надо иметь особую ненависть к тому, кто будет отчеты разбирать после них. Потому что по ctrl+f найти одну английскую буковку t в нужном месте довольно нетривиально. Чтоб они спали спокойно после этого.
Спасибо подписавшимся, да и отписавшимся тоже: какая-то движуха тут без меня происходила, прикольно)
👍18🔥2👏1
netbox
Пару-тройку лет назад, я ходила и приставала к людям с вопросом: "а что используете для ведения ip адресации и для всякой базы знаний о сети?". И люди достаточно единодушно слали меня в netbox.
Netbox у нас пережил первую итерацию, когда им никто не пользовался и туда ничего не заводил (ну ладно, три стойки в цоде по юнитам расписали и даже пару раз обновляли данные). Затем сотрудник, который его поднимал, уволился, а netbox умер в муках.
Потом у меня появилсяраб сотрудник, у которого есть время и желание. У нетбокса появилась доменная авторизация по группе, плагины и новый сервак. Настала итерация 2.1, в которой мы поиграли с правами (пару раз проиграли, но потом пришли к ничьей) и дали доступ другому очень активному человеку, который его затестил по мере сил.
Сейчас итерация 2.2 - я туда перетащила ip адресацию и немного ещё всякого, а также призвала им пользоваться. Ну, лучше, чем excel-ка в шаре. Уже неплохой результат: завела все VLANы, посмотрела на них и поняла, что надо чистить конфиг, много хвостов.
Потом, надеюсь, дойдём до итерации три: интеграция с чем-нибудь и динамическое обновление данных.
Итерация 4 предполагает, что у нас будет автоматическая настройка сетевого оборудования в филиалах до стадии "можно подключиться по ssh". Ну, в отдалённом светлом будущем.
До идеологии "netbox - единственный источник правды" пока идти не готовы. Эта идеология предполагает, что все изменения делаются в netbox, а потом разными способами отливаются на прод (изменяются конфиги сетевого оборудования, создаются и удаляются виртуалки и т.д.).
В целом, конечно, наша автоматизация пока робко выглядывает из каменного века полностью ручной работы. Это я почитала соответствующие статьи и немного загрустила. С другой стороны, есть к чему стремиться 😁
Ну а к классическому комментарию "во всех нормальных компаниях есть netbox со всеми интеграциями" я уже давно писала пост про это
Пару-тройку лет назад, я ходила и приставала к людям с вопросом: "а что используете для ведения ip адресации и для всякой базы знаний о сети?". И люди достаточно единодушно слали меня в netbox.
Netbox у нас пережил первую итерацию, когда им никто не пользовался и туда ничего не заводил (ну ладно, три стойки в цоде по юнитам расписали и даже пару раз обновляли данные). Затем сотрудник, который его поднимал, уволился, а netbox умер в муках.
Потом у меня появился
Сейчас итерация 2.2 - я туда перетащила ip адресацию и немного ещё всякого, а также призвала им пользоваться. Ну, лучше, чем excel-ка в шаре. Уже неплохой результат: завела все VLANы, посмотрела на них и поняла, что надо чистить конфиг, много хвостов.
Потом, надеюсь, дойдём до итерации три: интеграция с чем-нибудь и динамическое обновление данных.
Итерация 4 предполагает, что у нас будет автоматическая настройка сетевого оборудования в филиалах до стадии "можно подключиться по ssh". Ну, в отдалённом светлом будущем.
До идеологии "netbox - единственный источник правды" пока идти не готовы. Эта идеология предполагает, что все изменения делаются в netbox, а потом разными способами отливаются на прод (изменяются конфиги сетевого оборудования, создаются и удаляются виртуалки и т.д.).
В целом, конечно, наша автоматизация пока робко выглядывает из каменного века полностью ручной работы. Это я почитала соответствующие статьи и немного загрустила. С другой стороны, есть к чему стремиться 😁
Ну а к классическому комментарию "во всех нормальных компаниях есть netbox со всеми интеграциями" я уже давно писала пост про это
Telegram
Работать сисадмином - как это
"ошибка в самом начале"
Как продолжение "ты делаешь неправильно"
Сюда же относится "в нормальных компаниях это давно сделано".
Ну например, "в нормальных компаниях давно есть мониторинг", или "в нормальных компаниях давно собираются все логи и анализируется"…
Как продолжение "ты делаешь неправильно"
Сюда же относится "в нормальных компаниях это давно сделано".
Ну например, "в нормальных компаниях давно есть мониторинг", или "в нормальных компаниях давно собираются все логи и анализируется"…
👍10🔥1
Линукс или сетевая железка?
Иногда смотришь на энтерпрайз железки с тоской и думаешь, ну ёпрст, а не взять ли мне говнокомп, вкатить туда debian с iptables и радоваться жизни за ценник на порядки меньше..
Сегодня у нас пятничные размышления, возможно, немного наивные.
Давайте выкинем случай с ЦОДом, или очень нагруженной инфраструктурой, где действительно чипы и процессоры в железках, заточенных под маршрутизацию или коммутацию, играют большую роль.
Рассмотрим обычный вариант малого офиса или филиала, где канал 100 мегабит, ну на край гигабит. Пара серваков, сотня компов. Роутер немножк фильтрует трафик между сетями и в инет, держит до пары десятков vpn-каналов, NAT'ит трафик в инет, пробрасывает внутрь пару портов, ну и может dhcp раздаёт. И встаёт выбор: кинетик/микротик/хуавей/циска или комп/сервер/виртуалка на линухе. Считаем, что производительности условного компа хватит на то, что делает роутер.
Почему роутер на линухе это плохо:
1) нет единого конфига. Уася поставил рандомный firewall поиграться, сложил конфиги неизвестно куда, обмазал скриптами на питоне и, конечно же, не задокументировал. Уася уволился или его переехала машина и вы получили чёрный ящик. А может он ещё и диск зашифровал, чтоб никто не догадался, что там в конфигах. В сетевых же железках всё структурировано, шаг влево, шаг вправо и уже ничего нельзя сделать иначе.
2) бэкапы из-за пункта 1 могут быть неполными, чтобы вернуть систему в то же самое состояние нужно прям поебаться. Это не раскатать бэкап с одной циски на другую такую же. Это если вообще кто-то подумал про бэкапы.
3) чтоб нанять замену вашему кулибину, нужно найти достаточно компетентного чувака. Это вам не пройти мастер на кинетике в виде далее-далее-готово и даже не поковыряться внутри микротика по менюшкам. Тут нужны какие-то дополнительные знания.
4) если у вас два офиса, привет два абсолютно разных конфига. Даже если написан регламент как надо.
5) размер имеет значение иногда - маленькая коробочка или десктоп куда-то деть.
6) держать штуку, обеспечивающую доступ к инфраструктуре, внутри этой самой инфраструктуры - ну, не особо безопасно. Это примерно как ставить получение адреса по dhcp на хост-машине, при том что dhcp без failover'а крутится виртуалкой на этой же хост-машине.
7) бывает, нужно ставить сертифицированное решение и, обычно, это железка, тут уж никуда не деться.
На самом деле, почти все эти пункты можно победить. Об этом в конце.
Почему роутер на линухе это хорошо:
1) он правда умеет всё, что вам надо. А если не умеет, вы поставите дополнительный пакет. Или напишете свой.
2) он отлично скриптуется, можно реализовывать самые извращённые сценарии, вроде работы vpn только в будни по производственному календарю с 7 до 16 с отсылкой напоминаний в телеграм.
3) не справляется? Докиньте оперативки. Короче, худо-бедно по производительности можно менять. А можно вообще масштабировать на несколько.. ладно, мы всё еще про маленький офис, не будем об этом.
4) это стоит мало денег. Ну, типа говнокомп или заначенный маленький сервак есть у каждого админа. И быстро! Не надо играть тендер, ждать согласования..
Минусы в плюсы
И если лет пять назад я безальтернативно говорила "только сетевые железки, иначе потом не разгребёте", то сейчас я начиталась про автоматизацию и появились варианты. Если у вас единственный офис с единственним админом, всё ещё условный кинетик - ваш выбор.
А вот если у вас много офисов с более-менее едиными условиями и центральным управлением, то можно заняться девопсом: даже без всяких контейнеров грамотно всё загнать в Ansible и вот вы уже получите единое управление, массовую безопасную раскатку изменений, автодокументирование, быструю воспроизводимость и единообразие. И нужно вам не 40 линуксоидов в 40 филиалов, а один сетевик-немножко-девопс (ладно, два). Ну, купить компы в маленьком корпусе (+запас) или обеспечить отказоустойчивый кластер с виртуалками - это уже по деньгам переплюнет маленькие сетевые железки, конечно. Но всё-таки, варианты появляются.
Иногда смотришь на энтерпрайз железки с тоской и думаешь, ну ёпрст, а не взять ли мне говнокомп, вкатить туда debian с iptables и радоваться жизни за ценник на порядки меньше..
Сегодня у нас пятничные размышления, возможно, немного наивные.
Давайте выкинем случай с ЦОДом, или очень нагруженной инфраструктурой, где действительно чипы и процессоры в железках, заточенных под маршрутизацию или коммутацию, играют большую роль.
Рассмотрим обычный вариант малого офиса или филиала, где канал 100 мегабит, ну на край гигабит. Пара серваков, сотня компов. Роутер немножк фильтрует трафик между сетями и в инет, держит до пары десятков vpn-каналов, NAT'ит трафик в инет, пробрасывает внутрь пару портов, ну и может dhcp раздаёт. И встаёт выбор: кинетик/микротик/хуавей/циска или комп/сервер/виртуалка на линухе. Считаем, что производительности условного компа хватит на то, что делает роутер.
Почему роутер на линухе это плохо:
1) нет единого конфига. Уася поставил рандомный firewall поиграться, сложил конфиги неизвестно куда, обмазал скриптами на питоне и, конечно же, не задокументировал. Уася уволился или его переехала машина и вы получили чёрный ящик. А может он ещё и диск зашифровал, чтоб никто не догадался, что там в конфигах. В сетевых же железках всё структурировано, шаг влево, шаг вправо и уже ничего нельзя сделать иначе.
2) бэкапы из-за пункта 1 могут быть неполными, чтобы вернуть систему в то же самое состояние нужно прям поебаться. Это не раскатать бэкап с одной циски на другую такую же. Это если вообще кто-то подумал про бэкапы.
3) чтоб нанять замену вашему кулибину, нужно найти достаточно компетентного чувака. Это вам не пройти мастер на кинетике в виде далее-далее-готово и даже не поковыряться внутри микротика по менюшкам. Тут нужны какие-то дополнительные знания.
4) если у вас два офиса, привет два абсолютно разных конфига. Даже если написан регламент как надо.
5) размер имеет значение иногда - маленькая коробочка или десктоп куда-то деть.
6) держать штуку, обеспечивающую доступ к инфраструктуре, внутри этой самой инфраструктуры - ну, не особо безопасно. Это примерно как ставить получение адреса по dhcp на хост-машине, при том что dhcp без failover'а крутится виртуалкой на этой же хост-машине.
7) бывает, нужно ставить сертифицированное решение и, обычно, это железка, тут уж никуда не деться.
На самом деле, почти все эти пункты можно победить. Об этом в конце.
Почему роутер на линухе это хорошо:
1) он правда умеет всё, что вам надо. А если не умеет, вы поставите дополнительный пакет. Или напишете свой.
2) он отлично скриптуется, можно реализовывать самые извращённые сценарии, вроде работы vpn только в будни по производственному календарю с 7 до 16 с отсылкой напоминаний в телеграм.
3) не справляется? Докиньте оперативки. Короче, худо-бедно по производительности можно менять. А можно вообще масштабировать на несколько.. ладно, мы всё еще про маленький офис, не будем об этом.
4) это стоит мало денег. Ну, типа говнокомп или заначенный маленький сервак есть у каждого админа. И быстро! Не надо играть тендер, ждать согласования..
Минусы в плюсы
И если лет пять назад я безальтернативно говорила "только сетевые железки, иначе потом не разгребёте", то сейчас я начиталась про автоматизацию и появились варианты. Если у вас единственный офис с единственним админом, всё ещё условный кинетик - ваш выбор.
А вот если у вас много офисов с более-менее едиными условиями и центральным управлением, то можно заняться девопсом: даже без всяких контейнеров грамотно всё загнать в Ansible и вот вы уже получите единое управление, массовую безопасную раскатку изменений, автодокументирование, быструю воспроизводимость и единообразие. И нужно вам не 40 линуксоидов в 40 филиалов, а один сетевик-немножко-девопс (ладно, два). Ну, купить компы в маленьком корпусе (+запас) или обеспечить отказоустойчивый кластер с виртуалками - это уже по деньгам переплюнет маленькие сетевые железки, конечно. Но всё-таки, варианты появляются.
👍13🔥2
Поленись/не поленись
Где-то раз в год возникает задача обновить список почтовых контактов сторонних организаций в AD. Новый список попадает ко мне в виде csv'шки. Задача удалить те контакты, которые не актуальны, залить новые, а те, что остались - поправить (у кого должность сменилась, а у кого-то почта). Просто пачкой удалить всё и залить новое нельзя, потому что тогда при выборе контакта из кэша в outlook полезут ошибки.
Контактов около 8 тысяч.
Ну понятно, что это powershell. Раньше это было несколько скриптов - сначала просто на компе (где AD обвеска стоит), потом на почтовике, потому что только там есть почтовая оснастка. И много допиливания напильником - тёзки, одинаковая почта (alias'ы) с нашими пользователями, другие ошибки создания. Ну прям человек 200 набегало таких. В этот раз я предстваила страдания и пошла писать скрипты с нормальными проверками, с условиями и прочим таким. Ну потому что надоело страдать. Потом подумала, что я мучаюсь и пошла сразу всё с почтовика делать. Всё равно три прогона получается - один удаление, второй создание, а третий обновление. Потому что в создании почтового контакта нельзя сразу должность впихнуть, а если сразу на него начать делать get-adObject, ад-шка не успевает отсинхронизироваться и в половине случаев говорит, что объект не найден. Поэтому сначала все создать, а потом у старых и новых обновить данные по должностям/почтам.
Неплохо получилось, всего 6 контактов с ошибками, требующими ручной доработки. Меньше 0,1%. Лень - двигатель прогресса))
Для новых подписчиков: я стараюсь писать свои впечатления от работы, истории, байки, немного философских мыслей. Каналов типа "приёмы работы bash/linux/windows которые вы не знали" и так много, среди них есть прям хорошие, так что я с ними не конкурирую))
Где-то раз в год возникает задача обновить список почтовых контактов сторонних организаций в AD. Новый список попадает ко мне в виде csv'шки. Задача удалить те контакты, которые не актуальны, залить новые, а те, что остались - поправить (у кого должность сменилась, а у кого-то почта). Просто пачкой удалить всё и залить новое нельзя, потому что тогда при выборе контакта из кэша в outlook полезут ошибки.
Контактов около 8 тысяч.
Ну понятно, что это powershell. Раньше это было несколько скриптов - сначала просто на компе (где AD обвеска стоит), потом на почтовике, потому что только там есть почтовая оснастка. И много допиливания напильником - тёзки, одинаковая почта (alias'ы) с нашими пользователями, другие ошибки создания. Ну прям человек 200 набегало таких. В этот раз я предстваила страдания и пошла писать скрипты с нормальными проверками, с условиями и прочим таким. Ну потому что надоело страдать. Потом подумала, что я мучаюсь и пошла сразу всё с почтовика делать. Всё равно три прогона получается - один удаление, второй создание, а третий обновление. Потому что в создании почтового контакта нельзя сразу должность впихнуть, а если сразу на него начать делать get-adObject, ад-шка не успевает отсинхронизироваться и в половине случаев говорит, что объект не найден. Поэтому сначала все создать, а потом у старых и новых обновить данные по должностям/почтам.
Неплохо получилось, всего 6 контактов с ошибками, требующими ручной доработки. Меньше 0,1%. Лень - двигатель прогресса))
Для новых подписчиков: я стараюсь писать свои впечатления от работы, истории, байки, немного философских мыслей. Каналов типа "приёмы работы bash/linux/windows которые вы не знали" и так много, среди них есть прям хорошие, так что я с ними не конкурирую))
👍16
Автобэкапы
На прошлой неделе коллега из дружественной организации тоже заинтересовался моим скриптом автобэкапа сетевого оборудования, так что я собралась с силами и его выложила проектом
Я уже кучу раз в постах на пикабу писала почему не "ваше любимое готовое решение". Но повторю:
1) потому что я хочу понимать, что происходит.
2) потому что я на основе своего решения уже имею, например, анализатор занятых портов на свичах в рамках филиала. А в целом имею возможность выполнить любые команды и проанализировать вывод.
3) Ну и вообще: моё решение с шахматами и поэтэссами умеет делать ровно то, что мне надо, таким образом, как мне надо. Плохо что ли? Хорошо!
И немного истории:
Про то, как я боролась с ключами ssh на хуавее я уже писала, но вспоминаю, что это было непросто. Ну и к идее хранения конфигов в системе контроля версий пришла давно, ещё когда у нас были D-Link DFL, и также давно мы переехали с svn на git (в gitea).
Был у меня скрипт на bash, а хотелось его переписать на python. Потому что стильно-модно-молодёжно, понятнее к восприятию и можно накрутить всякого.
Первый затык был в параллельность. Ну потому что 300 бэкапов, да по 1 минуте на каждый минимум - это уже 5 часов. Как бы питон это не Си и просто fork-exec это немного не то, что нужно. И не bash, где можно просто в конце амперсанд написать. В результе пришла к subprocess. Но тут как бы... триста питон процессов все разом запускать - мой бедный сервер с одним гигом памяти немного может не справиться. Так что надо запускать их параллельно, но не все. Тут муж немного мне помог с логикой карусели процессов. Запускаем N в параллель, отслеживаем завершение, потом как один бэкап кончился - запускаем следующий. Всё круто, но появились зависшие процессы, пришлось сделать таймаут и отстреливать.
Потом хотелось сделать одну суперфункцию на всё. Но нет, пришла к выводу, что лучше по своей функции на каждый тип устройств, несмотря на большую часть копирования кода.
Естественно, нужно было оценить успешность бэкапа. А если есть оценка успешности - почему бы не запустить повторный бэкап на неуспешные устройства с увеличенным таймаутом?
А, да, пыталась я использовать все эти модули - netmiko, paramiko и чёт там ещё. В результате оставила только paramiko и только в части открытия ssh сессии и то не на все устройства. Потому что это грёбаный пипец - то одно не работает, то второе, то не так считывает, то исключения нет и оно падает с ошибкой. В результате, конечно, не кроссплатформенно, а под debian получилось. Зато работает как надо, а не как бог на душу положил разработчикам, которые сетевые девайсы в глаза не видели и бэкапы с них не делали.
Потом нам зарубили отправку почты без авторизации внутри домена. Всё, что я нашла для авторизации на exchange это swaks. Это вообще инструмент тестирования и я немного гвозди микроскопом забиваю, но как есть.
После этого, нам пришли новые коммутаторы maipu, но тут, спасибо мне, они включились в систему добавлением одной функции и одного if'a.
Сейчас вот пришли новые хуавеи с новой прошивкой (там другая ОС!) И у них изменилось сообщение об успешном бэкапе. Придётся зводить их с новым тегом видимо.
Такая вот длинная история. В целом система пару лет работает и очень в жизни помогает.
Код по ссылке в начале. Readme я сделала на английском, а комменты остались частично на русском. Ну, переводчиком все пользоваться умеют. Надеюсь, кому-то пригодится. Ну а нет - так нет)
На прошлой неделе коллега из дружественной организации тоже заинтересовался моим скриптом автобэкапа сетевого оборудования, так что я собралась с силами и его выложила проектом
Я уже кучу раз в постах на пикабу писала почему не "ваше любимое готовое решение". Но повторю:
1) потому что я хочу понимать, что происходит.
2) потому что я на основе своего решения уже имею, например, анализатор занятых портов на свичах в рамках филиала. А в целом имею возможность выполнить любые команды и проанализировать вывод.
3) Ну и вообще: моё решение с шахматами и поэтэссами умеет делать ровно то, что мне надо, таким образом, как мне надо. Плохо что ли? Хорошо!
И немного истории:
Про то, как я боролась с ключами ssh на хуавее я уже писала, но вспоминаю, что это было непросто. Ну и к идее хранения конфигов в системе контроля версий пришла давно, ещё когда у нас были D-Link DFL, и также давно мы переехали с svn на git (в gitea).
Был у меня скрипт на bash, а хотелось его переписать на python. Потому что стильно-модно-молодёжно, понятнее к восприятию и можно накрутить всякого.
Первый затык был в параллельность. Ну потому что 300 бэкапов, да по 1 минуте на каждый минимум - это уже 5 часов. Как бы питон это не Си и просто fork-exec это немного не то, что нужно. И не bash, где можно просто в конце амперсанд написать. В результе пришла к subprocess. Но тут как бы... триста питон процессов все разом запускать - мой бедный сервер с одним гигом памяти немного может не справиться. Так что надо запускать их параллельно, но не все. Тут муж немного мне помог с логикой карусели процессов. Запускаем N в параллель, отслеживаем завершение, потом как один бэкап кончился - запускаем следующий. Всё круто, но появились зависшие процессы, пришлось сделать таймаут и отстреливать.
Потом хотелось сделать одну суперфункцию на всё. Но нет, пришла к выводу, что лучше по своей функции на каждый тип устройств, несмотря на большую часть копирования кода.
Естественно, нужно было оценить успешность бэкапа. А если есть оценка успешности - почему бы не запустить повторный бэкап на неуспешные устройства с увеличенным таймаутом?
А, да, пыталась я использовать все эти модули - netmiko, paramiko и чёт там ещё. В результате оставила только paramiko и только в части открытия ssh сессии и то не на все устройства. Потому что это грёбаный пипец - то одно не работает, то второе, то не так считывает, то исключения нет и оно падает с ошибкой. В результате, конечно, не кроссплатформенно, а под debian получилось. Зато работает как надо, а не как бог на душу положил разработчикам, которые сетевые девайсы в глаза не видели и бэкапы с них не делали.
Потом нам зарубили отправку почты без авторизации внутри домена. Всё, что я нашла для авторизации на exchange это swaks. Это вообще инструмент тестирования и я немного гвозди микроскопом забиваю, но как есть.
После этого, нам пришли новые коммутаторы maipu, но тут, спасибо мне, они включились в систему добавлением одной функции и одного if'a.
Сейчас вот пришли новые хуавеи с новой прошивкой (там другая ОС!) И у них изменилось сообщение об успешном бэкапе. Придётся зводить их с новым тегом видимо.
Такая вот длинная история. В целом система пару лет работает и очень в жизни помогает.
Код по ссылке в начале. Readme я сделала на английском, а комменты остались частично на русском. Ну, переводчиком все пользоваться умеют. Надеюсь, кому-то пригодится. Ну а нет - так нет)
👍17
Вопрос к аудитории
Коллеги, просьба в комментариях поделиться опытом, кто столкнулся с такой проблемой и как решал.
Ситуация следующая: компания не айтишная, занимается какой-то своей деятельностью, жила и живет с виндовой инфраструктурой. То есть, AD, Exchange, MSOffice, рабочие места на винде, ну и т.д. Но в связи с событиями последних лет (начиная с ковида) резко возросло число линуховых серверов. То есть, их было типа три, а стало триста. И в полный рост встал вопрос, как их админить централизованно? В основном это debian, есть немного ubuntu и немного centos.
То есть, я так понимаю, задачи следующие:
1) выделить какие-то типовые наборы пакетов и типовые конфигурации виртуалок
2) централизованно раздавать и отбирать права
3) централизованно обновлять (ну, есть nexus sonatype, но это немного не то, нужен аналог wsus)
4) завести внутренний репозиторий со своим специчным софтом
5) собирать инфу об установленном софте
6) быстро восстанавливать и/или разворачивать критичные и/или типовые сервисы
7) обеспечить авторегистрацию и автоудаление в DNS
В связи с этим вопрос, вводить ли линуксовые сервера в домен? Кто как решал перечисленные вопросы (можно просто названия, которые гуглить)? Путь только к Ansible или есть ещё что? Что я упустила в задачах?
Уходить от AD пока не планируется, если что, да и виндовых серверов тоже достаточно.
Всем заранее спасибо за ответы)
Коллеги, просьба в комментариях поделиться опытом, кто столкнулся с такой проблемой и как решал.
Ситуация следующая: компания не айтишная, занимается какой-то своей деятельностью, жила и живет с виндовой инфраструктурой. То есть, AD, Exchange, MSOffice, рабочие места на винде, ну и т.д. Но в связи с событиями последних лет (начиная с ковида) резко возросло число линуховых серверов. То есть, их было типа три, а стало триста. И в полный рост встал вопрос, как их админить централизованно? В основном это debian, есть немного ubuntu и немного centos.
То есть, я так понимаю, задачи следующие:
1) выделить какие-то типовые наборы пакетов и типовые конфигурации виртуалок
2) централизованно раздавать и отбирать права
3) централизованно обновлять (ну, есть nexus sonatype, но это немного не то, нужен аналог wsus)
4) завести внутренний репозиторий со своим специчным софтом
5) собирать инфу об установленном софте
6) быстро восстанавливать и/или разворачивать критичные и/или типовые сервисы
7) обеспечить авторегистрацию и автоудаление в DNS
В связи с этим вопрос, вводить ли линуксовые сервера в домен? Кто как решал перечисленные вопросы (можно просто названия, которые гуглить)? Путь только к Ansible или есть ещё что? Что я упустила в задачах?
Уходить от AD пока не планируется, если что, да и виндовых серверов тоже достаточно.
Всем заранее спасибо за ответы)
🤯1
Про мониторинг и не только.
Спасибо всем, кто не отписался!
Сегодня поговорим про то, как происходит трансформация подхода к мониторингу. На моём примере.
Кто помнит, я в посте "заббикс в первый раз" рассказывала как я когда-то в древности поднимала нам мониторинг. С тех пор прошло много времени. Какие-то попытки прийти к более приемлемой работе с инцидентами у меня были года два назад и тогда они не увенчались успехом.
Но попробуем по порядку. Заббикс у нас мониторит серваки и сетевое оборудование. И вроде всё хорошо. Но с ростом инфраструктуры мы получили несколько проблем (помимо того, что параметры запуска его БД надо подкручивать с увеличением базы).
Проблема первая: слишком много сообщений. У меня было около 70 тысяч непрочитанных сообщений от заббикса за три месяца. Да, можно подкрутить шаблоны, повыключать алерты, разметить группы, чем я частично и занялась.. Но мы подходим ко второй проблеме: сообщения не информативны для понимания состояния работоспособности инфраструктуры.
Ну то есть, сообщение "меньше 5ГБ осталось на диске D сервера s00-db01". Вообще не говорит нам о том, что у нас навернулся или НЕ навернулся корпоративный портал. А такое же сообщение про диск G - это не критично, потому что "не обращайте внимания, это temp db".
Или, например, "туннель с Роутером1 Вологды недоступен". Тут сразу вопрос: а с роутером2 доступен? Ну то есть, сеть филиала видна, всё ок, резерв работает. Или, например, недоступны все туннели с Вологдой. Плохо это? Ну как бы да, филиал недоступен. Но, допустим, время сейчас 3 утра субботы, филиал не работает. А может время рабочее, но они прислали письмо "у нас авария на электроподстанции, полгорода без света". Уже сразу критичность инцидента понижается - потому что не нужна связь или сделать со своей стороны ничего не можем.
И третья проблема: а непонятно, как определять критичность, как определить ответственных, кто должен добавить там места или посмотреть что с туннелями. И непонятно, что считать за "хорошее состояние системы". Можно начать писать инструкцию на каждый сервер, но сервера прибавляются быстрее, чем ты пишешь инструкции.
То есть, есть у нас гора алертов заббикса, есть круглосуточная поддержка в виде одного человека единовременно, который пырится в этот мониторнг и пытается понять, а что с этим делать. И у которого записки "на это не обращать внимания, а вот это важно, писать туда".
Я тут сходила в мае на LinkMeetUp, послушала тематические доклады и, наверное, смогла лучше сформулировать то, что нам надо. А может, компания дозрела до перемен.
А теперь забываем все перечисленные проблемы. Потому что это такие, ит-шные мелкие проблемки. Ставим вопрос по другому: а что важно для бизнеса? Для бизнеса важно понимать, что не сломался бизнес-процесс. Сайтик крутится, лавэха мутится, как говорится. И приходим к мониторингу сервисов, а не серверов. Тут надо поймать баланс между ИТ-метриками и бизнес-метриками, конечно. А в идеале мониторить и то и другое.
Много чего нужно в идеале и я про что-то попробую рассказать в будущих постах. Но мы помним, компания не рождается гуглом и яндексом. Из имеющихся сил - примерно я. А мониторинг - отнюдь не единственная область, которой я занимаюсь в компании.
Поэтому я начала с малого: веб сервисы. Это достаточно просто и наглядно, плюс должно сильно уменьшить время реакции на важные инциденты. Да, то, что веб страничка возвращает 200 ОК не означает, что сервис прямо таки работает. Но лучше такой мониторинг, чем "а зайди проверь, говорят, портал чёт упал".
Продолжение в следующих сериях. Там будет про написание инструкций, prometheus, grafana, а также поучаствуют нейросети.
Спасибо всем, кто не отписался!
Сегодня поговорим про то, как происходит трансформация подхода к мониторингу. На моём примере.
Кто помнит, я в посте "заббикс в первый раз" рассказывала как я когда-то в древности поднимала нам мониторинг. С тех пор прошло много времени. Какие-то попытки прийти к более приемлемой работе с инцидентами у меня были года два назад и тогда они не увенчались успехом.
Но попробуем по порядку. Заббикс у нас мониторит серваки и сетевое оборудование. И вроде всё хорошо. Но с ростом инфраструктуры мы получили несколько проблем (помимо того, что параметры запуска его БД надо подкручивать с увеличением базы).
Проблема первая: слишком много сообщений. У меня было около 70 тысяч непрочитанных сообщений от заббикса за три месяца. Да, можно подкрутить шаблоны, повыключать алерты, разметить группы, чем я частично и занялась.. Но мы подходим ко второй проблеме: сообщения не информативны для понимания состояния работоспособности инфраструктуры.
Ну то есть, сообщение "меньше 5ГБ осталось на диске D сервера s00-db01". Вообще не говорит нам о том, что у нас навернулся или НЕ навернулся корпоративный портал. А такое же сообщение про диск G - это не критично, потому что "не обращайте внимания, это temp db".
Или, например, "туннель с Роутером1 Вологды недоступен". Тут сразу вопрос: а с роутером2 доступен? Ну то есть, сеть филиала видна, всё ок, резерв работает. Или, например, недоступны все туннели с Вологдой. Плохо это? Ну как бы да, филиал недоступен. Но, допустим, время сейчас 3 утра субботы, филиал не работает. А может время рабочее, но они прислали письмо "у нас авария на электроподстанции, полгорода без света". Уже сразу критичность инцидента понижается - потому что не нужна связь или сделать со своей стороны ничего не можем.
И третья проблема: а непонятно, как определять критичность, как определить ответственных, кто должен добавить там места или посмотреть что с туннелями. И непонятно, что считать за "хорошее состояние системы". Можно начать писать инструкцию на каждый сервер, но сервера прибавляются быстрее, чем ты пишешь инструкции.
То есть, есть у нас гора алертов заббикса, есть круглосуточная поддержка в виде одного человека единовременно, который пырится в этот мониторнг и пытается понять, а что с этим делать. И у которого записки "на это не обращать внимания, а вот это важно, писать туда".
Я тут сходила в мае на LinkMeetUp, послушала тематические доклады и, наверное, смогла лучше сформулировать то, что нам надо. А может, компания дозрела до перемен.
А теперь забываем все перечисленные проблемы. Потому что это такие, ит-шные мелкие проблемки. Ставим вопрос по другому: а что важно для бизнеса? Для бизнеса важно понимать, что не сломался бизнес-процесс. Сайтик крутится, лавэха мутится, как говорится. И приходим к мониторингу сервисов, а не серверов. Тут надо поймать баланс между ИТ-метриками и бизнес-метриками, конечно. А в идеале мониторить и то и другое.
Много чего нужно в идеале и я про что-то попробую рассказать в будущих постах. Но мы помним, компания не рождается гуглом и яндексом. Из имеющихся сил - примерно я. А мониторинг - отнюдь не единственная область, которой я занимаюсь в компании.
Поэтому я начала с малого: веб сервисы. Это достаточно просто и наглядно, плюс должно сильно уменьшить время реакции на важные инциденты. Да, то, что веб страничка возвращает 200 ОК не означает, что сервис прямо таки работает. Но лучше такой мониторинг, чем "а зайди проверь, говорят, портал чёт упал".
Продолжение в следующих сериях. Там будет про написание инструкций, prometheus, grafana, а также поучаствуют нейросети.
👍18🔥6❤1
Продолжаем про мониторинг. Серия 2 из нескольких.
Началось всё на самом деле с "поговорить". Пришла к начальнику и попыталась выянить, а какие сервисы у нас важны с точки зрения бизнеса. Ну вот, за что мы денег либо потеряем, либо недоприобретём. А какие просто важные и хотелось бы следить, потому что неприятно, когда падает, а мы (ИТ) узнаём об этом не первыми. Слово за слово, провели пяток совещаний и поняли с чего начать. Начальник ещё посоветовал почитать приказ "об обеспечении непрерывности деятельности" - сто страниц чистого восторга! Там написано примерно всё то, что я хотела делать. Правда, относится он в основном ко всяким пожарам, наводнениям и прочим прорывам дамб, но натягивается на нужную область как родной.
Второй момент: я попыталась донести, что мало мониторить сервисы, надо к ним при постановке на мониторинг писать сопроводиловку, где будет указано:
- "нормальное" состояние системы (у нас есть сервис, который виснет на ответах каждые несколько минут и это его нормальное состояние - всех устраивает доступность 94% в час)
- уровень отклонений, когда работают алерты
- уровень критичности (будить ночью ответственного или потерпит)
- собственно список ответственных (не по документам, а по факту - кто может диагностировать и починить)
- желательно, простые шаги диагностики, которые может выполнить поддержка
- желательно, простые шаги для починки, котоые может выполнить поддержка перед эскалацией (типа, выполни скрипт, ребутни службу, ребутни сервер)
- ну и путь эскалации
И вот всё это не на 57 страниц приказа, а понятным языком во внутренней вики и по единой схеме. Ну чтоб люди в момент, когда упало, не читали многотомник канцелярщины, а имели простые и понятные шаги для диагностики и выполнения.
Потом, очень потом, сюда добавятся группы реагирования, анализ инцидентов и прочее. В идеале ещё бы иметь схему зависимости сервисов, которая может разворачиваться и углубляться до серверов. Обновляемую.
Вообще, задача "а давайте внедрим SRE" выглядит масштабно до одури. Но у меня есть опыт переваривания больших задач, которые делались годами. Так что послушаем умных людей и примем, что SRE начинается с правильного мониторинга.
Заббикс я решила не трогать - мониторить, где там место кончилось, тоже надо. В планах потом сильно уменьшить от него поток оповещений. В общем, заббикс остаётся как низкоуровневый мониторинг и как мониторинг с длительной историей (год).
А параллельно поднимаю prometheus, victoriametrics и графану. Это будет оперативный мониторинг. И начала я с blackbox exporter, который проверяет у меня отклик от веб страничкек.
Поднять по инструкции - в целом, проблем не вызвало. А вот дальше меня ждало то, что всегда бывает, когда начинаешь изучать что-то прям для себя новое. В yaml я ни в зуб ногой, синтаксис незнакомый, promql тоже как бы. Что там должно подняться, где конфиги и где метрики - тоже надо изучать. Как сделать так, чтобы 401 unauthorized было валидным ответом и т.д.
Обычно как: чет гуглишь, настраиваешь, не работает, изучаешь логи, гуглишь ещё и так до победного. А тут я внезапно сходила на ещё одну конфу, где был очень искренний доклад сетевого инженера о том, что нейросети реально могут помочь, и вообще лучше, чем мы, старпёры, думаем. И я пошла общаться с deepseek.
Писала ему примерно как ТЗ для тупенького админа, который обязательно твоё ТЗ извратит. Это, чёрт возьми, работает. И очень, прям очень помогает сломать первую стену непонимания работы системы. Да, потом он пошёл врать, уже на шаблонах алертменеджера. Да, надо быть внимательным и перепроверять. Да, он советует китайские дашборды к графане. Да, надо понимать, что нельзя в него копипастить корпоративные данные. Но насколько же это охрененно, когда deepseek мне сократил время до начала работы системы в приемлемом виде раз в семь!
Продолжение следует.
Началось всё на самом деле с "поговорить". Пришла к начальнику и попыталась выянить, а какие сервисы у нас важны с точки зрения бизнеса. Ну вот, за что мы денег либо потеряем, либо недоприобретём. А какие просто важные и хотелось бы следить, потому что неприятно, когда падает, а мы (ИТ) узнаём об этом не первыми. Слово за слово, провели пяток совещаний и поняли с чего начать. Начальник ещё посоветовал почитать приказ "об обеспечении непрерывности деятельности" - сто страниц чистого восторга! Там написано примерно всё то, что я хотела делать. Правда, относится он в основном ко всяким пожарам, наводнениям и прочим прорывам дамб, но натягивается на нужную область как родной.
Второй момент: я попыталась донести, что мало мониторить сервисы, надо к ним при постановке на мониторинг писать сопроводиловку, где будет указано:
- "нормальное" состояние системы (у нас есть сервис, который виснет на ответах каждые несколько минут и это его нормальное состояние - всех устраивает доступность 94% в час)
- уровень отклонений, когда работают алерты
- уровень критичности (будить ночью ответственного или потерпит)
- собственно список ответственных (не по документам, а по факту - кто может диагностировать и починить)
- желательно, простые шаги диагностики, которые может выполнить поддержка
- желательно, простые шаги для починки, котоые может выполнить поддержка перед эскалацией (типа, выполни скрипт, ребутни службу, ребутни сервер)
- ну и путь эскалации
И вот всё это не на 57 страниц приказа, а понятным языком во внутренней вики и по единой схеме. Ну чтоб люди в момент, когда упало, не читали многотомник канцелярщины, а имели простые и понятные шаги для диагностики и выполнения.
Потом, очень потом, сюда добавятся группы реагирования, анализ инцидентов и прочее. В идеале ещё бы иметь схему зависимости сервисов, которая может разворачиваться и углубляться до серверов. Обновляемую.
Вообще, задача "а давайте внедрим SRE" выглядит масштабно до одури. Но у меня есть опыт переваривания больших задач, которые делались годами. Так что послушаем умных людей и примем, что SRE начинается с правильного мониторинга.
Заббикс я решила не трогать - мониторить, где там место кончилось, тоже надо. В планах потом сильно уменьшить от него поток оповещений. В общем, заббикс остаётся как низкоуровневый мониторинг и как мониторинг с длительной историей (год).
А параллельно поднимаю prometheus, victoriametrics и графану. Это будет оперативный мониторинг. И начала я с blackbox exporter, который проверяет у меня отклик от веб страничкек.
Поднять по инструкции - в целом, проблем не вызвало. А вот дальше меня ждало то, что всегда бывает, когда начинаешь изучать что-то прям для себя новое. В yaml я ни в зуб ногой, синтаксис незнакомый, promql тоже как бы. Что там должно подняться, где конфиги и где метрики - тоже надо изучать. Как сделать так, чтобы 401 unauthorized было валидным ответом и т.д.
Обычно как: чет гуглишь, настраиваешь, не работает, изучаешь логи, гуглишь ещё и так до победного. А тут я внезапно сходила на ещё одну конфу, где был очень искренний доклад сетевого инженера о том, что нейросети реально могут помочь, и вообще лучше, чем мы, старпёры, думаем. И я пошла общаться с deepseek.
Писала ему примерно как ТЗ для тупенького админа, который обязательно твоё ТЗ извратит. Это, чёрт возьми, работает. И очень, прям очень помогает сломать первую стену непонимания работы системы. Да, потом он пошёл врать, уже на шаблонах алертменеджера. Да, надо быть внимательным и перепроверять. Да, он советует китайские дашборды к графане. Да, надо понимать, что нельзя в него копипастить корпоративные данные. Но насколько же это охрененно, когда deepseek мне сократил время до начала работы системы в приемлемом виде раз в семь!
Продолжение следует.
👍15❤2🔥2
Продолжаем про мониторинг, серия 3 из нескольких.
Итак, прошлая серия закончилась на том, что я решила начать с веб-сервисов и blackbox exporter. Дальше с помощью deepseek и матерных выражений склеила два шаблона в графане во что-то приличное. Поняла, что сервисы, требующие авторизации, требуют подкручивания. Подкрутила.
Дальше черёд был за алертами. Спросила нейросетку: что лучше? Она ответила: алерты графаны типа попроще и есть веб-интерфейс, а алерты от алертменеджера более гибкие в настройке, но только yaml. Честно скажу: от графановских алертов я исплевалась. Про простоту настройки - это им сильно польстили. Через пару часов свернула насилие над собой и поставила алерт-менеджер. Потом с временем реагировния, с уровнями алертов поигралась, пока не пришла к чему-то удобоваримому.
Кстати, оффтопик. Как отладить работу алертов доступности (веб странички) без того, чтобы ронять сервис? Просто в hosts на сервере мониторинга прописываете типа
(Меняете на любой серый адрес, которого нет в вашей сети).
И всё, для мониторинга сервис недоступен. А для всех остальных пользователей ничего не поменялось. Это, конечно, не отследит какую там ошибку сервер отдаёт, когда падает, но для первичной настройки - самое то.
И вот, когда я показала народу первый результат, на который можно попыриться на большом экране, начались параллельно несколько следующих этапов. Первый - следить за алертами и подкручивать "наживую" - чтоб понять, что есть "нормальная работы системы". Кстати, сразу прям стала видна ненормальная работы одной из систем, на что программеры сказали "знаем, только полностью ререписывать код, ща времени нет, некритично, терпите". Они вот знали, а кто-то и не знал..
Второй этап - написать хоть на какие-то сервисы ту самую "сопроводиловку", определив её формат. Выглядит это примерно так: сервис такой-то, общее название "окошки". Критичность низкая. Нормальные показатели: ответ 200, сертификат сроком действия больше нуля, доступность 98% в час или более 0% за 2 последних минуты. Как проверить: зайти по ссылке, должен мелким текстом показаться json такого-то вида. Валиден любой текст, кроме ошибки. Как лечить: перезапустить iis на сервере Х. Кто может починить, если не помогло? Вася П.
Пока я в процессе формирования всего этого, нужно ещё обмазывать табличку в вики регламентом реакции на инциденты.
Третий этап - стребовать сопроводиловку на уже заведённые в мониторинг сервисы. Ну, я их добавляла по велению души и начальника. Типа мы прикинули, помимо критичных сервисов, на что нам тут жаловались последнее время - то и загнали. Это прям самый непростой пункт - народ сопротивляется как может.
Четвертый этап: эй все, присылайте сервисы с сопроводиловкой. Будем добавлять. Ну и там маленько бюрократии: создать сервис в хэлпдеске под такие заявки, например. Ещё оттестировать алерты на почту. Deepseek прям вообще не может в шаблоны алертменеджера, сразу врёт напропалую. Не сразу догадалась попросить его прямую ссылку на кусок документации - тогда и стронулось дело.
На самом деле, из пройденных этапов осталось рассказать ещё про маленькую интересную задачку, ну и может пару слов про шаблоны алерт-менеджера. А потом серия продолжится уже только сильно позже, с новыми результатами.
Итак, прошлая серия закончилась на том, что я решила начать с веб-сервисов и blackbox exporter. Дальше с помощью deepseek и матерных выражений склеила два шаблона в графане во что-то приличное. Поняла, что сервисы, требующие авторизации, требуют подкручивания. Подкрутила.
Дальше черёд был за алертами. Спросила нейросетку: что лучше? Она ответила: алерты графаны типа попроще и есть веб-интерфейс, а алерты от алертменеджера более гибкие в настройке, но только yaml. Честно скажу: от графановских алертов я исплевалась. Про простоту настройки - это им сильно польстили. Через пару часов свернула насилие над собой и поставила алерт-менеджер. Потом с временем реагировния, с уровнями алертов поигралась, пока не пришла к чему-то удобоваримому.
Кстати, оффтопик. Как отладить работу алертов доступности (веб странички) без того, чтобы ронять сервис? Просто в hosts на сервере мониторинга прописываете типа
192.168.10.2 myservice.mydomain.ru (Меняете на любой серый адрес, которого нет в вашей сети).
И всё, для мониторинга сервис недоступен. А для всех остальных пользователей ничего не поменялось. Это, конечно, не отследит какую там ошибку сервер отдаёт, когда падает, но для первичной настройки - самое то.
И вот, когда я показала народу первый результат, на который можно попыриться на большом экране, начались параллельно несколько следующих этапов. Первый - следить за алертами и подкручивать "наживую" - чтоб понять, что есть "нормальная работы системы". Кстати, сразу прям стала видна ненормальная работы одной из систем, на что программеры сказали "знаем, только полностью ререписывать код, ща времени нет, некритично, терпите". Они вот знали, а кто-то и не знал..
Второй этап - написать хоть на какие-то сервисы ту самую "сопроводиловку", определив её формат. Выглядит это примерно так: сервис такой-то, общее название "окошки". Критичность низкая. Нормальные показатели: ответ 200, сертификат сроком действия больше нуля, доступность 98% в час или более 0% за 2 последних минуты. Как проверить: зайти по ссылке, должен мелким текстом показаться json такого-то вида. Валиден любой текст, кроме ошибки. Как лечить: перезапустить iis на сервере Х. Кто может починить, если не помогло? Вася П.
Пока я в процессе формирования всего этого, нужно ещё обмазывать табличку в вики регламентом реакции на инциденты.
Третий этап - стребовать сопроводиловку на уже заведённые в мониторинг сервисы. Ну, я их добавляла по велению души и начальника. Типа мы прикинули, помимо критичных сервисов, на что нам тут жаловались последнее время - то и загнали. Это прям самый непростой пункт - народ сопротивляется как может.
Четвертый этап: эй все, присылайте сервисы с сопроводиловкой. Будем добавлять. Ну и там маленько бюрократии: создать сервис в хэлпдеске под такие заявки, например. Ещё оттестировать алерты на почту. Deepseek прям вообще не может в шаблоны алертменеджера, сразу врёт напропалую. Не сразу догадалась попросить его прямую ссылку на кусок документации - тогда и стронулось дело.
На самом деле, из пройденных этапов осталось рассказать ещё про маленькую интересную задачку, ну и может пару слов про шаблоны алерт-менеджера. А потом серия продолжится уже только сильно позже, с новыми результатами.
👍11