Знаете ли вы, как сочетать Terraform и Chaos Engineering для анализа устойчивости инфраструктуры?

Подход “инфраструктуры как кода” дает надежные механизмы автоматизации, но гарантии реальной отказоустойчивости появляются только после проверки системы под неожиданными сбоями и хаосными событиями. Автоматизированный деплой средствами Terraform — это база, а устойчивость к реальным отказам требует симуляции “аварий” и анализа процессов самовосстановления.

Внедрение хаотического тестирования для облачных инфраструктур как AWS

Когда инфраструктура на AWS развернута через Terraform и управляется autoscaling group, можно предположить, что резервы устойчивости уже реализованы за счет автоматического масштабирования и перезапусков. Тем не менее, без моделирования реальных сбоев сложно сказать, насколько быстро и корректно восстанавливается сервис под нагрузкой или во время отсутствия одного из ресурсов.

Вот базовый пример Terraform-конфигурации для группы приложений на EC2:

resource "aws_launch_configuration" "app_lc" {
  image_id        = "ami-0c55b159cbfafe1f0"
  instance_type   = "t2.micro"
  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group" "app_asg" {
  launch_configuration = aws_launch_configuration.app_lc.id
  min_size             = 2
  max_size             = 10
  desired_capacity     = 5
  tag {
    key                 = "Name"
    value               = "AppServer"
    propagate_at_launch = true
  }
  health_check_type        = "EC2"
  health_check_grace_period = 60
}

Автоматизация запуска и поддержки пяти инстансов выглядит рабочей конфигурацией. Но готова ли система действительно к хаосу? Чтобы проверить это, можно задействовать Chaos Monkey или иной инструмент для случайных остановок или завершения инстансов прямо внутри указанной ASG. Пример вызова для “убийства” случайного сервера:

chaos-monkey --app AppServer --instance-type t2.micro --duration 30s

Такой сценарий воспроизведет внезапный отказ в реальном времени. Дальнейшее поведение наблюдаем через метрики: ASG практически сразу запустит новый инстанс, чтобы поддерживать необходимый desiredcapacity. Но чтобы сделать вывод об устойчивости, обязательно фиксируйте время до полного восстановления сервиса (вплоть до прохождения всех health-check и включения в балансировщик) и сопоставьте с логами группы и приложений.

Тонкости на практике: что смотреть после теста?

- Важно мониторить не только момент появления нового EC2, но и скорость его регистрации во всех жизненно важных компонентах (LB, сервис-дискавери и др).
- Если неправильно заданы параметры healthcheckgraceperiod, scale-in или scale-out, система может либо не среагировать на сбой вовремя, либо потерять часть ресурсов под нагрузкой.
- Обязательно проверьте, что lifecycle hooks корректно отрабатывают: иногда задержки в shutdown могут тормозить быстрое восстановление.

Добавьте интеграцию с Telegram-ботом — моментальные нотификации о рестарте инстансов позволят ловить аномалии не только по метрикам, а и по необычным сценариям (например, если один инстанс постоянно уходит в unhealthy без явных причин).

Такой подход позволяет удостовериться, что код инфраструктуры не только развернут “по спецификации”, но и готов к реальным непредсказуемым событиям: проверена реакция на аварии, скорость восстановления и корректность триггеров автоскейлинга. Чем лучше симулированы настоящие сбои, тем увереннее можно масштабироваться — и тем спокойнее команда поддерживает работу в проде.

Когда один разработчик из dotCloud решил упростить деплой своих Python-приложений, мир еще не знал, что через пять лет контейнеры станут стандартом индустрии.

В 2013-м Docker появился как обертка над LXC – технологией, которую мало кто понимал и еще меньше использовал. Соломон Хайкс показал демо на PyCon, где приложение запускалось одной командой на любой машине. Магия была в том, что контейнер нес с собой все зависимости, от библиотек до переменных окружения.

docker run -d -p 80:80 nginx

Эта строчка делала то, на что раньше уходили часы настройки. Netflix быстро подхватили идею – их микросервисная архитектура требовала быстрого масштабирования. Google молча усмехнулся – у них уже десять лет работал Borg, но никто об этом не знал.

К 2014-му стало ясно, что один контейнер – это игрушка. Нужна оркестрация. Docker Swarm появился как встроенное решение, но был слишком простым. Kubernetes вышел из недр Google как открытая версия Borg, со всей сложностью enterprise-систем. Mesos пытался конкурировать, предлагая универсальную платформу для любых задач.

Банки начали экспериментировать с контейнерами для изоляции торговых алгоритмов. Каждый алгоритм жил в своем контейнере с четко определенными ресурсами – CPU, память, сетевые лимиты. Это решало проблему "соседей", когда один агрессивный алгоритм мог положить всю систему.

