Обновить
316.33

DevOps *

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги:
+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.

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

Redis упал.

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

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

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

Теги:
0
Комментарии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
Комментарии0

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

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

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

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

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

Теги:
+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
Комментарии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 🧠 ↩

Теги:
+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 🧠 ↩

Теги:
0
Комментарии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 🧠 ↩

Теги:
+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
1
23 ...