Вы знали, что необязательно читать талмуд книг в Google, чтобы постичь основные концепции SRE?

Компании наконец-то догадались, что стабильный продукт — это неплохо. (Вот это поворот 😉)
Каждая минута простоя стоит как крыло от Боинга, поэтому все начали дружно «делать надёжность». И, конечно же, делать её правильно — по канону SRE. Ведь где SRE, там аптайм в стиле 99.999999999%.

Книги у Google по теме есть. Но давайте честно: кто их реально читал? Я вот осилил целиком одну, остальные — кусочками.

Что обычно вспоминают, когда речь заходит про SRE? Ну, SLI/SLO/SLA (куда без них), «actionable alerts» (чтобы не будили зря в 3 ночи) и ещё пару модных слов. В теории всё просто: знай определяй SLA, делай правильные алерты, а неправильные — не делай. В реальности всё куда сложнее 🐈

🟠 Но тут нам на выручку пришли добрые люди и сделали выжимку главных идей из гугловских книг в формате микро-уроков. Так что, если хотите быстро получить цельное представление о SRE (google edition, конечно же) и сэкономить кучу времени, добро пожаловать сюда ➡️ https://sre.in100.dev

До сих пор думаете, что SRE это только SLA и ничего больше?

Да-да, я постоянно сталкиваюсь с мнением, что SRE полезен только тогда, когда случился алерт 🙄
Надо ли говорить, что такое мнение, меня, мягко сказать, фрустрирует? 😅

Потому что в реальности можно придумать квантиллион задач! Пройдёмся по примерному списку того, чем SRE обязан заниматься на любом проекте. Естественно, в каждой компании функции будут адаптированы под цели проекта. Но база примерно одна⬇️

🟠 Построение надёжной архитектуры
Сюда входит всё: начиная от настройки правильных таймаутов/ретраев в сервисах, чтобы не создать retry storm, заканчивая применением подходов chaos engineering и проведением учений по отказу ДЦ.

🟠 Инцидент-менеджмент
Тут правильная реакция на алерты, эскалации при необходимости, ведение инцидентов с разделением ролей (incident manager, communication lead, scribe, etc.) и многое другое.

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

🟠 Наблюдаемость aka observability, она же телеметрия
Это не только метрики, логи и трейсы. Мало просто генерировать сигналы работы системы, нужно их правильно использовать, строить на их основе actionable alerts, которые ещё будут и нешумными и не будить ночью.

🟠 Автоматизация
Любые ручные действия в любой части системы, будь то сложный процесс деплоя с ручной правкой конфигов либо элементарные quality gates, которые работают на основе human review, а не на основе линтеров. Нет линтера, подходящего для твоего кейса — напиши, что ж не как SRE-то, вручную проверяешь на ошибки IaC код?

🟠 Capacity planning
Посчитать нагрузки, оценить стоимость инфраструктуры, заложить ресурсы под пиковые нагрузки.

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

🟠 Обучение/менторство
Проведение воркшопов, q&a сессий и прочих форматов передачи знаний. Даже если кажется, что тема «как правильно строить алерты» очевидна, всегда найдётся, кому это будет полезно. И, конечно же, написание документации.

🟠 Управление рисками
Да, неплохо бы понимать, насколько надёжны все те вендоры, что вы используете, для вашего бизнеса, и какие у них SLA. И речь не только про облака, а вообще про любые решения, даже если они деплоятся в вашу инфраструктуру, но обслуживаются снаружи.

🟠 Архитектурные комитеты
Любые значимые изменения в инфраструктуре, сервисах, продукте, должны проходить через такой комитет, куда собираются, в зависимости от характера изменений, люди из разных подразделений (например, из команд service mesh и dbaas). И цель этого не соблюдение бюрократии, а получение фидбека на предлагаемое решение и подсвечивание возможных рисков. Потому что невозможно знать всё, и может случиться так, что решение нужно пилить совсем по-другому, иначе прод развалится через квартал под нагрузкой.

🟠 Определение SLI, SLO, SLA
Добрались и до них)) И до построения поверх них actionable alerts, желательно на основе multi window, multi burn rate alerts. Подробнее об этом тут.

Помимо определения SLA существует ещё огромное количество крайне нетривиальных задач, и SRE должен уметь с ними справляться.

А что добавили бы вы? Или, может, с чем-то не согласны?

Зачем бизнесу и командам DevSecOps?

