Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть 1, Часть 2, Часть 3, Часть 4, Часть 5. Сегодня мы обсудим создание площадки обучения DevOps в стенах компании для обмена опытом между коллегами разных подразделений, повышения компетенции и культуры обучения.

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

Какие могут быть предпосылки?

• Разбиение ИТ на развитие/RnD и внедрение/поддержку;

• Резкий рост ИТ в компании с набором большого количества новых сотрудников с рынка;

• Утечка кадров из компании по различным причинам, например, из-за чересчур эффективного менеджмента или сокращений;

• Необходимость повышения компетенций специалистов ИТ из-за роста потребности рынка;

• Прочие.

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

С чего же стоит начать?

Начнём с того, что оглянемся по сторонам и сделаем следующее:

• Попробуем определить активистов из разных подразделений ИТ в компании. Это можно сделать, например, в рамках гильдии DevOps. Если такой нет, то давайте её организуем. Зачем?

  Гильдия DevOps и вообще гильдии – это площадки, на которых можно делиться:

• Опытом;

• Болями других подразделений;

• Последними новостями;

• Планами на будущее – проведением работ, реализацией задач и прочим.

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

Кого стоит привлекать в данную гильдию прежде всего? Конечно же разработчиков, особенно, если вы отвечаете за контур разработки, который, например, находится в том же k8s. Начните с лида разработки, объясните полезность площадки, периодичность, формат и что будете обсуждать. А для пущего эффекта перед каждой встречей объявляйте набор тем для обсуждения, чтобы целевые участники были на встрече. Если вы постоянно взаимодействуйте с командой тестирования, поддерживаете контура тестирования, то первыми эшелонами затягивайте в гильдию тестировщиков, также предварительно это проговорив в лидом или лидами тестирования. Всех остальных - по остаточному принципу или принципу частоты взаимодействия, при этом допустимы и временные участники по экстренным вопросам. Если в вашей компании ранее не было гильдий, то эту практику можно распространить, начиная с вашего подразделения. Например, мы следом сделали гильдию безопасности, где обсуждали все те же насущные вопросы, но в разрезе безопасности и немного с другим составом лиц. Важно, что периодичность встреч подобных гильдий не стоит делать очень часто сразу после внедрения, иначе вы просто будете обсуждать одно и то же, либо это всем скоро надоест. Раз в 2-3 недели - самое то, а на первых парах, пока вопросов много, можно делать более частую периодичность. Если опыт использования гильдий дает результаты, то далее можно создавать гильдии разработки, тестирования и т.д.

• После того, как у нас появилась команда условных активистов, вы услышали их боли, завели задачи, структурировали планы, следует заняться ревью базы знаний. Я сейчас не буду писать большие эпосы про то, как оптимизировать весь confluence компании. Таких материалов много, но, пожалуй, выделю вот этот доклад - Как управлять базой знаний и не сойти с ума. А мы попробуем реализовать оптимизацию и заполнить белые пятна пространства или раздела в пространстве DevOps. Как говориться, всегда начинайте с себя, что мы и сделаем. Но как?

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

Немного поясним каждый из разделов:

• Поскольку мы общаемся с другими подразделениями, пишем им инструкции, повышаем их компетенции (хоть и до площадки обучения, про которую будет сказано позднее, это не поставлено на поток), то раздел инструкций для других отделов с разбивкой по структуре – звучит вполне логично;

• Набор инструкций по онбордингу новых бойцов подразделения;

• Раздел с типовыми проблемами и ошибками, с которыми сталкиваются и могут решить только бойцы DevOps – troubleshooting;

• Раздел со всеми орг вопросами, процессами взаимодействиями, flow, KPI и прочим – это конечно же DevOps management;

• Разбор спринтовых или релизных инцидентов – RCA;

• Стратегия развития – намерено вынесено из management, включает все составляющие планирования на короткие и длинные дистанции. Туда могут входить – NAP, инициативы, roadmap перехода на целевые процессы и ПО и т.д.;

• Описание всего тулсета, его настроек и полезных статей в разделе DevOps our tools manuals;

• И замыкает всё это понятный из названия раздел – наша инфраструктура.

• А вишенкой на торте будет описание всех бойцов подразделения, чтобы народ знал своих героев в лицо, например, вот в таком вот формате ;)

Со структурой определились. Далее заполняем все белые пятна, которые в документации не покрыты по любому из разделов, чтобы она была актуальна, понятна, легко искалась, названия статей соответствовали назначению. Другие критерии вы уже можете подобрать под себя сами.

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

Прежде чем мы пойдём дальше, следует сделать ещё несколько манипуляций:

• расширяем базу знаний с разбиением по подразделениям и типам проблем. Стараемся расширить нашу базу знаний и сделать её удобной для пользования другими коллегами. Не забываем при этом снимать с них обратную связь на предмет того, что нужно дописать, что не понятно, чтобы они могли этим пользоваться. И, что тоже очень важно, – ваша база знаний должна быть единым источником правды. Не позволяйте копировать ваши статьи с переименованием и последующими дополнениями. Если кому-то надо, пусть вставляет их через include page, чтобы ваша часть содержимого контролировалась только вами, иначе будет бардак из разных инструкций, что повлечёт за собой ещё больше обращений.

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

  

