Опыт многопоточной работы, или Как быть DevOps’ом для множества команд разработки
Привет, Хабр! В этой статье хотел бы поделиться опытом участия в процессе цифровизации огромной компании. Под катом расскажу об особенностях, с которыми столкнулся при взаимодействии с большим количеством команд разработки. На их основе во второй части статьи рассмотрим, какие принципы помогли справиться с работой в таких условиях и оптимизировать ее.
Введение
Несмотря на то, что в основном компания Nixys работает в формате аутсорс или выполняет проектные работы, в данном случае мы больше года взаимодействовали с заказчиком — большой производственной компанией — именно в формате аутстафф.
Крупное производство состоит из множества разных этапов, и на каждом работает отдельный цех или бригада. Чтобы провести цифровизацию, необходимо для каждого отдельного этапа создать свое особенное приложение с уникальной внутренней логикой.
Таким образом, в компании заказчика трудилось множество команд разработчиков, а также отдельная команда DevOps-инженеров, которая занималась развертыванием приложений в общий кластер. В контексте этой статьи термин «проект» можно приравнивать к термину «приложение». За каждым из инженеров, в том числе и за мной, был закреплен свой список проектов. Отсюда возникла необходимость взаимодействовать с большим количеством команд. Одно время число проектов, за которые я отвечал, превышало 20, но в обычном режиме взаимодействовать приходилось в среднем с 10 командами. Зачастую работа это интенсивная и очень интересная за счет большого количества коммуникаций с разными людьми.
Их много и все такие разные
Большое количество есть разнообразие, большое разнообразие есть хаос.
То, что мы называем хаосом — это всего лишь закономерности, которые мы не сумели распознать. © Чак Паланик, «Уцелевший»
Именно множество неизбежных различий между командами разработки порождало наибольшую путаницу в начале нашей совместной работы. Об этих «различиях между» я и расскажу далее.
Состав
Люди в командах могут быть абсолютно разными. Одни являются специалистами в разработке, другие — руководителями цехов, многое знающими про процесс производства, но мало понимающие процесс разработки, которым руководят. Воспроизвожу вопрос про настройку cronJob, который запал мне в душу:
Та же ситуация и с разработчиками. Они могут быть как опытными, так и не понимающими некоторых базовых для DevOps-команды вещей.
Распределение ролей
В одних командах может быть четко выделенная роль лида. Тогда все решения согласуются с ним, и не возникает никакой путаницы, в других — ответственность берет на себя один из разработчиков, либо процессом управляет РП. В одной команде привыкаешь к одним правилам взаимодействия, в других — все совсем иначе. Это сложно предугадать до того, как столкнешься с конкретной ситуацией. Остается только быть более гибким и искать свои подходы в каждом случае.
Слаженность работы, взаимодействие
Если работа по проекту согласована и активно продвигается, а у РП возникают вопросы почему «до сих пор ничего не работает», — значит проблема в коммуникации. Иногда об этом узнаешь из жалобы руководству.
Одно из моих любимых (теперь) воспоминаний, когда в первые дни работы мне позвонил незнакомый человек. На повышенных тонах предъявлял претензии, что у них «все время что-то ломается» и требовал объяснить, почему все так плохо. Потом я узнал, что это руководитель проекта.
Но в противовес этому случаю всегда есть команды с полным взаимопониманием, каждый видит свои задачи и продвижение процесса. В таких условиях работать очень приятно.
Различный темп и активность на проектах
Некоторым командам важно уложиться в конкретный срок, поэтому они используют и выходные в качестве рабочего времени (привет, воскресные деплои!). Другие — наоборот, готовы отложить проверки на несколько дней, чтобы качественно уделить этому время, предварительно завершив плановые задачи.
Количество мессенджеров и чатов
Их невероятно много. Одни проекты закрываются, другие открываются, разработчики пишут в личные сообщения, чаты при этом копятся. Часто сперва пару минут листаешь переписку с человеком, чтобы понять, кто пишет и по какому проекту. Если нужно кому-то написать, то есть риск провести много времени в попытках вспомнить, в каком мессенджере вы с ним общались.
Основная особенность заключается в том, чтобы найти подход и эффективно взаимодействовать с каждой командой. А для этого нужно выделить и пропустить через себя все эти параметры. Постепенно все эти пункты начинаешь держать в голове. Иногда использование всех тонкостей значительно ускоряет решение задачи.
Как справиться с работой в таком режиме?
Безусловно, первое время (как на любом новом проекте) было тяжело.
Например, обычная ситуация — пауза в общении с человеком. В это время происходит несколько других диалогов. В момент возвращения к первому чату уже не понимаешь, что происходит, кто это пишет, и что ты вообще здесь делаешь.
Оптимизировать работу в таком режиме мне помогли принципы, которые перечислю ниже. Они появлялись не сразу. Каждый в свое время помог улучшить рабочий процесс. Иногда это было разрешение конфликтных ситуаций, иногда — ускорение понимания происходящего, повышение качества общения или просто организация собственного спокойствия.
Записывать всё, что делаешь
Поскольку общение с разработчиками происходит в диалогах, в огромном потоке легко потерять, чем конкретно ты занимался в текущий день. Особенно в первое время. Такие детали нужно записывать. Это поможет впоследствии с будущими задачами:
детально описать трудозатраты в конце дня
не потерять ни одной задачки, даже если она растянется на несколько дней или недель (недель)
создать подробную историю проекта
Вести историю задач каждого проекта
Продолжение предыдущего пункта. Удержать в оперативной памяти статусы по 10 проектам — нереально (в первые месяцы). Зачем это может пригодиться?
Поскольку на проекте работает несколько инженеров, возникали ситуации неравномерной нагрузки, когда коллеги скучают, а у меня переполнен бэклог (или наоборот). В этот момент им легко подключиться мне на помощь, если есть детальное описание истории проекта.
Использовать собственную систему задач
Об этом я задумывался нечасто, поскольку такой необходимости не было, общение с командами, в основном, происходило вне нашего таск-трекера, в разных чатах. Но после того, как к работе на проектах этой компании также присоединились другие мои коллеги из Nixys, ситуация изменилась. Для наших целей подошла доска в trello. Она помогла удобно организовать два пункта, описанные выше. В самом начале проекта создавался список с его именем и описанием на момент старта. При поступлении задачи из любого проекта я создавал карточку в личный список, а после решения перемещал её в конец списка конкретного проекта, формируя историю. Кроме того, в общий workspace было удобно собирать ссылки на постоянно обновляющиеся важные ресурсы (помним о пункте «Эволюция стандартов»).
Этот пункт вкупе с предыдущими позволил 4–5 часов в неделю, которые тратились на орг. моменты, сократить до 1 часа.
Всегда проверять входные данные
Пункт, о который много раз разбивались я и коллеги. Если поступает задача «сменить это значение на вот это», самое неверное решение — пойти и сделать в точности то, о чем попросили. Из-за разной степени погруженности, знакомства с технологиями и просто невнимательности очень часто в таких запросах предоставляются неверные данные. Русские символы в латинском тексте, ошибка в написании хоста, пропущенные цифры в IP-адресе — список может быть бесконечным. Для ускорения процесса перед тем, как сделать саму задачу, стоит добавить проверку, что вам предоставили корректные данные. Иначе впоследствии можно очень долго и зубодробительно искать ошибку совсем в других местах.
Данное правило в конечном итоге позволило экономить как минимум 2 часа в неделю на поиск самостоятельно созданных ошибок.
Настаивать на простых и прозрачных решениях
В моменты, когда приходит задача реализовать некое нетипичное решение, важно уделить внимание его подробному обоснованию, задать уточняющие вопросы. Как уже было описано выше, иногда разработчики обладают неполной информацией, особенно по части CI/CD-процесса. Часто есть более простое и грамотное решение, важно просто предложить и обосновать его.
И главное в этом пункте — настаивать. Даже если вы очень хорошо разобрались в каком-то сложном способе работы проекта, в его особенности будет тяжело вникнуть коллеге (помним о передаче задач из бэклога), а также самому повторно вникнуть через несколько месяцев. Поэтому если есть более распространенные альтернативы — лучше воспользоваться ими для облегчения жизни себе и окружающим в дальнейшем при поддержке проекта.
Заранее обозначать сроки
Выше я описывал возникновение ситуаций с переполненным бэклогом. В связи с этим на простую задачу (15–30 минут) может уйти намного больше времени. И в такой ситуации лучше обозначить заранее, через какое время приблизительно она будет решена. Потому что второй раз РП в гневе могут пойти сразу к руководству с жалобами на игнорирование их самого важного проекта! Таким способом мы сразу даем понимание ситуации авторам задачи и уменьшаем вероятность возникновения конфликтов в дальнейшем.
Описывать статусные вещи в общий чат
Даже если обсуждение решения происходило во время созвона с разработчиком, о принятом решении следует отписать резюме. Это очень помогает держать коллег (и особенно РП) в курсе всего что происходит, даже если они не участвуют в решении непосредственно. Также, если решение затрагивает кого-то еще, они могут высказать свое мнение, задать вопросы и внести корректировки до того, как это будет реализовано и возникнет следующая проблема.
Посещать ежедневные встречи крупных проектов
К активным и крупным проектам нужно ходить на дейли. Благодаря этому значительно улучшается понимание статуса проекта и приоритета задач всеми участниками. Критерии необходимости этого — повторяющиеся ситуации с отсутствием взаимопонимания с командой проекта, а также наличие множества параллельных задач от разных авторов.
Заключение
Все описанные выше принципы формировались постепенно при столкновениях с реальными ситуациями, и я успел в полной мере ощутить их эффективность. Некоторые из них у меня получилось вывести самостоятельно, другие — подсказки и рекомендации от старших коллег, за что им спасибо.
Мой опыт работы в таком режиме оказался очень интересным и интенсивным. Прежде всего он о взаимодействии и развитии навыков коммуникации. Если бы меня спросили, рекомендую ли я пережить нечто подобное, однозначно — да. И если вам действительно однажды доведется это испытать, надеюсь, описанные здесь советы помогут не бросаться в омут с головой, а подойти к ситуации более подготовленным и знающим, чего стоит ожидать и как действовать.
Сейчас, по прошествии времени, ко мне пришло осознание, что я участвовал в цифровизации — огромном, ресурсоемком процессе и внес свой вклад в развитие удобства и эффективности рабочей среды производства. Как и громадные постройки, большие процессы, тоже вдохновляют и завораживают.
Кстати, подписывайтесь на наш Telegram-канал DevOps FM, там мы публикуем не только авторские статьи, но также актуальные новости мира DevOps.