В 2015-м произошел раскол экосистемы. Docker Inc. хотела монетизировать платформу, добавляя enterprise-фичи в Docker Engine. Сообщество забеспокоилось о vendor lock-in. Появился Open Container Initiative – попытка стандартизировать формат контейнеров и runtime.

Kubernetes тем временем набирал обороты. Red Hat делала ставку на него в OpenShift, Microsoft интегрировала в Azure. К 2017-му стало очевидно – в войне оркестраторов побеждает K8s. Docker Swarm остался нишевым решением, Mesos ушел в специализированные кейсы.

Появление CRI-O и containerd показало, что Docker как runtime становится избыточным. Kubernetes научился работать с любым OCI-совместимым runtime. Docker превратился из платформы в один из инструментов экосистемы.

Финтех-стартапы строили всю инфраструктуру на контейнерах с первого дня. Deployment pipeline выглядел как конвейер: git push → CI собирает образ → registry → K8s разворачивает. Rollback за секунды, blue-green deployment из коробки.

К 2018-му контейнеры стали commodity. AWS запустила Fargate – serverless-контейнеры без управления нодами. Google предложила Cloud Run. Абстракция поднялась на уровень выше – разработчики думали о сервисах, а не о серверах.

Пять лет потребовалось, чтобы превратить "работает на моей машине" из мема в решенную проблему. Контейнеры не просто изменили деплой – они переосмыслили саму архитектуру приложений.

5 инструментов LangChain для MLOps в 2025

LangChain превратился из экспериментального фреймворка в промышленную платформу для разработки LLM-приложений. Экосистема продуктов компании включает несколько ключевых инструментов для полного цикла разработки, мониторинга и развертывания агентов в продакшене.

1. LangSmith для observability

Платформа мониторинга и evaluation LLM-приложений. Автоматически отслеживает стоимость запросов к моделям, синхронизирует промпты с внешними системами через webhook-уведомления. Включает LLM-as-Judge evaluators для автоматической оценки качества и возможность сбора human feedback от экспертов. Особенно полезна для отладки сложных цепочек агентов, где нужно видеть промежуточные шаги и токены. Framework-agnostic - работает не только с LangChain.

2. LangGraph для stateful агентов

Low-level фреймворк для создания контролируемых агентов с поддержкой state management. Поддерживает различные control flows - single agent, multi-agent, hierarchical, sequential. Решает проблему управления состоянием в enterprise-сценариях, где агенты должны помнить контекст между сессиями. Включает built-in checkpointing и возможность human-in-the-loop взаимодействия.

3. LangGraph Platform для managed deployment

Управляемая инфраструктура для развертывания LangGraph приложений. Предлагает one-click deploy, horizontal scaling, APIs для state management и built-in persistence. Доступны разные опции деплоймента: Cloud SaaS, Hybrid (SaaS control plane + self-hosted data plane), и полностью self-hosted решения. Интегрирован с LangSmith для мониторинга производительности.

4. LangGraph Studio IDE

Визуальная среда разработки для создания и отладки агентов. Включает граф-визуализацию workflow, интерактивное выполнение агентов, time-travel debugging. Работает как с локально запущенными агентами через LangGraph Server, так и с деплоями на LangGraph Platform. Поддерживает два режима: Graph mode для детальной отладки и Chat mode для простого тестирования.

5. Enterprise коннекторы и интеграции

Поддержка корпоративных платформ и расширенные memory модули с vector-based памятью. Vector-based memory использует семантический поиск для релевантного извлечения контекста, а summarization memory динамически сжимает длинные диалоги. Более 600 интеграций с различными источниками данных, векторными базами и cloud платформами делают LangChain пригодным для enterprise RAG систем.

В 2000 году Эрик Брюэр бросил бомбу в мир распределенных систем – CAP-теорему, которая разнесла в пух и прах все розовые мечты о совершенных базах данных. Три буквы стали проклятием каждого системного архитектора: Consistency, Availability и Partition tolerance.

Суть жестока, как приговор: можешь выбрать любые два из трех, но никогда – все сразу. Сеть упала? Либо система остается доступной, но данные расходятся по узлам, как пьяные матросы по портам, либо сохраняет согласованность, но умирает для пользователей.

MongoDB и Cassandra танцуют на грани, жертвуя согласованностью ради скорости. PostgreSQL с его синхронной репликацией предпочитает смерть хаосу – лучше упасть, чем врать. Amazon с их DynamoDB выбрал золотую середину eventual consistency: "Данные сойдутся... когда-нибудь".

CAP превратил проектирование систем в русскую рулетку с тремя патронами. Каждое архитектурное решение – компромисс между тремя дьяволами. И самое страшное? В реальном мире сеть всегда может упасть.

Как почистить Docker от мусора без потери данных

