DevOps и инфраструктура — страница 3

#cocoon #noiseДецентрализованный ИИ и частные облака⭐️◽️◽️◽️◽️📖 Читать

про инфраструктуры часто говорят, что они обеспечивают связность.например, телеграм замедлили в России, а теперь и блокируют. значит, связность превращается в бессвязность. и вообще, это выглядит как поломка инфраструктуры. но верно ли это?согласно Сьюзан Ли Стар [1], инфраструктуры:1. встроены в структуры и технологии, работают в конкретных условиях.2. незаметны, но видны, когда ломаются.3. всеохватны и доступны, могут быть масштабированы4. их правила усваиваются в социальных практиках и построены на конвенциях.5. стандартизированы (или могут быть стандартизированы)видите? ни слова про связность. почему же мы ждём её от инфраструктур, и так удивляемся, если связность прерывается, или наоборот, возникает бессвязность? что произошло, когда у радио появились национальные границы и действительно ли оно было WWW (world wide wireless)? повторяет ли интернет его судьбу?об этом буду рассказывать на лекции в Европейском университете 30 марта в 19.00. рассказываю в рамках нашей образовательной программы про Евразию и связность, чтобы образование помогало справляться с такими непонятными процессами и превращать удивление в исследовательские вопросы. подробности, регистрация и анонс.———1. Star, S. L. (1999). The ethnography of infrastructure. American behavioral scientist, 43(3), 377-391.

📺 System Design: продвинутое кэшированиеВ этот раз поговорим о многослойном кэше, когерентности между уровнями кэша и как ее соблюдать через различные стратегии наполнения и инвалидации кэша. Также посмотрим на распространенные проблемы - thundering herd, stale data, hot keys, версионирование кэша и отравление кэша.Постарался сделать видео полезным для прохождения собеседований и применения знаний на практике, а не абстрактную теорию.👉 https://www.youtube.com/watch?v=_96AOLES_6M#cache #SystemDesign 👮‍♂️ Злой полицейский

