Comments 10
А как сервисный DevOps отдел узнает о проблемах, если он находится вне контекста этих проблем? Соответственно следующий вопрос - как этот отдел выберет правильное решение из множества? Если будет советоваться с руководством и тимлидами - так это не у них проблемы...
Добрый день.
Под "сервисным DevOps" я подразумевал кросс службу DevOps в компании, которая ведает всем инфраструктурным пластом вокруг CI/CD, а так же помогает подразделениям dev и qa в troubleshooting, rnd решений, внедрению новых технологий. Поэтому, на мой взгляд, данное подразделение находится в контексте.
Что касается решения, то надо исходить из личных знаний и опыта, а так же тем, что предлагает рынок в виде решения той или иной проблемы исходя из источников - книги, статьи, конференции и т.д. Т.к. на большинство проблем уже есть решения и не надо изобретать велосипед, чтобы закрыть тот или иной вопрос.
В последующих статьях будут описаны варианты решений тех проблем, что описаны тут. Поэтому, следите за новостями)
Прочитал в заголовке "DevOps as a Service" и пришел почитать именно об этом. О том как любые желающие команды, у которых еще нет никакого DevOps, захотели себе внедрить типовые пайплайны и метрики, куда-то зашли, что-то нажали и у них раскатался из образа контур CI, что-то для CD, какой-то номинальный мониторинг. А прочитал про то, как навести порядок в отделе, где не было никакой управляемости.
Организовать службу (в терминах ITSM) и воплотить (S/D)aaS - это вообще про разное.
Исследование на тему "может это я тупой" по-быстрому нагуглило такое определение
DaaS - "devops as a service" - это такой преднастроенный (но конфигурируемый если надо) набор компонентов, позволяющих быстро организовать "devops".
Да! Это не про подъем с 1го на 2й/3й уровень CMMI. Это про
Программное обеспечение как услуга (software as a service, SaaS) — это облачная модель предоставления ПО, при которой поставщик услуг разрабатывает облачное ПО, обеспечивает его обслуживание, автоматическое обновление и доступность и предоставляет такое ПО заказчикам через Интернет за оплату, пропорциональную объемам использования. src
только про пайплайны туда и обратно.
2018 in review: State of DevOps adoption
Не нашел там никаких "DaaS", "as a service", нашел те же буквы и рассуждения, что есть в "Accelerate" про "High performers vs Low performers". Про то что DevOps помогает. Про DevOps в целом.
Со второй ссылкой
“DevOps as a Service or Do You Really Need a DevOps Team”
Лично мне еще более не понятно, что там происходит и возможно у меня действительно какие-то сложности с буквами:
DaaS is a delivery model that in its core implies to store all the development tools in the cloud platform to make certain that developers use a common toolset and all of the actions are tracked.
Отсюда можно вырулить на "развертывание по требованию", но я не очень понимаю, чего именно. "Development tools in the cloud platform" - рабочие места в облаке, RDP и только те devtools, которые там установлены? Допускаю, но это даже не DevOps, не то что следующий уровень.
With DaaS, you get a dedicated DevOps team that provides developers with documentation and mentorship for helping your in-house IT department to learn new tools and systems.
By using cloud services, everything becomes more data-driven so the team uses the same dataset. This service provides better documentation and quality control.
Автор той статьи, видимо, рассуждает о том, как уйти от вашей локальной толпы велосипедов с толпой же штатных DevOps-инженеров к CI/CD решениям, работающим в облаках (а-ля Azure DevOps). Т.е., пользуясь предложенной терминологией, воспользоваться чьим-то DaaS, а не реализовать какой-то свой.
В вашей статье никаких рассуждений об автоматизации развертывания DevOps-пайплайнов не вижу, только наведение порядка в управлении службой DevOps в терминах ITSM, установление правил и границ.
Если материал про некий DaaS все-таки есть, то было бы здорово увидеть это в статье, в противном случае, возможно стоит скорректировать заголовок и неуместные упоминания "as a service" устранить, оставить только упоминания самого 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 имеет очень много пересечений и до сих пор идут споры по их реализации в тех же облаках. Поэтому, на мой взгляд, это вопрос восприятия и дискутировать тут можно бесконечно, каждый останется при своём мнении.
В последующих статьях из этого цикла будут описаны точечные решения проблем, как путём изменением процессов, так и техническими реализациями.
Я тут нагуглил определение и оно расходиться с Вашим
Приводить результаты гугления пришлось, поскольку вы не дали никакого определения, принятого хотя бы в вашем коллективе.
> Организовать службу (в терминах ITSM) и воплотить (S/D)aaS - это вообще про разное.
Всё верно, тут и не утверждается обратного.
Вынужден повториться: у вас заголовок про некий DaaS, а статья про организацию службы (в терминах ITSM), в связи с чем и возник комментарий с вопросами.
2 принцип. Подразделение DevOps представляет из себя сервисную службу.
Это - про ITSM.
4 принцип - Контроль за качеством (MTTD, MTTR, MTTF).
Это - просто DevOps. DORA и DevOps Radar не вводят никаких видов DevOps. Это сам DevOps и есть.
Вы из бардака с постановкой задач делаете просто нормальное подразделение с нормальным управлением, которое занимается решением DevOps задач. Для этого не нужно придумывать новых терминов и вводящих в заблуждение аббревиатур.
Определение действительно потерялось при переносе статьи, добавим.
Над заголовком, подумаем.
Про формулировки, как и говорил выше, есть устоявшиеся термины, а есть те, которые интерпретируем каждый по своему.
Что я имею ввиду в плане разночтения формулировок, это очень хорошо и подробно освещает Игорь Курочкин в своём докладе - https://devoops.ru/talks/46d375e0ad234521a70e6ef6953efc20/?referer=/schedule/days/
Если кратко, то есть разные сообщества, в том числе в мире DevOps, которые больше нацелены на решения точечных проблем и задач, именно они и интерпретируют эти определения по разному. И тут, как я говорил Выше, скорее всего в части вопросов, наши мнение могут не сойтись.
Благодарю за интересную дискуссию.
Статья-то неплохая, спасибо, что делитесь опытом, блок-схемы интересные, но согласен название - муть.
Эх, жаль, что из заголовка ушло DevOps as a Service - первое, на что я среагировал, поскольку именно эту тему сейчас прорабатываем.
Как по мне, так вполне справедливо употребление этого термина, в первую очередь в связи одним из наиболее частных пунктов во внедрении devops методологии/ принятия devops культуры (как хотите называйте) - ops-инженеры и разработчики становятся частью одной команды. Выделение неких "devops" инженеров в отдельную структуру может и будет воспринято как отхождение от принципов devops и возврат к классической функциональной структуре. И Devops as a service, на мой взгляд, это попытка:
а) решить проблему сегментации тех. опыта и шаринга знаний при невозможности насытить инфраструктуру (читай - каждую команду каждого продукта) необходимым кол-вом инженеров
б) взять лучшие наработки ITSM и подружить их с принципами devops - полностью отвергать предыдущий опыт, на мой взгляд, неправильно
в) показать, как может выглядеть адаптация devops методологии в организациях, на которых переиспользование опыта того же amazon или netflix будет слишком травматичным из-за чего от реализации хоть чего-то из стека devops просто откажутся.
Саш, к тебе пара вопросов:
«В зависимости от наличия или отсутствия проектного офиса, продуктовой фабрики, особенностей процессов компании, служба может работать по разному. Это может быть:
привлечение людей на проекты в виде аллокации;
аллокация на вид работ по какой‑то системе;
использование конкретной работы «под ключ».
Мог бы ты раскрыть этот пункт - как могут выглядеть работы в рамках DaaS. Мне тут видятся следующие основные риски:
Как не скатиться обратно к матричной модели, т.е. выделению инженера на проект на постоянку?
Как быть с maintanence-задачами? Да, мы сделали проект под ключ, набодяжили там мониторинг, обучили людей как с этим работать. Но так или иначе что-то там будет ломаться, что-то потребует постоянного контроля со стороны [dev]ops-инженеров - не все получится отдать разработчикам/тестировщикам с концами. Должно ли это выглядеть как "подписка на сервис" - т.е. от DaaS это будет как постоянная услуга, а все остальное - кто выполняет, как выполняет - под капотом сервиса, как в ITSM?
"И делаете большую презентацию на уровне компании. Почему так широко? Потому что, как правило, данное внедрение осуществляется на уровне компании, а не просто на примере небольшого подразделения, ибо все участники цикла разработки должны начать жить по новому процессу, иначе это работать не будет."
Могут ли все же, пусть с некими ограничениями, и, возможно, с меньшим положительным эффектом, существовать реализации подобного на масштабе подразделения? Сейчас мне видится DaaS как реальная альтернатива матричной структуре в условия ограниченных людских ресурсов (и ограниченных админ.ресурсов, чего уж греха таить).
Благодарю за комментарий. По названию, посмотрим, может оно ещё будет претерпевать изменение, поживём, увидем)
В целом, соглашусь, частично, основываясь теми же принципами и опытом, ход моих мыслей был схож.
По вопросам:
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. Поэтому, подобные истории и внедряются на уровне, если не компании, то всего ИТ.
Про матричную структуру, возможно, но тут сложно сказать без контекста.
Магия внедрения сервисного подхода DevOps. Часть 1. Развиваем культуру коммуникации и разработки в компании