Презенташка про подходы, а не тулзы

О уроках извлеченных из создания систем

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

SLI/SLO ничего не значат, пока юзеры счастливы

Последнее время говорят про DevOps и это опсы которые кодят, а что если девов научить опсить?

И вот Observability - это как раз тот самый мостик который поможет девелоперам понимать в чем же отличие запуска кода в проде от их локальной машины )

Для опсов - e2e check'и, алерты, ресурсы, сеть, метрики, хосты и инстансы

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

Software Developer - очень сфокусирован на кастомерах

Все TDD, архитектура, тесты, ревью, CI/CD - про это

Не все что интересно девелоперам - проблемы. Иногда им интересно что будет если пооптимизировать кусочек

Тестов - недостаточно
Бенчмарков - недостаточно
Исключений - недостаточно

Время нескучных историй!

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

(какие то скучные нескучные истории)

А теперь она решает потестировать все в продакшене!

Повключать feature flag'и и посмотреть что случиться

так она может сравнить всякую всячину с кластером

А еще таким макаром можно включать фичи по частям и увеличивать сколько людей получают новые фичи!

А теперь представим что у нас релиз с багами

Очень хочется знать откуда баг появился