Комментарии 8
Расскажите, пожалуйста, что в вашем понимании есть команда (разработка определенного продукта)? Сколько у вас таких команд, сколько в каждой команде людей, шарятся ли люди между командами?
А также очень интересно, что происходит потом с командами, когда продукт перестает активно разрабатываться, но при этом остается необходимость его сопровождать. Фактически остается только Ops часть + багфиксинг. Из ниоткуда появляется старорежимная команда сисадминов, которая готова присматривать за еще одним проектом?
А также очень интересно, что происходит потом с командами, когда продукт перестает активно разрабатываться, но при этом остается необходимость его сопровождать. Фактически остается только Ops часть + багфиксинг. Из ниоткуда появляется старорежимная команда сисадминов, которая готова присматривать за еще одним проектом?
Если вкратце: команд разработки несколько десятков. Размер может быть разным — от 5-6 человек до 30+ (в этом случае есть внутреннее деление). Классический состав команды — разрабочики, аналитики, тестировщики, софтверные архитекторы (обычно совмещающие это с разработкой), в ряде команд — дизайнеры, OPS и некоторые другие специальности. Люди между командами в подавляющем большинстве случаев не шарятся.
Если продукт перестает активно развиваться (это бывает редко), большая часть ресурсов команды развития переходит на другие продукты. Ops как поддерживал продукт, так и продолжает поддерживать — за счет того, что команды Ops в большинстве случаев закрывают большИе куски ландшафта, там маневр ресурсами выполнить проще.
Если продукт перестает активно развиваться (это бывает редко), большая часть ресурсов команды развития переходит на другие продукты. Ops как поддерживал продукт, так и продолжает поддерживать — за счет того, что команды Ops в большинстве случаев закрывают большИе куски ландшафта, там маневр ресурсами выполнить проще.
Может вопрос покажется глупым, но все же:
В чем разница между анти-типом F и типом 2, особенно учитывая контекст про «NoOps»? Ведь в обоих случаях Ops Team нет как таковой, но в случае с F акцентируется внимание на том, что команда разработчиков выполняет Ops-функции. А кто их выполняет для типа 2?
В чем разница между анти-типом F и типом 2, особенно учитывая контекст про «NoOps»? Ведь в обоих случаях Ops Team нет как таковой, но в случае с F акцентируется внимание на том, что команда разработчиков выполняет Ops-функции. А кто их выполняет для типа 2?
Отличный вопрос! Грань между Анти-типом F (Dev внутри Ops) и Типом 2 (Полностью совмещенные команды) на самом деле довольно тонкая.
В классическом варианте Типа 2 предполагается, что люди внутри команды представляют разные функции, а при наличии в организации «честной» матрицы еще и относятся к разным профессиональным линейкам (и, возможно, разным структурным подразделениям). За счет T-shape грань между профессиями может несколько размываться, но все равно одни остаются «чуть больше Dev», а другие «чуть больше Ops». При этом достигается определенный баланс целей и задач Dev и Ops, без хронического перекоса в ту или другую сторону.
В случае чистого Анти-типа F Ops является выделенной, но подчиненной командой внутри Dev, и с одной стороны цели и задачи Dev имеют существенно больший вес, а с другой — Ops существует как отдельная команда, что может привести к любому из классических анти-паттернов общения между функциями («перекинь через стенку» или «мы тут накреативили, возьмите на поддержку»)
В классическом варианте Типа 2 предполагается, что люди внутри команды представляют разные функции, а при наличии в организации «честной» матрицы еще и относятся к разным профессиональным линейкам (и, возможно, разным структурным подразделениям). За счет T-shape грань между профессиями может несколько размываться, но все равно одни остаются «чуть больше Dev», а другие «чуть больше Ops». При этом достигается определенный баланс целей и задач Dev и Ops, без хронического перекоса в ту или другую сторону.
В случае чистого Анти-типа F Ops является выделенной, но подчиненной командой внутри Dev, и с одной стороны цели и задачи Dev имеют существенно больший вес, а с другой — Ops существует как отдельная команда, что может привести к любому из классических анти-паттернов общения между функциями («перекинь через стенку» или «мы тут накреативили, возьмите на поддержку»)
Позвольте узнать, а где вы откопали такое определение SRE?
Мне кажется идея Site Reliability Engineering дефакто соотвествует "Типу 2", описанному в статье.
И да, в терминологии DevOps явно забыли Qa. Видимо, название DevOpsQa не очень благозвучно.
Такое определение SRE я откопал в оригинале статьи, а авторы статьи — в том же источнике, что и Вы, и в других материалах от Гугла. Мне кажется, что на Тип 2 это не очень похоже — в Google команда SRE существует отдельно от Dev-команды, между ними есть очень четкое разграничение и процессы взаимодействия, иногда (ИМХО) очень жесткие в отношении Dev.
И да, в название можно было бы добавить некоторое кол-во букв — QA, Biz, Sec и т.д.
И да, в название можно было бы добавить некоторое кол-во букв — QA, Biz, Sec и т.д.
Простите, не заметил что перевод.
В целом с вами согласен. Но лично я понимаю SRE как среднее между "Тип 1" и "Тип 2".
Подробнее об описании зоны ответственности SRE написано здесь:
https://landing.google.com/sre/interview/ben-treynor.html
https://landing.google.com/sre/book/chapters/introduction.html
https://landing.google.com/sre/book/chapters/evolving-sre-engagement-model.html
А для тех, кого заинтересовал этот загадочный термин, я позволю себе добавить ссылку на видео классической презентации про SRE от того же Бена Трейнора из Google:
www.usenix.org/conference/srecon14/technical-sessions/presentation/keys-sre
www.usenix.org/conference/srecon14/technical-sessions/presentation/keys-sre
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Правильная» структура команд для DevOps