Чтобы запустить новую функцию за несколько недель до недели онлайн-покупок, как гарантировать, что новая функция сможет противостоять толпе людей в Черную пятницу и сохранить доверие клиентов к веб-сайту? В том году Zalando применил смелый подход, воссоздав взрывную нагрузку онлайн-покупок за несколько недель в формальной обстановке в будние дни, чтобы протестировать новые функции.
После того, как разработка технологий Zalando вступила в зрелую стадию, принятие технических решений больше не имеет той свободы, которая была при первом запуске Radical Agile. Вместо этого им руководит высшее инженерное сообщество, и была создана техническая радиолокационная карта (Tech Radar). разработан для помощи сотням команд в принятии технических решений. Все команды обязаны использовать этот общий список рекомендаций по технологиям в качестве справочного материала для выбора технологий для новых проектов. Им не нужно проводить техническую оценку с нуля каждый раз при запуске нового проекта, а непосредственно обращаться к рекомендациям списка для выбора. Поскольку при выборе каждая команда обращается к одной и той же технологической диаграмме, Zalando может гарантировать, что технологии, используемые в разных проектах, входят в объем этого общего списка технологий, чтобы обеспечить технологическую направленность всей компании. / Развитие технологий Zalando вступило в зрелую стадию, опираясь на технологический радар, чтобы сосредоточиться на технических решениях сотен команд. С 2009 по 2019 год организационная сторона Zalando претерпела множество изменений, а ее техническая сторона также получила очень масштабное развитие. децентрализованная микросервисная архитектура. По данным, представленным Заландо на конференции DevOpsCon в Берлине в 2022 году, количество микросервисов в 2019 году составило от четырех до пяти тысяч. В настоящее время разработка технологий Zalando вступила в зрелую стадию. Принятие технических решений уже не является таким свободным, как во время первого запуска Radical Agile. Вместо этого им руководит высшее инженерное сообщество и используется техническая радиолокационная карта (Tech Radar). разработан, чтобы помочь 2 командам принимать технические решения. Дизайн этой технологической диаграммы основан на практике консалтинговой компании ThoughtWorks, но на ее основе была разработана собственная эксклюзивная версия Zalando. Эта консалтинговая компания имеет около сотни технических терминов, охватывающих четыре категории: технологии, инструменты, платформы, фреймворки и языки. Они разделены на четыре уровня в зависимости от степени рекомендуемого внедрения и расположены на круговой диаграмме, разделенной на четыре квадранта. На этой технологической диаграмме перечислены рекомендуемые уровни внедрения различных типов технологий. Различные кольца используются для обозначения разных уровней рекомендаций. Чем ближе кольцо к ядру, тем выше уровень рекомендаций для этой технологии. Zalando подвела итоги своих потребностей и, наконец, сосредоточилась на технологиях, связанных с разработкой программного обеспечения, включая четыре основные категории: хранение данных, управление данными, инфраструктура и языки разработки. Рекомендуемый уровень принятия разделен на четыре уровня, образующих четыре кольца, каждое из которых представляет отдельный уровень рекомендаций. Эти четыре уровня включают в себя: принятие (рекомендуется для внедрения), испытание (рекомендуется для испытания), оценку (этап оценки) и сохранение (зарезервировано, но не рекомендуется). Рекомендуемые пробные технологии относятся к технологиям, которые уже имели успешные внутренние проекты и, по крайней мере, используются для решения реальных проблем, а не смоделированных ситуаций. Они также придают большое значение широкому внедрению и представляют собой технологии, в которые высшие руководители готовы инвестировать в долгосрочной перспективе. . уровень. Технологии, включенные в этап оценки, относятся к группе технологий, которые имеют очевидную потенциальную ценность и достойны инвестиций. Автоматически анализируя данные планов испытаний всех продуктов, мы можем определить технологии, которые были протестированы и заслуживают внимания. включения в стадию испытаний технологии. . Последняя категория зарезервированных уровней — это технология, которая не рекомендуется, но будет продолжать поддерживаться. Она не только недоступна для новых проектов, но и не рекомендуется использовать ее для рекламных услуг. Широта применения этого типа технологии должна расширяться постепенно. сузился. Каждая технология также будет сопровождаться документом с техническим описанием, в котором перечислены преимущества, недостатки, ограничения, условия использования и уроки, извлеченные после использования технологии. Каждая технология имеет документ, и все технические документы объединяются в базу технических знаний. Zalando также собрала шаблоны и руководства по внедрению этих рекомендуемых технологий на технологической диаграмме. В руководствах будут описаны часто задаваемые вопросы при их использовании, примеры использования от команд, которые их внедрили, или даже сравнение различных альтернативных технологий.
Время от времени, чтобы корректировать уровень рекомендаций по технологиям, главный инженер собирает данные о реальном использовании каждой технологии на существующем технологическом радаре, включая объем использования, записи об инцидентах и опыт внедрения (например, сколько лет прошло с момента внедрения этой технологии). технология была внедрена в Заландо), а затем выполнит оценку. Назначенный главный инженер по техническому обслуживанию сначала создаст таблицу оценок новых технологий, а затем откроет ее сообществу главных инженеров для голосования, чтобы решить, «обновить» или «понизить» версию.
Zalando требует, чтобы каждая команда использовала этот общий список технологий в качестве справочного материала для выбора технологий для новых проектов. Нет необходимости проводить техническую оценку с нуля каждый раз, когда запускается новый проект. Инженеры напрямую обращаются к рекомендациям списка для выбора. Поскольку при выборе каждая команда обращается к одной и той же технологической диаграмме, Zalando может гарантировать, что технологии, используемые в разных проектах, попадают в рамки этого общего списка технологий, чтобы достичь фокуса технического руководства.
Заландо переименовал первоначальный отдел цифровой инфраструктуры в отдел строительства (Build) и продолжает отвечать за создание и улучшение платформы для разработчиков, предназначенной специально для разработчиков. Строительный отдел начал изучать клиентский путь разработчика, то есть ежедневный рабочий путь разработчика, и обнаружил, что платформы разработки, используемые разработчиками, были достаточно разбросаны по-своему. Каждая команда общалась со своими участниками по-своему, и их не хватало. общий язык общения в компании.
Решите проблему фрагментации процесса разработки и создайте сайт портала разработчиков.
Чтобы решить проблему фрагментированного рабочего процесса разработчиков, отдел строительства создал портал разработчиков Sunrise (Sunrise Platform) как первый веб-сайт, который разработчики открывают каждый день, когда идут на работу. Пользователями этой платформы являются инженеры-программисты, инженеры по обработке данных, технические директора, специалисты по данным, менеджеры проектов, дизайнеры и т. д.
На основе проекта платформы управления ML с открытым исходным кодом Spotify Backstage отдел строительства интегрировал множество внутренних технических инструментов Zalando, компонентов разработки, шаблонов реализации и технической документации для разработки этой внутренней специализированной платформы для разработчиков самообслуживания (Internal Developer Platform). работает так же гладко, как коммерческая платформа для совместной работы корпоративного уровня, а детали дизайна пользовательского интерфейса подчеркиваются, чтобы помочь разработчикам приступить к работе. Даже разработчики могут напрямую просматривать общие данные мониторинга ответственных точек доступа на платформе Sunrise.
На первой странице, которую разработчики видят при открытии платформы Sunrise, за один вечер собрана вся часто используемая ими информация, что позволяет им легко искать конкретные приложения, за которые они несут ответственность, и часто используемые API, а также быстро видеть, кто является их преданным владельцем. каждое приложение или API? При необходимости вы можете напрямую отправить заявку на этой странице, чтобы обратиться за помощью, вместо того, чтобы подавать заявку через другую систему, как это было раньше. На домашней странице платформы Sunrise также собрана вся информация о событиях точек доступа, за которые несут ответственность все разработчики, а также справочные документы, на которые можно подписаться.
Инженеры или другие пользователи могут проверять ход выполнения или состояние каждого этапа жизненного цикла продукта, отслеживать его в режиме реального времени и сотрудничать с командами и другими людьми для устранения проблем в процессе CI/CD. Члены команды Zalando могут даже загружать и развертывать новые приложения с помощью Sunrise.
Чтобы создать эту удобную и простую в использовании внутреннюю платформу для разработчиков, Zalando публично поделилась несколькими ключами.
Например, они напрямую модифицировали исходный код K8s для решения проблемы, превратив K8s в систему, которой они могут управлять для разработки собственной облачной платформы. Например, платформа Sunrise использует самостоятельно разработанную и настроенную функцию инкапсуляции kubectl.
Когда возникает чрезвычайная ситуация и вам необходимо быстро создать кластер k8s с временным доступом, эта функция инкапсуляции может пригодиться. Нет необходимости следовать исходной стандартной функции инкапсуляции, что еще больше сокращает время развертывания. Еще одним ключевым моментом является то, что Zalando также оцифровывает «опыт разработки», что означает измерение эффективности платформы разработки по опыту разработчиков и производительности.
Заландо сослался на рекомендации книги «Accelerate: The Science of Lean Software and DevOps» (название тайваньско-китайской версии — «The Science Behind Lean Software & DevOps»), чтобы определить четыре показателя матрицы эффективности разработчика.
Он включает в себя время выполнения, частоту выпуска, среднее время восстановления (Time to Restore Service) и частоту неудачных изменений (Change Fail Rate). Это именно те четыре показателя, которые используются в известной концепции показателя производительности DevOps DORA.
Однако конкретный метод измерения четырех показателей Zalando немного отличается. Время подготовки — от фиксации до официального запуска среды. Частота выпусков: количество развертываний на одного разработчика в неделю. Среднее время восстановления рассчитывается от момента возникновения события до момента восстановления службы (а не от момента сбоя службы). Частота сбоев последнего изменения рассчитывается на основе количества сбоев, произошедших за все время развертывания.
Самым большим преимуществом платформы разработчиков Sunrise является то, что она позволяет всем разработчикам работать в одном направлении. Кроме того, она также может удовлетворить потребности различных организационных подразделений в асинхронных отделах, обеспечивая гибкость. Наконец, эта единая платформа также интегрирует дизайн. Zalando Техническая радиолокационная карта и весь справочный технический практический опыт, тестовые документы группы проверки и даже соответствующие шаблоны устоявшихся практик и процессов. Его можно сосредоточить на одной платформе, и команде разработчиков рекомендуется использовать ту технологию, которую они особенно хотят добавить.
Цель дизайна веб-сайта Zalando Sunrise — «сделать разработчиков счастливыми и продуктивными!» Он обеспечивает лучший опыт разработчиков и максимально снижает когнитивную нагрузку технической команды и команды разработчиков, чтобы повысить скорость и производительность разработки. Это был первый раз, когда Zalando раскрыла процесс разработки платформы Sunrise на прошлогодней конференции по разработке платформ, Хеннинг Джейкобс, старший главный инженер Zalando, подчеркнул этот вопрос.
Чтобы решить проблему фрагментированного рабочего процесса разработчиков, конструкторский отдел Zalando создал портал разработчиков Sunrise (Sunrise Platform) как первый веб-сайт, который разработчики открывают каждый день, когда идут на работу. /Заландо
Sunrise (Sunrise Platform) использует проект платформы управления машинным обучением с открытым исходным кодом Spotify Backstage в качестве основы, интегрируя множество внутренних технических инструментов Zalando, компонентов разработки, шаблонов реализации и технической документации для разработки этой внутренней специализированной платформы для разработчиков самообслуживания (Внутренняя платформа разработчика). Разработчики Zalando могут использовать платформу Sunrise для получения информации о различных инструментах и услугах, созданных различными отделами и продуктовыми командами компании, а также для получения всех услуг поддержки в одном месте. /Заландо
Разработчики Zalando могут быстро просматривать и управлять ходом проектов продуктов, за которые они отвечают, на платформе Sunrise. /Заландо
Снова активно внедряйте SRE и даже создайте специальный отдел SRE.
С другой стороны, как упоминалось ранее, говоря о Неделе онлайн-покупок, Zalando снова создала группу поддержки SRE. В 2019 году она напрямую создала специальный отдел SRE. В этот отдел входят группа записи журналов, группа отслеживания инцидентов. команда реагирования и коучинг стартапов. Состав команды позволяет этой группе людей сосредоточиться на одном и том же видении и целях с помощью одного и того же набора ключевых показателей эффективности.
Эндрю Хауден отметил: «Цель отдела SRE — создать ключевую модель обслуживания бизнеса, сосредоточиться на обслуживании клиентов и решить проблемы согласования между отделами в течение последних четырех лет».
Ключевое обслуживание бизнеса — это цель уровня обслуживания (SLO), ориентированная на качество обслуживания клиентов. Измеряя взаимодействие между клиентами и веб-сайтом, точки зрения разработчиков, менеджеров и клиентов могут быть интегрированы в один и тот же набор данных, и эти данные могут быть интегрированы. использоваться для повышения надежности.
Создайте встроенную команду SRE для решения конкретных проблем по техническому обслуживанию и эксплуатации.
Недостаточно иметь специальный отдел SRE. Zalando также создала новую команду SRE под названием Embedded SRE для решения особых задач процесса оформления заказа. Например, некоторые сумасшедшие покупатели внезапно начинают продавать определенные продукты в больших объемах, вызывая некоторые системные проблемы. Этот тип проблемы процесса оформления заказа предполагает взаимодействие и сотрудничество между более чем дюжиной приложений, 4 или 5 отделами и сотнями инженеров. Эндрю Хауден — лидер этой команды и возглавляет двух инженеров.
Эндрю Хауден сначала проанализировал влияние связанных продуктовых систем на различные исключения при оформлении заказа и нашел решения одно за другим. Он справился с такими проблемами, как большое количество запросов, которые перегружали систему и не отвечали, что приводило к автоматическому перезапуску программного обеспечения управления кластером, но приводило к завершению работы всей системы.
Поскольку система проверки представляет собой крупномасштабную распределенную микросервисную архитектуру, она изначально была разработана в режиме автоматического выключателя, чтобы избежать постоянного вызова одной и той же неисправной службы. Однако, поскольку конструкция автоматического выключателя слишком чувствительна, при сбое системы она происходит. начинает влиять Оценка частоты ошибок автоматических выключателей в других системах будет иметь каскадный эффект.
Или другая проблема заключается в том, что для обеспечения надежности система оформления заказов разработала множество механизмов автоматического расширения. Как только обнаруживается, что скорость ответа на запрос клиента на оформление заказа замедлилась, она автоматически расширяется. Однако это привело к резкому увеличению. в облачных затратах. Позже было обнаружено, что небольшое количество клиентов генерирует большое количество запросов из-за своего покупательского поведения, в результате чего эта небольшая группа людей реагирует медленно. определяется стандартом, охватывающим 99.9% обычных клиентов. Верхний предел количества запросов для клиента может снизить влияние безумного поведения конкретного клиента на механизм автоматического расширения.
Интеграция опыта решения проблем технического обслуживания в ежедневное обслуживание
Потому что обычно на решение проблемы уходит всего 3 недели, но требуется 3 месяца, чтобы передать опыт решения этой ненормальной проблемы команде платформы и различным участвующим группам, ответственным за продукт. Последняя задача внедрения команды SRE — как превратить опыт решения этих проблем обслуживания в часть ежедневного обслуживания.
Каждую неделю Zalando проводит еженедельные совещания по обзору эксплуатации (WORM). Сообщество главных инженеров использует это собрание для рассмотрения отчетов по результатам анализа и рассмотрения различных вопросов технического обслуживания. Однако качество этих аналитических отчетов сильно различается, и инженеры тратят много усилий на подготовку этих документов.
Внедрение группы SRE помогает автоматизировать процесс создания таких аналитических отчетов и даже добавляет предложения по корректировке соответствующих методов SRE. Отчет можно автоматически отправлять этой группе, а также отчет можно автоматически отправлять группе инженерного управления для еженедельного рассмотрения. .
В середине 2023 года встроенная группа SRE завершила задачи, для решения которых она изначально была создана, завершив миссию команды. Эндрю Хауден также завершил свою работу в Заландо в августе и стал консультантом, проводящим обучение SRE.
Однако разработка платформ Zalando не остановила темп изменений и продолжает развиваться.