Приветствую, Новенький! Рад, что вы завершили онбординг в нашей корпорации ACME. У меня для вас есть первый тикет. Это простая задача, всего два сторипоинта, но она позволит вам немного научиться тому, как взаимодействуют наши сервисы. Просто реализуйте SLO доступности нашего сервиса Foo. Вы ведь знаете, как реализуются SLO?

Думаю, нам стоит стремиться к четырём девяткам. Я уверен, что вы в курсе всех best practices нашей отрасли, поэтому не буду надоедать вам советами. Если нужно, внизу есть бумажная Google SRE Book. Мне кажется, это быстрая задача; сможете представить свой SLO к пятничному демо?

Наступает обычная скучная пятница

Спасибо за презентацию, Новенький, отличная работа! Здорово, что вы освоили наши метрики Prometheus, генерируемые сервисом Foo, но у меня есть пара вопросов. Ваш SLO показывает, что мы уже исчерпали наш бюджет ошибок, хотя в последнее время инцидентов не было. Может быть, что-то не так с расчётами? ... Так, сейчас... Ага, я вижу, в чём проблема! Коды ответов 4xx учитываются, как плохие события SLO. Это ерунда! Сервис Foo работает ровно так, как и должен. Если пользователи выполняют недопустимые запросы или ищут несуществующие ресурсы, то это не наша проблема и не показатель проблем Foo. Поэтому просто исключите эти запросы 4xx, после чего мы сможем добавить в ваш SLO алерты и закрыть тикет. Совещание закончено, увидимся на ретро через пять минут.

Постмортем инцидента утром во вторник

Понятно... Джон решил, что если установить ограничение частоты равной 0, то это, по сути, отключит фичу, но на самом деле любое значение, отличающееся от положительного целого означает, что использование фичи не ограничено. Я назначу Джону action item для изменения документации по конфигурации.

Но на самом деле больше всего мне хочется понять, почему мы узнали об этом только тогда, когда мне написала команда разработчиков Bar? Новенький, почему этого не перехватил ваш SLO? Сервис Foo не работал четыре часа! По моим расчётам, при частоте ошибок 100% SLO должен был сработать через пять секунд.

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

За полчаса до ухода домой в четверг

Привет, Новенький! Я как раз поговорил с проект-менеджером команды Bar. Похоже, у неё возникают проблемы с созданием объектов через наш веб-UI. Что-то связанное с тем, что фронтенд отправляет строку, а бэкенд ожидает объект, содержащий строку, поэтому возвращает 400. Я уже договорился с нашим фронтендером об исправлении UI, но ещё подумал: разве не должно это отражаться в нашем SLO? Знаю, я говорил, что нужно исключить коды ответов 4xx из статистики ошибок. Но если они поступают от нашего UI, то это другое дело, потому что за него отвечаем мы и он часть сервиса Foo. Можете ли вы изменить SLO так, чтобы он учитывал коды ответов 4xx как ошибки, если они поступают от нашего веб-UI? Чтобы определять, что запрос поступает от UI, можете использовать информацию заголовков, потому что мы всегда задаём нестандартные заголовки.

... Хм, это неприятно. Значит, поскольку теперь вы используете для вычисления SLO метрики балансировщика нагрузок, сложно будет создавать новые метрики на основании значений заголовков. Правильно я вас понял? Тем не менее, вряд ли это какая-то редкая проблема. В конце концов, мы не делаем ничего необычного с сервисом Foo, а значит, подобные трудности возникали у многих компаний. Наверно, в Интернете есть куча литературы по решению этой проблемы. Сможете представить своё решение к завтрашнему демо?

Наступает ещё одна унылая, безжизненная пятница

Ещё раз благодарю вас, Новенький, за это полезное демо. Кто бы мог подумать, что спустя неделю мы всё ещё будем говорить об этом SLO. Ха-ха-ха! Мне очень понравилось решение скомбинировать метрику подсчёта общего количества запросов из балансировщика нагрузок с нашей новой специализированной метрикой сервиса Foo. Очень инновационно. Сегодня же представлю его руководству.

Дождливое, не предвещающее ничего хорошего утро понедельника

Привет, Новенький. Послушайте, если эта задача оказалась для вас слишком сложной, нужно было попросить о помощи. В пятницу представил ваш SLO руководству, и оно заметило некоторые проблемы с вашим SLO. Вот, посмотрите! Это SLI второй половины для в пятницу, сразу после 13:00. По какой-то причине SLI немного падает. А потом повышается до 102%! Руководство должно поверить, что мы в команде Foo пишем волшебные приложения с доступностью выше 100%? Что это вообще может означать?! Я не специалист в SLO, но знаю, что доступность не может быть больше 100%.

... Нет. Я не хочу слышать никаких ваших оправданий о разном времени скрейпинга. Если результат иногда оказывается неправильным, то можем ли мы вообще ему доверять? Даже дети знают, что доступности на 102% быть не может.

Очевидно, у нас проблема. Задача признана стоящей два сторипоинта, прошло две недели, а мы всё ещё её обсуждаем. Это доказывает несоответствие между вашим уровнем навыков и тем, который мы ожидаем на вашей должности. Сегодня утром я поговорил с HR, сейчас у вас будет совещание с ним в кабинете 101. Ноутбук можете оставить здесь. Прощайте, Новенький.