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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Идея! Давайте тегировать error rate еще и build number'ом

В конце дня наш девелопер научилась тестировать в продакшене, смотреть в мониторинг и ваще стала лучше

(или нет, прим. записывающего человека)

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