DevOps *

Привет, Хабр! Тем, кому регулярно приходится заглядывать в etcd — будь то QA, поддержка или разработчики — хорошо знакома ситуация, когда нужно разобраться с неожиданным состоянием сервиса, проверить конфиги или найти застрявший лок. И каждый раз всё сводится к одному: копировать ключ, запускать etcdctl get, читать многострочный JSON в терминале, ошибаться в пути… и в какой-то момент понимаешь, что это однообразие выматывает больше, чем сама проблема.

Поэтому наш коллега из Хайстекс сделал небольшой TUI-инструмент, который заметно упрощает работу с etcd и делает её куда дружелюбнее для тех, кто каждый день копается в окружениях. Он снимает рутину etcdctl, даёт привычную “каталожную” навигацию, подсвечивает скрытые _-ключи, позволяет комфортно открывать большие конфиги и помогает разбираться с локами, которые любят появляться в самых неожиданных местах.

Если вы в QA, поддержке или просто часто работаете с etcd, этот инструмент легко сэкономит вам время и нервы.

Статью можно прочитать здесь.

Уровень загрузки ресурсов (Percentage Resource Utilization)

Уровень загрузки ресурсов помогает быстро понять, насколько действительно используются выделенные мощности. Это один из самых простых и при этом самых рабочих способов найти неоптимальности в инфраструктуре. Компании начинают применять его ещё до формального внедрения FinOps, просто потому что здравый смысл подсказывает: если сервис использует 5% ресурсов, есть повод что-то менять.

Мы смотрим на три базовых показателя. Это CPU, память и диск. Этого достаточно, чтобы увидеть общую картину. Да, в инфраструктуре есть и другие ресурсы, например трафик, но для первичной диагностики хватает именно этих трёх.

Как считается

➖  CPU: использованные ядро-часы / количество выделенных ядер

➖  Память: фактическое потребление в гигабайтах / выделенный объём

➖  Хранилище: используемые GB / выделенное пространство

Что даёт этот анализ

Когда компания оценивает уровень загрузки, она перестаёт работать на предположениях и начинает принимать решения на фактах. На практике это чаще всего приводит к трём сценариям.

1. Команда отказывается от ресурсных объектов, если загрузка держится на уровне нескольких %.

2. Команда объединяет инфраструктуру. Например, три виртуальные машины загружены по 20% каждая, их сводят в одну, а две отключают.

3. Команда корректирует конфигурацию. Это классический rightsizing, когда сервису просто уменьшают объём ресурсов, потому что реальная нагрузка намного ниже.

Это базовый навык, с которого начинается оптимизация в любой компании. Он одинаково полезен и в публичных облаках и в частных инфраструктурах. И независимо от уровня зрелости, компании, которые работают с фактической загрузкой, быстрее находят резервы, снижают расходы и точнее планируют будущие потребности. (Источник: FinOps Foundation).

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

Уже в следующий вторник — развернем Kubernetes-кластер за 15 минут

2 декабря в 11:00 по мск подключайтесь к next-next-next инсталляции кластера из GUI.

После нее пройдемся и по другим обновлениям релиза «Штурвал 2.12»:

• Изменение UI создания кластера: статусная модель и контроллер управления кластерами.

• Развертывание на OpenStack с использованием нативных балансеров и сертификатов Let's Encrypt.

• Поддержка Cinder CSI и Ubuntu 24.04.

Вебинар будет интересен DevOps-инженерам и архитекторам, разработчикам, специалистам служб эксплуатации.

Регистрация

Яндекс.Облако легло вместе с половиной интернета

Если во вторник утром сервисы Яндекса работали у вас через раз, знайте, что вы такой не один. Мы в Практиках FinOps тоже смотрели на ошибку 504 и думали, что это у нас что-то сломалось. А оказалось, это ru-central-1b упал. Поэтому полетело все, что там крутилось: Аптека.ру, КИОН, ФНС и много кто еще.

К обеду все починили. Только вот Яндекс такой не один. Последние недели облачные провайдеры падают один за другим как доминошки. То AWS накроется, то Azure, то Cloudlfare. То есть, по сути, даже неважно, где вы хоститесь: cloud-native компании накрывает независимо от географии.

