Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Говорим о DevOps: ответственность и задачи

В определённый момент каждый опс сталкивается с вопросами «Кто я?», «Зачем я здесь?» и «Что делать?», порождающими многочисленные споры и дискуссии. С одной стороны, у нас есть текущие проблемы, которые надо решить, с другой — логичная и непротиворечивая архитектура девопса. Мне кажется, логика есть и там, и там, поэтому стоит обернуться назад и посмотреть на историю возникновения девопс-культуры.

Допустим, у нас есть бизнес — разработка какого-то софта. Таким образом, внутри у нас уже есть несколько команд, которые разрабатывают различные компоненты и сервисы. Независимо от языка, который они используют, разные команды делают это по-разному. Кто-то может позволить себе stateless, кто-то нет. Кто-то хочет использовать какие-то архитектурные решение, а кто-то просто не может в силу специфики продукта. В своих рассуждениях я беру за отправную точку то, что все команды имеют разные задачи и стараются сделать их максимально точно и просто.

Опс

Спустя какое-то время становится ясно, что команды, пусть и решают разные задачи, сталкиваются с одинаковыми или похожими проблемами. Решение некоторых из них будет одним и тем же независимо от сервиса.

Соответственно, бизнес думает так: если можно выделить что-то общее, то можно сформировать отдел людей, которые будут заниматься только этим и извлекать выгоду.

Экономия на разнице стоимости работы

Если у нас есть дорогой девелопер, время которого стоит 30 долларов в час, то зачем ему делать ту работу, с которой справляется человек стоимостью 10 долларов в час? Если выделить всю низкооплачиваемую и простую работу, то можно сэкономить.

К тому же дорогой девелопер будет делать сложные задачи, которые ему интересны, а дешёвый опс — простые, которые девелоперу не интересны.

Экономия на простоях

Если внутри команды есть люди, которые занимаются только опс-задачами, то у них будет время простоя, пока команда не сгенерирует новые задачи.

Объединяя людей в общий отдел, можно «шарить» их на несколько команд и получать от этого выгоду.

Экономия на экспертизе

Если есть задачи, общие для всех, то разные отделы всё равно приходят к примерно одним и тем же решениям. Развивать экспертизу сразу в нескольких командах всегда дороже, чем содержать нескольких экспертов, которые решат задачу и быстрее, и качественнее.

К тому же, имея нескольких экспертов, которые замещают друг друга, можно не бояться, что кто-то станет незаменимым просто потому, что никто кроме него не умеет обновлять хитрый сетап.

Опс эра

В до-девопс эру принято было поручать отдельной команде решение задач такого типа:

  • настройка производительности OS (экспертиза);
  • управление базами данных (экспертиза);
  • работа с другим open source софтом (экспертиза);
  • мониторинг продукта (экспертиза);
  • доставка обновлений продукта (экспертиза/стоимость);
  • производительность продукта (экспертиза);
  • управление серверами\инфраструктурой (экспертиза/стоимость);
  • бекапы (экспертиза/стоимость);
  • безопасность (экспертиза);
  • обеспечение стабильности работы (экспертиза/стоимость);
  • мелкая поддержка 24/7 (стоимость).

Самое смешное, что почти всё из списка выше не вопрос стоимости, как обычно считают, а вопрос экспертизы: когда люди, которые умеют что-то делать, помогают другим людям, которые не умеют этого делать. Таким образом, редко получается нанять дешёвого человека, который будет опытным и при этом не против поделать какую-то рутинную фигню.

Так как занимать дорогих спецов рутиной не получается, а дешёвые спецы творят фигню, то обычно внутри такой команды формируется (эволюционно или специально) структура разделения запросов в зависимости от сложности.

Вроде звучит здорово. Но, как мы все знаем, чаще всего чем больше хопов, тем выше латенси. Следовательно, такая структура повышает время решения любой задачи.

И это ещё не всё: любой человек или группа людей почти всегда делает только то, что от них требуют. В итоге у нас образовывается несколько команд, у которых в приоритете новые фичи, и одна команда, которая отвечает исключительно за стабильность. И если у этих команд нет ничего общего, то начинается игра с нулевой суммой. А она, как известно, для бизнеса ничем хорошим не заканчивается: опсы хотят стабильности настолько, что саботируют фичи и новые технологии, а девы хотят как можно меньше заниматься чем-то, кроме фичей, потому что именно по этой метрике их судит бизнес.

