DevOps

🔥 Server Survival: Стройте облачную инфраструктуру! Играйте в интерактивную 3D-симуляцию, где вы - облачный архитектор. Стройте и масштабируйте облачную инфраструктуру, защищаясь от DDoS-атак и управляя бюджетом. Цель — выжить как можно дольше, обрабатывая легитимный трафик и избегая потерь репутации. 🚀Основные моменты: - Управление бюджетом и репутацией. - Разные типы трафика: веб, API и мошеннический. - Режимы игры: выживание и песочница для экспериментов. - Улучшение сервисов для повышения производительности. - Интуитивное управление и визуальная обратная связь. 📌 GitHub: https://github.com/pshenok/server-survival

🔥 На stepik вышел курс, который учит Создавать настоящие AI-сервисы, а не просто запускать скрипты? Этот практический курс по Python и FastAPI покажет, как собрать полноценное приложение с ИИ, базой данных, автогенерацией контента и Telegram-ботом. Ты пройдёшь путь от первого HTTP-запроса до рабочего сервиса, который сам генерирует текст через ИИ, сохраняет данные, отправляет результаты по расписанию и отвечает пользователям. Никакой теории ради теории - только практические шаги, из которых рождается реальный продукт. 🎁 48 часов действует скидка в 40% процентов 👉 Начать учиться на Stepik

⚖️ Алгоритм LinkedIn и LLM: появился ли скрытый перекос? В LinkedIn разгорается спор после того, как платформа стала активнее использовать LLM в ранжировании ленты. Поводом стал вирусный эксперимент #WearthePants, где авторы меняли пол, имя и иногда фото в профиле - и наблюдали резкие изменения охватов. Что заметили создатели контента: - Одна авторка с 10 000 подписчиков регулярно получала столько же показов, сколько ее муж с ~2 000 - После смены пола в профиле некоторые фиксировали рост показов на 200–238% всего за один день - Также сообщают о +27% к вовлеченности и похожих скачках у других участников эксперимента Позиция LinkedIn: - Пол и другие демографические поля не используются напрямую для ранжирования ленты - Сравнения «до и после» могут быть некорректными - Демографические данные применяются только в масштабных fairness-тестах, а не в продакшн-алгоритме - В реальном ранжировании используется сотни недемографических сигналов Где начинается сложная часть: Даже если пол не передается в модель напрямую, LLM может косвенно восстанавливать «gender-like» сигналы: - стиль письма - контекст профиля - реакция аудитории - история вовлеченности - паттерны языка и тем Фактически модель учится не полу, а коррелирующим с ним признакам. Еще одно наблюдение авторов: Новая система, похоже, сильнее награждает ясность мысли и ценность текста, а не частоту постинга или количество лайков. Это автоматически меняет баланс выигрывающих авторов, даже если контент кажется «тем же самым». Это не история про злой умысел, а про сложность LLM-систем. Даже без прямых демографических данных модели могут воспроизводить перекосы через косвенные сигналы. И чем сложнее алгоритм, тем труднее доказать, где именно проходит граница между корреляцией и дискриминацией. Источник: https://techcrunch.com/2025/12/12/ok-whats-going-on-with-linkedins-algo/

📈 $GOOGL, возможно, имеет один из лучших инвестиционных трек-рекордов в истории Если посмотреть на ключевые сделки Google за последние 20 лет, становится ясно, насколько рано и точно компания заходила в технологические тренды. Вот лишь часть примеров: — Android Куплен в 2005 году за ~$50 млн Сегодня оценивается более чем в ~$200 млрд ≈ 4 000x — Stripe (Series B, 2012) Оценка тогда — ~$100 млн Сегодня — около ~$70 млрд ≈ 700x — DeepMind Куплен в 2014 году за ~$500 млн Оценка сегодня — ~$100 млрд+ (как отдельной компании) ≈ 200x — YouTube Куплен в 2006 году за $1.65 млрд Оценка сегодня — ~$300 млрд+ ≈ 180x — CrowdStrike (Series D, 2017) Оценка тогда — ~$1 млрд Сегодня — ~$130 млрд ≈ 130x — Uber (Series C, 2013) Оценка тогда — ~$3.5 млрд Сегодня — ~$168 млрд ≈ 48x — AST SpaceMobile (Strategic Round, 2024) Оценка тогда — ~$1 млрд Сегодня — ~$31 млрд ≈ 31x — Slack (Series D, 2014) Оценка тогда — ~$1.1 млрд Продан Salesforce в 2021 за $27.

