Обновить
512K+

DevOps *

Методология разработки программного обеспечения

273,41
Рейтинг
Сначала показывать
Порог рейтинга

Узнаете на GoCloud, как построить ИИ-инфраструктуру на физических серверах: от инференса до обучения на уровне суперкомпьютера

Компании переходят от внешних поставщиков искусственного интеллекта к собственной инфраструктуре ради контроля данных, безопасности, предсказуемых затрат и независимости. Разберем, как построить платформу искусственного интеллекта полного цикла на голом железе: от запуска вывода моделей до тонкой настройки. Покажем, как объединение узлов с графическими ускорителями через InfiniBand превращает серверы в кластер суперкомпьютера и как масштабировать ИИ-нагрузку по всем канонам высокопроизводительных вычислений.

Спикер: Александр Шакмаев — менеджер продукта, Cloud.ru

Трек: Инфраструктура

📅 Когда: 9 апреля в 14:40–15:20 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: Тестируем B200: живые бенчмарки с GLM-4.7

Теги:
0
Комментарии0

Автоматизация облачных сценариев в эпоху искусственного интеллекта — одна из тем доклада на GoCloud 2026 ☁️

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

Также покажу, как одни и те же блоки выполняются в разных окружениях и как ИИ-ассистент ускоряет сборку полного цикла: от архитектуры и непрерывной интеграции до бизнес-логики приложений.

Спикер: Антон Щеколдин — менеджер продукта, Cloud.ru

Трек: Приложения и разработка

📅 Когда: 9 апреля в 12:50–13:30 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: Практическое применение eBPF: serverless-платформа с поддержкой TCP-приложений

Теги:
0
Комментарии0

SpaceWeb добавил в частное облако четыре DevOps-инструмента: MinIO, Zulip, n8n и Zabbix

SpaceWeb запустил в частном облаке серию готовых open-source сервисов для командной разработки. Каждый разворачивается независимо — можно выбрать только то, что нужно под конкретную задачу. В набор вошли четыре инструмента:

  • MinIO — S3-совместимое объектное хранилище для бэкапов, логов, артефактов сборки и статики;

  • Zulip — командный чат с тематическими ветками для асинхронной работы;

  • Zabbix — мониторинг серверов и приложений: CPU, память, диски, базы данных, веб-серверы;

  • n8n — конструктор автоматизации без кода: соединяет сервисы, ловит вебхуки, создает тикеты, управляет файлами.

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

Подробности — на сайте SpaceWeb.

Теги:
+2
Комментарии0

Управляемые базы данных и почему это тоже про машинное обучение — расскажем на GoCloud 2026 ☁️

Покажем, почему ML-системы начинаются не с моделей, а с дата-инфраструктуры. Разберем роль PostgreSQL, Kafka, Redis, ClickHouse и OpenSearch в реальных сценариях машинного обучения клиентов. Обсудим, как управляемые дата-сервисы становятся фундаментом ИИ-нагрузок, и какие продуктовые требования меняются — превращая дата-платформу в IaaS-слой для машинного обучения.

Спикер: Сергей Геворкян — менеджер продукта, Cloud.ru

Трек: Данные и аналитика

📅 Когда: 9 апреля в 15:35–16:05 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: Как мы разгрузили базу данных в проде и не сломали систему

Теги:
0
Комментарии0

Как делать бизнес-процессы как в n8n — безопасно и масштабируемо? Узнаете на конференции GoCloud 2026 ☁️

Расскажем, как обойти лимиты n8n для enterprise- и ИИ-систем: живой трейсинг и метрики из коробки, предсказуемое масштабирование, нативная работа с кастомными моделями машинного обучения и мультиагентными системами. Плюс бесшовный импорт сценариев из n8n без простоев. В финале — живая миграция реального воркфлоу за минуты.

Спикер: Владислав Янковский — старший Go-разработчик, Cloud.ru

Трек: Прикладной ИИ

📅 Когда: 9 апреля в 16:40–17:00 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: NoCode инструменты для создания AI-приложений с RAG: быстрый старт

Теги:
0
Комментарии0

Автоматизируем жизненный цикл баз данных: вебинар про DBaaS в Deckhouse

Database as a Service — подход, в котором базами данных управляют как платформенным сервисом: с автоматизацией и предсказуемым жизненным циклом. Вместо ручного администрирования каждой БД по отдельности — единый процесс от создания и развёртывания до обновлений и оптимизации.

Мы реализовали этот подход в Deckhouse Kubernetes Platform. На вебинаре 3 апреля покажем, как он работает, и расскажем:

  • что Cloud Native-подход меняет в управлении сервисами данных;

  • как устроен DBaaS в Deckhouse: жизненный цикл БД и платформенные модули;

  • как реализовать облачные принципы управления БД в закрытом контуре.

Регистрируйтесь и подключайтесь 3 апреля в 12:00 по Москве, если используете БД или хотите применить DBaaS-подход в своей инфраструктуре.

Теги:
+1
Комментарии0

Я не разработчик, но сделал Telegram-бота для Hysteria 2

Я не программист, языков не знаю, я небольшой руководитель отдела в айти, неплохо знаю серверную архитектуру. Но у меня была простая боль: недавно завел для себя и родни сервер Hysteria 2, до этого было с VLESS на сервере и устал каждый раз руками править YAML, когда нужно:

добавить или удалить пользователя, выдать доступ, проверить статус, перезапустить сервис и при этом ничего не сломать

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

Сразу честно: делал с помощью LLM. Статью эту тоже, кстати. Панаму я приготовил. Цель статьи не выпендреж, а просто рассказать о боте, что бы его уже нормальные разработчики посмотрели переделали, может на основе его сделали адекватный продукт

Почему не SSH?

Да, можно через SSH, nano и systemctl. Но когда делаешь это регулярно — растёт шанс ошибки.

Хотелось проще: открыть Telegram, нажать пару кнопок и выдать доступ без ручного редактирования config.yaml.

Веб-панель тоже рассматривал, но бот оказался быстрее и удобнее “на ходу”.

Что умел MVP

Минимум, который был нужен:

/status — жив ли сервис /users — список пользователей add / delete / enable / disable генерация hy2:// ссылки /logs — последние логи /restart — перезапуск с подтверждением

Звучит просто. Пока не думаешь о безопасности.

Главная проблема: бот ≠ root

Первая (и плохая) идея — дать боту полный доступ: пусть сам правит YAML, дергает systemctl и читает логи.

Это почти готовый root-доступ извне.

Я сделал иначе:

Бот — это интерфейс, не исполнитель.

Бот хранит данные (SQLite) Все опасные действия делает отдельный helper на сервере Helper: генерирует YAML делает backup валидирует только потом применяет и перезапускает

В sudoers разрешены только конкретные команды helper-а, а не shell.

Безопасность (без этого смысла нет)

Сделал максимально жёстко:

deny by default доступ только по Telegram user ID (не username) админ-команды только в личке в группах — никаких опасных действий delete/apply/restart — через подтверждение audit log: кто, когда и что сделал

