Mikrotik Ninja
3.53K subscribers
341 photos
7 videos
56 files
1.14K links
Канал по новым компьютерным технологиям и защите компьютерных программ


Блог http://bubnovd.net
https://medium.com/@dbubnov
https://xakep.ru/author/bubnovd/
Мысли неглупых людей https://t.me/channel1name
Книги https://t.me/mreadninja
Download Telegram
Forwarded from DevOps&SRE Library
Building SRE from Scratch

Как организовать SRE процессы с нуля.

https://medium.com/ibm-garage/building-sre-from-scratch-485e23985bbd
- Для чего можно использовать Ansible?
- Для установки Puppet
(C) Алексей Степаненко. Селектел
Forwarded from NetDevOps Space
Наткнулся на интересное пошаговое руководство по Ansible для использования в автоматизации сетей.
Руководство в виде выполнения лабораторной работы с 5 маршрутизаторами.

Внутри разбирается следующее:
1. Автоматическое резервное копирование конфигурации
2. Соответствие требованиям безопасности - на основе ACL
3. Простая настройка маршрутизатора
4. Настройка маршрутизатора - Использование Roles
5. Траблшутинг сети

Супер! - 🔥
То, что надо! - 💪
Nornir лучше! - 🧐

Хотите обсудить, добро пожаловать в чат - https://t.me/automate_devnet

#ansible
Forwarded from Мониторим ИТ
Посмотрите на эту картинку. Да, это из известной сказки, в которой лживый мальчик кричал «Волки! Волки!» в то время, когда волки доедали каких-то других козлят. А когда волки пришли за его козлятами — никто не прибежал с вилами на помощь.

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

1️⃣ Выгружать отчёты по событиям/алертам. Выявлять повторяющиеся. В идеале каждое событие должно появляться из-за какого-то нового бага в коде или настройках.

2️⃣ События должны быть только по тому, что требует вмешательства. Если можно автоматизировать реакцию на событие — это нужно сделать как можно скорее и никого об этом не оповещать. Это касается повторяющихся событий, причину которых невозможно пофиксить.

3️⃣ В системах мониторинга или алертинга есть (или должен быть) такой Duration. Это позволит не реагировать на разовые всплески. Важно уточнить у администраторов информационных систем насколько долго эти системы могут работать в «красной зоне».

4️⃣ По каждому событию/алерту в системе мониторинга должна фиксироваться реакция ответственного сотрудника. Если на какие-то события реакции нет — нужно выяснить кто заказывал мониторинг. Может это уже никому не нужно.

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

6️⃣ Создавайте связанные триггеры. В системах Zabbix и Prometheus это можно делать. Не нужно плодить 100500 событий из-за отказавшего коммутатора на удалённой площадке.

7️⃣ Если есть мониторинг приложения, которое разрабатывается парнями через стенку, важно, чтобы они поучаствовали в определении метрик мониторинга, на которые должна реагировать эксплуатация (да они сами что-то могли записать в баг-репорт).

Хотел написать 10, но на 7 мысль дальше не идёт. Если хотите небольшое продолжение — я как-то писал на Медиуме о борьбе с событийной усталостью. Малую толику информации можно посмотреть там.
Forwarded from Мониторим ИТ
Подвезли стафф для линукс-администраторов. Ещё одна интересная статья от уже известного вам Антуана Солничкина, на которую стоит обратить внимание. Пишет про мониторинг MySQL при помощи специализированного экспортера для Prometheus и создании бизнес-дашборда в Grafana. Там есть список ключевых метрик и парав видосов с объяснениями.
Шшшшшикарно
🔎 https://ihateregex.io/ - пачка примеров регэкспов, с объяснением того, как они работают. #линк #regexp
Никому не нужны твои знания всех ключей Ansible и годы поддержки MS SQL. Чтобы быть востребованным на рынке нужно уметь быстро учиться и видеть широкий горизонт перед собой. Нужно правильно строить процессы работы, а не заучивать команды.

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

https://medium.com/@dbubnov/%D0%BC%D0%B8%D1%80%D1%83-%D0%BD%D1%83%D0%B6%D0%BD%D1%8B-%D0%B8%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D1%8B-cb2908c0952f
Forwarded from linkmeup
Давненько нас не обвиняли, что мы тут все помешанные на Wi-Fi.
Дельный набор советов по поиску проблем на основе понимания типа фреймов и что в них может пойти не так.

https://keepcalmandping.online/2020/02/07/troubleshooting-wlan-issues-with-802-11-frames-cwap9/
В Mikrotik есть инструмент Sniffer (в меню Tools), который позволяет дампить весь трафик или отфильтрованный по каким-то условиям. Дамп можно открыть прямо в WinBox или скопировать на компьютер и наглядно посмотреть на него в Wireshark.

А в IP - Firewall - Mangle есть действие sniff-tzsp. Мало кто знает что оно делает. Этот экшн снифит трафик, специальным образом упаковывает его и отправляет по нужному адресу в сети. То есть этакий Sniffer, только с отправкой дампа на нужный узел (ага, Wireshark) в реальном времени.

Проблема в том, что распаковать этот tzsp непросто. Поэтому эта фича часто остается незамеченной. Здесь попытка написать распаковщик для этого протокола. Будем ждать от автора работающий бинарник.

Если вы знаете работающий распаковщик TZSP, то напишите о нем в комментариях.

🤩 - супер! Буду пользоваться
👽 - а че так можно было? До чего техика дошла!
🤢 - вряд ли кому-то пригодится
В личку добавляют, что сам tool - Sniffer умеет отправлять дамп на удаленный хост в реальном времени. Как правильно настроить Wireshark для приема этого дампа по ссылке

Спасибо, Макс

#wireshark #mikrotik #sniffer
Когда-то писал подобное с применением iperf

#speed #test #speedtest
Forwarded from NetDevOps Space
Не питоном единым...
Так можно назвать статью, в которой Kelvin Tegelaar рассказывает об истории создания скрипта на Powershell для проверки скорости соединения. Он создал его по просьбе своего друга, которого попросил один из клиентов, который хотел иметь возможность запускать тесты скорости и заставлять систему RMM генерировать алерты каждый раз, когда падает скорость соединения.
Он создал скрипт на PowerShell, который использует утилиту CLI от speedtest.net
Прям как в "Доме, который построил Джек".
Что умеет делать скрипт:

1. Возвращает внешний и внутренний IP для используемого интерфейса.
2. Текущий провайдер.
3. Скорость загрузки и выгрузки.
4. Jitter, задержку и потери пакетов при соединении.
5. Сервер, который он использует
6. Фактический адрес speedtest.net для сравнения результатов.

Круто!-👍
Вон оно как!- 🤔
Я бы лучше сделал!-😏

Хотите поделиться своим мнением? Добро пожаловать в чат - https://t.me/automate_devnet

#powershell
Как трубят во всех каналах про сети, Mikrotik имплементирует VXLAN в 7 версии RouterOS. А это значит, что через пару лет Mikrotik можно будет увидеть в датацентрах.

Первая лаба с VXLAN уже описана в Интернетах - ученье свет!

#vxlan
https://snafucatchers.github.io - мета-анализ постмортемов из Etsy, IBM, и IEX

Советуют в чатике курсов

#postmortem
Поучительная история, подтверждающая мой недавний пост про инженеров. Иногда возникают такие проблемы, которые можно решить только обладая глубокими познаниями в широком стеке технологий

https://dou.ua/lenta/columns/story-of-new-years-eve-release/

#архитектор