Поддержите рост и цифровую трансформацию вашего бизнеса в условиях эпидемии с помощью Программы поддержки малого и среднего бизнеса против COVID-19. Получите купон на 300 долларов для всех новых клиентов малого и среднего бизнеса или купон на 500 долларов для платежеспособных клиентов.
Цзяо Ба, старший технический эксперт Alibaba
Ниже приводится общая запись с сокращенным содержанием.
Как решить проблемы командного взаимодействия и процесса НИОКР при работе из дома
Команда разработчиков программного обеспечения столкнулась с двумя основными проблемами при работе из дома: командным общением и процессом исследований и разработок. Члены команды Apsara DevOps распределены по нескольким городам и обычно проводят онлайн-встречи для общения. По этой причине общение и координация между членами команды были менее затронуты, когда они начали работать из дома. Однако проблемы со связью между членами подкоманд оставались. В обычное время, когда члены подкоманд работают в офисе, они могут эффективно решать проблемы посредством личного общения. Но это невозможно при удаленном общении. После более чем 10 дней настройки мы постепенно решили эту проблему и повысили эффективность общения. В этой статье команда Apsara DevOps используется в качестве примера, чтобы продемонстрировать разницу между работой в офисе и работой из дома.
Вопросы, обсуждаемые на утренних и еженедельных встречах, в основном не изменились, за исключением того, что формат встреч был другим. Все мы общаемся лицом к лицу, когда работаем в офисе, тогда как мы общаемся посредством телеконференций и видеоконференций, работая дома. Кроме того, для повышения эффективности коммуникации нам потребовалось синхронизировать личные рабочие задания и заранее уточнить тему встречи. При работе из дома, помимо еженедельного отчета, мы используем ежедневный отчет, чтобы сообщать о ходе личной работы и возможных рисках каждый день перед уходом с работы.
Что касается процесса НИОКР, то, если ваша команда не применяет стандартный интерактивный или основанный на графическом интерфейсе процесс НИОКР, команда может столкнуться с проблемами. Как только вы столкнетесь с проблемами или сбоями в процессе выпуска, проблемы могут усугубиться, потому что вам будет труднее найти кого-то еще, чтобы помочь вам, когда вы работаете из дома. Alibaba всегда хорошо работала в процессе исследований и разработок. Мы используем платформу Aone (внутреннее название Apsara DevOps) для выполнения всего процесса исследований и разработок, включая разработку, сборку, развертывание и безопасное производство.
Работая из дома, мы решаем основные проблемы командного взаимодействия и процесса НИОКР с помощью гибких НИОКР и непрерывной доставки. Далее мы подробно расскажем, как мы решаем проблемы.
Agile R&D, ориентированная на итерацию
На самом деле Agile R&D - это зрелая методология. Как говорится, в глазах тысячи людей тысяча Гамлетов. Каждая команда НИОКР должна сочетать теорию с собственной практикой и находить набор методов и механизмов, наиболее подходящих для этой группы. Основываясь на практике команды Apsara DevOps, мы считаем, что гибкие исследования и разработки должны быть сосредоточены на итерациях, ключевым моментом которых является асинхронная коммуникация.
Итак, что мы подразумеваем под этим? Итерация - это отказ от долгосрочных или конечных целей. Когда большая цель разбита на маленькие, наша команда может лучше понять эти маленькие цели. Когда итерация сосредоточена, мы далее разбиваем эти небольшие цели на рабочие элементы или карточки в канбане и распределяем их между конкретными владельцами задач. Это составляет основу асинхронной связи.
В чем преимущества асинхронной связи перед синхронной? Во-первых, при асинхронной связи можно накапливать контекст. При асинхронном общении содержание нашего сообщения будет записано для каждого конкретного рабочего элемента. Однако такой контент просто передается устно при синхронном общении. Во-вторых, асинхронное общение также позволяет членам команды четко определять свои цели, сохранять их сосредоточенность и сокращать перерывы, тем самым повышая эффективность.
Команда Apsara DevOps делит рабочие элементы на три категории: ежедневные дефекты, требования к проекту и требования к продукту. Ежедневные дефекты связаны с обслуживанием запущенных продуктов, а дефекты возникают в результате отзывов пользователей или самотестирования. Требования к проекту относительно сложны. Они имеют длительный цикл доставки и конкретное время доставки и исходят от корпоративных клиентов или от внутренних требований предприятия. Требования к продукту в большинстве случаев ориентированы на общественность и должны постоянно развиваться. Ниже описывается, как команда Apsara DevOps обрабатывает три категории рабочих элементов.
Как мы справляемся с ежедневными дефектами? Во-первых, команда Apsara DevOps делит ежедневные дефекты на четыре подкатегории: аварийные дефекты, которые необходимо исправить немедленно, дефекты, которые необходимо исправить в течение одной недели, дефекты, которые необходимо исправить в течение двух недель, и дефекты, которые не нужно исправлять. Почему мы используем эти подкатегории? Это связано с тем, что дефекты более специфичны и имеют меньше изменений, чем требования. Мы можем подтвердить время, необходимое для исправления дефектов, когда нам поручают их устранять.
Во-вторых, дефекты не занимают очков истории, что означает, что вы должны исправить дефекты в свободное время, а время, необходимое для исправления дефектов, не будет включено в ваши обычные рабочие часы. Фактически это создает положительный механизм стимулирования. Рабочие элементы, такие как задачи и требования, приведут к определенным дефектам. Если ваши рабочие элементы выполнены с более высоким качеством, у вас будет меньше дефектов, и наоборот. Этот механизм побуждает всех делать все возможное для выполнения своих рабочих задач.
В-третьих, дефекты не рассматриваются на утренних собраниях. Однако на еженедельной встрече будет рассматриваться ход работы с дефектами, а новые дефекты будут классифицироваться и назначаться.
Этот механизм прост и проще в реализации. После того, как команда Apsara DevOps внедрила этот механизм для устранения ежедневных дефектов, качество наших продуктов значительно улучшилось и стало более гарантированным.
Как мы справляемся с требованиями проекта? Как правило, требования к проекту имеют четко определенные сроки и четко определены. Исходя из указанного срока, мы можем определить ключевые моменты времени и определить этапы, которые позволят нам лучше контролировать риски. Обратите внимание, что содержание этапов должно быть измеримым и наблюдаемым. Затем мы выполняем итерацию на основе этапов, уточняем требования и оцениваем точки истории перед началом каждой итерации. Это соответствует методологии Agile R&D. Следует отметить, что команда должна по возможности развивать у своих членов всесторонние навыки. Таким образом, рабочие элементы или карточки, которые мы разбиваем на итерациях, могут быть назначены любому разработчику, а не привязаны к конкретному человеку. Это предотвращает технические узкие места из-за некомпетентности определенного разработчика.
Как мы справляемся с требованиями к продукту? Требования к продукту обрабатываются так же, как и требования проекта. Как для требований к продукту, так и для требований проекта, нам необходимо уточнить требования, оценить точки истории, а затем взять на себя карточки задач и предоставить предупреждения о рисках на совещании. Основное отличие состоит в том, что итерационный цикл требования к продукту относительно фиксирован, что способствует долгосрочной стабильности продуктов. Если цикл итераций сильно различается по продолжительности, это означает, что количество карточек, обработанных разработчиками в одном цикле НИОКР, сильно различается, что может вызвать различия в качестве доставки. Другое отличие состоит в том, что итеративная цель требования к продукту обычно основана на обратной связи от пользователей, рынков и данных, что приводит к некоторым неопределенностям. Поэтому необходимо уточнить требование и рассмотреть его более подробно.
Команда Apsara DevOps достигла хороших результатов в практике Agile R&D, и члены команды также получили большое чувство выполненного долга. По нашему опыту, очень важно найти ритм команды. Мы надеемся, что вы найдете ритм своей собственной команды, практикуя гибкие НИОКР, и найдете гибкий механизм НИОКР, который лучше всего подходит вашей команде.
Как стандартизировать процесс исследований и разработок с помощью непрерывной доставки
В этом разделе описывается, как команда Apsara DevOps стандартизирует процесс исследований и разработок посредством непрерывной доставки. Непрерывная интеграция и непрерывная доставка реализуются через конвейер. В дополнение к конвейеру мы представим некоторые отличительные методы, принятые командой Apsara DevOps, включая тестовую среду (изоляция среды разработки от тестовой среды в рамках микросервисной архитектуры для реализации облачной разработки), управление филиалами (процесс- на основе управления на основе ветвей кода и статических элементов конфигурации в рамках совместной научно-исследовательской работы нескольких человек) и производственной безопасности (обеспечение доставки программного обеспечения, стандартизация процессов и отслеживаемая доставка).
Первый - это тестовая среда. Давайте сначала посмотрим на предысторию этого решения. Раньше мы разрабатывали гигантские приложения. С развитием микросервисной архитектуры гигантские приложения начали разделяться на множество небольших приложений. Хотя микросервисная архитектура приносит нам преимущества, она также создает новые проблемы для процесса разработки. При постоянном увеличении количества приложений ссылка на приложение станет очень длинной. Общие ресурсы разработки ограничены и нестабильны, что усложняет весь процесс разработки и отладки. Однако вам нужна эксклюзивная среда в процессе разработки. Как решить эту проблему?
Первый способ - загрузить все приложения в эксклюзивную среду. У этого метода есть недостатки. Во-первых, по мере увеличения количества приложений каждый разработчик приложений не может загрузить все приложения во всей среде, когда ресурсы разработки ограничены. Во-вторых, по мере увеличения количества приложений всю архитектуру микросервисов становится трудно описать, и становится трудно загрузить все приложения хотя бы один раз.
Второй метод сейчас широко используется. Сначала мы устанавливаем некоторые общие базовые среды, такие как тестовая среда и предварительная версия среды. Когда нам нужно разработать программное обеспечение, мы можем запустить службу или приложение локально и провести совместную отладку в общих базовых средах. У этого метода тоже есть недостатки. Во-первых, при разработке функции вам может потребоваться изменить несколько приложений и развернуть эти приложения в общей базовой среде. Однако службы или приложения нестабильны в процессе разработки, что, в свою очередь, вызывает нестабильность общих базовых сред. Кроме того, эта операция приводит к вытеснению общих базовых сред. Такое вытеснение делает обычные базовые среды узкими местами в процессе разработки, что сильно влияет на эффективность разработки.
Основываясь на нашем предыдущем опыте и практике, Alibaba разработала решение для изолированной среды. Как показано на предыдущем рисунке, когда вам нужно разработать некоторые функции, вам не нужно развертывать приложения или службы в общей базовой среде. Вместо этого вы только привлекаете некоторые ресурсы для разработки и развертывания функций, соединяете эту среду функций с общей базовой средой и должным образом изолируете две среды друг от друга. Одни и те же ресурсы могут использоваться совместно, но запросы изолированы друг от друга. У этой конструкции есть два преимущества. Во-первых, вы не будете занимать много ресурсов разработки. Во-вторых, это не влияет на стабильность общей базовой среды.
Среда функций - это виртуальная среда. Похоже, что каждая функциональная среда представляет собой независимую и полную тестовую среду, состоящую из кластера служб. Фактически, за исключением сервисов, которые текущий пользователь хочет протестировать, другие сервисы виртуализируются с помощью системы маршрутизации и промежуточного программного обеспечения, ориентированного на сообщения, и направляются к соответствующим сервисам в общей базовой среде.
Эта технология тестирования развивалась на протяжении нескольких поколений в Alibaba. Вначале используемое промежуточное программное обеспечение, такое как микросервисы и очередь сообщений, необходимо преобразовать для поддержки этого типа механизма изоляции. Позже, с развитием облачной технологии, мы стали использовать возможности Service Mesh для изоляции. Кроме того, мы разработали продукт KT Virtual Environment, который теперь является открытым. Мы приветствуем ваши отзывы о любых дефектах, которые могут быть у этого продукта.
Следующее - управление филиалом. Команда Apsara DevOps и внутренние группы исследований и разработок Alibaba в основном применяют модель управления филиалами под названием AoneFlow. Эта модель управления филиалами была создана на основе многолетнего опыта практического применения. Он управляет ветвями функций и статическими элементами конфигурации путем изменения модели. Слияние и конфликты между ветвями кода и статическими элементами конфигурации обрабатываются через графический интерфейс. В отличие от общей модели управления фиксированными ветвями, AoneFlow предоставляет динамические ветки выпуска, которые позволяют гибкую комбинацию функций и быстрое добавление и удаление функций.
Почему мы должны использовать ветки динамического выпуска? Во-первых, полная проверка интеграции становится чрезвычайно сложной при использовании микросервисной архитектуры по сравнению с традиционными гигантскими приложениями. Вам необходимо выполнить проверку интеграции с другими приложениями в общей среде. Даже если ваш код работает правильно во время автономной проверки, трудно гарантировать надежность вашей функциональной ветки, когда она проходит проверку интеграции вместе с другими приложениями. Если возникает проблема, ваша функциональная ветка должна быть удалена из ветки выпуска. Во-вторых, когда несколько человек совместно разрабатывают ветку кода, трудно гарантировать отсутствие проблем, когда ваш код интегрирован с кодом других людей. Кроме того, чем выше частота выброса, тем больше нестабильность. В частности, интернет-предприятия отличаются высокой частотой итераций и высокой частотой разработки, и, соответственно, вероятность конфликта также очень высока. В этом случае вам сложно гарантировать надежность ветвей кода во время проверки интеграции. В обоих случаях требуется, чтобы ветвь кода могла быть быстро добавлена или удалена.
И последнее, о чем мы хотели бы рассказать, - это безопасность производства. В тестовой среде и управлении филиалами мы сосредоточены на повышении эффективности непрерывной доставки. Более важная задача - обеспечить качество доставки, чтобы в процессе выпуска не было ошибок.
Во-первых, нам необходимо создать ряд механизмов безопасности, таких как сканирование безопасности и проверка кода, чтобы заранее выполнить тесты, чтобы дефекты можно было обнаружить на этапе разработки. Во-вторых, эти механизмы не могут быть простыми словесными условностями, и нам нужны эффективные инструменты для управления ими. Команда Apsara DevOps превращает все эти механизмы в контрольные точки или красные линии, интегрирует их в процесс исследований и разработок и реализует их через конвейер Apsara DevOps. Кроме того, чтобы сбалансировать эффективность, команда Apsara DevOps предъявляет требования к качеству приращений, настраивая модульные тесты, статическое сканирование кода, интеграционное тестирование, степень покрытия и другие контрольные точки качества или красные линии для приращений. В-третьих, цель состоит в достижении глобального контроля посредством ручных проверок и контроля за выпуском. Участие человека и вышеупомянутые технические меры могут дополнять друг друга для обеспечения безопасности производства.
Скоро выйдет новая версия Apsara DevOps
Вскоре будет запущена новая версия Alibaba Cloud Apsara DevOps, в которой будут представлены все новые функции продукта и пользовательский интерфейс. Это продукт, который мы разработали вместе со многими разработчиками малого и среднего бизнеса после того, как выслушали отзывы разработчиков из различных каналов.
Об Apsara DevOps
Apsara DevOps - это универсальная платформа DevOps корпоративного уровня, основанная на передовых концепциях управления и технических приемах Alibaba. Он призван стать двигателем эффективности НИОКР для цифровых предприятий. Apsara DevOps предоставляет комплексные услуги онлайн-сотрудничества и инструменты исследований и разработок, охватывающие весь жизненный цикл, от сбора требований до разработки, тестирования, выпуска, обслуживания и эксплуатации продукта. Используя искусственный интеллект и облачные технологии, разработчики могут повысить эффективность своих исследований и разработок и продолжать предоставлять клиентам ценные продукты.
Продолжая вести войну против всемирной эпидемии, Alibaba Cloud сыграет свою роль и сделает все возможное, чтобы помочь другим в их битвах с коронавирусом. Узнайте, как мы можем обеспечить непрерывность вашего бизнеса, на странице https://www.alibabacloud.com/campaign/fight-coronavirus-covid-19
