Год назад мы запустили пилотную версию промо проекта по децентрализованному прокату электроскутеров.

Изначально проект назывался Road-To-Barcelona, позже стал Road-To-Berlin (отсюда встречающиеся на скриншотах R2B), а в итоге и вовсе был назван xRide.

Основная идея проекта была в следующем: вместо того чтобы иметь централизованный сервис проката автомобилей или скутеров (речь пойдет о скутерах aka электро-мотоциклах, а не kickscooter/самокатах)
мы хотели сделать платформу для децентрализованной аренды. О сложностях с которыми мы столкнулись уже писали ранее.

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

Пользователь устанавливал iOS или Android приложение на телефон, подходил к понравившемуся ему скутеру, после чего телефон и скутер устанавливали peer-to-peer соединение, происходил обмен ETH и пользователь мог начать поездку включив скутер через телефон. По завершении поездки так же можно было провести оплату поездки за счет эфира из кошелька пользователя на телефоне.

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

Так в целом и выглядел наш пилот, запущенный в сентябре прошлого года в двух городах Германии: Бонн и Берлин.

И вот, однажды, в Бонне, ранним утром наша команда поддержки (находящаяся в локации для поддержания скутеров в работоспособном состоянии) была поднята по тревоге: один из скутеров бесследно исчез.
Как его найти и вернуть?

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

Что и зачем мониторить: скутеры, инфраструктура, зарядки?

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

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

Скутеры

Что же из себя представляли наши скутеры и что мы хотели о них знать?

Первое, и самое существенное GPS координаты, так как благодаря им мы можем понимать, где они находятся и куда двигаются.

Далее заряд батареи, благодаря ему мы можем определять, что зарядка скутеров подходит к концу и отправить juicer'а или хотя бы предупредить пользователя.

Конечно, необходимо также проверять что происходит с нашими Hardware компонентами:

• работает ли Bluetooth?
• работает ли сам GPS модуль?
  
  • так же у нас была проблема с тем, что GPS мог отсылать неверные координаты и "залипать", а определить это можно было только на уровне дополнительных проверок на скутере,
    и нотифицировать поддержку как можно скорее для устранения проблемы

И последнее: проверки софтверной части, начиная с ОС и загрузки процессора, сети и диска, заканчивая уже более специфичными для нас проверками наших собственных модулей (jolocom, keycloak).

Hardware

Что же представляла наша "железная" часть?
Учитывая максимально сжатые сроки и необходимость быстрого прототипирования мы выбрали для себя максимально простой для реализации и подбора компонентов вариант Raspberry Pi.
Помимо самого Rpi мы имели кастомную борду (которые мы сами разработали и заказывали в Китае для ускорения процесса сборки конечного решения) и набор компонентов реле (для включения/выключения скутера), считыватель заряда батареи, модем, антенны. Все это было компактно укомплектовано в специальную коробочку "xRide box".

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

Docker? Plain linux? и деплой

Вернемся к мониторингу, итак Raspberry что же мы имеем?

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

К сожалению, довольно быстро стало ясно что Docker на RPi хоть и работает, но дает достаточно много накладных расходов, в частности по энергопотреблению.

Разница с использованием "нативной" ОС пусть и не была настолько сильной, но все же достаточной чтобы мы опасались возможности слишком быстрой потери заряда.

Второй причиной стала одна из библиотек наших партнеров на Node.js (sic!) единственный компонент системы, который не был написан на Go/C/C++.
Авторы библиотеки не успели вовремя предоставить рабочую версию на любом из "нативных" языков.
Мало того, что нода сама по себе не является самым элегантным решением для низкопроизводительных девайсов, так еще и сама библиотека была весьма прожорлива по ресурсам.

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

OS

В итоге, качестве ОС мы, опять же, избрали самый простой вариант и использовали Raspbian (сборка Debian для Pi).
Весь наш софт мы пишем на Go, поэтому и основной hardware-агент модуль в нашей системе мы также написали на Go.
Именно он и отвечает за работу с GPS, Bluetooth, считывание заряда, включение скутера, итд.

Деплой

Тут же встал вопрос о необходимости реализации механизма доставки обновлений на девайсы (OTA) как обновлений самого нашего агента/приложения, так и обновления самой ОС/"прошивки"
(так как новые версии агента могли требовать обновлений ядра или компонентов системы, библиотек итд).

После довольно долгого анализа рынка выяснилось, что существует довольно много решений для доставки обновлений на девайс.
От относительно простых утилит, по большей части ориентированных на обновление/dual-boot вроде swupd/SWUpdate/OSTree до полноценных платформ вроде Mender и Balena.

В первую очередь мы решили, что нас интересуют именно end-to-end решения, поэтому выбор сразу пал на платформы.
Самым Balena была исключена ввиду того, что фактически использует тот же самый Docker внутри своего balenaEngine.
Но отмечу, что несмотря на это, в конечном итоге мы постоянно использовали их продукт Balena Etcher для флеша прошивок на SD карты простая и крайне удобная утилита для этого.

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

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

Ansible

Самым простым решением в нашей ситуации оказалось использование Ansible. Пары playbook'ов для начала было вполне достаточно.
Суть их сводилась к тому, что мы просто подключались с хоста (CI сервер) по ssh к нашим расберри и разливали на них обновления.

В самом начале все было просто нужно было находиться в единой сети с устройствами, разливка шла через Wi-Fi.
В офисе просто находилось десяток тестовых малинок, подключенных к одной сети, каждое устройство имело статический IP адрес так же указанный в Ansible Inventory.

Именно Ansible доставлял наш мониторинг-агент на конечные устройства

3G/LTE

К сожалению, такой вариант использования Ansible мог работать только в режиме разработки, пока у нас еще не было реальных скутеров.
Потому что скутеры, как вы понимаете, не стоят подключенные к одному Wi-Fi роутеру постоянно ожидая обновления по сети.

В реальности у скутеров вообще не может быть никакого соединения кроме мобильного 3G/LTE (и то не постоянно).
Это накладывает сразу много проблем и ограничений, вроде низкой скорости соединения и нестабильной связи.

Но самое главное в 3G/LTE сети мы не можем просто надеяться на статичный IP присвоенный в сети.
Это частично решается некоторыми провайдерами SIM карт, есть даже специальные симки предназначенные для IoT устройств со статическими IP адресами. Но мы не имели доступа к таким SIM картам и не могли использовать IP адреса.

Конечно, были идеи делать некую регистрацию IP адресов aka service discovery где-то вроде Consul, но от подобных идей пришлось отказаться,
так как у нас в тестах IP адрес мог меняться слишком часто, что приводило к большой нестабильности работы.

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

VPN

В качестве решения этой проблемы мы выбрали VPN а конкретно Wireguard.

Клиенты (скутеры) на старте системы подключались к VPN серверу и держали возможность подключения к ним. Этот туннель и использовался для доставки обновлений.

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

Облачные ресурсы

Последнее необходимо отслеживать наши облачные сервисы и БД, так как для них мы используем Kubernetes, в идеале чтобы разворачивание мониторинга в кластере было максимально простым. В идеале с использованием Helm, так как для деплоя, мы в большинстве случаев используем его. И, само собой, для мониторинга облака нужно использовать те же решения, что и для самих скутеров.

Дано

Фуф, вроде с описанием разобрались, давайте составим список того, что нам было нужно в итоге:

• Быстрое решение, так как мониторить необходимо уже во время процесса разработки
• Объем/количество нужно множество метрик
• Сбор логов обязателен
• Надежность данные критически важны для успеха запуска
• Нельзя использовать pull модель нужен push
• Нужен единый мониторинг не только железа, но и облака

Конечная картинка выглядела примерно так

Выбор стека

Итак, перед нами встал вопрос выбора стека для мониторинга.

В первую очередь, мы искали наиболее полноценное all-in-one решение, которое одновременно покрывало бы все наши требования, но при этом и было бы достаточно гибким чтобы подогнать его использование под наши нужды. Все-таки, у нас было много ограничений наложенных на нас железом, архитектурой и сроками.

Существует огромное множество решений для мониторинга,
начиная полноценными системами вроде Nagios, icinga или zabbix и заканчивая уже готовыми решениями по Fleet management.

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

После анализа какого-то количества подобных решений мы быстро пришли к выводу, что проще и быстрее будет собрать схожий стек самостоятельно. Да, это будет чуть сложнее чем разворачивание полностью готовой Fleet management платформы, но зато нам не придется идти на компромиссы.
Почти наверняка, во всем огромном обилии решений и есть уже готовое которое полностью бы нам подошло,
но в нашем случае значительно быстрее было собрать некий стек самостоятельно и подогнать "под себя", нежели тестировать готовые продукты.

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

(B)ELK?

Первое решение, которое реально рассматривалось широко известный ELK стек.
На самом деле он должен называться BELK, ведь начинается все с Beats https://www.elastic.co/what-is/elk-stack

Конечно, ELK это одно из самых известных и мощных решений в области мониторинга, а уж в сборе и обработке логов, так и самое.

Мы подразумевали, что ELK будет использоваться для сбора логов и, так же как долговременное хранилище метрик полученных из Prometheus.
Для визуализации можно использовать Grafan'у.

На самом деле, свежий ELK стек умеет собирать метрики и самостоятельно (metricbeat), Kibana так же умеет показывать их.

Но все-таки изначально ELK вырос из логов и пока функционал метрик имеет ряд серьезных недостатков:

• Значительно медленнее Prometheus
• Интегрируется в куда меньшее количество мест чем Prometheus
• Сложно настроить алертинг по ним
• Метрики занимают большое количество места
• Настройка дашбордов с метриками в Kiban'е значительно сложнее Grafan'ы

В общем, метрики в ELK тяжелые и пока не такие удобные как в других решениях, которых сейчас на самом деле значительно больше чем просто Prometheus: TSDB,
Victoria Metrics, Cortex итд итп. Конечно, очень бы хотелось иметь сразу полноценное all-in-one решение, но в случае с metricbeat выходило слишком много компромиссов.

Да и у самого ELK стека есть ряд непростых моментов:

• Он тяжелый, порой даже очень, если у вас собирается довольно большое количество данных
• Его нужно "уметь готовить" скалировать его необходимо, но делается это нетривиально
• Урезанная бесплатная версия в бесплатной версии нет нормального алертинга, на момент выбора не было и аутентификации

Надо сказать, что в последнее время с последним пунктом стало получше и помимо вывода в open-source X-pack (в том числе аутентификация) начала меняться сама модель прайсинга.
Но на момент, когда мы собирались разворачивать это решение, алертинга не было совсем.
Возможно, можно было попробовать собрать что-то с использованием ElastAlert или других community решений, но все же решили рассмотреть другие альтернативы.

Loki Grafana Prometheus

На данный момент неплохим решением может быть сборка стека мониторинга на основе чисто Prometheus как поставщика метрик,
Loki для логов, а для визуализации можно использовать все ту же Grafana.
К сожалению, на момент старта прода пилота проекта (сентярбь-октябрь 19ого года) Loki еще находился в бета версии 0.3-0.4,
а на момент старта разработки и вовсе не мог рассматриваться как produtcion решение.

Я пока не имею опыта реального использования Loki в серьезных проектах, но могу сказать, что Promtail (агент для сбора логов) здорово работает как для bare-metal, так и для подов в kubernetes.

TICK

Пожалуй, наиболее достойной (единственной?) полнофункциональной альтернативой ELK стеку сейчас можно назвать только TICK стек Telegraf, InfluxDB, Chronograf, Kapacitor.

Я опишу все компоненты ниже более подробно, но в целом идея такая:

• Telegraf агент для сборки метрик
• InfluxDB база данных метрик
• Kapacitor обработчик метрик в реальном времени для алертинга
• Chronograf веб панель для визуализации

Для InfluxDB, Kapacitor и Chronograf есть официальные helm чарты, которые мы использовали для их разворачивания.

Надо отметить, что в свежей версии Influx 2.0 (beta) Kapacitor и Chronograf стали частью InfluxDB и больше не существуют отдельно

Telegraf

Telegraf это очень легковесный агент для сбора метрик на конечной машине.
Он умеет мониторить огромное количество всего, от nginx до
сервера minecraft.

У него есть ряд классных преимуществ:

• Быстрый и легкий (написан на Go)
  
  • Ест минимальное количество ресурсов
• Push метрик по умолчанию
• Собирает все необходимые метрики
  
  • Системные метрики без каких-либо настроек
  • Хардварные метрики вроде информации с датчиков
  • Очень легко добавлять собственные метрики
• Много плагинов "из коробки"
• Собирает логи

Так как push метрик был для нас необходим, все остальные преимущества были более чем приятными дополнениями.

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

Telegraf вообще отличный агент для сборки метрик, даже если вы не используете весь остальной ICK стек.
Многие скрещивают его и с ELK и с различными другими time-series базами по удобству, так как он умеет писать метрики почти куда угодно.

InfluxDB

InfluxDB основное ядро TICK стека, а именно time-series база данных для метрик.
Помимо метрик Influx также может хранить и логи, хотя, по сути логи для него это всего лишь такие же метрики,
только вместо обычных числовых показателей основную функцию несет строка текста лога.

InfluxDB тоже написан на Go и работает, по ощущениям, значительно быстрее в сравнении с ELK на нашем (не самом мощном) кластере.

К одним из крутых преимуществ Influx я бы также отнес очень удобное и богатое API для запросов к данным,
которые мы очень активно использовали.

Недостатки $$$ или скалирование ?

У TICK стека есть только один обнаруженный нами недостаток он дорогой. Даже очень.

А что есть в платной версии, чего нет в бесплатной?

Насколько нам удалось понять, единственное чем отличается платная версия TICK стека от бесплатной возможности скалирования.

А именно поднять кластер с High availability можно только в Enterprise версии.

Хотите полноценное HA нужно либо платить, либо городить какие-нибудь костыли. Есть пара решений сообщества например influxdb-ha похоже на грамотное решение, но написано что не подходит для продакшена, а так же
influx-spout простое решение с прокачкой данных через NATS (его тоже придется скалировать, но это решаемо).
Жаль, но оба они, похоже, заброшены нет свежих коммитов, предположу, что дело в скором ожидаемом выходе новой версии Influx 2.0 в которой многое будет иначе (пока информации о скалировании в ней нет).

Официально для бесплатной версии существует Relay фактически это примитивное HA, но только посредством балансировки,
так как все данные будут писаться во все инстансы InfluxDB за load balancer'ом.
У него есть некоторые недостатки вроде потенциальных проблем с перезаписью точек и необходимости создавать базы для метрик заранее
(что при обычной работе с InfluxDB происходит автоматически).
К тому же шардирование не поддерживается, это означает дополнительные накладные расходы на дуплицированные метрики (и обработка и хранение),
которые могли вам быть не нужны, но разделить их возможности нет.

Victoria Metrics?

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

Time-series баз немало, но наиболее подающая надежды Victoria Metrics, у нее целый ряд плюсов:

• Быстрая и легкая, по крайней мере по результатам бенчмарков
• Есть кластерная версия, про которую сейчас даже есть хорошие отзывы
  
  • Она можешь шардироваться
• Поддерживает InfluxDB протокол

Мы не собирались строить полностью кастомный стек на основе Victoria и основная надежда была на то, что мы сможем воспользоваться ею как drop-in заменой для InfluxDB.

К сожалению, это невозможно, несмотря на то, что поддерживается протокол InfluxDB, это работает только для записи метрик "наружу" доступно только Prometheus API,
а значит натравить Chronograf на нее не получится.
Более того, для метрик поддерживаются только числовые значения (мы использовали строковые значения для кастомных метрик об этом в разделе админка).
Очевидно, по той же причине VM не может хранить логи, как это делает Influx.

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

