Последние две недели ходил с классной идеей, которую хотел реализовать и выложить на GitHub — резюме как код.

Суть простая: описываем по определенному шаблону в yml файле свое резюме, далее в рамках CI/CD процесса происходит генерация персонального сайта с резюме и блогом, создание резюме в виде PDF файла и публикация/обновление резюме на hh.ru, Habr.Карьера и LinkedIn.

Но когда сел делать исследование перед разработкой, суровая реальность заставила похоронить идею. Habr.Карьера не поддерживает API для кандидатов, только для рекрутеров. В LinkedIn также не нашел метода для работы со своим резюме, кроме его получения. Только hh.ru молодцы — позволяют работать с резюме с помощью API, но делать приложение только для них явно нецелесообразно.

Вот так суровые реалии ограничивают наши возможности. Но ничего, будем искать другие пути и идеи!

#IT #DevOps #резюме #карьера #API #GitHub #CICD #автоматизация

Привет, друзья! 👋

Недавний сбой в работе облачной платформы Microsoft Azure 19 июля вызвал горячие обсуждения в СМИ и особенно на Хабре. Многие спешат обвинить в этом разработчиков, но давайте разберемся глубже.

Основная причина сбоя — ошибка в обновлении ПО от компании CrowdStrike, отвечающей за безопасность. Это обновление вызвало «синий экран смерти» на устройствах с Windows 10, что привело к многочисленным проблемам для компаний по всему миру: от авиакомпаний до банков и больниц.

Однако, обвинять только разработчиков — это упрощение проблемы. Разработчики не работают в вакууме. Для выпуска качественного продукта необходимы здоровые процессы в компании. Вот как это должно выглядеть:

1. Системный аналитик анализирует требования.
2. Разработчик разрабатывает функционал.
3. Тестировщик проводит тестирование.
4. DevOps и релиз-менеджеры автоматизируют публикацию обновлений.

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

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

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

#Microsoft #Azure #сбой #разработчики #CrowdStrike #DevOps #CI_CD #тестирование #ИТпроцессы #команднаяработа

Готовлю доклад по AsyncAPI, обещал рассказать.

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

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

Основное преимущество — улучшение командной работы. AsyncAPI делает взаимодействие между разработчиками, тестировщиками и аналитиками более прозрачным. Все понимают, как работают события, и какие данные передаются. Это снижает ошибки и упрощает тестирование.

Кодогенерация и автоматизация — вот что мне больше всего зашло. Вы буквально можете сгенерировать код клиента или сервера на основе спецификации, а это экономит кучу времени. AsyncAPI отлично работает с современными DevOps процессами, что делает релизы более быстрыми и стабильными.

Если вы работаете с событиями, настоятельно рекомендую попробовать AsyncAPI в вашем следующем проекте.

Интересно, кто уже внедрил у себя? Пишите в комментариях! 👇

#AsyncAPI #API #микросервисы #IoT #документация #кодогенерация #DevOps #технологии #IT

Multi-stage builds и правильный .dockerignore могут уменьшить размер образа в несколько раз. Вместо этого:

FROM node:18
COPY . .
RUN npm install
RUN npm run build

Используйте:

FROM node:18-alpine AS builder
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /build /usr/share/nginx/html

А в .dockerignore добавьте node_modules, .git, tests. Образы собираются быстрее и занимают меньше места в registry.

Альтернативный подход - Buildpacks, но они менее гибкие в настройке.
#Docker #optimization #DevOps

Mozilla SOPS + age решают проблему хранения секретов в Git-репозитории. SOPS шифрует только значения, оставляя структуру файла читаемой:

# До шифрования
database:
    user: admin
    password: super_secret

# После шифрования
database:
    user: ENC[AES256_GCM,data=...] 
    password: ENC[AES256_GCM,data=...]

Поддерживает yaml/json/env файлы. Интегрируется с cloud KMS или локальными ключами через age. В отличие от Vault, не требует отдельного сервера.
#security #DevOps #GitOps

Для анализа метрик в Prometheus часто используют increase(metric[5m])/300, но это не самый удачный подход. Rate(metric[5m]) даёт более точные результаты, особенно при нестабильном скрейпинге или пропуске метрик.

Rate сразу показывает значение в секунду и правильно обрабатывает counter reset. Плюс формула короче и понятнее. Win-win!
P.S. Для событий, которые случаются редко (раз в минуту или реже), лучше использовать increase.
#Prometheus #monitoring #DevOps

