#метрики — Public Fediverse posts

Автоматизация матчмейкинга: как я знакомлю полезных друг другу лидов

Я много знакомлю лидов друг с другом. Теперь этот процесс автоматизирован. Этот способ позволяет мне расширять свой нетворк и давать пользу тем, с кем я знаком

https://habr.com/ru/articles/1089220/

#crm #matchmaking #intro #networking #sqlite #лидогенерация #метрики

Автоматизация матчмейкинга: как я знакомлю полезных друг другу лидов

Я много знакомлю лидов друг с другом. Теперь этот процесс автоматизирован. Этот способ позволяет мне расширять свой нетворк и давать пользу тем, с кем я знаком

https://habr.com/ru/articles/1089220/

#crm #matchmaking #intro #networking #sqlite #лидогенерация #метрики

Выручка +49 %, но это не заслуга ИИ: разбор ИИ-контура у селлера на Wildberries и Ozon

Производитель косметики, шесть кабинетов на Wildberries и Ozon, оборот около 45 млн ₽ в месяц. За шесть недель команда маркетплейсов из шести человек запустила 26 автоматизаций — по плану внедрения было три. Выручка за то же время выросла на 49 %, и ниже я объясню, почему мы не записываем этот рост на счёт ИИ. В разборе — как устроен корпоративный ИИ-контур, откуда взялись 26 автоматизаций, что ИИ нашёл в данных компании (включая ключ доступа к финансам всех кабинетов, лежавший по публичной ссылке), как мы мерили эффект и что не получилось. Это промежуточный замер: 11 августа — 22 сентября 2026 года. Повторный — через три месяца. Читать разбор

https://habr.com/ru/articles/1088838/

#внедрение_ИИ #LLM #ИИассистенты #Wildberries #Ozon #маркетплейсы #автоматизация #управленческий_учёт #метрики #кейс

Выручка +49 %, но это не заслуга ИИ: разбор ИИ-контура у селлера на Wildberries и Ozon

Производитель косметики, шесть кабинетов на Wildberries и Ozon, оборот около 45 млн ₽ в месяц. За шесть недель команда маркетплейсов из шести человек запустила 26 автоматизаций — по плану внедрения было три. Выручка за то же время выросла на 49 %, и ниже я объясню, почему мы не записываем этот рост на счёт ИИ. В разборе — как устроен корпоративный ИИ-контур, откуда взялись 26 автоматизаций, что ИИ нашёл в данных компании (включая ключ доступа к финансам всех кабинетов, лежавший по публичной ссылке), как мы мерили эффект и что не получилось. Это промежуточный замер: 11 августа — 22 сентября 2026 года. Повторный — через три месяца. Читать разбор

https://habr.com/ru/articles/1088838/

#внедрение_ИИ #LLM #ИИассистенты #Wildberries #Ozon #маркетплейсы #автоматизация #управленческий_учёт #метрики #кейс

«Выросли на 11% к прошлому месяцу» — и ни одного нового клиента

В феврале 28 дней, в марте 31, продавайте одинаково каждый день — и рост на 11% появится сам, без новых клиентов. В статье разбираю базу, как календарь и сезонность ломают отчёты: три вопроса перед сравнением периодов, SQL-запросы для среднего за день и скользящего среднего, ловушки сравнения год к году.

https://habr.com/ru/articles/1088720/

#сезонность #скользящее_среднее #карьера_итспециалиста #карьера_аналитика #карьера_аналитика_данных #карьера_аналитиков #метрики #джуниор_аналитик #аналитика_данных #аналитик_данных

«Выросли на 11% к прошлому месяцу» — и ни одного нового клиента

В феврале 28 дней, в марте 31, продавайте одинаково каждый день — и рост на 11% появится сам, без новых клиентов. В статье разбираю базу, как календарь и сезонность ломают отчёты: три вопроса перед сравнением периодов, SQL-запросы для среднего за день и скользящего среднего, ловушки сравнения год к году.

https://habr.com/ru/articles/1088720/

#сезонность #скользящее_среднее #карьера_итспециалиста #карьера_аналитика #карьера_аналитика_данных #карьера_аналитиков #метрики #джуниор_аналитик #аналитика_данных #аналитик_данных

664 тысячи книг, десятки агентов — и ни одной метрике нельзя верить

Мне нужны собственные каноники книг. Каноник — это одна устойчивая запись «вот этот текст», к которой привязывается всё остальное: файлы в разных форматах, аудиокниги, издания, дубли. Не потому, что внешние источники плохие. Если мне нужно быстро получить автора, название или идентификатор книги, я вполне могу взять их из существующего каталога. Даже если в каталоге есть мусор, это не катастрофа: мусор можно постепенно исправлять. Проблема в другом — это не мой каталог. Я могу годами накапливать вокруг внешнего идентификатора результаты собственных анализаторов: связывать с ним аудиокниги, находить дубли, определять издания, собирать статистику, строить рекомендации. А потом внешний источник поменяет идентификаторы, структуру или просто исчезнет, и вся накопленная работа повиснет в воздухе. Поэтому я решил сделать собственный корпус книг. Он тоже будет грязным, и это нормально. Главное, что это мой грязный корпус: я могу его постепенно улучшать, и его идентификаторы контролирую я сам. В корпусе сейчас около 664 тысяч книг. А задача, ради которой всё это понадобилось, на первый взгляд была совсем простой: взять несколько минут аудиокниги, прогнать через Whisper и найти соответствующую книгу по тексту. Ну что может быть сложного? Оказалось — примерно всё.

https://habr.com/ru/articles/1088532/

#MinHash #fingerprinting #поиск_дубликатов #оценка_качества_поиска #метрики #ложные_срабатывания #датасет #LLMагенты #Whisper #шинглы

664 тысячи книг, десятки агентов — и ни одной метрике нельзя верить

Мне нужны собственные каноники книг. Каноник — это одна устойчивая запись «вот этот текст», к которой привязывается всё остальное: файлы в разных форматах, аудиокниги, издания, дубли. Не потому, что внешние источники плохие. Если мне нужно быстро получить автора, название или идентификатор книги, я вполне могу взять их из существующего каталога. Даже если в каталоге есть мусор, это не катастрофа: мусор можно постепенно исправлять. Проблема в другом — это не мой каталог. Я могу годами накапливать вокруг внешнего идентификатора результаты собственных анализаторов: связывать с ним аудиокниги, находить дубли, определять издания, собирать статистику, строить рекомендации. А потом внешний источник поменяет идентификаторы, структуру или просто исчезнет, и вся накопленная работа повиснет в воздухе. Поэтому я решил сделать собственный корпус книг. Он тоже будет грязным, и это нормально. Главное, что это мой грязный корпус: я могу его постепенно улучшать, и его идентификаторы контролирую я сам. В корпусе сейчас около 664 тысяч книг. А задача, ради которой всё это понадобилось, на первый взгляд была совсем простой: взять несколько минут аудиокниги, прогнать через Whisper и найти соответствующую книгу по тексту. Ну что может быть сложного? Оказалось — примерно всё.

