AI атакует open source фейковыми запросами 🤥

История про то как ИИ может выступать в роли помощника в open source проектах и все зафакапать: https://thenewstack.io/ai-is-spamming-open-source-repos-with-fake-issues/. Такой идеальный стажер, который всё делает сам: чинит баги, оптимизирует код и приносит утренний кофе. Казалось бы, звучит прекрасно но в реальности все как всегда оказалась гораздо хуже.

Открываешь репозиторий — а там спам-фест 📧

Давайте перенесёмся в реальный мир. Jarek Potiuk, мейнтейнер Apache Airflow, однажды обнаружил, что количество открытых запросов внезапно подскочило с привычных 20-25 до целых 50 в день. “Отлично!” — подумал он сначала. А потом начал читать эти запросы и понял, что это не взрыв популярности проекта, а просто взрыв бессмыслицы.

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

Кто за этим стоит? 🥸

Виновником неожиданно стала платформа Outlier AI, которая обучает людей и ИИ взаимодействовать с open source проектами. Казалось бы, благая идея, но пользователи решили тестировать свои “навыки” не на локальных данных, а на реальных репозиториях. В результате — ни пользы, ни веселья.

Outlier уверяет, что это было недоразумение и инструкции уже изменили. Ну да, конечно. А как быть с потраченным временем мейнтейнеров?


Что делать? 🫥

Если вы мейнтейнер, то надо сделать так:
- Настройть фильтры для входящих запросов. Даже простой скрипт может отсечь значительную часть спама.
- Сообщить о подобных случаях GitHub. Чем больше мы об этом говорим, тем быстрее появятся решения.
- Помнить, что ИИ — всего лишь инструмент. Пока он больше похож на нуб-стажера, который искренне старается, но всё время что-то путает.

Не забываем про здравый смысл и немного скепсиса. Возможно, когда-нибудь ИИ действительно станет помощником.

Chainguard

Нашел прикольную вещь Chainguard - https://www.chainguard.dev. DevOps и SRE инженерам уже прожужжали все уши про CVE в контейнерах. Они буквально напичканы CVE (уязвимостями). Вообще, CVE — это система, которая предоставляет общепринятые (обществом секьюрити) идентификаторы для уязвимостей в программном обеспечении и системах. Это как если бы вы купили новую машину, а в комплекте шли бы ржавые тормоза 🪓 — вы знаете, что что-то нужно чинить, но откуда начинать? Так вот Chainguard предложила свой подход в решение данной проблемы

Почему бы просто не начать с чистого листа? 🧼

Типичная проблема докер образов заключается в том, что они строятся на основе полных операционных систем. Вместо того чтобы включать только необходимые зависимости, в образах часто остаются ненужные и уязвимые компоненты. Это как если бы вы заказали пиццу, а вам привезли еще и весь холодильник, полный просроченных продуктов.

Chainguard решила пойти другим путем: вместо того чтобы брать готовый образ и вырезать из него ненужное, они начинают с пустого контейнера и добавляют только то, что действительно необходимо. Например, для Python-образа они добавляют минимальный набор зависимостей, чтобы язык работал, — и ничего лишнего. Такой подход позволяет не только уменьшить размеры контейнеров, но и, что самое главное, избавиться от CVE.

Wolfi: их свой Линупс 🐺

В основе подхода Chainguard лежит их собственная Linux дистриб под названием Wolfi — точнее, даже "не-дистриб". Это минималистичная, специально созданная операционная система, которая изначально проектировалась с учетом безопасности CI/CD. Ее цель — быть настолько чистой и безопасной, чтобы вы могли сосредоточиться на разработке, а не на патчинге.

Визуализация CVE: цифры говорят за себя 📊

Недавно Chainguard представила новую фичу для своей консоли — визуализацию CVE. Теперь компании могут видеть, сколько уязвимостей было устранено в их контейнерах за время использования Chainguard, и, что не менее важно, сколько времени их команды сэкономили, не занимаясь этим вручную.

По-моему выглядит круто, хотя бы для внутреннего обоснования бюджета. Представьте, что вы можете показать своему руководству график: "Вот, сколько часов работы мы сэкономили благодаря Chainguard, и вот, сколько денег это сэкономило компании". Это не только помогает защитить выбор технологии, но и укрепляет доверие к принятым решениям.

Почему мы вообще это терпим? 🤡

Вопрос, который задает Chainguard, звучит почти философски: почему мы смирились с тем, что в ПО всегда будут уязвимости? В мире физической безопасности, например, никто не станет продавать вам еду с пометкой "может содержать смертельные бактерии, но вы же все равно их сварите". Так почему в IT мы принимаем это как норму?

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

Что дальше? 📡

Chainguard уже предлагает более 1200 CVE-чистых образов, и их число растет. Кроме того, компания расширяет свои решения на работу с AI и LLM, что делает их подход еще более актуальным.

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

Telemetry, agents, collectors: observability термины которые гоняют на DevOPS интревью 📡

Раньше как было - выбор стека observability был почти бинарным решением - либо выбираешь готового вендора, либо уходишь с головой в open source. Третьего не дано. Но времена меняются, и стандарты вроде OpenTelemetry и Prometheus стерли эти границы. Теперь можно смешивать вендорские решения с open source, создавая свой идеальный стек.