Бот должен быть параноидальным, а не “удобным для всех”.

Грабли, на которые я наступил

  1. Права на конфиг permission denied на /etc/hysteria/config.yaml — лечится не перезапуском, а нормальными правами.

  2. Cert/key Один неправильный путь — сервис не стартует. Плюс легко сломать доступ к privkey.pem.

  3. URI и userpass

hy2:// и hysteria2:// формат username:password спецсимволы нужно кодировать

Очень легко получить “почти рабочую” ссылку.

  1. Клиенты На iOS импорт URI иногда работает хуже, чем ручной ввод.

  2. OpenWrt + sing-box Сначала “не работает”, потом “работает, но не так”, и только после настройки DNS и роутинга — всё нормально.

Что получилось

Сейчас это нормальный админ-пульт:

управляю доступами из Telegram не трогаю YAML руками опасные действия подтверждаются и главное — нет полного root-доступа у бота

Удобство появилось без видимых дыры в безопасности.

Про LLM

Да, я использовал нейронку. Но это не “магическая кнопка”.

Без продуманной архитектуры (права, границы, apply, валидация, rollback) получилась бы просто опасная игрушка.

Что бы сделал иначе сразу делал бы helper-архитектуру добавил бы audit log с самого начала разделил бы read и write операции по правам сделал бы preflight-проверки перед apply

Что дальше

Планирую:

улучшить UX, возможно добавить лёгкую веб-панель, оставить Telegram, как быстрый пульт

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

P.S. Это моя первая статья, готов ко всем минусам, хейту и так далее. Единственная цель этого поста - рассказать о боте и дать его в народ

ссылка не репу https://github.com/Ramisya4ka/hysteria-bot-manager (внутри есть очень подробное Readme)

Теги:
+5
Комментарии0

Код, контейнеры и немного ИИ. GoCloud 2026: трек «Приложения и разработка»

Один из треков ежегодной конференции GoCloud 9 апреля будет про приложения и разработку в облаке. Без воды, только то, с чем команды сталкиваются в реальных проектах: сборка сценариев, управление артефактами, безопасность приложений и монетизация через маркетплейс.

Вот что разберут в докладах:

  • AI Assisted Cloud Workflow: автоматизация облачных сценариев в эпоху ИИ — поделимся инструментом, который убирает ручную склейку сервисов: просто берете готовый шаблон, а ИИ-ассистент помогает собрать все от архитектуры до бизнес-логики. Полезно тем, у кого нет выделенного архитектора на каждый проект.

  • Артефакты в масштабе: история роста и эволюции Evolution Artifact Registry — как устроено централизованное хранилище артефактов, как оно дружит с Kubernetes и что анонсируют из новых функций в этом году. Полезно командам, у которых артефакты разбросаны по разным местам.

  • Evolution Container Apps: платформа для платформ — как на базе одного сервиса поднять изолированные среды для разработки, тестирования и обучения. Разберут на примерах: от личного ноутбука до учебной платформы в стиле «Школы 21».

  • Снижаем рутину в облаке: новые сценарии Гига-помощника — как ИИ-помощник теперь умеет разворачивать сразу несколько продуктов и настраивать мониторинг. Покажут живьем, без слайдов с обещаниями.

  • Защита cloud native приложения: от GUI до ИИ — как атакуют контейнеры и где типичные дыры в Kubernetes. На практике покажут, как закрыть угрозы через Evolution Container Security за несколько кликов.

  • От сервиса до экосистемы: как Маркетплейс Cloud.ru ускоряет путь продукта к клиенту — как устроен путь от первого релиза до выплат, сколько это стоит и сколько экономит. Будут реальные цифры и разбор типичных ошибок.

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

Регистрируйтесь и до встречи на GoCloud 2026! 

Теги:
0
Комментарии0

Запустили Yandex Cloud Stackland — инфраструктурную платформу для развёртывания приложений в закрытом контуре

С помощью Stackland можно как настроить среду для разработки собственных сервисов, так и быстро внедрять облачные решения. Это готовая инфраструктура со встроенными управляемыми базами данных, контейнерным оркестратором, объектным хранилищем, а также инструментами для управления доступом к графическим ускорителям, которые помогут решать задачи инференса при разработке ИИ‑решений. Выдавать доступы к разработке можно гранулярно, используя встроенные средства безопасности.

Платформу можно развернуть на любых виртуальных, арендованных или собственных серверах, а также интегрировать с уже существующими корпоративными системами. Также она позволяет без дополнительной интеграции внедрять готовые сервисы Yandex Cloud, доступные по модели on‑premises. Сейчас в Stackland доступны инструмент для речевой аналитики Yandex SpeechSense и BI‑система Yandex DataLens, в ближайшее время появится ещё несколько решений, в том числе Yandex AI Studio для разработки ИИ‑приложений и агентов.

Подробнее о разработке опенсорс‑решения для бэкапов CloudNativePG в Stackland и предыстории платформы мы уже рассказывали в отдельной статье.

Для получения доступа к Yandex Cloud Stackland оставьте заявку.

Теги:
+7
Комментарии0

lazy-tmux — быстрый и «ленивый» менеджер сессий tmux

Весь мой рабочий процесс происходит внутри сессий tmux. Долгое время я использовал tmux-resurrect + tmux-continuum. Они работали… но с нюансами. Иногда терялись все сохранённые сессии, а при множестве активных сессий всё оставалось загружено в память, в частности, запущенные nvim процессы, которые поднимаю lsp, что со временем отъедало все больше и больше ОЗУ.

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

Так родился lazy-tmux, написанный на Go. Ключевые фичи:

  • Сохраняет текущую сессию, конкретную сессию или все сессии целиком. Снимки сохраняют окна, панели, layout, команды (например, npm, docker-compose, редакторы) и опционально scrollback историю шела.

  • Ленивое восстановление: поднимается только выбранная сессия. RAM не расходуется на всё сразу.

  • Интерактивный TUI браузер с деревом сессий, окон и панелей, таблицей с активными командами, временем последнего снимка, количеством окон/панелей и статусом сессии. Поддержка fuzzy search для быстрого поиска.

  • Навигация и полное управление сессиями и окнами с клавиатуры в TUI браузере сессий.

  • Гибкая сортировка сессий и окон через флаги --session-sort и --window-sort

  • Можно заменить встроенный TUI на fzf, использую облегчённый бинарник.

  • Автосейв через фоновый демон, периодически снимающий все сессии на диск.

  • Восстановление при старте tmux для автоматизации workflow.

Проект ещё молодой, но буду рад любой помощи и идеям по улучшению: GitHub issues

За моими новостями можно следить в Telegram-канале

Теги:
+3
Комментарии0

ingress-nginx официально переведён в архив

Репозиторий

24 марта 2026 года репозиторий kubernetes/ingress-nginx переведён в архив и стал read-only.