https://habr.com/ru/articles/1088532/

#MinHash #fingerprinting #поиск_дубликатов #оценка_качества_поиска #метрики #ложные_срабатывания #датасет #LLMагенты #Whisper #шинглы

После релиза БОЛТУНа на Tauri: 134 млн голосовых кадров и рост аудитории

15 сентября мы выпустили БОЛТУН с Windows-клиентом на Tauri. К 28 сентября сервер учёл 134 млн входящих голосовых кадров, а среднее число разных клиентских ID в сутки выросло со 145 до 192 при сравнении одинаковых дней недели — примерно на 33%. Разбираем первые результаты: рост активности, голосовой трафик, демонстрации экрана и 854 часа суммарного прослушивания радио.

https://habr.com/ru/articles/1087540/

#БОЛТУН #Tauri #голосовой_чат #мониторинг #метрики #продуктовая_аналитика #демонстрация_экрана #радио

После релиза БОЛТУНа на Tauri: 134 млн голосовых кадров и рост аудитории

15 сентября мы выпустили БОЛТУН с Windows-клиентом на Tauri. К 28 сентября сервер учёл 134 млн входящих голосовых кадров, а среднее число разных клиентских ID в сутки выросло со 145 до 192 при сравнении одинаковых дней недели — примерно на 33%. Разбираем первые результаты: рост активности, голосовой трафик, демонстрации экрана и 854 часа суммарного прослушивания радио.

https://habr.com/ru/articles/1087540/

#БОЛТУН #Tauri #голосовой_чат #мониторинг #метрики #продуктовая_аналитика #демонстрация_экрана #радио

Jev, Laya и Gemini Flash на трёх задачах классификации в поддержке

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

https://habr.com/ru/articles/1087326/

#llm #классификация_текста #auc #калибровка #поддержка_клиентов #ии_агенты #метрики #fast_model #jev #laya

Jev, Laya и Gemini Flash на трёх задачах классификации в поддержке

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

https://habr.com/ru/articles/1087326/

#llm #классификация_текста #auc #калибровка #поддержка_клиентов #ии_агенты #метрики #fast_model #jev #laya

Гайд по switchback‑экспериментам: длина окна, кластеризация ошибок и мощность

Новый алгоритм может уверенно выигрывать A/B‑тест и не показывать ожидаемого эффекта после запуска, если эксперимент учитывает только пользователей, но игнорирует общий ресурс. В статье разбираемся, как работают switchback‑эксперименты, почему стандартный анализ даёт ложные выводы и как корректно оценивать результаты. Разобрать подход

https://habr.com/ru/companies/otus/articles/1081848/

#эксперименты #статистический_анализ #анализ_данных #рандомизация #проверка_гипотез #метрики #машинное_обучение #кластеризация #аналитика_данных #A_Bтестирование

Гайд по switchback‑экспериментам: длина окна, кластеризация ошибок и мощность

Новый алгоритм может уверенно выигрывать A/B‑тест и не показывать ожидаемого эффекта после запуска, если эксперимент учитывает только пользователей, но игнорирует общий ресурс. В статье разбираемся, как работают switchback‑эксперименты, почему стандартный анализ даёт ложные выводы и как корректно оценивать результаты. Разобрать подход

https://habr.com/ru/companies/otus/articles/1081848/

#эксперименты #статистический_анализ #анализ_данных #рандомизация #проверка_гипотез #метрики #машинное_обучение #кластеризация #аналитика_данных #A_Bтестирование

Кто нашёл больше багов — агент или человек? Мои замеры 11 недель работы с AI-тестировщиком

Одиннадцать недель я вёл дневник каждой рабочей сессии с Claude Code: часы агента, свои часы, судьба каждого кандидата в дефекты. Вышло 277 агентских часов против 213 моих и 94 подтверждённые находки — 77 нашёл агент, 16 я. Внутри: почём обошёлся час агента, где он не окупился, что пропустил и почему первый подсчёт находок оказался завышен почти вдвое.

https://habr.com/ru/articles/1085288/

#Claude_Code #AIагенты #QA #тестирование #автоматизация_тестирования #Playwright #метрики #LLM #стоимость_разработки #paranoidqa

Кто нашёл больше багов — агент или человек? Мои замеры 11 недель работы с AI-тестировщиком

Одиннадцать недель я вёл дневник каждой рабочей сессии с Claude Code: часы агента, свои часы, судьба каждого кандидата в дефекты. Вышло 277 агентских часов против 213 моих и 94 подтверждённые находки — 77 нашёл агент, 16 я. Внутри: почём обошёлся час агента, где он не окупился, что пропустил и почему первый подсчёт находок оказался завышен почти вдвое.

https://habr.com/ru/articles/1085288/

#Claude_Code #AIагенты #QA #тестирование #автоматизация_тестирования #Playwright #метрики #LLM #стоимость_разработки #paranoidqa

Хватит считать токены: почему KPI в эпоху ИИ превратились в фикцию

Каждые несколько лет индустрия придумывает новую единицу продуктивности. Строки кода. Коммиты. Пул-реквесты. Теперь - токены. Схема одна: берём то, что легко посчитать, вешаем на дашборд и начинаем по этому оценивать людей. Счётчик крутится - значит, работа кипит. Отстающие подсвечиваются красным, лидеры - зелёным, и никто не задаёт неудобный вопрос: а что из этого дошло до пользователя? В 2026-м на эту роль назначили токены. Метрика удобная: она всегда под рукой, её видно в реальном времени, и её очень легко накрутить - достаточно оставить агента работать на ночь. Проблема в том, что она измеряет активность, а не результат. Ровно так же, как когда-то строки кода.

https://habr.com/ru/articles/1082736/

#kpi #метрики #управление_разработкой #продуктивность #продуктивность_разработчиков #технический_долг #качество_кода #менеджмент #менеджмент_проектов #управление_проектами

Хватит считать токены: почему KPI в эпоху ИИ превратились в фикцию