Звучит круто? Но есть и обратная сторона медали: термины в обсервабилити используются как попадется. Когда даже эксперты не могут сойтись на едином определении APM (Application Performance Monitoring), как тут быть новичкам? Даже после десяти лет работы в этой сфере я порой ловлю себя на мысли, что мои мозги вот-вот взорвутся от очередной волны новых терминов.

Возьмем, к примеру, telemetry pipelines. Когда я впервые услышал этот термин, вопросов было больше, чем ответов. Это продукт? Категория инструментов?
Telemetry pipeline — это система, которая собирает, обрабатывает и перенаправляет телеметрию (логи, метрики, трейсы) из разных источников в разные инструменты анализа. Вместо того чтобы управлять отдельными агентами или коллекторами для каждого сигнала, пайплайн объединяет все это в единую маршрутизацию.

А что тогда агенты и коллекторы? 🤖

Вот тут начинается самое интересное.

- Агенты — это такие почтальоны на местном уровне. Они работают рядом с вашим приложением, собирая данные на самом входе и отправляя их дальше. Обычно они запускаются как сайдкары или на том же хосте, где работает приложение.

- Коллекторы — это что-то вроде регионального сортировочного центра. Они собирают данные от нескольких агентов (или напрямую от приложений) и перенаправляют их в конечный пункт назначения.

- Telemetry pipeline (по-русски не получается) — это уже вся почтовая система целиком. Он не только пересылает данные, но и может их нормализовать, обогащать, фильтровать и динамически маршрутизировать.

Практика: OpenTelemetry и Fluent Bit 📝

На примере OpenTelemetry Collector — это, по сути, telemetry pipeline. Он может действовать как агент (сбор данных на входе) или как шлюз (централизованный хаб обработки данных).
Fluent Bit тоже выполняет функции telemetry pipeline: собирает, обрабатывает и маршрутизирует данные. Но и здесь терминология может запутать. Например, "pipeline" в Fluent Bit может означать как весь инструмент, так и конкретные маршруты внутри него.

Выводы

Да, это только вершина айсберга - каждый вендор и каждая команда интерпретируют слова по-своему. Но понимая общие принципы, вы сможете не только разобраться в терминах, но и построить telemetry pipeline, который будет работать именно для нужд вашей компании.

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

Голова лишняя? Добро пожаловать в мир headless observability!
Observability это всегда ТБ логов которые ежедневно плодятся. А их хранение и анализ стоят очень дорого. Плюс, если добавить к этому vendor lock, то хочется порой отказаться от этой observability. Тут подоспело решение - headless observability. Обсудим.

Что за зверь такой — headless observability?

Если коротко, это подход, который разделяет фронтенд (визуализация, запросы, аналитика) и бэкенд (хранение и обработка данных). На выходе - гибкость и возможность использовать данные для разных задач (например, для аналитики или ML) и плюс неплохая экономия. Это как лего для логов: можно собрать свою идеальную систему из отдельных блоков, а не покупать монолитный набор, где половина деталей будет не нужна.
Потом можно использовать разные инструменты для анализа собранных данных: от Grafana до специализированных BI-систем. Можно подключить свою команду по кибербезопасности, можно проанализировать данные для маркетинга. Всё это без необходимости строить систему с нуля и ломать голову над каждым шагом.

Практика headless observability
1. Сбор данных с OpenTelemetry
Допустим, есть приложение на Python, и мы хотим собирать метрики и логи. Используем OpenTelemetry SDK:

from opentelemetry import trace, metrics
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.exporter.kafka import KafkaSpanExporter

# Настраиваем провайдеры
trace.set_tracer_provider(TracerProvider())
metrics.set_meter_provider(MeterProvider())

tracer = trace.get_tracer(__name__)

# Отправляем трейсы в Kafka
exporter = KafkaSpanExporter(
    bootstrap_servers="kafka:9092",
    topic="otel-traces"
)

👉 Что тут происходит? Мы создаем OpenTelemetry-трейсер, который будет собирать данные и отправлять их в Kafka.

2. Настройка Kafka для обработки событий
В docker-compose.yml можно запустить Kafka и Zookeeper:

version: '3.8'
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181

  kafka:
    image: confluentinc/cp-kafka:latest
    depends_on:
      - zookeeper
    environment:
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

👉 Что тут происходит? Мы поднимаем Kafka-брокер и Zookeeper для координации.

3. Хранение данных в Apache Iceberg
Теперь направим данные из Kafka в Iceberg с помощью Flink. Вот SQL-пример создания таблицы:

CREATE TABLE telemetry_data (
    trace_id STRING,
    span_id STRING,
    timestamp TIMESTAMP(3),
    attributes MAP<STRING, STRING>
) WITH (
    'connector' = 'kafka',
    'topic' = 'otel-traces',
    'format' = 'json'
);

👉 Что тут происходит? Данные из Kafka читаются и кладутся в таблицу Iceberg.

4. Визуализация в Grafana
Grafana может подключаться к Iceberg через Presto. Добавляем в grafana.ini:

[database]
type = postgres
host = presto:8080
database = iceberg_db

Затем создаем дашборд с запросом: SELECT timestamp, trace_id, span_id FROM telemetry_data ORDER BY timestamp DESC;

👉 Что тут происходит? Grafana получает данные через Presto и отображает их.

Как внедрить headless observability (и не сойти с ума)