Как результат, страдает культура внутри компаний и понижается конкурентоспособность. Бизнес перестаёт использовать все те возможности, которые мог бы использовать. К тому же проблема роста одного отдела, количество задач которого зависит от других отделов, это очень сложная тема. Как-то поговорим отдельно :)

Devops

Столкнувшись с этими проблемами, можно прийти к простому решению: давайте наймём дорогих специалистов, которые будут автоматизировать рутинные задачи, и при помощи всяких культурных штук оформим диалог людей, которые поддерживают продукт, с теми, кто его деплоит.

Для уменьшения задержек мы сделаем команды инженеров ответственными как за новые фичи, так и за стабильность работы продукта. Потому что как одно, так и второе, — часть пользовательского опыта от использования сервиса. И фичи, и стабильность — это и есть продукт. К тому же, если надо выстроить приоритеты между стабильностью и скоростью, то лучше это делать в одной команде, где понимают, что чем чревато, чем на бесконечных совещаниях двух команд с совершенно противоположными целями.

Тут внимательный читатель обратит внимание, что почти всё, чем занимался опс-отдел, связано со стабильностью, и будет прав. Поэтому работа опсов должна быть вынесена в команды, которые разрабатывают и используют продукт.

Я знаю, это очень громкое утверждение. Проблемы, с которыми сталкиваются при таком переходе, были описаны ещё в начале статьи, но давайте подумаем: можно ли решить эти проблемы другим путём? Что если у нас будет отдел, который при помощи автоматизации уберёт рутинные задачи и будет иметь необходимую экспертизу, чтобы делиться ею с другими командами? Одни проблемы могут быть решены обучением и совместным внедрением, а другие (в том числе и шаринг экспертизы) — скриптами. А немногое общее может стать внутренним продуктом, который эта команда будет предоставлять:

  • настройка производительности OS (автоматизация/обучение/совместные проекты);
  • управление базами данных (автоматизация/внутренний SaaS);
  • работа с другим open source софтом (автоматизация/внутренние best practices/ответственность команд);
  • мониторинг продукта (автоматизация/внутренний SaaS/обучение);
  • доставка обновлений продукта (автоматизация);
  • производительность продукта (ответственность команд);
  • управление серверами\инфраструктурой (автоматизация);
  • бекапы (автоматизация);
  • безопасность (экспертиза/обучение/автоматизация/совместные проекты);
  • обеспечение стабильности работы (автоматизация/обучение);
  • мелкая поддержка 24/7 (автоматизация?).

И получается, что сложные и общие вопросы решает одна команда, а все остальные команды не следят за тем, как обновляется графит или как меняются тренды докеров. Они просто используют внутренние продукты и утилиты, которые и являются лучшими практиками.

Никто не пишет свой мониторинг, никто не придумывает своё докерное извращение — об этом думает специальная команда.

Но если вы хотите получать метрики и доставлять свои приложения на продакшн, у вас есть набор утилит/практик, помогающих делать это правильно, не наступая на одни и те же грабли. И не надо каждый раз изобретать велосипед и получать экспертизу там, где она вам не нужна.

Подобная схема удобна. Команда опсов превращается в мультикоманду инженеров, которая занимается всем, чем может, и помогает везде, где надо. В список задач может прийти и переписывание/оптимизация высокопроизводительного кода, и внутренний PaaS, и упрощение сборки/доставки приложения.

И такая команда занимается не поддержкой всего на свете, а конкретными продуктами, как и в других продуктовых командах. И как для других продуктовых команд для неё можно выставлять собственные приоритеты, ориентируясь на общее инженерное виденье, делать продукт для конкретных пользователей.

А остальные продуктовые команды лучше понимают то, как работает их код в продакшене, и это достаточно благостно и отрезвляюще влияет на продукт-менеджмент и стабильность, ведь если вы отвечаете за пользовательский опыт, то обычно очень быстро находите нужную и выгодную именно вам точку между стабильностью и новыми возможностями.