Проект просуществовал более восьми лет, набрал 20 тысяч звёзд на GitHub и стал стандартом для HTTP-маршрутизации в Kubernetes. Теперь поддержка и разработка полностью прекращена: новых релизов, багфиксов и патчей безопасности не будет.

Причина архива: ресурс Ingress изначально был слишком ограничен. Весь расширенный функционал реализовали через vendor-специфичные аннотации, нормального RBAC не было, протоколы: только HTTP/HTTPS. Gateway API решает все эти проблемы на уровне спецификации.

Мейнтейнеры рекомендуют переходить на реализации Gateway API:

"If you are not already using ingress-nginx, you should not be deploying it as it is not being developed. Instead you should identify a Gateway API implementation and use it."

Источник

Актуальные варианты: NGINX Gateway Fabric, Cilium, Envoy Gateway, Istio, Traefik.

Теги:
+5
Комментарии1

Худший бэкап — не тот, что не восстановился. А тот, что положил прод.

Что, если post-script не отработал? Моргнула сеть или случился таймаут. Внешний оркестратор просто пишет в лог failed и снимает задачу. А вот PostgreSQL об этом не знает. База остается в режиме бэкапа и начинает непрерывно копить WAL-файлы, ожидая команды на завершение.

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

Уметь дернуть pg_backup_start( ) — мало. Если СРК не имеет встроенного watchdog-механизма для сброса зависших сессий, резервное копирование превращается в угрозу доступности. Разделение ответственности — правильный архитектурный подход, но он означает, что защита базы от переполнения диска полностью ложится на ваши плечи.

О зависшем backup mode, разрывах PITR и других неудобных вопросах эксплуатации PostgreSQL совместно с Акурой поговорим в режиме live-демо на вебинаре 26 марта в 11:00 (МСК).

Регистрация по ссылкеПриносите в комментарии свои вопросы.

Теги:
0
Комментарии0

SIP-exporter: eBPF-мониторинг SIP-трафика для Prometheus

Хочу поделиться своим open-source проектом для мониторинга SIP-трафика — SIP-exporter. Это сервис, который использует eBPF для захвата пакетов прямо в ядре Linux и экспортирует метрики в Prometheus.

SIP-exporter — сервис, который захватывает SIP-пакеты (UDP/5060-5061) через eBPF socket filter, использует ringbuf для zero-copy передачи в userspace, парсит SIP в Go и экспортирует 40+ метрик в Prometheus, включает готовый дашборд для Grafana.

Архитектура: SIP Traffic → NIC → eBPF socket filter → ringbuf → Go poller → SIP parser → Prometheus

SIP-exporter экспортирует: активные SIP сессии (диалоги), SIP запросы по методам: INVITE, BYE, REGISTER, OPTIONS... SIP ответы по кодам: 1xx, 2xx, 4xx, 5xx, 6xx-, сессии.

Теги:
+1
Комментарии0

Ближайшие события

Покажем Internal Development Platform от Deckhouse на вебинаре 26 марта

Внутренние платформы разработки позволяют командам перейти от разрозненного набора инструментов к сервисному подходу. Разработчики получают self-service доступ ко всему необходимому — от создания окружений до управления quality gates и релизами — и могут работать автономно, не привлекая DevOps-команду.

Мы разработали собственную IDP — Deckhouse Development Platform, которая уже доступна для внедрения. 26 марта покажем её демо и расскажем: 

  • что вообще такое IDP и когда она будет полезна; 

  • на какие DORA-метрики влияет внутренняя платформа разработки;

  • для каких сценариев подойдёт Deckhouse Development Platform.

Регистрируйтесь и подключайтесь, если вы отвечаете за зрелость процессов разработки, масштабирование команд или платформенные сервисы.

Теги:
+2
Комментарии0

Неудобные вопросы про бэкап PostgreSQL: открытый разбор на вебинаре

Вокруг бэкапа PostgreSQL легко создать иллюзию, что все уже решено. Достаточно добавить в текст WAL, PITR, пару слов про консистентность и назвать агент «умным». Проблема в том, что в проде такие формулировки мало что гарантируют.

Можно ли вообще считать решение PostgreSQL-aware, если оно не живет внутри логики самой СУБД? Где проходит граница между нативными механизмами PostgreSQL и внешней платформой? Что происходит, если не доехал WAL-сегмент, не завершился post-script или восстанавливать нужно не весь инстанс, а один объект?

Из таких вопросов и вырос отдельный вебинар про PostgreSQL в Акуре, в формате открытого инженерного разбора: что здесь должна делать сама СУБД, что имеет смысл выносить во внешний слой, где начинаются реальные эксплуатационные проблемы и какие ограничения в таком подходе нельзя замалчивать.

План такой:

  • отдельно пройтись по WAL, PITR и консистентности;

  • обсудить, где файловый агент уместен, а где уже нет;

  • разобрать сценарии с ошибками pre/post-скриптов;

  • поговорить про восстановление в безопасную локацию и ручной recovery;

  • отдельно затронуть вопрос масштаба: почему на двух базах хватает shell-скриптов, а на пятидесяти уже начинается совсем другая жизнь.

26 марта 2026, 11:00 (МСК) Регистрация по ссылке. Приносите в комментарии вопросы, которые особенно хочется поднять в эфире.

Теги:
+4
Комментарии0

Разделяй и властвуй: вебинар про BSA-модель для IaC и опыт её применения «Магнит OMNI» 

Infrastructure as Code в компаниях нередко развивается стихийно: Terraform-скрипты копятся годами, репозитории разбросаны по командам, стандарты не зафиксированы. В результате инфраструктура остаётся сложной для понимания и управления.

Модель BSA (Base, Service, Application) помогает навести порядок: структурировать код, распределить ответственность и сделать процессы поставки предсказуемыми. На совместном вебинаре «Экспресс 42» и «Магнит OMNI» расскажем, как это работает на практике.

Вы узнаете:

  • как работает трёхуровневая модель BSA и как она распределяет зоны ответственности;

  • как устранить «функциональные колодцы» между DevOps-командами и инфраструктурными инженерами;

  • какие результаты дало внедрение BSA в «Магнит OMNI» и с чего начать в своей компании.

Регистрируйтесь по ссылке и подключайтесь 13 марта в 12:00, если вы управляете инфраструктурным кодом, развиваете платформенные сервисы или отвечаете за процессы поставки.

Теги:
0
Комментарии0

Запустили Yandex Monium — observability‑платформу собственной разработки

Сегодня мы открываем доступ к Monium — платформе для мониторинга и анализа работы IТ‑систем. Новое решение собирает и анализирует большое количество телеметрических данных, в том числе логов, трейсов и метрик в едином интерфейсе, а также позволяет визуализировать их в виде дашбордов. С помощью Monium можно следить за работой сервисов, приложений, а также ИИ‑агентов — независимо от того, где они находятся: в облаке или на ваших собственных серверах (on‑premises).

