• Сегодня ночью в Калифорнии прошло открытие тестового тоннеля от Boring Company
    0
    Если Вы о видео Boring Company, то там максимальная скорость была меньше 60 миль в час. Откуда 180 км/ч взялось?
    Так что про узкий тоннель и своеобразную аэродинамику- мысль правильная. А при 250 км/ч еще и нагрев всего воздуха в тоннеле пойдет очень шустро.
  • Сегодня ночью в Калифорнии прошло открытие тестового тоннеля от Boring Company
    0
    Длину необходимых ответвлений посчитайте, пожалуйста. Причем не для разгона (это еще может быть более-менее быстрый процесс), а для торможения.

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

    Если продукт перестает активно развиваться (это бывает редко), большая часть ресурсов команды развития переходит на другие продукты. Ops как поддерживал продукт, так и продолжает поддерживать — за счет того, что команды Ops в большинстве случаев закрывают большИе куски ландшафта, там маневр ресурсами выполнить проще.
  • «Правильная» структура команд для DevOps
    +1
    Отличный вопрос! Грань между Анти-типом F (Dev внутри Ops) и Типом 2 (Полностью совмещенные команды) на самом деле довольно тонкая.

    В классическом варианте Типа 2 предполагается, что люди внутри команды представляют разные функции, а при наличии в организации «честной» матрицы еще и относятся к разным профессиональным линейкам (и, возможно, разным структурным подразделениям). За счет T-shape грань между профессиями может несколько размываться, но все равно одни остаются «чуть больше Dev», а другие «чуть больше Ops». При этом достигается определенный баланс целей и задач Dev и Ops, без хронического перекоса в ту или другую сторону.

    В случае чистого Анти-типа F Ops является выделенной, но подчиненной командой внутри Dev, и с одной стороны цели и задачи Dev имеют существенно больший вес, а с другой — Ops существует как отдельная команда, что может привести к любому из классических анти-паттернов общения между функциями («перекинь через стенку» или «мы тут накреативили, возьмите на поддержку»)