🐧 Linux/DevOps совет: используйте `nsenter` для входа в неймспейсы любого процесса - как будто вы «телепортируетесь» внутрь его окружения. Что это дает: - Можно зайти в network namespace контейнера или pod'а без Docker/K8s CLI. - Можно дебажить процессы, которые живут в своём mount/network/ipc пространстве. - Можно "войти" в зависший контейнер даже если обычные средства не помогают. Базовый пример: nsenter --target <PID> --net --uts --ipc --mount -- pidof bash Вы окажетесь *в том же network/mount пространстве*, что и целевой процесс. Пример: войти в network-namespace контейнера Docker: nsenter --target $(docker inspect -f '{{.State.Pid}}' <container>) --net bash Лайфхаки: 1) Проверить сетевой стек проблемного пода в Kubernetes: nsenter --target $(crictl inspect <container> | jq .info.pid) --net bash 2) Посмотреть реальную файловую систему процесса: nsenter --target <PID> --mount bash 3) Разобраться, почему сервис не видит DNS: nsenter --target <PID> --net cat /etc/resolv.conf 4) Проверить firewall/NAT внутри network namespace: nsenter --target <PID> --net iptables -L -n Почему полезно: - Это самый низкоуровневый способ «зайти внутрь» изолированного окружения. - Работает даже когда Docker/K8s/ctr разваливаются. - Отлично подходит для сложного дебага сетевых и файловых проблем. nsenter - инструмент, который большинство DevOps слышали, но редко используют. А зря.

Новые сервисы для надежности вашей инфраструктуры 🔗 Облачный провайдер Cloud․ru выпустил три сервиса в общий доступ на платформе Cloud․ru Evolution. Используйте их, чтобы повысить защиту ваших ресурсов.

➡️Evolution Load Balancer v2 помогает быстро и стабильно распределять нагрузку, работая сразу в нескольких зонах доступности. С этим сервисом вы можете быть уверены в стабильности работы своих систем, даже в случае сбоев в одной из зон. ➡️Evolution Agent Backup создает резервные копии виртуальных машин из облаков сторонних провайдеров, экономя место и время благодаря полным и инкрементальным копиям. ➡️Evolution Disaster Recovery обеспечивает быстрое восстановление работы IT-систем при сбоях или киберинцидентах.

А еще вы можете бесплатно протестировать Evolution Container Security — сервис, который помогает выявлять проблемы безопасности на всех этапах жизненного цикла контейнерных приложений. Все сервисы работают с поддержкой 24/7, гарантированным SLA и возможностью масштабирования нагрузки.

🐧 Продвинутый Linux/DevOps совет: используйте `systemd-run` для мгновенного запуска задач в изолированных временных сервисах - без написания unit-файлов. Фишка: systemd-run позволяет запускать команды как полноценные systemd-сервисы "на лету". Это идеальный инструмент для временных задач, отладки, ограничения ресурсов и тестирования поведения в боевых условиях. Примеры: 1) Запуск команды в отдельном cgroup с лимитом CPU: systemd-run --scope -p CPUQuota=20% bash -c "make build" 2) Запуск периодической задачи без cron: systemd-run --on-calendar="hourly" /usr/local/bin/cleanup.sh 3) Проверка сервиса в sandbox-режиме: systemd-run --property=PrivateTmp=yes --property=ProtectSystem=strict bash 4) Изоляция для небезопасной команды: systemd-run -p NoNewPrivileges=yes -p PrivateDevices=yes ./script.sh Чем полезно: - Не нужно создавать и чистить unit-файлы - Команда получает все преимущества systemd: логи, cgroups, sandbox - Отлично подходит DevOps-инженерам для тестов и временных задач - Позволяет гарантировать безопасность и стабильность окружения Если вы ещё не используете systemd-run как «одноразовый unit-файл», попробуйте - это один из самых недооценённых инструментов systemd.