Docker со временем забивает диск кешем сборки, старыми образами и неиспользуемыми volumes. Иногда нужно пересобрать контейнер – но при сборке вылезает no space left on device. И если освободить место универсальным способом:

docker system prune -af --volumes

То удалится все подчистую: остановленные контейнеры, неиспользуемые образы, networks, volumes и весь кеш сборки. То есть, можно потерять данные в незапустившемся контейнере, ради которого это все затевалось.

Если нужно аккуратно сократить занятое Докером место, есть три команды, которые удалят только откровенный мусор:

docker builder prune -af
docker image prune -af
docker volume prune -f

Что удаляется:
- Кеш сборки образов
- Неиспользуемые образы
- Volumes, не примонтированные ни к одному контейнеру

Что НЕ удаляется:
- Запущенные контейнеры и их данные
- Образы, используемые любыми контейнерами (даже остановленными)
- Volumes, примонтированные к контейнерам

Если вы как и я используете для генерации кода в основном Claude и начали замечать, что в последнее время он начал слишком долго сидеть над кодом и генерировать кучу ненужного (инструкции, описание проекта, схемы которые никто не просил) – есть простое решение.

Запретите создавать артифакты, весь код строго в код-сниппетах (путь к файлу в чат + исправленное содержимое в код-сниппете). Так генерируется только то, что нужно, без траты времени и токенов.

claude-code-telegram + 🦞 = ??

RichardAtCT/claude-code-telegram
312 звезд, MIT, Python.

Простая утилита, которая дает соединять запущенный на дев-сервере Клауде Код с телеграм-ботом. То есть, пока ты у монитора – можно ставить задачи в нормальном окружении VS Code по SSH, а потом следить и управлять всем просто из телеги на телефоне.

Пока не стал пускать нейронку в свою кодовую базу без плотного присмотра и добрался до OpenClaw. Штука хоть и простая, местами оказалась капризной, особенно если хочется поэксперементировать с ЛЛМ-провайдерами. Но раз на сервере уже бегал Клауде Код, разбираться со всем пришлось ему: конфиги, модели, провайдеры, права файлов, rate limits – все это правится не выходя из чата. Так я и настраивал одного робота другим, из Телеграма, вне чатов пришлось только получить ключ для OpenClaw-бота от @BotFather.

Потенциально, применений для OpenClaw масса – но пока будет работать у меня вместо ручного тестировщика в вебе и поднимать того, второго, если сломается.

APILayer – 408k звезд, MIT, курируемый список

Большая база бесплатных публичных API для учебы или пет-проектов:

- Trace Moe – по скриншоту находит из какого аниме кадр, говорит серию и тайм-код
- Frankfurter – курсы валют от ЕЦБ с историей, без ключа и лимитов
- Open Food Facts – состав, КБЖУ и штрихкоды продуктов со всего мира
- WallstreetBets – sentiment analysis комментариев реддита по акциям
- Chess.com – статистика игроков, история партий, рейтинги
- Mempool – комиссии, состояние мемпула, история транзакций биткоин-сети

И еще почти полторы тысячи вариантов.

Radiant – 50+ шейдеров для веба, MIT

Каждый HTML-файл – отдельный эффект. Черные дыры, рвущаяся бумага, spring-сетки – скопировал, вставил, работает; без npm и зависимостей.

https://radiant-shaders.com/

PowerShell-скрипт для очистки Windows от мусора

Win11Debloat за одну команду в PowerShell убирает предустановленные приложения, телеметрию, Copilot, виджеты, рекламу в настройках.

4.5k строк PowerShell, 71 файл, ноль внешних зависимостей – только reg-файлы для реестра, WinGet для Edge/OneDrive и Remove-AppxPackage для остального.

14 релизов за 3 месяца, issues регулярно закрываются.

Есть Sysprep-режим: Win11Debloat применяет свои настройки к образу Windows для установки на новые машины. Конфиги можно экспортировать и импортировать.

Поддерживается Windows 10 и 11.

Визуальный AI-редактор для Next.js/Tailwind

Onlook – open-source альтернатива Bolt.new/v0/Lovable.

25k звезд, 1.6k коммитов, Apache-2.0. Монорепо на Bun 1.3.1, стек create-t3-app: Next.js App Router + Drizzle + tRPC + Tailwind. Бэкенд – Supabase, пользовательские проекты исполняются в CodeSandbox. Раньше был Electron-приложением, в 2025 переехал в веб.

Для self-host нужны 4+ CPU, 8GB RAM (рекомендуется 16GB), 50GB диска, локальный Supabase, и ключи от OpenRouter и CodeSandbox. Плюс еще с десяток опциональных интеграций.