Описанная выше схема, помимо всего прочего, стимулирует делиться знаниями и опытом вместо сосредоточения умений в одних руках и дополнительно даёт свободу там, где она необходима, решая проблему масштабирования команд: хочешь использовать тарантул, монгу, очереди, постгрю? Не надо упрашивать опсов, чтобы они этим занялись. Ставь и зарабатывай свой опыт. Но отвечаешь за это тоже ты.

И если всё идёт правильно, то побеждают тот, кто берёт на себя ответственность, а не тот, кто лучше всех перекладывает её на других. Это ведь здорово, правда?

Послесловие

Для того чтобы девопс заработал, в него надо вложить немало сил. Но кроме этого много сил надо и для поддержки. Надо постоянно учиться, постоянно искать, что можно сделать лучше, и делать это лучше. Надо думать не только о сегодняшнем дне, но и том, что будет через год. Со стороны этой общей экспертной команды надо всегда смотреть на несколько шагов вперёд и стараться облегчить жизнь другим. Надо делать продукты максимально автономными и в меру абстрактными. Такими, чтобы они подходили как можно большему количеству инженеров. Сделать так, чтобы у остальных команд было как можно меньше проблем. А другие продуктовые команды должны принять на себя ответственность за свой продукт, ответственность за опыт своих пользователей и постоянно пересматривать свой продукт со стороны этого опыта.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



60 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Не понял, что хотел донести автор статьи. Это высосано из пальца или из реальных кейсов... тоже не ясно. Я работал занимался задачами DevOps в одном стартапе пару лет назад и использую эти (docker, rancher, не kubernetes) навыки сейчас для быстрого разворачивания новых продуктов, что выходят на рынке. В основном, конечно, я больше изучаю технологии, CMS, фреймворки, языки программирования на аналитическом уровне (короче, то для чего они были созданы и для чего их лучше использовать) и думаю что Senior DevOps-ы — это уже типа, админы зоопарков, что имеют экспертное мнение в технологиях и должны знать от 0 до 255, а так же другие подводные камни своих зверюшек. Когда козе дать баян, а медведю — гармошку. Я не уверен точно, но могу сказать, что команды DevOps-ов нужны только продукту, который проходит апгрейд (архитектуры, языков, подходов). Это как бы проблемы, которые вылезли после создания чего-либо с нуля и в том случае, когда «поперло» та и «попрело» тоже :-). В иных случаях, как по мне, лучше максимально далеко продумывать архитектуру вашего продукта с нуля, чтобы потом не было зоопрарков и команд. Вообще, понятие команд в проекте — это уже разделение проекта на какие-то единицы, которые кто-то потом должен соединять, контроллировать и остальные «пирожки с начинкой».

Если проект — это зоопарк в облаке, который без поллитры не настроить, то вполне оправдано.

Хм. Ну я работал и консультировал такие компании как grammarly, datarobot, ring.com, в принципе это достаточно большие и успешные компании.

Senior DevOps-ы — это уже типа, админы зоопарков

Хм. Я вот вообще считаю, что такой позиции как DevOps не должно существовать, если это не подразумевает позицию евангелиста.

экспертное мнение в технологиях и должны знать от 0 до 255, а так же другие подводные камни своих зверюшек.

Вообще больше похоже на позицию архитектора.

но могу сказать, что команды DevOps-ов нужны только продукту, который проходит апгрейд

Собственно в первой части статьи я говорю о том что DevOps нужен компании, которой надо уменьшить time-to-market и собственно на уменьшение ttm и повышение эффективности кросскуммуникаций между командами и направлен DevOps как методология

В иных случаях, как по мне, лучше максимально далеко продумывать архитектуру вашего продукта с нуля

В современном мире вэба это скорее редкий случай. Потому что намного выгоднее выпустить и проитерироваться, чем делать что-то, что может не быть востребовано. Но это уже больше вопрос бизнеса, чем вопрос девопс.

Да, ДевОпс это один из бекбонов agile.

команды DevOps-ов нужны только продукту, который проходит апгрейд

это очень сильно сказано. А если продукт ВСЕ время в процессе апгрейда? (о чем собственно и CI/CD).