Выбор базы

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

Основных причин такого выбора было несколько:

• Нам очень нравился функционал TICK стека целиком
• Мы уже успели его развернуть и оно отлично работало
• Сроки поджимали и не оставалось много времени тестировать другие варианты
• У нас не ожидалось такой большой нагрузки

Скутеров у нас для первой фазы пилота было не так много, и тестирование во время разработки не выявило каких-либо проблем с производительностью.
Поэтому мы решили, что для данного проекта нам вполне хватит и одно ноды Influx без необходимости скалирования (cм выводы в конце).

Со стеком и базой решили теперь об остальных компонентах TICK стека.

Kapacitor

Kapacitor это часть TICK стека, сервис который может следить за попадающими в базу метриками в реальном времени и выполнять на основе правил различные действия.

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

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

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

В Influx 2.0 Kapacitor стал частью DB

Chronograf

Я повидал много различных UI решений для мониторинга, но могу сказать, что по функционалу и UX ничто не сравнится с Chronograf'ом.

Начинали мы использовать TICK стек, как ни странно, с Grafan'ой в качестве веб-интерфейса.
Описывать ее функционал не буду, всем известны ее широкие возможности по настройке всего что угодно.

Однако, Grafana все же представляет из себя совсем универсальный инструмент, тогда как Chronograf в основном заточен под использование с Influx.
И конечно, благодаря этому, Chronograf может позволить себя куда более хитрый или удобный функционал.

Пожалуй, основное удобство работы с Chronograf в том, что вы можете смотреть внутренности вашей InfluxDB через Explore.

Казалось бы, в Grafana есть почти идентичный функционал, но в реальности настройка дашборда в Chronograf может осуществляться несколькими кликами мыши
(попутно смотря на визуализацию там же), тогда как в Grafana вам все равно рано или поздно придется редактировать JSON конфигурацию
(само собой Chronograf позволяет выгрузить ваши настроенные "руками" даши и редактировать в виде JSON если необходимо но мне никогда не приходилось их трогать после создания на UI).

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

Сами дашборды, помимо приятного визуального стиля, фактически ничем от дашбордов в Grafana или Kibana не отличаются:

Так выглядит то самое окно запросов:

Важно отметить, помимо прочего, что зная типы полей в базе InfluxDB хронограф иногда сам может
автоматически помогать вам с написанием Query или выбором правильной функции агрегации типа mean.

Ну и конечно же, Chronograf максимально удобен для просмотра логов. Выглядит это так:

По умолчанию Influx логи заточны под использование syslog и поэтому в них есть важный параметр severity.

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

Конечно, в идеале было бы настроить алертинг на такие ошибки, благо у нас уже было все для этого.
Мы даже на какое-то время включали это, но, в процессе подготовки пилота выяснилось, что у нас возникает довольно много ошибок
(в том числе системных вроде недоступности LTE сети), которые слишком сильно "спамят" в Slack канал, при этом не неся большой пользы.

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

Аутентификация

Отдельно стоит упомянуть то, что Chronograf поддерживает OAuth и OIDC в качестве аутентификации.
Это очень удобно, так как позволяет легко прикрутить его к вашему серверу и сделать полноценное SSO.

В нашем случае сервером был Keycloak он использовался для подключения к мониторингу,
но при этом тот же сервер использовался и для аутентификации скутеров и запросов на back-end.

Админка

Последний компонент, который я опишу это наша самописная "админка" на Vue.
В целом это просто отдельный сервис, который отображает информацию о скутерах одновременно из наших собственных баз данных, микросервисов и данные метрик из InfluxDB.

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

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

Один из уже упомянутых плюсов Influx возможность легко создавать свои собственные метрики.
Это позволяет использовать его для огромного множества сценариев.
Мы старались записывать туда всю полезную информацию: заряд батареи, состояние замка, работоспособность датчиков, bluetooth, GPS, множество других healthcheck'ов.
Все это мы и отображали на админ панели.

Конечно, самым главным критерием для нас было состояние работы скутера фактически Influx проверяет это сам и показывает в разделе Nodes "зелеными лампочками".
Делается это функцией deadman мы использовали ее же для понимания работоспособности нашей коробочки и отсылки тех самых алертов в Slack.

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

Да и вообще так было веселее. Постоянно звучали фразы вроде "Ребята Смитерс умер!"

Строковые метрики

Важно, что InfluxDB позволяет хранить не только числовые значения, как в случае с Victoria Metrics.

Казалось бы, это не так важно ведь если не считать логов, любые метрики можно хранить в виде чисел (всего лишь добавить маппинг для известных состояний своего рода enum)?

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

В результате API зарядок было далеко от идеала, но основной проблемой было то, что мы не всегда могли понять их состояние.
Тут на помощь и пришел Influx. Мы просто-напросто записывали приходящий нам строковый status в поле базы InfluxDB без изменений.

Какое-то время туда попадали только значения вида "online" и "offline", на основе чего у нас в админке отображалась информация,
а в Slack приходили уведомления. Однако в какой-то момент туда стали попадать так же значения вида "disconnected".
Как позже выяснилось, этот статус высылался однократно после потери связи, если зарядка не могла установить соединение с сервером после какого-то количества попыток.

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

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

Помимо обычных метрик, мы так же записывали в InfluxDB информацию о GPS локации. Это было невероятно удобно для мониторинга местонахождения скутеров в нашей админской панели.
Фактически, мы всегда знали где и какой скутер был в нужный нам момент времени.

Очень сильно нам это пригодилось, когда мы разыскивали скутер (смотри выводы в конце).

Мониторинг инфраструктуры

Помимо самих скутеров, нам было необходимо мониторить и всю нашу (довольно обширную) инфраструктуру.
Очень обобщенная архитектура выглядела примерно так:

Если выделить чисто стек мониторинга, то он выглядит следующим образом:

Из того что мы хотели бы проверять в облаке, это:

• Базы данных
• Keycloak
• Микросервисы

Так как все наши облачные сервисы находятся в Kubernetes, то было бы неплохо собирать информацию и о его состоянии.
К счастью, Telegraf "из коробки" может собирать огромное количество метрик о состоянии Kubernetes кластера, а Chronograf сразу предлагает для этого красивые дашборды.

Мы следили в основном за работоспособностью подов и потреблением памяти. В случае падения алерты в Slack.

Для отслеживания подов в Kubernetes есть два пути: DaemonSet и Sidecar.
Оба способа подробно описаны в этом блог посте.
Мы использовали Telegraf Sidecar и помимо метрик собирали логи подов.
В нашем случае с логами пришлось повозится. Несмотря на то что Telegraf умеет вытаскивать логи из Docker API, мы хотели иметь единообразный сбор логов с нашими конечными устройствами и настраивали для этого syslog для контейнеров. Возможно, это решение не было красивым, но нареканий в его работе не было и логи хорошо отображались в Chronograf'e.

Мониторить мониторинг???

В конце концов встал извечный вопрос мониторинга систем мониторинга, но к счастью, или к сожалению, на это у нас просто не хватило времени.
Хотя Telegraf легко умеет отправлять свои собственные метрики или собирать метрики InfluxDB базы для отправки либо в тот же Influx, либо куда-то еще.

Выводы

Какие выводы мы сделали по результатам пилота?

Как можно делать мониторинг

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

Производительность

Основная проблема TICK стека в бесплатной версии отсутствие возможностей по скалированию. Для нас это не стало проблемой.

Мы не собирали точных данных/цифр о нагрузке, но мы собирали данные с примерно 30и скутеров одновременно.
Каждый из них собирал более трех десятков метрик. Одновременно собирались логи с устройств. Сбор и отправка данных происходили каждые 10 секунд.

Важно отметить, что спустя полторы недели пилота, когда основную массу "детских болячек" удалось исправить и самые важные проблемы уже были решены,
нам пришлось снизить частоту отправки данных на сервер до 30и секунд. Это стало необходимо, потому что трафик на наших LTE SIM картах начал быстро таять.
Основную массу трафика съедали логи, сами метрики даже с 10и-секундным интервалом практически не тратили его.

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

Еще добавлю, что каждый отдельный environment у нас был отделен друг от друга, и вышеописанная нагрузка была актуальна только для продакшен среды.
В среде разработчиков у нас был поднят отдельный инстанс InfluxDB который продолжал собирать данные раз в 10 секунд и мы не уткнулись в какие-либо проблемы с производительностью.

TICK идеально для небольших-средних проектов

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

Если у вас нет тысяч подов или сотен машин даже один инстанс InfluxDB прекрасно справится с нагрузкой.
В некоторых случаях вас может устроить Influx Relay как примитивное решение по High Availability.

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

Если же вы не уверены в ожидаемой нагрузке на сервисы мониторинга, или у вас гарантированно есть/будет очень "тяжелая" архитектура бесплатную версию TICK стека использовать я бы не порекомендовал.
Конечно, простым решением было бы приобретение InfluxDB Enterprise но тут я не могу как-то прокомментировать, так как сам не знаком с тонкостями. Кроме того, что это очень дорогои точно не подойдет для мелких компаний.

В таком случае, на сегодняшний день, я бы порекомендовал посмотреть в сторону сбора метрик через Victoria Metrics и логов с помощью Loki.
Правда, снова оговорюсь, что Loki/Grafana значительно менее удобны (в виду своей большей универсальности) чем готовый TICK, но зато они бесплатны.

Важно: вся описанная здесь информация актуальна для версии Influx 1.8, в данный момент вот-вот должен выйти в релиз Influx 2.0.
Пока не довелось попробовать его в боевых условиях и сложно делать выводы об улучшениях, точно еще лучше стал интерфейс, упростилась архитектура (без kapacitor и chronograf),
появились темплейты ("киллер фича" можно отслеживать игроков в Fortnite и получать нотификации когда твой любимый игрок выигрывает партию). Но, к сожалению, в данный момент в версии 2 нет ключевой вещи, по которой мы выбрали первую версию нет сбора логов.
Этот функционал в Influx 2.0 тоже появится, но каких-либо сроков, даже примерных, найти не удалось.

Как не нужно делать IoT платформы (теперь)

В конце концов, запустив пилот мы сами собрали свой полноценный IoT стек, за неимением подходящей по нашим меркам альтернативы.
Однако, с недавнего времени в Beta версии доступна OpenBalena жаль ее не было когда мы начинали делать проект.

Конечный результат и та платформа на основе Ansible + TICK + WireGuard, которую мы собрали самостоятельно нас полностью устраивает. Но на сегодняшний день, я бы порекомендовал внимательней посмотреть на Balena прежде чем пытаться собрать свою IoT платформу самим.

Потому что, в конечном итоге она умеет делать большую часть того, что мы делали, при этом OpenBalena бесплатна, а код открыт.
Оно уже умеет не просто рассылать обновления, но и VPN там уже вшит и заточен под использование в IoT среде.

А совсем недавно они и вовсе выпустили свою Hardware, которая легко подключается в их экосистему.

Эй, а что с пропавшим скутером?

Итак скутер, "Ральф", бесследно исчез.
Мы сразу побежали смотреть карту в нашей "админке", с данными GPS метрик из InfluxDB.

Благодаря данным мониторинга, мы легко определили, что парковку скутер покинул около 21:00 прошлого дня, проехал где-то полчаса до какого-то района и был запаркован до 5и утра рядом с каким-то немецким домом.
После 5и утра данных мониторинга не поступало это означало либо полный разряд дополнительной батареи, либо злоумышленник догадался-таки извлечь умную начинку из скутера.
Несмотря на это, по тому адресу, где находился скутер все же была вызвана полиция. Скутера там не оказалось.
Однако владелец дома тоже был этому удивлен, так как он действительно вчера вечером приехал на этом скутере из офиса домой.

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

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

Зачем нужны цели? Как их формулировать? Какие проблемы могут возникнуть? По случаю Я.Субботника Pro я подготовил доклад, основанный на нескольких годах опыта ведения целей для команд в Яндексе.

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

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



Дисклеймер: о чем я не расскажу в докладе? Я не буду вам рассказывать всякие энциклопедические определения что такое SMART, OKR, KPI. Все это уже сто раз изложено в Википедии. Вы, наверное, и сами слышали все эти вещи. Если нет, быстрый поиск с помощью вашего любимого поисковика даст вам ответ. Там полно очень хороших статей. Буквально сегодня ночью проверял.



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

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

Зачем вести цели?

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

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



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



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



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

Второе: если вы руководитель, то возникает проблема одну и ту же вещь можно сделать очень большим диапазоном разных способов. И вам нужно понимать, как оценивать на ревью то, что сделали ваши подчиненные.

У меня есть доклад, посвященный нашей системе ревью. Там я подробнее рассказываю именно о том, как устроена наша внутренняя RPG: с уровнями, левел-апами, оценками и т. д.

Жизненный цикл

Давайте поговорим о жизненном цикле. Перейду уже, собственно, к изложению того, как это устроено у нас.



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



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

Что у нас есть? Разные части нашего процессного фрактала. Есть шестимесячные интервалы ревью сотрудников.



Каждые три месяца мидревью, где мы подводим промежуточные итоги ревьюшного периода.



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



И те самые двухнедельные спринты.



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



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

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



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

В рассказе про измеримость я приведу антипример. У меня есть крылатое (внутри Яндекса) понятие чекбоксовые цели.

Чекбоксовые цели

Это антипаттерн. Ваши цели, скорее всего, не очень хороши, если они звучат как сделать новую версию компонента X, запустить сервис Y или отрефакторить Z. Почему это плохо?

• Потому что, как я уже говорил, способов достижения целей в нашем мире очень много. Усилия на эти достижения расходуются суперНЕлинейно. Можно, например, сделать, тяп-ляп или сделать суперхорошо: упороться, написать документацию, все автотесты, а потом еще и выложить это в опенорс, что тянет за собой еще больше трудозатрат. То есть можно вообразить большую шкалу возможностей, как именно можно сделать ту или иную вещь.
  
  И если цель чекбоксовая, то совершенно нет ответа на вопрос насколько проработанным мы запускаем сервис X? Как много сил мы на него тратим?
• Если нет способа померить вещи друг относительно друга, эта приоритизация усложняется. Неизбежно возникнет ситуация, что нужно сделать и это, и это. Если задача сделать X, то вы не сможете по понятному курсу разменять это на что-то другое.
• Усложняется оценка результата. Например, вам нужно оценить две команды. Без процесса ревью и калибровок вы не сможете обнаружить, что одна команда поработала тяп-ляп, MVP-стайл, а вторая всё сделала хорошо, на века и очень подробно.

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

Создание метрики и определение таргетов часть работы над целью

Может возникнуть вопрос, что что-то очень сложно померить. И иногда уже нужно начинать бежать. Уже понятно, что нужно сделать сервис X или рефакторинг Y, но еще нет никаких метрик, которые позволили бы это измерить. Мы не понимаем, какие таргеты хотим себе поставить в качестве целевой картины. Как быть?

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



Я приведу пару примеров из наших реальных целей. В Яндексе есть команда, которая занимается так называемой Красотой Серпа, делает его красивее. Когда она появлялась, была только общая идея. Нате вам столько-то человек, делайте.

Команда вообще не знала, что такое красота и сколько процентов этой неизвестной красоты можно изменить. Тем не менее, они начали работать в параллельном режиме. Было интуитивное мнение, что какие-то вещи красивее, и давайте делать вот это. А параллельно они начали придумывать систему, которая позволит измерить эту самую красоту. И в итоге получилась система, метрика, про которую рассказал Антон Виноградов в докладе Красота Яндекса: дизайн для миллионов:


