Эпоха комфортного программирования подходит к концу. Пока программисты ваших конкурентов потягивают тыквенный латте и вяло ждут окончания медленных пайплайнов, GitCrab превращает ваш репозиторий в суровую экосистему, где выживает только сильнейший.
Большинство CI/CD инструментов помогают вам деплоить. GitCrab заставляет вас бороться.
Сервер лагает. Смотришь на диск - df -h говорит 95% занято. Запускаешь du -sh /* - в сумме набирается 20%. Куда делись остальные 75%? Файлы не найти, место не освободить, сервис падает.
Это не баг и не магия. Это фундаментальная особенность того как Linux работает с файлами. Разберём почему так происходит и как это чинить за две команды.
df и du смотрят на файловую систему с разных сторон.
df читает метаданные файловой системы напрямую - сколько блоков выделено, сколько свободно. Это данные суперблока, они обновляются мгновенно при любом изменении.
Представьте: вы открываете Grafana в три часа ночи по алерту. На экране — 30 дашбордов, сотни графиков, и везде мигает жёлтым. CPU 60%, connections 50%, replication lag 500ms, bloat растёт, dead tuples накапливаются. Ни один показатель не пробил красную черту — но что-то явно идёт не так. База тормозит. Пользователи жалуются. А вы стоите перед этим океаном данных и пытаетесь понять: это уже пожар или ещё можно ждать до утра?
Это не гипотетическая история. Именно в такие моменты становится ясно: мониторинг PostgreSQL сломан на уровне концепции. Не потому что метрик мало — их избыток. Проблема в том, что нет единого ответа на вопрос «база здорова?».
Знакомая ситуация: просишь Claude Code добавить авторизацию — он переписывает половину проекта. Просишь поправить одну функцию — получаешь удалённые тесты и новую зависимость, о которой не просил. За час строишь рабочий прототип, а потом три часа разгребаешь то, что Claude наворотил при «улучшении».
Я бэкенд-разработчик на Python, работаю в основном один. У меня нет роскоши держать QA-инженера, который будет ловить регрессии после каждого промпта. Мне нужно, чтобы AI-агент помогал быстрее шипить, а не создавал новые проблемы.
Всем привет! Я около 10 лет в разработке и последние 5 лет полностью живу в экосистеме JetBrains. За это время у меня накопилось порядка 150 репозиториев — рабочие проекты, личные эксперименты, демо, инфра. Всё это, конечно, аккуратно разложено по папочкам, помечено тегами в Finder и добавлено в быстрый доступ.
И долгое время этого хватало.
Я работаю с несколькими клиентами. Активных проектов обычно около 25 штук. С таким количеством стандартный Recent Projects в IntelliJ IDEA справляется прекрасно: быстро ввёл название сервиса в поиск — быстро открыл. Никаких проблем.
Я студент и соло‑разработчик, который только начинает заходить в devops‑тематику. Сам я не админ и не держу в проде десяток серверов, поэтому решил не выдумывать «боли» из головы, а посмотреть, на что реально жалуются люди в статьях и форумах.
Одна жалоба повторялась достаточно часто: «Когда что‑то падает, приходится обходить несколько серверов, смотреть логи по отдельности и пытаться сложить картину вручную. ELK/syslog решают, но ради пары сервисов это перебор.»
После этого я решил собрать небольшой прототип LogRangerЧитать полностью »
Все, кто плотно сидит на C++ и использует Conan, знают: сам по себе пакетный менеджер — это только полдела. Настоящее веселье начинается, когда нужно раскатать одинаковые настрйки на всю команду и десяток CI-нод. Репозитории, профили, хуки, кастомные настройки всё это хозяйство нужно как-то синхронизировать.
Раньше у нас был conan config install, который тянул конфиги из git-репозитория или zip-архива. Решение рабочее, но с душком: попробуйте воспроизвести сборку двухлетней давности, если за это время мастер-ветка с конфигами улетела далеко вперед.
В Conan версии 2.x (и последних минорных обновлениях) завезли киллер-фичу: Читать полностью »
Это история о том, как желание просто проверить, жив ли мой блог, привело к трём дням танцев с бубном вокруг SSL-сертификата, а затем — к созданию собственного сервиса мониторинга, который теперь используют сотни разработчиков. Расскажу, почему существующие решения перестали устраивать, как мы реализовали поддержку UDP и ICMP в облаке и почему мониторинг должен быть «скучным».
Год назад у меня была простая задача: настроить уведомления о падении личного блога и API пары пет-проектов. Думал, уложусь в 15 минут.
Спойлер: не уложился.
Десять лет в девопсе. Десять. И я гуглю tar -xzf. Не раз в год — раз в неделю. Ну, может раз в десять дней, если повезёт. Открываю хром, набираю «tar extract gz linux», пролистываю три рекламы, нахожу ответ на SO, копирую, вставляю, закрываю вкладку. Через неделю — по новой.
Я не идиот. Точнее, может и идиот, но не поэтому. Просто tar — это такой синтаксис, который у меня физически отказывается залезать в долговременную память. Там дефис или нет? xzf или xfz? Или zxf? Вроде порядок не важен? Или важен?..
Короче. Месяц назад я написал скрипт, который это решил. А потом скрипт решил больше, чем я хотел.