Каждые несколько лет индустрия придумывает новую единицу продуктивности. Строки кода. Коммиты. Пул-реквесты. Теперь - токены. Схема одна: берём то, что легко посчитать, вешаем на дашборд и начинаем по этому оценивать людей. Счётчик крутится - значит, работа кипит. Отстающие подсвечиваются красным, лидеры - зелёным, и никто не задаёт неудобный вопрос: а что из этого дошло до пользователя? В 2026-м на эту роль назначили токены. Метрика удобная: она всегда под рукой, её видно в реальном времени, и её очень легко накрутить - достаточно оставить агента работать на ночь. Проблема в том, что она измеряет активность, а не результат. Ровно так же, как когда-то строки кода.

https://habr.com/ru/articles/1082736/

#kpi #метрики #управление_разработкой #продуктивность #продуктивность_разработчиков #технический_долг #качество_кода #менеджмент #менеджмент_проектов #управление_проектами

Правда ли, что медицинский ИИ точнее врачей? Наш фреймворк помогает это выяснить

Привет, Хабр! Меня зовут Илья Копаничук, я старший научный сотрудник лаборатории «Сильный ИИ в медицине» AIRI. Мы с коллегами создаём ИИ‑инструменты, задача которых сделать качественную медицину доступнее. Например, основанное на нашей технологии приложение «Помощник по здоровью» стало лучшим ИИ‑решением в клиентском сервисе по версии Generation AI Awards 2025 . Но речь сегодня не об этом. За время нашей работы мы поняли, что контроль качества ИИ‑диагностики в медицине — это одна из ключевых задач, которая, как оказалось, не была ещё достаточно хорошо решена. Во‑первых, тесты для медицинских моделей зачастую далеки от реальной практики. А во‑вторых, всегда ли точны люди? Пытаясь ответить на эти вопросы, мы с помощью коллег из ФГБУ «НМИЦ им. В. А. Алмазова» Минздрава России собрали собственный фреймворк и опубликовали про него статью в Scientific Reports . Здесь я расскажу, как он устроен и на какие метрики мы обратили внимание, а также постараюсь дать ответ на вопрос, заданный в заголовке.

https://habr.com/ru/companies/airi/articles/1079898/

#метрики #оценка_качества #llm #llmприложения

Правда ли, что медицинский ИИ точнее врачей? Наш фреймворк помогает это выяснить

Привет, Хабр! Меня зовут Илья Копаничук, я старший научный сотрудник лаборатории «Сильный ИИ в медицине» AIRI. Мы с коллегами создаём ИИ‑инструменты, задача которых сделать качественную медицину доступнее. Например, основанное на нашей технологии приложение «Помощник по здоровью» стало лучшим ИИ‑решением в клиентском сервисе по версии Generation AI Awards 2025 . Но речь сегодня не об этом. За время нашей работы мы поняли, что контроль качества ИИ‑диагностики в медицине — это одна из ключевых задач, которая, как оказалось, не была ещё достаточно хорошо решена. Во‑первых, тесты для медицинских моделей зачастую далеки от реальной практики. А во‑вторых, всегда ли точны люди? Пытаясь ответить на эти вопросы, мы с помощью коллег из ФГБУ «НМИЦ им. В. А. Алмазова» Минздрава России собрали собственный фреймворк и опубликовали про него статью в Scientific Reports . Здесь я расскажу, как он устроен и на какие метрики мы обратили внимание, а также постараюсь дать ответ на вопрос, заданный в заголовке.

https://habr.com/ru/companies/airi/articles/1079898/

#метрики #оценка_качества #llm #llmприложения

Ежедневный ряд подписчиков в MAX: публичный эндпоинт, четыре грабли и почему not_found — не измерение

У мессенджера MAX нет публичного API со статистикой каналов. Числа есть у каталогов-агрегаторов, но они чужие и заморожены с 10 июля. Нам нужен был свой ряд подписчиков — и мы полгода снимаем его каждую ночь с публичного data-эндпоинта max.ru. Ниже — как устроен сбор и четыре места, где мы ошиблись. Самая дорогая ошибка стоила трёх ночей молчащего ряда при зелёном логе и exit 0: парсер на любую неудачу писал один статус not_found, а под него попадали три разных события — канала нет, max.ru сменил формат, нас затроттлило. Пока они не разделены, скрипт ничего не измеряет — он производит число, похожее на измерение.

https://habr.com/ru/articles/1080198/

#MAX #мессенджер_MAX #парсинг #SvelteKit #SQLite #каталог_каналов #firstparty_данные #обработка_ошибок #антинакрутка #метрики

Ежедневный ряд подписчиков в MAX: публичный эндпоинт, четыре грабли и почему not_found — не измерение

У мессенджера MAX нет публичного API со статистикой каналов. Числа есть у каталогов-агрегаторов, но они чужие и заморожены с 10 июля. Нам нужен был свой ряд подписчиков — и мы полгода снимаем его каждую ночь с публичного data-эндпоинта max.ru. Ниже — как устроен сбор и четыре места, где мы ошиблись. Самая дорогая ошибка стоила трёх ночей молчащего ряда при зелёном логе и exit 0: парсер на любую неудачу писал один статус not_found, а под него попадали три разных события — канала нет, max.ru сменил формат, нас затроттлило. Пока они не разделены, скрипт ничего не измеряет — он производит число, похожее на измерение.

https://habr.com/ru/articles/1080198/

#MAX #мессенджер_MAX #парсинг #SvelteKit #SQLite #каталог_каналов #firstparty_данные #обработка_ошибок #антинакрутка #метрики

Prometheus и VictoriaMetrics: почему одни и те же метрики могут занимать в 139 раз больше места

Меня зовут Стас Погоржельский, я технологический евангелист VK Cloud и последние месяцы гоняю Prometheus и VictoriaMetrics на одном стенде, чтобы понять, сколько на самом деле стоит одна точка метрики на диске. Обе системы делают одно и то же: принимают миллионы точек в минуту, хранят их месяцами и быстро отдают в алерты и дашборды. Обе сжимают точку до байтов и долей байта. Именно эти байты, умноженные на миллиарды точек в сутки, превращаются в счёт за диск. Ошибка в расчёте цены сэмпла заканчивается переполненным диском под мониторингом, урезанным retention или незапланированным расходом. Когда место под метрики кончается, первым на планёрке звучит «сменим движок». Публичные бенчмарки подталкивают к тому же: Флант показывает, что Prom++, форк Prometheus, тратит памяти в 7,8 раза меньше Prometheus v2 ( разбор на Habr ), VictoriaMetrics показывает трёхкратную экономию диска против Grafana Mimir ( бенчмарк VictoriaMetrics , замер вендора, 2022 год). На моём стенде картина оказалась сложнее. В Prometheus 3.13 и VictoriaMetrics 1.149 ушёл один и тот же набор: 2,88 млн сэмплов, шесть профилей данных, один генератор с фиксированным seed. Внутри одного движка цена сэмпла различалась в 139 раз у VictoriaMetrics и в 12,8 раза у Prometheus. Между движками на одних данных разрыв доходил до 30,7 раза на шести профилях и до 34,3 раза в опыте с точностью. На равномерно случайных float64 движки менялись местами. Один лишний знак после запятой поднимал цену сэмпла у Prometheus в восемь раз, у VictoriaMetrics на 12%.