Суть системы: мы делаем сравнение side-by-side старой версии и новой. Затем считаем сумму позитивных изменений от каждого нашего внедрения на протяжении какого-то участка времени.

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



Второй пример в контексте работы над метриками один из наших старейших контуров, команда, которая занимается скоростью интерфейсов.

Когда она начиналась, тоже был общий посыл: сделайте, пожалуйста, чтобы Серп грузился быстрее. Но как измерить, быстрый он или нет? Были претензии вида: Я вот у себя открываю на телефоне, мне чего-то кажется медленно. Поисковики конкурентов быстрее!. Чтобы начать эту работу делать, не нужно было формулировать именно метрику. Мы знали банальные вещи: если пересылать по сети много байтиков, много кода запускать в JS, то будет долго. Давайте начнем что-то делать, а попутно собирать реальные метрики, понимать, как мы будем это измерять.

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


Параллельно ребята работали над достижением содержательной цели сокращения этих самых байтиков.

Измерить неизмеримое

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



Во-первых, стоит подумать еще раз. Как я говорил, с той же красотой, которая казалась субъективным понятием, нам удалось вывести более измеримую метрику.

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

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

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

Пара ключевых слов, которые помогут в опросах пользователей: csi nps. Но я думаю, идея понятна.

Метрика антибага

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

Сейчас расскажу, как она устроена. На ней можно проиллюстрировать сразу несколько моментов.



Первое: мы построили для команд суммарные графики взвешенного количества багов. То есть мы считаем в плавающем окне количество возникающих багов и расставили им веса соразмерно их приоритету. У нас миноры, тривиалы, нормалы, критикалы и блокеры отличаются друг от друга на порядок. У минора и тривиала вес 1, у нормала 10, у критикала 100, у блокера 1000. Получается такой график, который отражает, сколько сейчас на сервисе багов с учетом их приоритетов.

Второе: мы начали строить такие графики отдельно для багов, которые нашла сама команда и тестировщики команды, и для тех, которые зарепортили внешние пользователи. Затем мы подвесили составную часть цели, провели таргет. У нас внутри этот процесс называется zero bug policy. Но понятно, что zero это такой недостижимый идеал и у каждой команды в каждый момент времени может быть разный zero. Там определен threshold что вес не больше 50 или 100.

Если команда только начинает работать над антибагом, мы говорим нужно ежемесячно снижаться на 20%. В семестре шесть месяцев, пять месяцев на снижение по 20%, плюс еще месяц на удержание этого результата. Таким образом, можно за семестр выйти в таргетное значение и иметь маленькое количество багов.

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

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

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

Вы просто расставляете этим критериям веса, проценты и говорите, что одно влияет на 40%, второе на 20%, третье на 40%. Вот такой пример, и эта метрика позволяет более-менее унифицированно на десятки команд в Яндексе распространять работу над антибагом.



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

Первое это баланс между слишком мало целей и слишком много целей. Целей не должно быть слишком мало, потому что это будет недостаточно амбициозно для команды. Вы просто не будете утилизировать весь свой потенциал. Слишком много тоже плохо: начиная с какого-то момента накладные расходы на осознание и ведение цели станут слишком большими. Они суммарно накопятся и будут вам мешать.



У нас есть пара таких примеров. Например, была команда, которая состояла из восьми человек. У них было около шести целей. Они сказали: Мы как команда не можем уследить сразу за шестью целями. Нам нужно их трекать на гринлайтах, постоянно понимать, каждая ли из них у нас хорошо продвигается. Давайте мы разделимся на две команды по четыре человека и распределим: эти три цели в одну команду, три другие в другую. Это работающий способ, который в итоге позволяет сфокусировать людей чуть более узко на конкретной цели.

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

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

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

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

Нужен баланс между двумя формулировками: вовремя переориентироваться под изменившуюся реальность и сдаться при первых трудностях. Иногда вы можете начать что-то делать и обнаружить, что задачи оказались сложнее, чем ожидалось. Или же случились внешние факторы, например коронавирус или еще что-то. Очень велик соблазн, руководствуясь принципом Agile, гибко подстроиться под изменившуюся реальность и, например, занизить себе KPI, отказаться от каких-то целей или еще чего-то. Тут мы оказываемся в той же самой ситуации, что и при первоначальном целеполагании, только уже в динамике.

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

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

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



И еще пара таких аналогий и картинок про баланс. Он, в том виде, в котором я его для себя формулирую, бывает двух типов:

1. Бывает баланс кататься на кайте. Это когда естественная сила гравитация, ветер, что-то еще тянет вас в одну сторону, а вам нужно изо всех сил сопротивляться.
   
   Сюда входят вещи, связанные с перфекционизмом. Андрей Миронов сказал: Надо стараться делать всё хорошо, а плохо оно само получится. При прочих равных, вы скорее совершите больше ошибок, чем меньше. Поэтому нужно прикладывать специальные усилия, направленные на исправление багов: при прочих равных людям больше нравится делать обычные фичи.
2. Второй тип баланса я называю велосипедным. Это когда у вас есть две крайности, и между ними нельзя свалиться одинаково ни в одну, ни в другую сторону. Тут уже сложнее. Мне кажется, что первый вид баланса сильно проще: просто бери и с максимализмом изо всех сил делай что-то одно. Второй баланс требует тонкой настройки системы, ощущения того, в какую из сторон лучше не сваливаться. Но даже понимание того, какой вид баланса сейчас перед вами, может вам помочь в развесовке ваших сил.

Итого

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

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

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

Здесь могла бы быть реклама нашего или любого вашего инструмента, потому что плюс-минус любой инструмент ведения задач или целей может быть использован. Просто поищите в любимом поисковике [название вашего инструмента, пробел, цели]. Вы наверняка найдете статью, которая описывает, как именно это сделать. Спасибо за внимание. Желаю вам всем такого же удачного попадания в цели, как на этой гифке.

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

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

В итоге мы получили полноценную систему мониторинга, являющуюся полностью open-source self-host решением, не имеющим внешних коммуникаций, с полностью определяемыми пользователем инцидентами.

И в этом посте мы хотим познакомить Вас с получившимся продуктом.

Технические детали

Для разработки была выбрана микросервисная архитектура. Бэкэнд разрабатывался на GoLang-е, как быстром и удобном языке для разработки микросервисов. Для общения между сервисами мы использовали gRPC. Кроме того, что gRPC работает на HTTP/2 со всеми вытекающими, описание интерфейсов сервисов через proto позволит Вам, как пользователям, создавать собственные имплементации отдельных частей системы, если в этом возникнет необходимость.

В проекте используются Mongo как база быстрого доступа и Postgres для хранения собираемой статистики.

Для сборки и деплоя использовался Bazel. Bazel позволяет декларативно описывать зависимости и отношения между пакетами в Golang. Кроме этого, мы начали тестировать Bazel с remote cache, что позитивно сказывается на скорости работы системы. Также Bazel собирает все приложения в Docker и организует Unit testing. Все это интегрировано в Github actions.

Dashboard системы написан на Angular 9.

Мы стараемся держать планку в unit тестах, в данный момент покрыта каждая сущность. В ближайших планах реализация интеграционных и E2E тестов, для наиболее полного поддержания системы

Описание системы

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

Список сервисов:

• Agent Client клиент, разворачиваемый на устройстве. Собирает информацию о процессоре, загрузке памяти и сетевом взаимодействии. Отправляет информацию в Agent Server.
• Agent Server обработчик информации, поступающей от клиента. Собирает список клиентов в Mongo, а информацию от агентов передает в Storage.
• Application Monitoiring мониторинг приложений, осуществляемый путем добавления модулей/пакетов Squzy в приложения, собирающих информацию о транзакциях. На текущий момент поддерживается GoLang и NodeJS, в краткосрочной перспективе PHP & Java имплементации.
• Monitoring мониторинг external/internal сервисов.
• Storage сервис для доступа к собранной статистике. Текущая имплементация использует Postgres, но в дальнейшем планируется перейти на ClickHouse.
• Incident Manager- обработка инцидентов. Система позволяет пользователю создавать свои собственные правила обработки нештатных ситуаций (подробнее об этом расскажем чуть позже). Сами правила хранятся в Mongo, в то время как инциденты в случае возникновения передаются в Storage.
• Notification Manager сервис для уведомления пользователей в случае возникновения инцидента. На текущий момент поддерживает уведомления в Webhook & Slack.
• API является API Gateway для системы

Схема взаимодействия сервисов выглядит следующим образом:



Для демонстрации возможностей Squzy разработано демо, мониторящее свой же сервер и позволяющее следить за системой на dashboarde: https://demo.squzy.app/.

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

Эта часть системы отвечает за external/internal проверки. В данный момент она позволяет отправлять запросы и ожидать ответы на следующие типы endpoint-ов:

1. Tcp проверка открытого порта;
2. gRPC проверка по протоколу;
3. Http проверка на соответствие статус коду;
4. SiteMap проверка того, что все URL из Sitemap отвечают 200 OK;
5. JsonValue сбор определенных значений из JSON ответа.

Squzy позволяет добавлять свои заголовки ко всем видам HTTP проверок.

Интерфейс добавления проверки через Squzy dashboard выглядит следующим образом:



Здесь интервал интервал между проверками в секундах, а timeout время, после которого проверка считается неудачной.

После создания пользователю доступна конфигурация чекера:



На каждый вид проверки можно написать инцидент правило. Подробнее об инцидентах будет рассказано ниже, здесь же просто приведем пример:



В данном случае мы измеряем значение курса доллара с сайта, и если он будет больше 80 мы создадим инцидент.

Ссылка на demo.

Инциденты можно создавать на:

• Длительность проверки (время получения ответа от сервера);
• Статус (возвращаемый статус код);
• Значение (информация, передаваемая в чекере).

Squzy agent

Для мониторинга хостов в системе используется Squzy Agent, устанавливаемый на сервер. В данный момент он собирает следующую статистику:

• CPU нагрузка по процессорам;
• Memory Used/Free/Total/Shared;
• Disk Used/Free/Total по каждому из дисков;
• Net по каждому сетевому интерфейсу.

Timeline агента:

1. Агент регистрируется в Agent Server и получает ID (при регистрации есть возможность указать интервал мониторинга и имя агента);
2. Агент с определенным интервалом отправляет статистику на сервер;
3. .
4. Агент уведомляет сервер о выключении.

Если связи с сервером нет, агент продолжает собирать статистику и она будет отправлена при восстановлении соединения.

Demo версию агента можно посмотреть здесь: https://demo.squzy.app/agents/5f142b6141a1c6518723483a/live

Агент также может иметь набор правил для проверки инцидентов:

Squzy Application Monitoring

Для мониторинга приложений разработаны интеграции с популярными frameworks для Go/NodeJs (дальше больше, как говорят успешные маркетологи). Интеграции определяют тип транзакции (Http/Router/gRPC/WebSocket/etc) и анализируют ответы от движков/запросов.

Также Squzy поддерживает Tracing транзакций, что позволяет мониторить связанные между собой транзакции нескольких серверов/сервисов. Пример мониторинга таких транзакций на Dashboard: https://demo.squzy.app/transactions/om8l8LP96PRsvx67UxkES.

Библиотеки для интеграции в Go и Node Js.

• Go https://github.com/squzy/squzy_go (GIN/gRPC/Http);
• NodeJs https://github.com/squzy/squzy_node (Express) + FE (Angular + vanilla).

По своей сути библиотеки представляют собой Middleware, засекающий время до отправки транзакции и время после ее обработки и анализирующий ответ. Также мы написали пример GO приложения для мониторинга: https://github.com/squzy/test_tracing.

Вы можете создавать свои транзакции и измерять время их выполнения, статусы и ошибки. Для это используйте пакет Core. Для удобства поддержки продукта во всех языках будут использоваться одинаковые названия для пакетов, определяющих поведение.

Можно создавать инциденты на транзакции, основываясь на следующих данных:

• Длительность транзакции;
• Статус транзакции;
• Полученные ошибки;
• Тип транзакции.

Squzy Incident Manager + Notification Manager

Инциденты в Squzy основаны на правилах. При добавлении новой сущности в Storage происходит проверка выполнения описанного правила, и в случае, если оно выполняется, создается инцидент (если он уже не был создан).

Правила представляют собой расширенную версию expr, к которой добавлены специфические правила, учитывающие спецификацию системы, такие как Last (берет n последних записей из Storage), Use (использовать при этом конкретный фильтр) и так далее. Подробное описание всех правил Вы можете найти на https://squzy.app/usage/squzy-incident/incident-rules, здесь же мы остановимся на показательном примере.

Представим, что у Вас есть сервер с 1792 процессорами, 256 Гб ОЗУ и 16 Тб места на жестком диске. И Вы очень хотите проверить, что ваш девопс не запускает Doom на мониторе отображения загрузки ЦП. Вы знаете, что поддержка одностраничного сайта, который обслуживает Ваш сервер, никогда не загружает на 100 процентов больше 8 процессоров дольше, чем на минуту. Кроме того, оперативка свободна более чем наполовину. В то время как жесткий диск имеет целый Тб свободного места в запасе (не хранить же известные архивы дома жена увидит). В таком случае, зная, что метрики собираются раз в 10 секунд, вы можете определить следующее правило для проверки корректности работы Вашего сервера:

Last(7, UseType(All),     all(.CpuInfo.Cpus, {.Load > 80}) &    all(.MemoryInfo.Mem, {.UsedPercent < 50}) &    all(.DiskInfo.Disks[System], {.Free > 1000000000000}))

Аналогично Squzy позволяет описывать различные паттерны нежелательного поведения системы.

После того, как проверка правила прошла успешно (или, скорее, неуспешно), создается инцидент и происходит нотификация пользователя, в случае, если она настроена.

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

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

Заключение

Сейчас мы находимся в стадии сбора фидбеков и комментариев от IT- сообщества.

Уже сейчас у нас есть ряд планов по развитию продукта:

1. добавление Java/PHP интеграций;
2. чекеры баз данных;
3. переход с Postgres на ClickHouse;
4. больше методов нотификаций;
5. интеграция с kubernetes;
6. улучшение документации;
7. GQL API;
8. Интеграционные и E2E тесты ;
9. мониторинг мобильных приложений.
10. Автодополнения для правилов инцидентов на UI

Мы будем рады любым фидбекам и предложениям.

Ссылки

• Backend системы: https://github.com/squzy/squzy
• Frontend системы: https://github.com/squzy/squzy-dashboard
• Demo dashboard: https://demo.squzy.app/
• Документация: https://squzy.app/
• Авторы: PxyUp DreamAndDrum

P.S.:
Спасибо за статью Vonotirax

Попробовать в 1 клик: https://github.com/squzy/starter

Это первая (1) статья цикла, посвященного разработке и использованию системы сбалансированных показателей (ССП/BSC) для мониторинга состояния проекта и оптимизации управления проектом с целью получения запланированных результатов.

Различные моменты оценки проекта

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

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

В ходе жизненного цикла проекта и его используются следующие оценки:

1. Оценка ожиданий от проекта до старта проекта;
2. Оценка исполнения процессов в ходе проекта;
3. Оценка исполнения планов в ходе проекта;
4. Оценка исполнения планов в момент закрытия проекта;
5. Оценка исполнения ожиданий от проекта после завершения проекта;

Далее, подробно, рассмотрим, что и по каким показателям оценивается в каждый из перечисленных моментов, кто производит оценку и какая при этом может быть получена польза для управления проектом.

