Забегу навалить базы и кринжа про куб, приходите посмотреть :)
Forwarded from Amplicode
Современный Senior Spring девелопер просто обязан разбираться в Kubernetes. Независимо от того, разворачиваете ли вы приложение в облаке или работаете с внутренним кластером компании — без этих знаний уже никуда.
На митапе разберём всё, что нужно знать Java-разработчику в 2025 году:
Спикеры:
🍃 Рустам Курамшин (Spring АйО)
Please open Telegram to view this post
VIEW IN TELEGRAM
Открыт прием заявок на DevOops 2025 😀
Хей!
🔵 Есть что интересного рассказать для Дево-псов, поделиться опытом и потом обсудить все это с такими же инженерными инженерами на конференции DevOops - закидывай заявку 😀
🔵 Если есть, но стесняешься или просто хочешь понять как правильно податься, сформулировать тезисы, позадавать вопросы или просто пообщаться - забегай на онлайн-встречу с Программным комитетом DevOops, режка тут 😀
Хей!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤🔥1🔥1
Forwarded from Ever Secure (Aleksey Fedulaev)
Не могу не поделиться огненным материалом от моего друга
🚀 Kubernetes The Hard Way — по-настоящему, вручную, от и до, без kubeadm и прочих поблажек.
В статье:
— полный пошаговый гайд по сборке Kuberentes.
— удобные alias’ы, функции и обёртки
— десятки скриптов, которые реально работают в бою
— важные моменты, о которых молчат в туториалах
enjoy 😉
Оригинальный пост
Ссылка Github
👀 @ever_secure
🚀 Kubernetes The Hard Way — по-настоящему, вручную, от и до, без kubeadm и прочих поблажек.
В статье:
— полный пошаговый гайд по сборке Kuberentes.
— удобные alias’ы, функции и обёртки
— десятки скриптов, которые реально работают в бою
— важные моменты, о которых молчат в туториалах
enjoy 😉
Оригинальный пост
Ссылка Github
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
Forwarded from Amplicode
Присоединяйтесь к эфиру, чтобы узнать все тонкости развертывания Spring-приложений в Kubernetes!
Начинаем уже через 15 минут!
Please open Telegram to view this post
VIEW IN TELEGRAM
🥰1
Первая рекламная интеграция на канале. Жаль что шутка:(
А если серьезно, то мы в Dodo Engineering ищем Middle+ SRE в Observability Team (Infra Platform)
Мы открываем вакансию middle+ SRE в команду и готовы рассматривать кандидатов. Если рассматриваете для себя новые возможности — пишите мне, познакомимся)
Что за Observability Team?
Не так давно, команда наша Infra Platform разделилась из монолита на микро-сервисы-команды, одной из которых и является Observability Team.
Сейчас в команде я и прекрасный Кирилл, мы активно ищем еще 2х таких же классных ребят себе в команду.
Чем занимается команда?
* Делаем наши инструменты Observability лучше
* Разрабатываем, развиваем и внедряем платформу Observability, что бы помогать командам разработки и эксплуатации получать все необходимые данные о работе наших сервисов
* Автоматизируем процессы развертывания и управления инструментами Observability (и не только)
Кого ищем и что надо делать?
Ищем middle+ SRE (или разработчика который хочет в SRE, мы с радостью всему научим)
Подробное описание вакансии - тут
У нас грандиозные планы по развитию наших инструментов, внедрение платформы и улучшение DevExp наших коллег
А если серьезно, то мы в Dodo Engineering ищем Middle+ SRE в Observability Team (Infra Platform)
Мы открываем вакансию middle+ SRE в команду и готовы рассматривать кандидатов. Если рассматриваете для себя новые возможности — пишите мне, познакомимся)
Что за Observability Team?
Не так давно, команда наша Infra Platform разделилась из монолита на микро-
Сейчас в команде я и прекрасный Кирилл, мы активно ищем еще 2х таких же классных ребят себе в команду.
Чем занимается команда?
* Делаем наши инструменты Observability лучше
* Разрабатываем, развиваем и внедряем платформу Observability, что бы помогать командам разработки и эксплуатации получать все необходимые данные о работе наших сервисов
* Автоматизируем процессы развертывания и управления инструментами Observability (и не только)
Кого ищем и что надо делать?
Ищем middle+ SRE (или разработчика который хочет в SRE, мы с радостью всему научим)
Подробное описание вакансии - тут
У нас грандиозные планы по развитию наших инструментов, внедрение платформы и улучшение DevExp наших коллег
🔥5
Обновление технологического радара Dodo Engineering на 2025 год!
Честно говоря, подглядел этот пост у коллеги и решил сделать свой :D
Привет, Берёзка, спасибо за вдохновение!
Мы в Dodo Engineering продолжаем двигаться вперёд и адаптировать наши технологии и инструменты, чтобы оставаться на передовой инноваций. И вот основные (или нет) изменения, которые произошли с 2023 года:
Языки и фреймворки:
Python, который в 2023 году использовался для легаси проектов, больше не фигурирует в нашем списке.
Jsonnet и Bash продолжают оставаться в статусе "Adopt", подтверждая свою надёжность и эффективность (нет).
Платформы:
MySQL, Kubernetes и GitHub продолжают быть нашими лучшими друзьями в статусе "Adopt".
GitLab остаётся в статусе "Hold" (но скоро мы с ним попрощаемся).
Инструменты:
Ansible остаётся в статусе "Hold".
Jaeger продолжает оставаться в статусе "Adopt".
Grafana и Prometheus переведены в статус "Hold" как "Legacy monolith visualization" и "Legacy monolith monitoring" соответственно (мигрируем на операторов).
Техники:
Подход "You build it, you run it, you budget it" продвинулся до стадии "Assess".
Практики oncall для критических сервисов остаются в стадии "Assess".
Wheel of Misfortune — очень надеюсь, что доведу его до ума и будет конфетка, но пока в стадии "Trial".
Новые технологии в 2025 году:
DodoEngineering CLI, IDP/PaaS и K8S Operators в статусе "Assess".
Grafana Stack (alloy, mimir, tempo, loki, pyroscope), OTel Collector и Grafana Operator в статусе "Assess".
Grafana Faro Web SDK в статусе "Trial".
Prometheus Operator в статусе "Assess".
Вывод:
Неожиданно, но мы развиваемся, пробуем новые технологии и инструменты. Надеюсь, они помогут нам в достижении наших целей :)
Радарчик посмотреть можно тут
UPD: чуть ошибся ссылкой, уже поправил :)
Честно говоря, подглядел этот пост у коллеги и решил сделать свой :D
Привет, Берёзка, спасибо за вдохновение!
Мы в Dodo Engineering продолжаем двигаться вперёд и адаптировать наши технологии и инструменты, чтобы оставаться на передовой инноваций. И вот основные (или нет) изменения, которые произошли с 2023 года:
Языки и фреймворки:
Python, который в 2023 году использовался для легаси проектов, больше не фигурирует в нашем списке.
Jsonnet и Bash продолжают оставаться в статусе "Adopt", подтверждая свою надёжность и эффективность (нет).
Платформы:
MySQL, Kubernetes и GitHub продолжают быть нашими лучшими друзьями в статусе "Adopt".
GitLab остаётся в статусе "Hold" (но скоро мы с ним попрощаемся).
Инструменты:
Ansible остаётся в статусе "Hold".
Jaeger продолжает оставаться в статусе "Adopt".
Grafana и Prometheus переведены в статус "Hold" как "Legacy monolith visualization" и "Legacy monolith monitoring" соответственно (мигрируем на операторов).
Техники:
Подход "You build it, you run it, you budget it" продвинулся до стадии "Assess".
Практики oncall для критических сервисов остаются в стадии "Assess".
Wheel of Misfortune — очень надеюсь, что доведу его до ума и будет конфетка, но пока в стадии "Trial".
Новые технологии в 2025 году:
DodoEngineering CLI, IDP/PaaS и K8S Operators в статусе "Assess".
Grafana Stack (alloy, mimir, tempo, loki, pyroscope), OTel Collector и Grafana Operator в статусе "Assess".
Grafana Faro Web SDK в статусе "Trial".
Prometheus Operator в статусе "Assess".
Вывод:
Неожиданно, но мы развиваемся, пробуем новые технологии и инструменты. Надеюсь, они помогут нам в достижении наших целей :)
Радарчик посмотреть можно тут
UPD: чуть ошибся ссылкой, уже поправил :)
🔥1
Всем привет
Важная штучка тут прилетела!
Google собирается провести бесплатный воркшоп по SLO 22 мая!
Ссылка для регистраций:)
Налетай, делись, учись :)
Важная штучка тут прилетела!
Google собирается провести бесплатный воркшоп по SLO 22 мая!
Ссылка для регистраций:)
Налетай, делись, учись :)
Withgoogle
SRE Fundamentals: Developing and calculating SLOs
This workshop will help your SRE team understand the importance of developing meaningful SLOs on Google Cloud and Nobl9, derived from proper Critical User Journeys (CUJs) and properly implemented Service Level Indicators (SLIs).
🔥1👨💻1
Перевел и актуализировал для вас классную статейку, о том как почистить свои метрики от мусора.
Перевод тут
Оригинал тут
Перевод тут
Оригинал тут
Telegraph
Как найти неиспользуемые метрики в Prometheus с помощью mimirtool?
Недавно мне нужно было стабилизировать, отслеживать проблемы с кардинальностью и значительно снизить использование ресурсов в установке Prometheus. Чтобы сделать это, я сначала должен был проанализировать систему. В этой статье я объясню, как я использовал…
👍3
Неожиданно, но я (и канал) живой :)
Поэтому вот вам еще новостя с полей конференций и ПК :)
Я еще состою и в ПК DevOops Conf, где ребята тоже решили поделиться промокодом для скидки на покупку билета для вас. Целых 25%!
Но, тк закон о рекламе запрещает его выкладывать в публичных каналах - за ним можно прийти в личку и я с радостью поделюсь :)
Поэтому вот вам еще новостя с полей конференций и ПК :)
Я еще состою и в ПК DevOops Conf, где ребята тоже решили поделиться промокодом для скидки на покупку билета для вас. Целых 25%!
Но, тк закон о рекламе запрещает его выкладывать в публичных каналах - за ним можно прийти в личку и я с радостью поделюсь :)
2👍3
Наконец-то завязал с мучениями в Obsidian!
Устал от постоянной возни с его markdown'ом, плагинами и прочими заморочками. Решил вернуться к облачным решениям.
Что пробовал:
Notion — с VPN работает нестабильно, медленно и крайне долго синкается.
Наши аналоги и китайские клоны — быстро надоели кучи багов, глюков и зависаний, плюс не у всех есть приложение на мобилку.
Что выбрал: AFFiNE
- Open source (авторы из Сингапура)
- Удалось легко перенести все заметки
- Есть мобильное приложение
- Главный плюс — published notes работают отлично и мигранулись в один клик
Мои публичные заметки
Итог:
Оказалось гораздо удобнее, чем мучиться с Obsidian и его плагинами или другими аналогами. Рекомендую попробовать, жаль что нет рефералок :D
Устал от постоянной возни с его markdown'ом, плагинами и прочими заморочками. Решил вернуться к облачным решениям.
Что пробовал:
Notion — с VPN работает нестабильно, медленно и крайне долго синкается.
Наши аналоги и китайские клоны — быстро надоели кучи багов, глюков и зависаний, плюс не у всех есть приложение на мобилку.
Что выбрал: AFFiNE
- Open source (авторы из Сингапура)
- Удалось легко перенести все заметки
- Есть мобильное приложение
- Главный плюс — published notes работают отлично и мигранулись в один клик
Мои публичные заметки
Итог:
Оказалось гораздо удобнее, чем мучиться с Obsidian и его плагинами или другими аналогами. Рекомендую попробовать, жаль что нет рефералок :D
GitHub
GitHub - toeverything/AFFiNE: There can be more than Notion and Miro. AFFiNE(pronounced [ə‘fain]) is a next-gen knowledge base…
There can be more than Notion and Miro. AFFiNE(pronounced [ə‘fain]) is a next-gen knowledge base that brings planning, sorting and creating all together. Privacy first, open-source, customizable an...
✍6👀2
Есть у SRE особая головная боль - метрики и их хранение.
У нас в Додо два Prometheus, каждый честно слал свои метрики в Mimir, ни о чём не подозревая. А на деле? Хранилище почти захлёбывалось: память росла, запросы замедлялись, отрисовать нужный график - проще в вообще все в prometheus посмотреть, чем ждать когда mimir отрисует. Иногда казалось, что мы работаем не инженерами, а оуним железо, на котором магнит биткоин mimir.
Были даже забавные моменты: сидишь, рисуешь красивую дашборду по метрикам, а она получается в два раза разных графика, потому что данные уходили по разному в каждый инстанс prometheus. Графики прыгают как на батуте, потому что каждый Prometheus отправил свой дубль world save. Пытаешься понять, почему сервис перегружен - а это просто один и тот же сигнал приходит с двух сторон. Иногда такие ситуации реально мешали находить баги и реагировать на инциденты.
И вот мы наконец решились, точнее руки дошли - мы подключили Consul к Mimir, настроили дедупликацию.
Сначала я просто не поверил графикам:
- потребление памяти у Mimir сразу упало в полтора раза
- нагрузка на Prometheus ушла примерно на 30% (и это реально чувствуется!).
Теперь жизнь стала гораздо приятнее:
- сами графики стали честнее и понятнее
- перестали терять время на борьбу с дублями
- вся инфраструктура стала быстрее реагировать на запросы и тревоги(или нет)
- наконец можно смотреть на мониторинг и ловить не фантомные сигналы, а реальные события.
Мораль — если чувствуете, что drowning in duplicate metrics, настройте дедупликацию, не откладывайте. Она не только экономит ресурсы, но делает работу SRE чуть менее страдательной и гораздо более эффективной.
У нас в Додо два Prometheus, каждый честно слал свои метрики в Mimir, ни о чём не подозревая. А на деле? Хранилище почти захлёбывалось: память росла, запросы замедлялись, отрисовать нужный график - проще в вообще все в prometheus посмотреть, чем ждать когда mimir отрисует. Иногда казалось, что мы работаем не инженерами, а оуним железо, на котором магнит биткоин mimir.
Были даже забавные моменты: сидишь, рисуешь красивую дашборду по метрикам, а она получается в два раза разных графика, потому что данные уходили по разному в каждый инстанс prometheus. Графики прыгают как на батуте, потому что каждый Prometheus отправил свой дубль world save. Пытаешься понять, почему сервис перегружен - а это просто один и тот же сигнал приходит с двух сторон. Иногда такие ситуации реально мешали находить баги и реагировать на инциденты.
И вот мы наконец решились, точнее руки дошли - мы подключили Consul к Mimir, настроили дедупликацию.
Сначала я просто не поверил графикам:
- потребление памяти у Mimir сразу упало в полтора раза
- нагрузка на Prometheus ушла примерно на 30% (и это реально чувствуется!).
Теперь жизнь стала гораздо приятнее:
- сами графики стали честнее и понятнее
- перестали терять время на борьбу с дублями
- вся инфраструктура стала быстрее реагировать на запросы и тревоги(или нет)
- наконец можно смотреть на мониторинг и ловить не фантомные сигналы, а реальные события.
Мораль — если чувствуете, что drowning in duplicate metrics, настройте дедупликацию, не откладывайте. Она не только экономит ресурсы, но делает работу SRE чуть менее страдательной и гораздо более эффективной.
👍4👏1
И так, снова про метрики. Что вы знаете о Trickster?
Но начну с проблем, которые мы решали.
У нас в observability команде Prometheus начал задыхаться под нагрузкой:
- Grafana-дашборды открывались по 30-40 секунд
- Одни и те же запросы выполнялись десятки раз
- PromQL-запросы с большими временными диапазонами убивали память
- Кардинальность метрик росла, а железо - нет
Встал вопрос, как это решать, и неожиданно нашёлся Trickster.
Trickster - это умный HTTP reverse proxy, который сидит между Grafana и Prometheus. Он кэширует результаты запросов и умеет делать несколько крутых вещей:
Delta Proxy Cache - запрашивает только новые данные, а старые берёт из кэша. Например, если у вас запрос за последние 6 часов, а в кэше уже есть данные за 5 часов 50 минут - Trickster догрузит только последние 10 минут.
Time Series Merging - склеивает закэшированные данные с новыми так, что Prometheus даже не догадается.
Query Rewriting - оптимизирует тяжёлые запросы на лету.
Результаты после внедрения:
- Нагрузка на Prometheus упала на 60-70%
- Дашборды открываются в 3-5 раз быстрее (не всегда :D)
- Hit rate кэша стабильно держится на уровне 75-80%
- Можно спокойно масштабировать дашборды без страха положить Prometheus (нет)
Альтернатив особо нет. Есть Promxy, Cortex, Thanos - но они решают другие задачи (федерация, долгосрочное хранение). Именно для кэширования запросов на уровне HTTP с умным delta-подходом Trickster практически уникален.
Что важно знать:
- Работает с Prometheus, InfluxDB, ClickHouse, IronDB
- Поддерживает Redis и Filesystem как бэкенд для кэша
- Можно настроить TTL отдельно для каждого типа запросов
- Метрики самого Trickster экспортируются в Prometheus (очень meta)
Если у вас Prometheus начинает тормозить, а дашбордов становится всё больше - внедрение Trickster займёт пару часов, но сэкономит месяцы оптимизаций.
PS: ах, да, особо не смотрите на последний релиз Trickster-a, форкните репо себе и соберите image. Ребята что-то забросили сборки обновлять :(
Но начну с проблем, которые мы решали.
У нас в observability команде Prometheus начал задыхаться под нагрузкой:
- Grafana-дашборды открывались по 30-40 секунд
- Одни и те же запросы выполнялись десятки раз
- PromQL-запросы с большими временными диапазонами убивали память
- Кардинальность метрик росла, а железо - нет
Встал вопрос, как это решать, и неожиданно нашёлся Trickster.
Trickster - это умный HTTP reverse proxy, который сидит между Grafana и Prometheus. Он кэширует результаты запросов и умеет делать несколько крутых вещей:
Delta Proxy Cache - запрашивает только новые данные, а старые берёт из кэша. Например, если у вас запрос за последние 6 часов, а в кэше уже есть данные за 5 часов 50 минут - Trickster догрузит только последние 10 минут.
Time Series Merging - склеивает закэшированные данные с новыми так, что Prometheus даже не догадается.
Query Rewriting - оптимизирует тяжёлые запросы на лету.
Результаты после внедрения:
- Нагрузка на Prometheus упала на 60-70%
- Дашборды открываются в 3-5 раз быстрее (не всегда :D)
- Hit rate кэша стабильно держится на уровне 75-80%
- Можно спокойно масштабировать дашборды без страха положить Prometheus (нет)
Альтернатив особо нет. Есть Promxy, Cortex, Thanos - но они решают другие задачи (федерация, долгосрочное хранение). Именно для кэширования запросов на уровне HTTP с умным delta-подходом Trickster практически уникален.
Что важно знать:
- Работает с Prometheus, InfluxDB, ClickHouse, IronDB
- Поддерживает Redis и Filesystem как бэкенд для кэша
- Можно настроить TTL отдельно для каждого типа запросов
- Метрики самого Trickster экспортируются в Prometheus (очень meta)
Если у вас Prometheus начинает тормозить, а дашбордов становится всё больше - внедрение Trickster займёт пару часов, но сэкономит месяцы оптимизаций.
PS: ах, да, особо не смотрите на последний релиз Trickster-a, форкните репо себе и соберите image. Ребята что-то забросили сборки обновлять :(
GitHub
GitHub - trickstercache/trickster: Open Source HTTP Reverse Proxy Cache and Time Series Dashboard Accelerator
Open Source HTTP Reverse Proxy Cache and Time Series Dashboard Accelerator - trickstercache/trickster
1🔥3
Forwarded from Берёзка
Тестфлайт Додо Пиццы
Мы открываем бета-сборочки в публичный тестфлайт. Сборки довольно стабильные: они прошли все внутренние автоматические проверки и часть ручных. Критический путь в них 100% работает, но могут быть супер-редкие краши. Их мы и хотим отловить с вашей помощью.
Бета-сборочку можно установить по ссылке: https://testflight.apple.com/join/DJjtWbmY
Новые сборки выкладываем каждые две недели, так что включите автообновление и выключите оповещения.
Мы открываем бета-сборочки в публичный тестфлайт. Сборки довольно стабильные: они прошли все внутренние автоматические проверки и часть ручных. Критический путь в них 100% работает, но могут быть супер-редкие краши. Их мы и хотим отловить с вашей помощью.
Бета-сборочку можно установить по ссылке: https://testflight.apple.com/join/DJjtWbmY
Новые сборки выкладываем каждые две недели, так что включите автообновление и выключите оповещения.
Apple
Join the Dodo Pizza Delivery beta
Available on iOS
Как работают инженеры по надёжности в 2025 году?
SRE-инженеры — те, кто держат production в живых, настраивают мониторинг, ловят и устраняют инциденты и отвечают за uptime.
Ребята из DevCrowd, которые специализируются на ёмких и открытых отчетах о разных профессиях в IT, запускают свое первое исследование про SRE и DevOps-практики — чтобы понять, как всё устроено изнутри: кто за что отвечает, какие инструменты реально работают и где проходит граница между SRE и DevOps. Они попросили меня помочь и я не смог им отказать. :)
💡 Зачем участвовать?
– посмотрите, как ваш опыт соотносится с другими инженерами: процессы, зрелость команд, инструменты;
– узнайте, какие reliability-практики внедряют коллеги;
– поможете сделать роль SRE понятнее и заметнее на рынке.
🛠 В опросе задачи, инструменты, мониторинг, алертинг, CI/CD, культура постмортемов и взаимодействие ролей.
🕐 Заполнение займёт около 10 минут.
📊 Результаты — в ноябре на devcrowd.ru
📝 Пройти опрос → https://survey.alchemer.eu/s3/90909470/SRE-2025
⚠️ Важно — результаты будут опубликованы в открытом доступе, чтобы все сообщество могло оценить/обсудить и сделать собственные выводы.
SRE-инженеры — те, кто держат production в живых, настраивают мониторинг, ловят и устраняют инциденты и отвечают за uptime.
Ребята из DevCrowd, которые специализируются на ёмких и открытых отчетах о разных профессиях в IT, запускают свое первое исследование про SRE и DevOps-практики — чтобы понять, как всё устроено изнутри: кто за что отвечает, какие инструменты реально работают и где проходит граница между SRE и DevOps. Они попросили меня помочь и я не смог им отказать. :)
💡 Зачем участвовать?
– посмотрите, как ваш опыт соотносится с другими инженерами: процессы, зрелость команд, инструменты;
– узнайте, какие reliability-практики внедряют коллеги;
– поможете сделать роль SRE понятнее и заметнее на рынке.
🛠 В опросе задачи, инструменты, мониторинг, алертинг, CI/CD, культура постмортемов и взаимодействие ролей.
🕐 Заполнение займёт около 10 минут.
📊 Результаты — в ноябре на devcrowd.ru
📝 Пройти опрос → https://survey.alchemer.eu/s3/90909470/SRE-2025
Please open Telegram to view this post
VIEW IN TELEGRAM