Ну мы же говорим не только про веб. Сейчас любое, клиент-серверное приложение может вертеться в контейнерах на продакшине? ...за исключением, наверное, каких-то игрушек (я не знаю специфики разработки игр).
Это скорее не в современном мире вэба, а в текущем состоянии дел в продажах и продвижении продукта выгоднее итерироваться и нагромождать потом зоопарк при росте дел или новых требований. А ситуация, когда выпускают LetGo, после OLX, и я уверен, есть еще куча их аналогов, и даже при таких раскладах я знаю деятелей, что хотят выпустить их аналог... я такого не понимаю. Да, это стандартная конкуренция и типа законы рынка, скажете Вы,
такая же, как и любой другой бизнес: аптеки, супермаркеты на каждом углу и прочие издержки современного мира, который вещает, что конкуренция заставляет улучшать качество и понижать цену.... Ага, если подумать, что каждый новый конкурент порождает спрос на рекламу, которая закладывается в стоимость, то почему тогда реальная цена продукта будет падать та еще и качество расти, если для лучшего качества нужны спецы подороже? Я думаю, что можно сопоставить коммерческую разработку с производством молока или колбасы и увидеть некоторую аналогию в аспектах ценообразования конечного продукта. К этому не относиться только open-source. Далеко меня чет занесло... но это раскрытие фразы: «лучше продумывать максимально далеко архитектуру вашего продукта с нуля», где архитектуру — лучше заменить на смысл или предназначение. Это как старая заезженная фраза, «создаем технологии ради технологий».
Пы.Сы. Я тогда-то статью, после тяжелого дня читал да и бегло, потому и не понял всего смысла. Перечитал и могу сказать, что тема и контент имеют общее. Так что сорян за недоосмысленный комментарий. Спасибо автору, наткнул на интересные мысли.

Допустим, у нас есть бизнес — разработка какого-то софта.
может стать внутренним продуктом, который эта команда будет предоставлять:

настройка производительности OS (автоматизация/обучение/совместные проекты);
управление базами данных (автоматизация/внутренний SaaS);
работа с другим open source софтом (автоматизация/внутренние best practices/ответственность команд);
мониторинг продукта (автоматизация/внутренний SaaS/обучение);
доставка обновлений продукта (автоматизация);
производительность продукта (ответственность команд);
управление серверами\инфраструктурой (автоматизация);
бекапы (автоматизация);
безопасность (экспертиза/обучение/автоматизация/совместные проекты);
обеспечение стабильности работы (автоматизация/обучение);
мелкая поддержка 24/7 (автоматизация?).

я не понял главного — куда исчез бизнес по разработке софта?

так это ж в рамках команды.

это как раз противоположно devops

Я думал что это подмножество DevOps.

я планирую зафигачить целый доклад, в котором я описываю, почему я считаю, что SRE это противоположно тому, чему учит DevOps

А можно тезисно тут? Потому что мой опыт говорит противоположное (хотя да — смотря что или кого называть ДевОпс. Если КОГО то безусловно SRE противоположно).

как раз SRE это есть тот случай, когда назначили КОГО-ТО, только назвали их SRE а не девопсами.

а) как я уже писал ДевОпс это не позиция.
б) утверждение

когда назначили КОГО-ТО, только назвали их SRE а не девопсами

не верно. Те кого у нас рекрутеры называют джевопсами и кого гребет как не в себя аутсорс и близко не дохожят до SRE как минимум по причине того что в аутсорсе доли процента имеют доступ к проду на ведущих ролях.

спустя месяц меня попустило и я попробую ответить ещё раз. Я написал одно, но вы прочитали там совершенно другое.

1) ДевОпс это методология, а не позиция, я нигде не утверждал что девопс это позиция.
2) SRE это как раз частный случай ошибки когда юникорнов садят в одно место и заставляют их чинить и держать жизнь в том, что наворотили девы и опсы. Поэтому я считаю что гугл воплотил в жизнь стратегию наших местных компаний (нанять «девопсов» заставлять их держать прод руками плюс «всё автоматизировать») и назвал это SRE. Как раз поэтому я и считаю что SRE противоположно devops.

Можно вопрос — Вы гугловскую Site Reliability Engineering читали?

Лол. Учитывая что девопс это набор практик главные цели которых:
а) уменьшить TTM
б) решить проблему отсутствия единого приоритета между командами