Оценка ожиданий от проекта до старта проекта

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

Оцениваются и планируются показатели, которые позволяют объединить стратегические цели компании и бизнеса с результатами проекта такие как чистый дисконтированный доход (NPV), внутренняя норма рентабельности (IRR), период окупаемости (PP). Кроме количественных показателей, могут применяться качественные, например, повышение безопасности производства.

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

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

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

Оценка исполнения процессов в ходе проекта

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

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

Оценка может производится в рамках следующих доменов:

• Исполнение стандартов (например, PMI, ГОСТ);
• Используемые процессы управления (например, управление рисками и управление знаниями);
• Используемые проектные документы (например, журнал открытых вопросов и реестр рисков);
• Наличие и частота ключевых событий (например, встречи по переоценке рисков);
• Другие домены, зависящие от специфики и сложности проекта (например, количество требований и доля заинтересованных сторон, выставивших требования).

Показатели исполнения процессов в ходе реализации проекта позволяют:

1. Определить на сколько корректно осуществляется управление проектом;
2. Определить на сколько результативно выполняются работы по проекту;
3. Заранее выявить и устранить источники рисков;
4. Помочь правильно организовать работу и расставить акценты;

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

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

Оценка исполнения планов в ходе проекта

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

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

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

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

Оценка исполнения планов в момент закрытия проекта

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

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

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

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

Оценка исполнения ожиданий от проекта после завершения проекта

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

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

Основными заинтересованными сторонами оценки проекта после завершения являются спонсор проекта и Заказчики. Руководитель проекта, как правило, уже не привлекается.

Выводы

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

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

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

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

Для ответа на подобные вопросы кажется логичным прибегнуть к метрикам. В конце концов, мы уже давно и успешно используем их для самих программных продуктов. Есть метрики быстродействия, нагрузки на продакшен-сервера, аптайма. Есть также продуктовые метрики, основанные на поведении пользователей вроде конверсии и удержания. Польза метрик заключается не только в более ясном понимании текущего состояния, но и, что важнее, в предоставлении обратной связи. Вы делаете изменение, призванное что-то улучшить, и по метрикам видите, насколько значительное улучшение (или ухудшение) получилось. Народная программистская мудрость гласит: каждая оптимизация производительности программы должна начинаться с измерения, и в этом есть большой смысл.

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

У нас нет хороших метрик для этого

Скорость разработки это выполненный объем работы в единицу времени. Время мы можем измерить, тут все просто. А вот как измерить выполненный объем работы? Попытки сделать это начались много десятилетий назад, вместе с зарождением самой индустрии программирования. Однако каждый раз, когда показатель начинали использовать как цель для улучшения, обязательно что-то шло не так. Например:

• Количество строк кода. Это, наверное, старейшая метрика, которую уже окончательно никто не воспринимает всерьез. Если так оценивается объем работы, это приводит к замусориванию избыточным кодом, а разработчики начинают предпочитать самые простые задачи, избегая сложных проблем;
• Количество коммитов. Разработчики будут стараться дробить свои коммиты на более мелкие и, опять же, избегать сложных проблем;
• Количество выполненных задач. Стимулирует дробить задачи на более мелкие. Каждая проблема, даже незначительная, будет оформлена в виде задачи. Помимо этого, создает стимул срезать углы, если это приводит к скорейшему закрытию задач;
• Количество багов или процент багов. Метрика не объема, но качества работы. Если поставить ее как цель, разработчики будут бояться вносить изменения, а также будут неохотно рапортовать об ошибках, которые они нашли сами;
• Оценка задач в часах или сторипойнтах. Если продуктивность команды измеряется в единицах, которые она сама же и оценивает, нетрудно догадаться, к чему это приведет со временем, оценки начнут завышаться;
• и так далее.

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

Но почему?

Почему для улучшения свойств программных продуктов метрики прекрасно работают, но для измерения выполненной программистами работы нет? Может, это какой-то заговор программистов? На самом деле, если мы посмотрим за пределы разработки ПО, то увидим и другие примеры, в одних из которых метрики работают хорошо, а в других нет.

Примеры, когда метрики хорошо работают массовое промышленное производство или продажи. Пусть будет производство и продажа кружек. Вы можете измерять объем производимой продукции количество кружек в единицу времени, ее качество (процент брака), себестоимость одной кружки. В продажах объем продаж, наценку. Эти метрики вполне успешно используются в управлении. Например, начальнику производства можно поставить задачу снижения процента брака при сохранении себестоимости, а начальнику отдела продаж увеличения объема продаж при сохранении цены. Улучшения этих показателей принесут пользу бизнесу, так что их можно считать и показателями эффективности труда людей, которые за это отвечают.

Пример когда метрики не работают оценка научной деятельности. Ученые производят исследования, которые потом публикуются в виде научных работ. В этой области тоже есть свои численные метрики количество работ, количество цитирований, статистическая значимость результатов и др. Можно ли сказать, что ученый, выпустивший 10 научных работ, принес миру в два раза больше пользы, чем ученый, выпустивший 5 работ? Вряд ли, потому что ценность их трудов может сильно отличаться, и при этом даже на субъективном уровне бывает сложно понять, какой труд был более ценным. Проблема накрутки цитирований и публикаций широко известна в научной среде, так что, к сожалению, они не считаются надежными показателями ценности. Есть также и проблема манипуляций со статистической значимостью.

Два главных критерия

Вне зависимости от контекста у хорошо работающих метрик есть две общие черты:

1. Прямая (а не косвенная) связь с ценностью;
2. Точность, то есть метрика основана на измерении количества каких-то единиц ценности и эти единицы равны между собой;

Давайте посмотрим еще раз на примеры, которые мы рассматривали выше:

Метрики для массового производства и продаж удовлетворяют обоим критериям. В производстве кружек ценностью выступает продукция сами кружки. Связь прямая, предприятию как раз и нужно производить кружки. А раз производство массовое, то единицы ценности (кружки) равны между собой. Если же мы говорим о продажах, то единицами ценности становятся деньги. Целью деятельности предприятия является получение прибыли, поэтому связь с ценностью, опять же, прямая. А поскольку каждый вырученный доллар равен другому, мы можем строить точные метрики.

В оценке научных трудов эти критерии соблюсти не удается. Мы не можем найти единицу измерения, которая бы напрямую определяла ценность научного труда, потому что все научные труды уникальны. По-другому быть и не может, просто исходя из самой сути науки открывать новые знания. Ученому нет никакого смысла писать еще один научный труд, который бы в точности повторял другой. Каждая научная работа должна нести что-то новое.

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

Вернемся к измерению производительности программистов

Что у нас там было? Строчки кода, количество коммитов, задач, оценка задач в часах или сторипойнтах Если вы попробуете проверить эти метрики на соответствие двум главным критериям, вы увидите, что ни одна из них им не соответствует:

1. Нет прямой связи с ценностью. Мы не поставляем нашим клиентам строчки кода, человеко-часы или сторипойнты. Пользователям нет никакого дела, сколько коммитов мы сделали или сколько задач закрыли;
2. Они не являются точными. Коммит коммиту рознь, одна строчка кода не равноценна другой, задачи тоже разные, а человеко-часы и сторипойнты оценены субъективно, поэтому также будут отличаться.

Так что нет ничего удивительного, что ни одна из этих метрик не работает они же все косвенные и неточные.

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

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

А нет ли чего-то более современного, основанного на исследованиях?

Конечно, сегодня уже никто всерьез не говорит об измерении труда программиста строчками кода. Должны же быть какие-то более современные метрики, основанные на исследованиях, верно?

Есть и такие. В книге 2018-го года Accelerate авторы приводят результаты исследования 2000 организаций из разных отраслей. Авторы пытались выяснить, какими метриками можно было бы оценивать эффективность:


Источник: Nicole Forsgren, Jez Humble, and Gene Kim, Measuring Performance, in Accelerate: The Science behind DevOps: Building and Scaling High Performing Technology Organizations

Здесь приведены четыре метрики. Давайте посмотрим, какие из них связаны с ценностью и могут быть точно измерены:

• Частота поставок в продакшен. Я понимаю, почему эту метрику привели здесь. Чем чаще вы поставляете код в продакшен, тем лучше отлажен процесс поставки. Более продуктивные команды обычно поставляют код чаще. Однако корреляция не означает причинности. Вряд ли это напрямую связано с ценностью для клиента. Людям нужно, чтобы продукт решал их задачи, а не чтобы он как можно чаще менялся. Метрика также не является точной, потому что поставка поставке рознь. В одной поставке могли быть сделаны серьезные изменения, в другой тривиальные;
• Lead time время, в течение которого удовлетворяется запрос клиента. Эта метрика лучше связана с ценностью для клиента, поскольку мы говорим об изменениях в продукте, о которых он сам просил. Она не является при этом точной, потому что, опять же, изменения изменениям рознь сложность их реализации может отличаться на порядки;
• Время восстановления после сбоя (MTTR) если ваша программа не работает, клиенты грустят, так что связь с ценностью присутствует, и это хорошо. Но есть и недостатки. Во-первых, метрика не учитывает частоту сбоев. Частые сбои с быстрыми восстановлениями тоже будут расстраивать ваших клиентов, но MTTR этого не покажет. Во-вторых, она является неточной, ибо сбои бывают разные. Некоторые очень серьезные, другие нет;
• Процент изменений, в процессе внесения которых возникали сбои. Связь с ценностью имеется в основном в ситуациях, когда пользователи устанавливают обновления самостоятельно. Если, согласно прошлому опыту, обновления несут существенный риск, люди будут бояться их устанавливать. Как говорят пользователи некоторых дистрибутивов Linux, не было печали апдейтов накачали. В случае SaaS-продуктов связь с ценностью более слабая. Пользователям неважно, по какой причине у вас возник сбой из-за изменений, сбоя у вашего провайдера, высокой нагрузки или чего-то еще. Им важно, чтобы ваш сервис всегда работал. Как и другие метрики выше, эта тоже не является точной по той же самой причине изменения изменениям рознь. Одни серьезные, другие нет.

Итого: ни одна из этих четырех метрик не является точной, и не всегда у них прослеживается четкая связь с ценностью для клиента. Есть ли в этом случае возможность для читерства? Конечно. Поставляйте тривиальные малорисковые изменения как можно чаще, и все метрики, кроме Lead time, будут выглядеть прекрасно.

Что касается Lead time даже если опустить тот (немаловажный) факт, что она неточная, упор на нее приведет к приоритезации самых простых хотелок клиента и задвиганию в дальний угол всего, о чем клиент явно не просил обычно это рефакторинги, тесты, да и просто любые улучшения, о которых он сам не подумал.

Поэтому я бы не рекомендовал использовать эти метрики в качестве целей.

Но может, мы найдем новые метрики?

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

1. Прямая (а не косвенная) связь с ценностью;
2. Точность, то есть метрика основана на измерении количества каких-то единиц ценности, и эти единицы равны между собой.

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

Можно ли улучшить области, для которых нет хороших метрик?

Метрики очень удобны, потому что предоставляют обратную связь. Вы делаете какие-то изменения в процессе и можете наглядно видеть, привели они к улучшениям или нет. Если же метрик нет, то обратная связь становится не такой явной и может даже создаваться ощущение, что вы двигаетесь вслепую. Есть известное высказывание, приписываемое Питеру Друкеру:

Вы не можете управлять тем, что не можете измерить.

Только это неправда. Согласно Институту Друкера, Питер Друкер на самом деле не питал иллюзий, что для любой деятельности можно найти метрику, и никогда не говорил таких слов. Не все, что ценно, можно измерить, и не все, что можно измерить, представляет ценность.

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

Резюме

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

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

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

На этом все, пишите в комментариях, что вы думаете. Удачных вам деплоев, даже по пятницам.

Сегодня мне хотелось бы с помощью моих коллег Agile-коучей Ани Родионовой, Макса Зотова и владельца продукта в Трайбе Розничное взыскание и урегулирование Свята Божухина рассказать о практике применения интересного инструмента. Итак, речь пойдёт о Program Increment Planning Meeting aka PI Planning.

Это метод планирования из SAFe (Scaled Agile Framework) гибкого фреймворка для крупных компаний. Ну, знаете, это когда люди стоят у стены, оклеенной стикерами, лепят всякие ниточки от одного стикера к другому, но при этом в городе не орудует маньяк.

Ниже пример места встречи одной из команд для PI в Сбере (обратите внимание на ту самую стену на заднем плане):



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

С чего началось

В марте 2020 года бОльшая часть команд перешла на дистанционный формат работы. Со встречами по планированию нужно было что-то делать. С технической точки зрения у нас были Zoom и Confluence, но организационно нужно было немного докрутить.

Вот так выглядит SAFe, и скромную часть в нём занимает PI:



Вот что должны сделать разные участники, чтобы планирование прошло успешно:



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

Scrum-мастерам поручили подготовить все шаблоны флипов (флипчартов). В онлайне они трансформировались в таблички на Confluence в специальном пространстве для совместной работы.

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

Группа фасилитаторов следила за тем, чтобы все шаблоны в Confluence были подготовлены и всё логистически готово.

Мы фокусировались на основных задачах и по возможности распределяли их. Must have-задачи это задачи, например, по изменению законодательства, которое в пандемию достаточно часто менялось, и к этому никак нельзя быть готовыми, но их точно надо сделать. У нас как у банка нет ни малейшей возможности не сделать этого в принципе.

Второй тип необычных задач сиротки. Представьте, что вы владелец продукта, у вас есть команда, вы понимаете, как развиваете свой продукт, но видите что-то со стороны, что тоже нужно сделать. И это важно. А вы уже не можете, ваш бэклог переполнен, и ваши задачи важнее. Тогда вы берёте эту задачу и помещаете её в специальное пространство, где живут все задачи, которые нужно сделать. Ну и, конечно, прояснить и посмотреть по эффектам, зачем они в принципе нам нужны.

Сама история почти не поменялась: если раньше были физические флипчарты, то теперь они стали виртуальными.

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

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



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

Потом риски. Если команда видит, что у неё, возможно, будут проблемы при реализации какой-то задачи, то она его обозначает, и потом уже мы решали, кто с этим работает и как.



И дальше распределение по спринтам. Мы смотрели на оптимистичность, пессимистичность и реалистичность команд и приводили их к чему-то единому, равному. Кто был не нагружен нагружали, а кто был перегружен чуть помогали освободить их бэклог.

И ещё один флип, на котором участники указывали контакты, по которым всегда можно было выйти на команду и обсудить бэклог на квартал.

Процесс

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

Дальше идёт работа команд:

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

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

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

В среднем из запланированного делается по факту 7080 %. Это очень качественный показатель.

Инвестиция в будущее

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

Вот так, если вкратце про PI Planning. Если хотите больше подробностей, то можно посмотреть выступление коллег тут.

Перевод статьи подготовлен в преддверии старта курса Product Manager IT-проектов

---

Важность Product-менеджеров, которые руководствуются данными

Если у вас нет опыта в Data Science, управление данными в качестве Product-менеджера может показаться непростой задачей. Однако это то, на что необходимо обратить внимание. И вот почему:

• Данные позволяют получить важный фидбэк от пользователей о вашем продукте;
• Данные помогают вам разрабатывать правильные продукты и быстрее решать задачи;
• Данные это мощный инструмент коммуникации между командами и стейкхолдерами.

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

Метрики, которые важны для Product-менеджера

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

Здесь представлены основные метрики, которые будут иметь большое значение почти для всех Product-менеджеров:

1. MAU/DAU