The State of DevOps Modernization 2026 (Рубрика #Devops)Изучил недавно вышедший отчет "The State of DevOps Modernization 2026" от Harness. Отчет основан на опросе ~700 инженеров и руководителе, что был проведен в феврале 2026 года компанией Coleman Parkes. Основной вывод отчета в том, что AI резко ускорил локальный цикл кодирования, а остальная часть delivery контура во многих командах внутри корпораций не успевает его переварить.Основная аналитическая модель отчета очень простая: почти все выводы построены через cross-tab по вопросу "как часто вы используете AI инструменты для кодирования" - от нескольких раз в день до более редкого использования. То есть это не анализ телеметрии и не каузальный инференс как в DORA, а срез восприятия и самооценок респондентов.Авторы выделил следующие ключевые результаты1️⃣ Скорость действительно выросла. 45% very frequent AI пользователей говорят о ежедневных или чаще развертывания против 32% у frequent и 15% у occasional users. Но рядом с этим идет налог на стабильность: 69% very frequent users говорят, что AI-generated code приводит к проблемам с развертыванием как минимум в половине случаев; 22% deployments в этой когорте заканчиваются rollback, hotfix или customer-impacting incident; MTTR по таким инцидентам у них выше - 7.6 часа против 6.0 и 6.3 часа в соседних когортах.2️⃣ Но это напряжение распространяется далеко за пределы инцидентов. Среди very frequent AI users 50% говорят о росте vulnerabilities/security инцидентов и 50% - о росте non-compliance issues; 49% видят больше проблемы с производительностью; 51% - больше code quality/efficiency problems. При этом сами авторы специально оговаривают: явной причинно-следственной связи между AI coding и этими проблемами отчет не доказывает (такой дизайн эксперимента может показать только корреляции)3️⃣ Coding автоматизируется быстрее, чем остальной SDLC. 84% респондентов используют AI ежедневно для coding, но для QA testing этот показатель 68%, для performance/cost optimization 63%, для refactoring 62%. 47% very frequent users говорят, что ручная работа дальше по пайплайну после кода стала проблемнее (это QA, code review, remediation); 69% теряют время из-за медленных и ненадженых CI/CD; 70% считают, что их pipelines страдают от flaky тестов and неуспешных развертываний; 75% связывают давление на шиппинг с выгоранием; 73% говорят, что у них почти нет стандартных темплейтов и golden pathsВ итоге, видно, что проблема в том, что AI усиливает throughput там, где платформа, CI/CD, гейты контроля и координация остались на старой скорости. Авторы сами это почти проговаривают: у них есть гипотеза, что heavy AI users просто пытаются доставлять больше кода и поэтому острее чувствуют flaky tests и deployment failures; их pipelines не обязательно хуже, просто потребности уже выше. Это сильный инсайт, но как доказательств причинности отчет не дает:)Примерно эти же мысли я писал в статье "От классического PDLC к AI-native разработке", но в основном опирался на другие исследования типа DORA или нашего AI4SDLC, который мы проводили от "Т-Технологий" в конце прошлого года и проведем еще раз в этом году#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

⚙️ Использование systemd-analyze для оптимизации загрузки системы✔️При работе с Linux-серверами и даже десктопами, производительность системы во время загрузки часто остаётся упущенной. Но с помощью инструмента systemd-analyze можно не только анализировать время загрузки, но и выявлять узкие места, которые замедляют процесс.➡️ Анализ времени загрузки▶️Команда systemd-analyze позволяет увидеть, сколько времени уходит на загрузку всей системы и отдельных компонентов. Вывод покажет общую продолжительность загрузки, включая ядро и пользовательские службы.➡️ Выявление «тяжелых» сервисов▶️Для более детального анализа, чтобы понять, какие службы и процессы занимают больше всего времени, можно использовать команду systemd-analyze blame▶️Вывод отобразит все активированные сервисы с их временем загрузки в порядке убывания. Это поможет вам определить, какие сервисы требуют оптимизации или может быть даже отключения.➡️ Оптимизация▶️Если вы хотите понять, какие службы непосредственно зависят друг от друга, и как они влияют на общую продолжительность загрузки, используйте команду systemd-analyze critical-chain▶️Она покажет цепочку зависимостей сервисов, и вы сможете понять, какой из них блокирует или замедляет другие. Это поможет принять решение, стоит ли изменить порядок загрузки или даже оптимизировать сами сервисы.➡️ Это позволяет не только ускорить загрузку системы, но и выявить слабые места в её конфигурации, что полезно для администраторов, стремящихся повысить производительность серверов или десктопных машин.🖼️ Ссылка на источник🔨 bash_help

📝 DNS-записи - справочник, который должен знать каждый👋 Привет, сетевой друг! DNS работает не одной записью, а целым набором типов. Каждый отвечает за свою задачу, разберём все по порядку.🟣A и AAAA: A-запись связывает домен с IPv4, AAAA с IPv6. Первое, что проверяют при диагностике любой сетевой проблемы.🟣PTR: Обратная резолюция, адрес в имя. Используется в почтовых серверах и логах. Отсутствующий PTR частая причина, почему письма уходят в спам.🟣CNAME: Псевдоним домена, www.my.com → my.com. Именно через брошенные CNAME происходит subdomain takeover - запись есть, ресурса нет, его можно занять.🟣MX: Указывает сервер для приёма почты домена. Чем меньше число приоритета, тем выше в очереди стоит сервер.🟣NS: Какие серверы авторитативны для домена. Компрометация NS это перехват всего, что связано с доменом.🟣TXT: Формально просто строка, но там живут SPF, DKIM, DMARC и верификационные токены. Аудит TXT-записей показывает, какие сторонние сервисы подключены к домену.🟣SRV: Хост и порт для конкретного сервиса. Используется в SIP, XMPP, Kubernetes. При разведке помогает понять топологию инфраструктуры.🟣SOA: Первичный NS, email администратора, серийный номер зоны. По серийному номеру видно, как давно и как часто зона обновляется.🟣CAA: Какие CA имеют право выпускать SSL для домена. Записи нет, любой центр может выпустить сертификат.Серверная Админа | Zeroday | #VLAN #subnet

1.0 release of Ingress2GatewayIngress в Kubernetes постепенно уходит: ingress-nginx официально перестанут поддерживать с марта 2026. Под это как раз вышел Ingress2Gateway 1.0 — инструмент, который конвертирует существующие Ingress-манифесты в новый формат Gateway API (Gateway, HTTPRoute и т.д.). То есть можно взять уже работающие ingress’ы и не переписывать всё руками.Сам Gateway API — более гибкая и чистая модель (меньше магии с аннотациями, больше нативных возможностей). А Ingress2Gateway упрощает переход: вместо ручной миграции — автоматическая конверсия и постепенный переход.https://kubernetes.io/blog/2026/03/20/ingress2gateway-1-0-release/?utm_source=tg&utm_medium=devops&utm_campaign=240326(written by this guy: Chatham Gptman)

Сколько аудитории мы потеряем в Telegram?Про замедление Telegram вы и так всё знаете. У меня тут медиапроекты, и мне хочется понимать, какую часть аудитории мы потеряем при разных раскладах. Изучил все блокировки последних лет и их результаты, прикинул сценарии.Сценарий «Блокировка» → минус 50-65% аудиторииПолная блокировка. Ближайший аналог — Instagram: потерял 80% ежедневной аудитории за год по данным Mediascope, охват постов упал до 40-55% от доблокировочного по данным LiveDune. В Telegram нет алгоритмической ленты, поэтому даже при меньшем оттоке (мессенджер и рабочий инструмент, люди будут ставить VPN) каналы недосчитаются 50-65% аудитории.Сценарий «Замедление» → минус 15-50% аудиторииСкорость падает, но полной блокировки нет. Как YouTube в период замедления до полной блокировки в феврале 2026. Отток мягче, потому что растянут во времени. При стабильном замедлении минус 30-50% аудитории, при нестабильном (ТСПУ уже перегружено по данным CNews за март 2026) — минус 15-25%.Сценарий «Ограничения» → минус 0-35% аудиторииБлокируют, но получается не очень. Тут всё зависит от технической эффективности. В 2018 в России Роскомнадзор заблокировал 19 млн IP-адресов, положил Spotify, онлайн-банкинг и сайты МГУ, а 80% пользователей обошли блокировку за две недели — не было инструментов. В Иране в том же году Telegram заблокировали грамотнее: государство контролирует инфраструктуру интернета напрямую, мессенджер реально перестал работать без VPN, аудитория за два месяца упала на 30% и стабилизировалась. Сейчас у России есть ТСПУ, которого не было в 2018. Вопрос — хватит ли мощности. Если не хватит, аудитория каналов почти не изменится. Если хватит, то минус 20-35%.Что с этим делать, я уже размышлял вот тут. Если коротко: собирать контакты, дублировать присутствие, не строить дом на чужой территории.А вы к чему готовитесь? Что по конспирологическим теориям? Хочу обсуждать!

L4 vs L7 балансировщики: Когда хватит Nginx, а когда нужен аппаратный чемодан?Трафик пробивает потолок, сервера задыхаются, а вы всё ещё терминируете миллионы TCP-соединений на одном Nginx, сжигая CPU? Пора разобраться, где нужна умная маршрутизация, а где — тупая, но железобетонная молотилка пакетов.🥊 L4: Грубая сила и обход ядраБалансировщик 4-го уровня (IPVS, HAProxy в tcp-mode) не смотрит в payload. Он оперирует исключительно заголовками транспортного уровня (IP и порты). Никаких SSL-хэндшейков и парсинга HTTP.Боль и тюнинг: Классический программный L4 опирается на nf_conntrack в ядре Linux для отслеживания состояний. При DDoS или всплеске легитимных микро-соединений эта таблица переполняется за секунды, безжалостно дропая трафик ("table full, dropping packet"). Когда тюнинг ядра перестает спасать, энтерпрайз покупает те самые «аппаратные чемоданы» (апплайнсы с ASIC от F5 или A10) для хардварной обработки сессий. Альтернатива из мира BigTech — уход от conntrack в eBPF/XDP (например, Katran от Meta), чтобы распределять пакеты до того, как они коснутся тяжелого сетевого стека ОС.Киллер-фича: Direct Server Return (DSR). Балансировщик лишь переписывает MAC-адрес получателя (или использует IPIP инкапсуляцию), а бэкенд отвечает клиенту напрямую, минуя балансировщик. Идеальный хак для асимметричного трафика.🧠 L7: Интеллект, сжигающий тактыNginx, Envoy, Traefik терминируют TCP-соединение на себе, расшифровывают TLS, парсят HTTP/gRPC, принимают решение о маршрутизации и открывают новое соединение к бэкенду.Боль и тюнинг: Вы платите за каждый байт, который копируется из kernel space в user space и обратно. Терминация TLS на сотнях тысяч RPS ставит на колени даже самые "жирные" сервера, упираясь в CPU и требуя крипто-оффлоада. Кроме того, архитектура event-loop (epoll) чувствительна к блокировкам. Любая долгая I/O операция на диске или перегруженный воркер вызывает мгновенные спайки tail latency, отправляя 99-ю перцентиль в космос. Зато вы получаете абсолютный контроль над запросом.⚔️ Вердикт: что и когда внедрятьВыбирайте L4 (eBPF/XDP или аппаратный балансировщик), если:🔹 Вы уперлись в raw throughput (десятки Gbps) и PPS (packets per second), а не в сложную логику распределения.🔹 Ваш трафик экстремально асимметричен (запрос 1 KB, ответ 100 MB — стриминг, тяжелая статика). Паттерн DSR спасет вашу сеть от схлопывания.🔹 Вы строите Edge-слой или ingress-шлюз на bare-metal (BGP + ECMP распределяют трафик на L4-балансировщики, а те уже кидают его на пул L7-прокси).🔹 Требуется жесткий end-to-end TLS из соображений комплаенса, без man-in-the-middle терминации на балансировщике.Оставайтесь на L7 (Envoy, Nginx), если:🔸 Инфраструктура требует application-aware маршрутизации: rate limiting по API-ключам, circuit breakers, sticky sessions, routing по кастомным HTTP-заголовкам (must-have для canary-релизов).🔸 Вы внедряете Service Mesh с мультиплексированием gRPC/HTTP2.🔸 Вам нужна единая точка для аутентификации, нормализации запросов и WAF (работа в паттерне API Gateway).📚 Что почитать:Site Reliability Engineering (Google) — глава 12 (Load Balancing at the Frontend).Whitepaper: Katran: A high performance layer 4 load balancer (Engineering at Meta).Доклад Load Balancing is Impossible (найти на YouTube, спикер Tyler McMullen).

💎 АЛРОСА ПЕРЕВЕЛА ДОПУСК СОТРУДНИКОВ К СМЕНАМ В ЦИФРОВОЙ ФОРМАТ⤷ АЛРОСА завершает внедрение автоматизированной системы выдачи наряд-заданий на основных производственных площадках. За последние полгода в ней зарегистрировано более 59 тыс. заданий — почти 100% от общего числа в охваченных подразделениях. Доступ к системе получили свыше 1,5 тыс. сотрудников, инвестиции в проект превысили 50 млн рублей.➡️ Теперь подготовка, согласование и контроль нарядов ведутся в электронном виде с использованием электронной подписи. Система автоматически проверяет, прошёл ли сотрудник медосмотр, обучение по охране труда и имеет ли средства защиты. При нарушении любого требования доступ к работе блокируется.✅ В компании отмечают, что это повышает безопасность и ускоряет оформление по сравнению с бумажными журналами. До июля 2026 года систему внедрят ещё в нескольких подразделениях. Также планируется запустить электронные наряд-допуски для работ повышенной опасности и мобильное приложение для оперативных изменений прямо на месте.⏺Нефтяная и горная промышленность

#mlops https://python.plainenglish.io/12-mlops-mistakes-every-developer-makes-f7efe06ba4a2

🤔 Расскажи про процесс от пуша кода до продакшенаКогда разработчик пушит код, он проходит несколько этапов перед развертыванием в продакшене. Этот процесс автоматизируется с помощью CI/CD (Continuous Integration / Continuous Deployment). 🚩Этапы CI/CD 🟠Разработчик пушит код в Git-репозиторий - Код отправляется в GitHub, GitLab, Bitbucket или другой репозиторий. - Открывается Pull Request (PR) для ревью. git add .git commit -m "Добавлена новая фича"git push origin feature-branch🟠CI (Continuous Integration) – Автоматическая сборка и тестирование После пуша CI-сервер (Jenkins, GitHub Actions, GitLab CI/CD, CircleCI)** запускает автоматические тесты и сборку. Клонирование репозитория. Сборка проекта (например, mvn package для Java). Запуск юнит-тестов (JUnit, Mockito). Запуск интеграционных тестов (например, TestContainers). Анализ кода (SonarQube). name: CI Pipelineon: push: branches: - main - developjobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Setup Java uses: actions/setup-java@v3 with: java-version: '17' distribution: 'temurin' - name: Build project run: mvn clean package - name: Run tests run: mvn test🟠CD (Continuous Deployment) – Развёртывание на Staging После успешного CI код автоматически разворачивается в стейджинг (staging) – это тестовая среда, похожая на продакшен. Развёртывание может происходить с помощью: Docker + Kubernetes (K8s) AWS CodeDeploy, GitLab CD Terraform + Ansible FROM openjdk:17COPY target/app.jar /app.jarCMD ["java", "-jar", "/app.jar"]🟠Код проходит код-ревью и одобряется Проверяется чистота кода, читаемость и ошибки. В некоторых компаниях код проходит Security Review git merge feature-branchgit push origin main🟠CD (Continuous Deployment) – Развёртывание в продакшен Blue-Green Deployment – новый код разворачивается на отдельном сервере, затем трафик переключается. Canary Release – новый код деплоится на 5-10% пользователей, если всё хорошо – на всех. Rolling Deployment – обновление происходит поэтапно, без даунтайма. deploy: stage: deploy script: - kubectl apply -f deployment.yaml only: - mainСтавь 👍 и забирай 📚 Базу знаний

Anthropic Channels - еще один (сырой) OpenClaw кирпичикВ Claude Code завезли экспериментальную возможность подключать асинхронные каналы в сессию. От телеграмма (чтобы управлять сессией издалека) до CI/CD сервера (чтобы Claude Code видел косяки в коде и сразу же правил).Фишка потенциально интересная, но вы пока свое на это свое время не тратьте - она сырая. Там нотификации местами не ходят, теряются, MCP соединение отваливается, лимиты иногда быстро заканчиваются. А те, кто хвалят - сами не пробовали)Но во всем это очень интересна не сама фича, а продуктовое использование LLM, которая она пытается закрыть. Это та самая OpenClaw ниша, когда у нас есть долгоживущий экземпляр AI агента, в который можно засылать сообщения, а они будут исполняться.Люди обычно строят подобное через tmux + capture-pane + send-keys + свой чатик, или иные аналогичные механизмы. То есть запускают сессию в терминале и как-то пробрасывают в чат. И когда такое есть, можно сделать немало интересных интеграций:(1) чтобы Claude слушал все комментарии, которые прилетают на его PR (тесты, люди, ошибки в логах).(2) чтобы Claude сидел в Slack-e и реагировал на задачи оттуда(3) чтобы можно было запускать задачки сессии Claude Codex, которая включена в подписку (экономия tokens)В этом плане забавна такая история. В скринкасте про BitGN Sandbox, я показал свой терминал, про который начали спрашивать - "что за красота такая?" Это Ghostty, его сделал Mitchell Hashimoto (который основал Hashicorp с Terraform/Consul/Vault). И он с самого начала говорил, что делает не терминал, а библиотеку работы с терминалами, а удобное приложение - это побочный эффект (миллион выкачиваний на маках. В неделю)И сейчас libghostty используют компании для запуска AI агентов на серверах, чтобы они крутились в терминалах и общались не через достаточно шумный и нестабильный MCP, а через более привычный и экономный CLI интерфейс. Тем более, что куча старых программ и фишек через CLI и доступна. Да и развернуть безопасно MCP - это отдельная головная боль.Получается в перспективе такая дихотомия. Для запуска личных агентов - MCP, для запуска корпоративных и бизнес систем с LLM под капотом - терминальные сессии на сервере.Ваш, @llm_under_hood 🤗

