Если Вы о видео Boring Company, то там максимальная скорость была меньше 60 миль в час. Откуда 180 км/ч взялось?
Так что про узкий тоннель и своеобразную аэродинамику- мысль правильная. А при 250 км/ч еще и нагрев всего воздуха в тоннеле пойдет очень шустро.
Такое определение SRE я откопал в оригинале статьи, а авторы статьи — в том же источнике, что и Вы, и в других материалах от Гугла. Мне кажется, что на Тип 2 это не очень похоже — в Google команда SRE существует отдельно от Dev-команды, между ними есть очень четкое разграничение и процессы взаимодействия, иногда (ИМХО) очень жесткие в отношении Dev.
И да, в название можно было бы добавить некоторое кол-во букв — QA, Biz, Sec и т.д.
Если вкратце: команд разработки несколько десятков. Размер может быть разным — от 5-6 человек до 30+ (в этом случае есть внутреннее деление). Классический состав команды — разрабочики, аналитики, тестировщики, софтверные архитекторы (обычно совмещающие это с разработкой), в ряде команд — дизайнеры, OPS и некоторые другие специальности. Люди между командами в подавляющем большинстве случаев не шарятся.
Если продукт перестает активно развиваться (это бывает редко), большая часть ресурсов команды развития переходит на другие продукты. Ops как поддерживал продукт, так и продолжает поддерживать — за счет того, что команды Ops в большинстве случаев закрывают большИе куски ландшафта, там маневр ресурсами выполнить проще.
Отличный вопрос! Грань между Анти-типом F (Dev внутри Ops) и Типом 2 (Полностью совмещенные команды) на самом деле довольно тонкая.
В классическом варианте Типа 2 предполагается, что люди внутри команды представляют разные функции, а при наличии в организации «честной» матрицы еще и относятся к разным профессиональным линейкам (и, возможно, разным структурным подразделениям). За счет T-shape грань между профессиями может несколько размываться, но все равно одни остаются «чуть больше Dev», а другие «чуть больше Ops». При этом достигается определенный баланс целей и задач Dev и Ops, без хронического перекоса в ту или другую сторону.
В случае чистого Анти-типа F Ops является выделенной, но подчиненной командой внутри Dev, и с одной стороны цели и задачи Dev имеют существенно больший вес, а с другой — Ops существует как отдельная команда, что может привести к любому из классических анти-паттернов общения между функциями («перекинь через стенку» или «мы тут накреативили, возьмите на поддержку»)
Сегодня ночью в Калифорнии прошло открытие тестового тоннеля от Boring Company
Так что про узкий тоннель и своеобразную аэродинамику- мысль правильная. А при 250 км/ч еще и нагрев всего воздуха в тоннеле пойдет очень шустро.
Сегодня ночью в Калифорнии прошло открытие тестового тоннеля от Boring Company
150 и 240 это две оочень большие разницы именно с точки зрения тормозного пути
«Правильная» структура команд для DevOps
www.usenix.org/conference/srecon14/technical-sessions/presentation/keys-sre
«Правильная» структура команд для DevOps
И да, в название можно было бы добавить некоторое кол-во букв — QA, Biz, Sec и т.д.
«Правильная» структура команд для DevOps
Если продукт перестает активно развиваться (это бывает редко), большая часть ресурсов команды развития переходит на другие продукты. Ops как поддерживал продукт, так и продолжает поддерживать — за счет того, что команды Ops в большинстве случаев закрывают большИе куски ландшафта, там маневр ресурсами выполнить проще.
«Правильная» структура команд для DevOps
В классическом варианте Типа 2 предполагается, что люди внутри команды представляют разные функции, а при наличии в организации «честной» матрицы еще и относятся к разным профессиональным линейкам (и, возможно, разным структурным подразделениям). За счет T-shape грань между профессиями может несколько размываться, но все равно одни остаются «чуть больше Dev», а другие «чуть больше Ops». При этом достигается определенный баланс целей и задач Dev и Ops, без хронического перекоса в ту или другую сторону.
В случае чистого Анти-типа F Ops является выделенной, но подчиненной командой внутри Dev, и с одной стороны цели и задачи Dev имеют существенно больший вес, а с другой — Ops существует как отдельная команда, что может привести к любому из классических анти-паттернов общения между функциями («перекинь через стенку» или «мы тут накреативили, возьмите на поддержку»)