Как комплексно оценить эффективность микросервиса?

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

1. Технические метрики, или «Четыре золотых сигнала» от этих, блядь, гугловских умников (Google SRE)

Это как четыре столпа, на которых держится вся наша конструкция. Если один хромает — вся постройка к ебеням рухнет.

• Задержка (Latency): Это сколько наш сервис тупит, прежде чем ответить. И смотрите, сука, самое главное — не средняя температура по больнице! Надо смотреть на самые долгие, ёбта, запросы (95-й, 99-й перцентиль). Потому что один пользователь, который пять минут ждёт, — это уже пи**ец какому пользовательскому опыту. Он уже всё про тебя в твиттере написал, пока ты среднюю цифру считал.
• Трафик (Traffic): Просто — сколько к нам ломятся. Запросов в секунду, гигабайтов в час. Если цифра ноль — может, сервис уже сдох, а мы и не в курсе?
• Ошибки (Errors): Сколько раз мы, простите, обосрались. Не только явные «500 Internal Server Error», но и эти подлые «200 ОК», а в ответе — хуйня какая-то. Вот это и есть самые опасные твари, блядь.
• Насыщенность (Saturation): Насколько мы уже по горло в дерьме. Процессор пыхтит на 95%, память вся забита — это знак, что скоро будет большой, жирный, вонючий пиздец. Надо заранее видеть, куда бежать и что масштабировать.

2. Бизнес-метрики, или «А нахуя мы это вообще делали?»

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

• Влияние на продукт: Этот сервис сколько денег принёс? Регистраций, заказов, платежей? Если ноль — может, его выключить и сэкономить на электричестве?
• Конверсия: Если наш сервис — часть воронки, и из-за его тормозов люди уходят, не купив, то мы, простите, просто пидарасы шерстяные, которые бизнесу саботируют.

3. Стоимость владения, или «А не дороже ли он золотого унитаза?»

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

• Инфраструктурные затраты: За хостинг сколько платим? За процессоры, память, трафик?
• Затраты на поддержку: Сколько времени инженеры, вместо того чтобы новые фичи пилить, тратят на то, чтобы этот сервис оживлять, чинить и успокаивать? Это время — тоже деньги, и немалые, блядь.

Инструменты, без которых мы как без рук

• Сбор метрик: Prometheus. Без него мы слепые кроты.
• Визуализация: Grafana. Чтобы эти цифры не просто в столбике были, а на красивых графиках, которые даже менеджеру покажешь.
• Трассировка: Jaeger, OpenTelemetry. Чтобы понять, где именно в цепочке наш сервис начал, простите, срать кирпичами.
• Логирование: ELK Stack или Loki. Чтобы когда всё упало, можно было покопаться в этих, блядь, логических дебрях и найти причину.

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

import (
    "net/http"
    "time"
    "github.com/prometheus/client_golang/prometheus"
)

func metricsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        next.ServeHTTP(w, r)
        duration := time.Since(start)

        // Записываем длительность запроса в гистограмму Prometheus
        httpRequesDuration.WithLabelValues(r.URL.Path).Observe(duration.Seconds())
    })
}

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