DevOps

🖥Понятное объяснение Docker Networking Models Docker поддерживает несколько сетевых моделей - от полной изоляции до работы напрямую с сетью хоста. Выбор нужного варианта влияет на безопасность, производительность и масштабируемость приложения. 1) Bridge (по умолчанию) → Docker создаёт виртуальный мост docker0. → Контейнеры общаются друг с другом по внутренним IP. → Чтобы получить доступ извне, нужно пробрасывать порты (-p 8080:80). → Идеально для локальной разработки и одиночных хостов. 2) Host → Контейнер использует сетевой стек хоста напрямую. → Нет виртуальной сети и NAT - максимум производительности. → Минимальная изоляция. → Применяется для мониторинга, логгинга, высокоскоростных сервисов. 3) None → У контейнера вообще нет сети. → Нет доступа ни к интернету, ни к другим контейнерам. → Используется для задач, где требуется полная изоляция. 4) Overlay → Сеть, работающая поверх нескольких хостов или в Docker Swarm. → Контейнеры на разных серверах могут общаться как будто они в одной сети. → Основа для распределённых микросервисных систем. 5) Macvlan → Каждый контейнер получает свой MAC-адрес и «видится» как отдельная машина. → Контейнеры становятся полноценными участниками вашей физической сети. → Полезно, когда контейнеры должны быть напрямую доступны по LAN. 6) IPvlan → Похоже на Macvlan, но проще управляет IP-адресами на уровне L3. → Хорошо подходит для масштабных систем с жёсткими требованиями к маршрутизации. Дополнительно: Сервис-дискавери → Внутри Docker работает собственный DNS - контейнеры могут общаться по имени сервиса, а не по IP. Проброс портов → Стандартный вариант доступа извне: -p 8080:80 Драйверы сетей → bridge → host → overlay → macvlan → ipvlan Как выбрать модель? → Bridge — одиночный хост, локалка. → Host — максимум скорости, минимум изоляции. → Overlay — распределённые микросервисы. → Macvlan — нужны «настоящие» сетевые адреса. → None — полная изоляция без сети. Правильный выбор сетевой модели Docker напрямую влияет на безопасность, структуру архитектуры и производительность. Чтобы уверенно работать с контейнерами и микросервисами - эти модели нужно знать.

💡QuantWare, квантовый стартап из Нидерландов, представил новую архитектуру квантового процессора — VIO-40K. Ключевая заявка - до 10 000 кубитов на одном чипе. Это примерно в 100 раз больше, чем у ведущих квантовых процессоров Google и IBM сегодня. Такой скачок стал возможен за счёт отказа от классической 2D-разводки: - переход на 3D-архитектуру с вертикальными соединениями - модульный подход с chiplet-ами - поддержка до 40 000 линий ввода-вывода Идея простая, но мощная: масштабировать не «в плоскости», а в объёме, резко увеличивая плотность кубитов без экспоненциального усложнения разводки. Параллельно QuantWare строит собственное производственное предприятие в Нидерландах, чтобы выпускать такие чипы уже на индустриальном уровне, а не в лабораторных объёмах. Если подход подтвердится на практике, это может стать одним из самых серьёзных шагов к реально масштабируемым квантовым компьютерам. https://www.slashgear.com/2053448/quantware-quantum-computer-processor-10000-qubit/

⚡Git Cheatsheet - коротко и по делу Настройка git config --global user.name "Name" — задать имя git config --global user.email "email" — задать почту git config --list — показать настройки Старт git init — создать репозиторий git clone url — клонировать репо Стейджинг и коммиты git status — статус git add . — добавить все изменения git reset file — убрать из стейджа git commit -m "msg" — коммит git commit --amend — исправить последний коммит Ветки git branch — список git branch name — создать git checkout -b name — создать и перейти git branch -d name — удалить Merge и Rebase git merge branch — слить ветку git merge --abort — отменить git rebase branch — перебазирование История git log --oneline — компактная история git log --graph --all — граф git diff — показать изменения Откат git restore file — вернуть файл git reset --soft HEAD~1 — откатить коммит, сохранить изменения git reset --hard HEAD~1 — откатить и удалить изменения git clean -f — удалить лишние файлы Удалённые репозитории git remote -v — список git push origin branch — запушить git pull — получить изменения git fetch — только забрать Теги git tag — список git tag name — создать git push origin --tags — отправить теги Stash git stash — сохранить изменения git stash list — список git stash apply — применить Поиск и анализ git blame file — кто менял строки git grep "text" — поиск git bisect — бинарный поиск бага Продвинутое git cherry-pick commit — взять коммит git revert commit — отменить коммит через новый git submodule add url — добавить сабмодуль Полезно сохранить под рукой.

