#машины_разное

Тонкое искусство наблюдаемости (оно же observability), прошло не один десяток лет, прежде чем заматереть.

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

После SRE научил не просто мерять сигналы, а выработать некий стандарт из 4 золотых сигналов , тот же Брендан Грегг использует метод USE (Utilisation/Saturation/Errors) для выявления проблем с производительностью.

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

Если отвлечься от технической части, то наблюдаемость нам нужна, чтобы ответить на вопрос “Оно работает?”, и этот вопрос куда сложнее, чем многие думают.

Автор этих строк помнит активные дискуссии на том же Хабре и тематических чатах времен 2014-2018, когда сильные умы мира сего задавали эти титанически сложные вопросы “А что значит не работает?”, “А что мы понимаем под работой?” или мое любимое “А когда оно у вас в последний раз работало?”.

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

Но я не зря написал про толкования “рабочести” и изменчивость нашей индустрии. Видите ли, система может быть по всем фронтам “здоровой”, значения метрик приемлемыми, пейджер тихим, дежурство спокойным… А система все равно не будет работать! 😱

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

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

Например, если у нас есть определенный SLA на техподдержку, то рабочая система такая: 10 человек завели по жалобе, 10 жалоб создалось, 10 жалоб получили по назначенному специалисту ТП, 10 жалоб разрешилось в рамках SLA. Любое отклонение - вне зависимости от причин - является симптомом нерабочей системы. 🎉

---

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

С наступающим!