В коде две критических уязвимости – удаленное выполнение кода и SSRF в axios 1.12.2 (тот самый HTTP-клиент, который торчит в половине npm-проектов). Плюс SQL-инъекция в Drizzle ORM 0.44.7 и подделка JWT-токенов в hono 4.10.2, и кроме них, еще несколько помельче. Хороший кандидат для PR в большой опенсорс – с февраля в мастер-ветке не было новых коммитов.

За годы запусков продуктов и работы с нетехническими фаундерами, я заметил повторяющиеся факторы, которые из раза в раз срывают выход на рынок. И, как ни парадоксально, половина из них связана с ИИ.

Представьте, что пока вы работаете над фичей или фиксом, ваш нетехнический партнер или заказчик из лучших побуждений проработал эту проблему, общаясь с нейронкой, и теперь предлагает вам почитать трехчасовой лог своего общения с ChatGPT, потому что "кажется, там что-то важное". Какие еще проблемы возникают и что с этим можно делать – я расписал в статье на Хабре.

https://habr.com/ru/articles/1028284/

Шел 2020 год когда Cellebrite – израильская компания, занимающаяся цифровым шпионажем, громко заявила, что способна вскрыть Signal – якобы самый защищенный мессенджер в мире. Их инструменты покупают спецслужбы всего мира, от ФБР до ФСБ, и используют против всех, кого нужно – от собственных журналистов до громких несогласных. Создатель Signal – также известный как Мокси Марлинспайк (настоящее имя) – прочитал это заявление и решил разобраться в ситуации своими силами.

Через несколько месяцев он опубликовал пост, сразу ставший легендарным. По его словам, он просто шел по улице, когда с проезжавшего грузовика упала небольшая коробка; внутри оказался полный комплект для вскрытия телефонов той самой компании. Мокси забрал находку домой, разобрал и тщательно изучил их софт.

То, что он обнаружил, выглядело удручающе: старый код, слабая защита и куча дыр. Любое приложение на телефоне могло подкинуть вредоносный файл, который в момент сканирования полностью захватывал их машину. Мокси опубликовал эксплойты в открытом доступе и Cellebrite быстро убрала Signal из списка поддерживаемых приложений, а ее акции ощутимо просели.

Никогда не оставляйте ваше шпионское оборудование лежать на улице без присмотра.

Питер Штайнбергер – автор OpenClaw, заполонившего интернет ботами-суетологами, для которых в конце прошлого года весь соло-фаундер-твиттер скупал МакМини. Кто-то из этих 🦞 наверняка стучался своими тентаклями к вам в телеграм и пытался что-то продать.

Совсем недавно Штайнбергера купили в OpenAI – делать уже закрытых агентов с клешнями. OpenClaw при этом продолжил жить своей жизнью в опенсорсе, отдельно от создателя, а сам Штайнбергер написал об этом прощальный пост, в котором рассказал, что это было его условием для перехода под крыло Альтмана.

Но за пару месяцев до этого поста он сделал другой интересный текст. "Shipping at Inference-Speed " – о том, почему он практически перестал обращать внимание на код, который пишут агенты, как на код, – и, по сути, стал фокусироваться на результатах, которые кодинг-агенты доставляют. Сами подходы, описанные в статье, сейчас не вызывают уже особого интереса – за почти полгода с выхода того текста часть стала мейнстримом, часть не выжила, оказавшись глупостью.

Интересно то, что в тексте сам он сравнивает, как все изменилось с современного вида Codex'ом и Клауде Кодом по сравнению с маем прошлого года. И интересно именно с ретроспективной точки зрения посмотреть на прошедший год – как с самописных поделок для генерации кода все перешли к корпоративным инструментам по подписке. Я прочитал и перевел его текст, самые интересные замечания на данный момент:

- "Я не читаю код. Я смотрю, как он стримится" – главный тезис поста и, наверное, новая норма для всех, кто хоть раз дал агенту сделать что-то серьезное. Если все при этом нормально покрыто тестами, то это даже безопасно.

- "Коммичу прямо в мастер" – сомнительно, но когда работаешь один, это выходит само собой. Плохая практика из прошлого вернулась с автоматизацией процесса, только с агентом это нормально работает. В командах такое не пройдет, естественно, – и об этом он сам честно пишет.

- "Стек важнее архитектуры" – это, конечно, полная ерунда. Про стек все верно – без правильно подобранного набора инструментов даже современный агент на сложном проекте начнет захлебываться в собственной тупости. Но с инженерной точки зрения не проектировать то, что собираешься делать – такое же самоубийство, как кривой стек. Сам автор при этом замечает, что не делает все сразу, а тестирует модели для работы с данными через CLI, и только потом делает к ним фронт – какое-никакое проектирование.

Процесс разработки софта, хоть и изменился местами до неузнаваемости, пренебрегать проектированием и тестами лучше не надо.