1. Собираем. Юзаем OpenTelemetry или аналогичные инструменты для сбора телеметрии.
2. Поточно обрабатываем. Настройм стриминг через Apache Kafka или Flink. Это позволит обрабатывать данные в реальном времени.
3. Храним. Выберим object storage, оптимизированное для логов. Например, Amazon S3 или Google Cloud Storage.
4. Настроим ETL. Автоматизируем extraction, transformation и loading данных.
5. Визуализируем. Подключим инструменты вроде Grafana или Superset.

Зачем всё это нужно?
Во-первых, дешевле. Объектное хранилище стоит меньше, чем SSD, а возможность использовать стандартные инструменты для анализа избавляет от необходимости покупать дорогие SaaS-решения.
Во-вторых, это гибкость. Мы сами решаем, какие данные хранить, как долго и кто к ним получит доступ.
И, наконец, это масштабируемо. Система растет вместе с вами, а не против вас.

TCP, UDP и QUIC: База 📡

На последних 3ех интервью, был блиц опрос и вопрос повторился - в чем же отличие TCP от UDP. Набил уже шишку, так сказать. А на самом деле, выбор сетевого протокола — это не просто техническая мелочь, но это лежит в основе бизнеса. Например при отправке важного бумажного письма - вы доверите его почте с уведомлением о доставке, бросите в ящик наугад или наймете курьера с подписью получателя? Именно так выглядят TCP, UDP и QUIC в мире передачи данных.

Начнем с основ. TCP — это как отправить заказное письмо с уведомлением. Надежно, аккуратно, но медленно. UDP — это бросить посылку на порог и надеяться, что ее никто не украдет. Быстро, но без гарантий. А QUIC — это нанять курьера, который не только доставит быстро, но и потребует подпись.

TCP: Медленно, но верно 🐢
TCP — это старый добрый стандарт. Он гарантирует, что каждый пакет данных дойдет до адресата в нужном порядке. Это идеальный выбор для задач вроде загрузки файлов, запросов к базам данных или пересылки электронных писем. Но есть нюанс: за надежность приходится платить временем. Если потерялись данные, TCP терпеливо запросит их повторно. Кароче, как старый дед - всегда перепроверяет, закрыл ли он дверь, — надежно, но немного раздражает.

UDP: Быстрее ветра 💨
UDP, напротив, не заморачивается. Его принцип: "Кто успел, тот и съел". Он идеально подходит для видеозвонков, онлайн-игр и стриминга, где важнее скорость, чем идеальная картинка. Представьте, что вы смотрите матч, и пропали пара кадров — вы же не будете рыдать? Вот и UDP не будет. Главное, чтобы большинство данных дошло.

QUIC: Лучшее из обоих миров 😎
Теперь о QUIC. Этот протокол объединяет лучшее из двух миров: скорость UDP и надежность TCP. Он создан для современных приложений вроде HTTP/3, а еще умеет сохранять соединение, даже если вы переключаетесь с Wi-Fi на мобильные данные. Это как курьер, который не только доставит быстро, но и подождет, пока вы найдете паспорт, чтобы расписаться.

Как выбрать? 🤔
Все просто:
1. Нужна молниеносная скорость для живого общения? Берите UDP.
2. Хотите баланс скорости и безопасности? QUIC — ваш выбор.
3. Любите классику и стабильность? TCP все еще в деле.

На практике, я недавно поработал с QUIC для одного проекта. Ну как поработал, понял что большинство сетевых инструментов его не поддерживают, и чтобы работал какой-нибудь Network protection на macOS (защищает устройства от сетевых угроз, блокируя доступ к вредоносным сайтам и контролируя сетевую активность) QUIC просто надо выключать. Не все еще готовы к такой крутой штуке.

eBPF и Kubernetes: как Kubescape вырос из песочницы 👶

Недавно флексил своим eBPF знанием (ну совсем немного) на собеседовании. Для себя обнаружил что этот фреймворк еще и в кубере используется. Вот пример: Kubescape. Начинался как "песочница" в CNCF, теперь вышел на уровень инкубационного проекта. И это большой шаг. Представь, что твой по сути пет-проджект, который ты начинал как эксперимент, вдруг становится важной частью экосистемы Kubernetes. У Kubescape получилось.

Итак, что же это это такое? Если коротко, это инструмент безопасности для Kubernetes, который использует eBPF для мониторинга событий на узлах кластера. Но это не просто еще один сканер уязвимостей. Kubescape умеет анализировать риски, сканировать на соответствие стандартам безопасности (например, NSA-CISA), проверять конфигурации и даже анализировать образы контейнеров. И всё это в реальном времени.

На практике, Kubescape упрощает жизнь. Например, его интеграция с CI/CD пайплайнами позволяет ловить проблемы на ранних этапах разработки, а не тогда, когда всё уже развалилось. А eBPF, если ты ещё не в курсе, это как сверхспособность Linux: позволяет отслеживать события в системе без значительного влияния на производительность. Это как? Хз, магия. 💫

Как внедрить Kubescape в свой рабочий процесс? 🔄
1. Установи Kubescape. Это можно сделать через kubectl или Docker. Всё довольно просто, и документация у них понятная.
2. Запусти сканирование твоего кластера. Команда kubescape scan framework nsa проверит твой кластер на соответствие рекомендациям NSA-CISA. Да, даже NSA заботится о Kubernetes.
3. Настрой интеграцию с твоим CI/CD. Тут понятно, выбор большой.
4. Если хочешь большего, подключи eBPF-мониторинг для отслеживания событий в реальном времени. Это немного сложнее, но усилия того стоят.
5. Настрой алерты. Kubescape умеет анализировать поведение приложений и предупреждать, если что-то идёт не так.