Изначально observability‑платформа была разработана командой Yandex Infrastructure для обеспечения стабильной работы внутренних сервисов компании. Сейчас с Monium ежедневно работают 16 тысяч сотрудников Яндекса, платформа обрабатывает 50 гигабайт логов в секунду. При возникновении проблем ответственным дежурным отправляются автоматические уведомления через различные каналы: мессенджеры, почту, звонки и другие системы.

Monium использует современные механизмы аутентификации и авторизации, а данные о пользователях на платформе шифруются. Платформа соответствует требованиям международных и российских стандартов безопасности, в том числе ISO, PCI DSS и ГОСТ Р 57580.

Yandex Monium находится в общем доступе — зайти и оценить фичи платформы можно из облачной консоли.

Теги:
Всего голосов 12: ↑12 и ↓0+12
Комментарии0

Как сейчас живется DevOps в разных компаниях и что будет дальше? Обсудили в новом выпуске подкаста МТС True Tech Talks 🎧

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

В новом выпуске к нам в гости заглянул Антон Егорушков — DevOps-эксперт и автор канала сыча. Вместе с Алексеем Костюковым, DevOps Lead в MWS, и Ариной Зайцевой, Senior DevOps в MWS, поговорили про то, как все меняется в профессии сейчас и что будет в будущем.

Обсудили:

  • что мотивирует в работе и профессии,

  • использование ИИ в рабочих задачах, 

  • варианты реализации IaC и EaC,

  • как лучше размещать инфраструктуру: on-prem, hybrid, one-cloud или multi-cloud,

  • каких изменений в DevOPS ожидать в ближайшие пару лет.

Смотрите и слушайте на удобной площадке: в VK Видео или на YouTube

Если было интересно — вступайте в сообщество МТС True Tech, чтобы быть в курсе лучших практик в ИТ.

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии0

Прошу помощи. Не могу найти документацию на плату. Купил когда-то на а**-э*****сс, но к ней не было в комплекте вообще ничего. За время поисков удалось найти только два фрагмента схемы. Мб есть у кого такая....

Теги:
Всего голосов 2: ↑2 и ↓0+3
Комментарии11

DevSecOps: как встроить безопасность в разработку и не тормозить релизы

DevSecOps — это подход, при котором безопасность перестает быть отдельным этапом перед релизом и становится частью всего жизненного цикла продукта. Проверки уязвимостей, контроль зависимостей и анализ конфигураций встраиваются прямо в CI/CD-пайплайн — команда получает обратную связь сразу, а не после деплоя в продакшн.

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

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

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Где хранить код и как настроить CI/CD, если GitLab CE уже не хватает

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

У нас есть готовое решение для такого случая. На вебинаре 27 февраля мы расскажем о Deckhouse Code — единой платформе для непрерывной разработки и управления жизненным циклом ПО:

  • Покажем, как настроить правила слияния, CODEOWNERS, push rules и безопасно хранить секреты вне платформы.

  • Обсудим, как сократить нагрузку на команды за счёт managed-подхода.

  • Проведём живое демо от коммита в консоли до артефакта в registry.

Регистрируйтесь и подключайтесь, если вы отвечаете за CI/CD в корпоративной среде. Автор лучшего вопроса в чате вебинара получит персональное демо под свою задачу.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Всем привет! Сделал Тетрис, в который можно играть в терминале. Получилось вполне залипательно)

Tetris
Tetris

Что умеет:

  • Все 7 фигур с wall kick при повороте

  • Превью следующей фигуры

  • Очки, линии, уровень

  • Скорость растёт с уровнем

  • Рекорд за сессию

  • Пауза, рестарт на ходу, экран game over

  • Центрируется в окне терминала

Видео геймплея
GitHub

Установка:

curl -sSL https://raw.githubusercontent.com/oakulikov/tetris/main/install.sh | bash

На Windows: открыть WSL/Ubuntu терминал и выполнить ту же команду.
Потом просто tetris.

Теги:
Всего голосов 9: ↑8 и ↓1+7
Комментарии5

Redis упал.

Периодически Redis падает по OOM.

Интересно послушать разные мнение , на что стоит обратить внимание. Есть решение , почему происходит OOM .

Буду очень признателен комментарию . 🤝

Теги:
Всего голосов 6: ↑3 и ↓30
Комментарии8

Ребята, в свете блокировок Telegram я накидал bash-скрипт который сделает всю магию и поднимет вам прокси за пару минут. На выходе получите адрес прокси и сразу им поделиться с друзьями... 

Можете ставить на свои VPS-ки одной командой: 

curl -sSL https://raw.githubusercontent.com/itcaat/mtproto-installer/main/install.sh | bash

Исходники тут: https://github.com/itcaat/mtproto-installer

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 6: ↑6 и ↓0+7
Комментарии0

Статический анализ и ASOC: нулевая терпимость к ошибкам в проекте

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

Что делать в такой ситуации? Самый эффективный путь — не дать дефекту шанса появиться в коде. Именно эту задачу решает политика нулевой терпимости к ошибкам.

Причём внедрение такой политики не заканчивается на установке новых инструментов. Безопасность должна стать неотъемлемой части процесса разработки, а не проверяться постфактум. Такой подход позволяет не просто выявлять уязвимости, а предотвращать их попадание в основную ветку.

В статье обсудим, что такое политика нулевой терпимости и то, как статический анализ и ASOC помогут её достичь.

Теги:
Всего голосов 3: ↑3 и ↓0+4
Комментарии0

Только что я релизнул cli-stash v0.2.9. Теперь можно редактировать сохраненную команду.

cli-stash - tui-тулза для добавления терминальных команд в избранное, с возможностью переноса из истории

Кейсы использования такие:

  1. Вы хотите параметр заменить на какое то ключевое слово. Например, я хочу в избранное добавить команду dig для определения NS серверов, которые отдает нам 1.1.1.1. Я не хочу видеть захаркорженные значения. И чтобы было красиво меняю их просто на ключевые слова. Это дает больше эстетического удовольствия при использовании команды - не более.
    Ну и в будущем я подвезу автосинк с шарингом на команду, так что может быть полезно.

  2. Да просто надо поменять команду - почему бы не дать такую возможность =)

Пример редактирования
Пример редактирования

Кстати, тут вопрошали сколько 🌟 наберет тулза в github - пока всего 37. Ну а что это за инструмент и чем он может быть полезен можно подробнее прочитать в предыдущем посте.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 4: ↑4 и ↓0+4
Комментарии0

Ребята, я сегодня релизнул cli-stash. Это TUI-утилита на Go + Bubble Tea для сохранения shell-команд в "избранном".

Пример использования cli-stash
Пример использования cli-stash

Она решает простую боль: сложные команды (docker, kubectl, ffmpeg) постоянно забываются, а копаться в history каждый раз это страдание.

Что умеет:

  • Сохраняет ваши команды в избранном

  • Возможность добавить из истории шелла

  • Нечеткий поиск

  • Сортировка по частоте использования

И самое крутое, что команда вставляется прямо в терминал. Таким образом вам не надо ничего копипастить: нашел → выбрал → enter → команда уже в cli.