Замедление домашнего интернета16.03.2026 оператор "Дом.ру" запустил в Санкт-Петербурге, Самаре и Екатеринбурге тестирование механизма ограничения скорости для абонентов, превышающих лимит трафика в 3 ТБ в месяц. При достижении порога скорость падает до 50 Мбит/с, чего, по заверениям компании, достаточно для основных цифровых сервисов. Под ограничения пока попали 267 клиентов — менее 1% от общего числа.❗️В "Дом.ру" объясняют, что 1% абонентов потребляет более 15% трафика сети, причем значительная часть этих "сверхпотребителей" — юридические лица, использующие домашние тарифы в коммерческих целях. Такая нагрузка снижает качество услуги для добросовестных клиентов. Пользователь может либо доплатить 100 рублей за каждые дополнительные 500 ГБ без ограничения, либо дождаться нового расчетного периода.❗️Лимит в 3 ТБ для обычного домохозяйства едва ли достижим: согласно статистике, среднее потребление составляет около 300 ГБ в месяц, а 99% пользователей укладываются в 500 ГБ. Чтобы превысить порог в 3 ТБ, нужно скачать не менее 300 фильмов в Full HD-качестве. Таким образом, ограничение направлено на тех, кто использует домашний интернет как бизнес-инструмент: например, для сдачи в аренду соседям или подключения терминалов оплаты.❗️В "Ростелекоме" инициативу поддержали, назвав ее защитой интересов большинства абонентов. При этом ФАС России уже анонсировала проверку экономической и технологической обоснованности нововведения. Другие крупные операторы (МТС, "Мегафон") от комментариев пока воздержались. Если эксперимент признают успешным, практику могут масштабировать на другие регионы.Для обычных пользователей 3 ТБ — действительно заоблачный объем, но сам прецедент важен: это первый шаг к отказу от полной безлимитности домашних тарифов в пользу "разумного потребления". Вопрос в том, насколько прозрачными будут критерии и не станет ли это предпосылкой введения ограниченного трафика для домашних сетей на фоне отключений и регулирования интернета.#дела_цифровые @forensic_lawyer

