Comments 13
Судя по фразе «Разработчики — наши клиенты» ваши SRE по большей части являются DevOps. В философии SRE правильнее считать «мы - разработчики», просто фокус SRE на масштабируемости и отказоустойчивости, а разработчиков - на фичах. Когда SRE и швец (сисадмин), и жнец (девопс) и на дуде игрец (внутренняя инфраструктура) - это скорее всего приведет к проблемам.
В философии SRE правильнее считать «мы - разработчики»
А что такие SRE разрабатывают?
Как я уже сказал, SRE помогают разрабатывать сам сервис, просто фокусируются на других задачах. Одна из проблем взаимодействия SRE и разработчиков возникает, когда разработчики полностью передают продакшн SRE, а сами SRE занимаются исключительно инфраструктурой этого продакшэна.
В этом случае разработчики пишут софт не понимая, как же он работает в проде, а SRE поддерживают прод не понимая, что за софт на нем крутится и что происходит у него внутри. Отсюда вырастают проблемы, что данные на тестовом стенде никто не обновляет - разработчики пишут софт и не понимают, как именно он взаимодействует с окружением, а SRE понимают эти взаимодействия, но не знают требований к ним.
Привет, я как раз из команды SRE в Додо. Тут произошла небольшая путаница в понятиях. Полноценные SRE у нас есть не только в одноимённой команде: есть разработчики, основной фокус которых – на надёжности конкретных сервисов. В этом месте довольно близко к книжке: сервисы должны передаваться к SRE на LTS только, когда сервисы feature complete. У нас таких сервисов почти нет: разработчики поддерживают свои сервисы end-to-end: код, пайплайн, продакшн.
То есть пайплайны за разработчиков мы не пишем, хотя свои домашние инструменты для деплоя у нас есть.
Сама команда SRE тоже довольно близка к книжке: "SRE is a software engineering approach to IT operations". Наша команда почти целиком состоит из инженеров с бэкграундом в разработке. Мы сфокусированы на надёжности и стоимости инфраструктуры, помогаем разработчикам с их сервисами, когда надо. И стараемся делать инструменты, которые делают operations проще: мониторинг, disaster recovery, инструменты для того, чтобы разработчик сам мог сделать всё что считает правильным и не ошибиться.
Мы как компания только сейчас выходим из режима стартапа. Как команда приходим к тому, чтобы не быть "многорукими многоногами", а разделяться по компетенциям. Хотя органическое разделение, конечно, есть давно.
Определение SRE из википедии:
Тезисы про SRE из "SRE book" от Google (авторов термина и подхода):
Таким образом, SRE - это разработческий подход к операционке (не к разработке бизнес-приложений). Т.е. эти инженеры делают так, чтобы рутинные ручные операционные задачи за людей делала автоматика. Они могут контрибьютить в бизнес-приложения, но не это их основная работа, и чаще они выступают центром экспертизы в том, как писать надежные бизнес-приложения.
А операционные задачи - это поддержка продакшена, инфраструктуры, инциденты, их устранение и предотврадщение и т.д.
Вот как раз о поддержке в основном и идет речь в статье.
Хочу обратить ваше внимание на то, что все аспекты, описанные в статье - это тойл. И занимается им только один (реже 2) человек из команды в каждый момент времени. Что делают остальные? Занимаются инженерной работой - автоматизируют тойл, внедряют или сами пишут новые инструменты.
Есть еще, конечно, SRE-SWE, но это уже более глубокая специализация, о которой мы пока только задумываемся (хотя у нас по факту есть даже такая команда).
Насчет непонимания того, как код работает в проде, абсолютно с вами согласна. Но чтобы полностью отдать поддержку разработчикам, нужно ого-го сколько всего сделать и в техническом, и в процессном плане, это не сделаешь по щелчку пальцев.
Прямо сейчас мы гораздо активнее занимаемся именно этим вопросом. Например, где-то с марта-апреля 2021 некоторые команды разработки сами дежурят по своим сервисам днем. И, надо сказать, довольно успешно)
Коммент удален
Борьба с токсичностью — отдельная большая тема, углубляться в неё в этой статье не хочется
Углубитесь в следующей, пожалуйста? Например, расскажите, какой именно «малой кровью» обошлось, менялась ли оргструктура, система мотивации, сколько человек из скольки ликвидировали, и вот это всё. А то эта статья выглядит как «мы построили ядерный реактор и прицепили к нему две лампочки, смотрите, как красиво они светят». Красиво, но ядерный реактор, то есть превращение типичного ops-серпентария в нормальное подразделение, интереснее.
Спасибо за историю. Оценка результата на основе опросов - хорошо. Еще лучше когда можно сравнить данные "до" и "после". Например, распределение lead time для On Duty реквестов. Судя по изложению, у вас для этого всё есть.
Спасибо за статью. Можете поделиться несколькими моментами?
Как у вас между SRE и разработчиками были не очень хорошие отношения, они же бок о бок работать должны? Т.е. они как бы opposite у вас?
Как они могли не знать о проблемах разработчиков, если должны работать бок о бок?
Я так понял, что SRE в основном у вас занимаются тестовыми стендами. В этом свете я не очень понял, как они дают консультации по поводу дизайна отказоустойчивых сервисов.
Про включение и выключение стендов повеселило. То, что делается стикерами, мемами и прочими напоминаниями - суть меры, которые не работают. Эти вещи нужно обеспечивать техническими средствами, о которых не нужно думать и вспоминать.
Кстати, а зачем тестовые стенды? Почему не получается нужные куски локально развернуть?
сколько интересных вопросов! отвечаю:
Как у вас между SRE и разработчиками были не очень хорошие отношения, они же бок о бок работать должны? Т.е. они как бы opposite у вас?
По идее, должны работать вместе, но это не так. Во-первых, это разные команды: SRE живут отдельно, в своем маленьком мирке, делая свои задачи, имея свои приоритеты, а разработчики разделены на команды, и каждая из них тоже живет в своем маленьком мирке со своими задачами и приоритетами. Во-вторых, взаимодействия случались в основном через те самые просьбы и на инцидентах. Ведь разработчики почти не лезли в домен SRE - не хватало ни прав, ни экспертизы. Наличие каких-то границ между мирками разобщало, а при наличии проблем противопоставляло людей. У одних не работает, у других все пули вылетели, а где искать концы не понятно. Только сейчас начинаем устранять причину разделения - выдаем разработчикам права и потихоньку выдаем им экспертизу. Но это еще далеко не конец пути к полноценной самостоятельности разработчиков.
Как они могли не знать о проблемах разработчиков, если должны работать бок о бок?
кажется, ответ был дан в абзаце выше. Если остались вопросы - спрашивайте)
Я так понял, что SRE в основном у вас занимаются тестовыми стендами. В этом свете я не очень понял, как они дают консультации по поводу дизайна отказоустойчивых сервисов.
SRE занимаются далеко не только тестовыми стендами, просто в декабре 2019 тестовые стенды болели больше всего, поэтому в статье так много сказано про них. Мы говорили в основном про тойл команды (но и он состоит не только из тестовых стендов), но кроме тойла есть еще инженерная работа (когда ты не на дежурстве), которая составляет сейчас примерно 60-70% деятельности наших SRE: создание или внедрение новых инструментов, автоматизация рутинных, сложных, скучных задач, построение более отказоустойчивой инфраструктуры для продакшена и много чего еще. Это те задачи, которые ребятам хочется делать, то, за что они любят свою работу.
И т.к. у ребят есть понимание системы целиком, ее инфраструктуры, возможностей этой инфраструктуры, как это все работает, они могут дать дельный совет разработчикам. К тому же в команде есть прокачанные в прошлом разработчики, которые сами писали качественные высоконагруженные сервисы.
Эти вещи нужно обеспечивать техническими средствами, о которых не нужно думать и вспоминать
мне тут пока не очень понятно, как можно техническими средствами обеспечить осведомленность о новых инструментах?
Кстати, а зачем тестовые стенды? Почему не получается нужные куски локально развернуть?
можно, и разработчики постоянно так делают, но локальное окружение гораздо сложнее показать кому-то еще - например, продакту или тестировщику. Ну и локальное окружение сильно дальше от продакшена, чем тестовый стенд - нет большей части инфраструктуры и состояние локальной машины почти невозможно сматчить с продакшен-серверами. Если запускать сервисы в докере, то становится лучше, но у нас, к сожалению, пока есть легаси-монолит, который еще не контейнеризирован, а без него можно очень мало чего запустить и проверить.
Как подружить SRE с разработкой, а на сдачу улучшить качество сервиса