Monthly Active Users (MAU, количество уникальных пользователей в месяц) и Daily Active Users (DAU, количество уникальных пользователей в день) это отличные индикаторы здоровья вашего цифрового продукта в целом. Если вы заинтересованы в долгосрочном росте, то это те показатели, про которые нельзя забывать! Они помогают отслеживать, растет база пользователей или нет, и то, насколько залипательным оказывается ваш продукт для конечных пользователей.

Понимание того, как высчитывать DAU, определяется спецификой вашего продукта. Частенько это просто показатель, который считает людей, которые открыли приложение и закрыли его. Большинство менеджеров еще пытаются определить минимальное предпринятое действие для получения ценности от продукта. Для сервиса стриминга музыки, например, это может быть воспроизведение песни. Для приложения-мессенджера это может быть отправка одного сообщения.

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

Установка слишком высокой планки может оказаться такой же катастрофической, как и установка слишком низкой. Вопрос, который вы должны себе задавать: Каким образом я обеспечиваю ценность продукта для пользователя?. Свои метрики вы должны основывать на нем.



2. Коэффициент конверсии

Сколько людей, приходящих на ваш сайт, делают то, что вы от них хотите? Будь то подписка на freemium-версию вашего нового инструмента, загрузка фотографий или стриминг вашего контента. Низкая конверсия показывает, что люди заходят в ваше приложение/на ваш сайт и не находят того, зачем пришли, или разочаровываются в вашем продукте.

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

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



3. Churn и Customer Retention Rate

Вы уже знаете, что такое дрель То, как нужно считать отток (churn) клиентов, будет зависеть от вашего продукта!

Клиенты это здорово, а ежедневно приходящие новые клиенты отлично смотрятся на диаграммах роста. Но если эти же клиенты уходят через несколько дней (или через несколько секунд в этом непостоянном мире приложений!), то у вас, по сути, дырявая корзинка, а не продукт. Нет смысла заполнять корзинку новыми пользователями, пока вы не научитесь удерживать их. Вам нужен высокий Customer Retention Rate или коэффициент удержания клиентов это когда к вашему продукту возвращаются больше людей, чем уходят.

Как говорил Growth Product Manager из Airbnb, компании, которые не поняли концепцию удержания и слишком резко увеличили стоимость привлечения клиента, затем очень быстро растеряли всех своих пользователей. Без пользователей ваш продукт ничто.

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

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



4. Индексы NPS и CSAT

Net Promoter Score (NPS) и Customer Satisfaction Score (CSAT) отличный способ измерить настроение ваших пользователей.
Вкратце, ваш показатель NPS скажет вам, насколько ваш продукт нравится пользователям. Он поможет вам разделить пользователей на 3 категории в зависимости о того, на сколько баллов из 10 они оценят ваш продукт.



1-6 = Критики
Такие люди используют ваш продукт, но только по необходимости/из-за отсутствия альтернатив, и не порекомендовали бы его другу.

7-8 = Пассивные клиенты
Этим людям нравится ваш продукт, но он их не впечатлил.

9-10 = Промоутеры
Такие люди золотая жила. Они ваши первые поклонники и будут активно продвигать ваш продукт в своих кругах.

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

CSAT это более простая оценка, ее можно использовать для понимания того, насколько пользователи довольны отдельными процессами или функциями. NPS чаще используется для измерения того, насколько пользователи довольны своим User Journey, тогда как CSAT даст вам больше конкретики. Например, вы можете попросить пользователей оценить опыт от онбоардинга по шкале от 1 до 10, как только они закончат его проходить. Этот вопрос решается одним касанием, и является распространенным методом сбора обратной связи в рамках обслуживания клиентов.

Управления данными вашего продукта

Управление данными вашего продукта может показаться непростой задачей, если вы не специалист в Data Science. Есть несколько ключевых мыслей, которые помогут вам в этом преуспеть:

• Централизуйте свои данные. Отслеживать метрики становится сложнее, если у вас несколько источников данных. Когда разные команды/члены команд руководствуются данными из различных источников, вы рискуете получить недопонимание в коллективе.
• Делитесь данными. Общие данные очень мощная вещь. Предоставьте всем членам команды возможность принимать правильные, основанные на данных, решения, дав им доступ к необходимым метрикам.
• Визуализируйте свои данные. Использование инструментов визуализации данных превращает сложные числа в простые визуальные элементы. Это делает их понятными для всех членов команды, а не только для тех, кто хорошо знаком с этими данными.

Выбор правильных метрик и понимание того, как подровнять команду по одинаковым метрикам это непросто! К счастью, этот навык можно получить на тренинге по Product-менеджменту. Какие еще показатели вы бы включили в этот список? Расскажите нам об этом в твиттере!

---

Узнать подробнее о курсе

---

Перевод статьи подготовлен в преддверии старта курса Team Lead 2.0.

---

Как я отмечал в статье Why metrics dont matter in software development unless you pair them with business goals", выбор метрик нужно продумывать очень тщательно, чтобы дать ответы на вопросы, которые ставит перед собой бизнес. Вот эта критическая точка: измерения должны быть спроектированы так, чтобы отвечать на вопросы бизнеса. И эти вопросы никогда не будут звучать как Сколько у нас сейчас тысяч строк кода в проекте?

В этой статье продолжается тема, начатая в предыдущей. Сначала мы поговорим о конкретных метриках, которые должна использовать каждая команда, или по крайней мере планирует использовать для того, чтобы заметно улучшить производительность. Обратите внимание, что название этой статьи начинается как 9 метрик, которые МОГУТ иметь значение, потому что важно именно то, как эти метрики повышают ценность бизнеса. Как вы их будете использовать зависит только от вас. Завершим мы статью рассказом о том, как осмысленно сочетать эти метрики между собой, а также сформулируем и проверим гипотезу о ценности бизнеса.

Начните с измерения правильных вещей

Здесь представлены 9 объективных показателей (или метрик), которые необходимо постоянно отслеживать, чтобы инкрементально улучшать процессы и производственную среду. Улучшение этих показателей не гарантирует, что уровень удовлетворенности ваших клиентов будет расти не по дням, а по часам. Однако, это те показатели, которые действительно нужно мониторить. В одном из последующих разделов Собираем все вместе, вы узнаете почему.

Метрики Agile-процесса

Для agile и lean-процессов основными метриками будут leadtime, cycle time, velocity команды, и open/close коэффициент. Эти показатели помогают в планировании и принятии решений по улучшению процессов. Несмотря на то, что они не измеряют успешность или добавочную ценность, не имеют ничего общего с объективным качеством программного обеспечения, вам все равно нужно их отслеживать. Ниже я объясню почему.

• Leadtime время, которое проходит от появления идеи до поставки программного обеспечения. Если вы хотите быстрее реагировать на нужды своих клиентов, работайте над уменьшением leadtime, зачастую посредством упрощения процесса принятия решений и сокращения времени ожидания. Leadtime включает в себя cycle time.
• Сycle time количество времени, которое требуется на внесение изменений в систему ПО и доставку этих изменений на продакшн. Команды, использующие continuous delivery, могут измерять cycle time в минутах или даже секундах вместо месяцев.
• Velocity команды количество единиц программного обеспечения, которое команда обычно выполняет в одну итерацию (спринт). Это число следует использовать только для планирования итераций. Сравнивать команды по показателю velocity идея бессмысленная, поскольку метрика основана на необъективных оценках. Рассматривать velocity как показатель успешности тоже бесполезно, да и постановка цели вроде придерживаться определенной velocity искажает ценность этой метрики для мероприятий по оценке и планированию.
• open/close коэффициент количество появившихся и закрытых issue в единицу времени. Общая тенденция будет иметь большее значение, чем конкретные цифры.

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

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

Аналитика продакшена

• Средняя наработка на отказ (Mean time between failures, MTBF)
• Среднее время восстановления (Mean time to recover/repair, MTTR)

Оба этих показателя являются общими показателями производительности вашей системы ПО в текущей производственной среде.

Частота сбоев приложения количество раз, которое приложение падает, деленное на количество использований. Этот показатель напрямую связан с MTBF и MTTR.

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

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

Помимо MTBF и MTTR, более точные метрики основаны на отдельных транзакциях, приложениях и т.д., и они отражают доставленную бизнес-ценность, а также стоимость устранения сбоев. Если ваше приложение для обработки транзакций падает один раз из ста, но при этом поднимается через 1-2 секунды без критических потерь информации, то и с частотой сбоев в 1% можно жить. Но если с такой частотой падает приложение, которое обрабатывает 100 000 транзакций в день, теряет по 100$ за сбой и восстановление стоит 50$, то исправление этого 1% будет в приоритете. И такое исправление в итоге сильно повлияет на итоговую ситуацию.

Метрики безопасности

Безопасность важный аспект качества программного обеспечения, который на поздних этапах разработки (или последующих этапах жизненного цикла) часто упускается. Инструменты анализа безопасности могут использоваться в процессе сборки вместе с более специализированными методами оценки и стресс-тестами. Требования к безопасности согласуются со здравым смыслом, но команда разработчиков должна всегда о них помнить, ровно как и о метриках от них происходящих.

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

• Инциденты на конечных точках количество конечных точек (мобильных устройств, рабочих станций и т.д.), на которых был обнаружен вирус в течение определенного времени.
• MTTR (среднее время наработки на отказ) в терминах безопасности это время между обнаружением нарушения безопасности системы и развертыванием и работой средства защиты. Как и в случае с MTTR, о котором мы говорили в метриках продакшена, вопрос безопасности должен отслеживаться в течение определенных временных интервалов. Если значение MTTR со временем уменьшается, то разработчики работают эффективнее и лучше понимают проблемы безопасности, находят ошибки и устраняют их.

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

Вы найдете больше способов применения метрик безопасности в разработке программного обеспечения в статьях Application Security for Agile Projects и Security Threat Models: An Agile Introduction.

Заметка о метриках исходного кода

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

Не стоит зацикливаться на цифрах. Приведу пример, чтобы вы поняли, к чему я клоню.

Допустим, вы обнаружили в классе метод с нелепым значением показателя сложности NPATH в 52 миллиона. То есть потребуется 52 миллиона тест-кейсов, чтобы протестировать каждый вариант выполнения метода. Вы можете отрефакторить код и получить более простую структуру, но прежде, чем это сделать, подумайте о том, как это отразится на бизнес-логике. Скорее всего этот старый страшный код работает достаточно хорошо (несмотря на то, что он может быть не полностью покрыт тестами). Ценным будет показать этот антипаттерн своей команде, чтобы они так больше не делали, поскольку фикс этого метода в целом не изменит ни одну стоящую бизнес-метрику.

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

Соберем все вместе: Успех универсальная метрика

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

Как использовать метрики для достижения успеха

У бизнеса есть цели. В целях кроются вопросы, например: Как выглядит успех? или Как продукт повлияет на поведение клиентов?. Правильно сформулированные вопросы таят в себе метрики.

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

Разве не все у всех проектов есть некоторый набор инвариантных целей, вопросов и гипотез, а следовательно, и метрик?

Да, но только с точки зрения бизнеса. Метрики уровня бизнеса, такие как вовлеченность пользователей, коэффициент закрытия сделок, генерирование доходов и т.д., дают фидбэк о том, как влияет бизнес на реальный мир. Изменения в ПО, которые повлияют на бизнес, также повлияют и на эти метрики.

На более тонком уровне разрешения каждая функция и User Story могут иметь свой собственный показатель успеха предпочтительнее, чтобы он был единственным и был связан непосредственно с ценностью, которая доставляется клиенту. Закрытие 9 из 10 историй за спринт для функций, которые остаются недоставленными это не успех, а поражение. Доставка историй, которые клиентам не нужны, и они их не используют не успех, а пустая трата времени и сил. Создание историй, которые делают пользователя немного счастливее вот это успех. Создание истории, которая не улучшила взаимодействие с пользователями, тоже своего рода успех, поскольку теперь вы знаете, что эта бизнес-гипотеза не работает, и можете освободить ресурсы для поиска других идей.

Как сформулировать ценностную гипотезу

Ценностная гипотеза это утверждение о том, что, по вашему мнению, произойдет в результате добавления определенной функции. Взаимосвязь между программным обеспечением, желаемым результатом и метриками формирует ценностную гипотезу для функции (или системы, истории, обновления и т.д.). Гипотеза должна выражать ожидаемое изменение целевой метрики в течение определённого промежутка времени, а также понятие о ее эффективности. Вам нужно будет поговорить с командой и с Product Owner-ом, чтобы как минимум выяснить, что именно это функция или история может создать или улучшить применительно к бизнесу, чтобы сформулировать относительно нее ценностную гипотезу. Возможно, задать вопрос почему вам придется несколько раз (как ребенку), чтобы избавиться от невысказанных предположений, поэтому будьте терпеливы. Когда вы поймете, какой должна быть ценность для бизнеса, вы можете начать задавать вопросы, которые приведут вас к метрикам, дающим на них ответы.

Например, техническая история о повышении скорости оформления заказа в интернет-магазине может иметь под собой идею о том, что ускорение продаж приведет к росту их количества. Но почему мы так думаем? Много ли людей оставляют корзины с товарами во время процесса оформления заказа? Если вы пришли к консенсусу (подкрепили свои предположения данными), то ценностная гипотеза может быть звучать так: Мы считаем, что ускорение процесса оформления заказа приведет к снижению коэффициента отказа от корзины. В свою очередь это приведет к увеличению продаж и улучшению пользовательского опыта.

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

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

Шесть эвристик для эффективного использования метрик

Мы увидели, как субъективные метрики делали больший вклад в успех бизнеса, чем старые добрые объективные показатели качества. Полученные знания и возможности для обучения преобладают над усилиями, необходимыми для поиска и измерения соответствующих бизнес-показателей функций. Условия бизнеса и возможности меняются постоянно, поэтому вместо того, чтобы выводить хрупкую формулу, которой можно было бы следовать, я дам шесть эмпирических правил, или эвристик, которые помогут сохранить сосредоточенность и гибкость. Пусть они помогут вам на вашем пути к качественному программному обеспечению и успеху!

1. Метрики не расскажут вам всю историю, а вот команда расскажет (снимаю шляпу перед Тоддом Декапула);
2. Сравнивать снежинки это бесполезная трата времени.
3. Вы можете измерить практически все, но не всему можете уделить внимание.
4. Метрики успеха бизнеса способствуют улучшению программного обеспечения, а не наоборот.
5. Каждая функция добавляет ценность, измеряете вы ее или нет.
6. Измеряйте только те показатели, которые имеют значение в данный конкретный момент.

Еще

• Выстраиваем рабочие процессы на удаленке: практические рекомендации
• Почему вам не надо становиться тимлидом?
• Почему мои коллеги/сотрудники ведут себя как @%?
• Гореть, но не сгорать гореть, чтобы светить

---

Узнать подробнее о курсе

Вы читаете вторую статью из серии Дизайнер и метрики. В первой статье я пытался ответить на вопрос, нужны ли дизайнеру метрики. Ее можно найти тут.

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

Retention метрика, на которую я смотрю чаще всего

Предлагаю не вдаваться в теорию, а сразу взять конкретную метрику и посмотреть, что это такое и как она работает.

Начнем с retention метрика, которая показывает возвращаемость пользователей. То есть, если сегодня наше приложение скачало 100 новых пользователей, то retention ответит на вопрос, сколько из них к нам вернется завтра, через месяц и так далее.

Допустим, что retention второго дня равен 60% это значит, что на второй день приложение запустят 60 пользователей из 100 скачавших.