🔥 Пишу прямо с Highload++! Конференция настолько насыщенная, что только сейчас выдалась минутка поделиться впечатлениями. А через час уже самому выступать!

Хочу рассказать про сногсшибательный доклад Евгения Харченко из Райффайзен Банка про инженерную культуру (Инженерная культура на масштабе: как развивать и оценивать практики). Ребята сделали нереальную вещь – полностью автоматизировали внедрение инженерной культуры! И главное – всё по-инженерному, с измеримыми результатами и доказанной эффективностью на реальных цифрах 📊

Уже взял контакт Евгения для референса. Как только выйдет видео – обязательно поделюсь, это must-watch!

#Highload2024 #EngineeringCulture #DevOps #RaiffeisenBank #ITConference

🎤 Выступил! Делился историей о том, как мы не справились с нагрузкой в 20 000+ RPS, и какие уроки из этого вынесли.

Если честно – это было самое волнительное выступление в моей карьере. И дело не только в масштабе конференции и количестве слушателей, но и в самой теме. Хотелось честно рассказать о том, что проблемы случаются у всех – важно не это, а то, как мы с ними справляемся 💪

Надеюсь, теперь у инженеров будет под рукой наглядный кейс, который можно показать менеджменту – вот что бывает, если игнорировать технические риски на старте 😉

Презентацию можно посмотреть тут

А сейчас пойду немного выдохну и пройдусь по стендам – мерч сам себя не соберет 🎁

#Highload2024 #PublicSpeaking #SystemDesign #DevOps #ITConference

Для регулярных задач в Linux обычно используют crontab, но systemd timers дают больше возможностей. Вместо записи в crontab создаем два файла:

backup.service:

[Service]
ExecStart=/usr/local/bin/backup.sh

backup.timer:

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Преимущества: встроенный журнал событий (journalctl), мониторинг состояния (systemctl status), оповещения о сбоях и возможность задать зависимости между сервисами.

#Linux #automation #DevOps

3 проверенных стека для метрик:

Классика: Prometheus + Grafana
➕ Простота, огромное комьюнити
➖ Масштабируется до средних нагрузок
Идеально для начала и небольших систем

Длинное хранение: VictoriaMetrics + Grafana
➕ Хранит годы данных, совместим с Prometheus
➖ Сложнее в настройке
Отлично для растущих проектов

Распределенный: Thanos + Prometheus + Grafana
➕ Горизонтальное масштабирование
➖ Сложная инфраструктура
Для больших распределенных систем

#monitoring #devops #metrics"

Привет! Если вы думали над тем, чтобы заменить bash на Go для CI/CD, получить мощные инструменты тестирования, отладки и читаемый код, посмотрите на Dagger. Это инструмент, который позволяет писать CI/CD-пайплайны на Go, TypeScript или Python — как обычный код. Например сборка приложения и публикация в registry:

package main

import (
    "context"
    "dagger.io/dagger"
)

func main() {
    ctx := context.Background()
    client, err := dagger.Connect(ctx)
    if err != nil {
        panic(err)
    }
    defer client.Close()

    // Собираем Docker-образ
    image := client.Container().Build(client.Host().Directory("."))
    
    // Пушим в registry
    _, err = image.Publish(ctx, "my-registry/my-app:latest")
    if err != nil {
        panic(err)
    }
}

Из минусов, кода становится больше:

#!/bin/bash
echo "Building app..."
docker build -t my-app .
echo "Pushing to registry..."
docker tag my-app my-registry/my-app:latest
docker push my-registry/my-app:latest

Но на больших и сложных кейсах приемущество становиться очевидным.

#DevOps #CI_CD #Dagger #Automation #GoLang

Мне все больше нравится работать с легковесной альтернативой Elastic - Vector + Loki + Grafana 📊
Легче, дешевле, и работает с PromQL, который вы уже знаете по метрикам!
#мониторинг #логи #vector #loki #grafana #devops

