---

Я разрабатываю Observability платформу Solomon (она же Мониторинг, monitoring, monium или Мониум) и руковожу командой разработчиков, в чьей зоне ответственности находтся авторизация, квотирование, control plane, управление доступами и API Monium, а так же отправка данных в биллинг и в сервис управления квотами. Мы являемся владельцами сервисов gateway, project-manager и quota-service, а так же ресурсов и датасорсов мониторинга в terraform-provider-ycp.

Сейчас я готовлюсь к конференции DevOops 2026, где у меня будет доклад "Вы делаете обзервабилити неправильно". Это провакационное название, внутри я на самом деле хочу рассказать о том на какие метрики обзервабилити платформы мы обычно смотрим при принятии решений о развитии, как эти метрики соотносятся с фичами и проблемами с этим связанными. Доклад будет основан на материалах моих прошлых докладов "Математика Observability" на DevOpsConf 2025 и "Строим APM-систему" на DUMP 2026.

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

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



# Выступление

## Слайд 1

### Контент слайда

### Прямая речь выступающего

<Тут слайд с темой и именем>

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

<Тут слайд с моим фото на фоне экрана с DUMP с заголовком темы>

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

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

<Слайд с заголовком "Что будет в ближайшие пол часа", первый пункт "Почему я это рассказываю">

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

<На слайде появляется второй пункт "Деконструкция надежности">

Потом пару слов про то из чего состоит надежность и на что мы её тратим.

<На слайде появляется третий пункт "Доеконструкция инцидента">

И ещё более подробный разбор на что мы её тратим.

<На слайде поялвется четвертый пункт "Деконструкция observability">

И почему мы её тратим, и как её не тратить. Тут будет какой-то первый вывод. 

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

<На слайде появляется пятый пункт "Привычный путь развития observability">

От прометеуса, к дашам, алертам, автоматизации, платформизации и прочему.

<На слайде появляется шестой пункт "Привычный тупик развития observability">

Ну и вишенкой на торте то почему это тупик. 

<На слайде появляется седьмой пункт "и как из него выйти">

И раз уж меня пустили на сцену - то душное мнение всезнайки по этому поводу.

Ну что, выглядит плотно. Погнали!

<Слайд "Глава 1. Почему я это рассказываю">

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

<Слайд с моим фото с мягкими кубиками на голове>

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

Последний год я делаю нашу observability-платформу Monium и скоро объясню почему. 


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

<Слайд "Глава 2. Деконструкция надежности">

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

<Слайд с заголовком "Что такое надежность" На экране появляется формула "Надежность = Общее время измерения - продолжительность недоступности в секундах">

И каких девяток от нас просят. Скажите, есть тут люди, которым не нравится эта формула? Отлично. Я с вами. И правда, чего это мы измеряем время, когда у нас есть сезонность, заказы. 

<На экране перечеркивается исходная формула, вместо неё появляется новая "Наженость = Все возможные заказы/запросы/целевые действия - число несделанных действий из-за недоступности">

Может тогда так лучше?

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

<Вторая формула тоже перечеркивается и появляется третья "Надежность = вся возможная прибыль - неполученная из-за недоступности прибыль">

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

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

<На слайде появляется большая формула "Надежность = f(инцидентов)">

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

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

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

<От блока "Инцидентов много и они все одинаковые" отходят вниз новые блоки "автоканарейка", "фиче-флаги", "быстрый rollback">

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

<От блока "Как инциденты тратят надежность" отходит новый блок "Все инциденты разные">

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

<От блока "Все инциденты разные" отходит блок "Уменьить продолжительность оставшихся инцидентов">

И тогда остается только сокращать продолжительность оставшихся инцидентов. 

<Слайд "Глава 3. Деконструкция инцидента">

А из чего состоит время инцидента? Нас сейчас интересует горячая фаза, то есть от того, когда случился триггер или началось влияние на пользователей до того, когда влияние на пользователей прекратилось. 

<На слайде появляется множество пунктов: Mean time to detect, mean time to respond, mean time mitigate, mean time to recover, mean time to restore, mean time to root cause, mena time to aknowlage>

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

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

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

Потом начинается самое интеерсное - найти, что сломалось или как починить. 

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

А давайте так - кого-нибудь что-нибудь раздражает на этом слайде?

<Во всех пунктах Mean зачеркивается на слайдах>

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

Но у нас же есть постмортемы. И в них сырые данные, которые мы можем использовать.

<Слайд "Распределение времени на разных этапах инцидента">

Давайте попробуем собарть картинку. Например, обнаружение.