Эту метрику можно посчитать на любой день жизни пользователя. Допустим, retention 7 дня равен 30% это означает, что на 7 день с момента скачивания в нашем приложении останется 30 человек из 100 скачавших.

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

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

Допустим, наше приложение скачали 1000 раз за неделю. Во второй день из этой тысячи зашли 600 пользователей, а в седьмой 300. Используя эти данные, мы можем посчитать retention второго дня 600/1000 = 60%, и retention седьмого дня 300/1000 = 30%

Чем полезна эта метрика?

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

Если retention какого-то дня составляет 0%, значит, из всех, кто когда-то скачивал приложение, никто в нем не остался, и приложение никому не нужно. Может, стоит его закрыть?

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

Но чаще всего цель разработки приложения найти пользователей, которые будут пользоваться им в течение длительного времени. То есть, с какого-то дня retention должен перестать убывать retention 90 дня должен быть равен retention 180 дня и так далее. В таком случае аналитики говорят, что retention вышел на плато.

Если у продукта большая и постоянно растущая аудитория, это свидетель того, что продукт вышел на плато retention как Facebook, Telegram, Google Maps и так далее.

Метрики роста и метрики продукта

Отойдем на шаг назад и посмотрим, какие вообще бывают метрики. Выделяют 2 типа: метрики роста и метрики продукта

Допустим, у нас есть некое мобильное приложение. В него попадают пользователи, как-то с ним взаимодействуют, и по итогам этого взаимодействия приложение зарабатывает деньги.

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

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

Как думаете, retention это метрика роста или метрика продукта?

Определить это поможет очень простое правило: увеличьте в разы количество пользователей, скачавших приложение. Если показатели метрики при этом не изменятся, значит, это метрика продукта.

Допустим, мысленно сравняйте количество пользователей своего приложения с количеством пользователей Facebook. Retention приложения при этом останется неизменным. Как был 30% на седьмой день, так и останется. А значит, Retention это метрика продукта.

А что произойдет с выручкой? Выручка при увеличении аудитории заметно взлетит. Если один пользователь приносил нам 10, то 100 пользователей принесут нам 1 000 , а 1 000 000 пользователей 10 000 000 . Получается, что выручка (или revenue) это метрика роста.

Итак, метрики роста отвечают на вопросы:

Растет или падает дневная аудитория нашего приложения?

Сколько зарабатывает наш продукт?

А метрика продукта:

Сколько денег нам приносит один средний пользователь?

Какая часть пользователей остается с нами спустя месяц после установки приложения?

Зачем разбираться в метриках роста и продукта

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

Конечно, проще всего было бы ответить на эти вопросы, посмотрев на метрики роста. Мол, если мы стали больше зарабатывать значит, все не зря, а если начали зарабатывать меньше, то что-то идет не так.

Но в этом подходе кроется ошибка, которая может стоить продукта.

Чтобы лучше разобраться, почему при оценке дизайна или редизайна не стоит опираться на метрики роста, давайте разберем следующий кейс:

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

Команда выкатывает эту фичу и она оказывается неудачной. Метрики продукта то есть, retention, возвращаемость пользователей летят вниз. Продукт начинает хуже удерживать пользователей, доход на нового пользователя уменьшается.

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

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

Такой случай не редкость в компаниях.

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

Подытожим

1. Одна из главных метрик продукта это retention, то есть, возвращаемость пользователей. Найти его можно, разделив количество дневных пользователей на N-ный день на количество скачавших приложение.
2. Мы научились отличать метрики роста от метрик продукта. Достаточно мысленно увеличить количество пользователей приложения и посмотреть, увеличился вслед за этим показатель метрики или нет. Например, выручка revenue увеличится; значит, это метрика роста. А retention нет; значит, это метрика продукта.
3. Поняли, что для оценки продукта и своей деятельности нужно использовать именно метрики продукта.

Что дальше

Это была 2 статья из серии Дизайнер и метрики. В следующей статье я планирую рассказать как сравнивать изменение метрик что было до релиза и что стало после, как понять улучшили мы продукт или нет. Подписывайтесь, чтобы не пропустить.

Photo by Brooke Cagle on Unsplash

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

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

Дни после релиза

После раскатки нового функционала каждый дизайнер спрашивает себя: что изменилось? Удалось ли нам улучшить продукт?

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

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

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

Как сравнить метрики до и после

Реальное значение метрики против замеренной

У каждой метрики есть её реальное значение назовем его R (реальное), а есть значение, которое мы получили через замеры Z (замеренное).

И первое, с чем нам надо справиться это понять, что R Z.

Разберемся на примере

Допустим, перед нами стоит вопрос, сколько в России людей, которые работают в силовых структурах. Вариант загуглить и узнать не наш выбор в этой статье.

Допустим, теоретически мы могли бы опросить каждого человека в России, силовик он или нет, и получить реальное значение, то есть R.

Но поскольку практически это невозможно, мы опрашиваем столько людей, сколько смогли найти допустим, 300 человек (выборку формируем по науке), и потом просто экстраполируем эти данные на всю Россию.

Так мы получаем Z, то есть замеренную метрику. Думаю, теперь стало понятно, что почти всегда Z R.

Как из замеренной метрики получить реальную?

На этот вопрос как раз и отвечает математика. С помощью математической формулы мы можем получить промежуток значений, в котором находится R.

Вернемся к примеру с силовиками. Предположим, что после опроса 300 человек, 5 из них ответили, что являются сотрудниками силовых структур, то есть приблизительно 1,7%.

Этих данных достаточно, чтобы получить промежуток значений в котором находится R. Для этого нам необходимо:

1. Замеренное значение метрики в случаем с силовиками это 1.7%
2. Количество выборки, на которой сделан замер 300 человек
3. Количество потенциальной выборки (не обязательно) в нашем случае наслеление России 146 млн человек.
4. Выбрать точность, с которой мы хотим получить результат. Обычно используют 90, 95 и 99%

Эти данные нужно ввести в специальный калькулятор для расчета доверительного интервала и нажать вычислить.

На выходе мы получим промежуток, в котором содержится R с вероятность 90, 95 и 99% (в зависимости от того, какой процент мы выбрали при расчёте).

Если вернуться к примеру с силовиками, то после этих расчётов можно сказать, что R находится в промежутке (или доверительном интервале) от 0% до 3,59% от всего населения России.

А значит, если умножить этот процент на население России, то получим интервал от 0 человек до 5 268 274 человек. (В этом интервале действительно содержится верный ответ в реальности это 2,6 миллиона).

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

А как же все-таки сравнить метрики до и после

Теперь нам уже достаточно знаний, чтобы ответить на этот вопрос. Осталось дело за малым: надо просто посчитать доверительный интервал для метрики до и для метрики после и посмотреть, есть ли между ними пересечение.

Если пересечения нет, то мы получили статистически значимые результаты и можно утверждать, что мы что-то изменили в продукте.

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

Разберемся на примере маркетинговой компании

Допустим, мы подготовили 2 креатива, и их посмотрели по 5 000 пользователей. Первый показал значение CTR 2% (это процент нажавших на креатив и перешедших на лендинг), а другой 3%. Можно ли сказать, что второй лучше первого?

Чтобы ответить на этот вопрос, нам надо собрать все данные для измерения доверительного интервала:

По первому банеру:

1. Значение метрики 2%
2. Сколько людей увидело этот банер 5 000
3. Опускаем потенциальную выборку
4. Выбираем точность 95%

Получаем, что R по первому креативу с 95% вероятностью находится между [ 1,61% 2,39% ]

Тоже самое проделываем по второму банеру (его посмотрело тоже 5 000 человек) и получаем интервал [ 2,53% 3,47% ]

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

Подытожим

1. Чтобы оценить работу дизайнера, недостаточно просто посмотреть метрики до и после, нужно сравнить их доверительные интервалы.
2. Посчитать доверительный интервал можно с помощью специального калькулятора.
3. Если доверительные интервалы до и после не пересекаются значит, работа дизайнера точно дала положительный результат.

Что дальше

Это была 3 и последняя статья из серии Дизайнер и метрики.

В следующей статье я планирую рассказать, почему у пользователя нельзя спрашивать, что ему нравится, а что нет. Подписывайтесь, чтобы не пропустить!

Как известно, компания SAP предлагает полный спектр программного обеспечения, как для ведения транзакционных данных, так и для обработки этих данных в системах анализа и отчетности. В частности платформа SAP Business Warehouse (SAP BW) представляет собой инструментарий для хранения и анализа данных, обладающий широкими техническими возможностями. При всех своих объективных преимуществах система SAP BW обладает одним значительным недостатком. Это высокая стоимость хранения и обработки данных, особенно заметная при использовании облачной SAP BW on Hana.

А что если в качестве хранилища начать использовать какой-нибудь non-SAP и желательно OpenSource продукт? Мы в Х5 Retail Group остановили свой выбор на GreenPlum. Это конечно решает вопрос стоимости, но при этом сразу появляются вопросы, которые при использовании SAP BW решались практически по умолчанию.



В частности, каким образом забирать данные из систем источников, которые в большинстве своем являются решениями SAP?

HR-метрики стал первым проектом, в котором необходимо было решить эту проблему. Нашей целью было создание хранилища HR-данных и построение аналитической отчетности по направлению работы с сотрудниками. При этом основным источником данных является транзакционная система SAP HCM, в которой ведутся все кадровые, организационные и зарплатные мероприятия.

Экстракция данных

В SAP BW для SAP-систем существуют стандартные экстракторы данных. Эти экстракторы могут автоматически собирать необходимые данные, отслеживать их целостность, определять дельты изменений. Вот, например, стандартный источник данных по атрибутам сотрудника 0EMPLOYEE_ATTR:



Результат экстракции данных из него по одному сотруднику:



При необходимости такой экстрактор может быть модифицирован под собственные требования или может быть создан свой собственный экстрактор.

Первой возникла идея о возможности их переиспользования. К сожалению, это оказалось неосуществимой задачей. Большая часть логики реализована на стороне SAP BW, и безболезненно отделить экстрактор на источнике от SAP BW не получилось.

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

Структура хранения данных в SAP HCM

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

Большинство данных в SAP HCM хранится в плоских SQL таблицах. На основании этих данных приложения SAP визуализируют пользователю оргструктуры, сотрудников и прочую HR информацию. Например, вот так в SAP HCM выглядит оргструктура:



Физически такое дерево хранится в двух таблицах в hrp1000 объекты и в hrp1001 связи между этими объектами.

Объекты Департамент 1 и Управление 1:



Связь между объектами:



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

Отображение руководителя в SAP:



Хранение в таблице БД:



Данные по сотрудникам хранятся в таблицах pa*. Например, данные о кадровых мероприятиях по сотруднику хранятся в таблице pa0000



Мы приняли решение, что GreenPlum будет забирать сырые данные, т.е. просто копировать их из SAP таблиц. И уже непосредственно в GreenPlum они будут обрабатываться и преобразовываться в физические объекты (например, Отдел или Сотрудник) и метрики (например, среднесписочная численность).

Было определено порядка 70 таблиц, данные из которых необходимо передавать в GreenPlum. После чего мы приступили к проработке способа передачи этих данных.

SAP предлагает достаточно большое количество механизмов интеграции. Но самый простой способ прямой доступ к базе данных запрещен из-за лицензионных ограничений. Таким образом, все интеграционные потоки должны быть реализованы на уровне сервера приложений.
Следующей проблемой было отсутствие данных об удаленных записях в БД SAP. При удалении строки в БД, она удаляется физически. Т.е. формирование дельты изменений по времени изменения не представлялось возможным.

Конечно, в SAP HCM есть механизмы фиксация изменений данных. Например, для последующей передачи в системы получатели существуют указатели изменений(change pointer), которые фиксируют любые изменения и на основании которых формируются Idoc (объект для передачи во внешние системы).

Пример IDoc изменения инфотипа 0302 у сотрудника с табельным номером 1251445:



Или ведение логов изменений данных в таблице DBTABLOG.

Пример лога удаления записи с ключом QK53216375 из таблицы hrp1000:



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

Следующей серьезной проблемой были кластерные таблицы. Данные оценки времени и расчета зарплаты в RDBMS версии SAP HCM хранятся в виде набора логических таблиц по каждому сотруднику за каждый расчет. Эти логические таблицы в виде двоичных данных хранятся в таблице pcl2.

Кластер расчета заработной платы:



Данные из кластерных таблиц невозможно считать SQL командой, а требуется использование макрокоманд SAP HCM или специальных функциональных модулей. Соответственно, скорость считывания таких таблиц будет достаточно низка. С другой стороны, в таких кластерах хранятся данные, которые необходимы только раз в месяц итоговый расчет заработной платы и оценка времени. Так что скорость в этом случае не столь критична.

Оценивая варианты с формированием дельты изменения данных, решили так же рассмотреть вариант с полной выгрузкой. Вариант каждый день передавать гигабайты неизменных данных между системами не может выглядеть красиво. Однако он имеет и ряд преимуществ нет необходимости как реализации дельты на стороне источника, так и реализация встраивания этой дельты на стороне приемника. Соответственно, уменьшается стоимость и сроки реализации, и повышается надежность интеграции. При этом было определено, что практически все изменения в SAP HR происходят в горизонте трех месяцев до текущей даты. Таким образом, было принято решение остановиться на ежедневной полной выгрузке данных из SAP HR за N месяцев до текущей даты и на ежемесячной полной выгрузке. Параметр N зависит от конкретной таблицы
и колеблется от 1 до 15.

Для экстракции данных была предложена следующая схема:



Внешняя система формирует запрос и отправляет его в SAP HCM, там этот запрос проверяется на полноту данных и полномочия на доступ к таблицам. В случае успешной проверки, в SAP HCM отрабатывает программа, собирающая необходимые данные и передающая их в интеграционное решение Fuse. Fuse определяет необходимый топик в Kafka и передает данные туда. Далее данные из Kafka передаются в Stage Area GP.

Нас в данной цепочке интересует вопрос извлечения данных из SAP HCM. Остановимся на нем подробнее.

Схема взаимодействия SAP HCM-FUSE.



Внешняя система определяет время последнего успешного запроса в SAP.
Процесс может быть запущен по таймеру или иному событию, в том числе может быть установлен таймаут ожидания ответа с данными от SAP и инициация повторного запроса. После чего формирует запрос дельты и отправляет его в SAP.

Данные запроса передаются в body в формате json.
Метод http: POST.
Пример запроса:



Сервис SAP выполняет контроль запроса на полноту, соответствие текущей структуре SAP, наличие разрешения доступа к запрошенной таблице.

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

Внешняя система в случае ошибки регистрирует ее в журнале. В случае успешного ответа передает id сессии и имя таблицы по которой был сделан запрос.

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

Фоновое задание SAP формирует курсор по заданным параметрам и пакет данных заданного размера. Размер пакета максимальное количество записей, которые процесс читает из БД. По умолчанию принимается равным 2000. Если в выборке БД больше записей, чем используемый размер пакета после передачи первого пакета формируется следующий блок с соответствующим offset и инкрементированным номером пакета. Номера инкрементируются на 1 и отправляются строго последовательно.

Далее SAP передает пакет на вход web-сервису внешней системы. А она система выполняет контроли входящего пакета. В системе должна быть зарегистрирована сессия с полученным id и она должна находиться в открытом статусе. Если номер пакета > 1 в системе должно быть зарегистрировано успешное получение предыдущего пакета (package_id-1).

В случае успешного контроля внешняя система парсит и сохраняет данные таблицы.