❕ Бесплатный вебинар: «GitOps + Flux — автоматизированный деплой в Kubernetes» Мечтаете деплоить в Kubernetes по принципу «закоммитил — заработало»? Приходите на открытый урок! Когда: 23.12 в 20:00 Для кого: DevOps‑инженеры, разработчики, администраторы Kubernetes. Вы узнаете: • что такое GitOps и почему это стандарт работы с Kubernetes; • как Flux синхронизирует кластер с Git; • примеры настройки Flux; • как избежать ошибок при внедрении GitOps. После урока сможете: • настроить базовый пайплайн GitOps с Flux; • оценить применимость GitOps для вашего проекта. ➡️ Регистрируйтесь сейчас: https://otus.pw/CDpN/?erid=2W5zFJsoC3J Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

⚡️ CACHING STRATEGIES В СИСТЕМНОМ ДИЗАЙНЕ Кэширование хранит часто используемые данные в быстром слое, обычно в памяти. Это снижает нагрузку на базу данных и ускоряет ответы системы. Один из самых эффективных способов улучшить производительность, масштабируемость и сократить расходы. ПОЧЕМУ КЭШИРОВАНИЕ ВАЖНО Экономит запросы к базе Уменьшает задержку Справляется с высоким количеством чтений Укрепляет стабильность при нагрузках Снижает стоимость инфраструктуры 1) CLIENT-SIDE CACHING Хранение данных в браузере пользователя. Используются cookies, localStorage, service workers. Меньше повторных загрузок статических ресурсов. 2) CDN CACHING Статические файлы лежат на глобальных edge-серверах. CSS, JS, изображения, видео, шрифты. Меньше задержка у глобальных пользователей и разгрузка основного сервера. 3) APPLICATION-LEVEL CACHING Кэш внутри приложения. Например, структуры в памяти вроде LRU cache. Очень быстро, но работает в рамках одного сервера. 4) DISTRIBUTED CACHING Общий кэш для множества серверов. Инструменты: Redis, Memcached. Подходит для горизонтального масштабирования и устраняет дублирование кэша. 5) DATABASE QUERY CACHING Базы хранят результаты частых запросов. MySQL Query Cache, Postgres внутренний кэш, MongoDB WiredTiger. Ускоряет повторные чтения. 6) WRITE-BEHIND Запись идет в кэш, а в базу — асинхронно. Снижает задержку записи. Подходит для систем с высокой нагрузкой на запись. 7) WRITE-THROUGH Записи попадают в кэш и базу одновременно. Гарантирует консистентность. Немного медленнее из-за двойной записи. 8) CACHE-ASIDE Приложение сначала проверяет кэш. Если промах — идет в базу, затем помещает результат в кэш. Гибкий и самый популярный вариант. 9) READ-THROUGH Приложение всегда читает из кэша. При промахе сам кэш получает данные из базы. Кэш всегда остается обновленным. 10) TTL И ПОЛИТИКИ ИСТЕЧЕНИЯ Каждая запись имеет срок жизни. TTL, LRU, LFU, FIFO — разные режимы очистки данных. 11) INVALDATION Ручное удаление ключей, удаление по шаблону, автоматическое истечение по TTL или лимиту памяти. 12) MULTI-LAYERED CACHING Несколько уровней сразу: браузер, CDN, распределенный кэш, кэш приложения. Полезно для глобальных систем с большим трафиком. Совет Кэширование помогает добиться высокой скорости, низкой нагрузки на базу и хорошей масштабируемости. Стратегию нужно подбирать исходя из размеров системы, интенсивности запросов и требований к консистентности.