Привет, Хабр! Сегодня мы расскажем о том, как подходили к созданию сообщества практики по автоматизации DevOps CI/CD в Сбере. Рассмотрим предпосылки, методологии и лучший мировой опыт, который использовали, а также ключевые проблемы и ошибки. В этой статье опытом делится Рашид Галиев – руководитель группы развития методологии DevOps и внедрения инженерных практик CI/CD, эксперт команды ядра сообщества DevOps в Сбере.
Начну с цифр и предпосылок: у нас порядка 16000 инженеров разных ролей и областей экспертизы, около 3000 продуктовых команд, большое количество систем со своим независимым релизным циклом и достаточно много внедрений в месяц.
Топология команд
Как можно заметить, объемы работы достаточно большие, равно как и количество участвующих людей. Но я сосредоточусь на цифре в 16000 инженеров, так как сообщество практики мы создаем в первую очередь для них.
Люди формируют команды, поэтому остановлюсь немного на топологиях команд. Для них сформировалась вполне каноническая структура: есть большие бизнес-темы, в этих бизнес-темах есть трайбы, в трайбах – продуктовые команды.
Когда в компании произошел старт DevOps-трансформации и началось внедрение автоматизации CI/CD, в результате такого масштабного движения сформировались достаточно типовые антипаттерны топологий команд с точки зрения DevOps-практик.
При этом топологии команд встречаются разные, накопление и развитие определенной экспертизы осуществляется либо выделенными функциями, либо отдельными ролями участников команд.
Есть ситуация, когда автоматизация CI/CD в трайбе выглядит как сервис, предоставляемый отдельной выделенной командой для всего трайба. Другая ситуация, когда в командах появляются выделенные люди, которые берут на себя роль по развитию автоматизации CI/CD.
Еще встречается, когда Dev формируют объединенную команду и развивают практики CI/CD для всего трайба. И обратная ситуация, когда практику развивают командные роли Ops-инженеров.
Также есть подразделение Security-кибербезопасности, развивающее инновационные практики, в частности DevSecOps. Эти практики транслируются в команды и становятся неким вызовом, так как их необходимо имплементировать в процессы команд и применять на практике.
Мы движемся к «идеальному миру», чтобы в каждом трайбе, в каждой команде появилась роль и компетенция Security Champion, который стал бы агентом изменений DevSecOps-практик в командах. Пока инициативы DevSecOps-практик выглядят как внешняя история, которая приходит в команды.
Ключевые проблемы
К чему это все в совокупности привело и какая характерная ситуация возникла для существующих команд:
появилось огромное количество различных реализаций CI/CD;
в Confluence возникло много разрозненных источников информации с разными how-to-статьями, CookBook-ами, инструкциями под каждый продукт и команду;
команды состоят из сотрудников, имеющих разный уровень инженерной зрелости;
нет единого места для обмена опытом и знаниями. В результате у команд низкая осведомленность о формальных требованиях и существующих лучших практиках;
в процессе активной работы люди не могут посвятить достаточное количество времени на обмен опытом, своими наработками, практиками друг с другом.
Таким образом, можно сказать, что в целом команды имели низкий уровень осведомленности о существующих лучших практиках, подходах и стандартах, которые они могли бы применять в своей работе.
Раньше, новые команды и сотрудники сталкивались со следующими сложностями:
длительная адаптация и порог входа;
много разнообразной информации, инструкций how-to;
не всегда имели возможность получить оперативную помощь по возникающим вопросам и проблемам.
Другими словами, можно сказать, что нет так называемой единой точки правды, которая содержит актуальную и исчерпывающую информацию, а также нет возможности ее получить в случае возникновения каких-либо трудностей.
К чему мы пришли
После осмысления этих ключевых проблем возникло понимание необходимости создания площадки для обмена опытом, через которую сотрудники получат возможность меняться практическими наработками и вместе успешно решать возникающие проблемы и вопросы.
DevOps CI/CD сообщество практики
Данная площадка, в нашем понимании, должна быть представлена сообществом практики в домене экспертизы DevOps CI/CD, главной целью которого является обмен практическими наработками. Эксперты и участники из каждой команды и трайба могут войти в сообщество, чтобы внести свой вклад в его развитие.
Ключевые аспекты
Далее рассмотрим методологию и лучшие мировые практики по созданию и развитию сообществ. В русскоязычном сегменте практически нет информации по методологии развития сообществ практики. Поэтому все материалы лучше искать в англоязычном пространстве.
Жизненный цикл сообщества
Согласно существующим методологиям, жизненный цикл развития сообществ состоит из пяти ключевых этапов. Их названия могут отличаться в зависимости от конкретной методологии.
Согласно приведенной выше схеме, на начальных этапах жизни сообщества придется вложить массу сил и времени в его становление.
На четвертом-пятом этапе существования произойдет формирование главной ценности этого сообщества и максимизация отдачи от него. Кроме того, на последнем этапе начнется возникновение новых подсообществ, которые будут развивать узкие темы экспертизы основного сообщества. В результате произойдет митоз одного сообщества в несколько самостоятельных.
Ожидаемые результаты развития сообщества на разных этапах жизненного цикла можно посмотреть в таблице, представленной ниже:
Факторы вовлечения участников
Согласно методологии, существует шесть факторов для вовлечения участников в активное взаимодействие с сообществом. Человек хочет прийти в него, чтобы повысить свои навыки, инженерную зрелость, компетенции. Чтобы он мог их проявить, ему нужно дать какую-то задачу в сообществе.
Соответственно, следует предложить участникам сообщества вызовы, соревнования, интересные задачи, эксперименты и т. д. За достижения они должны получать какие-то «плюшки», поэтому нужно предусмотреть систему поощрений. За вклад участника в сообщество ему также нужно давать что-то взамен, например поощрение или признание.
Другими словами, участник должен прозрачно ощущать свой прогресс и чувствовать, что сообщество обеспечивает его определенным признанием.
Если разложить все шесть факторов по важности, то «Признание» является наиболее существенным и занимает в мотивации людей 90 %, поэтому механизму системы признания и поощрений нужно уделить максимум внимания при проработке сообщества. Остальные люди хотят быть вместе с лучшими, а человек, который много вкладывает, желает получать от сообщества мотивацию и обратную ценность.
Модель участник vs сторонник
Во многих методологиях говорится о двух моделях. Одна из них рассматривает сообщество как элитарное и закрытое, некую «Лигу плюща». Данный подход является устаревшим, так как в его рамках люди только потакают своему эго, и это, к сожалению, не приносит какую-либо пользу сообществу и широким слоям его участников.
Современная же модель представляет сообщество как самоорганизующийся механизм, в котором отсутствуют жесткие критерии и требования для участия, а членом сообщества может стать кто угодно. Люди хотят становится его участниками ради какой-то большой миссии. Сторонник приходит в сообщество и делает свой вклад. Нет никакого внешнего давления и директивных указаний. Активность сообщества направлена не только внутрь на участников, но и на трансляцию основной цели и миссии сообщества во вне для привлечения еще больших масс заинтересованных энтузиастов. Связи внутри сообщества строятся на совместных активностях, проектах и экспериментах.
Главные заблуждения при создании сообщества
Первое заблуждение: для создания успешного сообщества необходимо просто собрать в кучу некие инструкции, wiki, how-to, и вокруг этого объема информации сформировать костяк участников. К сожалению, данный подход не работает, так как существуют явные и скрытые знания. Несмотря на то, что, как правило, явные знания обычно хорошо задокументированы, всегда существует объем скрытых знаний, базирующихся на существующих в любом знании нюансах, которые можно выявить только при совместной практике с привлечением и поддержкой экспертов – носителей этих скрытых знаний.
Согласно статистике, сотрудник в среднем находится в компании 4,4 года. Поэтому необходимо организовать такую систему передачи скрытых знаний, чтобы он не ушел с ними из компании.
Второе заблуждение: сообщества в компаниях обычно создаются, основываясь на инициативе HR, нацелены на развитие компетенций, улучшение процесса найма, проведение профоценок. Однако нельзя забывать про два важнейших фактора, которые существуют помимо компетенций, – единство и автономность.
Под единством подразумевается, что человек попадает в комфортное пространство, безопасную группу, где люди занимаются экспериментами, никто никого не критикует и существуют возможности для раскрытия. Поэтому очень важно создавать комфортную и дружескую атмосферу в сообществе.
Вспоминаем модель сторонника. Сообщество должно быть автономным и самоорганизующимся, где каждый участник может делать что ему нравится, отсутствуют директивные указания, каждый влияет на то, что происходит в сообществе.
Безусловно, компетенции никуда не деваются – нужно профессионально развивать участников, разрабатывать обучающие курсы, активности, чтобы человек мог ощущать свой прогресс. Это уже более прагматичные цели сообщества.
Роли сообщества
Посмотрим внимательно на схему, где отражены роли и позиции сообщества.
Наверху перечислен ряд типовых задач для участников сообщества. Все, что ниже белой пунктирной линии – позиции. Основатель и менеджер сообщества должны быть выделены как отдельные позиции, так их очень сложно совмещать с основной деятельностью.
Все, что выше, это уже роль, она совмещается с какой-то основной деятельностью. Внизу у нас область основателей, вверху область сторонников. На моменте зарождения сообщества основатель и менеджер должны приложить максимум усилий, чтобы в выделенной красной линией области появились эксперты ядра сообщества, волонтеры, которые будут помогать с организационной составляющей, и эксперты от команд, транслирующие информацию дальше в команды и трайбы.
Типы участников сообщества
Рассмотрим разные типы участников сообщества и их критерии. Всего выделяют четыре типа участников: посетитель, участник, активный сторонник и участник core-team. Ключевые критерии этих типов представлены на схеме ниже.
Нюанс, который здесь следует отметить, заключается в том, что только активные сторонники хотят развивать лучшие практики, вкладываться в жизнь сообщества. Не стоит ожидать того, что обычные посетители за короткое время превратятся в активных участников, поэтому только 10 % становятся активными участниками сообщества, и только 1 из 50 становится активным сторонником через 6 месяцев.
Поэтому если в поле зрения попадается человек с горящими глазами, нужно сделать все возможное, чтобы он стал одним из экспертов ядра* или активным участником, волонтером.
Важным моментом является выделение в рамках core-команды небольшого ядра, которое будет заниматься только сообществом все свое рабочее время. Этому надо уделить пристальное внимание, так как если не будет постоянно работающего над сообществом основного ядра, оно может просто прекратить свое существование.
Кроме того, необходимо учитывать, что люди обычно боятся принимать решения и делать первый шаг, долго присматриваются, не знают, что можно, а что нельзя. C этим надо активно бороться: мотивировать сделать первый шаг, задать первый вопрос, написать первую статью, выступить на митапе и т. д.
С чего начинается сообщество
Когда мы создавали свое сообщество в Сбере, мы пошли по трайбам и командам, начали искать экспертов, желающих участвовать на старте сообщества, придумали концепцию, определили ряд ключевых задач.
Очень важно на старте придумать классную концепцию того, что мы будем делать с группой участников, готовых быть в экспертном ядре, кому не все равно.
Запуск сообщества
При запуске сообщества мы провели большой митап, на начальном этапа команда ядра была представлена 10 участниками. Это были самые заряженные люди, которые действительно хотели перемен и улучшений. На митапе рассказали, что мы хотим делать и зачем, обозначили фокус сообщества. Объяснили, что что мы создаем сообщество практики для обмена опытом, а не для найма сотрудников.
Так как мы осознавали, что основной проблемой является длительный порог входа новых команд, то решили сосредоточиться именно на них. Поэтому первые наши усилия были сосредоточены на создании пошаговых подробных инструкций, детальнейших how-to, формировании площадки для обмена опытом и поиске ответов на вопросы. Мы занимались проработкой болей, чтобы побороть длительный порог входа.
Основные площадки сообщества
Что касается базы знаний, то мы сформировали ее на основе вики-системы Confluence. Выбор системы продиктован стеком инструментов, уже использующихся в компании. Таким образом, база знаний сообщества становится дополнением к уже существующей, доступной системе.
Любой участник может прийти в бэклог статей how-to и докладов, обозначить потребность в материале или желание написать статью на определенную тему, провести какой-либо митап. Остальные участники голосуют, определяется приоритет материалов, затем сотрудники берутся за материалы, получившие наибольшее количество голосов.
Таким образом устраняется риск, что некто сможет искусственно «прокачивать» свой рейтинг, массово генерируя никому не нужные статьи, поэтому участники берутся работать только над теми темами, которые интересны сообществу и за которые проголосовали его участники.
То есть основной контент сообщества генерируется его участниками, в отличие от стандартного старого подхода, когда за генерацию основного контента отвечает подразделение, занимающееся соответствующей методологией в рамках компании.
Здесь особо необходимо отметить следующие моменты:
должен быть запущен landing page для новичков. Таким образом, любой человек, приходящий в сообщество в первый раз, должен сначала открыть лендинг, откуда он узнает, куда он попал, зачем, какие пять шагов необходимо сделать, чтобы стать участником сообщества;
необходимо создать матрицу по компетенциям и экспертам, чтобы участники могли знать, к кому можно обратиться с конкретным адресным вопросом;
нужно вести рейтинг вкладов участников.
Остальные площадки
Отдельный чат команды ядра сообщества для стратегического планирования развития.
Общий чат всех участников для оперативной связи и помощи.
Сбервидео – внутренний видеохостинг, где выкладываем записи митапов, интервью, подкастов.
Корпоративная почта для информирования и рассылок.
Bootcamp – платформа обучения и тестирования. Туда приходят все новые сотрудники компании, чтобы пройти onboarding и адаптационный трек обучения. Это удобная площадка, на которой каждому новому сотруднику можно рассказать о сообществе и пригласить стать его участником. Здесь же сосредоточены программы обучения DevOps.
ZOOM для видеоконференций, митапов и круглых столов с экспертами.
Ценность вклада и активностей участников
Необходимо заранее подумать над тем, как мы будем поддерживать активность участников сообщества.
Обычно сотрудники хотят больше рассказывать о своем личном опыте, высказывать разнообразные мнения, однако такой вклад является наименее ценным с точки зрения сообщества. Поэтому необходимо побуждать людей делать вклад, относящийся больше к верхней части рисунка, чтобы это были какие-то пилотные проекты, эксперименты с конкретными результатами или поддержка (в том числе эмоциональная).
Диаграмма ниже отражает, что нужно сделать, чтобы существующее сообщество затронуло максимальное количество участников. Чтобы реализовать максимальную ценность, лучше всего сосредоточиться на активностях, находящихся в правом верхнем углу.
Основными видами контента сообщества, разделенными по периодичности, являются следующие:
Геймификация и достижения
Чтобы стимулировать активность участников сообщества, необходимо разработать определенную программу достижений и поощрений для удовлетворения главного фактора вовлечения участников – признания за вклад.
Здесь мотивацию можно подразделить на материальную и нематериальную:
в качестве материальной мотивации может выступать разнообразный мерч, подарки и даже то, что может повлиять на годовой финансовый бонус сотрудника;
нематериальной мотивацией является признание в рамках сообщества.
Есть система достижений и система рангов, за которые предусмотрена какая-то награда.
Система достижений может выглядеть, например, следующим образом: Ambassador занимается привлечением новых людей в сообщество, Wikinist пишет статьи, Spokesman участвует в митапах и т. д.
Говоря же о возможных рангах, их можно представить следующим образом:
Например, Common является только что пришедшим человеком. Если он хочет стать Uncommon, ему необходимо написать 2 статьи, выступить один раз на митапе и т. д. Таким образом, можно сказать, что для каждого ранга предусмотрен тот или иной набор достижений.
Основные ошибки
Основными трудностями, с которыми мы столкнулись в процессе создания сообщества, были следующие:
мы полагали, что core-команда сможет совместить участие в сообществе со своей основной деятельностью в компании. Но это оказалось невозможным ввиду потребности в большом вовлечении в жизнь сообщества и отсутствии такого количества времени у основных сотрудников;
во время формирования ключевых задач и концепции общества мы не распределили зоны ответственности по областям экспертизы между участниками команды ядра. Поэтому в результате возникали конфликты, кто какую область возьмет для курирования;
только что пришедшие люди плохо понимали слишком абстрактные и высокоуровневые цели сообщества, которые были больше похожи на лозунги, чем на что-то реально достижимое. Поэтому нам пришлось задуматься об упрощении и детализации, чтобы они были понятны всем, даже новичкам;
при создании площадки мы изначально не провели UI/UX-исследования, и она была сформирована в виде достаточно громоздкой структуры со сложным деревом и глубокой вложенностью материалов;
выявили суть проблемы с невыходом материалов в топ в рамках Confluence. Лайфхак для тех, кто работает с Confluence: необходимо насыщать страницу ключевыми словами и как можно чаще ее редактировать, тогда она будет в топе выдаче Confluence;
производство видео- и аудиоконтента должно быть отдано профессионалам этого дела, так как данный процесс занимает много времени и даже при вложении больших усилий качество результата получается ниже того, что ожидалось;
запускали участников в чат без регистрации в сообществе. Из-за этого многие и не знали, что есть что-то кроме чата;
нужно учитывать, что в рамках больших компаний почтовые рассылки не работают;
были установлены слишком высокие требования к вкладу участников сообщества, так что на каком-то этапе люди поняли, что получение достижений, основываясь на этих требованиях, малореально. Поэтому мы осознали, что необходимо снизить требования.
Промежуточные итоги и планы
В результате наших действий по созданию и развитию сообщества, решению возникших проблем, мы получили следующие промежуточные результаты:
была создана площадка для обмена профессиональной информацией и опытом;
появилась «единая точка правды»;
разработаны подробнейшие how-to (step-by-step) по реализации CI/CD;
появилось место для получения оперативной помощи в решении возникающих проблем;
был снижен временной порог входа для новых сотрудников и команд в 3 раза.
Характеризуя участников сообщества на текущем этапе, можно привести следующую диаграмму:
В наших дальнейших планах следующие шаги по развитию сообщества:
переезд в cloud (перемещение основного пространства сообщества во внешний контур, чтобы оно стало доступно дочерним зависимым организациям);
переформатирование подходов к информированию;
корректировка и упрощение подходов к геймификации;
пересмотр функций и курируемых зон ответственности участников core-команды. Причем здесь DevOps? Возможно, у вас может возникнуть вопрос: «Причем здесь DevOps?» Несколько аргументов на этот счет:
DORA DevOps Report говорит нам, что сообщества практики являются неотъемлемой составляющей sharing фреймворка CALMS развития культуры DevOps; / статья на русском языке.
сообщество было создано в соответствии с классическим подходом DevOps – инициатива снизу вверх, что является составляющей culture фреймворка CALMS;
при желании каждый уже сегодня может стать основателем и лидером сообщества.
В заключение можно сказать, что сообщество практики дает возможности для создания инноваций, применения и развития лучших мировых практик в компании. Оно является основным инструментом накопления, управления и передачи явных и скрытых знаний через обмен опытом и совместную работу, способствует вовлечению существующих команд и распространению среди них лучших практик и наработок, обеспечивает поддержку новых команд и сотрудников, сокращая срок их адаптации в компании, существенно снижая материальные и временные затраты.
Если вы захотите построить свое сообщество практики, кроме нашего опыта, вы можете ознакомиться со следующими ресурсами:
материалами портала по методологии создания сообществ: feverbee.com;
пошаговым руководством по созданию сообществ: tacitlondon.com.