Дополнительно, если в пакете присутствует флаг final и сериализация прошла успешно, происходит уведомление модуля интеграции об успешном завершении обработки сессии и модуль обновляет статус сессии.

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

Так же и в обратном случае, когда внешняя система возвращает ошибку, она логируется и прекращается передача пакетов.

Для запроса данных на стороне SAP HСM был реализован интеграционный сервис. Сервис реализован на фреймворке ICF (SAP Internet Communication Framework help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html). Он позволяет производить запрос данных из системы SAP HCM по определенным таблицам. При формировании запроса данных есть возможность задавать перечень конкретных полей и параметры фильтрации с целью получения необходимых данных. При этом реализация сервиса не предполагает какой-либо бизнес-логики. Алгоритмы расчёта дельты, параметров запроса, контроля целостности, и пр. также реализуются на стороне внешней системы.

Данный механизм позволяет собирать и передавать все необходимые данные за несколько часов. Такая скорость находится на грани приемлемой, поэтому это решение рассматривается нами как временное, позволившее закрыть потребность в инструменте экстракции на проекте.
В целевой картине для решения задачи экстракции данных прорабатываются варианты использования CDC систем типа Oracle Golden Gate или ETL инструментов типа SAP DS.

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

Небольшая, но чертовски интересная преамбула

Идея этой статьи ко мне пришла случайно, когда в очередной раз я набросился на пресловутое уравнение

В попытке решить его АНАЛИТИЧЕСКИ, то есть получить так называемое closed-form solution или ответ в виде конечной композиции чисел (что-то типа ). Кстати, попробуйте сами! Потупив минут 15 над этим уравнением вы быстро поймёте, что предоставленных Вам школьных знаний явно не хватает (наверное) чтобы решить это уравнение, а сложные вышматовские штучки делают решение и вовсе недосягаемым. После вашей первой капитуляции перед этим уравнением, к Вам придёт желание пойти в гугл, а он с подобающим ему беспристрастием выдаст Вам Dottie number, предложив компромиссное решение в виде бесконечной сходящейся численной последовательности.

Да кстати, численное решение: .

Получив решение, Вы можете, вздохнув с облегчением, закрыть вкладку в браузере, приняв реальность talis qualis. Однако я отношусь к той касте отбитых любителей математики, которые считают, что если такие чрезвычайно просто сформулированные задачи испытывают проблемы с решением, то у самой сути разработанной математики есть какие-то проблемы и их неплохо было бы решить (попутно разработав новый аппарат).

В любом случае, в один из таких крестовых походов на эту задачу ко мне пришёл резонный вопрос: "а что такое косинус?". Самое первое определение, которое я когда-то узнал в школе было следующим:

Косинус острого угла в прямоугольном треугольнике это отношение прилежащего катета к гипотенузе.

И именно с этого определения начинается мой рассказ.

Многоликость гипотенузы

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

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

Давайте теперь изменим определение гипотенузы, предполагая, что мы работаем в пространстве с Манхэттенской метрикой. Тогда:

Соответственно определения Синуса и Косинуса станут:

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

К сферам

Определяя метрику в пространстве, мы автоматически определяем сферу на ней (которая по определению: множество равноудалённых точек от данной). Об этом на хабре уже были статьи (например Пространства с иным числом Пи). Поэтому коротко: если мы зададим радиус сферы равным 1, то для различных норм, мы можем определить следующее равенство, задающее сферу (окружность для двумерного случая):

Подставляя различные значения p в уравнение, получаем наших героев:

Как вы наверняка догадались, случай соответствует нашей привычной Евклидовой метрике, а Манхэттенской метрике. Наблюдение того, как плавное изменение параметра p приводит к деформации сферы (и нашего понимания сферы), доставляет неподдельное эстетическое наслаждение Но давайте двинемся дальше.

К тригонометрии

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

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

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

Таким образом, мы будем выполнять следующий набор действий, задавшись, как и ранее единичным радиусом окружности:

1. Зададимся некоторым углом и найдём для него значнеие ;
2. Приравняем полученное значение тангенса к коэффициенту наклона прямой: , и построим эту прямую.
3. Решим уравнение для .
4. Для найденного значения рассчитаем
5. Найдём значение (или любую другую тригонометрическую функцию) по определению.

Кстати, напомню и сразу обобщу это определение для произвольной нормы.

Чтож, я обещал картинки? Да будут картинки! Отправимся же наконец в царство подпольной тригонометрии.

Подполье

Наша первая остановка косинус для Манхэттенской метрики, мы построили его для множества углов: . Для удобства я также построил классический "легальный" косинус.

Что лично меня удивило в этом новом косинусе, это его невыпуклость (или возможно более точно "not concaveness") на заданном интервале. С удовольствием почитаю Ваш комментарий по вопросу: "почему выпуклость могла потеряться?".

Что-нибудь более периодическое?

Кстати, формулы приведения похоже работают как раньше.

Жаль, конечно что потерялась гладкость функции, но этого можно было ожидать, ведь манхэттэнская сфера тоже не особо гладкая.

А что там с тангенсом?

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

Продолжим наши развлечения, построим косинус для множества различных метрик.

Добавим точек:

Вывод

И напоследок. Вызывая в вашем любимом файлообменнике языке программирования встроенную функцию Cos(), помните, что вы обречены получить в ответ только легальную, проверенную временем, всеми любимую . И только те, кто решился на отчаянный шаг войти в кастом подполье, найдут для себя что-то новое и удивительное).

Извините, что оставляю подвал без ссылок на какие-либо источники по данной теме. 10 минут честного гугления на английском не привели меня ни к чему похожему ни на хабре ни где-либо ещё. Буду счастлив добавить это в апдейт из комментариев.

Для любителей посмотреть в код: https://github.com/shappiron/Lp_trigonometry

Tarantool это платформа in-memory вычислений с гибкой схемой данных. На её основе можно создать распределённое хранилище, веб-сервер, высоконагруженное приложение или, в конце концов, сервис, включающий в себя всё вышеперечисленное. Но какой бы ни была ваша промышленная задача, однажды настанет момент, когда её решение придётся мониторить. В этой статье я хочу дать обзор существующих средств для мониторинга приложения на базе Tarantool и пройтись по основным кейсам работы с ними.

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

Настройка логов в Tarantool

Базовое конфигурирование и использование логов

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

Каждое сообщение лога имеет свой уровень детализации. Уровень логирования Tarantool характеризуется значением параметра log_level (целое число от 1 до 7):

1. SYSERROR.
2. ERROR сообщения log.error(...).
3. CRITICAL.
4. WARNING сообщения log.warn(...).
5. INFO сообщения log.info(...).
6. VERBOSE сообщения log.verbose(...).
7. DEBUG сообщения log.debug(...).

Значение параметра log_level N соответствует логу, в который попадают сообщения уровня детализации N и всех предыдущих уровней детализации < N. По умолчанию log_level имеет значение 5 (INFO). Чтобы настроить этот параметр при использовании Cartridge, можно воспользоваться cartridge.cfg:

cartridge.cfg( { ... }, { log_level = 6, ... } )

Для отдельных процессов настройка производится при помощи вызова box.cfg:

box.cfg{ log_level = 6 }

Менять значение параметра можно непосредственно во время работы программы.

Стандартная стратегия логирования: писать об ошибках в log.error() или log.warn() в зависимости от их критичности, отмечать в log.info() основные этапы работы приложения, а в log.verbose() писать более подробные сообщения о предпринимаемых действиях для отладки. Не стоит использовать log.debug() для отладки приложения, этот уровень диагностики в первую очередь предназначен для отладки самого Tarantool. Не рекомендуется также использовать уровень детализации ниже 5 (INFO), поскольку в случае возникновения ошибок отсутствие информационных сообщений затруднит диагностику. Таким образом, в режиме отладки приложения рекомендуется работать при log_level 6 (VERBOSE), в режиме штатной работы при log_level 5 (INFO).

local log = require('log')log.info('Hello world')log.verbose('Hello from app %s ver %d', app_name, app_ver) -- https://www.lua.org/pil/20.htmllog.verbose(app_metainfo) -- type(app_metainfo) == 'table'

В качестве аргументов функции отправки сообщения в лог (log.error/log.warn/log.info/log.verbose/log.debug) можно передать обычную строку, строку с плейсхолдерами и аргументы для их заполнения (аналогично string.format()) или таблицу (она будет неявно преобразована в строку методом json.encode()). Функции лога также работают с нестроковыми данными (например числами), приводя их к строке c помощью tostring().

Tarantool поддерживает два формата логов: plain и json:

2020-12-15 11:56:14.923 [11479] main/101/interactive C> Tarantool 1.10.8-0-g2f18757b72020-12-15 11:56:14.923 [11479] main/101/interactive C> log level 52020-12-15 11:56:14.924 [11479] main/101/interactive I> mapping 268435456 bytes for memtx tuple arena...

{"time": "2020-12-15T11:56:14.923+0300", "level": "CRIT", "message": "Tarantool 1.10.8-0-g2f18757b7", "pid": 5675 , "cord_name": "main", "fiber_id": 101, "fiber_name": "interactive", "file": "\/tarantool\/src\/main.cc", "line": 514}{"time": "2020-12-15T11:56:14.923+0300", "level": "CRIT", "message": "log level 5", "pid": 5675 , "cord_name": "main", "fiber_id": 101, "fiber_name": "interactive", "file": "\/tarantool\/src\/main.cc", "line": 515}{"time": "2020-12-15T11:56:14.924+0300", "level": "INFO", "message": "mapping 268435456 bytes for memtx tuple arena...", "pid": 5675 , "cord_name": "main", "fiber_id": 101, "fiber_name": "interactive", "file": "\/tarantool\/src\/box\/tuple.c", "line": 261}

Настройка формата происходит через параметр log_format так же, как для параметра log_level. Подробнее о форматах можно прочитать в соответствующем разделе документации.

Tarantool позволяет выводить логи в поток stderr, в файл, в конвейер или в системный журнал syslog. Настройка производится с помощью параметра log. О том, как конфигурировать вывод, можно прочитать в документации.

Обёртка логов

Язык Lua предоставляет широкие возможности для замены на ходу практически любого исполняемого кода. Здесь я хотел бы поделиться способом помещения стандартных методов логирования в функцию-обёртку, который мы использовали при реализации сквозного логирования в своих приложениях. Стоит отметить, что способ этот расположен в "серой" зоне легальности, так что прибегать к нему стоит только при отсутствии возможностей решить проблему более элегантно.

local log = require('log')local context = require('app.context')local function init()    if rawget(_G, "_log_is_patched") then        return    end    rawset(_G, "_log_is_patched", true)    local wrapper = function(level)        local old_func = log[level]        return function(fmt, ...)            local req_id = context.id_from_context()            if select('#', ...) ~= 0 then                local stat                stat, fmt = pcall(string.format, fmt, ...)                if not stat then                    error(fmt, 3)                end            end            local wrapped_message            if type(fmt) == 'string' then                wrapped_message = {                    message = fmt,                    request_id = req_id                }            elseif type(fmt) == 'table' then                wrapped_message = table.copy(fmt)                wrapped_message.request_id = req_id            else                wrapped_message = {                    message = tostring(fmt),                    request_id = req_id                }            end            return old_func(wrapped_message)        end    end    package.loaded['log'].error = wrapper('error')    package.loaded['log'].warn = wrapper('warn')    package.loaded['log'].info = wrapper('info')    package.loaded['log'].verbose = wrapper('verbose')    package.loaded['log'].debug = wrapper('debug')    return trueend

Данный код обогащает информацию, переданную в лог в любом поддерживаемом формате, идентификатором запроса request_id.

Настройка метрик в Tarantool

Подключение метрик

Для работы с метриками в приложениях Tarantool существует пакет metrics. Это модуль для создания коллекторов метрик и взаимодействия с ними в разнообразных сценариях, включая экспорт метрик в различные базы данных (InfluxDB, Prometheus, Graphite). Материал основан на функционале версии 0.6.0.

Чтобы установить metrics в текущую директорию, воспользуйтесь стандартной командой:

tarantoolctl rocks install metrics 0.6.0

Чтобы добавить пакет в список зависимостей вашего приложения, включите его в соответствующий пункт rockspec-файла:

dependencies = {    ...,    'metrics == 0.6.0-1',}

Для приложений, использующих фреймворк Cartridge, пакет metrics предоставляет специальную роль cartridge.roles.metrics. Включение этой роли на всех процессах кластера упрощает работу с метриками и позволяет использовать конфигурацию Cartridge для настройки пакета.

Встроенные метрики

Сбор встроенных метрик уже включён в состав роли cartridge.roles.metrics.

Для включения сбора встроенных метрик в приложениях, не использующих фреймворк Cartridge, необходимо выполнить следующую команду:

local metrics = require('metrics')metrics.enable_default_metrics()

Достаточно выполнить её единожды на старте приложения, например поместив в файл init.lua.

В список метрик по умолчанию входят:

• информация о потребляемой Lua-кодом RAM;
• информация о текущем состоянии файберов;
• информация о количестве сетевых подключений и объёме сетевого трафика, принятого и отправленного процессом;
• информация об использовании RAM на хранение данных и индексов (в том числе метрики slab-аллокатора);
• информация об объёме операций на спейсах;
• характеристики репликации спейсов Tarantool;
• информация о текущем времени работы процесса и другие метрики.

Подробнее узнать о метриках и их значении можно в соответствующем разделе документации.

Для пользователей Cartridge также существует специальный набор встроенных метрик для мониторинга состояния кластера. На данный момент он включает в себя метрику о количестве проблем в кластере, разбитых по уровням критичности (аналогична Issues в WebUI Cartridge).

Плагины для экспорта метрик

Пакет metrics поддерживает три формата экспорта метрик: prometheus, graphite и json. Последний можно использовать, например, в связке Telegraf + InfluxDB.

Чтобы настроить экспорт метрик в формате json или prometheus для процессов с ролью cartridge.roles.metrics, добавьте соответствующую секцию в конфигурацию кластера:

metrics:  export:    - path: '/metrics/json'      format: json    - path: '/metrics/prometheus'      format: prometheus

Экспорт метрик в формате json или prometheus без использования кластерной конфигурации настраивается средствами модуля http так же, как любой другой маршрут.

local json_metrics = require('metrics.plugins.json')local prometheus = require('metrics.plugins.prometheus')local httpd = require('http.server').new(...)httpd:route(    { path = '/metrics/json' },    function(req)        return req:render({            text = json_metrics.export()        })    end)httpd:route( { path = '/metrics/prometheus' }, prometheus.collect_http)

Для настройки graphite необходимо добавить в код приложения следующую секцию:

local graphite = require('metrics.plugins.graphite')graphite.init{    host = '127.0.0.1',    port = 2003,    send_interval = 60,}

Параметры host и port соответствуют конфигурации вашего сервера Graphite, send_interval периодичность отправки данных в секундах.

При необходимости на основе инструментов пакета metrics можно создать собственный плагин для экспорта. Советы по написанию плагина можно найти в соответствующем разделе документации.

Добавление пользовательских метрик

Ядро пакета metrics составляют коллекторы метрик, созданные на основе примитивов Prometheus:

• counter предназначен для хранения одного неубывающего значения;
• gauge предназначен для хранения одного произвольного численного значения;
• summary хранит сумму значений нескольких наблюдений и их количество, а также позволяет вычислять перцентили по последним наблюдениям;
• histogram агрегирует несколько наблюдений в гистограмму.

Cоздать экземпляр коллектора можно следующей командой:

local gauge = metrics.gauge('balloons')