То перевод режима деплоя в математическое пространство (главная идея SRE) очень неплохо ложится на идеологию DevOps.

Опять же, от SRE не требуют стабильной работы приложения. Он них просят его поддерживать, в то время как за стабильность и SLA\SLO отвечает проджект менеджер команды разработчиков приложения, который впрочем может принимать рекомендации ребят из SRE.

В мене як мінімум десяток разів виникала саркастична посмішка від вашого твору на тему девопс та вашої творчості в айпад, але викладу основне

1) Дев не більше опс в будь якому вимірі, переконання у протилежному тільки показує як мало ви бачили спеціалістів та як сильно недооцінюєте те їх важливість

2) опси — не для оптимізаціі часу чи нецікавості розробників, див п1. Якщо ваші розробники займаються задачами, що під силу продавцю макдональдс — не тою справою займаєтесь ;)

3) девопс у вашій статті звужений до комунікації між командами та розмазування відповідальності, і якщо з першим я згоден то друге просто помилкове. Врешті комунікація між командами — це тільки одна грань девопс

Девопс не може «заработать» наче він до цього курив на вулиці без діла, він або є, або нема, а якщо нема то нема. Ну це все звісно якщо ми не граємо в сучасні смислові корпоративні ігри де девопсом можуть назвати будь-кого від сісадміна до студента що запустив свій перший контейнер

Власне і відповідей на питання на початку статті ви теж не дали

ПС. Взагалі гарно що пишете про таке. Незважаючи на вищесказане цікаво пишете, і в деяких моментах я вас підтримую

1) Так дев > опс это историческое понимание и я дальше в статье прихожу к тому что не больше.
>Самое смешное, что почти всё из списка выше не вопрос стоимости, как обычно считают, а вопрос экспертизы: когда люди, которые умеют что-то делать, помогают другим людям, которые не умеют этого делать. Таким образом, редко получается нанять дешёвого человека, который будет опытным и при этом не против поделать какую-то рутинную фигню.

Аналогично и по остальным пунктам. У меня такое ощущение что все читают вступительную «историческую» часть, тригерятся и не дочитывают до конца.

Це через рисунки

Про експертизу взагалі теж не згоден, тим більше в історичному контексті, навіть зараз грамотний опс, чи мережевик зара на вагу золота, що казати про десять-п’ятнадцять років тому коли завести якийсь нормальний кластер без талмуду й бубна було нереально. Мережі у вас, до речі, взагалі не згадуються. Процеси релізу теж. Це сумно

Клауд просто навіяв пурги на очі, все здається легким, доступним і стабільним. Це не так, і не було так ніколи ;) Будь-яка системна фатальна проблема на продакшені серед ночі вас протверезить

Так ведь и я говорю что хоть все и считают что опс дешевле, но на самом деле это не так. Выше я привёл цитату в которой дословно говорю это же.

Не так

ну почнемо з того що девопс по цій статистиці має більше за девелопера, а сеньйора девопса нема, в той час як сеньйор дев є

Потім в багатьох компаніях навіть тайтла девопс нема, я наприклад по штату розробник

Ну і девопсом називається зараз все підряд, можна писати роками скрипти на баші для автоматизації древньої домашньої системи патчів бд чи пошкрябувати дсл для дженкінса раз на тиждень

Ну кароч, статистика та ще й по Києву не друг, беріть вже санфрансіско шолі

Там можно по опыту глянуть. 5+ лет к примеру ) Это и будут ваши синьер девопсы )

А вот на тему размазывания ответственности интересно. Что вы имеете ввиду? Что разделение ответственности между командами это хорошо? Так это ведь как раз из-за чего девопс и появился, из-за того что разные отделы отвечали за разное...

Відповідальність має бути там де є експертиза й можливості її застосувати.

Просто сказавши ось тепер Вася не тільки лев але й мопс, і ось як впаде продакшен ми тебе його з’їмо це самодурство

Про можливості — я вам десяток прикладів можу навести коли технарі кажуть, але менеджмент має інші пріорітети чи не відстрілюють проблеми й ігнорують технічні борги. Але це нюанс, головне експертиза. Якщо Таня не шарить в постгресі чи лоадбалансерах, хай собі кодить тести на селеніумі чи чаклує контролєри, як уміє.