Конечно, не всё идеально. Например, настройка eBPF может вызвать пару седых волос, если ты с этим не сталкивался. Но, как говорится, кто не рискует, тот не пьёт шампанского (или кофе, если ты современный айтишник).

Что ж, теперь Kubescape официально в инкубационном статусе, и это значит, что проект будет расти и развиваться ещё быстрее. Возможно, мы скоро увидим Kubescape 4.0 с новыми фишками. А пока можно поздравить разработчиков и сообщество с этим достижением.

И напоследок: если кто-то спросит, зачем тебе Kubescape, скажи, что это твой "швейцарский нож" для безопасности Kubernetes. А если не поймут, просто покажи им, как он работает. Уверен, вопросов больше не останется.

Еще одно SRE интервью где я понял, что знаю слишком много (и слишком мало одновременно)

Интервью на SRE/DevOps часто выглядит очень рандомно т.к. стек технологий просто не перечислить. Вроде все знаешь, но потом тебя спрашивают “Что делает ldd?”, и ты понимаешь, что пропустил туториал.

За последние несколько дней мне удалось поучаствовать в довольно хардкорной серии собеседований. Вопросы сыпались как из пулемета: от основ Linux и Kubernetes до BGP, strace, авто-масштабирования, syscalls и проблем с балансировкой трафика. Весь этот опыт — это целая история, в которой я буквально прожил маленькую жизнь инженера, решая гипотетические (и не очень) проблемы.

Зомби (нет, не те, что в фильмах)

Интервью началось с Linux, и это был ожидаемый расклад. Конечно же, load average, zombie processes и ldd — классика жанра.

Load average? Да это же просто среднее количество процессов в run queue плюс те, кто ждут I/O. Тебе дают 1.5 1.3 1.1, и ты понимаешь, что сервер что-то переживает.

Zombie process? Это когда процесс уже умер, но родитель его не похоронил (wait() никто не вызвал). Вроде и памяти не жрет, но выглядит жутко (ps aux | grep Z).

ldd? Узнаем, какие библиотеки нужны бинарнику

ldd /bin/ls

И тут сюрприз — если видишь not found, значит, пора или в LD_LIBRARY_PATH лезть, или пересобирать.

Kubernetes: почему в поде “pause” и почему 500-я в браузере

Потом логично пришел Kubernetes. Классика жанра: “Вот у вас сервис, он возвращает 500, как дебажить?”
• Логи сначала! kubectl logs pod-name -n namespace
• Жив ли под? kubectl describe pod pod-name
• Если под жив, а трафик не идет — виноват сервис или ingress
kubectl get svc -n namespace
kubectl get ingress -n namespace

• “No route to host”? А вот это уже весело. Или под сдох, или iptables что-то намудрил, или сеть решила тебя потротлить.

Отдельный вопрос был про pause container в Kubernetes. Он, оказывается, держит network namespace для пода. По сути, это тихий гость на вечеринке, который организует пространство, но сам ничего не делает (docker ps | grep pause).

BGP, балансировка и алгоритмы трафика

Потом внезапно залетели вопросы по BGP. “Что это?”, “Как дебажить?”, “Какие алгоритмы балансировки?”

BGP (Border Gateway Protocol) — это тот самый протокол, который решает, как пакеты путешествуют между автономными системами. Если в интернетах что-то упало, это, скорее всего, он.

А балансировка?
Тут выбираем между:
• Round Robin (просто раскидываем запросы)
• Least Connections (отправляем туда, где меньше нагрузки)
• IP Hash (держим сессию клиента на одном сервере)
• Weighted Round Robin (если у одного сервера больше ресурсов — даем ему больше трафика)

Если на балансировщике внезапно “No route to host”, это или iptables съехал, или сервис просто не отвечает (curl -v).

Syscalls и strace — слежка за процессами

Тут мне задали вопрос про syscalls и как отлаживать бинарник, который жрет ресурсы. Встречайте strace:
• Как понять, какие syscalls делает процесс? strace -p <PID>
• Как узнать, какой из них самый долгий? strace -T -p <PID>
• Как быстро собрать статистику? strace -c -p <PID>

(Спойлер: если видишь futex() — процесс просто зависает в ожидании чего-то важного.)

Итог

Вопросы были жесткие, но полезные. После такого интервью хочется либо сразу идти работать, либо неделю пересматривать Linux, Kubernetes и BGP.

Что я понял?
1. Детали решают все. “Просто увеличь поды” — не ответ. “Разберись с балансировкой и пропускной способностью” — вот ответ.
2. Логирование — твой лучший друг. Если что-то не работает, всегда начинай с logs и describe.
3. Стандартные команды должны быть на автомате. Нет времени думать на интервью, как узнать load average или какие syscalls делает бинарник.
4. Сеть — это не просто “оно работает”. Маршрутизация, iptables, балансировка, BGP — если не знаешь, придется учить.

Docker Init: Даже не знал про такую тулу к своему удивлению

Если задумывался о том как перестать тратить часы на создание Docker-файлов вручную и начать жить, то вот статья: https://spacelift.io/blog/docker-init. Открыл для себя, расскажу здесь.