Стоило только написать первую статью в этом году, как тут же пришли с отличной новостью - мой доклад приняли на конференцию Merge (https://tatarstan2025.mergeconf.ru)! Буду выступать в секции DevOps.

Можно сказать, первая ласточка в этом году. В работе ещё 4 заявки, держим кулачки! 🤞

#конференции #merge #devops #публичныевыступления #татарстан

Сегодня хочу затронуть тему, которая волнует многих DevOps-инженеров и разработчиков: Terraform или Pulumi? Оба инструмента помогают управлять инфраструктурой как кодом (IaC), но подходы у них разные. И если вы ещё не пробовали Pulumi, то, возможно, после этого поста захотите! 😉

---

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

Плюсы:
- Огромное сообщество и поддержка множества провайдеров.
- Простота в освоении (HCL — это не язык программирования, а конфигурационный файл).
- Состояние инфраструктуры хранится в файле terraform.tfstate, что удобно для отслеживания изменений.

Минусы:
- HCL (HashiCorp Configuration Language) ограничен в возможностях.
- Нет типизации, что может приводить к ошибкам.
- Сложности с повторным использованием кода (хотя модули помогают, но это не всегда достаточно).

---

Pulumi: инфраструктура как настоящий код
А теперь давайте посмотрим на Pulumi. Это инструмент, который позволяет описывать инфраструктуру на реальных языках программирования: Python, TypeScript, Go, C# и других. Да, вы не ослышались — это Infrastructure as Real Code!

Плюсы:
- Pulumi использует строгую типизацию, что помогает избежать множества ошибок на этапе написания кода. IDE подскажет, если вы что-то сделали не так.
- Вы получаете все плюшки вашей любимой IDE: автодополнение, проверка типов, рефакторинг и даже отладку. Попробуйте это сделать в Terraform с его HCL!
- Не нужно учить новый синтаксис (HCL). Если вы уже пишете на Python, TypeScript или Go, то можете сразу начать использовать Pulumi.
- Функции, классы, модули — всё это доступно в Pulumi. Вы можете писать более структурированный и поддерживаемый код.
- Pulumi также хранит состояние, но предлагает больше гибкости в управлении им. Вы можете использовать Pulumi Service, S3, Azure Blob Storage и другие бэкенды.

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

---

Когда выбирать Pulumi?
- Если вы разработчик и хотите использовать знакомые языки программирования.
- Если вам нужна типизация и поддержка IDE.
- Если ваш проект сложный и требует повторного использования кода.

Когда выбирать Terraform?
- Если вам нужен проверенный инструмент с огромным сообществом.
- Если ваша инфраструктура относительно простая.
- Если вы уже используете Terraform и не хотите мигрировать.

---

Итог

Pulumi — это мощный инструмент для тех, кто хочет писать инфраструктуру как настоящий код. Он идеально подходит для разработчиков, которые хотят использовать свои навыки программирования. Terraform же остаётся надёжным выбором для классического подхода к IaC.

А какой инструмент используете вы? Делитесь в комментариях! И если ещё не пробовали Pulumi, может, самое время? 😉

#DevOps #IaC #Terraform #Pulumi #InfrastructureAsCode

Написал статью по observability - https://habr.com/ru/articles/885224/. В одну часть всё не влезло (как обычно 😅), так что планирую цикл из 4 статей.

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

P.S. Статья юбилейная, 10-я :)

#habr #observability #мониторинг #devops #статья #разработка

Благодаря меньшему количеству сна, я это сделал. Продолжение цикла статей, теперь на примере Golang — https://habr.com/ru/articles/888682/

Не забывайте ставить плюсы, если понравилось :)

#habr #observability #мониторинг #devops #статья #разработка #go #gloang

Всем привет! Я думаю, все знают, что прохождение интервью и работа в компании – это две большие разницы.

Для разработчиков и технических менеджеров есть этап, который вызывает у меня одновременно огромное удовольствие и сильный стресс — System Design.
Суть его в том, чтобы за час уточнить требования, спроектировать рабочую систему и углубиться в детали.

Даже если вы отлично умеете проектировать, в формате интервью это адская сложность. Всего 60 минут, за которые надо обсудить всё:
- Уточнение требований
- Оценку нагрузки
- OSI-уровни
- Шардирование, репликацию
- Метрики
- и многое другое

Нужно не просто предложить систему, но и защитить её перед интервьюером. Самое интересное – правильного ответа нет, только аргументированные решения.

---

Как к этому подготовиться?

Лидеры в России по System Design – Авито. У них сильнейший подход, которому они ещё и обучают.
Рекомендую посмотреть видео: https://youtu.be/eRUHvOJsGwk?si=DQlX7iCouI94BAaz