https://habr.com/ru/companies/vk/articles/1068798/

#vk_cloud #prometheus #victoriametrics #time_series #tsdb #мониторинг #метрики #observability #сжатие_данных #cardinality

Prometheus и VictoriaMetrics: почему одни и те же метрики могут занимать в 139 раз больше места

Меня зовут Стас Погоржельский, я технологический евангелист VK Cloud и последние месяцы гоняю Prometheus и VictoriaMetrics на одном стенде, чтобы понять, сколько на самом деле стоит одна точка метрики на диске. Обе системы делают одно и то же: принимают миллионы точек в минуту, хранят их месяцами и быстро отдают в алерты и дашборды. Обе сжимают точку до байтов и долей байта. Именно эти байты, умноженные на миллиарды точек в сутки, превращаются в счёт за диск. Ошибка в расчёте цены сэмпла заканчивается переполненным диском под мониторингом, урезанным retention или незапланированным расходом. Когда место под метрики кончается, первым на планёрке звучит «сменим движок». Публичные бенчмарки подталкивают к тому же: Флант показывает, что Prom++, форк Prometheus, тратит памяти в 7,8 раза меньше Prometheus v2 ( разбор на Habr ), VictoriaMetrics показывает трёхкратную экономию диска против Grafana Mimir ( бенчмарк VictoriaMetrics , замер вендора, 2022 год). На моём стенде картина оказалась сложнее. В Prometheus 3.13 и VictoriaMetrics 1.149 ушёл один и тот же набор: 2,88 млн сэмплов, шесть профилей данных, один генератор с фиксированным seed. Внутри одного движка цена сэмпла различалась в 139 раз у VictoriaMetrics и в 12,8 раза у Prometheus. Между движками на одних данных разрыв доходил до 30,7 раза на шести профилях и до 34,3 раза в опыте с точностью. На равномерно случайных float64 движки менялись местами. Один лишний знак после запятой поднимал цену сэмпла у Prometheus в восемь раз, у VictoriaMetrics на 12%.

https://habr.com/ru/companies/vk/articles/1068798/

#vk_cloud #prometheus #victoriametrics #time_series #tsdb #мониторинг #метрики #observability #сжатие_данных #cardinality

Кто на самом деле сломал вашего ИИ-агента: модель или обвязка?

Когда агент в проде ошибается, спор идёт по кругу: модель тупит, промпт кривой, API виноват. Свежая работа Scale AI даёт отказам адрес — ребро между компонентами и сторону вины. Оказывается, «виновата модель» почти никогда не значит «чинить дообучением»: разбираю таксономию из 41 режима, каталог-выжимку и четыре своих отказа с числами — ни один не закрыт сменой модели.

https://habr.com/ru/articles/1079638/

#LLM #ИИагенты #agent_harness #обвязка #таксономия_отказов #RAG #отладка #метрики #тестирование #arXiv

Кто на самом деле сломал вашего ИИ-агента: модель или обвязка?

Когда агент в проде ошибается, спор идёт по кругу: модель тупит, промпт кривой, API виноват. Свежая работа Scale AI даёт отказам адрес — ребро между компонентами и сторону вины. Оказывается, «виновата модель» почти никогда не значит «чинить дообучением»: разбираю таксономию из 41 режима, каталог-выжимку и четыре своих отказа с числами — ни один не закрыт сменой модели.

https://habr.com/ru/articles/1079638/

#LLM #ИИагенты #agent_harness #обвязка #таксономия_отказов #RAG #отладка #метрики #тестирование #arXiv

Почему одинаковые показатели в разных отчётах не совпадают

Два отчёта показывают один показатель за один период. Название одинаковое, подразделение выбрано одно и то же, но значения различаются. В этот момент обсуждение часто сводится к поиску «неправильной цифры»: аналитики проверяют формулы, разработчики перезапускают загрузку, пользователи сравнивают выгрузки вручную. Проблема в том, что совпадения названия, периода и формулы недостаточно. Один отчёт может считать текущее состояние объектов, другой - события за период. Один использовать время совершения операции, другой - время загрузки записи. Один пересчитывать историю после исправлений, другой хранить опубликованный срез. Оба расчёта при этом могут быть технически корректными. В проектах с BI-отчётностью я работал с контуром, где данные проходили путь от операционных систем и общей базы через API и выгрузки к ручной обработке, отчётам и справкам. При такой схеме итог зависит не только от SQL-запроса. На него влияют состояние источника, дата среза, справочники, правила исключения, ручные преобразования и момент обновления каждого звена. Поэтому расхождение лучше расследовать не как спор двух чисел, а как сравнение двух воспроизводимых расчётов. В этой статье разберу, из каких слоёв состоит показатель, как локализовать различие и что изменить в аналитическом контуре, чтобы одинаковая бизнес-метрика не реализовывалась заново в каждом отчёте.

https://habr.com/ru/articles/1079462/

#аналитика_данных #BI #метрики #качество_данных #семантический_слой #data_lineage #data_contracts #сверка_отчётов #временные_данные #дашборды

Почему одинаковые показатели в разных отчётах не совпадают

Два отчёта показывают один показатель за один период. Название одинаковое, подразделение выбрано одно и то же, но значения различаются. В этот момент обсуждение часто сводится к поиску «неправильной цифры»: аналитики проверяют формулы, разработчики перезапускают загрузку, пользователи сравнивают выгрузки вручную. Проблема в том, что совпадения названия, периода и формулы недостаточно. Один отчёт может считать текущее состояние объектов, другой - события за период. Один использовать время совершения операции, другой - время загрузки записи. Один пересчитывать историю после исправлений, другой хранить опубликованный срез. Оба расчёта при этом могут быть технически корректными. В проектах с BI-отчётностью я работал с контуром, где данные проходили путь от операционных систем и общей базы через API и выгрузки к ручной обработке, отчётам и справкам. При такой схеме итог зависит не только от SQL-запроса. На него влияют состояние источника, дата среза, справочники, правила исключения, ручные преобразования и момент обновления каждого звена. Поэтому расхождение лучше расследовать не как спор двух чисел, а как сравнение двух воспроизводимых расчётов. В этой статье разберу, из каких слоёв состоит показатель, как локализовать различие и что изменить в аналитическом контуре, чтобы одинаковая бизнес-метрика не реализовывалась заново в каждом отчёте.