Важливо ідентифікувати людей які вміють та хочуть вміти, їх постійно високо мотивувати, й на їх основі будувати крос функціональні команди, щоб решта девів мали горизонтальний доступ до тих процесів які продукт проходить після коміта

Так стой, я ведь и пишу что люди с экспертизой должны быть, просто они должны её шарить обучаю других сотрудников и консультируя в сложных случаях. Вместо того чтобы полностью отвечать за стабильность, например.

Люди які активно шерять свій нолідж — це надзвичайна рідкість, на таких важко розраховувати, це та рожева ілюзія девопс яку треба випалити. Тих хто сидить і мовчки робить роботу на порядки більше ;)

В цілому я думаю ми в цьому маємо спільне бачення, просто різними словами говоримо. Я просто хотів сказати що за ключові системи мають відповідати конкретні овнери. Думаю й ви ж про те.

девопс з’явився з нової генерації стартапів, які будувались на нових концепціях упавління, де проблеми розділення нема від початку

Решта світу побачили що вони програють новій генерації за багатьма критеріями важливими в конкуренції й почали тужитись і табунами «внєдрять»

Я б сказав що не девопс вирішує проблему розділення відповідальності й комунікації й руйнує walled gardens та silos, а навпаки вилучення тупих бюрократій, більше кроскомандної відповідальності й спілкування є передумовою того, що потім назвуть «о оце виглядає вже як девопс, ми це зробили»

Але в кроскомандній відповідальності все одно відповідальні конкретні люди й менеджмент

А менеджмент завжди забувають але саме з менеджменту треба починати перетворювати організацію, бо вони і є найбільша проблема ;)

Супер! Спасибо за отличную статью.

Команда Изобразительное Искусство. Или Команда Чтение Стихов Вслух. Вот на таком уровне это звучит.

не очень понял к чему это :)

Ну є така стереотипна манєчка, що девопс команд не може бути апріорі, бо це просто створює ще одне silo.

Андрію, на мій погляд, це хибна думка, хоча б неформальні девопс команди мають бути. Купа некоординованих бойскаутів нароблять прикрощів, а на продакшені нароблять лиха.

Проблема насправді не в поділі на команди, команди не створюють silo самі по собі, проблема в ізоляції ключових точок прийняття рішень, ієрархічності управління в класичних конторах і потоках ключової експертизи між різними командами.

На жаль, з подачі рекрутерів у нас почали називати девопсами просунутих (а іноді й не дуже) білд-інженерів. До речі Гугл також псіханув від цього і викоритовує інакшу назву для своїх спеціалістів — Site Reliability Engineer.

Site Reliability Engineer

За Гуглом багато західних контор почали використовувати цей тайтл, хоча він ще більш невідповідний ніж DevOps, тому що Site Reliability — це лише частина того чим вони займаються. Та і то не завжди.

Проблема насправді не в поділі на команди, команди не створюють silo самі по собі, проблема в ізоляції ключових точок прийняття рішень, ієрархічності управління в класичних конторах і потоках ключової експертизи між різними командами.

Це правда. Але з моїх спостережень ефективніше працюється коли опси формально і реально розподілені між проектними командами і отримують задачі безпосередньо, ніж коли вони існують у власному світі (Operations team/ DevOps team), отримують задачі з загального пулу і пріоритизують на власний смак.

Саме так, і це перше що треба робити — прибрати як мінімум двох босів з комунікації

Я про те, що в такій структурі з інженером на команду, девопси координується менше між собою і навіть пріорітети мають різні. Це створює проблеми коли треба приймати якесь архітектурне рішення чи довго тримати певний загальносистемний пріорітет, — незрозуміло хто має прогнозувати місткість CI чи банально яким способом структурувати якісь ансібл плейбуки чи координації загальносистемних змін. У нас зараз якраз ця структура і ці проблеми — деякі девопси просто випадають з загального процесу і зникають у своєму скваді, вони ще швидко спеціалізуються і не мають банально часу дивитись по сторонах трохи далі за свої дошки й стендапи

Короч, на мій погляд метакоманда з загальною нечасто координацією має бути особливо якщо таких девопсів багато, а їх в такій схемі багато коли розробників багато

