Рубрика «метрики»

Привет! На связи Владимир Гурьянов, технический директор Deckhouse Observability Platform в компании «Флант». В своём докладе на DevOpsConf 2024 я провёл небольшое расследование и выяснил, кто виноват в том, что Prometheus «съел» 64 ГБ оперативной памяти на сервере. А главное — я разобрался, что нужно делать, чтобы избегать этого в будущем. В этой статье приведу основные размышления и выводы из доклада.

Читать полностью »

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

Читать полностью »

Проектируем А-Б-эксперименты грамотно - 1

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

Читать полностью »

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

За информацию из этой статьи, я был готов заплатить деньги, убить или сходить на концерт Шамана.

Уверен, что мой рассказ будет полезен не только пользователям Superset, но и всем аналитикам, которые используют SQL в своей работе и учёбе.

Не буду рассказывать про базовое построение таблиц на BI системе Superset, с этим прекрасно справятся тонны видео на ютубе и бесполезные курсы (про которые я писал ранееЧитать полностью »

Почему OKR — это отстой - 1

Наверно, многие из моих читателей как раз закончили квартальный (и/или годовой) цикл планирования, так что сейчас будет подходящее время напомнить, что процесс, которым мы пользуемся как стандартом в технологической отрасли, на самом деле — полная чушь. Разумеется, я имею в виду методологию Objectives and Key ResultsЧитать полностью »

Тирания маргинального юзера. Почему всё вокруг становится примитивнее - 1

C каждым годом софт требует всё больше ресурсов: больше памяти, мощного CPU, аппаратного ускорения графики и т. д. Причина в целом понятна. Постоянные тормоза веб-платформы и нового софта — отчасти плата за удобство разработки (с повышением уровня абстракций). Железо становится мощнее, индустрия это использует. Всё нормально.

Но непонятно другое. Почему происходит реальная деградация интерфейсов. Грубо говоря, почему они становятся всё более примитивными и тупыми, словно рассчитаны на жителей «Идиократии» (на КДПВ). И речь не только о веб-сайтах.
Читать полностью »

Аналитика и оптимизация батарей в IoT-устройствах - 1


В прошлом я занимал должность инженера ПО в двух компаниях-производителях нательной электроники — Pebble и Fitbit. За время моей работы клиенты постоянно жаловались на одну и ту же проблему: продолжительность работы батареи. Это была непрекращающаяся «борьба с гидрой», когда каждая новая версия прошивки вела к очередной регрессии жизни батареи.Читать полностью »

Мониторинг — это боль - 1


И все мы выполняем его неправильно (в том числе и я).

Я должен признаться. Несмотря на то, что меня много раз нанимали в том числе и благодаря моему опыту работы с платформами мониторинга, я начал его ненавидеть. Инструменты мониторинга и наблюдаемости (observability) совершают тяжкий грех: обманом заставляют людей думать, что это простая задача. Очень легко мониторить маленькое приложение или сервис. Но почти ни одно из таких решений не масштабируется.

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

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

В статье я расскажу о том, что, по моему мнению, нужно делать, а также поделюсь своими надеждами и мечтами. Прошу вас убедить меня, что я не прав и что есть более качественные решения.
Читать полностью »

Как вообще можно управлять отдельными людьми в команде разработки? - 1

Перформанс — это результативность команды. Начиная с этого места понятийный аппарат разваливается. Чтобы измерять результативность, нужно знать какую-то метрику. Метрика «строчки кода» определённо не подходит, а метрика «готовые фичи» измеряет продуктолога или команду, а не индивидуального разработчика. И вот этим «чем-то» ещё нужно управлять. Логика в том, чтобы разработчик разрабатывал нужное и с понятной скоростью, чтобы на него можно было полагаться в задачах.

Управлять можно, например:

  • Балансом между костылями и оверинжинирингом.
  • Балансом между тестированием кода и быстрой выкаткой на прод.
  • Балансом между техническим долгом и TTM.
  • Балансом между «пиши код» и «развивай своего джуна» и так далее.

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

Но вы не управляете даже этим! Этим всем управляет сам разработчик. Вы же управляете тем, как он понимает текущую ситуацию с компанией, продуктом, командой и своим развитием.

Собственно, вот эта тонкая грань и есть перформанс-менеджмент.
Читать полностью »

Продолжаем цикл статей об организации мониторинга. В первом материале разбирали, как и куда вообще имеет смысл навешивать алерты. Теперь поговорим о мониторинге базового серверного ПО, которое встречается в работе практически любого веб-проекта. Хочу поделиться метриками и алертами, которые мы в ITSumma используем для мониторинга виртуальных машин, docker/LXC-контейнеров, web- и application-серверов, supervisor’а, кастомных сервисов, а также ping-url’ов, SSL-сертификатов и доменных имен.

Читать полностью »

https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js