https://habr.com/ru/articles/1079462/

#аналитика_данных #BI #метрики #качество_данных #семантический_слой #data_lineage #data_contracts #сверка_отчётов #временные_данные #дашборды

1.5 миллиона событий в день и ни одной таблицы events: как мы считали продуктовую аналитику 300K-бота по голому проду

Маркетолог прислал мне скрин дашборда и одно слово: «пусто». На скрине — панель «Количество пришедших по реферальной ссылке за период». Ноль. Под ней — график регистраций. Тоже ноль. Ссылка, по которой он пришёл, вела на дашборд с фильтром по конкретному slug — тому самому, который он неделю крутил в закупке. Я открыл ту же ссылку, поменял в урле from=now-6h на from=now-30d и увидел 16 регистраций. Дефолтный интервал в Grafana — 6 часов. У бота ночью в этой гео никого нет. Аналитика работала идеально и показывала абсолютно честный ноль. Это самая безобидная из историй, которые тут будут. Дальше — про то, как мы строили продуктовую аналитику для Telegram-бота с AI-персонажами на ~300K MAU, ~75 RPS в пике и ~1.5M событий в день : без ClickHouse, без Amplitude, без единой event-таблицы. Двенадцать дашбордов в Grafana поверх боевой MySQL. Три из них какое-то время врали, и это выяснилось не сразу. Главный парадокс всего проекта помещается в одну строку: через систему проходит полтора миллиона событий в день, и ни одно из них не записано как событие. Есть только строки в продуктовых таблицах и их created_at . Всё, что вы прочитаете ниже, — следствие этого факта. Статья — не туториал «подключите MySQL к Grafana за 10 шагов». Это разбор того, что происходит, когда продуктовые метрики приходится доставать из схемы, которую проектировали под продукт, а не под аналитику, — и когда по этим метрикам прямо сейчас решают, лить трафик дальше или нет. Дисклеймер: проект под NDA, поэтому названия, точные объёмы и часть деталей изменены. Порядок величин, схема и сами проблемы — настоящие.

https://habr.com/ru/articles/1078480/

#grafana #mysql #продуктовая_аналитика #sql #retention #воронка #telegram_bot #highload #метрики

1.5 миллиона событий в день и ни одной таблицы events: как мы считали продуктовую аналитику 300K-бота по голому проду

Маркетолог прислал мне скрин дашборда и одно слово: «пусто». На скрине — панель «Количество пришедших по реферальной ссылке за период». Ноль. Под ней — график регистраций. Тоже ноль. Ссылка, по которой он пришёл, вела на дашборд с фильтром по конкретному slug — тому самому, который он неделю крутил в закупке. Я открыл ту же ссылку, поменял в урле from=now-6h на from=now-30d и увидел 16 регистраций. Дефолтный интервал в Grafana — 6 часов. У бота ночью в этой гео никого нет. Аналитика работала идеально и показывала абсолютно честный ноль. Это самая безобидная из историй, которые тут будут. Дальше — про то, как мы строили продуктовую аналитику для Telegram-бота с AI-персонажами на ~300K MAU, ~75 RPS в пике и ~1.5M событий в день : без ClickHouse, без Amplitude, без единой event-таблицы. Двенадцать дашбордов в Grafana поверх боевой MySQL. Три из них какое-то время врали, и это выяснилось не сразу. Главный парадокс всего проекта помещается в одну строку: через систему проходит полтора миллиона событий в день, и ни одно из них не записано как событие. Есть только строки в продуктовых таблицах и их created_at . Всё, что вы прочитаете ниже, — следствие этого факта. Статья — не туториал «подключите MySQL к Grafana за 10 шагов». Это разбор того, что происходит, когда продуктовые метрики приходится доставать из схемы, которую проектировали под продукт, а не под аналитику, — и когда по этим метрикам прямо сейчас решают, лить трафик дальше или нет. Дисклеймер: проект под NDA, поэтому названия, точные объёмы и часть деталей изменены. Порядок величин, схема и сами проблемы — настоящие.

https://habr.com/ru/articles/1078480/

#grafana #mysql #продуктовая_аналитика #sql #retention #воронка #telegram_bot #highload #метрики

Написал детектор ИИ-текста на 13 правил и прогнал 59 своих статей: сумма баллов не забраковала ни одну

Площадки перестали пускать машинный текст самотёком. Habr проверяет публикации автоматически, а Кевин Индиг пишет о том, что платформы строят anti-slop-системы — механизмы подавления массового низкокачественного ИИ-контента. Дальше обычно следует совет писать хорошо, и на этом разговор заканчивается. Мне нужно было проверяемое условие вместо совета, поэтому я собрал детектор на правилах и прогнал через него 59 собственных статей. Главный результат оказался не в том, сколько текстов он забраковал, а в том, что при агрегатном подсчёте он не забраковал ни одного, хотя дефекты были в сорока.

https://habr.com/ru/articles/1077790/

#детектор_ИИтекста #антиплагиат #Python #регулярные_выражения #качество_текста #редактура #проверка_контента #автоматизация #лингвистика #метрики

Написал детектор ИИ-текста на 13 правил и прогнал 59 своих статей: сумма баллов не забраковала ни одну

Площадки перестали пускать машинный текст самотёком. Habr проверяет публикации автоматически, а Кевин Индиг пишет о том, что платформы строят anti-slop-системы — механизмы подавления массового низкокачественного ИИ-контента. Дальше обычно следует совет писать хорошо, и на этом разговор заканчивается. Мне нужно было проверяемое условие вместо совета, поэтому я собрал детектор на правилах и прогнал через него 59 собственных статей. Главный результат оказался не в том, сколько текстов он забраковал, а в том, что при агрегатном подсчёте он не забраковал ни одного, хотя дефекты были в сорока.

https://habr.com/ru/articles/1077790/

#детектор_ИИтекста #антиплагиат #Python #регулярные_выражения #качество_текста #редактура #проверка_контента #автоматизация #лингвистика #метрики

От MTTD и MTTR к реальной ценности: как навести порядок в метриках SOC

Что можно выжать из базовых метрик SOC, если у тебя лапки Многие руководители начинают день с дашбордов и красивых «бубликов». На них традиционно горят классические временные метрики по заветам NIST SP 800-61: среднее время обнаружения/решения/взятия в работу инцидентов ИБ совместно с общим количеством обработанных инцидентов. Топ-менеджмент всё устраивает – они понятные, линейные и отлично смотрятся в квартальных отчетах. Но потом внезапно выясняется, что кейсы закрываются по инерции, решения становятся все более поверхностными, а качество расследований тихо уезжает в закат.

https://habr.com/ru/companies/gazpromcps/articles/1076804/

