Вчера в первый раз был ведущим подкаста 😁
PODCAST++ - для инженеров, которые хотят понимать других от инженеров.
Моим гостем стал Владимир Утратенко, BDM в Лаборатория Числитель. Ранее CTO, DevOps Evangelist, соорганизатор сообщества DevOps Moscow.
Поговорили про DevOps, производство софта, инженеров в эпоху ИИ, и как "Штурвал" помогает большим компаниям.
Мне привычнее на стороне отвечающего, а это было новое в диковинку. Сложно. Как часто бывает с новым.
Производство и обработки записи займет еще некоторое время 🕘
Как выложим - обязательно услышимся 🔉! Жду вместе с вами.
#подкаст #devops #ведущий_подкаста
PODCAST++ - для инженеров, которые хотят понимать других от инженеров.
Моим гостем стал Владимир Утратенко, BDM в Лаборатория Числитель. Ранее CTO, DevOps Evangelist, соорганизатор сообщества DevOps Moscow.
Поговорили про DevOps, производство софта, инженеров в эпоху ИИ, и как "Штурвал" помогает большим компаниям.
Мне привычнее на стороне отвечающего, а это было новое в диковинку. Сложно. Как часто бывает с новым.
Производство и обработки записи займет еще некоторое время 🕘
Как выложим - обязательно услышимся 🔉! Жду вместе с вами.
#подкаст #devops #ведущий_подкаста
🔥5❤🔥3👍3
Макс тут перевел статью, где объясняют разницу и общность инженеров DevOps, SRE, Cloud, Platform. Не могу не поделиться
https://t.me/youngmaxnotes/101
#sre #статья #перевод #различия #devops
https://t.me/youngmaxnotes/101
#sre #статья #перевод #различия #devops
Telegram
A young Max’s notebook
Очень часто слышу споры и вопросы - а в чем разница между SRE/DevOps/Cloud Engineer/Platform Engineer?
Нашел тут статью на эту тему, которая мне очень понравилась, перевел ее для вас, оригинал по ссылке в конце :)
В современном мире технологий границы между…
Нашел тут статью на эту тему, которая мне очень понравилась, перевел ее для вас, оригинал по ссылке в конце :)
В современном мире технологий границы между…
❤🔥4
🙀 Что на самом деле имел в виду Google под «SRE implements DevOps»?
Из книги Google SRE:
Это не значит, что
Как мы знаем из программирования, у одного абстрактного класса может быть множество реализаций — и каждая решает общую задачу своим способом. При этом реализация ≠ наследование.
DevOps — это философия: культура, автоматизация, измеримость, совместная ответственность.
SRE — это конкретная роль, которая реализует эту философию через инженерные практики:
- SLO/SLI как договор о надёжности,
- автоматизация рутины (toil reduction),
- управление рисками через бюджет ошибок,
- отказ от «100% uptime» в пользу баланса скорости и стабильности.
SRE не заменяет DevOps — он инструмент для его воплощения.
🤌🏼 А что с SR-инженерами? 🔭⚙️
Мы кто? Мы реализация или наследование от DevOps инженера? Тут также
Поэтому я считаю, что
Для меня #SRE — это инженер с T-образной экспертизой:
- горизонталь — общее понимание стека (от сети до бизнес-логики),
- вертикаль — глубокая специализация в одной области (экспертиза).
В Google, например:
- Один SRE может быть экспертом по распределённым системам,
- Другой — по масштабируемой автоматизации,
- Третий — по надёжности ML-пайплайнов.
Никто не ожидает, что один SRE будет знать всё на уровне DevOps + DBA + Security + Network Engineer.
Ожидается, что он умеет диагностировать и координировать, а не заменять.
Замечу, что в маленькой компании или стартапе с 5-10 микросервисами и небольшим набором технологий ты еще можешь "закрыть все сам" (скорее всего ты разработчик или даже cto в роли sre) - щупалец хватит, но с ростом компании — у тебя щупалец не добавится.
В моём случае "вертикаль" — это observability и #SLO. Я не заменяю #DevOps или DBA, но умею диагностировать инцидент, сформулировать гипотезу и привлечь нужного эксперта — и именно в этом, на мой взгляд, суть надёжности как инженерной дисциплины. Инженерное мышление + системное видение, а не универсальная экспертиза.
🐳 А что думаете вы?
Из книги Google SRE:
"SRE is what happens when you ask a software engineer to design an operations function."
"SRE is one implementation of DevOps."
Это не значит, что
SRE = DevOps × 2.Как мы знаем из программирования, у одного абстрактного класса может быть множество реализаций — и каждая решает общую задачу своим способом. При этом реализация ≠ наследование.
DevOps — это философия: культура, автоматизация, измеримость, совместная ответственность.
SRE — это конкретная роль, которая реализует эту философию через инженерные практики:
- SLO/SLI как договор о надёжности,
- автоматизация рутины (toil reduction),
- управление рисками через бюджет ошибок,
- отказ от «100% uptime» в пользу баланса скорости и стабильности.
SRE не заменяет DevOps — он инструмент для его воплощения.
🤌🏼 А что с SR-инженерами? 🔭⚙️
Мы кто? Мы реализация или наследование от DevOps инженера? Тут также
реализация ≠ наследование. Поэтому я считаю, что
SRE != "DevOps на стероидах". SRE может вырасти хоть из инженера поддержки первой линии. Лично я — реализация из backend-разработчика.Для меня #SRE — это инженер с T-образной экспертизой:
- горизонталь — общее понимание стека (от сети до бизнес-логики),
- вертикаль — глубокая специализация в одной области (экспертиза).
В Google, например:
- Один SRE может быть экспертом по распределённым системам,
- Другой — по масштабируемой автоматизации,
- Третий — по надёжности ML-пайплайнов.
Никто не ожидает, что один SRE будет знать всё на уровне DevOps + DBA + Security + Network Engineer.
Ожидается, что он умеет диагностировать и координировать, а не заменять.
Замечу, что в маленькой компании или стартапе с 5-10 микросервисами и небольшим набором технологий ты еще можешь "закрыть все сам" (скорее всего ты разработчик или даже cto в роли sre) - щупалец хватит, но с ростом компании — у тебя щупалец не добавится.
В моём случае "вертикаль" — это observability и #SLO. Я не заменяю #DevOps или DBA, но умею диагностировать инцидент, сформулировать гипотезу и привлечь нужного эксперта — и именно в этом, на мой взгляд, суть надёжности как инженерной дисциплины. Инженерное мышление + системное видение, а не универсальная экспертиза.
🐳 А что думаете вы?
👍7
Michel The Bear с коллегами тут похоливарили "в SREду на кухне" про мониторинг и всё что с ним связано.
Приглашаю сравнить вашу точку зрения с коллегами 😉
Аудио https://music.yandex.ru/track/147188042
Видео
https://vkvideo.ru/video-152990965_456240051
https://youtu.be/WyT9ni4mGtU
#мониторинг #observability #devops #sre #подкаст
Приглашаю сравнить вашу точку зрения с коллегами 😉
Аудио https://music.yandex.ru/track/147188042
Видео
https://vkvideo.ru/video-152990965_456240051
https://youtu.be/WyT9ni4mGtU
#мониторинг #observability #devops #sre #подкаст
🔥2
Проверка инфраструктуры кодом - иногда и двух пар глаз 👀👀 недостаточно
Бывало у вас так: два инженера посмотрели в пулл-реквест, кивнули, мерджнули, а потом - бац!
Инцидент из-за кривой настройки безопасности или ресурса, улетевшего в продакшн без лимитов?
У нас бывало. И это не вопрос компетенции. Это вопрос того, что человек просто не может держать в голове все 750+ правил безопасной конфигурации.
Тут на помощь приходят инструменты статического анализа для Infrastructure as Code (IaC). Например, попался мне на глаза Checkov - https://www.checkov.io/
Что умеет:
- сканирует Terraform, CloudFormation, ARM, Helm, Kubernetes, Dockerfile и Serverless Framework
- проверяет на 750+ предустановленных политик - от открытых портов до отсутствия шифрования
- позволяет писать свои политики, если у вас специфичные требования
- интегрируется в CI/CD, чтобы ловить проблемы до мерджа
Почему это важно для SRE и DevOps:
- снижает когнитивную нагрузку на ревьюверов
- формализует знания о лучших практиках
- превращает "мы так не делаем" в автоматический чек
- дает артефакт для аудита и постмортема
Альтернативы, которые тоже стоит посмотреть:
- tfsec - легковесный, фокус на Terraform
- Terrascan - поддерживает несколько провайдеров, хорош для политик как код
- KICS от Checkmarx - открытый, с акцентом на безопасность
Внедряешь такую проверку в пайплайн - и количество "а мы не заметили" в ревью падает.
Конечно, инструмент не заменяет инженера, но страхует от банальных промахов.
А вы используете статический анализ для IaC? Какой инструмент выбрали и почему? Сталкивались с инцидентами, которые можно было предотвратить автоматической проверкой?
#SRE #IaC #SAST #Security #DevSecOps #DevOps
Бывало у вас так: два инженера посмотрели в пулл-реквест, кивнули, мерджнули, а потом - бац!
Инцидент из-за кривой настройки безопасности или ресурса, улетевшего в продакшн без лимитов?
У нас бывало. И это не вопрос компетенции. Это вопрос того, что человек просто не может держать в голове все 750+ правил безопасной конфигурации.
Тут на помощь приходят инструменты статического анализа для Infrastructure as Code (IaC). Например, попался мне на глаза Checkov - https://www.checkov.io/
Что умеет:
- сканирует Terraform, CloudFormation, ARM, Helm, Kubernetes, Dockerfile и Serverless Framework
- проверяет на 750+ предустановленных политик - от открытых портов до отсутствия шифрования
- позволяет писать свои политики, если у вас специфичные требования
- интегрируется в CI/CD, чтобы ловить проблемы до мерджа
Почему это важно для SRE и DevOps:
- снижает когнитивную нагрузку на ревьюверов
- формализует знания о лучших практиках
- превращает "мы так не делаем" в автоматический чек
- дает артефакт для аудита и постмортема
Альтернативы, которые тоже стоит посмотреть:
- tfsec - легковесный, фокус на Terraform
- Terrascan - поддерживает несколько провайдеров, хорош для политик как код
- KICS от Checkmarx - открытый, с акцентом на безопасность
Внедряешь такую проверку в пайплайн - и количество "а мы не заметили" в ревью падает.
Конечно, инструмент не заменяет инженера, но страхует от банальных промахов.
А вы используете статический анализ для IaC? Какой инструмент выбрали и почему? Сталкивались с инцидентами, которые можно было предотвратить автоматической проверкой?
#SRE #IaC #SAST #Security #DevSecOps #DevOps
www.checkov.io
Prevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.
Готовлюсь к докладу на DevOpsConf, пробовал рассказать первый раз - и мне не понравилось. Пришлось даже в презентации перестановки сделать.
Но я забыл в этот раз слушателя-дельфинчика посадить, может потому так и вышло. Экрану просто рассказывать - мозг ленится 😂.
Корректор кстати уже проверила презентацию, и нашла мне с 2 десятка пунктов на исправление. Каждый раз это удивление, вроде бы читаешь и все понятно. Но когда другой показал , где и не очень понятно, то это сразу замечаешь. Я думаю, это потому что я не читаю же слайд буквально с экрана, а припоминаю, потому не текст слайда в памяти, а что сказать.
Спасибо корректору!
❓А для чего тебе идти на конференцию? Доклады послушать, поделать руками, нетворкинг, мерча собрать, работу прогулять?
#доклад #спикеру #конференции #devopsconf #devops #sre
Но я забыл в этот раз слушателя-дельфинчика посадить, может потому так и вышло. Экрану просто рассказывать - мозг ленится 😂.
Корректор кстати уже проверила презентацию, и нашла мне с 2 десятка пунктов на исправление. Каждый раз это удивление, вроде бы читаешь и все понятно. Но когда другой показал , где и не очень понятно, то это сразу замечаешь. Я думаю, это потому что я не читаю же слайд буквально с экрана, а припоминаю, потому не текст слайда в памяти, а что сказать.
Спасибо корректору!
P.s. в этот раз конференцию перестроили по формату, потому будет как эксперимент. Станет больше воркшопов и мастер-классов, чтобы унести опыт на пальцах.
❓А для чего тебе идти на конференцию? Доклады послушать, поделать руками, нетворкинг, мерча собрать, работу прогулять?
#доклад #спикеру #конференции #devopsconf #devops #sre
🔥4
Forwarded from Мишка на сервере (Mikhail Savin)
UUID v4 vs UUID v7 — почему это важно для SRE?
Привет,
Что под капотом?
UUID v4 — это 128 бит чистой случайности (122 значимых бита). Красиво, уникально, предсказуемо. Но абсолютно хаотично с точки зрения порядка.
UUID v7 — первые 48 бит это Unix timestamp в миллисекундах, остальное — случайность. Идентификаторы монотонно возрастают, то есть более новые UUID всегда лексикографически больше старых.
Почему это критично для нас с тобой?
Проблема UUID v4 — это то, что происходит с B-tree индексом в твоей БД при вставке:
- Каждый новый UUID случаен → вставки идут в произвольные места индекса;
- Это вызывает page splits (расщепление страниц) и write amplification;
- Фрагментация листовых страниц индекса у v4 достигает ~50%, тогда как у v7 — около 0%;
- Бенчмарки показывают: вставка с UUID v7 до ~34.8% быстрее, чем с v4 на 10 млн строк;
- Запросы (point lookup и range scan) у v7 быстрее за счёт лучшей локальности индекса.
SRE-профит от перехода на v7
-
- При разборе инцидента UUID в логах сразу показывает временной порядок событий — экономит время в постмортеме;
- Меньше фрагментации → меньше нагрузка на autovacuum в PostgreSQL → меньше сюрпризов в VACUUM-графиках;
- Снижается write amplification → меньше нагрузка на диск, особенно актуально для облачных managed БД с billing per I/O.
Когда v4 всё ещё ок?
- Токены сессий, CSRF-токены — там сортировка не нужна, максимальная случайность важнее;
- Системы, где раскрытие временнОго паттерна нежелательно по соображениям безопасности.
Переход с v4 на v7 в новых сервисах — это практически бесплатный перформанс буст. Библиотеки есть во всех основных языках, а PostgreSQL 18 получит нативную поддержку
Делись в комментариях — используешь ли уже UUID v7 в своих системах? Сталкивался ли с фрагментацией индексов из-за v4 в проде? Как решал — автовакуум, партиционирование, или всё-таки миграция на v7?
#SRE #DevOps #Database #PostgreSQL #UUID #Performance #IndexOptimization #BackendEngineering
Привет,
%username%! Сегодня поговорим о вещи, которая на первый взгляд кажется мелкой деталью — выборе версии UUID. Но если ты работаешь с высоконагруженными системами, эта "мелочь" влияет на производительность БД, I/O и даже на читаемость логов во время инцидентов.Что под капотом?
UUID v4 — это 128 бит чистой случайности (122 значимых бита). Красиво, уникально, предсказуемо. Но абсолютно хаотично с точки зрения порядка.
UUID v7 — первые 48 бит это Unix timestamp в миллисекундах, остальное — случайность. Идентификаторы монотонно возрастают, то есть более новые UUID всегда лексикографически больше старых.
Почему это критично для нас с тобой?
Проблема UUID v4 — это то, что происходит с B-tree индексом в твоей БД при вставке:
- Каждый новый UUID случаен → вставки идут в произвольные места индекса;
- Это вызывает page splits (расщепление страниц) и write amplification;
- Фрагментация листовых страниц индекса у v4 достигает ~50%, тогда как у v7 — около 0%;
- Бенчмарки показывают: вставка с UUID v7 до ~34.8% быстрее, чем с v4 на 10 млн строк;
- Запросы (point lookup и range scan) у v7 быстрее за счёт лучшей локальности индекса.
SRE-профит от перехода на v7
-
ORDER BY created_at становится менее актуальным — можно сортировать прямо по PK;- При разборе инцидента UUID в логах сразу показывает временной порядок событий — экономит время в постмортеме;
- Меньше фрагментации → меньше нагрузка на autovacuum в PostgreSQL → меньше сюрпризов в VACUUM-графиках;
- Снижается write amplification → меньше нагрузка на диск, особенно актуально для облачных managed БД с billing per I/O.
Когда v4 всё ещё ок?
- Токены сессий, CSRF-токены — там сортировка не нужна, максимальная случайность важнее;
- Системы, где раскрытие временнОго паттерна нежелательно по соображениям безопасности.
Переход с v4 на v7 в новых сервисах — это практически бесплатный перформанс буст. Библиотеки есть во всех основных языках, а PostgreSQL 18 получит нативную поддержку
uuidv7() из коробки.Делись в комментариях — используешь ли уже UUID v7 в своих системах? Сталкивался ли с фрагментацией индексов из-за v4 в проде? Как решал — автовакуум, партиционирование, или всё-таки миграция на v7?
#SRE #DevOps #Database #PostgreSQL #UUID #Performance #IndexOptimization #BackendEngineering
👍4