На бумаге аптайм в 99,95%, обещанный провайдерами, выглядит очень привлекательно, но на практике оказывается так, что даже одна упавшая зона может положить десятки сервисов. Причем происходит это, как правило, именно в самый неудобный момент как у Яндекса: утро понедельника, пиковая нагрузка, куча клиентов. И тут бац — лежим. Тут волей-неволей задумаешься о том, чтобы уйти в гибрид.

Да и почему бы, собственно, нет? Гибридная инфраструктура сейчас – это отнюдь не перестраховка параноиков, а более чем здравый подход, который позволяет разместить все самые критичные сервисы на собственных серверах. Упала зона — половина продолжает работать. А если FinOps применим к гибриду не хуже, чем к облаку, оснований отказываться от него фактически и не остается.

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе. Там много интересного.

Как настроить очереди задач в Redis

Автоматизация очередей задач — типовая задача для IT-разработчиков и DevOps-инженеров, которые работают с распределенными системами.

Подготовили пошаговую инструкцию, как реализовать очереди в Redis тремя способами: Pub/Sub для событий «здесь и сейчас», List для классического FIFO и Streams — с историей сообщений и группами потребителей. Внутри инструкции — как подготовить окружение, написать издателя и подписчика на Python, работать с last_id и блокирующим чтением.

Подробности — в базе знаний Рег.облака.

⚡️ITFB Group запускает KODA — платформу для объективной оценки эффективности разработки

Мы представили KODA — собственную платформу, которая показывает, как на самом деле работает команда разработки. Не по ощущениям и не по субъективным отчётам, а на основе данных из всех инструментов инженеров: репозиториев, таск-трекеров, CI/CD, баз знаний и систем тестирования.

🔥 За первые 3 квартала внутреннего использования мы увеличили производительность команд на 30%, сократили количество переделок на 35% и ускорили code review на 40%.

💻 KODA объединяет инженерные метрики, ИИ-модули и аналитику, чтобы дать руководителям полную картину разработки — прозрачную, измеримую и безопасную. Все данные остаются внутри компании.

Наталья Романова, директор по развитию ITFB Group:
«Мы создавали KODA как инженеры для инженеров. Но в итоге получили инструмент, который одинаково важен и для бизнеса: он переводит работу разработки в язык цифр, прозрачности и управляемости».

📎 По оценкам Gartner, к 2027 году подобные системы станут стандартом для половины компаний мира. Российский рынок только начинает этот путь — и KODA становится одним из первых решений такого уровня.

Подробнее о KODA — на сайте ITFB Group.

Вебинар про мониторинг в Deckhouse Kubernetes Platform: от архитектуры до расследования инцидентов

В эту пятницу, 28 ноября в 12:00, разберём мониторинг в DKP на реальных кейсах. 

Внутри вебинара:

• концепции мониторинга DKP и чем они отличаются от стандартных подходов;

• как мультитенантность и веб-интерфейс делают работу проще;

• практические примеры расследования и локализации инцидентов с готовыми инструментами.

Спикер — Владимир Гурьянов, технический директор продуктового направления Observability. 

Регистрируйтесь и подключайтесь к эфиру. Будет интересно тем, кто уже использует DKP или только присматривается к ней. Покажем, что платформа умеет больше, чем вы думаете. Особенно в части мониторинга.

4 раунда за 2 недели собеседований → оффер в пятницу → отказ в понедельник.
Причина?
Мой чертов LinkedIn, который я не обновлял пару лет.

Все любят истории успеха 🙃
Но вот вам история НЕ-успеха - и при этом моя собственная.

За последние 2 недели прошёл:
🟢 HR-интервью
🟢 Техническое интервью (жёсткое, но честное)
🟢 Интервью с командой
🟢 Интервью с CPO
🟢 Получил оффер. Подтвердили, что всё ок.

В пятницу вечером в почте лежал «Welcome aboard».
Я, честно - обрадовался. Уже mentally onboarded. И самое !главное! крутая команда, крутые задачи впереди, возможность строить инфраструктуру с нуля и возможность топить в ИБ (реальную а не бумажную) - ну восторг жеж. Да я уже запланировал фаст-вины на первые 30 дней!