<Появляется график, по оси X время в минутах, по оси Y "доля инцдиентов". На графике показан этап "Обнаружение" с значением из исходной презентации.>

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

<Добавляется этап "Реагирование" с значением из исходной презентации>

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

<Добавляется этап "Поиск конревой причины" с значением из исходной презентации>

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

<Добавляется этап "починка" с значением из исходной презентации>

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

Шёпот из зала "Зачем он это рассказывает?" Подождите подождите, я веду к одной мысли. 

<Слайд "Глава 4. Деконструкция observability">

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

<Возвращается слайд с графиком и всеми этапами - обнаружением, реагирвоанием, поиском руткоза и починкой>

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

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

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

<Снова появляется слайд "Надежность = f(инцидентов)", где теперь есть ещё две формулы "Продолжительность инцидентов = g(observability)" и Надежность = f(g(observability))>

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

<Слайд "Глава 5. Привычный путь развития observability">

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

<Слайд "Каменный век. Ничего нет. На слайде написано ssh, grep">

Вначале ничего не было. Но инциденты всё равно чинились. Обнаруживали не сразу. Искали долго. Но чинились. 

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

<Слайд "helm install prometheus">

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

Давайте посмотрим на это вот с какой стороны

<Слайд с заголовком "Метрики observability-платформы", на слайде график с двумя осями. Ось X никак не подписана, это будет время или вехи. Ось Y подписана как "затраты">

Когда у нас ничего не было - мы не вкладыывали ресурсы в observability.

<На слайде появляется подзаголовок "Каменный век" и первая точка в крайней левой точке и 0 по оси Y, референс есть в исходной презентации>

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

<На слайде появляется вторая точка в крайней левой точке и на самом верху по оси Y, референс есть на исходной презентации>

Мы поставили прометеус и теперь его поддерживаем, поэтому затраты на observability выросли. 

<Подзаголовок "Каменный век" меняется на "helm install prometheus". От первой точки с отсутствием затрат начинается линия вверх и вправо, референс в исходной презентации>

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

<От второй точки с максимальной продолжительностью инцидентов начинается линия вниз влево, референс в исходной презентации>

Супер. Давайте теперь суперкратко посмотрим на эволюцию observability в компании.

<Подзаголвок "helm install prometheus" меняется на "Разработчики собирают дашборды руками". Появляются третьи точки с аналогичным прошлому трендом, референс в исходной презентации>

Дашборды позволят не писать запросы руками, ускорят расследование, но надо будет клапть дашборды.

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

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

Где-то в этот момент появляется платформа - все новые сервисы автоматически обзоводятся алертами, эскалациями, SLO и дашбордами из коробки.

<Слайд с заголовком "На что уходит время инцдиентов">

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

<На слайде появляется первый пункт "Разрыв между разными типами телеметрии">

Видим аномальную линию на графике. Чтобы понять, что случилось — нужно прыгнуть в логи или трейсы. Но они не рядом. Они в другой системе, со своими селекторами и контекстом. Переход руками — минуты.

<На слайде появляется второй пункт "Инцидент глазами одного сервиса - это ловушка">

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

<На слайде появляется третий пункт "Данные соседей по чатам">

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

<Новый слайд. Заголовок "Как ещё мы снижали время инцидентов">

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

<Слайд "Ранбуки">

Да, просто да. Я не буду в 2026 году объяснять почему да. Пошли дальше. 

<Слайд "Навигироваться прямо с линии", на нем скриншоты контекстных ссылок и быстрых ссылок из Monium, которые я добавлю>

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

Видим на графике всплеск ошибок или latency. Нажимаем на линию — и получаем готовый запрос в трассировки или логи. По ссылке — уже отфильтрованные данные по нужному эндпоинту и коду ошибки.

<Слайд "Карта сервисов", на нем скриншот нескольких карт сервисов из Monium, которые я добавлю отдельно>

Строим карту, где видны связи между сервисами, трафик, latency.

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

<Слайд "Страница дежурного", на нем скриншоты нескольких страниц дежурного, которые я добавлю отдельно>

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

Больше не надо бегать по чатам и внешним системам. 

<Снова появляется слайд с графиком продолжительности инцидентов и затрат на развитие observability, на нем тренд линий продолжаются и они пересекаются друг с другом и идут дальше.>

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

<Поялвяется слайд-заголовок "Привычный тупик развития observability">

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

<К заголовку добавляется надпись "и как из него выйти">

Смотрите. Есть идейка. Давайте объясню. Как мы привыкли воспринимать обзервабилити решения. 4 вида телеметрии. Возможность писать. Читать. Хранимые отображения. Поэтому мы о них и говорили - логи, дашборды, алерты и ссылки между ними. В общем, эдакий конструктор для всех на все случаи жизни.

