Forwarded from Откровенная аналитика
🚀 Как ещё быстрее прикинуть вилку на вакансию
В догонку к предыдущему посту
Во всех способах, которые я описывал выше, нужно что-то делать самому. А мне давно хотелось, чтобы было как-то попроще. И вот наконец сделал инструмент, который умеет оценивать вилку на вакансию
Так что встречайте @transparency_salary_bot
Ему достаточно скинуть ссылку на вакансию в headhunter, а он вернёт диапазон вознаграждения (пока работает только с HH, но если нужно подключить другие порталы, пишите)
Как это работает: под капотом у бота стоит llm дообученная на датасете свежих вакансий. Если интересны подробности, то напишите в комментариях, и я подготовлю рассказ, как обучал
Ну и не стесняйтесь писать в лс, если что-то не работает, да и вообще с любыми пожеланиями, соображениями или критикой
Всем огромных вилок и быстрых собесов)
В догонку к предыдущему посту
Во всех способах, которые я описывал выше, нужно что-то делать самому. А мне давно хотелось, чтобы было как-то попроще. И вот наконец сделал инструмент, который умеет оценивать вилку на вакансию
Так что встречайте @transparency_salary_bot
Ему достаточно скинуть ссылку на вакансию в headhunter, а он вернёт диапазон вознаграждения (пока работает только с HH, но если нужно подключить другие порталы, пишите)
Как это работает: под капотом у бота стоит llm дообученная на датасете свежих вакансий. Если интересны подробности, то напишите в комментариях, и я подготовлю рассказ, как обучал
Ну и не стесняйтесь писать в лс, если что-то не работает, да и вообще с любыми пожеланиями, соображениями или критикой
Всем огромных вилок и быстрых собесов)
👍16
В Capirca есть встроенный механизм проверки сетевой доступности на уровне конкретной политики.
Запуск:
Результат при наличии доступа:
Результат при отсутствии доступа:
Эти параметры можно вынести в переменные:
--destination-port
--destination
--source
--protocol
--policy-file
В Jenkins это будет выглядеть примерно так:
Запуск:
python3 /app/aclcheck_cmdline.py --definitions-directory def --destination-port 443 --source 10.1.1.1 --destination 10.2.2.2 --protocol tcp --policy-file pol/test_acl.pol
Результат при наличии доступа:
pol/test_acl.pol
filter: TEST_ACL
term: rule_10
accept
Результат при отсутствии доступа:
pol/test_acl.pol
filter: TEST_ACL
term: default-deny
deny
Эти параметры можно вынести в переменные:
--destination-port
--destination
--source
--protocol
--policy-file
В Jenkins это будет выглядеть примерно так:
👍5
Мы разрабатываем сервис, который поможет сетевикам управлять аплинками.
Задача: в изолированном окружении развернуть виртуальный маршрутизатор и анонсировать на него несколько Full-View.
Этот стенд использовался для сбора BMP и NetFlow с маршрутизатора и последующего анализа. В процессе работы генерировался трафик между различными виртуальными машинами, частично отключались анонсы, изменялись политики маршрутизации и выключались аплинки, что имитировало продуктивное окружение
Анонсируем Full-View на изолированном стенде
#Задача
Задача: в изолированном окружении развернуть виртуальный маршрутизатор и анонсировать на него несколько Full-View.
Этот стенд использовался для сбора BMP и NetFlow с маршрутизатора и последующего анализа. В процессе работы генерировался трафик между различными виртуальными машинами, частично отключались анонсы, изменялись политики маршрутизации и выключались аплинки, что имитировало продуктивное окружение
Анонсируем Full-View на изолированном стенде
#Задача
Telegraph
Анонсируем Full-View на изолированном стенде
Дано: изолированная среда виртуализации VMware. Задача: Поднять Juniper vMX и анонсировать на него несколько Full-View. Схема стенда:
👍23
В продолжении предыдущего поста.
Я опубликовал статью на Habr, и в комментариях один коллега напомнил, что кроме Python существуют и другие инструменты, такие как awk.
Да, есть множество способов решить одну и ту же задачу, но вариант с awk действительно оказался проще, поэтому я добавил его в статью.
Я опубликовал статью на Habr, и в комментариях один коллега напомнил, что кроме Python существуют и другие инструменты, такие как awk.
Да, есть множество способов решить одну и ту же задачу, но вариант с awk действительно оказался проще, поэтому я добавил его в статью.
Хабр
Анонсируем Full-View на изолированном стенде
Дано: изолированная среда виртуализации VMware. Задача: Поднять Juniper vMX и анонсировать на него несколько Full-View. Схема стенда: Схема стенда Схема потребовалась для тестов во время разработки...
🔥10👍5🍓2
Как связать on-prem с облачной инфраструктурой
(часть 1 из 4)
В зарубежных облачных сервисах есть варианты:
0️⃣ Public Internet — арендуем публичный IP-адрес, назначаем на виртуальную машину в облаке. Это позволяет организовать доступ из on-prem в облачную инфраструктуру по этому IP, в принципе можно поднять с ним GRE/IPSec. Для полноценного Site-to-Site слабовато, но в целом почему бы и нет?
1️⃣ Managed IPSec — быстрый и дешевый(относительно 2️⃣ и 3️⃣ ) способ создания Site-to-Site соединения, предоставляемый как сервис. Однако производительность будет зависеть от возможностей вашего оборудования on-prem и лимитов виртуального маршрутизатора в облаке, а скорость поднятия связности только от вас, а именно, как быстро вы сможете подружить IPSec между on-prem и облаком.
2️⃣ Partner или Hosted подключение — подключение через сети операторов-партнеров, которые уже имеют настроенные сетевые стыки и интеграции с облачными провайдерами. Обычно выделяемая полоса составляет от 50 Mbps до 10 Gbps. В России таких услуг не встречал, но они доступны во многих популярных облаках за пределами страны.
3️⃣ Dedicated подключение — выделенная линия от вашей инфраструктуры до точки подключения к облаку. Организация этой линии лежит на вас(если у вас нет оборудования в том же ДЦ, если есть, то кроссировку все равно придется проложить), но скорость подключения может варьироваться от 1 до 400 Gbps на порт.
▎Про IPSec
Все цифры в таблице актуальны для одного туннеля, но если облачный провайдер позволяет создать второй туннель и настроить ECMP с использованием протоколов маршрутизации, то конечная скорость может быть выше.
При этом у всех облачных провайдеров разные лимиты на количество туннелей и их ограничения. Например, в AWS можно создать 50 Site-to-Site подключений в одном регионе, а с включенным ECMP это по 2.5Gbps на каждое подключение, т.е. в теории могло бы получиться 125Gbps, но больше 50Gbps получить все равно не выйдет:
Часть провайдеров в документации указывают pps(max packets per second), но верно подмечают, что могут быть нюансы:
Например, Google:
И не забываем про рекомендации на счет MTU/MSS при использовании разных
алгоритмов шифрования.
▎Про IPv6:
1. AWS сообщает, что нельзя использовать external ipv6 для установки туннелей, но внутри туннелей уже можно, но это не серьезно.
2. Google утверждает, что умеет строить туннели на ipv6, но только в схеме с HA, в classic VPN - нет.
3. Azure признает, что VPN Gateway пока не поддерживает ipv6, возможно тут слишком мало голосов за эту фичу. Надо поднажать, кому актуально.
4. Alibaba Cloud скромно говорят, что у них есть ipv6 Gateway, но он может только выпустить VM в Интернет по ipv6, но не более того.
5. Oracle заявляют, что поддерживают ipv6 и можно обмениваться трафиком между on-prem и cloud по ipv6, но судя по всему построить туннель на ipv6 не получится:
Скажу честно, не люблю IPv6, но при случаю подмечаю кто и как его использует. Интересно наблюдать со стороны.
Итого, если нужен «самый крутой IPSec», то выбираем Google Cloud!
(часть 1 из 4)
В зарубежных облачных сервисах есть варианты:
0️⃣ Public Internet — арендуем публичный IP-адрес, назначаем на виртуальную машину в облаке. Это позволяет организовать доступ из on-prem в облачную инфраструктуру по этому IP, в принципе можно поднять с ним GRE/IPSec. Для полноценного Site-to-Site слабовато, но в целом почему бы и нет?
1️⃣ Managed IPSec — быстрый и дешевый(относительно 2️⃣ и 3️⃣ ) способ создания Site-to-Site соединения, предоставляемый как сервис. Однако производительность будет зависеть от возможностей вашего оборудования on-prem и лимитов виртуального маршрутизатора в облаке, а скорость поднятия связности только от вас, а именно, как быстро вы сможете подружить IPSec между on-prem и облаком.
2️⃣ Partner или Hosted подключение — подключение через сети операторов-партнеров, которые уже имеют настроенные сетевые стыки и интеграции с облачными провайдерами. Обычно выделяемая полоса составляет от 50 Mbps до 10 Gbps. В России таких услуг не встречал, но они доступны во многих популярных облаках за пределами страны.
3️⃣ Dedicated подключение — выделенная линия от вашей инфраструктуры до точки подключения к облаку. Организация этой линии лежит на вас(если у вас нет оборудования в том же ДЦ, если есть, то кроссировку все равно придется проложить), но скорость подключения может варьироваться от 1 до 400 Gbps на порт.
▎Про IPSec
Все цифры в таблице актуальны для одного туннеля, но если облачный провайдер позволяет создать второй туннель и настроить ECMP с использованием протоколов маршрутизации, то конечная скорость может быть выше.
При этом у всех облачных провайдеров разные лимиты на количество туннелей и их ограничения. Например, в AWS можно создать 50 Site-to-Site подключений в одном регионе, а с включенным ECMP это по 2.5Gbps на каждое подключение, т.е. в теории могло бы получиться 125Gbps, но больше 50Gbps получить все равно не выйдет:
The maximum bandwidth of a combined (using ECMP) set of VPNs is 50 Gb/s
Часть провайдеров в документации указывают pps(max packets per second), но верно подмечают, что могут быть нюансы:
There are many factors that can affect realized bandwidth through a Site-to-Site VPN connection, including but not limited to: packet size, traffic mix (TCP/UDP), shaping or throttling policies on intermediate networks, internet weather, and specific application requirements.
Например, Google:
250,000 packets per second is roughly equivalent to 1 Gbps to 3 Gbps, depending on the average packet size within the tunnel.
И не забываем про рекомендации на счет MTU/MSS при использовании разных
алгоритмов шифрования.
▎Про IPv6:
1. AWS сообщает, что нельзя использовать external ipv6 для установки туннелей, но внутри туннелей уже можно, но это не серьезно.
2. Google утверждает, что умеет строить туннели на ipv6, но только в схеме с HA, в classic VPN - нет.
3. Azure признает, что VPN Gateway пока не поддерживает ipv6, возможно тут слишком мало голосов за эту фичу. Надо поднажать, кому актуально.
4. Alibaba Cloud скромно говорят, что у них есть ipv6 Gateway, но он может только выпустить VM в Интернет по ipv6, но не более того.
5. Oracle заявляют, что поддерживают ipv6 и можно обмениваться трафиком между on-prem и cloud по ipv6, но судя по всему построить туннель на ipv6 не получится:
CPE device's public IP address. (The address must be IPv4, but IPv6 traffic is supported)
Скажу честно, не люблю IPv6, но при случаю подмечаю кто и как его использует. Интересно наблюдать со стороны.
Итого, если нужен «самый крутой IPSec», то выбираем Google Cloud!
👍14
Как связать on-prem с облачной инфраструктурой
(часть 2 из 4)
Каждый облачный провайдер предлагает свои сетевые сервисы(названия у всех свои), которые позволяют устанавливать прямые соединения между локальной on-prem инфраструктурой и облаком. Подключение может осуществляться через операторов-партнеров (Hosted/Partner) или напрямую к оборудованию облака (Dedicated).
▎Про Hosted/Partner подключение
Для подключения обычно доступны следующие скорости: 50 Mbps, 100 Mbps, 200 Mbps, 300 Mbps, 400 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps и 10 Gbps. В документации AWS также упоминается про 25 Gbps.
Процесс подключения достаточно прост:
1. Найдите провайдера, который предлагает услугу подключения к облаку.
2. Подключитесь к выбранному оператору.
3. Сообщите провайдеру данные вашего аккаунта в облаке.
4. Ожидайте, пока провайдер активирует новое подключение в вашем аккаунте.
5. Подтвердите новое подключение в вашем аккаунте.
6. Настройте виртуальный маршрутизатор и интерфейсы в облаке, а также BGP.
7. Настройте BGP на маршрутизаторе в вашей on-prem инфраструктуре.
Существуют варианты с L2 и L3. В случае с L2VPN BGP-сессия устанавливается с виртуальным маршрутизатором в облаке, а для L3VPN — с маршрутизатором оператора, предоставившего канал. Однако не все провайдеры всегда предлагают выбор между L2 и L3. Приходится брать то, что есть!
Одно Hosted подключение соответствует одному виртуальному интерфейсу, то есть одному VLAN. Если требуется несколько VLAN, придется заказывать дополнительное Hosted подключение или переходить на Dedicated.
▎Про IPv6
В документации утверждается, что пириться по IPv6 можно со всеми.
Ссылки на партнерские включения по регионам присутствия:
1. AWS Direct Connect partners
2. Google Cloud partners
3. Azure Express Route partners
4. Alibaba Cloud Express Connect partners
5. Oracle Cloud Fast Connect partners
(часть 2 из 4)
Каждый облачный провайдер предлагает свои сетевые сервисы(названия у всех свои), которые позволяют устанавливать прямые соединения между локальной on-prem инфраструктурой и облаком. Подключение может осуществляться через операторов-партнеров (Hosted/Partner) или напрямую к оборудованию облака (Dedicated).
▎Про Hosted/Partner подключение
Для подключения обычно доступны следующие скорости: 50 Mbps, 100 Mbps, 200 Mbps, 300 Mbps, 400 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps и 10 Gbps. В документации AWS также упоминается про 25 Gbps.
Процесс подключения достаточно прост:
1. Найдите провайдера, который предлагает услугу подключения к облаку.
2. Подключитесь к выбранному оператору.
3. Сообщите провайдеру данные вашего аккаунта в облаке.
4. Ожидайте, пока провайдер активирует новое подключение в вашем аккаунте.
5. Подтвердите новое подключение в вашем аккаунте.
6. Настройте виртуальный маршрутизатор и интерфейсы в облаке, а также BGP.
7. Настройте BGP на маршрутизаторе в вашей on-prem инфраструктуре.
Существуют варианты с L2 и L3. В случае с L2VPN BGP-сессия устанавливается с виртуальным маршрутизатором в облаке, а для L3VPN — с маршрутизатором оператора, предоставившего канал. Однако не все провайдеры всегда предлагают выбор между L2 и L3. Приходится брать то, что есть!
Одно Hosted подключение соответствует одному виртуальному интерфейсу, то есть одному VLAN. Если требуется несколько VLAN, придется заказывать дополнительное Hosted подключение или переходить на Dedicated.
▎Про IPv6
В документации утверждается, что пириться по IPv6 можно со всеми.
Ссылки на партнерские включения по регионам присутствия:
1. AWS Direct Connect partners
2. Google Cloud partners
3. Azure Express Route partners
4. Alibaba Cloud Express Connect partners
5. Oracle Cloud Fast Connect partners
👍7❤1
Как связать on-prem с облачной инфраструктурой
(часть 3 из 4)
▎Про Dedicated подключение
В зависимости от облака для подключения доступны варианты от 1 до 400 Gbps. Все поддерживают LAG, но есть ограничения:
100/400G x 2
10G x 8
Только AWS пишет про поддержку 400Gbps.
Процесс подключения достаточно прост:
1. Найдите ЦОД(PoP), где можно подключиться к облаку
2. Создайте новое подключение в консоли облака в данной точке присутствия
3. Дождитесь пока запрос на новое подключение будет выполнен
4. Скачайте Letter of Authorization and Connecting Facility Assignment (LOA-CFA, тут будут координаты портов для включения
5. Закажите кроссировку(и) в ЦОДе, данные будут в LOA
6. Настройте виртуальный маршрутизатор и интерфейсы в облаке (и BGP)
7. Настройте BGP на маршрутизаторе в вашей on-prem инфраструктуре
Далее возможны варианты по построению отказоустойчивых схем, например подключение к Direct Connect в разных AZ.
В комменты кину пример LOA из далекого 2020 г.
▎Про IPv6
В документации утверждается, что пириться по IPv6 можно со всеми.
P.S. Сейчас в РФ использовать зарубежные облака стало практически невозможно и независимо от того как будут дальше развиваться события, думаю никто их уже не будет использовать как раньше(или убедите меня в обратном). Поэтому осталось посмотреть, а что там есть из вариантов подключения к «нашим» облакам.
(часть 3 из 4)
▎Про Dedicated подключение
В зависимости от облака для подключения доступны варианты от 1 до 400 Gbps. Все поддерживают LAG, но есть ограничения:
100/400G x 2
10G x 8
Только AWS пишет про поддержку 400Gbps.
Процесс подключения достаточно прост:
1. Найдите ЦОД(PoP), где можно подключиться к облаку
2. Создайте новое подключение в консоли облака в данной точке присутствия
3. Дождитесь пока запрос на новое подключение будет выполнен
4. Скачайте Letter of Authorization and Connecting Facility Assignment (LOA-CFA, тут будут координаты портов для включения
5. Закажите кроссировку(и) в ЦОДе, данные будут в LOA
6. Настройте виртуальный маршрутизатор и интерфейсы в облаке (и BGP)
7. Настройте BGP на маршрутизаторе в вашей on-prem инфраструктуре
Далее возможны варианты по построению отказоустойчивых схем, например подключение к Direct Connect в разных AZ.
В комменты кину пример LOA из далекого 2020 г.
▎Про IPv6
В документации утверждается, что пириться по IPv6 можно со всеми.
P.S. Сейчас в РФ использовать зарубежные облака стало практически невозможно и независимо от того как будут дальше развиваться события, думаю никто их уже не будет использовать как раньше(или убедите меня в обратном). Поэтому осталось посмотреть, а что там есть из вариантов подключения к «нашим» облакам.
🔥9👍7
Коллеги, есть у кого отзывы «с полей» про железку Juniper qfx5130?
https://www.juniper.net/us/en/products/switches/qfx-series/qfx5130-ethernet-switches.html
https://www.juniper.net/us/en/products/switches/qfx-series/qfx5130-ethernet-switches.html
Juniper Networks
QFX5130 Ethernet Switches | HPE Juniper Networking US
The QFX5130 line of switches offers 10/25/40/100/400GbE interface options, making it an optimal choice for spine-and-leaf deployments in enterprise, service provider, and cloud provider environments.
RTT Москва <-> Алматы, Казахстан
L2VPN от провайдера:
RTT min/avg/max = 48.049 / 48.235 / 48.447 ms
Интернет:
RTT min/avg/max = 53.303 / 53.768 / 54.336 ms
Сойдет! 🙂
L2VPN от провайдера:
RTT min/avg/max = 48.049 / 48.235 / 48.447 ms
Интернет:
RTT min/avg/max = 53.303 / 53.768 / 54.336 ms
Сойдет! 🙂
👍9🔥6⚡2🥰1💩1😭1
Статья отражает мои мысли когда я пробовал разворачивать кластер Kubernetes пару лет назад. Помню, что где-то на RBAC мозг уже начал ломаться и с тех пор уже не стал прежним.
А вот это прям в точку:
https://habr.com/ru/companies/h3llo_cloud/articles/902188/
А вот это прям в точку:
Кубер унижает человеческое достоинство разными способами и на разных этапах. Это часть опыта от пользования продуктом. Так задумано.
https://habr.com/ru/companies/h3llo_cloud/articles/902188/
Хабр
Даже не влезайте в Kubernetes без этого
Главный прикол с k8s: поднять базовый кластер займёт всего 15 минут. А вот чтобы он реально заработал, ответить на все вопросы перед установкой, всё спланировать — на это нужны дни, реально дни...
👍8🔥7💯2
В IT Q2(второй квартал) — это спринт с горящим факелом жопой из бюджетных баталий, техдолга, подготовки к отпускам, конференций и перфоманс-ревью. Если в Q1 — это планирование, а в Q4 — подведение итогов, то Q2 — фаза максимальной реализации, и поэтому он такой сложный.
И тут как раз попалась статья про усталость.
P.S. В следующем посте я расскажу о способе переключения контекста с рабочих задач, который я нашел для себя.
https://habr.com/ru/articles/865660/
И тут как раз попалась статья про усталость.
P.S. В следующем посте я расскажу о способе переключения контекста с рабочих задач, который я нашел для себя.
https://habr.com/ru/articles/865660/
Хабр
5 видов усталости в IT… и не только
Эпиграф: " Руководитель: -Надеюсь тебе удалось отдохнуть в отпуске? Сотрудник: -Знаешь, ощущение, что я еще больше устал..." Думаю, что каждый из читателей встречался с проблемами отдыха. Знакомое...
👍9🔥5
Мир, Труд, Май!
Две недели до Linkmeetup 25 — самое время начинать работу над презентацией!
Шучу, я так не умею. Мне нужно еще 2-3 дня на доработки, но в целом всё почти готово.
Не раз слышал на конференциях фразы вроде: «Доделывал слайды прямо в самолёте». Конечно, ситуации бывают разные, но лично я считаю, что лучше об этом не говорить. Как слушатель, я тогда ловлю себя на мысли, что докладчик, возможно, не уделил подготовке достаточно времени — а значит, и моё внимание для него не так уж важно.
Две недели до Linkmeetup 25 — самое время начинать работу над презентацией!
Шучу, я так не умею. Мне нужно еще 2-3 дня на доработки, но в целом всё почти готово.
Не раз слышал на конференциях фразы вроде: «Доделывал слайды прямо в самолёте». Конечно, ситуации бывают разные, но лично я считаю, что лучше об этом не говорить. Как слушатель, я тогда ловлю себя на мысли, что докладчик, возможно, не уделил подготовке достаточно времени — а значит, и моё внимание для него не так уж важно.
👍22
С праздником!
Все знают о Попове и радио, но не все знают о профессоре М.А. Бонч-Бруевиче.
Я учился в «Бонче», поэтому предлагаю вам ознакомиться с достижениями этого ученого, в честь которого назван наш СПБ ГУТ.
P.S. На логотипе не улыбочки, а радиоволны!
https://www.sut.ru/university/about/istoriya/professor-mihail-aleksandrovich-bonch-bruevich
Все знают о Попове и радио, но не все знают о профессоре М.А. Бонч-Бруевиче.
Я учился в «Бонче», поэтому предлагаю вам ознакомиться с достижениями этого ученого, в честь которого назван наш СПБ ГУТ.
P.S. На логотипе не улыбочки, а радиоволны!
https://www.sut.ru/university/about/istoriya/professor-mihail-aleksandrovich-bonch-bruevich
Федеральное государственное бюджетное образовательное учреждение высшего образования «Санкт-Петербургский государственный университет телекоммуникаций им. проф. М.А. Бонч-Бруевича»
🎉14👍5🔥3
Обещал рассказать о том, что помогает мне переключаться с рабочих задач. У меня есть проблема, описанная здесь, поэтому мне нужен триггер для переключения, желательно жесткий.
В моем случае таким триггером стало купание в холодной, а лучше в ледяной воде! Нет, я не профессиональный морж, который может долго находиться в холодной воде — цель здесь совсем другая. Это про перенастройку мышления, очистку, перезагрузку и преодоление себя — нет, с каждым разом легче не становится, все также непросто лезть в прорубь. Это про закаливание и общение: как семьями, так и только в мужской компании.
Когда я только начал, мы делали прорубь зимой ручной пилой и переодевались в сугробе 🥶 Времена меняются: за три года у нас появились электропила, электробур (бур + шуруповерт), походная баня с печкой, вторая баня с двумя печками и парогенераторами, отдельная палатка для переодевания или чаепития, самовар и множество других вещей: веники, ковшики, коврики, масла, травы, соли и т.д.
Нам стало так хорошо, что возникла идея поделиться этим опытом со всеми 😅
И вероятно, в ближайшем будущем появится коммерческая версия нашего клуба для всех желающих.
Про пользу и вред данного мероприятия можно почитать здесь. Как всегда, главное — делать все с умом!
P.S. О запуске открытой версии клуба сообщу отдельно.
В моем случае таким триггером стало купание в холодной, а лучше в ледяной воде! Нет, я не профессиональный морж, который может долго находиться в холодной воде — цель здесь совсем другая. Это про перенастройку мышления, очистку, перезагрузку и преодоление себя — нет, с каждым разом легче не становится, все также непросто лезть в прорубь. Это про закаливание и общение: как семьями, так и только в мужской компании.
Когда я только начал, мы делали прорубь зимой ручной пилой и переодевались в сугробе 🥶 Времена меняются: за три года у нас появились электропила, электробур (бур + шуруповерт), походная баня с печкой, вторая баня с двумя печками и парогенераторами, отдельная палатка для переодевания или чаепития, самовар и множество других вещей: веники, ковшики, коврики, масла, травы, соли и т.д.
Нам стало так хорошо, что возникла идея поделиться этим опытом со всеми 😅
И вероятно, в ближайшем будущем появится коммерческая версия нашего клуба для всех желающих.
Про пользу и вред данного мероприятия можно почитать здесь. Как всегда, главное — делать все с умом!
P.S. О запуске открытой версии клуба сообщу отдельно.
🔥22
Linkmeetup_25_Ипатов_Okko.pptx
16 MB
Как и обещал, выкладываю презентацию с доклада.
Уложиться в отведенные 30 минут было непросто, и мне пришлось сократить первоначальный вариант примерно на 20%. Некоторые моменты не удалось раскрыть полностью, поэтому, если остались вопросы, пишите в личку.
Большое спасибо организаторам за мероприятие и за доверие быть спикером — всё прошло на высшем уровне!
P.S. Трафика от нас меньше не станет, так что если кто-то понял, что ему нужен кэш-сервер Okko, тоже пишите 🙂
Уложиться в отведенные 30 минут было непросто, и мне пришлось сократить первоначальный вариант примерно на 20%. Некоторые моменты не удалось раскрыть полностью, поэтому, если остались вопросы, пишите в личку.
Большое спасибо организаторам за мероприятие и за доверие быть спикером — всё прошло на высшем уровне!
P.S. Трафика от нас меньше не станет, так что если кто-то понял, что ему нужен кэш-сервер Okko, тоже пишите 🙂
🔥30❤8
Forwarded from linkmeup
С нескрываемым удовольствием сообщаю, что у нас опять произошла отличная рубка за звание лучшего доклада линкмитапа. То есть программа получилась достаточно ровная и без явных перекосов.
В плотнейшей борьбе у финиша были и истории про лабораторные тесты от Сергея Бочарникова, и выбор между Быстро или Безопасно от Игоря Панарина и Андрея Иванова, активно в затылок всем дышала история про Network as Code от Александра Игнатова. Плотной группой шли доклады про DWDM, дичь в мультимедиа сетях, балансировку терабита на межсетевых экранах и так далее.
Но с отрывом буквально в несколько голосов лучшим докладом признаётся история от Дмитрия Ипатова, и как они в Окко готовились транслировать Евро24 и справились с нагрузкой в млн пользователей.
P.S. Презентации все выложим.
P.P.S. Записи тоже все выложим.
P.P.P.S. По срокам - КТТС. Точнее не будет.
В плотнейшей борьбе у финиша были и истории про лабораторные тесты от Сергея Бочарникова, и выбор между Быстро или Безопасно от Игоря Панарина и Андрея Иванова, активно в затылок всем дышала история про Network as Code от Александра Игнатова. Плотной группой шли доклады про DWDM, дичь в мультимедиа сетях, балансировку терабита на межсетевых экранах и так далее.
Но с отрывом буквально в несколько голосов лучшим докладом признаётся история от Дмитрия Ипатова, и как они в Окко готовились транслировать Евро24 и справились с нагрузкой в млн пользователей.
P.S. Презентации все выложим.
P.P.S. Записи тоже все выложим.
P.P.P.S. По срокам - КТТС. Точнее не будет.
🔥19
Как неожиданно и приятно, очень приятно.
«Лучший доклад Linkmeetup 2025» — благодарю зрителей за высокую оценку. В этот раз было представлено множество мощных докладов, что добавляет ценности полученной оценке. Жду записей, чтобы посмотреть те доклады, что пропустил.
На фото — команда сетевиков Okko (правда, только 80%), которая и сделала все то, о чем я говорил.
P.S. Хорошо это или плохо я еще не понял, но наш CDN изначально строили и продолжают развивать сетевики, сейчас даже продуктовая часть находится в наших руках. Фокус у части инженеров в процессе полностью сместился в серверную часть, но изначально это «базовые» сетевики, в какой-то момент перешедшие на темную сторону.
«Лучший доклад Linkmeetup 2025» — благодарю зрителей за высокую оценку. В этот раз было представлено множество мощных докладов, что добавляет ценности полученной оценке. Жду записей, чтобы посмотреть те доклады, что пропустил.
На фото — команда сетевиков Okko (правда, только 80%), которая и сделала все то, о чем я говорил.
P.S. Хорошо это или плохо я еще не понял, но наш CDN изначально строили и продолжают развивать сетевики, сейчас даже продуктовая часть находится в наших руках. Фокус у части инженеров в процессе полностью сместился в серверную часть, но изначально это «базовые» сетевики, в какой-то момент перешедшие на темную сторону.
🔥28