• Можете делать сами, а можете договориться с HR или маркетингом и вести некий вестник DevOps, в котором на еженедельной основе давать краткие новости из мира ИТ, статьи, ближайшие внутренние и внешние мероприятия, как платные, так и бесплатные. Это поможет появиться некой единой культуре информационного поля, как внутри компании, так и на рынке за её пределами.

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

  

  Понимаю, что некоторые вещи могут быть мелкие и плохо читаемые, поэтому шаблон того, как это может выглядеть с учётом списка технологий, софт и хард скиллов, выложил на github: https://github.com/darkbenladan/Matrix_compitetion_DevSevOps

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

• создание площадки обучения DevOps. Мы собрали темы и потребности на базе матрицы компетенций или просто через коллег, составили полноценный список. Далее собираемся с командой и обсуждаем, кто какую тему и когда рассказывает, постепенно делая таблицу в базе знаний. После чего делаем анонс на всю компанию сами или через HR, что стартует площадка и приглашаете весь ИТ туда. Причем начинаем это с подразделения DevOps путём рассказов про наши инструменты, мониторинг, CI/CD, troubleshooting, и т.д. Каждую встречу записываем; если есть презентация, прикладываем и выкладываем, если надо дополнительно по теме сделать статью в базе знаний, делаем. Постепенно всё это соединяем в единой структуре и проводим. Список может выглядеть примерно так:

  

  Формат лучше всего выбирать 30-40 минут на тему, 10-20 минут вопросы из зала. Лучше всего не организовывать большие митапы, т.к. это займёт много времени. Лучше коротко, ёмко и по теме. Для начала стоит делать митапы на еженедельной основе, например, по вечерам в понедельник, а далее, вы сами это заметите где-то через 6-7 месяцев, можно их проводить уже раз в 2 или 3 недели. Это зависит от возможности привлечения спикеров из других подразделений, и наличия тем. Что ещё можно рассказывать? Кто-то прошёл обучение – вот рассказ на серию митапов, появился новый процесс или внедрилось новое ПО – рассказываем, сходили на конфу – сделали её ретро и т.д. Тем самым у нас работающая площадка, запущенная на поток, и тут важно не забывать, что вы не должны быть узким горлышком, кто этим занимается, в том числе ведёт и модерирует каждую встречу, пусть ведущие, модераторы и рассказчики каждый раз меняются, тем самым, в случае ваших болезни или отпуска ничего не остановится. Ещё небольшой совет – планируйте выступления площадки хотя бы на месяц вперед, а лучше на квартал). Что ещё можно дополнительно сделать?

  

• создаём карту внутренних мероприятий той самой площадки обучения, где мы перечисляем все даты, время, темы, ведущих, что входит в эту тему тезисно и обновляем это раз в 1-3 месяца.

  

• создаём процесс обучения troubleshooting. На скрине ниже - пример процесса, как это может работать для разных подразделений

  

• запускаем обучение на поток и радуемся жизни)

  

• Если вдруг возникают команды, которые отнекиваются от обучения, то через их руководителей и общее руководство доносите мысль о том, что происходит объединение команд едиными целями, например, для уменьшения показателей SLA по решению проблем в проде. Да, цели могут разными, вроде уменьшения t2m, регресс за сутки и т.д., но суть именно в том, что они должны быть понятны командам, должны стать общими, которые они будут делать вместе. Таким образом будет смещен фокус на развитие.

  

  Немного цифр, для понимая профита, от описанных выше мероприятий:

1. За 11 месяцев проведено 30 мероприятий

2. На 30% снизилось количество входящий обращений пользователей по типовым проблемам

3. В 2 раза уменьшилось количество обращений без предварительной диагностики

4. Уровень удовлетворённости пользователей инфраструктуры по 5-балльной шкале с 1 поднялся на стабильные 3,5-4.

Резюме и итоги по всему циклу статей.

Ну что же, пора подводить итоги по всему циклу статей, которых набралось аж 6 штук:

• да, по началу будет непонятно, возможно, плохо, но это временно (речь о внедрениях);

• лучше реализовать подобные внедрения итерациями, ведь даже кошки рождаются не быстро;

• автоматизация ChatOPS – снимает нагрузку;

• предзаполнение полей задач типа DevOps – порой очень удобно;

• повышение компетенций – важный и нужный процесс в компании, как и площадка обмена опытом;

• процесс оценки будущих потребностей инфраструктуры нужно проводить на постоянной основе;

• процесс внедрения новых технологий никогда не бывает лишним;

• контролируйте боль, но не доводите до фанатизма;

• прозрачность процессов разработки на всех этапах – важна;

• хорошо, когда все в едином информационном поле;

• хорошо, когда есть единая система координат;

• упрощайте жизнь и себе, и другим;

• помните, что Вы делайте одно дело в рамках компании.

А с Вами был Крылов Александр, до новых встреч в следующих статьях!

Небольшой спойлер, впереди будет и матрица компетенций, и DevOps governance, и многое другое))