#incident_response #soar #siem #mttr #mttd #MTTA #кибербезопасность #метрики #falsepositive #soc

От MTTD и MTTR к реальной ценности: как навести порядок в метриках SOC

Что можно выжать из базовых метрик SOC, если у тебя лапки Многие руководители начинают день с дашбордов и красивых «бубликов». На них традиционно горят классические временные метрики по заветам NIST SP 800-61: среднее время обнаружения/решения/взятия в работу инцидентов ИБ совместно с общим количеством обработанных инцидентов. Топ-менеджмент всё устраивает – они понятные, линейные и отлично смотрятся в квартальных отчетах. Но потом внезапно выясняется, что кейсы закрываются по инерции, решения становятся все более поверхностными, а качество расследований тихо уезжает в закат.

https://habr.com/ru/companies/gazpromcps/articles/1076804/

#incident_response #soar #siem #mttr #mttd #MTTA #кибербезопасность #метрики #falsepositive #soc

Соревнование замерло 16 августа, а таблица поехала дальше. Разбираю, что из этого настоящее

Я полез в данные соревнования Pokemon TCG AI Battle посмотреть, кто там выигрывает, и залип на другом. На публичной таблице 6806 команд. Самая поздняя отправка решения датирована 16 августа, 23:58:53. После этой секунды не отправил никто 1668 команд из 6806, почти четверть поля, сделали финальную отправку именно в этот день: 824 из них после шести вечера, 350 в последний час. Похоже, немалая часть узнала про срок в тот же день, когда он истекал

https://habr.com/ru/articles/1074532/

#kaggle #соревнования #анализ_данных #статистика #метрики #лидерборд #визуализация_данных #ошибки_анализа #значимость #байтовая_квота

Соревнование замерло 16 августа, а таблица поехала дальше. Разбираю, что из этого настоящее

Я полез в данные соревнования Pokemon TCG AI Battle посмотреть, кто там выигрывает, и залип на другом. На публичной таблице 6806 команд. Самая поздняя отправка решения датирована 16 августа, 23:58:53. После этой секунды не отправил никто 1668 команд из 6806, почти четверть поля, сделали финальную отправку именно в этот день: 824 из них после шести вечера, 350 в последний час. Похоже, немалая часть узнала про срок в тот же день, когда он истекал

https://habr.com/ru/articles/1074532/

#kaggle #соревнования #анализ_данных #статистика #метрики #лидерборд #визуализация_данных #ошибки_анализа #значимость #байтовая_квота

Перестаньте делать фичи, которые никому не нужны

Периодически мы чувствуем , что предлагаем хорошее решение. Как в меме: «Эта фича будет прибыльной, но я пока не могу этого доказать». В этом случае оценка продукта не учитывает мнение целевой аудитории, как будто мы единственный пользователь нашего решения. Иногда при формировании новых гипотез мы можем столкнуться с подменой понятий идеи, ценности и спроса. В моменте идея может показаться нам настолько классной, что мы объясняем её ценность команде, но пропускаем этап её фактической проверки и сразу приступаем к разработке. Давайте разберёмся, как же всё-таки принимать решения с опорой на реальность.

https://habr.com/ru/companies/tochka/articles/1072436/

#Метрики #решения #data_driven #исследования #аналитика

Перестаньте делать фичи, которые никому не нужны

Периодически мы чувствуем , что предлагаем хорошее решение. Как в меме: «Эта фича будет прибыльной, но я пока не могу этого доказать». В этом случае оценка продукта не учитывает мнение целевой аудитории, как будто мы единственный пользователь нашего решения. Иногда при формировании новых гипотез мы можем столкнуться с подменой понятий идеи, ценности и спроса. В моменте идея может показаться нам настолько классной, что мы объясняем её ценность команде, но пропускаем этап её фактической проверки и сразу приступаем к разработке. Давайте разберёмся, как же всё-таки принимать решения с опорой на реальность.

https://habr.com/ru/companies/tochka/articles/1072436/

#Метрики #решения #data_driven #исследования #аналитика

Цена, которой не существовало: две недели поиска бага, который не видел мониторинг

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

https://habr.com/ru/articles/1070518/

#кэширование #распределённые_системы #консистентность_данных #мониторинг #наблюдаемость #метрики #разбор_инцидента

Цена, которой не существовало: две недели поиска бага, который не видел мониторинг

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

https://habr.com/ru/articles/1070518/

#кэширование #распределённые_системы #консистентность_данных #мониторинг #наблюдаемость #метрики #разбор_инцидента

Как мониторить Java-приложения: метрики, алерты и правило 80/20

Хороший мониторинг помогает быстро понять, что происходит с приложением и куда смотреть в первую очередь. Для этого не нужно пытаться измерить всё: базовый набор технических метрик покрывает большинство типовых проблем, а бизнес-метрики, SLO и анализ аномалий помогают заранее замечать нетипичные отклонения. В Календаре мы называем этот подход правилом 80/20 . Всем привет! Меня зовут Настя, я бэкенд-разработчик в Яндекс 360 и отвечаю за надёжность Календаря. В этой статье я покажу, какие метрики стоит взять за основу, как выбирать полезные алерты и чем дополнять базовый набор для оставшихся 20%.

https://habr.com/ru/companies/yandex/articles/1068874/

#мониторинг #метрики #алертинг #java #devops #sre #site_reliability_engineering #надежность #инцидентменеджмент

Как мониторить Java-приложения: метрики, алерты и правило 80/20

Хороший мониторинг помогает быстро понять, что происходит с приложением и куда смотреть в первую очередь. Для этого не нужно пытаться измерить всё: базовый набор технических метрик покрывает большинство типовых проблем, а бизнес-метрики, SLO и анализ аномалий помогают заранее замечать нетипичные отклонения. В Календаре мы называем этот подход правилом 80/20 . Всем привет! Меня зовут Настя, я бэкенд-разработчик в Яндекс 360 и отвечаю за надёжность Календаря. В этой статье я покажу, какие метрики стоит взять за основу, как выбирать полезные алерты и чем дополнять базовый набор для оставшихся 20%.

https://habr.com/ru/companies/yandex/articles/1068874/

#мониторинг #метрики #алертинг #java #devops #sre #site_reliability_engineering #надежность #инцидентменеджмент

Цифры не сходятся: алгоритм действий, который поможет находить расхождения в отчетах