Ще хороший варіант з самостійною інфраструктурною командою, в якій крім опса є девелопер і QA. Тоді інші команди більш прогнозовано працюють над своїми задачами і не відволікаються на інфраструктурні активності. Планування відбувається простіше.

команда DevOps

Это такой оксюморон?

хм. Сори, у меня в блоге эта статья называлась «О DevOps» или как-то так. Попрошу редакторов поменять заголовок.

Эмм, я имел в виду continuousdelivery.com/...​h-thing-as-a-devops-team. То, что описано в статье называется Ops. Разве нужна отдеотная команда чтобы шарить практики? С таки подходим можно прийти и к одной большой команде на всю компанию. Идея DevOps — это автономность команд в первую очередь. А так получается зависимость еще на одну команду.

эм. Так и у меня про этом же.

A really bad way to try and solve this problem is to insert another layer of indirection between the dev and ops team, and call it a „devops team”. This is what I mean when I am arguing against creating a „devops team”

А в вашей статье, как я понял, вы предлагаете таки создавать команду devops. Возможно, я плохо читал.

ну я пришел к тому что вообще опс команды быть как таковой не должно, потому что чаще всего она не нужна. А опсов заменяет команда, которая делиться экспертизой и развивает внутренние продукты. Если коротко.

Как по мне, это просто называние опсов девопсами, что есть неправильно согласно изначальной идее девопса.

так я вроде как раз в статье и обозначил разницу между командой platform инженеров и опсов. Хм.

DevOps — это не роль и не позиция в компании — это нобор практик или филосовия. Поэтому я и написал про оксюморон. Не думаю, что корректно называть команду platform инженеров командой DevOps.

хм. А где я называю команду platform инженеров командой девопс?

в статье и обозначил разницу между командой platform инженеров и опсов

с статье есть опсы и девопсы. Если platform инженеры не опсы значит они девопсы (исходя из вашего описания). Или моя логика сломалась.

ммм.. если честно я не нашел ни одного упоминания девопс команды в статье.

не нашел ни одного упоминания девопс команды в статье

Вы просто говорите об одной выделенной команде которая занимается девопс?

The crucial thing is this: the „devops team” is not on the hook for the systems that get built, or for deploying them, or writing the build and deployment scripts, or for the operation of those systems. Nor should there be „devops specialists” on development teams doing this work: this is core developer work, the same as writing code, and developers need to own it.

А у вас в обязанности входит и мониторинг продукта, и обеспечение стабильности, и мелкая поддержка. Это все задачи разработчиков, практикущих DevOps.

о боже, я уже третий комментарий пытаюсь понять где я говорю о выделенной команде, которая занимается devops. Можете цитату, пожалуйста? Очень вас прошу!

Весь раздел Devops об этом.

никто не придумывает своё докерное извращение — об этом думает специальная команда.
сложные и общие вопросы решает одна команда
Команда опсов превращается в мультикоманду инженеров, которая занимается всем, чем может

Ты точно автор статьи?

Эм. Я не понимаю к чему вы ведёте. Опс команда характеризуется тем что делает общую работу в том числе и поддержку. Я в статье предлагаю чтобы отдельной команды, которая поддерживает\релизит и так далее не было, но была команда которая занимается внутренними продуктами (внутренние SaaS/PaaS) и шарит экспертизу. Плюсы этого тоже описаны, в частности возможность делать продукт\консультацию, то есть сменить flow с поддержки на продуктовый с всеми сопутствующими выгодами. Почему вы эту команду называете devops? И с чем конкретно вы спорите?

Я веду к тому, что то, что вы описали в секции DevOps — это не DevOps, хоть у подхода могут быть свои преимущества. Прошу прощение, что не получилось правильно донести эту мысль раньше.

DevOps это набор практик направленных на уменьшение TTM посредством единого управления приоритетами у ops и dev команд. В данном случае я скорее веду к NoOps как подмножеству девопс и мне это кажется наиболее рабочей схемой.

Девопс команда, по хорошему, может быть только командой евангелистов девопс, в то время как в современном IT принято девопс командой называть всех от релиз инженеров до просто опсов.

Підписатись на коментарі