Как гарантированно похоронить SRE в своей компании
На связи Алексей, читаю «Настоящий SRE» Бланк-Эдельмана. В книге разбирают, как SRE приживается в компаниях, и почему чаще всего не приживается. Сценарии, судя по всему, везде одни и те же. Вот вредные советы, что сделать, чтобы и у вас не прижился.
Самый быстрый способ — переименовать должности. Был «системный администратор», стал «SRE-инженер». Обязанности те же, культура та же, приоритеты те же. Через полгода организация разочаруется и скажет, что SRE не работает.
Второй вариант — превратить команду в службу поддержки третьего уровня. Все сложные тикеты, которые не смогли разобрать другие, летят к SRE-инженерам. Они разгребают, тушат пожары, ни на что другое времени не остаётся. Никаких петель обратной связи, никакого роста надёжности.
Третий вариант — дать команде роль привратника с правом блокировать любой деплой во имя надёжности. Звучит разумно, но на практике другие команды начинают искать способы обойти контроль, и в итоге проигрывают все.
Четвёртый — изолировать команду SRE, посадить их подальше от владельцев продукта. Когда чтобы обсудить приоритеты нужно подняться на несколько уровней иерархии, взаимодействие замедляется настолько, что SRE просто перестаёт влиять на то, что происходит.
Ещё один сценарий, который автор называет «смертью от успеха»: команда растёт, ей передают всё новые сервисы, а право говорить «нет» при этом никто не даёт. Инженеры тонут в операционке, выгорают и уходят.
Ну и классика — культура поиска виноватых. SRE как дисциплина держится на обучении из ошибок. Если за сбои наказывают, инженеры скрывают сигналы о проблемах, и учиться становится просто не на чем.
И отдельный антипаттерн, который выглядит невинно — скопировать практики Google один в один. Взять книжку, внедрить всё по инструкции, и получить результат, который не работает, потому что у вашей организации другая культура, другие ценности и другой контекст.
Все эти истории заканчиваются одинаково. SRE перестаёт быть инженерной дисциплиной и превращается в новое название для старых методов эксплуатации.
На связи Алексей, читаю «Настоящий SRE» Бланк-Эдельмана. В книге разбирают, как SRE приживается в компаниях, и почему чаще всего не приживается. Сценарии, судя по всему, везде одни и те же. Вот вредные советы, что сделать, чтобы и у вас не прижился.
Самый быстрый способ — переименовать должности. Был «системный администратор», стал «SRE-инженер». Обязанности те же, культура та же, приоритеты те же. Через полгода организация разочаруется и скажет, что SRE не работает.
Второй вариант — превратить команду в службу поддержки третьего уровня. Все сложные тикеты, которые не смогли разобрать другие, летят к SRE-инженерам. Они разгребают, тушат пожары, ни на что другое времени не остаётся. Никаких петель обратной связи, никакого роста надёжности.
Третий вариант — дать команде роль привратника с правом блокировать любой деплой во имя надёжности. Звучит разумно, но на практике другие команды начинают искать способы обойти контроль, и в итоге проигрывают все.
Четвёртый — изолировать команду SRE, посадить их подальше от владельцев продукта. Когда чтобы обсудить приоритеты нужно подняться на несколько уровней иерархии, взаимодействие замедляется настолько, что SRE просто перестаёт влиять на то, что происходит.
Ещё один сценарий, который автор называет «смертью от успеха»: команда растёт, ей передают всё новые сервисы, а право говорить «нет» при этом никто не даёт. Инженеры тонут в операционке, выгорают и уходят.
Ну и классика — культура поиска виноватых. SRE как дисциплина держится на обучении из ошибок. Если за сбои наказывают, инженеры скрывают сигналы о проблемах, и учиться становится просто не на чем.
И отдельный антипаттерн, который выглядит невинно — скопировать практики Google один в один. Взять книжку, внедрить всё по инструкции, и получить результат, который не работает, потому что у вашей организации другая культура, другие ценности и другой контекст.
Все эти истории заканчиваются одинаково. SRE перестаёт быть инженерной дисциплиной и превращается в новое название для старых методов эксплуатации.
❤28👍5🔥3🤔2👏1🐳1
Broadcom передала Velero в CNCF.
Velero — это инструмент для бэкапа и восстановления Kubernetes-кластеров. Бэкапит не диски, а объекты: деплойменты, права доступа, тома, то есть, всё, что нужно, чтобы поднять приложение заново или перенести его в другой кластер.
У проекта длинная история: он начинался как Heptio Ark, затем после покупки Heptio стал частью VMware, а после сделки VMware/Broadcom оказался в зоне влияния Broadcom. При этом Velero давно используется в проде многими командами и сейчас имеет около 10 тысяч звёзд на GitHub.
Несмотря на популярность, вокруг Velero оставался вопрос лицензии и регулирования. После резких изменений в VMware-лицензировании часть рынка стала осторожнее относиться ко всему, что находится под контролем Broadcom. Для Open Source это особенно чувствительно. Сегодня вендор активно развивает проект, завтра меняет стратегию, и пользователям приходится жить с последствиями.
Переход в CNCF этот аргумент снимает, и теперь ни один вендор не может в одностороннем порядке закрыть проект или резко сменить направление. Релизы, состав мейнтейнеров, роадмапы — всё это теперь решается коллегиально, по правилам CNCF
Важно не путать. Переход в CNCF не упрощает эксплуатацию. Object storage, IAM-учётки, живой целевой кластер никуда не делись, это по-прежнему требует инженерного внимания. Изменилось только то, кто принимает решения по проекту.
В общем, этот анонс — хороший повод снова посмотреть на Velero тем, кто давно не смотрел. Один весомый аргумент против теперь снят.
Velero — это инструмент для бэкапа и восстановления Kubernetes-кластеров. Бэкапит не диски, а объекты: деплойменты, права доступа, тома, то есть, всё, что нужно, чтобы поднять приложение заново или перенести его в другой кластер.
У проекта длинная история: он начинался как Heptio Ark, затем после покупки Heptio стал частью VMware, а после сделки VMware/Broadcom оказался в зоне влияния Broadcom. При этом Velero давно используется в проде многими командами и сейчас имеет около 10 тысяч звёзд на GitHub.
Несмотря на популярность, вокруг Velero оставался вопрос лицензии и регулирования. После резких изменений в VMware-лицензировании часть рынка стала осторожнее относиться ко всему, что находится под контролем Broadcom. Для Open Source это особенно чувствительно. Сегодня вендор активно развивает проект, завтра меняет стратегию, и пользователям приходится жить с последствиями.
Переход в CNCF этот аргумент снимает, и теперь ни один вендор не может в одностороннем порядке закрыть проект или резко сменить направление. Релизы, состав мейнтейнеров, роадмапы — всё это теперь решается коллегиально, по правилам CNCF
Важно не путать. Переход в CNCF не упрощает эксплуатацию. Object storage, IAM-учётки, живой целевой кластер никуда не делись, это по-прежнему требует инженерного внимания. Изменилось только то, кто принимает решения по проекту.
В общем, этот анонс — хороший повод снова посмотреть на Velero тем, кто давно не смотрел. Один весомый аргумент против теперь снят.
👍10🔥9❤3👏2🤔2🐳1
Все внедрили ИИ. Все давно в облаке, все Cloud Native, все успешны. Так выглядит любая конференция.
А что на самом деле? Наши коллеги из Ассоциации облачно-ориентированных технологий решили выяснить и запустили исследование состояния Cloud Native в России 2026, которое выросло из всем знакомого State of DevOps Russia.
Как всегда, опрос подробный, а отчёт с выводами будет открытым для всех.
Чем больше людей пройдут опрос, тем точнее будет отчёт и тем интереснее будет сверить себя с рынком. Может, окажется, что всё не так плохо. А может — наоборот)) И это тоже полезно знать.
Пройти опрос →
А что на самом деле? Наши коллеги из Ассоциации облачно-ориентированных технологий решили выяснить и запустили исследование состояния Cloud Native в России 2026, которое выросло из всем знакомого State of DevOps Russia.
Как всегда, опрос подробный, а отчёт с выводами будет открытым для всех.
Чем больше людей пройдут опрос, тем точнее будет отчёт и тем интереснее будет сверить себя с рынком. Может, окажется, что всё не так плохо. А может — наоборот)) И это тоже полезно знать.
Пройти опрос →
😁8🔥5🤡5👍3
Дочитал «Настоящий SRE» Дэвида Бланк-Эдельмана. Это третий пост из серии, я Алексей Крылов, менеджер продукта. Итоговые впечатления.
Главная фишка книги — иерархия надёжности Дикерсона. Пирамида, построенная по той же логике, что и пирамида Маслоу. В основании лежат мониторинг и наблюдаемость. Дальше идут реагирование на инциденты, разбор последствий без поиска виноватых, тестирование и релизы, планирование ресурсов, разработка. На самом верху — проектирование продукта с учётом надёжности с самого начала. Нельзя перейти на следующий уровень, не отстроив предыдущий. Для тех, кто только начинает, это честная дорожная карта.
Важный нюанс в том, что движение по этой пирамиде нелинейное. Команда может быть на высоком уровне зрелости и внезапно вернуться в режим «пожарных» из-за крупного инцидента. Это нормально, и книга честно об этом предупреждает.
Книга отвечает на вопрос «с чего начать», а не просто описывает, как всё устроено в Google. Структура позволяет читать нелинейно: первая часть про менталитет обязательна, а дальше можно выбирать — вторая часть про личный карьерный путь, третья про внедрение в организацию.
Автор так и говорит, выберите своё приключение. Он собрал опыт множества практиков, добавил реальные истории, здоровый юмор и неожиданно много внимания уделил человеческому фактору: этике, эмпатии, выгоранию. Для технической книги редкость.
Из слабых мест: иерархия Дикерсона при всей полезности неполна, и сам автор это признаёт. В ней нет места для роли SRE-инженера в проектировании архитектуры на ранних стадиях и нет борьбы с рутиной как отдельного уровня. Местами книга перегружена сносками, а центральная метафора с дайвингом к концу, по словам самого автора, становится «всё более громоздкой».
Но есть кое-что интереснее формальных недостатков книги. Ловушка самого подхода. Если система работает слишком хорошо и никогда не падает, все вокруг расслабляются и перестают готовиться к сбоям. Когда инцидент всё же случается — последствия непропорционально тяжёлые, потому что никто не ждал. Книга об этом честно предупреждает.
Кому рекомендую: инженерам, которые хотят взглянуть на свою работу с точки зрения влияния на компанию. Тем, кто чувствует, что просто тушит пожары, но хочет понять, как выстроить систему, в которой пожаров становится меньше.
P.S. Редакция канала благодарит издательство Питер за предоставленную физическую версию книги :)
Главная фишка книги — иерархия надёжности Дикерсона. Пирамида, построенная по той же логике, что и пирамида Маслоу. В основании лежат мониторинг и наблюдаемость. Дальше идут реагирование на инциденты, разбор последствий без поиска виноватых, тестирование и релизы, планирование ресурсов, разработка. На самом верху — проектирование продукта с учётом надёжности с самого начала. Нельзя перейти на следующий уровень, не отстроив предыдущий. Для тех, кто только начинает, это честная дорожная карта.
Важный нюанс в том, что движение по этой пирамиде нелинейное. Команда может быть на высоком уровне зрелости и внезапно вернуться в режим «пожарных» из-за крупного инцидента. Это нормально, и книга честно об этом предупреждает.
Книга отвечает на вопрос «с чего начать», а не просто описывает, как всё устроено в Google. Структура позволяет читать нелинейно: первая часть про менталитет обязательна, а дальше можно выбирать — вторая часть про личный карьерный путь, третья про внедрение в организацию.
Автор так и говорит, выберите своё приключение. Он собрал опыт множества практиков, добавил реальные истории, здоровый юмор и неожиданно много внимания уделил человеческому фактору: этике, эмпатии, выгоранию. Для технической книги редкость.
Из слабых мест: иерархия Дикерсона при всей полезности неполна, и сам автор это признаёт. В ней нет места для роли SRE-инженера в проектировании архитектуры на ранних стадиях и нет борьбы с рутиной как отдельного уровня. Местами книга перегружена сносками, а центральная метафора с дайвингом к концу, по словам самого автора, становится «всё более громоздкой».
Но есть кое-что интереснее формальных недостатков книги. Ловушка самого подхода. Если система работает слишком хорошо и никогда не падает, все вокруг расслабляются и перестают готовиться к сбоям. Когда инцидент всё же случается — последствия непропорционально тяжёлые, потому что никто не ждал. Книга об этом честно предупреждает.
Кому рекомендую: инженерам, которые хотят взглянуть на свою работу с точки зрения влияния на компанию. Тем, кто чувствует, что просто тушит пожары, но хочет понять, как выстроить систему, в которой пожаров становится меньше.
P.S. Редакция канала благодарит издательство Питер за предоставленную физическую версию книги :)
👍24🤔6👎2👀1
Linux Foundation с помощью CNCF выпустил два бесплатных курса про документацию.
• LFC111 — Open Source Technical Documentation Essentials
Тут основы. Как структурировать, писать и поддерживать техническую документацию в Open Source-проектах.
• LFC112 — Creating Effective Documentation for Developers
А здесь уже больше практики. Документация API, туториалы, гайды, всё, что мы пишем регулярно.
Оба курса рассчитаны на разработчиков, инженеров, PM’ов и технических писателей с базовым пониманием разработки. Обучение занимает 3-4 часа, можно проходить уроки в своём темпе.
Нас с вами, коллеги, особо никто не учил писать документацию, а жаль. Конечно, эти курсы не заменят практику и живые задачи. Но они могут дать хорошую базу, чтобы вашей документацией действительно пользовались.
Бесплатно, без подписок и смс. Круто же)
• LFC111 — Open Source Technical Documentation Essentials
Тут основы. Как структурировать, писать и поддерживать техническую документацию в Open Source-проектах.
• LFC112 — Creating Effective Documentation for Developers
А здесь уже больше практики. Документация API, туториалы, гайды, всё, что мы пишем регулярно.
Оба курса рассчитаны на разработчиков, инженеров, PM’ов и технических писателей с базовым пониманием разработки. Обучение занимает 3-4 часа, можно проходить уроки в своём темпе.
Нас с вами, коллеги, особо никто не учил писать документацию, а жаль. Конечно, эти курсы не заменят практику и живые задачи. Но они могут дать хорошую базу, чтобы вашей документацией действительно пользовались.
Бесплатно, без подписок и смс. Круто же)
🔥20👍12🐳2
OpenTelemetry получил статус Graduation в CNCF.
Это высший уровень зрелости проекта в экосистеме фонда. Обычно до Graduation доходят проекты, которые уже массово используются в проде и не зависят от одного вендора или команды.
Рынок давно принял OpenTelemetry как стандарт. Graduation — скорее формальность, чем сюрприз.
Раньше каждый вендор тащил собственных агентов, SDK и форматы данных. Хочешь перейти с одной платформы на другую? – Удачи! Это был тот ещё квест)
С OpenTelemetry приложения могут отдавать телеметрию единообразно. А backend для анализа, хранения и визуализации выбирается отдельно.
В результате конкуренция сместилась выше по стеку. Вендоры всё меньше конкурируют агентами и закрытыми форматами, а всё больше — качеством аналитики, удобством работы, снижением шума и дополнительными возможностями платформ.
Сейчас об OpenTelemetry всё чаще говорят уже не только в контексте классической observability.
С ростом ИИ-систем выясняется, что без качественной телеметрии там тоже далеко не уедешь. По сути это те же распределённые системы, только с новыми слоями сложности: агентами, моделями, внешними инструментами, промптами и длинными цепочками вызовов.
И если для микросервисов нам важно понимать, где сломался запрос, то для ИИ-платформ нужно ещё больше подробностей: какой агент что вызвал, какая модель ответила, где выросла задержка и сколько всё это стоило.
Так что OpenTelemetry перестал быть “перспективной технологией” и стал инфраструктурным стандартом для наблюдаемости. По сути, это общий язык, на котором приложения, платформы и observability-системы договариваются о метриках, логах и трейсах.
Это высший уровень зрелости проекта в экосистеме фонда. Обычно до Graduation доходят проекты, которые уже массово используются в проде и не зависят от одного вендора или команды.
Рынок давно принял OpenTelemetry как стандарт. Graduation — скорее формальность, чем сюрприз.
Раньше каждый вендор тащил собственных агентов, SDK и форматы данных. Хочешь перейти с одной платформы на другую? – Удачи! Это был тот ещё квест)
С OpenTelemetry приложения могут отдавать телеметрию единообразно. А backend для анализа, хранения и визуализации выбирается отдельно.
В результате конкуренция сместилась выше по стеку. Вендоры всё меньше конкурируют агентами и закрытыми форматами, а всё больше — качеством аналитики, удобством работы, снижением шума и дополнительными возможностями платформ.
Сейчас об OpenTelemetry всё чаще говорят уже не только в контексте классической observability.
С ростом ИИ-систем выясняется, что без качественной телеметрии там тоже далеко не уедешь. По сути это те же распределённые системы, только с новыми слоями сложности: агентами, моделями, внешними инструментами, промптами и длинными цепочками вызовов.
И если для микросервисов нам важно понимать, где сломался запрос, то для ИИ-платформ нужно ещё больше подробностей: какой агент что вызвал, какая модель ответила, где выросла задержка и сколько всё это стоило.
Так что OpenTelemetry перестал быть “перспективной технологией” и стал инфраструктурным стандартом для наблюдаемости. По сути, это общий язык, на котором приложения, платформы и observability-системы договариваются о метриках, логах и трейсах.
👍17❤7🔥3
Стандартизирован HTTP-метод QUERY, комбинирующий возможности GET и POST
GET много лет тащил на себе задачи, для которых он не особо предназначен. Сложные фильтры, большие списки параметров — со всем этим он справлялся так себе, упираясь в лимит 8000 байт на размер URI. IETF наконец закрыл эту дыру: HTTP-метод QUERY получил статус Proposed Standard, вышел RFC 10008. По сути это гибрид GET и POST. Тело как у POST, а идемпотентность как у GET.
Под этой новостью набежало больше сотни комментариев. Для рядового RFC это довольно много :)
И знаете, о чём там спорили? Не о технологии. Люди устали. Не от QUERY конкретно, от того, что стандартов и так вагон, а тут ещё один в копилку. Один из комментаторов вспомнил старый мем, мол, раньше было 14 конкурирующих стандартов, решили сделать один универсальный — получили 15. Вот примерно это все и почувствовали)
При этом в комментах реально были толковые технические разборы. Кто-то напомнил, что тело в GET и так никто не запрещал слать, люди этим годами пользуются, так что QUERY просто узаконивает то, что уже давно все делают. Кто-то поднял более практичный вопрос: браузер новый verb проглотит без проблем, а вот nginx и прочие reverse-proxy его просто не распознают, придётся патчить руками. Но все эти аргументы прошли мимо основного внимания, читатели зацепились не за них.
Тред благополучно свалился в спор про то, что браузеры жрут память. И там страстей было ничуть не меньше, чем в разговоре про сам метод.
В общем, повод был технический, а получилось скорее про настроение. Люди не столько разбирали RFC, сколько показывали, как они вообще относятся к очередному "мы придумали ещё один стандарт".
Согласны с этим настроением или считаете, что лишнего сгущаются краски?
GET много лет тащил на себе задачи, для которых он не особо предназначен. Сложные фильтры, большие списки параметров — со всем этим он справлялся так себе, упираясь в лимит 8000 байт на размер URI. IETF наконец закрыл эту дыру: HTTP-метод QUERY получил статус Proposed Standard, вышел RFC 10008. По сути это гибрид GET и POST. Тело как у POST, а идемпотентность как у GET.
Под этой новостью набежало больше сотни комментариев. Для рядового RFC это довольно много :)
И знаете, о чём там спорили? Не о технологии. Люди устали. Не от QUERY конкретно, от того, что стандартов и так вагон, а тут ещё один в копилку. Один из комментаторов вспомнил старый мем, мол, раньше было 14 конкурирующих стандартов, решили сделать один универсальный — получили 15. Вот примерно это все и почувствовали)
При этом в комментах реально были толковые технические разборы. Кто-то напомнил, что тело в GET и так никто не запрещал слать, люди этим годами пользуются, так что QUERY просто узаконивает то, что уже давно все делают. Кто-то поднял более практичный вопрос: браузер новый verb проглотит без проблем, а вот nginx и прочие reverse-proxy его просто не распознают, придётся патчить руками. Но все эти аргументы прошли мимо основного внимания, читатели зацепились не за них.
Тред благополучно свалился в спор про то, что браузеры жрут память. И там страстей было ничуть не меньше, чем в разговоре про сам метод.
В общем, повод был технический, а получилось скорее про настроение. Люди не столько разбирали RFC, сколько показывали, как они вообще относятся к очередному "мы придумали ещё один стандарт".
Согласны с этим настроением или считаете, что лишнего сгущаются краски?
❤11👍4
MetalBear выкатили mirrord под Windows и решили это отметить, сделали браузерный сапёр в стиле ретро-Windows на неделю запуска. Обещали мерч тем, кто к пятнице удержится в топе рейтинга (неделя запуска уже прошла, так что конкурс закрыт) .
Само собой, игру тут же взломали) Nitzan, security-инженер из Daylight (это клиент MetalBear), быстро нашла дыру. Сервер не валидировал тайминги, клиент сам присылал таймштампы по каждому ходу и итоговое время прохождения, а сервер принимал их без проверки. Плюс seed для генерации поля и сам PRNG лежали в клиентском JS, то есть браузер уже на старте знал полную раскладку мин. В сумме это давало возможность сгенерировать идеальную последовательность ходов скриптом и отправить её с любым правдоподобным временем :D
Вообще прикольно, что Nitzan прислала готовый regression-тест, где честное быстрое прохождение — ок, мгновенное прохождение бота — бан, а самое хитрое — заявленное время без реального ожидания — тоже бан.
MetalBear починили ровно так, как она и предложила. Но признали, что до полной неуязвимости всё ещё далеко. Seed по-прежнему виден клиенту, так что терпеливый бот в теории может дождаться нужного момента и пройти игру и-де-а-ль-но.
Игра всё ещё тут, если хотите пощупать.
А разбор взлома — в блоге MetalBear.
Само собой, игру тут же взломали) Nitzan, security-инженер из Daylight (это клиент MetalBear), быстро нашла дыру. Сервер не валидировал тайминги, клиент сам присылал таймштампы по каждому ходу и итоговое время прохождения, а сервер принимал их без проверки. Плюс seed для генерации поля и сам PRNG лежали в клиентском JS, то есть браузер уже на старте знал полную раскладку мин. В сумме это давало возможность сгенерировать идеальную последовательность ходов скриптом и отправить её с любым правдоподобным временем :D
Вообще прикольно, что Nitzan прислала готовый regression-тест, где честное быстрое прохождение — ок, мгновенное прохождение бота — бан, а самое хитрое — заявленное время без реального ожидания — тоже бан.
MetalBear починили ровно так, как она и предложила. Но признали, что до полной неуязвимости всё ещё далеко. Seed по-прежнему виден клиенту, так что терпеливый бот в теории может дождаться нужного момента и пройти игру и-де-а-ль-но.
Игра всё ещё тут, если хотите пощупать.
А разбор взлома — в блоге MetalBear.
MetalBear 🐻
Nitzan from Daylight hacked our vibe-coded minesweeper
We built a browser Minesweeper for marketing and trusted the client for timing. A security engineer at our customer Daylight tore the leaderboard open, then handed us the regression test to fix it.
Заканчивается набор в экспертный совет по cloud-native-технологиям
АОТ (Ассоциация профессионалов индустрии облачно-ориентированных технологий) набирает первый состав экспертного совета. Коллеги ищут практиков со значимым опытом в области Cloud Native и Kubernetes.
Совет будет определять направления развития и работы ассоциации: какие практики продвигать, какие темы исследовать, какой быть Kuber Conf. Также члены совета будут участвовать в разработке образовательных программ и профстандартов по облачным технологиям.
Что нужно:
— 5+ лет практики в Cloud Native / Kubernetes (разработка, архитектура или менеджмент)
— публичный трек: статьи, доклады, участие в Open Source-проектах
— 10–20 часов в месяц на дела совета, своя позиция и готовность её аргументировать в дискуссиях
Важно: работа в совете общественная, срок — год. Это возможности влияния на то, куда двигается индустрия, и подтверждения своего экспертного статуса на уровне сообщества.
Заявки принимаются до 22 июля, результаты объявят в августе.
Детали и форма заявки здесь.
АОТ (Ассоциация профессионалов индустрии облачно-ориентированных технологий) набирает первый состав экспертного совета. Коллеги ищут практиков со значимым опытом в области Cloud Native и Kubernetes.
Совет будет определять направления развития и работы ассоциации: какие практики продвигать, какие темы исследовать, какой быть Kuber Conf. Также члены совета будут участвовать в разработке образовательных программ и профстандартов по облачным технологиям.
Что нужно:
— 5+ лет практики в Cloud Native / Kubernetes (разработка, архитектура или менеджмент)
— публичный трек: статьи, доклады, участие в Open Source-проектах
— 10–20 часов в месяц на дела совета, своя позиция и готовность её аргументировать в дискуссиях
Важно: работа в совете общественная, срок — год. Это возможности влияния на то, куда двигается индустрия, и подтверждения своего экспертного статуса на уровне сообщества.
Заявки принимаются до 22 июля, результаты объявят в августе.
Детали и форма заявки здесь.
⚡10👏6👍4
Коллеги, ситуация. Отчётов и исследований сейчас по нашей теме выходит много, а времени прочитать всё — нет.
И заранее не всегда понятно, какой из них даст что-то полезное, а какой будет просто красиво оформленный текст ни о чём. Как вы выбираете, что читать целиком, а что пролистать по диагонали?
И заранее не всегда понятно, какой из них даст что-то полезное, а какой будет просто красиво оформленный текст ни о чём. Как вы выбираете, что читать целиком, а что пролистать по диагонали?
❤3
Спасибо за ваши ответы про отчёты! Ну, и раз уж мы здесь…
Возвращаемся в подкаст DevOps Deflope с выпуском, где вместе с Игорем Курочкиным (Enabling.team) разбираем индустрию исследований.
Обсудили:
• Для кого на самом деле пишут отчёты: для CTO или для работяг.
• Почему все отчёты сейчас массово ушли в ИИ-хайп.
• Где искать реальные инсайты (спойлер: в поле «Другое»).
• И почему лучший способ изучить инструмент — пойти пить пиво с его автором.
Слушать:
→ На любой удобной площадке
→ На YouTube
→ Наш сайт
Возвращаемся в подкаст DevOps Deflope с выпуском, где вместе с Игорем Курочкиным (Enabling.team) разбираем индустрию исследований.
Обсудили:
• Для кого на самом деле пишут отчёты: для CTO или для работяг.
• Почему все отчёты сейчас массово ушли в ИИ-хайп.
• Где искать реальные инсайты (спойлер: в поле «Другое»).
• И почему лучший способ изучить инструмент — пойти пить пиво с его автором.
Слушать:
→ На любой удобной площадке
→ На YouTube
→ Наш сайт
❤7🦄1