Как снизить стоимость наблюдаемости, не потеряв сигнал?Метрики держите как гистограммы с разумными бакетами и exemplars; для трасс — tail-based sampling и приоритет ошибок/p99; логи — семплинг по правилам, агрегаты в метриках, горячее/холодное хранение с разными ретенциями. Урезайте кардинальность лейблов, нормализуйте ключи и вводите бюджеты/алерты по объёму телеметрии.🐸Библиотека собеса по DevOps

Добавляем второй интерфейс с внешним IP.И чтоб он ещё и работал одновременно со старым./etc/network/interfaces:...auto eth3iface eth3 inet static address 1.2.3.0/24 gateway 1.2.3.1 up grep -q "^200 isp2" /etc/iproute2/rt_tables || echo "200 isp2" >> /etc/iproute2/rt_tables up ip route add 1.2.3.0/24 dev eth3 table isp2 up ip route add default via 1.2.3.1 dev eth3 table isp2 up ip rule add from 1.2.3.11 table isp2...#linux #route #pbr #rule

Я тут готовлю статью по теме прокси выше, пару команд уточнил заодно.Sing-box ставится теперь попроще, в частности:sudo mkdir -p /etc/apt/keyringssudo curl -fsSL https://sing-box.app/gpg.key -o /etc/apt/keyrings/sagernet.ascsudo chmod a+r /etc/apt/keyrings/sagernet.ascИ затемecho 'Types: debURIs: https://deb.sagernet.org/Suites: *Components: *Enabled: yesSigned-By: /etc/apt/keyrings/sagernet.asc' | sudo tee /etc/apt/sources.list.d/sagernet.sourcesПотом ставимsudo apt updatesudo apt install sing-box -yИ для unbound symlink для резволвера можно сделать такsudo rm /etc/resolv.conf sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf(это самая последняя команда в блоке unbound)Ещё возник вопрос, нафига вообще морочится с этими unbound, если можно ломиться в гугл или cloudflare. Ответ - можно, конечно. Там можно заодно настроить dns over tls, к примеру. Но в этом случае мы отдаём на откуп резолв этим организациям, то есть как бы "доверяем" им и ожидаем, что они всё правильно зарезолвят.Мы же делаем схему "сам себе велосипед", то есть ломимся напрямую к корневым серверам, кэшируем всё у себя и тп. Но тогда dns over tls особо не настроить, тк (если я не ошибаюсь) глобально его поддержки ещё нет. Впрочем, я не думаю, что dot в данном случае необходим, гораздо важнее, чтобы клиент правильно делал резолв и не пытался что-то резолвить в обход прокси