# Установка в Linux
go install github.com/itcaat/cli-stash@latest

# Сборка из исходников
git clone https://github.com/itcaat/cli-stash.git
cd cli-stash
go build -o cli-stash .
sudo mv cli-stash /usr/local/bin/

В macOS поставить изян brew install itcaat/tap/cli-stash

Исходники и инструкция по использованию есть на github.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 9: ↑8 и ↓1+8
Комментарии10

Сегодня хочу поднять тему, которую редко обсуждают отдельно, но без неё Docker просто не работал бы так стабильно и предсказуемо - манифесты образов.

Периодически в разные частях документации или статьях про Docker вы будете встречать "манифесты". Обычно это звучит как что-то второстепенное: мол, есть какая-то мета-информация, по которой Docker собирает образ из слоёв.

Но на деле это одна из ключевых деталей, которая отвечает за то, что контейнеры:

  • воспроизводимы

  • одинаковые на разных машинах

  • и не превращаются в "ну у меня работало".

Я попытаюсь все описать максимально просто.

Docker Manifest - это JSON-документ, который описывает образ. Можно представить его как схему или инструкцию, по которой Docker понимает:

  • какие слои относятся к образу

  • какие контрольные суммы должны быть у каждого слоя

  • в каком порядке их нужно использовать

  • для какой ОС и архитектуры этот образ подходит

И важный момент: когда ты делаешь docker pull, Docker сначала получает манифест, а уже потом начинает скачивать слои.

Как посмотреть манифест самому: docker manifest inspect nginx:latest.

Тут можно заметить, что один тег (nginx:latest) может ссылаться сразу на несколько вариантов образа - например под amd64 и arm64. Это как раз история про multi-arch. Иногда под словом manifest имеют в виду не сам образ, а manifest list (index). Это как меню: Docker смотрит на твою платформу и выбирает подходящий вариант (amd64/arm64).

Каждый слой Docker-образа имеет SHA256-хеш, который вычисляется из его содержимого.

Логика максимально простая:

  • поменялся файл

  • поменялось содержимое

  • поменялся хеш

  • значит получился другой слой

По сути это очень похоже на философию Git: всё завязано на содержимое, а не на "имя файла".

Docker Registry использует Content Addressable Storage - то есть хранит и раздаёт данные не по названию, а по их хешам.

Что происходит при push / pull?

Если упростить до понятной схемы, то процесс примерно такой:

  • клиент сначала отправляет/получает манифест

  • registry проверяет хеши и наличие слоёв

  • передаются только те слои, которых ещё нет

  • каждый слой проверяется по SHA256

То есть никакой лишней передачи данных и никаких "примерно совпало".

Комбинация манифестов и хешей даёт сразу несколько сильных преимуществ:

  • Безопасность - слой нельзя незаметно подменить

  • Экономия места - одинаковые слои не хранятся по сто раз

  • Целостность - скачанное гарантированно равно загруженному

  • Версионирование - образ это конкретная комбинация слоёв, а не “что-то похожее”

Именно поэтому условный nginx:latest на dev и на prod - это реально один и тот же образ, а не "почти такой же, но чуть другой". Ладно, давайте будем более дотошными. На самом деле нет - использовать latest плохая практика. За время пока образ приехал,- там уже могут быть разные образы.

Как минимум используйте конкретный тег, а еще лучше даже sha256 docker pull nginx@sha256:...

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 4: ↑2 и ↓20
Комментарии0

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

Речь про vi...😱 

Как выйти из vi? Никак. Это не редактор, это пожизненный контракт.

Я открыл vi один раз в 2009 году. С тех пор у меня один и тот же терминал, потому что я всё ещё пытаюсь выйти.

Если ты случайно запустил vi на проде — проще выкинуть сервер, чем найти правильную комбинацию клавиш.


Это тот самый редактор, который в обычной жизни можно спокойно не трогать годами… А потом ты оказываешься в air-gap, где:

  • нет vscode

  • нет nano

  • нет mc

  • иногда даже less нет и кажется, что у тебя есть только vi и судьба

И вот ты открываешь конфиг… и мозг такой: эээээ мы не умеем, всё, до свидания.

Давай разберёмся, как перестать бояться vi и научиться выживать с ним спокойно.

Почему vi вызывает ступор? Потому что он не работает как обычные редакторы. Ты нажимаешь клавиши - а текст не печатается. Пытаешься выйти - не выходит. И где-то рядом уже открывается вкладка “как выйти из vi”, но интернет… в другой реальности.

Главное, что нужно понять - в vi есть несколько режимов:

  1. Normal mode - это режим команд и перемещения. Тут ты не печатаешь текст, а управляешь редактором.

  2. Insert mode - это режим, где можно реально редактировать и вводить текст.

  3. Command mode (через :) - cохранение, выход, всякие служебные команды и тд

Минимальный набор клавиш, чтобы выжить:

  • Войти в редактирование -> i, a, o

  • Вернуться обратно в команды -> Esc

  • Сохранить файл -> :w

  • Выйти -> :q

  • Сохранить и выйти -> :wq

  • Выйти без сохранения -> :q!

Полезные команды, которые реально пригодятся:

  • удалить строку -> dd

  • вставить строку ниже -> o

  • отменить действие -> u

  • повторить последнее действие -> .

  • поиск: / и дальше текст который ищем

Пример: быстро поправить конфиг и уйти живым

vi /etc/hostname

Дальше всё по шагам:

  1. нажми i и внеси правки

  2. нажми Esc

  3. введи :wq

  4. готово - конфиг сохранён, ты победил

А если ты хочешь владеть vi как ниндзя, то вот тебе Vim Cheat Sheet https://vim.rtorr.com/

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 8: ↑7 и ↓1+7
Комментарии14

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

Наверняка знакомо ощущение: смотришь логи через tail -f, делаешь какое-то действие - рестарт сервиса, деплой, правку конфига - и потом пытаешься глазами понять, где закончился старый вывод и началось новое. Спойлер: это не всегда просто.

Для таких случаев существует крошечная, но очень полезная утилита
spacer: https://github.com/samwho/spacer

Она вставляет визуальные разделители прямо в поток вывода и отлично работает в реальном времени. Без магии, без лишних настроек - просто аккуратно отделяет "было" от "стало".

В итоге это неожиданно удобно:

  • при отладке,

  • при сопровождении сервисов,

  • при поиске изменений в логах после конкретных действий.

Отдельный плюс - минимализм. Никаких зависимостей, ничего лишнего: скачал, поставил, используешь. Именно тот случай, когда инструмент делает ровно одну вещь - и делает её хорошо.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 9: ↑8 и ↓1+8
Комментарии0

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

Ответ неожиданно нашёлся в одном месте - canitrundoom.org. Это не сайт и не галерея, а настоящий музей инженерного безумия, где люди снова и снова доказывают, что если есть процессор и немного упрямства, то DOOM запустится.

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