Выглядит как настоящий рабочий инструмент, который действительно экономит время и нервы. Разберемся, что это такое, как это использовать и почему стоит попробовать.

Что такое Docker Init

Если кратко, docker init — это команда, которая автоматически генерирует три ключевых файла для контейнеризации твоего проекта: Dockerfile, compose.yaml и .dockerignore. Она поддерживает Node.js, Python, Go, Rust и ASP.NET, а также имеет общий шаблон для других случаев.

Идея проста: запускаешь docker init, отвечаешь на несколько вопросов (какой язык, какая версия, какой порт и т.д.), и все - есть готовый набор конфигурационных файлов. Это особенно удобно, если только начинаешь разбираться с Docker или хочешь быстро добавить поддержку контейнеров в старый проект.

Как это сделать пошагово

1. Установим Docker Desktop версия 4.18 или выше, так как docker init идет в комплекте именно с этой версией.

2. Создаем проект. Например, простой сервер на Node.js:

const express = require("express");
   const app = express();

   app.get("/", (req, res) => res.send("Привет из Docker!"));
   app.listen(3000, () => console.log("Сервер запущен на порту 3000"));

3. Запустим `docker init` в директории проекта:

$ docker init

Зададут несколько вопросов: какой язык, какая версия Node.js, какой порт и т.д. Просто следуем инструкциям.

4. Проверим созданные файлы.
- Dockerfile — с готовыми инструкциями для создания образа.
- compose.yaml — для запуска стека (например, с базой данных).
- .dockerignore — чтобы исключить ненужные файлы из сборки.

5. Запустим проект. Используйте Docker Compose:

$ docker compose up --build

6. Проверим работу. Юзаем браузер или curl, чтобы убедиться, что сервер работает на localhost:3000.

Лучшие практики (и немного ворчания)

1. Не ленись проверять сгенерированные файлы. Иногда docker init может выбрать базовый образ, который не совсем подходит проекту. Например, Node.js на базе Alpine, когда нужен Debian.

2. Используй "Other" шаблон, если язык не поддерживается. Это даст минимальный набор файлов для кастомизации.

3. Не забывай про `.dockerignore`. Это может существенно ускорить сборку, исключив ненужные файлы.

4. Не используй `docker init` бездумно в старых проектах. Если уже есть Docker-файлы, команда может их перезаписать (хотя и предупредит об этом).

Так что, если вы устал от ручного написания Docker-файлов или хочешь сэкономить время на рутинной работе, попробуй docker init. А если что-то пойдет не так, всегда можно вернуться к старым добрым гугл-запросам, бесконечным беседсми с AI и ночным сеансам дебага. Удачи!

Claude prompts

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

В репозитории собраны промпты, из которых для работы в DevOps особенно полезны:

1. Explain Python Code (official example) – незаменим при анализе автоматизационных скриптов
2. Control output format (JSON mode) – идеален для работы с конфигурационными файлами и API
3. Smart Dev – помогает при разработке инфраструктурного кода
4. Prompts For Github Project – улучшает работу с репозиториями и CI/CD
5. Claude with Functions – полезен при создании автоматизированных рабочих процессов

Немного девоповской базы: IaC 👨‍💻

Когда-то давно (когда я начинал работать в IT), инфраструктура была чем-то вроде искусства. Если сервер упал, ты звонишь "тому парню", который знает магические заклинания для его поднятия. Сейчас же, благодаря Infrastructure as Code (IaC), всё стало куда более цивильным. Но не обманывай себя: даже в 2025 году многие компании всё ещё топчутся на месте, не понимая, как выжать максимум из этой технологии.

Что такое IaC

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

Но вот в чём подвох: большинство компаний использует IaC, как дорогой тостер, чтобы жарить хлеб. Да, они пишут Terraform-скрипты, но при этом половина их облачной инфраструктуры всё ещё "живет своей жизнью". Никакой магии, только хаос. Я лично был тем самым человеком который пытался прод "отзеркалить" через конфиги - та еще задача.

Почему это всё ещё сложно? 😓

Во-первых, мультиоблачные среды. В 2024 году 80% компаний использовали несколько облаков, и это звучит круто, пока ты не осознаешь, что управлять ими — это как пытаться одновременно дрессировать кошек и собак. Во-вторых, безопасность. Все говорят про безопасность, но как только доходит до IaC, она оказывается где-то на втором плане. Ну и, конечно, старое доброе "а давай просто напишем это вручную, быстрее же будет". Если у кого-то где-то горит, то ты быстрее хочешь залатать в админке GCP чем возиться с конфигом.

И, как вишенка на этом торте, даже такие гиганты как Terraform начинают терять позиции. Появляются OpenTofu и Pulumi, которые обещают сделать всё проще, но в итоге добавляют ещё больше выбора, а значит, и больше головной боли.

Как внедрить IaC у себя (и не сойти с ума)

1. Выбери инструмент: Terraform, Pulumi, OpenTofu — выбирай, что ближе по душе. Главное — начни с чего-то одного.
2. Начни с простого: не пытайся сразу автоматизировать всю инфраструктуру. Выбери один проект или сервис.
3. Обучи команду: без этого всё развалится. Если кто-то не понимает, как работает IaC, он станет слабым звеном. Это как Scrum (или как его назвали в Avito: Scrum, but ...), где вы вроде по манифесту, но на практике пропускаете пару скрам элементов что приводит к полной неработоспособности всего фреймворка.
4. Внедри CI/CD для IaC: автоматизация не должна быть ручной. Настрой пайплайны, чтобы проверять и применять изменения.
5. Следи за дрейфом: инфраструктура имеет свойство "уползать" от того, что ты написал в коде. Используй инструменты для мониторинга.