🛠️ Uncloud — лёгкий кластерный инструмент для управления контейнеризированными приложениями через сеть Docker-хостов. Это мост между Docker и Kubernetes — без их сложности.🚀 Ключевые возможности- Децентрализованный кластер без единой точки управления — каждый узел хранит синхронное состояние - WireGuard mesh — приватная сеть между хостами без лишней настройки - Автоматическое обнаружение сервисов и балансировка с TLS через встроенный Caddy - Знакомый Docker Compose — можно запускать привычные compose.yaml, без новой DSL - Zero-downtime deploy — rolling-обновления и автоматический откат (в разработке)🌍 Где использовать- Облачные VM, bare-metal, гибридные кластеры - Для разработчиков и self-hosting — альтернатива Kubernetes - Домашние лаборатории — развёртывание на spare-хостах без усилий⚡ Почему Uncloud?- Убирает большую часть боли Kubernetes и Docker Swarm - Предоставляет понятную и лёгкую инфраструктуру - Даёт мощь multi-host окружения без операционных сложностейhttps://github.com/psviderski/uncloud👣 Полезные ресурсы Go 🚀Max@golang_interview

Геозоны, парковка и штрафстоянки: как настроить правила каршеринга и снизить нагрузку на операторов 🅿️На старте сценарий в каршеринге выглядит просто: автомобиль, координаты на карте и базовый статус. Но по мере роста сервиса логика усложняется: появляются разрешённые и запрещённые зоны завершения аренды, платные парковки, служебные территории, штрафстоянки и разные городские ограничения.Чтобы такие процессы не требовали постоянной ручной проверки, важна правильная модель управления:▪️ Подход к настройке— геозоны как отдельные сущности с разными типами и правилами;— события входа, выхода и превышения допустимого времени;— статусы автомобилей и автоматические переходы между ними;— централизованное управление логикой через платформу.Такой подход позволяет автоматизировать контроль парковочных сценариев в каршеринге, снизить нагрузку на операторов и быстрее масштабировать сервис без роста ручной модерации.В Rightech подобные кейсы настраиваются через события и правила платформы: можно ограничивать завершение аренды вне разрешённой зоны, фиксировать длительное нахождение автомобиля без движения или автоматически переводить объект в статус штрафстоянки.Мы также помогаем запускать каршеринг-сервисы под ключ: от подключения устройств и настройки геозон до реализации бизнес-логики, биллинга и диспетчерского интерфейса.👉🏻 Оставить заявку на сайте #ric_about_iot