Сообщение в личку в 18:40: «Слушай, а почему у тебя в выгрузке 11 903 заказа, а на дашборде 12 480? Завтра в 11 показываем отчет». Дальше начинается то, что я про себя называю паникой первого года и человек открывает свой запрос и перечитывает его сверху вниз, надеясь, что ошибка как-нибудь сама подсветится. Не подсвечивается. Тогда он переписывает запрос немного иначе, получает третье число, и к полуночи у него уже три версии правды и ноль понимания. За годы работы я разбирала такие расхождения десятки раз, собрала алгоритм, по которому причина находится примерно за час: таблица симптомов, семь шагов и список типовых причин, от границ периода до кэша дашборда.

https://habr.com/ru/articles/1069396/

#качество_данных #аналитика #анализ #аналитика_данных #джуниор_аналитик #карьера_итспециалиста #карьера_аналитика #карьера_аналитика_данных #карьера_аналитиков #метрики

Цифры не сходятся: алгоритм действий, который поможет находить расхождения в отчетах

Сообщение в личку в 18:40: «Слушай, а почему у тебя в выгрузке 11 903 заказа, а на дашборде 12 480? Завтра в 11 показываем отчет». Дальше начинается то, что я про себя называю паникой первого года и человек открывает свой запрос и перечитывает его сверху вниз, надеясь, что ошибка как-нибудь сама подсветится. Не подсвечивается. Тогда он переписывает запрос немного иначе, получает третье число, и к полуночи у него уже три версии правды и ноль понимания. За годы работы я разбирала такие расхождения десятки раз, собрала алгоритм, по которому причина находится примерно за час: таблица симптомов, семь шагов и список типовых причин, от границ периода до кэша дашборда.

https://habr.com/ru/articles/1069396/

#качество_данных #аналитика #анализ #аналитика_данных #джуниор_аналитик #карьера_итспециалиста #карьера_аналитика #карьера_аналитика_данных #карьера_аналитиков #метрики

Как оценивать эффективность разработки

Меня зовут Антон Омельяненко, я Head of Software Development в EXANTE. Менеджер управляет командой так, чтобы она приносила бизнесу результат. Чтобы понимать, насколько хорошо люди справляются с задачами, ему нужны данные о работе и система оценки. С разработкой это сложнее, чем кажется. В статье я разберу три вопроса: почему классические метрики не подходят для оценки эффективности разработчиков, как измерять её правильно и что делать, если вам кажется, что сотрудник работает не только на вас.

https://habr.com/ru/articles/1067558/

#продуктивность #удаленка #ии #эффективность #аналитика #метрики #разработка_по #gitlab #jira

Как оценивать эффективность разработки

Меня зовут Антон Омельяненко, я Head of Software Development в EXANTE. Менеджер управляет командой так, чтобы она приносила бизнесу результат. Чтобы понимать, насколько хорошо люди справляются с задачами, ему нужны данные о работе и система оценки. С разработкой это сложнее, чем кажется. В статье я разберу три вопроса: почему классические метрики не подходят для оценки эффективности разработчиков, как измерять её правильно и что делать, если вам кажется, что сотрудник работает не только на вас.

https://habr.com/ru/articles/1067558/

#продуктивность #удаленка #ии #эффективность #аналитика #метрики #разработка_по #gitlab #jira

OpenTelemetry как единый стандарт наблюдаемости для распределённых систем

Когда метрики, логи и трассировки живут в разных системах, поиск причины сбоя превращается в ручное сопоставление фрагментов. В статье разберём, как OpenTelemetry объединяет телеметрию распределённых систем, где в этой архитектуре находится Collector и какие ошибки чаще всего мешают получить действительно полезную наблюдаемость.

https://habr.com/ru/companies/otus/articles/1059546/

#OpenTelemetry #наблюдаемость #распределённые_системы #телеметрия #метрики #логирование #распределённая_трассировка #OpenTelemetry_Collector #OTLP #сэмплирование

OpenTelemetry как единый стандарт наблюдаемости для распределённых систем

Когда метрики, логи и трассировки живут в разных системах, поиск причины сбоя превращается в ручное сопоставление фрагментов. В статье разберём, как OpenTelemetry объединяет телеметрию распределённых систем, где в этой архитектуре находится Collector и какие ошибки чаще всего мешают получить действительно полезную наблюдаемость.

https://habr.com/ru/companies/otus/articles/1059546/

#OpenTelemetry #наблюдаемость #распределённые_системы #телеметрия #метрики #логирование #распределённая_трассировка #OpenTelemetry_Collector #OTLP #сэмплирование

Мы чинили инциденты всё быстрее — а недовольство клиентов росло. Почему MTBF важнее MTTR

Инцидентов стало в два раза больше. Время восстановления сократилось вдвое. Uptime сервисов держался в норме. По всем ключевым метрикам мы становились лучше. А обращения в саппорт росли, аккаунт-менеджеры передавали жалобы, и в клиентском чате всё чаще писали, что сервис нестабилен. Эта статья о том, как метрики надёжности могут хором врать о клиентском опыте, почему установка «чините быстрее» — ловушка, которая сжигает дежурных инженеров и прячет настоящую причину проблем, и как мы развернули фокус с MTTR на MTBF, сократили количество инцидентов вдвое и вернули поток обращений клиентов к норме.

https://habr.com/ru/articles/1064948/

#mtbf #mttr #sre #надежность #метрики #инциденты #управление_разработкой

Мы чинили инциденты всё быстрее — а недовольство клиентов росло. Почему MTBF важнее MTTR

Инцидентов стало в два раза больше. Время восстановления сократилось вдвое. Uptime сервисов держался в норме. По всем ключевым метрикам мы становились лучше. А обращения в саппорт росли, аккаунт-менеджеры передавали жалобы, и в клиентском чате всё чаще писали, что сервис нестабилен. Эта статья о том, как метрики надёжности могут хором врать о клиентском опыте, почему установка «чините быстрее» — ловушка, которая сжигает дежурных инженеров и прячет настоящую причину проблем, и как мы развернули фокус с MTTR на MTBF, сократили количество инцидентов вдвое и вернули поток обращений клиентов к норме.

https://habr.com/ru/articles/1064948/

#mtbf #mttr #sre #надежность #метрики #инциденты #управление_разработкой

Логарифм для аналитика: где он спасает отчет, а где его ломает

Модель прогноза выручки занижала цифры вдвое. Ошибка была в одной строке – np.exp() вместо честного возврата из логарифмов. Разбираю этот кейс и всё остальное, что аналитику нужно знать про логарифм: декомпозиция роста, эластичность, A/B-тесты и поправка Дуана. С кодом и цифрами.

https://habr.com/ru/articles/1064212/

#математика_для_аналитика #анализ_данных #аналитика_данных #логарифм #логарифмы #эластичность #абтесты #метрики #выручка

Логарифм для аналитика: где он спасает отчет, а где его ломает