Смотришь на всё это и вдруг понимаешь: пределы возможностей куда дальше, чем кажется. Если DOOM смог заработать там, где для этого не было ни интерфейсов, ни смысла - то уж доставить очередной говнокод в прод - вообще же плевое дело.

Очень рекомендую заглянуть и дать мозгу немного свободы.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 4: ↑1 и ↓30
Комментарии0

“Наши руки не для скуки” (с). Я давно хотел накидать скрипт для супер быстрой диагностики Linux. Конечно, это не замена полноценному мониторингу. Это  дополнительный инструмент, который вы можете использовать в своем арсенале чтобы упростить себе жизнь. Самое главное что он сэкономит кучу времени.

В отчете вы получите:

  • Системную информацию - версия ОС, ядро, архитектура, uptime, внешний IP

  • Аппаратные ресурсы - CPU, RAM, Swap, температура процессоров

  • Дисковое пространство - занятое место, inodes, SMART статус

  • Тест скорости дисков - скорость записи/чтения (100MB тест)

  • Сетевые интерфейсы - статус, ошибки, активные соединения

  • Тест сети - ping до шлюза, ya.ru и 8.8.8.8 (по 10 пакетов каждый), скорость интернета

  • Процессы - топ по CPU и памяти, zombie процессы

  • Системные логи - критические ошибки, OOM события, kernel warnings

  • Системные службы - проверка упавших служб

  • Безопасность - неудачные входы, активные SSH сессии

  • Docker - статус контейнеров и их ресурсы

Пример запуска (можно без sudo - но там не будет всех показателей):

curl -o ~/linux-diag-script.sh https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh
chmod +x ./linux-diag-script.sh
sudo ./linux-diag-script.sh

# Одной командой
curl https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh | sudo bash