Кароче, если ты ещё не начал использовать IaC, самое время. А если начал, но не видишь результатов, может, стоит пересмотреть подход? В конце концов, лучше поздно, чем никогда.

PearsonVUE срань говна или как я стресанул не на шутку 💩

Хотел бы поделиться своим опытом с PearsonVUE.

Сегодня у меня был запланирован экзамен AI-900 на 11 часов утра. Я начал подготовку системы примерно в 10:20 на своем рабочем ноутбуке, и он прошел все проверки, а затем, после того как я подтвердил свою личность и рабочее место, появился чат с проктором. Они сказали, что всё в порядке, и запустили экзамен. Как только экзамен был запущен, мой компьютер завис, и никакое управление macOS не было доступно (табуляция, Forcw Quit, App Control). Он полностью завис.

Хорошо. Я перезагрузил компьютер, прошел тот же путь, и в тот момент, когда система начала проверять мое интернет-соединение, она показала ошибку: "The streaming connection requires that Wowza.com can be reached as well as a stable connection of at least 1mb upload and download speeds". Затем система явно сказала (у меня просто нет сообщения об ошибке), что я должен обратиться к системному администратору, чтобы разрешить соединения *443, *8080 с их веб-сайтом и отключить все антивирусные решения. Ну, абсурдность этой ситуации была уже высока, потому что... я не могу отключить никакие функции MDE на enrolled device. Ok.

Тогда я решил использовать другой ноутбук, который у меня есть и на котором на данный момент не установлено никакого ПО или антивируса. Я снова прошел регистрацию и начал общаться с проктором, объяснив всю ситуацию. Он продолжал говорить, что всё в порядке, и он всё исправит. Как только он запустил экзамен, система немедленно зависла, но, к счастью, у меня был проктор в голосовом чате. Мой другой компьютер снова завис. Я попросил его позвонить мне на мобильный телефон, но... нельзя использовать мобильные телефоны на экзамене!

Затем система пыталась запустить мой экзамен снова и зависла, а потом через 10 минут разморозилась и сообщила, что они не смогли запустить экзамен (несмотря на то, что все предварительные проверки были зелеными). Проктор сказал, что этот экзамен будет отменен, и я могу запланировать другой экзамен. Я сказал ему, что это не имеет смысла, потому что я увижу ту же проблему в следующий раз. Он сказал, что не может помочь, и отключился.

Время, которое прошло от начала подготовки до отключения проктора: 2 часа. Уровень стресса, который показало мое кольцо Oura, был выше крыши. Это не первый раз, когда я сталкиваюсь с проблемами PearsonVUE. Просто кошмар.

Спасибо за чтение...

LangChain Hub: Открыл классный хаб для работы с LLM 🐝

Вяло читаю книгу про RAG [Unlocking Data with Generative AI and RAG: Enhance generative AI systems by integrating internal data with large language models using RAG] наткнулся на очень прикольную тулу - LangChain Hub. Поделюсь своими впечатлениями об этом инструменте, который нормально упростил мою работу с языковыми моделями. Завариваем чай, погружаемся в мир LLM-приложений и читаем про новую (ну, для меня) платформу.

Что такое LangChain Hub?

LangChain Hub – это централизованная платформа для хранения, совместного использования и версионирования компонентов LangChain. Проще говоря, это репозиторий готовых решений для создания приложений на основе языковых моделей. Зачем все это? Ну например, разработчики могут обмениваться промптами, цепочками и другими компонентами.

Представь, что у тебя есть библиотека готовых решений, которые можно легко интегрировать в свои проекты – именно это и предлагает LangChain Hub.

Популярные юзкейсы📝

Возможности LangChain Hub очень недурные:

1. Управление промптами: хранение, версионирование и легкое повторное использование промптов. Идеально для команды.
2. Готовые цепочки: доступ к проверенным цепочкам обработки информации, которые решают конкретные задачи – от извлечения информации до генерации контента.
3. Инструменты для агентов: различные инструменты, которые расширяют возможности LLM-агентов (поиск, математические вычисления, API-интеграции).
4. Системы RAG: готовые компоненты для создания систем Retrieval Augmented Generation.
5. Оценка и бенчмаркинг: инструменты для сравнения эффективности различных моделей и подходов.

Что я лично использую 👨‍💻

Признаюсь, пока я только начинаю осваивать потенциал LangChain Hub, и больше всего меня зацепили Agents – это такие компоненты, которые могут самостоятельно решать задачи, выбирая нужные инструменты.

Агенты в LangChain Hub – это как мини-ассистенты, специализирующиеся на конкретных задачах. Они могут:
- Собирать и анализировать информацию
- Автоматизировать рутинные процессы
- Взаимодействовать с внешними API
- Принимать решения на основе контекста

Пока что System Prompt Generator – мой фаворит.

Из всех инструментов особенно полюбился ohkgi/superb_system_instruction_prompt. Это отличный инструмент, который помогает создавать эффективные системные промпты для различных LLM. Ты знаешь, что качественный системный промпт – это основа эффективной работы с AI. Он задает тон, стиль, ограничения и возможности модели. System Prompt Generator помогает:

1. Структурировать инструкции: создавать четкие, непротиворечивые указания для модели
2. Оптимизировать контекст: формулировать промпты так, чтобы модель получала именно ту информацию, которая нужна
3. Настраивать поведение: точно определять, как модель должна взаимодействовать с пользователем
4. Снижать галлюцинации: минимизировать вероятность генерации недостоверной информации

Этот инструмент существенно сократил время на разработку и тестирование промптов, помогая найти оптимальные формулировки. superb_system_instruction_prompt это один из нескольких крутых промт инжениринг агентов, их там много - можно поискать и другие.

Интеграция с Azure OpenAI 🤖

Огромный плюс LangChain Hub – возможность использовать свой Azure OpenAI API ключ. Для тех у кого он есть и кто не знает куда его засунуть - это самое оно.

Подытожим
Если ты только начинаешь свой путь в мире LLM, рекомендую начать с изучения агентов и System Prompt Generator – эти инструменты дают быстрые результаты и помогают лучше понять, как эффективно взаимодействовать с языковыми моделями.

#LangChain #LLM #AITools #PromptEngineering #AzureOpenAI

AI и Factorio, кмк созданы друг для друга

Я прошел Factorio в свое время, и когда я прочитал что туда принесли АИ чтобы они ее прошли https://the-decoder.com/factorio-joins-growing-list-of-video-games-doubling-as-ai-benchmarking-tools/ это для меня выглядило очень натурально. По сути, Factorio — это не просто игра, где ты превращаешь планету в промышленный кошмар, а ещё и тестовая площадка для искусственного интеллекта. На ютубе люди сидят проходят факторио с экселями и макросами чтобы все расчитать. Теперь агенты учатся планировать, строить и оптимизировать производство, играя в ту же самую игру, которая заставляла тех чуваков с ютуба пересчитывать конвейеры в три часа ночи.

Всё началось с того, что исследователи решили использовать Factorio как инструмент для оценки возможностей языковых моделей. Игра со своей сложной системой ресурсов и бесконечными вариациями фабрик оказалась идеальной для проверки того, насколько хорошо АИ может планировать, решать задачи и управлять ограниченными ресурсами. Но, как оказалось, даже самые продвинутые модели, типа Claude 3.5 Sonnet и GPT-4o, не так уж и умело справляются с задачами, которые для нас, простых смертных, иногда кажутся "чисто по фану".

Factorio Learning Environment — это специальная среда, где машины учатся строить фабрики. Есть два режима: "Lab-Play" с чёткими задачами и ограниченными ресурсами (например, построить завод из двух машин) и "Open Play", где задача проста — построить самый большой завод. Всё взаимодействие происходит через Python API, так что AI буквально пишет код, чтобы строить, соединять компоненты и следить за производственным процессом. Ну, или пытается это сделать, пока не запутается в своих же алгоритмах.

Ирония в том, что машины, которые мы учим строить заводы, часто сами нуждаются в "дебаге". Пространственное мышление, долгосрочное планирование и исправление ошибок — это там, где AI всё ещё спотыкается. Например, вместо того чтобы аккуратно расположить машины, чтобы минимизировать расстояния между ними, AI иногда создаёт такие "художественные" схемы, хотя вообще непонятно зачем. А ещё они обожают зацикливаться на мелочах, забывая о глобальной картине. Знакомо, правда?

Но не всё так плохо. Claude 3.5 Sonnet показал лучшие результаты, решив 15 из 24 задач в "Lab-Play" и набрав 2456 очков в "Open Play". Для сравнения, GPT-4o отстал на добрую тысячу очков. Однако даже у победителя остались проблемы: например, с переходом на более сложные технологии или оптимизацией ресурсов.

Если ты хочешь прикинуться роботом, можешь сам заглянуть в Factorio и попытаться построить идеальную фабрику. А если ты ещё и программист, то API Factorio Learning Environment — это способ поэкспериментировать с кодом и посмотреть, как AI справляется с твоими задачами.

В итоге, Factorio — это не просто игра, а целый мир, где пересекаются развлечения и наука. Наверное, скоро на серверах, кожанные будут соперничать с AI ...

System Design github repo 🕌

Проходил сис дизайн интервью в прошлый понедельник, а сегодня наткнулся на такой репозиторий: https://github.com/ByteByteGoHq/system-design-101?tab=readme-ov-file. Это просто библия для прохождения сис дизайна. По мне так отличное чтиво в мире сложных архитектурных решений. Здесь есть всё: от сравнений REST API и GraphQL до объяснений, почему Nginx называют reverse proxy. А если хочешь узнать, как работает Google Authenticator или почему Redis такой быстрый, то тут вообще велком.

Что здесь есть? (спойлер: ВСЁ) 🌍
- Архитектурные паттерны: Хочешь понять, что такое MVC, MVP, MVVM или даже VIPER? Легко.
- CI/CD: Хочешь почувствовать себя инженером Netflix? Добро пожаловать.
- Кэширование: Почему Redis так быстр? Как кэшировать данные правильно? Ответы здесь.
- Базы данных: Визуализация SQL-запросов, CAP-теорема и даже "8 структур данных, которые управляют вашими базами".
- Микросервисы: Лучшие практики, Kafka, и типичная архитектура микросервисов.
- Реальные кейсы: Хочешь понять, как Discord хранит триллионы сообщений или как YouTube справляется с потоковым видео? Этот репозиторий расскажет.