Модель прогноза выручки занижала цифры вдвое. Ошибка была в одной строке – np.exp() вместо честного возврата из логарифмов. Разбираю этот кейс и всё остальное, что аналитику нужно знать про логарифм: декомпозиция роста, эластичность, A/B-тесты и поправка Дуана. С кодом и цифрами.

https://habr.com/ru/articles/1064212/

#математика_для_аналитика #анализ_данных #аналитика_данных #логарифм #логарифмы #эластичность #абтесты #метрики #выручка

ClickHouse: сценарии, сильные стороны, лучшие практики работы в 2026 году

ClickHouse — один из самых востребованных инструментов для хранения и анализа больших объемов данных, обеспечивающий высокую производительность и наблюдаемость сервисов и приложений. Благодаря этим параметрам многие компании внедряют его в свои ИТ-инфраструктуры для решения задач аналитики, логирования и мониторинга. Однако, несмотря на широкое распространение, практика показывает, что далеко не все команды до конца осознают все особенности и нюансы работы с этой системой, что может приводить к неэффективному использованию ресурсов, ошибкам в проектировании и снижению общей производительности. Привет, Хабр. Меня зовут Александр Кривяков. Я пресейл-архитектор VK Data Platform , VK Tech. В этой статье я расскажу об основных принципах работы ClickHouse, а также покажу возможные архитектурные решения и типичные сценарии применения системы.

https://habr.com/ru/companies/vktech/articles/1061284/

#vk_cloud #clickhouse #olap #колоночное_хранение #большие_данные #data_platform #логирование #метрики #архитектура_данных #best_practices

ClickHouse: сценарии, сильные стороны, лучшие практики работы в 2026 году

ClickHouse — один из самых востребованных инструментов для хранения и анализа больших объемов данных, обеспечивающий высокую производительность и наблюдаемость сервисов и приложений. Благодаря этим параметрам многие компании внедряют его в свои ИТ-инфраструктуры для решения задач аналитики, логирования и мониторинга. Однако, несмотря на широкое распространение, практика показывает, что далеко не все команды до конца осознают все особенности и нюансы работы с этой системой, что может приводить к неэффективному использованию ресурсов, ошибкам в проектировании и снижению общей производительности. Привет, Хабр. Меня зовут Александр Кривяков. Я пресейл-архитектор VK Data Platform , VK Tech. В этой статье я расскажу об основных принципах работы ClickHouse, а также покажу возможные архитектурные решения и типичные сценарии применения системы.

https://habr.com/ru/companies/vktech/articles/1061284/

#vk_cloud #clickhouse #olap #колоночное_хранение #большие_данные #data_platform #логирование #метрики #архитектура_данных #best_practices

Вместо DORA: как перестать измерять всё подряд и начать управлять процессом разработки

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

https://habr.com/ru/companies/tochka/articles/1060134/

#метрики_процесса #метрики #команда_разработки #точка_банк

Вместо DORA: как перестать измерять всё подряд и начать управлять процессом разработки

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

https://habr.com/ru/companies/tochka/articles/1060134/

#метрики_процесса #метрики #команда_разработки #точка_банк

Сократили цикл разработки на 20% — и получили вдвое больше инцидентов

В продуктовой B2B-компании, где я отвечал за надёжность, поставили амбициозную цель: сократить цикл разработки (dev cycle time) на 20%. Забегая вперёд, скажу: к концу года цель достигли. Но уже через несколько месяцев после старта я смотрел на график инцидентов и не верил своим глазам: рост в два раза год к году. Эта статья — о том, почему так происходит почти всегда, когда компания оптимизирует одну метрику, как мы это починили и — главное — как продать решение руководству. Именно на продаже всё обычно и умирает.

https://habr.com/ru/articles/1059894/

#контрметрики #sre #метрики #надёжность #управление_разработкой #инциденты #dev_cycle_time

Сократили цикл разработки на 20% — и получили вдвое больше инцидентов

В продуктовой B2B-компании, где я отвечал за надёжность, поставили амбициозную цель: сократить цикл разработки (dev cycle time) на 20%. Забегая вперёд, скажу: к концу года цель достигли. Но уже через несколько месяцев после старта я смотрел на график инцидентов и не верил своим глазам: рост в два раза год к году. Эта статья — о том, почему так происходит почти всегда, когда компания оптимизирует одну метрику, как мы это починили и — главное — как продать решение руководству. Именно на продаже всё обычно и умирает.

https://habr.com/ru/articles/1059894/

#контрметрики #sre #метрики #надёжность #управление_разработкой #инциденты #dev_cycle_time

Как оценивать работу специалиста, отвечающего за автотесты, метрики и KPI?

Привет, Хабр! Меня зовут Андрей, я SDET-специалист в компании SimbirSoft. В этой статье мы разберём, какие метрики действительно применимы к специалисту по автотестированию и как их корректно использовать. Будет полезно для тимлидов команд по обеспечению качества, автотестировщиков и любых специалистов, которые хотят оценить метрики автотестирования. Традиционный метод постановки задач сотрудникам — это каскадная модель «сверху вниз»: общие цели проекта декомпозируются до целей подразделения, а затем преобразуются в индивидуальные задачи сотрудников. Логично предположить, что цели проекта и сотрудника синхронизированы, а собрав структурированные цели всех сотрудников, можно получить условный макет проекта. Однако возникает вопрос: как оценить вклад конкретного специалиста по автотестированию? Жми, чтобы узнать подробности 🤓

https://habr.com/ru/companies/simbirsoft/articles/1057952/

#автоматизация_тестирования #оценка_трудозатрат #метрики #kpi #kpi_показатели #обеспечение_качества

Как оценивать работу специалиста, отвечающего за автотесты, метрики и KPI?

Привет, Хабр! Меня зовут Андрей, я SDET-специалист в компании SimbirSoft. В этой статье мы разберём, какие метрики действительно применимы к специалисту по автотестированию и как их корректно использовать. Будет полезно для тимлидов команд по обеспечению качества, автотестировщиков и любых специалистов, которые хотят оценить метрики автотестирования. Традиционный метод постановки задач сотрудникам — это каскадная модель «сверху вниз»: общие цели проекта декомпозируются до целей подразделения, а затем преобразуются в индивидуальные задачи сотрудников. Логично предположить, что цели проекта и сотрудника синхронизированы, а собрав структурированные цели всех сотрудников, можно получить условный макет проекта. Однако возникает вопрос: как оценить вклад конкретного специалиста по автотестированию? Жми, чтобы узнать подробности 🤓

https://habr.com/ru/companies/simbirsoft/articles/1057952/

#автоматизация_тестирования #оценка_трудозатрат #метрики #kpi #kpi_показатели #обеспечение_качества