В дальнейшем получить доступ к объекту в любой части кода можно этой же командой.

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

local gauge = metrics.gauge('balloons')gauge:set(1, { color = 'blue' })gauge:set(2, { color = 'red' })

внутри коллектора возникнет два различных значения метрики. Для того чтобы каким-либо образом изменить значение конкретной метрики в коллекторе, необходимо указать соответствующие ей лейблы:

gauge:inc(11, { color = 'blue' }) -- increase 1 by 11

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

В программе есть модуль server, который принимает запросы и способен сам их отправлять. Вместо того, чтобы использовать две различных метрики server_requests_sent и server_requests_received для хранения данных о количестве отправленных и полученных запросов, следует использовать общую метрику server_requests с лейблом type, который может принимать значения sent и received.

Подробнее о коллекторах и их методах можно прочитать в документации пакета.

Заполнение значений пользовательских метрик

Пакет metrics содержит полезный инструмент для заполнения коллекторов метрик коллбэки. Рассмотрим принцип его работы на простом примере.

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

local metrics = require('metrics')local buffer = require('app.buffer')metrics.register_callback(function()    local gauge = metrics.gauge('buffer_count')    gauge.set(buffer.count())end)

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

Мониторинг HTTP-трафика

Пакет metrics содержит набор инструментов для подсчёта количества входящих HTTP-запросов и измерения времени их обработки. Они предназначены для работы со встроенным пакетом http, и подход будет отличаться в зависимости от того, какую версию вы используете.

Чтобы добавить HTTP-метрики для конкретного маршрута при использовании пакета http 1.x.x, вам необходимо обернуть функцию-обработчик запроса в функцию http_middleware.v1:

local metrics = require('metrics')local http_middleware = metrics.http_middlewarehttp_middleware.build_default_collector('summary', 'http_latency')local route = { path = '/path', method = 'POST' }local handler = function() ... endhttpd:route(route, http_middleware.v1(handler))

Для хранения метрик можно использовать коллекторы histogram и summary.

Чтобы добавить HTTP-метрики для маршрутов роутера при использовании пакета http 2.x.x, необходимо воспользоваться следующим подходом:

local metrics = require('metrics')local http_middleware = metrics.http_middlewarehttp_middleware.build_default_collector('histogram', 'http_latency')router:use(http_middleware.v2(), { name = 'latency_instrumentation' })

Рекомендуется использовать один и тот же коллектор для хранения всей информации об обработке HTTP-запросов (например, выставив в начале коллектор по умолчанию функцией build_default_collector или set_default_collector). Прочитать больше о возможностях http_middleware можно в документации.

Глобальные лейблы

В пункте "Добавление пользовательских метрик" вводится понятие лейблов, предназначенных для различения измеряемых характеристик в рамках одной метрики. Их выставление происходит непосредственно при измерении наблюдения в рамках одного коллектора. Однако это не единственный тип лейблов, которые поддерживает пакет metrics.

Для того чтобы прибавить к каждой метрике какой-то общий для процесса или группы процессов Tarantool (например, имя машины или название приложения) лейбл, необходимо воспользоваться механизмом глобальных лейблов:

local metrics = require('metrics')local global_labels = {}-- постоянное значениеglobal_labels.app = 'MyTarantoolApp'-- переменные конфигурации кластера (http://personeltest.ru/aways/www.tarantool.io/ru/doc/latest/book/cartridge/cartridge_api/modules/cartridge.argparse/)local argparse = require('cartridge.argparse')local params, err = argparse.parse()assert(params, err)global_labels.alias = params.alias-- переменные окружения процессаlocal host = os.getenv('HOST')assert(host)global_labels.host = hostmetrics.set_global_labels(global_labels)

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

Роль cartridge.roles.metrics по умолчанию выставляет alias процесса Tarantool в качестве глобального лейбла.

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

Мониторинг внешних параметров

Tarantool не только позволяет организовывать сбор внутренних метрик о работе приложения, но и способен выступать как агент мониторинга внешних параметров. Подмодуль psutils пакета metrics является примером реализации такого поведения.

С помощью psutils можно настроить сбор метрик об использовании CPU процессами Tarantool. Его информация основывается на данных /proc/stat и /proc/self/task. Подключить сбор метрик можно с помощью следующего кода:

local metrics = require('metrics')metrics.register_callback(function()    local cpu_metrics = require('metrics.psutils.cpu')    cpu_metrics.update()end)

Возможность писать код на Lua делает Tarantool гибким инструментом, позволяющим обходить различные препятствия. Например, psutils возник из необходимости следить за использованием CPU вопреки отказу администраторов со стороны заказчика "подружить" в правах файлы /proc/* процессов Tarantool и плагин inputs.procstat Telegraf, который использовался на местных машинах в качестве основного агента.

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

Визуализация метрик

Хранение метрик в Prometheus

Настройка пути для экспорта метрик Tarantool в формате Prometheus описана в пункте "Плагины для экспорта метрик". Ответ запроса по такому маршруту выглядит следующим образом:

...# HELP tnt_stats_op_total Total amount of operations# TYPE tnt_stats_op_total gaugetnt_stats_op_total{alias="tnt_router",operation="replace"} 1tnt_stats_op_total{alias="tnt_router",operation="select"} 57tnt_stats_op_total{alias="tnt_router",operation="update"} 43tnt_stats_op_total{alias="tnt_router",operation="insert"} 40tnt_stats_op_total{alias="tnt_router",operation="call"} 4...

Чтобы настроить сбор метрик в Prometheus, необходимо добавить элемент в массив scrape_configs. Этот элемент должен содержать поле static_configs с перечисленными в targets URI всех интересующих процессов Tarantool и поле metrics_path, в котором указан путь для экспорта метрик Tarantool в формате Prometheus.

scrape_configs:  - job_name: "tarantool_app"    static_configs:      - targets:         - "tarantool_app:8081"        - "tarantool_app:8082"        - "tarantool_app:8083"        - "tarantool_app:8084"        - "tarantool_app:8085"    metrics_path: "/metrics/prometheus"

В дальнейшем найти метрики в Grafana вы сможете, указав в качестве job соответствующий job_name из конфигурации.

Пример готового docker-кластера Tarantool App + Prometheus + Grafana можно найти в репозитории tarantool/grafana-dashboard.

Хранение метрик в InfluxDB

Чтобы организовать хранение метрик Tarantool в InfluxDB, необходимо воспользоваться стеком Telegraf + InfluxDB и настроить на процессах Tarantool экспорт метрик в формате json (см. пункт "Плагины для экспорта метрик"). Ответ формируется следующим образом:

{    ...    {        "label_pairs": {            "operation": "select",            "alias": "tnt_router"        },        "timestamp": 1606202705935266,        "metric_name": "tnt_stats_op_total",        "value": 57    },    {        "label_pairs": {            "operation": "update",            "alias": "tnt_router"        },        "timestamp": 1606202705935266,        "metric_name": "tnt_stats_op_total",        "value": 43    },    ...}

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

[[inputs.http]]    urls = [        "http://tarantool_app:8081/metrics/json",        "http://tarantool_app:8082/metrics/json",        "http://tarantool_app:8083/metrics/json",        "http://tarantool_app:8084/metrics/json",        "http://tarantool_app:8085/metrics/json"    ]    timeout = "30s"    tag_keys = [        "metric_name",        "label_pairs_alias",        "label_pairs_quantile",        "label_pairs_path",        "label_pairs_method",        "label_pairs_status",        "label_pairs_operation"    ]    insecure_skip_verify = true    interval = "10s"    data_format = "json"    name_prefix = "tarantool_app_"    fieldpass = ["value"]

Список urls должен содержать URL всех интересующих процессов Tarantool, настроенные для экспорта метрик в формате json. Обратите внимание, что лейблы метрик попадают в Telegraf и, соответственно, InfluxDB как теги, название которых состоит из префикса label_pairs_ и названия лейбла. Таким образом, если ваша метрика имеет лейбл с ключом mylbl, то для работы с ним в Telegraf и InfluxDB необходимо указать в пункте tag_keys соответствующего раздела [[inputs.http]] конфигурации Telegraf значение ключа label_pairs_mylbl, и при запросах в InfluxDB ставить условия на значения лейбла, обращаясь к тегу с ключом label_pairs_mylbl.

В дальнейшем найти метрики в Grafana вы сможете, указав measurement в формате <name_prefix>http (например, для указанной выше конфигурации значение measurement tarantool_app_http).

Пример готового docker-кластера Tarantool App + Telegraf + InfluxDB + Grafana можно найти в репозитории tarantool/grafana-dashboard.

Стандартный дашборд Grafana

Для визуализации метрик Tarantool с помощью Grafana на Official & community built dashboards опубликованы стандартные дашборды. Шаблон состоит из панелей для мониторинга HTTP, памяти для хранения данных вместе с индексами и операций над спейсами Tarantool. Версию для использования с Prometheus можно найти здесь, а для InfluxDB здесь. Версия для Prometheus также содержит набор панелей для мониторинга состояния кластера, агрегированной нагрузки и потребления памяти.

Чтобы импортировать шаблон дашборды, достаточно вставить необходимый id или ссылку в меню Import на сервере Grafana. Для завершения процесса импорта необходимо задать переменные, определяющие место хранения метрик Tarantool в соответствующей базе данных.

Генерация дашбордов Grafana с grafonnet

Стандартные дашборды Grafana были созданы с помощью инструмента под названием grafonnet. Что это за заморский зверь и как мы к нему пришли?

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

Одним из первых способов решить большинство возникающих проблем было использование механизма динамических переменных (Variables) в Grafana. Например, он позволяет объединить дашборды с метриками из разных зон в одну с удобным переключателем. К сожалению, мы слишком быстро столкнулись с проблемой: использование механизма оповещений (Alert) не совместимо с запросами, использующими динамические переменные.

Любой дашборд в Grafana по сути представляет собой некоторый json. Более того, платформа позволяет без каких-либо затруднений экспортировать в таком формате существующие дашборды. Работать с ним в ручном режиме несколько затруднительно: размер даже небольшого дашборда составляет несколько тысяч строк. Первым способом решения проблемы был скрипт на Python, который заменял необходимые поля в json, по сути превращая один готовый дашборд в другой. Когда разработка библиотеки скриптов пришла к задаче добавления и удаления конкретных панелей, мы начали осознавать, что пытаемся создать генератор дашбордов. И что эту задачу уже кто-то до нас решал.

В открытом доступе можно найти несколько проектов, посвящённых данной теме. К счастью или несчастью, проблема выбора решилась быстро: на контуре заказчика для хранения метрик мы безальтернативно пользовались InfluxDB, а поддержка запросов к InfluxDB хоть в какой-то форме присутствовала только в grafonnet.

grafonnet opensource-проект под эгидой Grafana, предназначенный для программной генерации дашбордов. Он основан на языке программирования jsonnet языке для генерации json. Сам grafonnet представляет собой набор шаблонов для примитивов Grafana (панели и запросы разных типов, различные переменные) с методами для объединения их в цельный дашборд.

Основным преимуществом grafonnet является используемый в нём язык jsonnet. Он прост и минималистичен, и всегда имеет дело с json-объектами (точнее, с их местной расширенной версией, которая может включать в себя функции и скрытые поля). Благодаря этому на любом этапе работы выходной объект можно допилить под себя, добавив или убрав какое-либо вложенное поле, не внося при этом изменений в исходный код.

Начав с форка проекта и сборки нашей дашборды на основе этого форка, впоследствии мы оформили несколько Pull Request-ов в grafonnet на основе наших изменений. Например, один из них добавил поддержку запросов в InfluxDB на основе визуального редактора.

Код наших стандартных дашбордов расположен в репозитории tarantool/grafana-dashboard. Здесь же находится готовый docker-кластер, состоящий из стеков Tarantool App + Telegraf + InfluxDB + Grafana, Tarantool App + Prometheus + Grafana. Его можно использовать для локальной отладки сбора и обработки метрик в вашем собственном приложении.

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

На что смотреть?

В первую очередь, стоит следить за состоянием самих процессов Tarantool. Для этого подойдёт, например, стандартный up Prometheus. Можно соорудить простейший healthcheck самостоятельно:

httpd:route(    { path = '/health' },    function(req)        local body = { app = app, alias = alias, status = 'OK' }        local resp = req:render({ json = body })        resp.status = 200        return resp    end)

Рекомендации по мониторингу внешних параметров ничем принципиально не отличаются от ситуации любого другого приложения. Необходимо следить за потреблением памяти на хранение логов и служебных файлов на диске. Заметьте, что файлы с данными .snap и .xlog возникают даже при использовании движка memtx (в зависимости от настроек). При нормальной работе нагрузка на CPU не должна быть чересчур большой. Исключение составляет момент восстановления данных после рестарта процесса: построение индексов может загрузить все доступные потоки процессора на 100 % на несколько минут.

Потребление RAM удобно разделить на два пункта: Lua-память и память, потребляемая на хранение данных и индексов. Память, доступная для выполнения кода на Lua, имеет ограничение в 2 Gb на уровне Luajit. Обычно приближение метрики к этой границе сигнализирует о наличии какого-то серьёзного изъяна в коде. Более того, зачастую такие изъяны приводят к нелинейному росту используемой памяти, поэтому начинать волноваться стоит уже при переходе границы в 512 Mb на процесс. Например, при высокой нагрузке в наших приложениях показатели редко выходили за предел 200-300 Mb Lua-памяти.

При использовании движка memtx потреблением памяти в рамках заданного лимита memtx_memory (он же метрика quota_size) заведует slab-аллокатор. Процесс происходит двухуровнево: аллокатор выделяет в памяти ячейки, которые после занимают сами данные или индексы спейсов. Зарезервированная под занятые или ещё не занятые ячейки память отображена в quota_used, занятая на хранение данных и индексов arena_used (только данных items_used). Приближение к порогу arena_used_ratio или items_used_ratio свидетельствует об окончании свободных зарезервированных ячеек slab, приближение к порогу quota_used_ratio об окончании доступного места для резервирования ячеек. Таким образом, об окончании свободного места для хранения данных свидетельствует приближение к порогу одновременно метрик quota_used_ratio и arena_used_ratio. В качестве порога обычно используют значение 90 %. В редких случаях в логах могут появляться сообщения о невозможности выделить память под ячейки или данные даже тогда, когда quota_used_ratio, arena_used_ratio или items_used_ratio далеки от порогового значения. Это может сигнализировать о дефрагментации данных в RAM, неудачном выборе схем спейсов или неудачной конфигурации slab-аллокатора. В такой ситуации необходима консультация специалиста.

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

Заключение

Как этот материал, так и пакет metrics назвать "всеохватными" и "универсальными" на данный момент нельзя. Открытыми или находящимися на данный момент в разработке являются вопросы метрик репликации, мониторинга движка vinyl, метрики event loop и полная документация по уже существующим методам metrics.

Не стоит забывать о том, что metrics и grafana-dashboard являются opensource-разработками. Если при работе над своим проектом вы наткнулись на ситуацию, которая не покрывается текущими возможностями пакетов, не стесняйтесь внести предложение в Issues или поделиться вашим решением в Pull Requests.

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

Полезные ссылки:

• документация log: ссылка;
• конфигурация параметров log: ссылка;
• модуль tarantool/metrics: ссылка;
• документация по мониторигу: ссылка;
• проект tarantool/grafana-dashboard: ссылка;
• стандартные дашборды Tarantool для Grafana: InfluxDB, Prometheus;
• проект grafonnet: ссылка;
• скачать Tarantool можно на официальном сайте;
• получить помощь можно в Telegram-чате.