📌 На MITT-2026 Cosmos Hotel Group и «Ростелеком» объявили о стратегическом сотрудничестве в области цифровизации гостиничного бизнеса. Речь идёт не просто о телеком-услугах, а о более глубокой интеграции технологий в операционную модель отелей.Первым шагом станет участие CHG в тестировании платформы «Цифровой отель», которую разрабатывает «Ростелеком». Это комплексная система для автоматизации гостиницы: управление инфраструктурой, облачные сервисы хранения данных, аналитика, резервное копирование и решения по информационной безопасности — всё в едином цифровом контуре.Параллельно «Ростелеком» окажет содействие в развитии телеком-инфраструктуры семейства CHG: построении внутренних сетей и подключении к современным каналам связи. Отели семейства станут площадкой для тестирования новых сервисов — в том числе решений на базе ИИ и других инструментов цифровой аналитики.Для CHG эта история напрямую связана с масштабом роста. За последние два года оператор открыл 11 новых отелей, ещё около 60 проектов находятся в разных стадиях реализации до 2030 года. При такой динамике цифровая платформа становится не вспомогательной функцией, а базовым инструментом управления.Если смотреть шире, подобные проекты постепенно формируют новую технологическую инфраструктуру отрасли. Российский гостиничный рынок растёт быстрее, чем появляются системные ИТ-решения для управления крупными гостиничными структурами. Поэтому эксперименты с платформами уровня «цифрового отеля» сегодня становятся важным полигоном для всей индустрии. Следим.🛎 Ночной портье в Telegram | в MAX

Как кубер и докер дебажить???Ладно, выдеру кусок из будущего сезона LF, s4e18 пусть побудет публичным, ради тебя ничего не жалко.ㅤ…Чуть раньше я уже писал подобный пост для докера «основные методы отладки», но там освещены не все моменты.Зачастую используются «тулбоксы», это такие специальные docker контейнеры, которые содержат в себе все самые необходимые утилиты для этого самого дебага. Такие «тулбоксы» можно делать самостоятельно, а можно воспользоваться готовыми.Один из самых популярных, это netshoot, в него включено свыше 50ти консольных утилит на все случаи жизни. Основной упор сделан на диагностику сетевой хуйни.Например:kubectl run netshoot --rm -it --image=nicolaka/netshootТеперь можно выполнить:dig service.bashdays.svc.cluster.local curl http://service:8080Или зайти в network namespace pod:kubectl debug pod/myapp -it --image=nicolaka/netshootКороче если какой-то сервис не работает, запускается netshoot делается DNS проверка dig service, проверка TCP nc service 5432, смотрим пакеты tcpdump -i any port 5432 и т.п.Довольная удобная штука, ничего выдумывать не нужно. Аналогично создаются другие «тулбоксы» со своим содержимым и утилитами.У каждого уважающего себя девопс-инженера, должен быть такой image под рукой, рано или поздно он обязательно пригодится и сослужит службу.Самое важное здесь, разместить этот образ на РФ серверах, чтобы рядышком был и никакие блокировки бы его не касались. Да и тот же `netshoot` желательно к себе утащить в норку.Чем еще подебажить:- k8s-toolbox- Busybox- dnsutils- Network MultitoolА в новых версиях куба активно используют Ephemeral containers, как раз тот самый kubectl debug. Можно внедрить debug container прямо в pod.Кстати «тулбоксы» можно использовать не только в кубере, они отлично ложатся на обычный докер, опять-же сеть потыкать, покурлить и помяукать. Так что если у тебя нет куба, похуй, пригодится и для обычного докера.Ну а теперь давай создадим искусственную проблему и попытаемся её диагностировать с помощью этих самых «тулбоксов».….На этом всё, изучай!🛠 #devops #debug #docker #k8s—💬 Bashdays 📲 MAX 🌐 LF 🔵 Blog

Жиза №973Был у меня проект, где заказчик решил максимально сэкономить и втихую подрезал бюджет на инфраструктуру. Мы настроили нормальный кластер с репликацией базы, а он посмотрел на счета и решил, что это лишние траты.В итоге он сам зашел в консоль облака и снес якобы лишнюю реплику. Оставил базу на одном единственном инстансе. Заодно и автоматические бэкапы отключил, мол, мы и так раз в неделю руками сохраняем. Сэкономил баксов двести в месяц.Через неделю у провайдера случается какой-то технический затык. У всех, кто сидел с репликами в разных зонах, все переключилось автоматически и незаметно. А наш одиночный инстанс просто не поднялся. Диск посыпался при перезагрузке.Этот экономист звонил мне в субботу вечером чуть ли не в слезах, потому что проект лежит, заказы не идут, а восстанавливать не из чего. Мы трое суток всей командой по кускам собирали базу из каких-то старых дампов и логов транзакций, которые чудом не затерлись.Стоимость наших овертаймов в те выходные в десять раз превысила ту экономию, которую он выгадал. Зато больше он со мной вообще ни на одну тему не спорил.______________Поделиться своей историей — @zhizaIT_bot