Если проектируете backend, и интервьюер сказал, что фронтенд не важен, после подсчетов можно сразу переходить к архитектуре в два этапа:
1. Подходы – сначала объясняем, почему делаем так, а не иначе. Например, очередь или синхронные запросы? SQL или NoSQL? API Gateway или прокси?
2. Решение – проверяем, бьётся ли система с цифрами, объясняем компромиссы, выбираем финальный вариант.

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

---

Что почитать и где тренироваться?

📖 Книга: *Алекс Сюй – System Design. Подготовка к сложному интервью*

Идеально – тренироваться на реальных задачах.
Берите задания, решайте, сравнивайте с чужими решениями.
Лучший вариант – найти ментора, который будет вас гонять.

Самое крутое в этом типе собеседований?
Он реально помогает в жизни: вы начнёте лучше понимать компромиссы в разработке и будете осознанно строить архитектуру.

А вы проходили такое собеседование? Как вам? Что оказалось сложнее всего?

#SystemDesign #Backend #Frontend #Архитектура #DevOps #Разработка #ITКарьерa

Неделю назад вышла Apache Kafka 4.0, но только сейчас дошли руки разобраться что там нового. И это, надо сказать, весьма значимый релиз!

Самое главное — с версии 3 можно было работать без ZooKeeper в экспериментальном режиме, но теперь это стало поведением по умолчанию. Технология KRaft (Kafka Raft) полностью заменила ZooKeeper, что серьезно упрощает развертывание и управление. Больше не нужно поддерживать отдельный ZooKeeper-кластер, что снижает операционные издержки и улучшает масштабируемость. Прощай, ZooKeeper, ты служил верой и правдой! 👋

Что еще интересного:

Новый протокол групп потребителей (KIP-848)
Наконец-то решена проблема с ребалансировкой! Если раньше при изменении числа потребителей происходила "stop-the-world" ребалансировка, приводящая к задержкам, то теперь процесс происходит гораздо плавнее. Особенно полезно для крупных деплойментов — больше никаких долгих простоев при масштабировании.

Очереди для Kafka (KIP-932, ранний доступ)
Появилась концепция "share group" для организации кооперативного потребления данных из топиков. По сути, это делает возможной реализацию классических очередей, где каждое сообщение обрабатывается только одним потребителем. Теперь Kafka может легко заменить RabbitMQ и другие традиционные брокеры сообщений.

Eligible Leader Replicas (превью)
Введен поднабор допустимых реплик (ELR), которые гарантированно содержат все данные и могут безопасно становиться лидерами без потери данных.

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

Повышение требований к Java
Kafka Clients и Streams теперь требуют Java 11, а брокеры, Connect и инструменты — Java 17.

Переход на Log4j2
Логирование переведено на Log4j2, что дает больше возможностей и лучшую производительность.

Не забудьте изучить гайд по переходу

А вы уже планируете переход на Kafka 4.0? Делитесь опытом в комментариях!

#kafka #apache #bigdata #streaming #devops #dataengineering #dev

Который раз убеждаюсь — профессия разработчика не даёт заскучать. Каждый день узнаёшь что-то новое.

Недавно со мной поделились интересной находкой: оказывается, в Nginx Ingress есть встроенная поддержка телеметрии. Можно буквально «из коробки» настроить отправку трейсов в OTLP, например, в Jaeger.

Я-то всегда был уверен, что в бесплатном Nginx такой возможности нет, и даже мысли не возникало искать её в Ingress. А зря 🙂

И самое приятное: даже для «чистого» бесплатного Nginx тоже есть решение — nginx-otel. Судя по описанию, этот модуль работает аж в 4 раза эффективнее официального варианта из Nginx Plus.

#nginx #otel #observability #devops #ingress

Вообщем, сегодня поймал второе откровение.

GitHub CI вырвался вперёд — и не за счёт “мощи”, а именно за счёт удобства.
Когда тебе нужно быстро поднять пайплайн, GitHub ощущается как «дружелюбный сосед»: открыл, выбрал нужные actions, связал пару шагов — и через 5-10 минут у тебя уже всё крутится и билдится. Без боли, без танцев, без «почему оно не нашло runner», или почему тут нужны сертификаты.

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

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

#devops #ci #github #gitlab #инженерия