Latest posts
Путь SRE
17 Sept, 10:48
Четыре алерта почти подряд. Один сервис отдаёт 500, latency поползла вверх, в чате уже спрашивают, что происходит. 😰 Что делаете первым?У нас как раз есть симулятор такого инцидента. Вы проходите его за дежурного SRE и принимаете решения по ходу ситуации.В конце сможете сверить свой подход с SRE-логикой и посмотреть, какие навыки стоит прокачать дальше.Если летом пропустили, то советую пройти. Минут 15, и почти наверняка где-то захочется выбрать свой вариант)Забрать симулятор здесь 🙂
Путь SRE
7 Sept, 10:14
В сентябре у нас стартует SRE-интенсив. Да, сегодня прямо рекламный пост 🙂21 сентября у Слёрма стартует 7-дневный интенсив по SRE. На нём за неделю соберёте для своего сервиса SRE-пакет: ✔️ SLI и SLO ✔️ error budget ✔️ сигналы мониторинга ✔️ план первых действий при инциденте ✔️ mini-postmortem ✔️ roadmap того, что улучшать дальшеТо есть на выходе остаётся не просто набор терминов, а понятная схема работы с надёжностью конкретного вашего сервиса.Разбирать всё это будем вместе с моим коллегой Максимом Гусевым, руководителем команды SRE в RWB. Он больше 11 лет занимается отказоустойчивыми системами, был SRE-техлидом в финтехе и руководил Observability
Путь SRE
4 Sept, 15:08
Давайте сегодня не мы вам кейс, а вы нам 🙂Наверняка у каждого, кто дежурил или настраивал мониторинг, был тот самый алерт. Он стабильно прилетает (часто ночью), все знают о его существовании, но каждый раз начинается немой диалог: «Так, и что мне теперь с этим делать?» Это может быть классический CPU > 80%, сообщение без контекста и ссылок на ранбук, алерт на технический симптом, который ни на что не влияет, или уведомление, которое срабатывает ложно настолько часто, что его просто заглушили в Slack/Telegram.Хотим разобрать один такой пример вместе. Принесите в комментарии самый бесячий алерт из своей практики (компания и сервис нам не нужны, всё чувствительное можно убрать или заменить): 1. Что примерно написано в алерте? 2. Что вы обычно делаете, когда он прилетает? 3. Почему хочется его выключить, переписать или забыть как страшный сон?Можно
Путь SRE
2 Sept, 15:08
Итак, backend отвечал 200 OK. А оплатить всё равно было нельзя.Закрываем нашу смоделированную историю. Проблема здесь даже не в том, что кто-то посмотрел «не на тот график». Дашборд честно отвечал на вопрос, который ему задали: сервис технически отвечает? Да. Только пользователь приходил за другим — ему нужно было закончить покупку.И вот тут полезно посмотреть на свой мониторинг со стороны: 1. Какое действие пользователя для сервиса действительно критично? 2. Увидим ли мы, если именно оно начнёт ломаться только у части людей? (Например, в одном регионе, на одном endpoint или в конкретном сценарии, пока общие графики остаются зелёными). 3. Узнаем ли мы о проблеме раньше поддержки? Если первым настоящим алертом становится сообщение пользователя «у вас ничего не работает», значит, в наблюдаемости есть слепая зона. 4. Когда сигнал приходит, понятно ли инженеру, что с ним делать? Сам по
Путь SRE
31 Aug, 08:11
Путь SRE
31 Aug, 08:09
В прошлый раз дашборд говорил, что всё хорошо, а пользователи были другого мнения.Докидываем данные: Жалобы идут не от всех. Проблема возникает только у части пользователей, которые доходят до оплаты через один конкретный сценарий. Разрезаем общие метрики, и картина становится интереснее: • У основного API по-прежнему всё зелёное. • 5xx почти нет. • Latency не уехала.Но в проблемном пользовательском пути резко просела доля успешных транзакций. Почему этого не было видно сразу?Потому что backend в этих случаях технически отвечает нормально. Запрос обработан, HTTP 200 вернулся (например, с ошибкой внутри тела ответа). Но нужного пользователю результата не случилось.Итак, сервис технически доступен, а воспользоваться им нельзя. В следующем посте закроем кейс и отдельно посмотрим, что здесь вообще стоило мониторить, чтобы не ждать сообщений от пользователей.
Путь SRE
28 Aug, 10:11
Путь SRE
28 Aug, 10:05
Дашборд зелёный. Пользователи говорят, что сервис не работает. Кому верим?Давайте немного поиграем в on-call. Ситуация смоделированная, но вполне жизненная. В поддержку начинают приходить жалобы: часть пользователей не может завершить покупку.Открываем основной дашборд: • HTTP 5xx — без аномалий. • p95 latency (время ответа) — в привычных значениях. • CPU и память — в норме. • Свежих релизов тоже не было.На первый взгляд всё прекрасно. Кроме маленькой детали: пользователи продолжают писать 🙂 Выбирайте, что сделали бы первым, имея только эти данные. В следующем посте принесём ещё немного фактуры — посмотрим, останется ли ваша версия прежней 👇
Путь SRE
25 Aug, 15:26
27 августа MTS Web Services собирает DevOps- и SRE-инженеров на офлайн-встречу в Москве. И я там тоже буду 😉Так что если давно хотелось выбраться из чатов и дашбордов в реальный мир, вот хороший повод.В программе вечера: ️⃣ мастер-класс по мониторингу ИИ-приложений «Смотри, как думает агент» от платформы MWS RelyOps ️⃣ «Как создать свой приватный enterprise-каталог операторов в закрытом сегменте» от Orion soft ️⃣ опыт внедрения ИИ-агента, который сам решает тикеты техподдержки, от SRE-лида MWS ️⃣«Оптимистичный прогноз о навыках инженера в эпоху AI-native» от платформы MWS DevRails AI Можно прийти офлайн в Москве или подключиться к трансляции.Я буду ведущим, так что если тоже придёте — подходите знакомиться
Путь SRE
25 Aug, 07:50
19:07. Падает один сетевой контроллер. Сервисы зарезервированы. Вроде ничего страшного?Примерно через час в Yandex Cloud уже каскадом отказывают узлы внешней связности. В какой-то момент проблемы одновременно затрагивают две зоны доступности. Как из одного отказа получился большой региональный инцидент?Мне здесь понравился один момент: довольно быстро проблема перестала быть только про сломанный контроллер. Система начала сама добавлять себе работы. После сбоя запустились миграции части виртуальных машин. Сам по себе механизм нормальный, для этого он и существует. Но в условиях аварии миграции создавали дополнительные служебные запросы. Пользовательский трафик не вырос, а внутренней нагрузки стало в разы больше.И это был только один слой. По сути, контроллер дал первый толчок, а дальше несколько факторов неудачно совпали и начали усиливать друг друга.В ретроспективе Яндекса для
Путь SRE pinned a photo
19 Aug, 10:41
Путь SRE
19 Aug, 10:15edited
Впервые в «Пути SRE»? Начните отсюда 👇Здесь мы разбираем SRE через то, с чем инженеры реально сталкиваются в production: инциденты, SLO, observability, алерты, postmortem, on-call и ситуации, где «сделали по best practice» ещё не означает «сделали хорошо».🐻 Если пока разбираетесь в базе → вот с чего можно начать: что важнее, SLA или SLO и зачем вообще нужны оба🙂 Если хочется чего-нибудь побоевее → ночная задача про БД: сервис тормозит именно тогда, когда нагрузка почти исчезает🤨А здесь можно проверить свою гипотезу → разбор задачи🐸 Хотите ещё одну → куда исчезли логи между Fluentd и Elasticsearch?😁 А вообще тут собрали хороший мясной дайджест за май-июнь: от метастабильных сбоев и высокой нагрузки до тихих
Путь SRE
17 Aug, 14:05
Путь SRE
17 Aug, 14:05
Давайте сверим координаты. В Пути SRE собрались люди с очень разным бэкграундом: кто-то только разбирается, где заканчивается DevOps и начинается SRE, а кто-то уже просыпался ночью от алертов и потом писал postmortem.Хотим сделать следующие месяцы канала ещё более практическими: больше инцидентов, инженерных задач, SLO, observability, on-call и разборов того, почему привычная SRE-практика иногда вообще не работает.Поэтому для начала интересно понять, кто сейчас по эту сторону экрана. Голосуйте ниже. А в комментариях можно добавить роль и одну reliability-задачу, которая сейчас больше всего бесит на работе 🙂Итак, а теперь к главному вопросу...
Путь SRE
6 Aug, 08:31
Друзья, всем привет 👋🏻 Сможете решить задачку?⬇️02:17. Pager разрывается. Продакшн падает. А вы — дежурный SRE.Успеете среагировать за 15 минут?Слёрм подготовил интерактивный симулятор реального инцидента: API отвечает 500-й ошибкой, задержка растёт, разработчики спят, а бизнес уже требует ответов.Вам предстоит принять 5 решений — ровно так, как это делают дежурные инженеры в проде: ⏩ что проверить первым ⏩ какую метрику считать критичной ⏩ когда объявлять инцидент ⏩ что написать пользователям ⏩ что делать после того, как всё починили❗️Никакой теории — только реальная ситуация и разбор каждого шага сразу после ответа. В конце узнаете, насколько ваш
Путь SRE
22 Jul, 14:10
Друзья, всем привет 👋🏻Слёрм запускает Интенсив по SRE⚡️За 7 учебных дней разберёте: ➡️как SRE измеряет надёжность — SLI/SLO и error budget не на словах, а на цифрах ➡️как работать с инцидентами так, чтобы фиксить систему, а не искать виноватого дежурного ➡️как системно улучшать сервисы, а не тушить одни и те же пожары по кругуНа выходе два реальных артефакта: 🔹SRE-пакет по вашему собственному, знакомому сервису 🔹личный roadmap внедрения SRE-практик на ближайшие 3 месяца✅Формат лёгкий: Telegram-чат, ~ 3 часов в день, из инструментов нужен только браузер.✅Автор — Максим Гусев, руководитель SRE в RWB, 11+ лет в отказоустойчивых системах.Если бы я
Путь SRE
18 May, 08:25
Введение в ИИ: от LLM и MCP до ИИ-агентовПривет всем! Приходите сегодня в 19:00 на вебинар по ИИ. Эксперты обсудят:🔸 как работает LLM; 🔸 полезные приемы написания запросов для ИИ на выполнение задачи (промптов); 🔸 как работать с внутренними данными с помощью ИИ-агентов; 🔸 что такое MCP и зачем это нужно; 🔸 как создать своего первого ИИ-агента.Вы скорее всего слышали про сертификацию CKAD (Certified Kubernetes Application Developer). Обычно на этот экзамен выделяют 120 минут и 18 задач. На вебинаре эксперты проведут демо, как решить все задания буквально за пару минут с помощью ИИ.👥 Спикеры вебинара — эксперты курса «ИИ в работе DevOps-инженера»:— София Филиппова, AI engineer at Innova. — Виктор Ведмич, Senior
1,610Open in TelegramПуть SRE
5 Apr, 16:03
forwarded from @slurmnews
Я вроде что-то знаю, но цельной картины нет 🧩Мы знаем, что путь в управление надежностью (SRE) может быть непростым — нужно разбираться и в коде, и в железе, и в процессах, и даже в психологии. Становится особенно трудно, когда не понимаешь, что от тебя требуется и с чего начать.Если вы готовы реально потрудиться, чтобы сделать большой шаг в направлении SRE, то приходите на обучение.📌 Старт уже завтра — 6 апреля!Вы получите:— Не гугловскую теорию, а рабочий опыт инженеров из российских компаний. — Не фантазийные задания, а практику в условиях, максимально имитирующих реальность SRE-инженера. — Не фрагментарные знания, а целый набор необходимых скиллов для того, чтобы развиваться в SRE.🔥 Набор в группу закроется на днях. Изучите программу и оставляйте заявку — ТУТ 👈🏻
Путь SRE
6 Mar, 17:13
➡️Время безотказной работы (Uptime, не по-нашенски).Друзья, всем привет! Сегодня погорим о почти бесполезной метрики надёжности: uptime. Инженеры любят говорить, что соглашение об уровне сервиса (SLA)= 99.99. Но это число почти ничего не говорит о реальной надёжности системы, потому что uptime не связан с пользовательским опытом и бизнес-результатом.Простой пример: 99.99% доступности = примерно 52 минуты простоя в год.⚡️Но важны не минуты, а контекст этих минут: • Это 52 минуты ночью или в пик трафика? • Сломался критический путь или второстепенная функция? • Затронуто 1% пользователей или 100%? Одинаковый uptime может означать радикально разные последствия.Инженеры по надежности (SRE) вообще почти не используют uptime, потому что это сервисная, а не ориентрованная на пользователя метрика. Она не отвечает наПуть SRE
2 Mar, 16:14
Красные флаги на собеседованиях 🚩Друзья, всем привет! Сегодня хочу поговорить про фразы, которые не стоит использовать на собесах, чтобы не поймать мгновенный отказ. Начнем с самой явной: ▶️Люблю, когда всё горит, инциденты бодрят, иначе скучно Такое высказывание почти всегда значит, что человек не различает хаос и управляемую надёжность. Он не хочет строить системы так, чтобы они реже падали, ему интересен адреналин и тушение пожаров. Такой кандидат с высокой вероятностью будет саботировать работу над техдолгом, автоматизацией и профилактикой, ведь тогда ему станет скучно.Идем дальше ▶️Если что-то падает — я просто иду и руками чиню Сигнал, что нет мышления в терминах процессов, автоматизации, SLO и устойчивости.▶️Документацию писать не люблю, я же не техпис SRE без передачи знаний
Related Channels
Other channels in the same section of the catalogue.