📌Итоги года от Андрея Карпаты. 2025 год был захватывающим годом для языковых моделей. Они проявились как новый вид интеллекта, одновременно гораздо более умный и гораздо более глупый, чем я ожидал. Я думаю, что индустрия не реализовала хотя бы 10% их потенциала даже при нынешних возможностях. Я одновременно верю и в то, что мы увидим быстрый и непрерывный прогресс, и в то, что впереди еще очень много работы. Пристегнитесь. 🟡Обучение с подкреплением на основе проверяемых вознаграждений (RLVR) В 2025-м стек обучения LLM дополнился новой ключевой стадией оптимизации по объективным наградам. Он заставляет модели самостоятельно находить стратегии рассуждения. Прогресс года в том, что создание моделей стало не про увеличение размера модели, а про более длительные RLVR-прогоны. Это также дало новый рычаг управления: "время размышления" на инференсе. Первопроходец - OpenAI o1, а переломный момент - o3. 🟡Интеллект современных LLM принципиально отличен от человеческого Интеллект LLM формируется под давлением специфических оптимизаций и на выходе мы имеем резкие всплески способностей в рядом с грубыми ошибками. Из-за этого бенчмарки теряют смысл: под них напрямую оптимизируются, что не ведёт к созданию AGI. 🟡Cursor - это новый слой LLM-приложений Это не просто интерфейс к условной модели, а сложная оркестрация работы LLM под конкретные вертикали, c управляемым контекстом, вызовами и интерфейсом. Cursor создаёт отдельную ценностную прослойку между LLM-лабораториями и конечными пользователями. 🟡Claude Code В отличие от облачных агентов, он использует ваши данные, контекст и инструменты для ризонинга и вызова инструментов. Его фишка - в низкой задержке, приватности и глубокой интеграции в рабочее окружение. Это сдвиг от ИИ как «сайта» к напарнику-помощнику в вашей системе. Я думаю, OpenAI допустили ошибку, сосредоточив свои усилия по созданию агентов в облаке и управляемых из ChatGPT, вместо localhost. 🟡Вайб-кодинг В 2025 году ИИ преодолел порог, позволяющий через текстовые инструкции создавать работающие программы. Это демократизирует программирование, позволяя непрофессионалам писать код, а экспертам - быстро прототипировать без глубокого погружения. Код становится эфемерным, гибким и бесплатным ресурсом. Забавно, что я придумал термин «вайб-кодинг» в этом твите с мыслями из душа, совершенно не представляя, как далеко это зайдет :) 🟡LLM GUI и Nano banana Взаимодействие с ИИ через чат - это аналог командной строки 80-х, неудобный для человека. Будущее за LLM GUI интерфейсом, где ИИ общается визуально (инфографика, анимации, веб-приложения). Nano banana - ранний пример такого взаимодействия, в ней объединены генерация текста, изображений и общие знания. Google Gemini Nano banana — одна из самых невероятных, меняющих парадигму моделей 2025 года. 🔜Читать статью полностью @ai_machinelearning_big_data

⚡️Monitoring и Observability в DevOps: понятное введение Monitoring и наблюдаемость - важная часть DevOps. Они помогают понять, как работает система, вовремя замечать проблемы и быстро их устранять. Monitoring показывает, что происходит в системе: рост задержек, ошибки, перегрузка ресурсов. Observability помогает понять, почему это произошло, используя данные из логов, метрик и трассировок. Зачем это нужно в DevOps - раннее обнаружение проблем - стабильность и высокий аптайм - быстрое расследование инцидентов - улучшение CI/CD и качества релизов - безопасные и предсказуемые обновления Три ключевых источника данных Метрики Числовые показатели: CPU, память, задержка, ошибки. Подходят для наблюдения за трендами. Логи Текстовые записи событий и ошибок. Нужны для отладки и поиска причин. Трейсы Путь запроса через микросервисы. Особенно важны для Kubernetes и распределённых систем. Инструменты, которые используют в DevOps Prometheus — сбор и хранение метрик. Хорошо интегрируется с Kubernetes. Grafana — визуализация данных и дашборды. ELK Stack — сбор, хранение и анализ логов. Jaeger / OpenTelemetry — распределённые трассировки и анализ сервисов. Как выглядит рабочий процесс мониторинга - определить ключевые метрики: CPU, память, задержка, ошибки - настроить агентов для сбора данных - отправлять данные в системы мониторинга - построить дашборды - настроить алерты - использовать логи и трейсы для поиска причины Лучшие практики мониторинга - определяйте SLI, SLO, SLA для оценки надёжности - автоматизируйте уведомления - мониторьте весь DevOps-пайплайн - отслеживайте реальный опыт пользователей - интегрируйте мониторинг с системой реагирования на инциденты Что это даёт - быстрое обнаружение проблем - снижение MTTR - уверенность при релизах - лучшее понимание микросервисов - улучшение пользовательского опыта - развитие DevOps-процессов на основе данных Совет напоследок Monitoring показывает что происходит. Observability показывает почему это происходит. Вместе они создают надёжную и масштабируемую DevOps-инфраструктуру.

🚀 Удобное управление CI/CD с Pipedash Pipedash — это настольное приложение, которое объединяет CI/CD пайплайны из различных провайдеров в одном интерфейсе. Вместо того чтобы переключаться между разными панелями управления, вы можете отслеживать статус всех своих пайплайнов в одном месте. Приложение поддерживает GitHub Actions, GitLab CI, Jenkins и другие. 🚀 Основные моменты: - Объединяет данные из нескольких CI/CD провайдеров - Автоматическое обновление статусов пайплайнов - Поддержка плагинов для добавления новых провайдеров - Локальное хранение данных без аналитики и телеметрии - Доступно для macOS, Windows и Linux 📌 GitHub: https://github.com/hcavarsan/pipedash #rust

Linux совет💡 Чтобы просмотреть длинный файл без открытия редактора, используй less: $ less /var/log/syslog Можно удобно скроллить вверх и вниз, искать по тексту и ничего не менять в файле. Чтобы выйти — нажми q.

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

⚖️ Алгоритм 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 слышали, но редко используют. А зря.

🐧 Продвинутый 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.