Документация понятным языком 😌
Здесь всё объясняется простыми словами, а визуализации помогут понять даже самые сложные концепции. Например, диаграммы HTTP-протоколов или сравнение Webhook и polling — это просто шедевры.
Что мне еще понравилось,это то что многие репозитории и статьи сосредотачиваются на одной теме — типа БД, DevOps или микросервисы. Но "System Design 101" — это будто шведский стол для инженеров: тут есть всё и сразу, причём подано так, что хочется взять добавки. Конечно, есть и другие хорошие источники (например, книги Фаулера или блоги Google), но этот репозиторий выигрывает своей компактностью и доступностью.

Добавляй в закладки и начни своё путешествие к званию мастера системного дизайна. Кароче, с таким багажом получаешь +10 к харизме на собеседованиях и +20 к навыкам архитектуры. Проверить это можно только одним способом — скачал, отсобесился, забрал офер на 500к.

Me? Nothing.

Запрыгивай в последний вагон AI-поезда: AI-агенты 🤖

Сейчас уже чатботы, LLM и RAG стали супер попсой которые использует каждая домохозяйка. Хочу поговорить про последний девелопмент в мире АИ, и это будут агенты. На самом деле, с большим опозданием, но пускай будет.

AI-агенты — это не просто умные чатботы. Они не только выполняют задачи, но и принимают решения. Представь себе мир, где Microsoft 365 Copilot или Google Gemini помогают не просто писать письма, а буквально управляют рабочими процессами. И всё это благодаря LCNC-платформам, которые позволяют бизнес-пользователям (да, даже тем, кто считает Excel вершиной технологий) создавать и настраивать эти системы.

К тому же, AI-агенты уже активно используются в облачных платформах, таких как AWS Bedrock, Azure AI Studio и Vertex AI. Они интегрируются с данными компании, автоматизируют процессы и, обещают сделать твою жизнь проще. Хотя, если честно, иногда кажется, что они просто хотят заменить нас.

Как мог бы выглядит день из жизни с AI-агентом 🍄

Просыпаешьсф утром, а твой AI-агент уже приготовил кофе. Ну, ладно, кофе он пока не умеет, но зато он уже проанализировал все рабочие задачи, отправил емейл клиенту и даже напомнил, что пора позвонить маме. Залогинился на работу, а агент уже разрулил половину тасок, в другую половину закрыл несколькими PR.

А что за LCNC 👨‍💻

На самом деле, на бекенде всей этой магии стоит LCNC (low code/no code). Без него AI-агенты не были бы такими умными. Это форма плагина которая позволяют подключать агентов к различным базам данных, системам и даже строить их с нуля. Можно сказать что это плагин для встройки во всевозможные системы.


Риски ✳️

Как и любой инструмент, AI-агенты не безупречны. Вот несколько проблем, которые они могут принести:

- Shadow AI: Представь себе, что коллега создал AI-агента, который случайно удалил половину базы данных. Тут мало отличия от человека конечно, но надо учитывать.
- Переполненные права доступа: AI-агенты могут получить доступ ко всему, что им не следует видеть. Именно процесс ограничения является самым трудоемким, т.к. не сразу все edge кейсы можно уловить.
- Взлом: AI можно взломать с помощью хитроумных инструкций (ну вы видели в тиктоке про крутые промпты).


Так что, если хочешь почувствовать себя частью элиты, юзай AI-агента (например из Copilot, настраивается через Copilot Studio, https://copilotstudio.preview.microsoft.com), настрой его через LCNC и наслаждайся. А если что-то пойдет не так, всегда можешь сказать, что "это был эксперимент."

Еще один классный GitHub-репозиторий, который спасет DevOps интервью

Вот он:

- https://github.com/Swfuse/devops-interview

Настоящая кладезь знаний для тех, кто хочет пройти собеседование и выйти из него героем (или хотя бы без нервного тика).



Тут 4 подраздела:

1. Техническое интервью: Здесь собраны вопросы от "Какой ваш любимый инструмент CI/CD?" до "Как вы настраиваете кластер Kubernetes, если у вас ничего и нет".

2. Интервью с HR: Потому что "расскажите о себе" — это не просто вопрос, а мини-испытание на уровень вашей харизмы.

3. Референсы и ссылки: Полезные материалы, которые помогут не выглядеть растерянным, когда спросят про Ansible или Terraform.

4. Топ вопросов: Субъективный рейтинг популярных вопросов. Хочешь знать, сколько боли приносит вопрос про сети? Здесь все по-честному.

Интересный сервис — Self.so — превращает PDF (например, резюме или портфолио) в аккуратную сайт-визитку буквально за пару кликов. Он сам вытаскивает ключевую информацию из документа и красиво оформляет её на одной странице.

Очень удобно, особенно если ты человек-оркестр и совмещаешь несколько профессий. Больше не нужно пропускать web-site поле когда аплаишься на позицию :)

Вот такой сервис который сравнивает IT зарплаты из всего русского сегмента.
Как я понял, он пылесосит все открытые источники типа hh и сливает все в приятный репорт.

https://public.tableau.com/shared/3KN2X2YXN?:display_count=n&:origin=viz_share_link&:showVizHome=no

По-моему выглядит очень хорошо и полезно. Готовимся.

Сомнений нет