На пути к 9999: практики обработки и мониторинга инцидентов
Каждый продукт Яндекс 360 (Диск, Почта, Телемост и другие) состоит из десятков, а то и сотен микросервисов, и каждый из них должен стабильно работать 24/7/365 и соответствовать самым высоким требованиям надёжности.
Игорь Обручев, руководитель группы SRE в Яндекс 360, рассказал, какими принципами они руководствуются, когда делают сервисы, как без паники чинят инциденты. А также кратко об учениях и для чего они нужны.
В докладе — про всё это, а также про команду 9999, тиры надёжности и про то, за что отвечает синий цвет протокола.
Больше материалов о технологиях в Яндекс 360
@yandex360team
Каждый продукт Яндекс 360 (Диск, Почта, Телемост и другие) состоит из десятков, а то и сотен микросервисов, и каждый из них должен стабильно работать 24/7/365 и соответствовать самым высоким требованиям надёжности.
Игорь Обручев, руководитель группы SRE в Яндекс 360, рассказал, какими принципами они руководствуются, когда делают сервисы, как без паники чинят инциденты. А также кратко об учениях и для чего они нужны.
В докладе — про всё это, а также про команду 9999, тиры надёжности и про то, за что отвечает синий цвет протокола.
Больше материалов о технологиях в Яндекс 360
@yandex360team
🧠 DevOps-задача: "Контейнер Шрёдингера"
Условие:
Ты получаешь баг-репорт:
> "Приложение внутри Docker-контейнера после деплоя не работает, но
Что известно:
- Docker-контейнер на основе
- Приложение запускается через
- Порт 8080 проброшен (`-p 8080:8080`)
-
-
-
Задача:
Найди вероятную причину, предложи способ воспроизведения, диагностики и исправления. Подумай как DevOps, а не просто как админ.
📌 Разбор:
🕵️ Подвох №1: **приложение слушает127.0.0.1:8080 **, а не 0.0.0.0
• внутри `curl localhost:8080` работает
• а хост не может достучаться, потому что `127.0.0.1` — это loopback внутри контейнера, а не на host
Решение:
- Проверить снаружи: `docker inspect <container_id> | grep IPAddress`
- Проверить bind-порт внутри:
```bash
netstat -tulpn | grep 8080
# или ss -tulpn | grep 8080
```
- Если видим ` 127.0.0.1:8080 ` — всё ясно: нужно слушать на ` 0.0.0.0:8080 `
🛠 Исправление:
1. Проверь запуск приложения. Может, внутри у тебя:
```bash
python3 app.py
```
и он слушает только на localhost? Добавь:
```bash
python3app.py --host= 0.0.0.0
```
2. В Go, Node.js, Python и т.д. — по умолчанию bind'ят на127.0.0.1
Проверь в настройках приложения или командной строке
🎯 Что проверяет задача:
• Умение мыслить в терминах изоляции контейнеров
• Понимание сетевых пространств имён (network namespaces)
• Знание, как работает NAT между контейнером и хостом
• Умение диагностировать "невидимый" bind
• Привычку **проверять всё снаружи**, а не только внутри контейнера
Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.
Условие:
Ты получаешь баг-репорт:
> "Приложение внутри Docker-контейнера после деплоя не работает, но
docker exec
показывает, что оно запущено, порт слушает, ошибок нет. Однако при curl изнутри — всё работает, а снаружи — нет ответа."Что известно:
- Docker-контейнер на основе
alpine:3.18
- Приложение запускается через
CMD ["/bin/service-start"]
- Порт 8080 проброшен (`-p 8080:8080`)
-
curl localhost:8080
внутри контейнера возвращает 200 OK-
curl localhost:8080
на хосте — зависает-
netstat -tulpn
показывает, что порт 8080 прослушивается внутриЗадача:
Найди вероятную причину, предложи способ воспроизведения, диагностики и исправления. Подумай как DevOps, а не просто как админ.
📌 Разбор:
🕵️ Подвох №1: **приложение слушает
• внутри `curl localhost:8080` работает
• а хост не может достучаться, потому что `127.0.0.1` — это loopback внутри контейнера, а не на host
Решение:
- Проверить снаружи: `docker inspect <container_id> | grep IPAddress`
- Проверить bind-порт внутри:
```bash
netstat -tulpn | grep 8080
# или ss -tulpn | grep 8080
```
- Если видим `
🛠 Исправление:
1. Проверь запуск приложения. Может, внутри у тебя:
```bash
python3
```
и он слушает только на localhost? Добавь:
```bash
python3
```
2. В Go, Node.js, Python и т.д. — по умолчанию bind'ят на
Проверь в настройках приложения или командной строке
🎯 Что проверяет задача:
• Умение мыслить в терминах изоляции контейнеров
• Понимание сетевых пространств имён (network namespaces)
• Знание, как работает NAT между контейнером и хостом
• Умение диагностировать "невидимый" bind
• Привычку **проверять всё снаружи**, а не только внутри контейнера
Подобные ошибки легко пропустить, особенно если всё проверяешь изнутри контейнера.
Знание контейнеров: путь к большим деньгам в ИТ или временный хайп? 💰
19 мая (понедельник) в 18:00 присоединяйтесь к настоящему батлу мнений.
В прямом эфире разработчики контейнерной платформы «Штурвал» вместе с AM Live соберут тех, кто знает индустрию изнутри.
Топовые спикеры обсудят, действительно ли знание Docker и Kubernetes в приоритете нужных навыков или это проходящая мода, которая никак не влияет на успешный карьерный трек?
Основные вопросы дискуссии:
▪️Насколько знания контейнеризации повышают конкурентоспособность и стоимость специалиста на рынке?
▪️Кто сейчас нужен больше — IT-специалист или IT generalist?
▪️Опыт работы с «ванильным» K8s VS с коммерческой платформой: есть ли разница?
▪️Что делать, если Kubernetes вообще не нравится?
▪️Площадки для обучения контейнеризации: норм или стрем?
🔜 Регистрация
19 мая (понедельник) в 18:00 присоединяйтесь к настоящему батлу мнений.
В прямом эфире разработчики контейнерной платформы «Штурвал» вместе с AM Live соберут тех, кто знает индустрию изнутри.
Топовые спикеры обсудят, действительно ли знание Docker и Kubernetes в приоритете нужных навыков или это проходящая мода, которая никак не влияет на успешный карьерный трек?
Основные вопросы дискуссии:
▪️Насколько знания контейнеризации повышают конкурентоспособность и стоимость специалиста на рынке?
▪️Кто сейчас нужен больше — IT-специалист или IT generalist?
▪️Опыт работы с «ванильным» K8s VS с коммерческой платформой: есть ли разница?
▪️Что делать, если Kubernetes вообще не нравится?
▪️Площадки для обучения контейнеризации: норм или стрем?
🔜 Регистрация
🦙 RamaLama — контейнерный подход к работе с AI-моделями. Этот инструмент переносит логику Docker/Podman в мир искусственного интеллекта, позволяя запускать LLM-модели как контейнеры с автоматической подгрузкой оптимизированных образов под ваше железо.
Вместо ручной настройки зависимостей RamaLama сама определяет доступные GPU/CPU и разворачивает изолированную среду для инференса. Модели из HuggingFace, Ollama или OCI-регистров можно тестировать через REST API или чат-интерфейс, не опасаясь утечек данных — все запуски происходят без сети с удалением временных файлов.
🤖 GitHub
@devopsitsec
Вместо ручной настройки зависимостей RamaLama сама определяет доступные GPU/CPU и разворачивает изолированную среду для инференса. Модели из HuggingFace, Ollama или OCI-регистров можно тестировать через REST API или чат-интерфейс, не опасаясь утечек данных — все запуски происходят без сети с удалением временных файлов.
🤖 GitHub
@devopsitsec
🌐 Задача-ловушка: Пропавший трафик после настройки iptables
Условие:
На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:
После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок.
На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:
❗ Проблема: Снаружи контейнер не доступен. В браузере или curl получаете
Дополнительно, если выполнить:
— сервер отвечает нормально. Но с других машин — нет.
❓ Вопрос:
Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему?
🔍 Подсказка:
Docker использует nat таблицы и
✅ Разбор:
💥 Ловушка:
Ваш iptables-правила:
запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через
Когда Docker пробрасывает порт с хоста (например, 8080), схема такая:
- Входящий пакет попадает в цепочку
- Потом через
И тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:
Поэтому трафик до контейнера блокируется именно на этапе FORWARD.
🔧 Как проверить:
Запустить:
Вы увидите, что счётчик пакетов в
🛠 Как починить:
Добавить правило разрешения проброса пакетов для Docker:
Или (более строго):
✅ Вывод:
• В Linux iptables цепочки работают по строгой логике:
- INPUT — для пакетов к хосту
- FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы)
• Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через
💡 Бонус-вопрос:
Что изменится, если вы запустите контейнер с флагом
Условие:
На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок.
На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:
docker run -d -p 8080:80 nginx
❗ Проблема: Снаружи контейнер не доступен. В браузере или curl получаете
Connection refused
. Но в ss -tlnp
порт 8080 виден и слушает.Дополнительно, если выполнить:
curl http://localhost:8080
— сервер отвечает нормально. Но с других машин — нет.
❓ Вопрос:
Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему?
🔍 Подсказка:
Docker использует nat таблицы и
PREROUTING`/`FORWARD
цепочки для проброса портов.✅ Разбор:
💥 Ловушка:
Ваш iptables-правила:
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через
INPUT
, но это не так!Когда Docker пробрасывает порт с хоста (например, 8080), схема такая:
- Входящий пакет попадает в цепочку
PREROUTING (nat)
- Потом через
FORWARD
, если пакет не адресован хосту напрямую, а перенаправлен внутрь контейнераИ тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:
iptables -P FORWARD DROP
Поэтому трафик до контейнера блокируется именно на этапе FORWARD.
🔧 Как проверить:
Запустить:
iptables -L -v -n
Вы увидите, что счётчик пакетов в
FORWARD
показывает дропы.🛠 Как починить:
Добавить правило разрешения проброса пакетов для Docker:
iptables -A FORWARD -o docker0 -j ACCEPT
Или (более строго):
iptables -A FORWARD -i eth0 -o docker0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT
✅ Вывод:
• В Linux iptables цепочки работают по строгой логике:
- INPUT — для пакетов к хосту
- FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы)
• Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через
FORWARD
, а не напрямую через INPUT
.💡 Бонус-вопрос:
Что изменится, если вы запустите контейнер с флагом
--network=host
? Какие цепочки будут задействованы тогда?Можно ли за 4 года стать хорошим фулстек-разработчиком с дипломом престижного вуза,
готовым портфолио и сильной теоретической базой? В совместном онлайн-бакалавриате
НИУ ВШЭ и Нетологии «Программные системы и автоматизация процессов разработки»
готовят как раз таких специалистов.
На первых курсах вы изучите базовые математические и гуманитарные предметы, основы
программирования и профильные дисциплины по фулстек-разработке. А с третьего курса
выберете углублённый трек: руководитель командой разработки или DevOps-инженер. По
итогу обучения освоите 4 языка программирования: Java, Python, JavaScript, Go.
Вас ждёт сильное студенческое комьюнити, постоянная практика, хакатоны и стажировки.
А ещё — все бонусы очной формы обучения: отсрочка от армии, льготы на проезд,
доступ к библиотеке, привилегии при посещении театров, льготный кредит на
образование.
Получите диплом, который поможет строить карьеру в сильных IT-командах.
Подробнее
Реклама. ООО "Нетология". ИНН 7726464125 Erid 2VSb5xYYjqJ
готовым портфолио и сильной теоретической базой? В совместном онлайн-бакалавриате
НИУ ВШЭ и Нетологии «Программные системы и автоматизация процессов разработки»
готовят как раз таких специалистов.
На первых курсах вы изучите базовые математические и гуманитарные предметы, основы
программирования и профильные дисциплины по фулстек-разработке. А с третьего курса
выберете углублённый трек: руководитель командой разработки или DevOps-инженер. По
итогу обучения освоите 4 языка программирования: Java, Python, JavaScript, Go.
Вас ждёт сильное студенческое комьюнити, постоянная практика, хакатоны и стажировки.
А ещё — все бонусы очной формы обучения: отсрочка от армии, льготы на проезд,
доступ к библиотеке, привилегии при посещении театров, льготный кредит на
образование.
Получите диплом, который поможет строить карьеру в сильных IT-командах.
Подробнее
Реклама. ООО "Нетология". ИНН 7726464125 Erid 2VSb5xYYjqJ
🛠️ Отправка уведомлений Slack из shell-скриптов
Автоматизация задач — это здорово, но ещё лучше — знать, когда они завершились или если что-то пошло не так.
Slack — популярный мессенджер, поддерживающий ботов, которых можно настроить для автоматических оповещений о важных событиях.
Сервер упал? Получите уведомление.
Скрипт завершил выполнение? Получите уведомление.
Добавив уведомления Slack в свои shell-скрипты, вы можете:
- 📣 легко делиться результатами работы скриптов с командой,
- 🛡️ быстро реагировать на проблемы,
- 🔍 быть в курсе событий без просмотра логов.
> Предполагается, что вы уже используете Slack и знакомы с понятием Slack Bot. Также необходимо базовое знание Bash.
🔗 Webhook + curl: секретная связка
Slack позволяет использовать входящие Webhook-и для получения сообщений.
А
Принцип:
- Slack даёт вам URL вида
- Вы используете
⚙️ Как включить входящие Webhook в Slack
1. Зарегистрируйтесь на [api.slack.com/apps](https://api.slack.com/apps)
2. Создайте новое приложение
3. В разделе Incoming Webhooks — активируйте их
4. Добавьте Webhook в рабочее пространство (выберите канал)
5. Сохраните Webhook URL — он понадобится далее
💬 Bash-скрипт для отправки уведомлений
Добавьте Webhook в
✅ Рекомендации
Не хардкодьте токены — используйте переменные окружения
Slack ограничивает частоту Webhook-запросов
Используйте уведомления только при необходимости (ошибки, алерты и т.п.)
Теперь вы можете:
- Добавить Slack-уведомления в свои cron-задачи
- Отслеживать состояние системы
- Получать оповещения об ошибках в скриптах.
Подробнее
Автоматизация задач — это здорово, но ещё лучше — знать, когда они завершились или если что-то пошло не так.
Slack — популярный мессенджер, поддерживающий ботов, которых можно настроить для автоматических оповещений о важных событиях.
Сервер упал? Получите уведомление.
Скрипт завершил выполнение? Получите уведомление.
Добавив уведомления Slack в свои shell-скрипты, вы можете:
- 📣 легко делиться результатами работы скриптов с командой,
- 🛡️ быстро реагировать на проблемы,
- 🔍 быть в курсе событий без просмотра логов.
> Предполагается, что вы уже используете Slack и знакомы с понятием Slack Bot. Также необходимо базовое знание Bash.
🔗 Webhook + curl: секретная связка
Slack позволяет использовать входящие Webhook-и для получения сообщений.
А
curl
позволяет отправлять эти сообщения через HTTP POST.Принцип:
- Slack даёт вам URL вида
https://hooks.slack.com/services/...
- Вы используете
curl
для отправки JSON с текстом сообщения.⚙️ Как включить входящие Webhook в Slack
1. Зарегистрируйтесь на [api.slack.com/apps](https://api.slack.com/apps)
2. Создайте новое приложение
3. В разделе Incoming Webhooks — активируйте их
4. Добавьте Webhook в рабочее пространство (выберите канал)
5. Сохраните Webhook URL — он понадобится далее
💬 Bash-скрипт для отправки уведомлений
Добавьте Webhook в
.bashrc
:
export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/your/webhook/url"
Пример скрипта мониторинга:
#!/bin/bash
source ~/notify_slack.sh
disk_usage=$(df -h / | awk 'NR==2 {print $5}')
cpu_load=$(uptime | awk -F'load average:' '{ print $2 }' | cut -d',' -f1 | xargs)
hostname=$(hostname)
message="*Отчёт о системе - $hostname*\n* Диск (/): $disk_usage\n* CPU (1 мин): $cpu_load"
notify_slack "$message"
✅ Рекомендации
Не хардкодьте токены — используйте переменные окружения
Slack ограничивает частоту Webhook-запросов
Используйте уведомления только при необходимости (ошибки, алерты и т.п.)
Теперь вы можете:
- Добавить Slack-уведомления в свои cron-задачи
- Отслеживать состояние системы
- Получать оповещения об ошибках в скриптах.
Подробнее
Forwarded from Machinelearning
🚀 VS Code трансформируется в опенсорнсый ИИ-редактор!
Команда Visual Studio Code объявила о планах трансформировать VS Code в редактор с открытым исходным кодом для работы с ИИ.
Конкуренция - двигатели прогресса!Где-то напряглась команда Cursor 🤓
🔗 Подробности: aka.ms/open-source-ai-editor
#VSCode #OpenSource #ИИ #Разработка #Сообщество
Команда Visual Studio Code объявила о планах трансформировать VS Code в редактор с открытым исходным кодом для работы с ИИ.
Конкуренция - двигатели прогресса!
🔗 Подробности: aka.ms/open-source-ai-editor
#VSCode #OpenSource #ИИ #Разработка #Сообщество
🔧 DevOps Pro Tips: Оптимизация контейнеров как у SRE Google
Контейнер — это не просто
⚫ Ограничь права контейнера
▪️
▪️
▪️
⚫ Установи лимиты CPU и памяти
▪️ Не давай контейнеру жрать весь хост — особенно на multi-tenant нодах
▪️ Используй
⚫ Чисти от мусора
- Используй multi-stage builds — минимизируй размер образа
- Оставляй только необходимые бинарники и конфиги
- Пример:
⚫ Используй distroless или Alpine
- Образы типа
-
⚫ Пропиши healthcheck
▪️ Kubernetes будет перезапускать только при реальных сбоях
⚫ Подключи observability
- Встраивай Prometheus exporter
- Логи — в stdout/stderr (для
- Используй
⚫ Проверь, чем занят контейнер
▪️ Вовремя заметишь, если процесс форкает что-то лишнее или идёт через
💡 Эти практики критичны, если:
- Вы деплоите в прод с autoscaling
- Контейнеры крутятся в k8s или Fargate
- Вам важно сократить издержки на ресурсы и повысить безопасность
Минимальный, безопасный, ограниченный и наблюдаемый контейнер — залог стабильности продакшна.
@devopsitsec
Контейнер — это не просто
Dockerfile
. Это микросистема, и если её не настраивать — она будет жечь CPU, RAM и SSD без пользы. Вот 🔥 продвинутые советы по настройке контейнеров:⚫ Ограничь права контейнера
docker run --read-only --cap-drop=ALL --security-opt no-new-privileges ...
▪️
--read-only
— защищает файловую систему ▪️
--cap-drop=ALL
— удаляет лишние привилегии ▪️
no-new-privileges
— запрещает повышение прав в процессе⚫ Установи лимиты CPU и памяти
docker run --memory="512m" --cpus="1.5" ...
▪️ Не давай контейнеру жрать весь хост — особенно на multi-tenant нодах
▪️ Используй
cpu-shares
, cpuset
, ulimits
для тонкой настройки⚫ Чисти от мусора
- Используй multi-stage builds — минимизируй размер образа
- Оставляй только необходимые бинарники и конфиги
- Пример:
FROM golang:1.22 as builder
WORKDIR /app
COPY . .
RUN go build -o app
FROM alpine:3.19
COPY --from=builder /app/app /bin/app
ENTRYPOINT ["/bin/app"]
⚫ Используй distroless или Alpine
- Образы типа
gcr.io/distroless/static
— без шелла, package manager и мусора -
alpine
— легче, но следи за совместимостью с glibc⚫ Пропиши healthcheck
HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/health || exit 1
▪️ Kubernetes будет перезапускать только при реальных сбоях
⚫ Подключи observability
- Встраивай Prometheus exporter
- Логи — в stdout/stderr (для
kubectl logs
и EFK/PLG стека) - Используй
otel
, если нужен tracing⚫ Проверь, чем занят контейнер
docker top <container>
docker inspect --format '{{ .HostConfig }}' <container>
▪️ Вовремя заметишь, если процесс форкает что-то лишнее или идёт через
/dev
💡 Эти практики критичны, если:
- Вы деплоите в прод с autoscaling
- Контейнеры крутятся в k8s или Fargate
- Вам важно сократить издержки на ресурсы и повысить безопасность
Минимальный, безопасный, ограниченный и наблюдаемый контейнер — залог стабильности продакшна.
@devopsitsec
⚡️ OneUptime — open-source-платформа для мониторинга всего и сразу. Этот инструмент предлагает готовый комплект: от мониторинга uptime до управления инцидентами. Редкий случай, когда open-source-проект не уступает коммерческим аналогам по функционалу.
Особенность проекта в глубокой интеграция компонентов. Например, при падении сервиса система автоматически создаёт инцидент, уведомляет ответственных через эскалацию и обновляет статус-страницу. Есть даже встроенный APM с трейсами и метриками производительности. Развернуть можно на Kubernetes или через Docker Compose.
🤖 GitHub
@devopsitsec
Особенность проекта в глубокой интеграция компонентов. Например, при падении сервиса система автоматически создаёт инцидент, уведомляет ответственных через эскалацию и обновляет статус-страницу. Есть даже встроенный APM с трейсами и метриками производительности. Развернуть можно на Kubernetes или через Docker Compose.
🤖 GitHub
@devopsitsec
Шпаргалка_по_командам_Linux_для_среднего_и_продвинутого_уровня_1.pdf
149.2 KB
Сохраняйте себе, чтобы не потерять
📌 Полная версия онлайн
Please open Telegram to view this post
VIEW IN TELEGRAM
🏰 SSHportal — умный шлюз для SSH-доступа без головной боли. Этот проект превращает управление SSH-доступом в интуитивный процесс. Вместо ручного редактирования authorized_keys на каждом сервере, SSHportal централизует контроль через единую точку входа с ролевой моделью доступа.
Инструмент имеет встроенную систему инвайтов: можно приглашать пользователей без обмена ключами вручную. Под капотом SQLite/MySQL для хранения данных и полная совместимость с обычными SSH-клиентами.
🤖 GitHub
@devopsitsec
Инструмент имеет встроенную систему инвайтов: можно приглашать пользователей без обмена ключами вручную. Под капотом SQLite/MySQL для хранения данных и полная совместимость с обычными SSH-клиентами.
🤖 GitHub
@devopsitsec
🧠 Claude Opus решил баг, с которым я боролся почти 5 лет — личная история разработчика C++ и бывшего старший инженер FAANG с
💬 Один из пользователей на Reddit поделился настоящим инсайтом: после многолетней борьбы с трудноуловимым багом, ему наконец-то помог… Claude Opus.
Баг был из тех, что появляются раз в полгода, ведут себя нестабильно, и каждый раз ускользают от дебаггера. В отчаянии он просто описал проблему Claude-у — без стеков, логов, трейсинга. И внезапно получил абсолютно точный ответ: баг оказался связан с тем, как обрабатывались замыкания внутри лямбд, теряющих доступ к нужному контексту после асинхронного вызова.
🤯 Результат: 5 лет неуловимого бага ушли за 30 секунд диалога с ИИ.
📌 Это не просто красивая история. Она показывает, как LLM уровня Opus начинает конкурировать не только с поиском и документацией — но и с самим процессом инженерного мышления.
🔍 Что можно вынести:
• Не бойся формулировать даже "глупые" вопросы — хорошие модели часто угадывают суть
• Застрял на баге? Попробуй объяснить его как человеку — иногда именно это помогает найти решение
• Хороший ИИ не заменит опыт, но может стать отличным напарником по отладке
📎 Оригинальный пост на Reddit
@devopsitsec
💬 Один из пользователей на Reddit поделился настоящим инсайтом: после многолетней борьбы с трудноуловимым багом, ему наконец-то помог… Claude Opus.
Баг был из тех, что появляются раз в полгода, ведут себя нестабильно, и каждый раз ускользают от дебаггера. В отчаянии он просто описал проблему Claude-у — без стеков, логов, трейсинга. И внезапно получил абсолютно точный ответ: баг оказался связан с тем, как обрабатывались замыкания внутри лямбд, теряющих доступ к нужному контексту после асинхронного вызова.
🤯 Результат: 5 лет неуловимого бага ушли за 30 секунд диалога с ИИ.
📌 Это не просто красивая история. Она показывает, как LLM уровня Opus начинает конкурировать не только с поиском и документацией — но и с самим процессом инженерного мышления.
🔍 Что можно вынести:
• Не бойся формулировать даже "глупые" вопросы — хорошие модели часто угадывают суть
• Застрял на баге? Попробуй объяснить его как человеку — иногда именно это помогает найти решение
• Хороший ИИ не заменит опыт, но может стать отличным напарником по отладке
📎 Оригинальный пост на Reddit
@devopsitsec
7 популярных мифов о Service mesh, которые мешают вам его освоить 🚫
Service mesh окружен заблуждениями, из-за которых многие его боятся внедрять или считают бесполезным:
➖ «У него огромный оверхед из-за нагрузки на систему»
➖ «Для разработчика это лишнее, пусть DevOps разбираются»
➖ «Зачем он нужен, если есть API Gateway?
И многое другое.
Собрали противоречивые утверждения в одном файле и разобрались, где – правда, а где – миф.
📌 Забирайте полезный материал у бота-помощника в один клик.
erid: 2W5zFFwDVYC
Service mesh окружен заблуждениями, из-за которых многие его боятся внедрять или считают бесполезным:
➖ «У него огромный оверхед из-за нагрузки на систему»
➖ «Для разработчика это лишнее, пусть DevOps разбираются»
➖ «Зачем он нужен, если есть API Gateway?
И многое другое.
Собрали противоречивые утверждения в одном файле и разобрались, где – правда, а где – миф.
📌 Забирайте полезный материал у бота-помощника в один клик.
erid: 2W5zFFwDVYC
🌒 LunaTrace — бесплатный open-source инструмент для аудита безопасности зависимостей. Он автоматически сканирует зависимости в проектах, выявляет уязвимости и интегрируется с GitHub Pull Requests, чтобы предупреждать о рисках до деплоя.
Главное преимущество проекта — это гибкость развёртывания. Можно использовать готовый SaaS или запустить свою инстанс-версию. Помимо мониторинга, в арсенале есть Log4Shell CLI для поиска и исправления уязвимых JAR-файлов и блог с разборами security-проблем.
🤖 GitHub
@devsecops
Главное преимущество проекта — это гибкость развёртывания. Можно использовать готовый SaaS или запустить свою инстанс-версию. Помимо мониторинга, в арсенале есть Log4Shell CLI для поиска и исправления уязвимых JAR-файлов и блог с разборами security-проблем.
🤖 GitHub
@devsecops
Безопасность приложений будущего — в ваших руках
В karpovꓸcourses запускается новая совместная программа с МФТИ — ведущим техническим вузом страны, который входит в престижные рейтинги лучших университетов мира, — «Application Security: безопасная разработка приложений».
За 3 месяца вы:
> Научитесь разрабатывать безопасные приложения, выявлять уязвимости и защищать сервисы от атак.
> Освоите ключевые инструменты анализа безопасности и интегрируете защиту на всех этапах разработки.
> Изучите безопасность AI-систем и ML-моделей.
Кому это может быть интересно?
Программа подойдёт для: разработчиков, DevOps-инженеров, архитекторов, специалистам по информационной безопасности, Security Champions и студентам факультетов инфо- и кибербезопасности
Узнать больше о программе и подать заявку можно по ссылке.
Реклама. ООО «Карпов Курсы», ИНН: 7811764627, erid: 2VtzqwrtNh3
В karpovꓸcourses запускается новая совместная программа с МФТИ — ведущим техническим вузом страны, который входит в престижные рейтинги лучших университетов мира, — «Application Security: безопасная разработка приложений».
За 3 месяца вы:
> Научитесь разрабатывать безопасные приложения, выявлять уязвимости и защищать сервисы от атак.
> Освоите ключевые инструменты анализа безопасности и интегрируете защиту на всех этапах разработки.
> Изучите безопасность AI-систем и ML-моделей.
Кому это может быть интересно?
Программа подойдёт для: разработчиков, DevOps-инженеров, архитекторов, специалистам по информационной безопасности, Security Champions и студентам факультетов инфо- и кибербезопасности
Узнать больше о программе и подать заявку можно по ссылке.
Реклама. ООО «Карпов Курсы», ИНН: 7811764627, erid: 2VtzqwrtNh3
🔍 Google Cloud представил **KHI (Kubernetes History Inspector)** — инструмент, который превращает логи Kubernetes в интерактивную визуальную историю.
🧠 Зачем нужен KHI:
• Когда что-то ломается в кластере, часто приходится разбираться по сырым логам, и это ад
• KHI решает эту проблему: загружает все события в память и строит понятную временную шкалу всего, что происходило с ресурсами
🚀 Что умеет:
• Визуализирует логи как временную шкалу: деплой, рестарты, скейлы, падения
• Поддерживает фильтры и поиск — быстро находит нужные события
• Работает без агентов — использует уже существующие логи
• Показывает историю манифестов, состояния контейнеров, эвенты подов и многое другое
🛠 Подходит для:
• Отладки инцидентов и RCA (root cause analysis)
• Разработчиков и SRE, которым важно понимать, что именно пошло не так и когда
📎 GitHub: https://github.com/GoogleCloudPlatform/khi
@devopsitsec
🧠 Зачем нужен KHI:
• Когда что-то ломается в кластере, часто приходится разбираться по сырым логам, и это ад
• KHI решает эту проблему: загружает все события в память и строит понятную временную шкалу всего, что происходило с ресурсами
🚀 Что умеет:
• Визуализирует логи как временную шкалу: деплой, рестарты, скейлы, падения
• Поддерживает фильтры и поиск — быстро находит нужные события
• Работает без агентов — использует уже существующие логи
• Показывает историю манифестов, состояния контейнеров, эвенты подов и многое другое
🛠 Подходит для:
• Отладки инцидентов и RCA (root cause analysis)
• Разработчиков и SRE, которым важно понимать, что именно пошло не так и когда
📎 GitHub: https://github.com/GoogleCloudPlatform/khi
@devopsitsec
Как микросервисы меняют правила игры сегодня?
5 июня на бесплатном вебинаре эксперты из Neoflex и СберТеха познакомят вас с инструментами для создания и управления интеграциями.
Как микросервисы меняют правила игры сегодня?
5 июня на бесплатном вебинаре эксперты из Neoflex и СберТеха познакомят вас с инструментами для создания и управления интеграциями.
Вы узнаете:
• как трансформируется подход к построению интеграционного ландшафта;
• как интеграционные сценарии позволяют сократить time-to-market;
• как создать надежную интеграционную архитектуру с решениями Platform V;
• какие возможности дает iPaaS бизнесу и ИТ;
• и многое другое.
Регистрируйтесь на вебинар. До встречи!
5 июня на бесплатном вебинаре эксперты из Neoflex и СберТеха познакомят вас с инструментами для создания и управления интеграциями.
Как микросервисы меняют правила игры сегодня?
5 июня на бесплатном вебинаре эксперты из Neoflex и СберТеха познакомят вас с инструментами для создания и управления интеграциями.
Вы узнаете:
• как трансформируется подход к построению интеграционного ландшафта;
• как интеграционные сценарии позволяют сократить time-to-market;
• как создать надежную интеграционную архитектуру с решениями Platform V;
• какие возможности дает iPaaS бизнесу и ИТ;
• и многое другое.
Регистрируйтесь на вебинар. До встречи!
⚡️ Composerize — мгновенное преобразование docker run в docker-compose. Composerize решает проблему нечитаемых строк с десятками флагов одним движением — конвертирует запуск контейнера через CLI в аккуратный
Инструмент доступен как, так и npm-пакет. Под капотом — парсинг флагов с их корректным переносом в YAML-структуру. Проект особенно удобен, когда нужно интегрировать новый сервис в существующий стек: Composerize умеет мержить конфиги, поддерживает разные версии Compose и даже настраивает отступы.
🤖 GitHub
@DevopsDocker
compose.yaml.
Инструмент доступен как, так и npm-пакет. Под капотом — парсинг флагов с их корректным переносом в YAML-структуру. Проект особенно удобен, когда нужно интегрировать новый сервис в существующий стек: Composerize умеет мержить конфиги, поддерживает разные версии Compose и даже настраивает отступы.
🤖 GitHub
@DevopsDocker
🗄 YTsaurus теперь как сервис в Yandex Cloud
Платформа для распределенной обработки и хранения данных, которую раньше использовали внутри Яндекса, теперь доступна внешним командам.
Поддерживает работу с эксабайтами, масштабируется до миллиона CPU, работает с ClickHouse, Spark, MapReduce. Можно строить пайплайны, гонять аналитику, собирать хранилища и обрабатывать логи - всё в одной системе.
Стриминговые, структурированные и неструктурированные данные - поддержка на уровне ядра. Подходит как для тяжёлых ML-задач, так и для типовых ETL-процессов.
Инфраструктура управляется как сервис - без ручного развертывания и поддержки.
@devopsitsec
Платформа для распределенной обработки и хранения данных, которую раньше использовали внутри Яндекса, теперь доступна внешним командам.
Поддерживает работу с эксабайтами, масштабируется до миллиона CPU, работает с ClickHouse, Spark, MapReduce. Можно строить пайплайны, гонять аналитику, собирать хранилища и обрабатывать логи - всё в одной системе.
Стриминговые, структурированные и неструктурированные данные - поддержка на уровне ядра. Подходит как для тяжёлых ML-задач, так и для типовых ETL-процессов.
Инфраструктура управляется как сервис - без ручного развертывания и поддержки.
@devopsitsec