Добрый день. Оркестрация - это термин относящийся к технологии, на базе которой построен Штурвал. Оркестратор - инструмент управления, в нашем случае, кластерами K8s. Это если совсем коротко. Веду к тому, что совпадения с музыкальной терминологией это совпадение и не более того. Комментарий не очень по делу)
Добрый день. Это обзорная статья про практики DevOps и фреймворки, которые можно использоваться в зависимости от потребности, основанная на личном опыте работы в разных компаниях без фокуса на какую-то одну.
Очень интересное применение RCA подхода, не всё же проводить расследования по тикетам ИТ и сбоям в инфраструктуре. Есть вопрос, почему использовался именно подход из 6 вопросов? Поясню, есть 3 реализации фреймворка от 4 до 6 вопросов, и наиболее распространённый из 5, которые сводятся к: •Определить проблему и ее влияние; •Сбор данных; •Анализ проблемы; •План действий; •Стандартизация.
Так же, как предложение - добавить к статье материалы в виде доп источников, чем вдохновлялся автор при написании статьи, помимо собственного опыта.
Коротко и ясно) На мой взгляд, я бы расширил вопросы в конце неким опрос или чек-листом, который помог бы коллегам из комьюнити переиспользовать подход с более практической, а не теоритической точки зрения.
В целом, это тоже рабочая история. Тут дело вкуса и компетенций по работе с тем или иным инструментом. Если не рекламировать какое-то облако, то можно смело сказать, что подобные инструменты есть не у всех, но у многих.
Благодарю за комментарий. По названию, посмотрим, может оно ещё будет претерпевать изменение, поживём, увидем)
В целом, соглашусь, частично, основываясь теми же принципами и опытом, ход моих мыслей был схож.
По вопросам: 1. "Привлечение людей на проекты в виде аллокации" - есть Х количество проектов или систем, есть кросс-служба DevOps, в которой Y количества людей. Есть понятие FTE, которыми исчисляются эти люди, например, их 5, а проектов 10, при равномерном распределении, хотя такое бывает не всегда, это будет 1 человек на 2 проекта, то есть по 0,5 fte на проект и т.д. Всё это на постоянной основе контролируется, например, раз в квартал, и обсуждается с владельцами или продактами/техруками проектов/систем. В данном варианте нужен понятный механизм и набор инструментов расчёта аллокации ресурсов с использованием, например, jira tempo teams + jira folio + jira timesheets., которые помогут эти аллокации контролировать.
"Аллокация на вид работ по какой‑то системе" - есть Х количество проектов или систем, есть кросс служба DevOps, в которой Y количества людей. При этом, в отличие от пункта выше, постоянной, например, ежеквартальной аллокации от службы на проекты/системы нет, либо она минимальна, но есть, в случае необходимости, временное привлечение, для решения одной или нескольких задач. Например, на системе О нам надо внедрить CI/CD, обучить разработчиков и тестировщиков этим пользоваться (передать компетенции) и всё. Служба осуществляет необходимый пул работ и далее у неё лапки. И она привлекается только для дополнительных консультаций или развития ранее разработанного механизма, но не на постоянной основе.
"Использование конкретной работы «под ключ»" - тут ближе к п.2, но в том отличие, что вообще нет постоянных аллокаций на проекты и системы, а только привлечение на точечные виды рад раз в квант времени.
Пожалую, дополю этим статью, спасибо)
2. В теории, может быть, хотя я таких рабочих реализаций в своём опыте не встречал. На практике же Вы будете замкнуты в себе и не прозрачны, а при коммуникации с другими подразделениями, у вас постоянно будут расхождения в процессах, что будет увеличивать время на коммуникацию, и как результат, даст совокупную просадку по t2m. Поэтому, подобные истории и внедряются на уровне, если не компании, то всего ИТ. Про матричную структуру, возможно, но тут сложно сказать без контекста.
Определение действительно потерялось при переносе статьи, добавим. Над заголовком, подумаем. Про формулировки, как и говорил выше, есть устоявшиеся термины, а есть те, которые интерпретируем каждый по своему. Что я имею ввиду в плане разночтения формулировок, это очень хорошо и подробно освещает Игорь Курочкин в своём докладе - https://devoops.ru/talks/46d375e0ad234521a70e6ef6953efc20/?referer=/schedule/days/
Если кратко, то есть разные сообщества, в том числе в мире DevOps, которые больше нацелены на решения точечных проблем и задач, именно они и интерпретируют эти определения по разному. И тут, как я говорил Выше, скорее всего в части вопросов, наши мнение могут не сойтись. Благодарю за интересную дискуссию.
Добрый день. Спасибо за Ваш комментарий. В данной статье описан подход, сформулированный на базе личного опыта на примере внедрения в компанию Bimeister. Признанный решить ряд существующих проблем до внедрения. Тут речь не только о "наведении порядка" в подразделении, но и в процессах разработки компании. И, прежде всего, в статье речь про процессы, не только про технологии.
Организовать службу (в терминах ITSM) и воплотить (S/D)aaS - это вообще про разное.
Всё верно, тут и не утверждается обратного.
Обращу внимание, что речи про CMMI тут нет, так же как и devops governance, но пересечения возможны. Так же отмечу, что проблема современного восприятия DevOps в том, что он везде трактуется по разному, от сообщества DORA с их state of devops до DASA DevOps радара. И каждый понимает это по своему, поэтому сказать - "Я тут нагуглил определение и оно расходиться с Вашим" - попросту не объективно, потому как каждый его понимает по своему и Вы лишь нашли одну из интерпретаций в сети.
По поводу источников, которые я привожу в пример - это трактаты того времени, в которых, на мой взгляд, есть крупица зарождения одной из реализаций подхода DevOps as a Service. И надо понимать, что в статье это прямо не говориться, но общий смысл и выводы идут именно в эту сторону. Поэтому рекомендую ознакомиться со статьями целиком на английском языке, а не выдёргивать фразы из контекста, которые можно интерпретировать по разному.
Что касается DaaS - реализация может быть, как в процессах и стеке on-prem, как и в нашем случае, так и в облаках. При этом нельзя забывать про подход Devops as a platform, который с DaaS имеет очень много пересечений и до сих пор идут споры по их реализации в тех же облаках. Поэтому, на мой взгляд, это вопрос восприятия и дискутировать тут можно бесконечно, каждый останется при своём мнении.
В последующих статьях из этого цикла будут описаны точечные решения проблем, как путём изменением процессов, так и техническими реализациями.
Добрый день. Под "сервисным DevOps" я подразумевал кросс службу DevOps в компании, которая ведает всем инфраструктурным пластом вокруг CI/CD, а так же помогает подразделениям dev и qa в troubleshooting, rnd решений, внедрению новых технологий. Поэтому, на мой взгляд, данное подразделение находится в контексте.
Что касается решения, то надо исходить из личных знаний и опыта, а так же тем, что предлагает рынок в виде решения той или иной проблемы исходя из источников - книги, статьи, конференции и т.д. Т.к. на большинство проблем уже есть решения и не надо изобретать велосипед, чтобы закрыть тот или иной вопрос.
В последующих статьях будут описаны варианты решений тех проблем, что описаны тут. Поэтому, следите за новостями)
На самом деле, это не совсем так. Т.к. данное направление зарождалось с процессами и инструментами того времени, которые постепенно сменялись на те, что мы видим сейчас. С одной стороны, да, можно внедрить свою версию подхода на своих инструментах, но с точки зрения процесса, это получиться скорее не devops в классическом понимании, а под себя заточенный agile. Поэтому, это весьма дискуссионный вопрос, о котором можно много спорить)
Как показывает практика общения в кулуарах на конференциях, какие-то практики до сих пор люди понимают для себя по разному, отсюда и такое начало. Что касается было/стало, в будущем планируются статьи на тему различного рода разбора подобных кейсов. Один из них рассмотрен тут - https://youtu.be/8X94vOuwrVw
Это крутой подход к формированию команды, который действительно работает. В игре познаёшь людей с разных сторон, раскрываешь их, раскачивая софт-скиллы, которые могли спать.
Тут речь не про админов, а про евангелистов и инженеров devops, которые могут повлиять на движение компании и изменение процессов в ней. Всё-таки тут речь не только о классических инженерах, которые могут только в технику, а про тех, кто может повлиять на улучшение процессов в компании и которые могут работать сообща с бизнесом, развивать его с технологической и процессуальной точек зрения.
Добрый день, просьба пояснить, что имеется ввиду :)
Добрый день.
Оркестрация - это термин относящийся к технологии, на базе которой построен Штурвал. Оркестратор - инструмент управления, в нашем случае, кластерами K8s. Это если совсем коротко.
Веду к тому, что совпадения с музыкальной терминологией это совпадение и не более того. Комментарий не очень по делу)
Спасибо за интересный и подробный обзор, теперь стало ясней где в каком случае что применять на практике)
Добрый день.
Это обзорная статья про практики DevOps и фреймворки, которые можно использоваться в зависимости от потребности, основанная на личном опыте работы в разных компаниях без фокуса на какую-то одну.
Очень интересное применение RCA подхода, не всё же проводить расследования по тикетам ИТ и сбоям в инфраструктуре. Есть вопрос, почему использовался именно подход из 6 вопросов? Поясню, есть 3 реализации фреймворка от 4 до 6 вопросов, и наиболее распространённый из 5, которые сводятся к:
•Определить проблему и ее влияние;
•Сбор данных;
•Анализ проблемы;
•План действий;
•Стандартизация.
Так же, как предложение - добавить к статье материалы в виде доп источников, чем вдохновлялся автор при написании статьи, помимо собственного опыта.
Коротко и ясно) На мой взгляд, я бы расширил вопросы в конце неким опрос или чек-листом, который помог бы коллегам из комьюнити переиспользовать подход с более практической, а не теоритической точки зрения.
В целом, это тоже рабочая история. Тут дело вкуса и компетенций по работе с тем или иным инструментом. Если не рекламировать какое-то облако, то можно смело сказать, что подобные инструменты есть не у всех, но у многих.
Благодарю за комментарий. По названию, посмотрим, может оно ещё будет претерпевать изменение, поживём, увидем)
В целом, соглашусь, частично, основываясь теми же принципами и опытом, ход моих мыслей был схож.
По вопросам:
1. "Привлечение людей на проекты в виде аллокации" - есть Х количество проектов или систем, есть кросс-служба DevOps, в которой Y количества людей. Есть понятие FTE, которыми исчисляются эти люди, например, их 5, а проектов 10, при равномерном распределении, хотя такое бывает не всегда, это будет 1 человек на 2 проекта, то есть по 0,5 fte на проект и т.д. Всё это на постоянной основе контролируется, например, раз в квартал, и обсуждается с владельцами или продактами/техруками проектов/систем. В данном варианте нужен понятный механизм и набор инструментов расчёта аллокации ресурсов с использованием, например, jira tempo teams + jira folio + jira timesheets., которые помогут эти аллокации контролировать.
"Аллокация на вид работ по какой‑то системе" - есть Х количество проектов или систем, есть кросс служба DevOps, в которой Y количества людей. При этом, в отличие от пункта выше, постоянной, например, ежеквартальной аллокации от службы на проекты/системы нет, либо она минимальна, но есть, в случае необходимости, временное привлечение, для решения одной или нескольких задач. Например, на системе О нам надо внедрить CI/CD, обучить разработчиков и тестировщиков этим пользоваться (передать компетенции) и всё. Служба осуществляет необходимый пул работ и далее у неё лапки. И она привлекается только для дополнительных консультаций или развития ранее разработанного механизма, но не на постоянной основе.
"Использование конкретной работы «под ключ»" - тут ближе к п.2, но в том отличие, что вообще нет постоянных аллокаций на проекты и системы, а только привлечение на точечные виды рад раз в квант времени.
Пожалую, дополю этим статью, спасибо)
2. В теории, может быть, хотя я таких рабочих реализаций в своём опыте не встречал. На практике же Вы будете замкнуты в себе и не прозрачны, а при коммуникации с другими подразделениями, у вас постоянно будут расхождения в процессах, что будет увеличивать время на коммуникацию, и как результат, даст совокупную просадку по t2m. Поэтому, подобные истории и внедряются на уровне, если не компании, то всего ИТ.
Про матричную структуру, возможно, но тут сложно сказать без контекста.
Определение действительно потерялось при переносе статьи, добавим.
Над заголовком, подумаем.
Про формулировки, как и говорил выше, есть устоявшиеся термины, а есть те, которые интерпретируем каждый по своему.
Что я имею ввиду в плане разночтения формулировок, это очень хорошо и подробно освещает Игорь Курочкин в своём докладе - https://devoops.ru/talks/46d375e0ad234521a70e6ef6953efc20/?referer=/schedule/days/
Если кратко, то есть разные сообщества, в том числе в мире DevOps, которые больше нацелены на решения точечных проблем и задач, именно они и интерпретируют эти определения по разному. И тут, как я говорил Выше, скорее всего в части вопросов, наши мнение могут не сойтись.
Благодарю за интересную дискуссию.
Благодарю за комментарий, подумаем, может изменим в будущем.
Добрый день.
Спасибо за Ваш комментарий.
В данной статье описан подход, сформулированный на базе личного опыта на примере внедрения в компанию Bimeister. Признанный решить ряд существующих проблем до внедрения. Тут речь не только о "наведении порядка" в подразделении, но и в процессах разработки компании. И, прежде всего, в статье речь про процессы, не только про технологии.
Всё верно, тут и не утверждается обратного.
Обращу внимание, что речи про CMMI тут нет, так же как и devops governance, но пересечения возможны. Так же отмечу, что проблема современного восприятия DevOps в том, что он везде трактуется по разному, от сообщества DORA с их state of devops до DASA DevOps радара. И каждый понимает это по своему, поэтому сказать - "Я тут нагуглил определение и оно расходиться с Вашим" - попросту не объективно, потому как каждый его понимает по своему и Вы лишь нашли одну из интерпретаций в сети.
По поводу источников, которые я привожу в пример - это трактаты того времени, в которых, на мой взгляд, есть крупица зарождения одной из реализаций подхода DevOps as a Service. И надо понимать, что в статье это прямо не говориться, но общий смысл и выводы идут именно в эту сторону. Поэтому рекомендую ознакомиться со статьями целиком на английском языке, а не выдёргивать фразы из контекста, которые можно интерпретировать по разному.
Что касается DaaS - реализация может быть, как в процессах и стеке on-prem, как и в нашем случае, так и в облаках. При этом нельзя забывать про подход Devops as a platform, который с DaaS имеет очень много пересечений и до сих пор идут споры по их реализации в тех же облаках. Поэтому, на мой взгляд, это вопрос восприятия и дискутировать тут можно бесконечно, каждый останется при своём мнении.
В последующих статьях из этого цикла будут описаны точечные решения проблем, как путём изменением процессов, так и техническими реализациями.
Добрый день.
Под "сервисным DevOps" я подразумевал кросс службу DevOps в компании, которая ведает всем инфраструктурным пластом вокруг CI/CD, а так же помогает подразделениям dev и qa в troubleshooting, rnd решений, внедрению новых технологий. Поэтому, на мой взгляд, данное подразделение находится в контексте.
Что касается решения, то надо исходить из личных знаний и опыта, а так же тем, что предлагает рынок в виде решения той или иной проблемы исходя из источников - книги, статьи, конференции и т.д. Т.к. на большинство проблем уже есть решения и не надо изобретать велосипед, чтобы закрыть тот или иной вопрос.
В последующих статьях будут описаны варианты решений тех проблем, что описаны тут. Поэтому, следите за новостями)
Крутая статья, интересно было почитать, спасибо.
Все очень круто расписано, респект автору!
На самом деле, это не совсем так. Т.к. данное направление зарождалось с процессами и инструментами того времени, которые постепенно сменялись на те, что мы видим сейчас.
С одной стороны, да, можно внедрить свою версию подхода на своих инструментах, но с точки зрения процесса, это получиться скорее не devops в классическом понимании, а под себя заточенный agile.
Поэтому, это весьма дискуссионный вопрос, о котором можно много спорить)
Да, это вполне можно трактовать таким образом, но я постарался раскрыть ряд практик, которые не так широко распространены в DevOps)
Как показывает практика общения в кулуарах на конференциях, какие-то практики до сих пор люди понимают для себя по разному, отсюда и такое начало.
Что касается было/стало, в будущем планируются статьи на тему различного рода разбора подобных кейсов. Один из них рассмотрен тут - https://youtu.be/8X94vOuwrVw
Это крутой подход к формированию команды, который действительно работает.
В игре познаёшь людей с разных сторон, раскрываешь их, раскачивая софт-скиллы, которые могли спать.
Тут речь не про админов, а про евангелистов и инженеров devops, которые могут повлиять на движение компании и изменение процессов в ней.
Всё-таки тут речь не только о классических инженерах, которые могут только в технику, а про тех, кто может повлиять на улучшение процессов в компании и которые могут работать сообща с бизнесом, развивать его с технологической и процессуальной точек зрения.
Auto Testing