Бонусом в скрипте встроена возможность получать Telegram уведомления и сам отчет при обнаружении проблем. Для этого надо создать бота и добавить в выполнение скрипта в cron.

  1. Найди [@BotFather](https://t.me/BotFather) в Telegram

  2. Отправь команду /newbot

  3. Следуй инструкциям и получи токен бота (например: 123456789:ABCdefGHIjklMNOpqrsTUVwxyz)

  4. Получи Chat ID:

        - Отправь сообщение боту

        - Откройте:  https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates

        - Найди "chat":{"id": - это твой Chat ID

Теперь можешь добавить в cron (подставь свой botToken и chatId) и будешь получать уведомление в telegram если будет обнаружена какая то проблема.

# Проверка каждые 6 часов
0 */6 * * * root TELEGRAM_BOT_TOKEN="your_token" TELEGRAM_CHAT_ID="your_chat_id" /usr/local/bin/linux-diag-script.sh >/dev/null 2>&1

Актуальная версия скрипты доступна на GitHub Gist.  Вы можете модифицировать его под свои нужды, добавлять новые проверки или как то интегрировать в runbook-и.

Пишите что еще можно добавить - я добавлю.

---

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
Всего голосов 7: ↑3 и ↓4+1
Комментарии0

Скрытые уязвимости в CI/CD: что мы упускаем и как защитить процесс доставки

CI/CD давно перестал быть просто удобным способом ускорить релизы. Сегодня это критическая часть цепочки поставки, через которую проходит весь код, зависимости и инфраструктурные изменения. Именно поэтому пайплайн всё чаще становится целью атак, при этом многие уязвимости остаются незаметными годами.

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

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

Отдельного внимания заслуживает хранение секретов. Даже при использовании секретных хранилищ они нередко утекaют в логи, артефакты или кэши. Проблема усугубляется тем, что логи CI часто доступны большему кругу людей, чем production-системы.

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

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

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

CI/CD — это не просто автоматизация, а часть поверхности атаки. Чем раньше это осознаётся, тем меньше шансов, что уязвимость проявится уже после успешного релиза.

А какие риски в своих пайплайнах вы обнаружили только со временем?

Теги:
Всего голосов 2: ↑1 и ↓1+2
Комментарии1

Kubernetes Zero to Hero — базовый видеокурс от «Фланта»

Если вы хотите изучить основы работы с Kubernetes, мы сняли подходящий для этого видеокурс. Из него вы получите практические знания, которых будет достаточно для решения большинства типовых задач.

В курсе 10 коротких — до 10 минут — видео. Они рассчитаны на начинающих разработчиков с опытом в продуктовой разработке, учебных или личных проектах, где возникает потребность в Kubernetes. С нами вы:

  • поднимете локальный кластер и разберётесь в ключевых сущностях Kubernetes;

  • научитесь развёртывать приложения, пройдя путь от коммита кода в Git-репозиторий до его выката в кластер;

  • поймёте, как устроены сетевое взаимодействие внутри кластера и доступ к приложениям извне;

  • познакомитесь с werf и Helm, шаблонизацией чартов и практиками реальных проектов.

Два первых ролика уже доступны. Во вводном будут план курса и желательный для старта бэкграунд, а второй поможет поднять локальный кластер Kubernetes с помощью Minikube и получить готовое окружение для экспериментов. Смотрите на удобной вам площадке:

Каждую неделю будет выходить по два ролика — по вторникам и четвергам. Присоединяйтесь, будем вместе проходить путь от новичка до Kubernetes Hero.

Теги:
Всего голосов 9: ↑8 и ↓1+7
Комментарии0

Kotlin и Hyperskill: как я искал курс и что получил в итоге.

Когда я решил изучать Kotlin, ожидал, что найти хороший курс будет просто: язык популярный, используется в Android и бэкенде, вокруг много материалов. Искал менторов и упирался в людей которые знаю java и вроде как используют в работе Kotlin. Это одновременно пугало и заинтересовывало, я решил поступить как мне казалось правильным, найти готовый курс  — особенно если хочется не “смотреть видео”, а именно учиться через практику и задачи.

Я перепробовал разные форматы обучения (платные и бесплатные), поэтому в этот раз подход был простой: найти платформу, где есть структурированная программа и много практики. В итоге я добрался до Hyperskill (hyperskill.org). Это не реклама — просто личный опыт, кому-то он может сэкономить время.

Как я пришёл к ресурсу.

Изначально искал курсы по Kotlin на привычных площадках. На Stepik в тот момент не нашёл того, что мне подходило по структуре (возможно, сейчас ситуация лучше). Видео-курсы на крупных “известных сайтах” сознательно не рассматривал: мне удобнее формат “прочитал → сделал → получил проверку”.

Дальше — обычный путь через поисковик и сравнение нескольких платформ. Из того, что выглядело цельно и практично, больше всего зацепил Hyperskill. Отдельно сыграло роль то, что платформа связана с JetBra…. (то есть ребята явно понимают, как устроена экосистема вокруг Kotlin и IDE).После регистрации быстро становится понятно: платформа активно ведёт к подписке.Раньше в сети встречались статьи про возможность оформить бесплатную подписку на полгода, но это устаревшая информация — сейчас такой опции нет (по крайней мере, в том виде, в каком её описывают старые гайды).

При этом у Hyperskill есть бесплатный режим, и я проходил курс именно так.

Что я проходил: Introduction to Kotlin.

На платформе несколько треков по Kotlin, я начал с Introduction to Kotlin. По ощущениям, это “введение с практикой”:

  • около 9 учебных проектов

  • порядка 60–70 тем

  • внутри тем — задачи/тренажёры с автоматической проверкой

В целом структура понравилась: материал подаётся дозировано, и почти сразу закрепляется практикой. Похожая на Степик.

Система “кристаллов” и лимиты.

Самая спорная часть бесплатного режима — ограничения на попытки.

У Hyperskill есть внутренняя валюта (“кристаллы”): ошибаешься в заданиях — кристаллы списываются. Когда кристаллы заканчиваются, обучение может блокироваться на 12–24 часа. Да, кристаллы можно зарабатывать активностью и выполнением некоторых задач, но при активном обучении и регулярных ошибках (что нормально) этого может не хватать.

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

Проекты: что внутри и зачем это полезно.

Сильная сторона Hyperskill — проекты. Они не выглядят как “игрушки ради галочки”, а позволяют постепенно потрогать основные конструкции языка.

Из того, что запомнилось:

  • “Сапёр”

  • “Крестики-нолики”

  • “Чат-бот”

  • “Кофемашина”

Например, в проекте “кофемашина” уже нормально используются циклы, классы и базовые элементы ООП. В таком формате проще понять, “зачем оно нужно”, чем на изолированных задачках.

Минус: часть проектов закрыта платной подпиской, и это немного обидно — именно проекты дают максимальную пользу и ощущение прогресса.

Проверка решений: не всегда понятно, почему “не принято”

Ещё один недостаток — качество обратной связи в тестах. Иногда тесты “падают” так, что ты видишь только факт ошибки, но не понимаешь причину: что именно ожидалось, на каком кейсе сломалось, где расхождение.Часть проектов проверяется через IntelliJ IDEA, и здесь иногда всплывают технические нюансы: несовпадение версий, необходимость обновить IDE или компилятор, странные падения на конкретном проекте.

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

Итоги:

  • бесплатный режим может раздражать лимитами на ошибки (кристаллы и блокировки)

  • часть контента (включая проекты) закрыта подпиской

  • обратная связь тестов местами недостаточно информативная

    Если готовы, то вперед!

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Поиск партнёра для совместной инженерной проверки идей (не найм)

Сразу обозначу границы, чтобы не тратить время друг друга.

Я не ищу работу, не нанимаю, не продаю услуги и не собираю команду.
Интересует формат равного партнёрского взаимодействия на уровне мышления и проверки гипотез.

Контекст

Мой бэкграунд - backend / инфраструктура / системы.
Умею проектировать и собирать техническую часть, доводить до рабочего состояния, автоматизировать, поддерживать.

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

Что именно ищу

Ищу одного человека, с которым можно:

  • разбирать идеи без романтизации

  • проверять гипотезы на реализуемость и смысл

  • делать небольшие, ограниченные по времени и объёму пробы (MVP / прототип / концепт)

Речь не про «стартап мечты», а про инженерный подход к неопределённости.

Кого не ищу

  • менторов и гуру

  • инвесторов

  • людей, ожидающих «готовый проект»

  • мотивационные разговоры без действия

Формат

  • асинхронная переписка

  • созвон 45–60 минут

  • если не совпали по подходу - спокойно расходимся

Без обязательств, без разговоров про доли, без долгих ожиданий.

Почему сейчас

Инструментов и ресурсов стало достаточно, чтобы проверять идеи быстро и дёшево.
Интересно найти человека, которому близка аккуратная инвестиция времени и внимания - с пониманием, что результат не гарантирован.

Контакт для связи: Telegram @sachconzales

Теги:
Рейтинг0
Комментарии1

💀 Когда диаграмма - источник истины, архитектура умирает первой.

📝 Аналитики, использующие PlantUML, Miro, Draw.io, Visio, Structurizer и прочее, забывают что знания в диаграммах - всё равно что код в скриншотах.

Знания должны храниться в виде взаимосвязанных элементов Модели, а диаграммы должны быть лишь их Проекциями. Разработчики ArchiVision.org это прекрасно понимают. Именно это делает систему ArchiVision значительно более эффективным инструментом для хранения знаний об ИТ системах чем все вышеназванные сервисы. При этом, генерируемые ею диаграммы живые, интерактивные и редактируемые. Система также поддерживает горячие клавиши для эффективной работы с моделью и диаграммами. Горячие клавиши позволяют рисовать быстрее, чем большинство перечисленных сервисов, тем более чем писать в PlantUML, Structurizer и аналогичных.

⚡ Ключевое отличия:
- 👎 в названных выше инструментах вы редактируете диаграммы;
- 👍 в ArchiVision вы работаете с моделью, а диаграммы - это её визуальная проекция, через которую тоже можно развивать модель.

🔄 За счет этого:
- 🧠 модель становится единственным источником истины;
- 🧱 диаграммы перестают быть хрупким артефактом;
- 🧩 структура модели позволяет устранять разночтения, дублирование и рассинхронизацию;
- ✅ система способна контролировать ввод и проверять полноту данных;
- 🧼 архитектура перестаёт расползаться по версиям и интерпретациям;
- ⌨️ навигация и горячие клавиши — это часть работы с моделью, а не удобство интерфейса.

🎥 Это видео - пример того, как сочетание модели, интерактивных диаграмм и горячих клавиш меняет процесс проектирования.

Ну а вот сам канал с видеоинструкциями находится здесь.

Теги:
Всего голосов 2: ↑1 и ↓1+2
Комментарии2

IMPulse - Open Source менеджмент инцидентов. Freeze, Jira, ChatOps

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

Из нового

  • У нас появился механизм Freeze, который выполняет пару задач. С одной стороны он отключает уведомления по инциденту на некоторое время, например на выходные. С другой - исключает создание таких же инцидентов на время "заморозки". Этот функционал похож на Silence Alertmanager'а.

  • Появилась интеграция с системой трекинга задач, Jira.

  • Теперь есть возможность просматривать закрытые (архивные) инциденты.

  • Добавлены метрики.

  • IMPulse теперь можно запускать в нескольких экземплярах. В случае недоступности основного (primary) инстанса, работу подхватит запасной (standby).

  • Webhook'и стали ещё мощнее. Теперь с их помощью можно очень гибко формировать JSON для отправки в любую сторонюю систему.

  • Появилась интеграция с алертами из Grafana.

  • IMPulse научился перечитывать (reload) конфигурацию без полной перезагрузки. Также вы можете добавить проверку конфигурации в CI/CD перед её применением.

  • В UI теперь есть индикатор online / offline, чтобы понимать, актуальная ли сейчас информацию на экране. К слову, несмотря на внешнюю простоту, UI очень гибок: умеет фильтровать инциденты по лейблам (в качестве фильтров можно использовать regex'ы), можно сортировать инциденты по нескольким столбцам, а также выделять цветом интересующие данные.

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

Планы

В первой статье я уже упоминал, что мы считаем крайне важным для всех, кто работает с инцидентами, иметь общий контекст. Многие решения при проектировании принимались, исходя из этого. Сейчас можно констатировать, что ChatOps стал основой IMPulse и дальнешее движение будет под этим знаменем. Мы будем глубже интегрироваться с мессенджерами, чтобы команде дежурных / devops'ов не нужно было переходить в UI. Да, обязательно останутся задачи, которые не решить в рамках мессенджера, но мы постараемся минимизировать их количество.

Здесь часть из наших планов на ближайшие пару месяцев:

  • добавить работу с группами в Slack и Mattermost;

  • добавить в UI механизм аутентификации;

  • перенести кнопки для работы с инцидентами в UI;

  • реализовать механизм подавления инцидентов на основе правил по аналогии с Inhibition в Prometheus. Если согласно правилам инцидент становится дочерним, то уведомления по нему прекращаются пока не будет решена основная проблема. Это позволит уменьшить количество активности по инцидентам.

По поводу других новшест мы пока сохраним интригу!

Критика и советы

Мы растём, решаем всё больше проблем, но конечно же всегда остаются незакрытые потребности. Будем рады услышать, чего не хватает лично вам и постараемся с этим помочь. Особенно интересно услышать мнение людей, которые ищут куда мигрировать с Grafana OnCall. Мы открыты к обратной связи и критике, будем рады услышать замечания. Наша задача - стать лучше благодаря сообществу.

Оставайтесь с нами в Telegram - мы используем его для общения с русским сообществом, следите за обновлениями в GitHub. Мы продолжаем!

Предыдущие публикации

Теги:
Всего голосов 3: ↑1 и ↓2-1
Комментарии0

Новогодняя задача: помогите Тирексу поздравить коллег

Условие

Программист Тирекс написал праздничное веб-приложение с обратным отсчетом до Нового года и хочет поздравить им всех коллег. Приложение уже собрано: в директории web находятся готовые статические артефакты (HTML, JavaScript и изображения). У Тирекса есть TLS-сертификат и приватный ключ, и он хочет, чтобы приложение работало по HTTPS.

Задача

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

Создайте конфигурацию nginx, которая:

  • слушает порт 80 и выполняет 301-редирект на HTTPS (https://$host$request_uri);

  • слушает порт 443 с включенным SSL;

  • использует сертификат /etc/nginx/ssl/cert.pem и ключ /etc/nginx/ssl/key.pem;

  • отдает статические файлы из /usr/share/nginx/html по пути /.

Напишите Dockerfile, который:

  • копирует в  контейнер конфигурацию nginx и артефакты приложения

  • создает пустую директорию /etc/nginx/ssl (для монтирования сертификатов при запуске);

  • использует легкий образ (например, nginx:alpine).

При запуске контейнера должны быть опубликованы порты 80 и 443.

Бонусная задача

Добавьте docker-compose.yml файл, чтобы запускать приложение одной короткой командой из папки с сертификатами.

Предлагайте варианты решения в комментариях. А посмотреть правильный ответ можно в Академии Selectel.

Теги:
Всего голосов 5: ↑5 и ↓0+9
Комментарии2

Философия IT-собеседований: взгляд разработчика и DevOps-инженера

Привет, Хабр! Мой пост носит дискуссионный характер. В веб-разработке, администрировании и DevOps я уже 17 лет. Долгое время работал «на себя», оказывая помощь клиентам, с которыми выстроены надёжные взаимоотношения, но текущие реалии рынка подтолкнули к поиску работы по ТК, об этом я и хочу поговорить.

Обо мне: 40 лет, из которых 17 лет в коммерческой разработке. Прошел долгий путь как в fullstack-разработке (web), так и в создании embedded-решений (каршеринг), администрировании и DevOps.

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

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

  1. Диалог на равных.
    Мое лучшее интервью: техлид не мучил теорией, а предложил обсудить реальную дилемму, которую он решает в данный момент (внедрение NoSQL-хранилища ради одного специфичного сервиса, т.е. доп. точка отказа vs производительность). Без таймера и стресса мы искали решение. Итог — оффер и годы отличной работы.

  2. Проверка логики, а не памяти.
    Люблю кейсы в духе: «Вот дано А, почему происходит Б?». Из банального: может ли Вася из другого города достучаться до вашего локального IP? Это показывает понимание базы лучше любого теста.

  3. Ценность универсальных знаний.
    Универсальные знания долгое время позволяли быстро находить решение практически любой проблемы от хардверной, до нарушения самых элементарных паттернов проектирования в коде и эффективно их устранять. Мне нравятся задачи, где проблема может быть скрыта на любом уровне и нравятся клиенты, понимающие, как я могу снять их головную боль обеспечив работоспособность ПО в любой среде и условиях.

А теперь я хочу описать то, от чего меня бомбит. Это факторы которые будут отпугивать меня вплоть до момента, когда будет нечего кушать и я буду вынужден прогнуться под выгодное предложение.

  1. Лайвкодинг.
    В 40 лет написание кода для меня — процесс интимный... хотя я практикую парное программирование в реальной команде и это мне нравится, но в предвкушении собеседований иногда хочется "психануть" и на предложение выбрать время для лайвокдинга сказать — "предлагаю парное программирование с одним из ваших специалистов, ведь для меня тоже важно, с кем я буду вести разработку". (Не пробовал так отвечать, но попробую, как только выдастся случай).

  2. Вакансии-обманки.
    Зачем заманивать стеком DevOps (Linux, Nginx, Ansible, Terraform, Puppet, Docker, Kubernetes, MySQL, PostgreSQL, Elasticsearch, Logstash, Kibana, Zabbix), если по факту сообщаете, что ничего этого не будет, а ищите классического сисадмина 9-18? — Давайте адкеватный запрос, а не тратьте время.

  3. Терминологическая каша. Сложно отвечать экспертно, когда интервьюер путает CI и OCI или Redis и Rabbit. Если нет погружения в контекст, конструктивного диалога не выйдет. Готовиться к собеседованию должен не только соискатель, но и тот, кто нанимает.

  4. Отсутствие пунктуальности.
    Для меня было шоком, что фаундер может просто не явиться на собседование, или рекретер забывает о диалоге и назначенной встрече. У вас там всё нормально?) Хотя рекрутер мало чем отличается от агента недвижимости, но фаундер забывающий про собеседование для меня персонаж странный.

  5. Узкая специализация.
    Раньше, как мне кажется, ценилась универсальность, способность разработчика понимать инфраструктуру, а инженера/админа — код. Сегодня индустрия уходит в жесткую сегментацию, видимо, для более точного просчёта рисков. А я считаю, что именно универсальность — это страховка проекта от того, что решение будет принято в вакууме одного стека, без учета общей картины.

Теги:
Всего голосов 6: ↑6 и ↓0+7
Комментарии2
1
23 ...