<Появляется слайд "Чего хотел пользователь" на котором расположен комикс с детсикими качелями и подписями "Как продакт описал потребность, как реализовали разработчики, как отдел маркетинга прорекламировал" и "чего на самом деле хотел пользователь" (извстный комикс демонстрирующий проблему согласованности ожиданий при разработке ИТ-продуктов)>

А что на самом деле нужно пользователю.

- Что с моими сервисами

<На слайде появляется надпись "Что с моими сервисами", слово "сервисами" выделено жирным>

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

<На слайде появляется надпись "Я дежурный, что самое главное я должен знать о своих сервисах прямо сейчас", слово сервисах выделено жирным>

- Что происходит с зависимостями моих сервисов?

<На слайде появляется надпись "Что происходит с зависимостями моих сервисов", слово "сервисов" выделено жирным>

Или, например, "какие аномалии есть в моих сервисах" потому что смотреть на что-то, что ведет себя так же, как всегда не очень нужно.

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

Предположим. А при чём тут вообще тема доклада?

<Слайд с заголовком "Сервисоцентричный Observability">

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

<Слайд с кубиком "метрики, логи, трейсы, профили">

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

<На слайде появляются следующие кубики "сервис 1", "сервис 2", ... "сервис N">

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

<На слайде появляются стрелки между кубиками сервисов, которые обозначают связи между ними>

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

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

<На слайде появляются скриншоты APM DataDog>

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

<На слайде появляются дополнительные скриншоты APM DataDog с графикаии конкретного сервиса>

И детализировать картину конкретного сервиса и его связей. 

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

<Появляется слайд с надписью "Данные у нас всегда были, просто мы не строили над ними продукта">

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

<Слайд с надписью "Нет, Вадим, нельзя">

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

<На слайде появляется продолжение "Нет, Вадим, нельзя, потому что все данные разные">

Если смотреть на идеальный мир, то у нас есть: 
- OpenTelemetry Semantic Conventions
- Prometheus naming conventions
- OpenMetrics
- Популярные библиотеки для языков

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

<Слайд с заголовком "Делаем типовое из нетипового", на нем две картинки с лейблами метрики, которые сильно отличаются>

Иногда одна и та же метрика из двух сервисов выглядит совершенно по-разному. Что тут можно сделать. 

Первое на мой взгляд - всё равно поддержать основные стандарты. Это будет мотиацией для ваших пользователей делать новые вещи на стандартных рельсах.

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

Для начала, куда же без этого сейчас, это ИИ. Смотрите. 2 очень разных селектора. Но если в пайплайне (не в реальном времени, конечно) есть скилл привязки принятых данных к атрибутам OpenTelemetry Semantic Conventions, то сейчас он решает большую часть проблем с настройкой маппинга селекторов.

<На слайде появляется картинка с скриншотом работы скилла маппинга из одной конвенции в другую>

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

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

<На слайде появляется скриншот APM DataDog>

Мы делаем одну страницу со списком сервисов. Список мы достали из данных. Агрегированную информацию достали по замапленым селекторам. 

<На слайде повявляется скриншот дашборда конкретного сервиса APM DataDog>

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

<Снова появляется заголовочный слайд, но уже с надаписью "Нет, Вадим, нельзя, потому что нас заменит ИИ">

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

<Слайд с заголовком "Кормим LLM правильно">

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

<На слайде появляется первый пункт "Метрики">

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

<На слайде появляется второй пункт "логи">

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

<На слайде появляется третий пункт "зависимости">

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

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

<Слайд заголовок "ретроспектива">

Давайте попробуем кратко подбить итоги.

<Слайд с заголовком "Что будет в ближайшие пол часа" и всеми пунктами>

Что я надеюсь сегодня останется с нами. 
1. Надежность это функция от инцидентов, спасибо, капитан.
2. Надежность это функция от observability. 
3. Как на основе статистики инцидентов выбирать, какие фичи в observability делать следующими
4. Взгляд на то, как пользователь взаимодействует с платформой и попытка сделать из комбайна готовый сервис. Эдакую надстройку над IDP
5. Ну и про ИИ поговорили, хотя про это можно и отдельный доклад делать.


---

---

---

# Дополнительные атериалы

* Презентация с выступления на DUMP, основной источник данных для текущего доклада ~/Downloads/Мартынов.pptx
* Ранний эскиз текущей презентации и доклада, может использоваться только как дополнительный источник вдохновения ~/Downloads/devoops-observability.pptx

# Дополнительное задание

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