Blameless culture: как перестать искать виноватых и начать чинить системыНа этой неделе обзора книги не будет, потому что я ещё не успел её дочитать (там почти 600 страниц по AI-инженерии, не самое лёгкое чтиво). Поэтому я решил поделиться подборкой материалов, которые накопал в своём недавнем рабочем процессе.Передо мной стояла задача — запустить процесс Post Mortem. Для этого нужно было собрать небольшой гайд и шаблон, чтобы коллегам было проще стартовать. Для этого я прочитал и просмотрел кучу материалов. Делюсь теми, которые показались мне самыми полезными.⭐️ Blameless culture. Как правильно работать с инцидентами / Андрей СиницынОчень хороший, добрый и местами пропитанный личной болью доклад моего дружочка-пирожочка Андрея. Послушать стоит, потому что этот человек ворочал огромными и крайне сложными инфраструктурами, в которых всегда что-то ломается.Доклад не про сами post mortem, а про безобвинительную культуру, которая является фундаментом. Если на post mortem искать виноватых и раздавать наказания, то работать они не будут никогда.➡️ Интересные идеи🟡В больших системах всегда что-то ломается. Это их суть: сложные распределённые системы не могут работать без ошибок, и это нормально. Post Mortem нужны для того, чтобы больше узнавать о своей системе и делать её надёжнее.🟡Виноваты процессы, а не люди. Если человек (даже сознательно) смог что-то критически сломать — это процессная проблема. Но чаще всего сбой вызывается непреднамеренным действием и раскрывает одно из слабых мест системы. Поэтому ругать людей бесполезно.🟡Action Items с post mortem пробивают все бэклоги и имеют критический приоритет. Для команды инфраструктуры, от которой зависит целый огромный бизнес, такой подход — норма. Для обычных команд разработки некоторые action items могут быть менее приоритетными. Тем не менее кто-то должен следить за тем, чтобы они были выполнены.⭐️ How to run a great incident post-mortemHow-to по blameless culture — отличное продолжение предыдущего доклада. Автор по сути даёт простой фреймворк обсуждения на post mortem без поиска виноватых и взаимных обвинений.Мне понравился подход «второй истории»: сначала говорим про очевидные ошибки, а потом закапываемся в системные штуки, которые эту ошибку допустили. Это позволяет копать глубже, чем просто «давайте ещё один алерт повесим».⭐️ Postmortem Culture: Learning from FailureШикарная статья от Google о их философии проведения post mortem. В ней чётко видно, что организация использует post mortem для исправления ошибок и взаимного обучения (например, есть рубрика «post mortem месяца», в которой раз в месяц хорошо написанный документ распространяется на всю организацию).Статья скорее предназначена для формирования правильного отношения к post mortem. Тем не менее она будет очень полезна на старте и даёт пачку классных идей для дальнейшего развития культуры.Также у Google есть отличный пример post mortem.⭐️ Incident postmortemsВ целом handbook по управлению инцидентами от Atlassian очень крут, и в нём много чего полезного. Конкретно эта статья — прекрасная методичка того, как проводить post mortem. Она даёт ответы на конкретные вопросы: кто, что, где, как и так далее. В том числе в ней содержится довольно хороший (хоть и объёмный) шаблон post mortem, который можно использовать в своих проектах.Для меня были особенно ценны примеры проведения анализа корневых причин инцидента. Atlassian используют метод «5 почему», и, судя по всему, он им помогает.Всем желаю blameless post mortem и стабильных систем!// Поделитесь, пожалуйста, в комментариях, как вам такой формат?

💥 Удары по дата-центрам AWS ставят под угрозу стабильность мирового трафикаИнфраструктура Amazon Web Services на Ближнем Востоке подверглась атаке иранских беспилотников. Под прямой удар попали два объекта в ОАЭ, еще один дата-центр в Бахрейне получил повреждения из-за взрыва поблизости.Масштаб проблемы подтверждается официальным отчетом AWS: на объектах зафиксированы разрушения конструкций, перебои с питанием и затопления из-за работы систем пожаротушения.На данный момент работа сервисов в регионе остается нестабильной. Клиенты сталкиваются с критическими ошибками и падением доступности ресурсов.⚠️ Для сегмента медиабайинга, завязанного на облачных решениях Amazon, это означает риск внезапной потери доступа к кастомным трекерам, лендингам и базам данных. ℹ️ AFFY — твой GPS в мире арбитража трафика

🐳 Полезный, но не банальный приём для DockerMulti-stage build для лёгких и безопасных образовЕсли нужно собрать бинарник и получить чистый минимальный образ, не таская за собой компиляторы и зависимости:FROM golang:1.22 AS builderWORKDIR /srcCOPY . .RUN go build -o app .FROM gcr.io/distroless/baseCOPY --from=builder /src/app /appENTRYPOINT ["/app"]💡 Что это даёт- На первом этапе (builder) ты собираешь приложение в полном окружении.- На втором - получаешь только бинарник, никаких инструментов сборки.- Образ становится в 10–20 раз меньше и гораздо безопаснее.Идеально подходит для деплоя в Kubernetes, CI/CD и serverless-окружениях.📦 Запускdocker build -t myapp .docker run --rm myapp🔥 Работает не только для Go, но и для Python/Node — достаточно перенести идею: собрать → очистить → упаковать минимально.

