Всем привет! Меня зовут Александр Афенов, я тимлид команды Order Processing в компании Lamoda. Сегодня я хочу вам рассказать о практиках обмена знаниями: какие проблемы эти практики решают, как мы к ним пришли, и как они влияют на жизнь разработчика.
По просьбам тех, кто вдохновил меня на этот доклад, все имена и фамилии были изменены. Но из-за уважения к боли, через которую эти люди прошли в своем карьерном пути, все события описаны именно так, как они происходили в реальности.
Описанные процессы варьируются от команды к команде, но основные моменты в том или ином виде присутствуют в Tech Lamoda повсюду.
Знакомьтесь: Коля
Речь пойдет о неком сферическом Николае. Когда-то он был разработчиком в одной компании, но потом его перестало устраивать текущее место работы, и он вновь вышел на рынок труда. В тот момент за плечами у Коли было уже достаточно опыта и достаточно боли, в том числе боли, связанной с крайне низким bus-фактором на его предыдущей работе. И тут Lamoda – хоп, нанимает его на должность, скажем, мидл-девелопера. В компании такого размера Коля еще ни разу не работал, и у него сразу же возникает много вопросов.
Кто все эти люди? Коля читает Confluence
Первый рабочий день Коли начинается с подписания тонны бумажек, потому что компания белая, надо много чего сделать. На это уходит пара часов, после чего его встречает тимлид и знакомит с командой. В команде помимо Коли и тимлида еще человек 10 — разработчики, QA, аналитик, техлид (он же архитектор) — в общем, толпа людей. Они тащат Колю с собой на обед. Коля сидит за столом, слушает разговор, и хочет спросить архитектора системы, почему выбрана такая версия PostgreSQL, почему не обновляли — но он понимает, что не знает, как к человеку обратиться, потому что он конечно не запомнил ни одного имени. Коля обращается к архитектору «извините, пожалуйста» (как к преподавателю в университете), а сам надеется, что потом где-то найдет имена всех своих коллег.
Вернувшись на рабочее место, он лезет в Confluence — это такая вики на стероидах от компании Atlassian, хорошо интегрированная с другими ее продуктами. Коля забивает в поиск название своей команды, и находит некий командный спейс (раздел). Там он с облегчением видит список сотрудников с контактами и указанием, чем они занимаются, какая у кого позиция. Плюс в этом же спейсе лежат данные о проведенных командой за последнее время ретроспективах по спринтам, календари отсутствия, отпусков — всякие штуки, связанные с самой командой. По перекрестным ссылкам Коля заодно еще залезает в проджект-спейс. Их у этой команды несколько, и в каждом описан конкретный проект, с которым команда работает. Можно посмотреть бизнесовые требования к проекту, разные архивные вещи. Еще там есть раздел, посвященный собственно разработке, где дежурные описывают возникающие проблемы. Те, кто поковырялся в сложных, забытых, протухших легаси-модулях, оставляют описания, как с ними работать, и тому подобные вещи.
А что мы вообще тут делаем? Колю приглашают на Induction
Коля посмотрел на описание проектов, с которыми работает его команда, и понял, что совершенно ничего не понимает про бизнес, который пришел автоматизировать. Он знает только, что устроился в fashion-компанию, которая продает шмоточки. Как она устроена, какие цели у бизнеса, какая организационная структура? Вскоре Коля получает приглашение на встречу под названием Induction. Эта встреча идет около 3-4 часов, и на ней выступают представители самых разных подразделений компаний: логистики, доставки, закупки, IT, и так далее. И в итоге у Коли формируется примерное понимание того, куда он попал. Оказывается, что вместе с ним работает несколько тысяч человек. Встреча длится долго, но зато Коля теперь примерно знает, что происходит на верхнем уровне.
Окей, а как мы это делаем? Колин первый Tech Onboarding
Коля хочет такую же встречу, но более близкую к его ремеслу — он же все-таки разработчик. Такая встреча для новых сотрудников тоже есть, она называется Tech Onboarding. Встреча более камерная — всего на 15-20 человек, и проводит ее кто-то из опытных сотрудников. На Tech Onboarding Коля узнает основные вещи о том, как построен рабочий процесс в IT-подразделении Lamoda. Как устроено планирование, как новые проекты попадают в разработку и что с ними потом происходит. Он узнает новые детали, например, сколько в компании вообще существует разных сервисов, и сколько команд эти сервисы поддерживает, какой у каждой из команд технологический стек. После Tech Onboarding у Коли есть уже довольно глубокое понимание того, с чем придется работать.
А можно на все это посмотреть? Коля щупает стеллажи
Чуть позже Коле предлагают съездить и посмотреть, как на деле происходят те процессы, которые он будет автоматизировать. Коля пришел работать в отдел WMS, который автоматизирует работу склада. Ему нужно оптимизировать алгоритм расчета маршрута для работников склада при сборке заказа. И вот он едет на экскурсию на склад, и видит огромные уходящие вдаль ряды стеллажей, контейнеры, все можно потрогать руками. А самое главное — он видит людей, которые там работают, у каждого есть планшет, на дисплее которого отображается оптимальный маршрут перемещения между стеллажами, что позволяет сократить время сборки заказов. Коля начинает ощущать свою задачу гораздо более реальной. Он понимает, что результат его труда напрямую повлияет на работу других людей, и ему становится по-настоящему интересно.
Еще позже Колю отвозят на экскурсию на фотостудию, и он видит весь процесс от распаковки и описания товара до фотосессии и добавления его в каталог.
Как другие поймут, что именно я сделал? Коля осваивает Bitbucket в связке с Jira
Наконец, Коля получил и сделал свою первую задачу. Он ждет, что прежде чем выложить сделанные им изменения, его попросят исправить какие-то моменты, связанные с не тем паттерном проектирования или нарушением код-стайла, что-то такое. Но первое, на что ему указывают — это правила оформления коммит-месседжа. Ему говорят: "Коль, ты написал, что поправил таймаут где-то в конфиге. Ты, конечно, молодец, но как это связано с задачами в нашем таск-трекере, не очень понятно."
В Lamoda мы используем таск-трекер Jira (это тоже продукт Atlassian, как и упоминавшаяся выше Confluence). В Jira есть функциональность, которую используют почему-то не так часто, как могли бы — это концепция smart commit, которую мы используем в связке с системой контроля версий Bitbucket. В начале каждого коммит-месседжа мы стараемся указывать название задачи из Jira, с которой связаны сделанные изменения. В результате в Bitbucket в названии бранча и в коммитах везде видно, что это за таск, и просто по клику на него можно попасть в Jira и увидеть задачу. Можно понять, когда, зачем и кем это делалось, посмотреть историю выполнения. Кроме того, перекрестными ссылками привязаны сборки автоматических тестов, которые запускались, и можно узнать, когда и кем все это релизилось, и какие возникли проблемы. То есть в итоге можно увидеть не просто оторванное от реальности изменение кода, а действительно все активности, мотивацию, и даже документацию, которая с этим связана, потому что упоминания в Confluence тоже будут видны.
Так много команд, а задачи еще и пересекаются! Почему все не падает при каждом деплое? Как Коля был дежурным
Деплойный тикет
Ковыряясь во всей этой структуре дальше, Коля находит такую штуку, как деплойный тикет — это отдельный проект в Jira, в котором задачи создаются каждый раз, когда планируется релиз. В деплойном тикете указывается, на какие площадки поедет проект, какие задачи в него вошли. Это в дальнейшем позволяет ретроспективно анализировать проблемы, которые возникают после релизов.
Деплойные тикеты удобны для глубокого анализа, но их одних недостаточно, чтобы получить информацию оперативно.
Telegram для коммуникаций. Deploy FM
И тут мы поговорим внезапно о Telegram. Мы в Lamoda активно используем его для коммуникаций. У этого мессенджера прекрасный API, можно создавать каналы, боты, и настраивать очень удобные нотификации. В списке рабочих каналов у Коли есть “радио” Deploy FM. Это канал, куда сыплется информация обо всех происходящих сейчас релизах, примерно в таком формате: что за проект поехал, на какую площадку, кто инициировал релиз, закончилось ли это успехом или возникли проблемы.
Отработав несколько месяцев, Коля стал дежурным. Он уже более-менее опытный парень. И вот во время своего дежурства он видит, что прямо сейчас в Deploy FM разворачивается драма — кто-то релизит внутренний инфраструктурный сервис. Коля, как уже опытный человек, понимает, что от такого релиза проект, за который он отвечает, может сильно тряхануть. И он решает глянуть на всякий случай графики, логи, проконтролировать процесс. Так он чувствует себя спокойнее. А если что-то ретроспективно нужно будет найти, то он всегда сможет проанализировать конкретные сборки и восстановить всю картину изменений.
Предотвращение ложных тревог. Request For Changes
Как-то ночью Коля сидит, играет в контру. Он опять дежурит в этот день, и вот ему звонят и сообщают, что возникла проблема — не уходят заказы на склад. Для нашего бизнеса это критично, нужно реагировать сразу, так что Коля садится и начинает разбираться. Какое-то время он изучает мониторинги, но потом соседний дежурный, которого тоже разбудили, пишет ему: "Слушай, на самом деле ничего не сломалось. Это плановые работы, у нас ночью релиз". Коля сидит и думает: "Здорово… То есть меня только что разбудили из-за того, что что-то не работает, хотя на самом деле это изначально было запланировано. Как я должен был об этом узнать?"
Сейчас для предотвращения таких ложных тревог мы используем RFC и календари. RFC (Request For Changes) — это отдельный проект в Jira, который позволяет зафиксировать важные или опасные изменения, и согласовать их деплой в продакшн. Например, в проекте RFC заводится новый таск, если меняется структура базы данных, что-то важное обновляется, происходит миграция данных и т.д… Подобные работы часто производятся ночью, а потому необходимо согласовывать их заранее. В проекте RFC указываются ответственные техлиды, тимлиды, дежурные тех систем, которые изменения могут зацепить. И только после согласования со всеми работы добавляются в календарь. Он пошарен на всю компанию, и теперь Коля может выбрать время для обновления своего сервиса так, чтобы оно не пересеклось с другими важными работами.
Я страдал, но вам не придется. Работа с бас-фактором конкретных инцидентов: Коля начинает сам писать в Confluence
Коля решил чекнуть тот самый календарь с реквестами на изменения, и видит там запланированную работу, которая уже по описанию плохо пахнет — ему кажется, что систему, за которую он отвечает, может тряхнуть. Он решает не ложиться спать, а понаблюдать, что будет происходить — и действительно, что-то ломается. Коля садится это дело чинить, у него на это уходит некоторое время. Что-то посмотрел, починил, сделал запрос в базу и решил, что проблема решена. И тут возможны два сценария. Если бы Коля не оставил после себя никаких артефактов по поводу решенной проблемы, то в будущем мы получили бы по такому типу проблем bus-фактор равный единице. И если инцидент повторится, а дежурным будет кто-то другой, этот кто-то другой потратит как минимум столько же времени, сколько Коля, чтобы с нуля разобраться в проблеме.
Некоторые люди, менее ответственные, чем наш Николай, используют анти-паттерн «проблема будущих программистов» — они там потом как-нибудь сами разберутся. Потом получается так, что человек принял подобное решение, и в итоге этот кто-то — он сам, а ведь уже не помнит, как решал эту проблему в прошлый раз, потому что ничего не записал.
К счастью, в нашем рассказе Коля записал все в Confluence, приложив все полезные скрипты, выгрузки и так далее, и когда через полгода бахнула схожая вещь — он по ключевым словам/тегам смог найти это описание и решить проблему быстрее. А скорость решения проблемы – это не только время Колиного сна, если проблема случилась ночью. Это еще деньги компании, если проблема, например, влияет на создание заказов.
Коля печется о своей системе, а в будущем подумывает стать архитектором или тимлидом. Так что плюс ко всему он создает в таск-трекере задачи на то, чтобы добавить важные для данной проблемы параметры в систему мониторинга. И эти задачи перекрестными ссылками будут связаны со статьей в Confluence, в которой описан инцидент.
Кто здесь? Коля знакомится с другими активными пользователями Confluence
Коле становится интересно, кто, кроме него активно, пишет что-то в Confluence.
Аналитик
Первым делом он видит много записей, сделанных аналитиком. Должность аналитика за время Колиной работы в Lamoda претерпела изменения, но это кто-то, кто общается с бизнесом и переводит желание бизнеса в функциональные требования к конкретным системам. Это не технический писатель, который просто документирует изменения в системе — все оставленные им артефакты, все нарисованные схемы объясняют, какая мотивация была при постановке каждой задачи.
QA-инженер
Еще Коля отмечает, что очень много пишет в Confluence QA-инженер. За долгое время сложилось понимание, что QA в нашей компании не просто делает тесты, это действительно Quality Assurance инженер — человек, который беспокоится о качестве продукта, над которым он работает. В это могут входить любые активности, начиная с ручного тестирования, и регрессов, и заканчивая обновлением документации. В работе над проектом закладывается время на то, чтобы заниматься актуализацией протухшего и написанием нового. Плюс ко всему QA занимается документированием своих действий, оставляя за собой тест-кейсы. В результате по задаче, которая уехала в продакшн, можно найти задачку на тестирование, и в ней — конкретные кейсы, которые тестировщик воспроизводил перед задачей.
Разработчики
А что с разработкой? Далеко не весь код самодокументируем, одних комментариев часто не достаточно, чтобы понять, что происходит. Поэтому еще Коля находит статьи, которые написали разработчики. Не все статьи посвящены описанию инцидентов. Часто бывает так, что просто в ходе работы над задачей кто-то потратил два дня, чтобы разобраться, как устроен какой-то сложный модуль — и решил записать, чтобы в следующий раз не страдать.
Я знаю, как сделать еще лучше! Коля становится тимлидом
Коля продолжает проявлять инициативу, стараться, получать хорошие оценки на ревью, и благополучно становится тимлидом. У него появляется больше возможностей что-то поменять, и он хочет простимулировать появление новой документации, еще немного улучшить процессы обмена знаниями о своей довольно сложной системе.
Test Notes
Первое, что он предлагает — писать обязательные test notes. Разработчик принес изменения в систему. У каждой задачи есть изначальное описание, но в ходе выполнения разработчик мог попутно что-то отрефакторить, затронуть что-то, чего не было в описании. И перед тем, как отдать задачу на тестирование, он пишет в комментарии test notes, что он конкретно поменял, на что стоит обратить внимание. С одной стороны, это помогает тестировщику, с другой — это такой очень странный и легковесный формат документации, когда не нужно специально делать записи в Confluence, а информация все-таки осталась, и потом при помощи smart commit ее можно будет найти. Если что-то взорвалось, то вы находите строчку кода, где что-то не работает, смотрите в системе контроля версий комментарии, и из test notes очевидно, что поменялось и почему взорвалось (здесь играет музыка из Шерлока Холмса).
Время на создание артефактов
В некоторых случаях test notes недостаточно. Бывает, что задача явно нетривиальна, или нужно сделать какие-то изменения в модуле, который с 2013 года никто не трогал. В таком случае очень важно, чтобы остались полноценные описания в Confluence. Очевидно, что никто не станет этого делать, если на это не заложено времени — поэтому Коля предлагает учитывать это при оценке конкретных задач.
Шаблоны описания задач
Плюс Коля стандартизирует описание задач в Jira. Автоматически настраивается шаблон, где есть блок Why (почему мы вообще хотим делать эту задачу), What (что именно мы собираемся делать) и Definition of Done. Последний блок — это список пунктов, выполнение которых говорит, что задача завершена. Скажем, Коля хотел бы знать, что заказы клиентов зависают в каких-то статусах, и он в разделе Definition of Done задачи пишет: завести новую методику, повесить на нее мониторинг, который будет вопить на таких-то значениях, описать в конфлюенс, что это за мониторинг и как он устроен.
Тимлид-talks
И тут Коля интересуется — а как остальные работают? Он привносит практики, что-то из этого ему подсказывает руководство, какие-то вещи транслируются на все IT. Но рядом много других команд, в каждой свое управление, и, возможно, кто-то из соседей придумал практики получше. Коля начинает активно интересоваться коммуникацией между командами, и узнает про тимлид-talks. Каждый вторник на определенное время бронируется одна из переговорок, все желающие могут прийти. Тимлиды из IT собираются и делятся друг с другом своими болями. Например: "Слушайте, у меня есть сотрудник, который обожает преждевременную оптимизацию. Не могу справиться." Или: "Есть сотрудник, он холиварит в code review. Помогите! Как сделать так, чтобы и ему было комфортно, и всей команде?" Другие тимлиды, групплиды, кто угодно приходящий, могут подсказать что-то из своего опыта, предложить решение.
Tech crunches
Коля думает: "Было бы здорово, чтобы не только тимлиды, но и все члены команд делились друг с другом знаниями, которые не остаются в документации". И обнаруживает, что появились такие встречи для IT команд, которые называются tech crunches. Коля приходит на одну из таких встреч, и там рассказывает, например, как устроена автоматизация службы доставки. Потом он возвращается к своей команде и предлагает устраивать еще небольшие внутренние встречи на полчаса, где тот, кто сделал что-то заметное с системой, рассказывает об этом остальным.
Архитектурный комитет
В какой-то момент Коле говорят: "Слушай, ты тимлид, у тебя, наверняка, много свободного времени. Давай ты будешь архитектором новой системы. Ты придумаешь, как она будет устроена, какой у нее будет технологический стек, как и с кем она будет интегрироваться".
Наконец у Коли появляется возможность что-то заметно поменять, сделать иначе, чем это принято в компании. Например, ему давно не нравится система очередей, он хочет использовать Apache Kafka. Ему не нравится писать логи в файлик, он хочет писать их в Elastic. Подобные изменения обсуждаются на архитектурном комитете. На встречи комитета приходят другие архитекторы, вплоть до технического директора. Они обсуждают, насколько корректное решение Коля придумал, как оно впишется в текущую идеологию IT в Lamoda, насколько это безопасно и оправданно. В итоге схема изменений либо утверждается, либо отправляется на доработку. Смысл не только в том, чтобы Коля получил обратную связь, но и в том, чтобы остальные узнали о новых инициативах, технологиях, инфраструктурных сервисах, которые внедряются и которые можно использовать.
Как сформировалась культура обмена знаниями в Lamoda
Откуда все это взялось? Так много разных встреч, которые кто-то ставит, о которых люди узнают, приходят. Кто-то определенно должен это драйвить. Подобная культура обмена знаниями не может появиться сама собой.
В 2016 году IT-бренд Lamoda выглядел не совсем так, большинства из описанных регулярных встреч не было. Но потом пришел сильный DevRel, начал заниматься этим вопросом, и к концу года из ничего появились несколько митапов на Highload++. На одном из них мы рассказывали в целом про архитектуру нашего IT и думали, что придет человек 10, а пришло 100. Мы потихоньку начали прокачиваться, стало появляться по паре десятков докладов каждый год, потом стали писать статьи на Хабр.
Все это было нужно, чтобы решить две проблемы. Во-первых, вырастить внутри компании спикеров, которые смогут что-то рассказывать наружу. Во-вторых, рассказать отделам внутри IT, что за люди сидят рядом с ними, чем они занимаются. Какие у нас есть сервисы, зачем мы более сотни сервисов напилили самостоятельно, а не просто пошли и купили. В результате выросла вовлеченность людей в происходящее в IT-департаменте в целом, ушел страх выступать, и постепенно стала формироваться культура проведения регулярных мероприятий. Кто-то притащил важное в проект — он рассказывает об этом команде. Если он этим гордится — рассказывает и соседним командам. Хочет узнать о том, что происходит в компании — приходит на общую встречу. Все время вокруг кто-то что-то друг другу рассказывает, и у людей возникает идея: а почему бы не попробовать и мне?
Ownership
Есть еще одна причина, чуть более философская, по которой в Lamoda развилась такая культура обмена знаниями. У нас в старом офисе на стене были написаны ценности компании, как это часто делается. Очень важная ценность, особо любимая героем этой истории Николаем, называется Ownership. Концепция этой ценности такова: человек, привнося в систему нововведения, вкладывая свой труд, свое время, свои нервы, начинает понемногу ощущать ее своей. Он начинает ценить результат своей работы. Одним из примеров было изменение в восприятии того же Коли, когда его сделали, дежурным, и он увидел, какое влияние поломки в системе могут оказывать на конечных клиентов, на сотрудников, на другие департаменты. Однажды Коле внезапно выгрузилось не в нужное время 20 тысяч заказов на склад, и там люди 10 суток работали, не покладая рук, чтобы их собрать. Коля увидел влияние своих действий на реальный мир. И он постепенно начал вовлекаться в заботу о том, с чем он работает, в данном случае с какой-то IT-системой, и это развитие как раз этого самого ownership. Так формируется идея коллективной ответственности за распространение знаний. Нет секретаря, который сидит и записывает все происходящее, но каждый, кто сталкивается с чем-то, отличающимся от ежедневной рутины, идет и фиксирует это. Делится с остальными, чтобы быть уверенным, что принесенный им в проект архитектурный паттерн будет использоваться, и будет использоваться корректно. Это проявление заботы о ближних, о команде и о системе, с которой человек работает.
Заключение
Я верю, что методологии, которые мы используем, могут быть применены в компаниях практически любого масштаба, причем довольно дешево.
Какие-то из них, совсем простые, нужно один раз внедрить – и это будет вас часто спасать. Какие-то подороже, требуют времени, инвестиций и вашего внимания. Но на основе нашего опыта могу уверенно сказать, что в результате они окупают себя.
Автор: kapolakaki