А в понедельник приходит письмо:
«СТО принял решение не двигаться дальше. Ваш опыт в резюме не соответствует тому, что в LinkedIn».

Что?! Какого?!
LinkedIn, который я не вёл несколько лет?
Площадка, которую большинство инженеров обновляет раз в эпоху?

Я объяснил, что могу подтвердить опыт трудовой, рекомендациями, стеками проектов, GitLab’ами, CI/CD пайплайнами - чем угодно.
Ответ:
«Решение финальное».

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

*Мой личный инсайт* В эпоху, когда DevOps пишет IAC, придумал собственный термин, что карьера тоже - Career As a Code, и её надо поддерживать.

Так что да: обновляю LinkedIn.
Да: выкладываю эту историю.
Да: остаюсь мотивирован строить системы, усиливать DevOps и DevSecOps, выстраивать безопасность, SRE, процессы, документирование, хаос-устойчивость - всё то, в чём я реально силён.

Может я единственный, кто еще живет по старому, а все остальные давно проснулись в матрице?

Как часто вы обновляете ЛН?

Как научить команды экономить IT-бюджет: 3 рабочих совета

Хотите довести финдира до нервного срыва? Просто не отключайте на выходные тестовые инстансы, а еще лучше – разверните staging на том же железе, что продакшен. А когда счет за облако придет на 800 тысяч вместо 300, спросите: "А при чем тут я?".

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

Вот как все исправить (подробности – тут):

Метрики затрат в Grafana. Если стоимость работы кластера отображается рядом с загрузкой CPU и потреблением памяти, разработчик реально видит, что во что обходится. Случился скачок расходов на графике — значит, надо разбираться. Только на этом можно сэкономить 20-30%.

Калькулятор стоимости в PR. Штуки типа Infracost смотрят на изменения в инфраструктурном коде и прямо в Pull Request пишут, во что это выльется. Так можно отсекать слишком дорогие вещи еще на этапе ревью.

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

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе. Там много интересного.

В июле я писал о том, что Gaunt Sloth Assistant дошёл до версии 0.9.2. Сегодня мы наконец можем сказать, что вышла версия 1.0.0. В этом релизе мы перевели основную зависимость на LangChain/LangGraph v1, обновили минимальные требования до Node 24/npm 11 и официально объявили CLI готовым к повседневной автоматизации.

Что изменилось с прошлого поста?

• Ревью теперь завершаются вызовом встроенного рейтингового инструмента. По умолчанию шкала 10/10, порог прохождения 6/10, и оценки ниже 6 заставляют команду review возвращать ненулевой код (non-zero exit code). Если нужен только режим предупреждений, установите commands.review.rating.enabled (и/или commands.pr.rating.enabled) в false в .gsloth.config.*.

• Профили идентичности стали частью базового сценария: один флаг -i profile-name, и вы переключаете промпты, модели и провайдеры на уровень нужной папки.

• Middleware теперь сущность первого класса. Можно комбинировать встроенные варианты вроде anthropic-prompt-caching или summarization, подключать собственные объекты на JS, а CLI показывает, что именно выполняется при каждой команде.

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

• Мы освежили кеш OAuth, документацию и README, чтобы новичкам было проще стартовать, и параллельно усилили безопасность зависимостей.

Профили идентичности — главный QoL‑апгрейд 1.0.0. Они позволяют мгновенно переключаться между системными промптами, пресетами моделей и наборами инструментов под конкретную задачу. gth pr 555 PP-4242 по‑прежнему читает .gsloth/.gsloth-settings, а gth -i devops pr 555 PP-4242 автоматически берёт конфиг из .gsloth/.gsloth-settings/devops/ со своими промптами и провайдерами.

Нужно поговорить с Jira через MCP? Создайте профиль вроде jira-mcp со своим конфигом и запустите gth -i jira-mcp chat. Укороченный пример:

{
  "llm": {
    "type": "vertexai",
    "model": "gemini-2.5-pro"
  },
  "mcpServers": {
    "jira": {
      "url": "https://mcp.atlassian.com/v1/sse",
      "authProvider": "OAuth",
      "transport": "sse"
    }
  },
  "requirementsProviderConfig": {
    "jira": {
      "cloudId": "YOUR-JIRA-CLOUD-ID-UUID",
      "displayUrl": "https://YOUR-BUSINESS.atlassian.net/browse/"
    }
  },
  "commands": {
    "pr": {
      "contentProvider": "github",
      "requirementsProvider": "jira"
    }
  }
}

Переключение между такими папками теперь — один флаг, поэтому удобно держать отдельные персоны для DevOps, документации или любого удалённого MCP.

Rater — второй крупный прорыв. Ревью всегда содержали текстовый фидбек, но в 1.0.0 оценка стала действенной: мы сохраняем её в хранилище артефактов, передаём в модуль ревью и вызываем setExitCode, чтобы CI автоматически падал при невыполнении цели по качеству. Настройка защит для продакшн‑сервисов занимает теперь секунды и не требует самописных скриптов.

Наконец, реестр middleware и хранилище артефактов дают аккуратные точки расширения на будущее. Можно оборачивать вызовы моделей и инструментов, логировать каждую операцию и при этом оставлять Gaunt Sloth вести те же chat/code/pr/init команды. CLI как и раньше — небольшой TypeScript‑бинарь, который устанавливается через npm или запускается npx gth, но теперь у него архитектура, позволяющая развиваться без костылей.

Хотите попробовать релиз — быстрый путь всё ещё
npm install -g gaunt-sloth-assistant

репозиторий https://github.com/Galvanized-Pukeko/gaunt-sloth-assistant пригодится как справочник и место для issues. Заводите issue, оставляйте фидбек в Discussions или подключайте rater к своему CI и расскажите, как он себя ведёт — буду рад помощи в движении к 1.1.

Спасибо всем, кто помог тестами и несколькими PR.

Минималистичные healthcheck-утилиты для Docker-контейнеров

Однажды я был маленький, и задавался вопросом - вот собираешь ты свое приложение, нежно помещаешь его в Docker-образ, заботишься о том чтоб и зависимостей было поменьше, и скомпилируешь его так чтоб итоговая каша из байт было погуще, но покомпактее; используешь scratch, статическую линковку, но чтоб "из коробки" был еще и healthcheck - приходится или писать свой мальний чекер каждый раз, или тянуть статичкски слинкованный curl/wget, если приложение работает как http сервер.

Потому что без healthcheck жизнь ну совсем не торт, даже при локальной разработке, когда запускаешь уже готовые образы, ставишь их в зависимость для других (в том же docker compose) - без него это все работать не будет так, как тебе хочется - демоны будут стучаться друг к другу без уважения и учета, готово оно в этому или нет.

Так родился microcheck - набор крошечных статически скомпилированных бинарников, созданных специально для healthcheck-ов. Они не имеют зависимостей от динамических библиотек, написаны на C, и работают даже в scratch и distroless образах, да умеют корректно возвращать exit-коды, понятные Docker’у (0 - здоров, 1 - приходи завтра).

В комплекте:

• httpcheck — проверка HTTP-эндпоинтов (~75 KB)

• httpscheck — то же самое, но с TLS и автоопределением протокола (~500 KB)

• portcheck — проверка TCP/UDP-портов (~70 KB)

У вас в продакшене наверняка Kubernetes, и все проверки делает kubelet - скорее всего, вам не нужно ничего менять. Но если вы запускаете контейнеры в «голом» Docker’е или других рантаймах без встроенных healthcheck-ов - такие инструменты могут здорово упростить жизнь.

Как выглядит в деле:

# Было (+~10MB)
RUN apt update && apt install -y curl && rm -r /var/lib/apt/lists/*
HEALTHCHECK --interval=10s CMD curl -f http://localhost:8080/ || exit 1

# Стало (+~75KB)
COPY --from=ghcr.io/tarampampam/microcheck /bin/httpcheck /bin/httpcheck
HEALTHCHECK --interval=10s CMD ["httpcheck", "http://localhost:8080/"]

Разница по размеру в десяток мегабайт против семи десятков килобайт, а в качестве бонуса - не нужен shell-процесс, всё работает напрямую и быстро (а еще и в переменные окружения умет).

Поддерживаются все популярные архитектуры (x86_64, ARM, ppc64le, s390x и др.), есть готовые образы в GitHub Container Registry и Docker Hub.

Посмотреть исходники, примеры Dockerfile и prebuilt-бинарники можно тут: github.com/tarampampam/microcheck

Фишки FinOps Radar: бесплатная платформа, которая помогает экономить в Yandex Cloud

Как говорили в старину, с FinOps Radar и облако милее

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

FinOps Radar — это первый бесплатный сервис для оптимизации расходов в Yandex Cloud.

Что он умеет:

Обнаружение аномалий. Сервис сравнивает текущие расходы с расходами за последнюю неделю. Если траты выросли больше чем на 5% от среднего, система помечает это цветом. Желтый — рост 5-10%, все что выше – красный. Можно сразу открыть детализацию и понять, какой сервис съел бюджет.

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

Автоалерты. Письма об аномалиях приходят в 05:00, о новых рекомендациях — в 09:00. Можно даже выгрузить отчет в Excel и в конце месяца показать начальству, сколько денег сэкономили.

Главное — сервис ничего не трогает в вашей инфраструктуре. Только смотрит и советует. У него даже прав таких нет. Вы даете доступ только для чтения, он собирает данные и показывает проблемы. А как на них реагировать — решаете сами. 

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

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

Завтра, 12 ноября, в 11:00 менеджер продукта и архитектор инфраструктурных решений Deckhouse проводят совместный вебинар с командой «Мобиус Технологии». Со своей стороны представим Deckhouse Virtualization Platform. Расскажем, как платформа помогает решать задачи миграции с монолитов на микросервисы и запускать кластеры Kubernetes как сервис. А ещё проведём демо возможностей DVP в реальной инфраструктуре и разыграем подарки.

Также в программе:

• обзор последних новостей рынка виртуализации и систем резервного копирования;

• знакомство с наиболее зрелыми российскими альтернативами западным платформам;

• кейсы по внедрению серверной виртуализации и виртуализации рабочих мест пользователей.

В конце вебинара будет Q&A-сессия, чтобы ничьи вопросы по теме не остались без ответов. Регистрируйтесь и подключайтесь!

Ссылка на пост в телеграм

Лучший стэк для запуска MVP SaaS-стартапа в РФ на 2025 год.

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

Проверено на собственной шкуре!

✅ Frontend:

- NextJS 15 (+React 19, Turbopack, Server Actions) - актуальный стек для веб-приложений.

- Shadcn UI (сделана на Tailwind) - библиотека UI-компонентов, чтобы сделать крутой интерфейс без дизайнеров.

- Netlify - бесплатный хостинг для тестовой версии продукта.

✅ Backend:

Supabase:

- База данных

- Database SQL Functions (функции сразу в базе PostgreSQL)

- Edge Functions (серверные функции на TypeScript)

Nextauth:

- Авторизация

✅ Инфраструктура:

Kubernetes:

- Репликация БД и сервисов на 3-х Worker-нодах

- Rollout-обновления без простоя

- Политики безопасности и изоляция

- CI/CD из GitHub.

+ Пароли/ключи в KeePass XC.

✅ Инструменты:

- IDEA Ultimate - среда разработки

- Cursor - для вайбкодинга (чистый, без всяких инфоцыганских MCP)

- DBeaver - для работы с БД

- GitHub - репозиторий

✅ Платежка

- Robokassa (РФ + иностранные платежи)

✅ Лендинг + блог

- Tilda (проще сделать сайт на конструкторе, чем все это вайбкодить)

Как мы все настроили

- Развернули проект в облачном хостинге в РФ, чтобы хранить данные в соответствии со 152 ФЗ. Выбрали хостинг с k0s, потому что он дешевле классического k8s.

- Supabase поставили на свой сервер (Cloud не подходит, так как данные хранятся не в РФ).

- Настроили регулярные бэкапы (хотя мы еще не релизились, но 1 раз у нас уже отлетали жесткие диски).

Почему именно такой стэк?

- Проще работать с технологиями, которые ты уже хорошо знаешь.

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

- Для работы в РФ нужно хранить персональные данные в РФ и избегать трансграничной передачи данных.

- Конструктор сайтов как простой и недорогой вариант для лендингов и блога. Чтобы не вайбкодить целую CMS.

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

А какие технологии используете вы для разработки MVP?

Как управлять затратами в облаке: 5 уровней

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

Естественно, при таком подходе говорить о какой-либо эффективности не приходится. Потому что если одни экономят, а другие забивают на отключение тестовых сред и гоняют MongoDB там, где хватило бы PostgreSQL, толку не будет. Ведь платить-то все равно из общего котла. 

Проблема решается детализацией:

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

• Уровень 2 - расходы распределяются по провайдерам. На этом уровне уже видно, что VK Cloud выставил столько-то, Яндекс Облако столько-то. Но почему – пока непонятно.

• Уровень 3 – раскладка по услугам. Compute съедает 60-70%, Storage – 20-30%, трафик – 10-15%. Уже появляется понимание, где самые дорогие компоненты.

• Уровень 4 – тегирование ресурсов. Так будет видно, какая команда тратит больше.

• Уровень 5 – cost-центры с реальными бюджетами. Showback показывает командам траты без списания денег. Chargeback списывает реальные суммы с реальных бюджетов. 

Компании, дошедшие до пятого уровня, экономят 20-30% без потери производительности.

Есть примеры обратного или хотите чем-то поделиться? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

Почему Kyverno и Gatekeeper: рассказываем об инструментах, сравниваем их и решаем, какой удобнее 🔐

Задумываетесь, что лучше выбрать для управления политиками в Kubernetes — Kyverno или Gatekeeper? У нас есть ответ. Приходите на вебинар, где мы поговорим о каждом контроллере, осветим их плюсы и минусы, а еще сценарии, для которых лучше подойдет каждый. Оба инструмента будем разбирать на практике.

О чем расскажем:

• что предлагает рынок для управления политиками в Kubernetes;

• почему выбираем между Kyverno и Gatekeeper, какие у них сильные и слабые стороны;

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

Ждем всех, кому интересна безопасность в Kubernetes, в частности DevOps-инженеров, техлидов, директоров по разработке и специалистов по кибербезопасности.

📅 Когда? 13 ноября в 11:00 мск.

📍Где? Онлайн. Зарегистрируйтесь, чтобы обсудить сетевые политики в кубере и задать вопросы экспертам.

FinOps против Excel: кто управляет деньгами в облаке

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

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

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

CFO смотрит на это и разводит руками. Финансисты видят цифры, но не понимают, почему всё так скачет.

Проблема не в суммах, а в подходе. Старый финконтроль держится на стабильности, а облако живёт по принципу «всё меняется каждую минуту». Любая мелочь в архитектуре мгновенно отражается в P&L, а привычные отчеты не успевают за скоростью изменений.

FinOps меняет этот подход:

• Вместо квартальных отчетов — короткие кост-ревью

• Вместо агрегированных сумм — расходы по командам и проектам

• Вместо запоздалых реакций — наблюдение в реальном времени.

Это уже даже не про “оптимизацию”, а про банальную прозрачность. Или транспарентность. Называйте как хотите.

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

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

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

Что будет с фотками, если закроется облако

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

Закрытие сервиса

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

Parse объявил о закрытии за год, а Everpix – за месяц. Но и в том, и в другом случае пользователям дали возможность выгрузить свои данные. Только после этого архивы удалили физически. 

Истечение подписки

У каждого провайдера свои правила хранения после окончания оплаченного периода. iCloud держит данные всего месяц, Dropbox – 2, а Google Drive позволяет загрузить их в течение двух лет.

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

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

Случаи потери данных

Бывает, что данные пропадают случайно. Вероятность такого исхода мала, но не равна нулю. Так, в 2015 году в дата-центр Google в Бельгии молния ударила 4 раза подряд. Пострадало около 0.000001% данных, то есть где-то 10 байт на гигабайт. Тем, кто попал в эту погрешность, конечно, легче не стало. Но цифры показывают, насколько это редкая ситуация.

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

Вышел релиз программного обеспечения topalias 3.0.0

Установка:
pip3 install -U --upgrade topalias
pipx install --force topalias
python3 -m pip install -U --upgrade topalias
python3.10 -m pip install -U --upgrade topalias

Запуск утилиты topalias:
topalias
python3 -m topalias
python3.10 -m topalias
python3 topalias/cli.py

Изменения:
Поддерживается Ubuntu 25.10/Python 3.13, Kubuntu 22.04/Python 3.10, KDE neon Rolling

Просьба проверить на актуальной версии Python 3.15 в KDE neon

Ссылка на дистрибутив KDE neon Rolling: https://distrowatch.com/table.php?distribution=kdeneon

topalias - утилита для генерации коротких алиасов по истории bash/zsh

На GitHub опубликована открытая утилита для генерации коротких алиасов на основании истории работы в bash или zsh. Утилита анализирует файлы ~/.bash_aliases, ~/.bash_history и ~/.zsh_history с историей выполнения команд в терминале Linux, после чего предлагает короткие аббревиатуры (акронимы) для длинных, долго набираемых и сложно запоминаемых, но часто используемых команд. Также поддерживается вывод статистики по истории работы в командной строке.

Если вы работаете в терминале десятки раз в день, алиасы — это мощный инструмент повышения эффективности. Но с ростом количества проектов и конфигураций .bashrc/.zshrc алиасов становится много: часть дублируется, часть устарела, некоторые перекрывают системные команды. topalias решает три задачи:

• дать метрику использования алиасов (какие используются чаще всего);

• упростить создание/удаление/пакетное управление алиасами;

• находить конфликтные или опасные алиасы и предлагать безопасные альтернативы.

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

Ключевые возможности

• Сбор статистики использования алиасов на основе shell-history.

• Команда top — список наиболее часто используемых алиасов.

• Интерактивный режим (TUI) для обзора, включения/выключения и редактирования.

• Поддержка bash, zsh и fish.

• Экспорт/импорт в виде конфигурационных файлов и git-репозиториев.

• Поиск конфликтов (алиас затеняет системную команду) и предупреждения.

• Генератор «умных» алиасов: на основе частых цепочек команд предлагает сокращения.

• Пакетная миграция между машинами (pack/unpack).

• Небольшой daemon/cron для частого обновления статистики (опционально).

# клонируем репозиторий

git clone https://github.com/CSRedRat/topalias.git

cd topalias

# установка в виртуальное окружение (рекомендуется)

python -m venv .venv

source .venv/bin/activate

pip install -e .

# инициализация в shell (одна строчка, добавьте в .bashrc/.zshrc)

topalias init --shell auto >> ~/.topalias-shell-rc && source ~/.topalias-shell-rc

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

Подписывайтесь на канал в Telegram: https://t.me/ruopsdev

Второй канал на Телеграм: https://t.me/journal_rbc_pro

• Просмотр самых часто используемых алиасов:

topalias top
topalias top --limit 20 # или с лимитом

• Найти алиас по фрагменту:

topalias find git

• Создать алиас:

topalias add ga='git add --all'

• Удалить алиас:

topalias rm ga

• Интерактивный режим (TUI):

topalias ui

• Экспорт текущих алиасов в файл:

topalias export --format bash > ~/.topalias-export.sh

Импорт из файла:

topalias import ~/.topalias-export.sh

Если вы часто выполняете цепочку:

git add . && git commit -m "WIP" && git push

topalias предложит вариант:

topalias suggest
# suggestion: gpush = git add . && git commit -m "WIP" && git push
topalias add gpush='git add . && git commit -m "WIP" && git push'

Проверим, не перекрывает ли алиас системную команду:

topalias check-conflicts
# output:
# - ls -> aliased to "ls --color=auto" (OK)
# - df -> aliased to "du -h" (DANGER: shadows system df)

Сохраняем пакет алиасов и переносим на другой компьютер:

topalias pack --name work-aliases > work-aliases.tar.gz
# на другом хосте
topalias unpack work-aliases.tar.gz
topalias import unpacked/work-aliases.sh