🎮 Способы распила монолита на микросервисыПравило:Нельзя резать, не определив границы. Начинать нужно с бизнес-логики и данных, а не с кодаКачественный сервис после распила обладает:💙слабой зависимостью (loose coupling) — изменения не ломают соседей💙высокой внутренней связностью (high cohesion) — сервис решает одну бизнес-задачу Стратегии💙 Декомпозиция по бизнес-доменамОснована на Domain-Driven Design💙Каждый сервис = один Bounded Context: собственная логика и данные💙Границы определяются бизнес-процессами, а не слоями кода💙 Пошаговый переход1. Анализ предметной области, выделение контекстов Например, где заканчивается работа склада и начинается работа логистики2. Определить владельцев данных. Н-р, какие таблицы в монолитной БД принадлежат какому контексту3. Запретить прямой доступ к «чужим» таблицам4. Выделить API5. Отдельный деплой💙 ПримерКаталог (товары, цены) и "Заказы" (корзина, оформление). Их можно разделятьЗаказы хранят цену на момент покупки и не зависят от текущей цены каталога❤️Не применять♥️плохо формализован домен и нет четких бизнес-процессов♥️ нет владельца продукта♥️ часто меняющиеся границы (MVP)💙 Strangler FigБезопасный способ рефакторинга "на ходу", когда монолит нельзя останавливать💙Перед монолитом ставится маршрутизатор: API Gateway или обратный прокси (nginx, HAProxy)💙Новая функциональность создаётся в микросервисах, старая постепенно удаляется.💙 Пошаговый переход1. Выбрать изолированный use-case2. Реализовать его как сервис3. Настроить маршрутизацию4. Переключить трафик5. Удалить старую реализацию💙 ПримерЛичный кабинет переносится по частям: сначала профиль, затем смена пароля, затем всё остальное. Монолит постепенно очищается❤️Не подходит♥️если нужен быстрый полный переход♥️ монолит невозможно маршрутизировать💙 Декомпозиция по данным (Database per Service)Не самостоятельная стратегия, а обязательное условие микросервисовКаждый сервис владеет собственной БД. Общих таблиц нет. Доступ к данным — только через APIПодходы💙разные схемы в одной СУБД💙физически отдельные БД💙копии данных + события💙Event-driven синхронизация💙 Пошаговый переход1. Определить владельца таблиц2. Запретить cross-schema JOIN3. Выделить БД4. Перевести взаимодействие через API5. Настроить события при необходимостиПримерOrder Service получает собственную БД. Остальные сервисы работают с заказами только через API❤️Не применять♥️требуются жёсткие распределённые транзакции♥️нет инфраструктуры событий 💙 Декомпозиция по нагрузке (Performance-driven)Выносится компонент, создающий нагрузку💙 Пошаговый переход1. Найти узкое место (метрики, профилирование)2. Выделить код3. Перевести в асинхронный режим4. Добавить кэширование💙 ПримерПоиск товаров выносится в сервис с собственным Elasticsearch и масштабируется отдельно ❤️Не применять ♥️если проблема в плохом SQL, а не в архитектуре ♥️нагрузка не критична💙 Декомпозиция по частоте измененийВыносится модуль, который меняется чаще остальных, чтобы ускорить релизы💙 Пошаговый переход1. Анализ истории коммитов2. Выделение часто меняющегося модуля3. Отделение данных4. API и независимый деплой💙 ПримерБлок Акции и предложения обновляется ежедневно. Его вынос позволяет деплоить изменения без затрагивания ядра системы❤️ Не применятьЧастые изменения вызваны хаосом требований📎 Материалы1. Шпаргалка по миграции монолита на микросервисы 2. Когда и как переходить с монолита на микросервисы. Предпосылки и общие понятия 3. Архитектура микросервисов: Разрушение монолита4. Как НЕ надо распиливать монолит 5. Микросервисная архитектура: от монолита к гибкой системе 📚 КнигиСэм Ньюмен - Создание микросервисов#архитектура➿➿➿➿➿➿➿➿🧑‍🎓 Больше полезного в базе знаний по системному анализу

Перспектива ЦОДов в Москве.Я вот чего думаю.Имеем:1. Механизм "бери-или-плати" на электричество, который пытаются продвигать энергетики. 2. Запрет на включение ЦОДов в Москве и области из-за исчерпания электрических мощностей.3. Активная замена промзон на жильё - заканчиваются возможности строительства новых ЦОДов зданиях старых пром.предприятий (удорожание из-за необходимости нового строительства).При этом:- единый реестр дата-центров Российской ФедерацииА теперь следите за руками:1. Дефицит ЦОДов есть уже сегодня.2. Новые ЦОДы в Московском регионе строить чем дальше, тем сложнее.3. Ещё бОльшее увеличение дефицита.4. Усиление регулирования отрасли ЦОД через реестр и СОРМ.Ну вот я прям вангую, что следующий шаг - это обязательство для ЦОДов из реестра размещать серверное оборудование разного рода ФГУПов и других гос.организаций. Причем не просто размещение, а по спущенному сверху фиксированному тарифу.Вот куда-то туда идём.

Amazon переводит стрелки с AI на людейУ Amazon за последнее время произошло несколько крупных падений, и как минимум в одном из них точно был замешан AI. Разработчик случайно оказался в продовом окружении вместо тестового, Kiro дернул команду не с теми флагами, и один из сервисов после этого лег. AWS во всех пресс-релизах после этого пытается всячески уйти от ассоциаций с AI, и говорит о том, что это человеческая ошибка – а в интернете на это смотрят как на попытку защищать AI.С моей точки зрения AWS все правильно делает. Проблема не в том, что AI дернул не ту команду, а в том, как выстроены процессы разработки и гардрейлы вокруг него. Как вообще разработчик случайно оказался в проде и смог что-то там поменять? Почему команда с такими сайд-эффектами была вызвана без одобрения? Все это выглядит, как провалы в тулинге, и вообще не важно, детерменистическая или вероятностная система там под капотом.

Что означает RPO?👾 — Максимально допустимая длительность простоя👍 — Цель по времени восстановления сервиса🥰 — Максимально допустимая потеря данных во времени⚡️ — Среднее время до отказаБиблиотека задач по Python

Меня в таких историях https://blog.zwindler.fr/en/2026/02/26/kyverno-killed-my-api-server.-again./ интересует вот что: многие компании разделяют администрирование кластеров Kubernetes по компонентам - условно, Kyverno и Cilium NetworkPolicy за ИБ-командой, control plane и CNI за кубовыми админами, CSI за командой хранилищ.Как они траблшутят в момент обновления кластера, когда что-то идёт не так? Насколько дольше растягивается инцидент из-за такого разделения? Мол ИБ-команда говорит "наш Kyverno работает штатно", кубовые админы говорят "апи-сервер падает из вебхука в Kyverno". И главное - бывало ли так, что после инцидента кто-то описывал постмортеме "так жить тяжело, надо менять подход"?Спрашивал об этом людей на конференциях - внятного ответа так и не получил.