Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про 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, которая позволит вам более быстро составить список тем, на основе которых вы сможете делиться опытом с коллегами, обогащать вашу базу знаний новыми статьями, поможет вам сформулировать список тем для площадки обучения. Вот пример того, как она может выглядеть:
Кусочек варианта матрицы компетенций 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 месяца.
Проведённые и будущие мероприятия площадки обучения DevOps создаём процесс обучения troubleshooting. На скрине ниже - пример процесса, как это может работать для разных подразделений
Вариант процесса обучения troubleshooting запускаем обучение на поток и радуемся жизни)
Ехху Если вдруг возникают команды, которые отнекиваются от обучения, то через их руководителей и общее руководство доносите мысль о том, что происходит объединение команд едиными целями, например, для уменьшения показателей SLA по решению проблем в проде. Да, цели могут разными, вроде уменьшения t2m, регресс за сутки и т.д., но суть именно в том, что они должны быть понятны командам, должны стать общими, которые они будут делать вместе. Таким образом будет смещен фокус на развитие.
Единые цели Немного цифр, для понимая профита, от описанных выше мероприятий:
За 11 месяцев проведено 30 мероприятий
На 30% снизилось количество входящий обращений пользователей по типовым проблемам
В 2 раза уменьшилось количество обращений без предварительной диагностики
Уровень удовлетворённости пользователей инфраструктуры по 5-балльной шкале с 1 поднялся на стабильные 3,5-4.
Резюме и итоги по всему циклу статей.
Ну что же, пора подводить итоги по всему циклу статей, которых набралось аж 6 штук:
да, по началу будет непонятно, возможно, плохо, но это временно (речь о внедрениях);
лучше реализовать подобные внедрения итерациями, ведь даже кошки рождаются не быстро;
автоматизация ChatOPS – снимает нагрузку;
предзаполнение полей задач типа DevOps – порой очень удобно;
повышение компетенций – важный и нужный процесс в компании, как и площадка обмена опытом;
процесс оценки будущих потребностей инфраструктуры нужно проводить на постоянной основе;
процесс внедрения новых технологий никогда не бывает лишним;
контролируйте боль, но не доводите до фанатизма;
прозрачность процессов разработки на всех этапах – важна;
хорошо, когда все в едином информационном поле;
хорошо, когда есть единая система координат;
упрощайте жизнь и себе, и другим;
помните, что Вы делайте одно дело в рамках компании.
А с Вами был Крылов Александр, до новых встреч в следующих статьях!
Небольшой спойлер, впереди будет и матрица компетенций, и DevOps governance, и многое другое))