На следующей неделе состоится бесплатный вебинар, на котором вы соберёте картинку взаимодействия Dev, Sec и Ops и выясните, почему DevSecOps в проекте — это необходимость, а не дань моде.

Спикеры последовательно, от принципов к практике, разберут, как:
🟣интегрировать сканеры в CI/CD так, чтобы они не мешали;
🟣разрулить конфликт между Dev, Ops и Sec раз и навсегда;
🟣 масштабировать безопасность без увеличения команды;
🟣 получать бюджет на безопасность у бизнеса без запугивания;

📅 Когда: 25 сентября, в 19:00 мск.

Спикеры:
▶️ Андрей Сухоруков, Team Lead DevOps/SRE/DevSecOps Лаборатория Касперского
▶️ Мария Шеховцова, руководитель группы архитектуры и анализа, Positive Technologies
▶️ Артём Пузанков, руководитель группы внедрения практик безопасной разработки, Positive Technologies

➡️ Получить напоминания и ссылки на подключение — в боте.

Как мониторить сложные пайплайны

Думаю, вы встречались с задачей: надо получить алерт, когда сервис начнет 500-тить. Или когда latency вырастет за пределы 500 мс.

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

Вернёмся к тому, как следить за сложными пайплайнами.

➡️ Простое решение — алерты на длину очереди. Работает в простых ситуациях, но фиксированный threshold — неудобно и может алертить даже тогда, когда проблем нет.

➡️ А что лучше?
Мониторить то, что действительно важно — сколько времени данные проводят в пайплайне. Сравниваешь метку времени инджеста пачки данных в начало и когда они вышли в конце — вот и время обработки. Если данные идут непрерывным потоком, этого достаточно. Если же бывают паузы, добавляешь heartbeat сообщения, чтобы заполнить очередь (код пайплайнов должен уметь правильно обработать, а это ой как нетривиально добавить, если заранее об этом не подумать). Ещё это можно назвать синтетическим тестом, который проверяет, что вся инфраструктура пайплайна в целом как-то работает.

А что если процессинг реально долгий? Был тормоз на входе — алерт прилетит сильно позже, когда сообщение доедет до конца пайплайна. И тут возвращаемся уже к загруженности очередей. Но не просто к больше чем 100500 сообщений в очереди, а в условиях, если она растёт! В PromQL это что-то типа deriv(my_awesome_kafka_queue_size[30m]) > 0 — то есть производная от скорости роста длины очереди.

🐈 Чувак, а где же здесь про кубер?
😏 А ничо тот факт, что сейчас пайплайны крутятся в кубере?) Да ещё и с автоскейлингом, как мы любим, чтобы экономить средства, изображая finops.

#kubнапальцах

Сколько реально нужно времени, чтобы найти нормальное место работы?

И закинул старик невод в море и стал ждать…
Мне вот интересно, сколько вы искали своё место работы? В последние годы рынок изменился, давайте пройдёмся по самому длинному ожиданию в период, скажем, после 2023г⬇️

Мой рекорд — 3 месяца с момента первого контакта с рекрутером. Да, добиться общения с живым человеком не так просто. А дальше — оффер, документы, релокация, но это уже другая история.

В целом, считаю норм в текущих условиях. Но любимый мем на эту тему у меня успел появиться⬆️

А что из relatable мемов про IT есть у вас? Кидайте в комментарии ⬇️

Признайтесь, вы тоже приукрашиваете своё резюме?

За свою карьеру я провёл больше сотни собеседований. Бэкендеры, фронтендеры, девопсы — чего я только не видел. И знаете, что меня всегда удивляет?

Нет, не когда человек не знает какой-то алгоритм с LeetCode. Это как раз норма. Удивляет, когда резюме выглядит как мечта, а в реальности — просто набор слов, который мало соотносится с соискателем.

Помню, как-то собеседовал кандидата. У него в резюме — 4 года опыта с PostgreSQL. Я не спрашиваю про индексы B-tree, не пытаю про тонкости MVCC. Я просто спрашиваю: «А когда PostgreSQL ломается?». И тут наступает неловкое молчание. Лицо собеседника меняется, а у меня в голове: «4 года и ни разу ничего не пошло не так?». Извини, но не верю.

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

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

Поэтому я не верю, что человек работал с инструментом 4 года, но ни разу не сталкивался с трудностями. К приукрашиванию резюме тоже нужно подходить с умом.

🐈 Котятки, давайте как на духу — ваше резюме на 100% честное? Или пара пунктов всё же выглядит более внушительно, чем есть на самом деле?