Русский
Русский
English
Статистика
Реклама

Спортмастер

Мониторим Спортмастер как и чем

03.09.2020 20:17:52 | Автор: admin
О создании системы мониторинга мы задумались на этапе формирования продуктовых команд. Стало понятно, что наше дело эксплуатация в эти команды никак не попадает. Почему так?

Дело в том, что все наши команды построены вокруг отдельных информационных систем, микросервисов и фронтов, поэтому общее состояние здоровья всей системы в целом команды не видят. Например, они могут не знать, как какая-то небольшая часть в глубоком бэкенде влияет на фронтовую часть. Круг их интересов ограничивается системами, с которыми интегрирована их система. Если же команда и её сервис А почти никак не связан с сервисом Б, то такой сервис для команды почти невидим.



Наша же команда, в свою очередь, работает с системами, которые очень сильно интегрированы между собой: между ними множество связей, это весьма большая инфраструктура. И от всех этих систем (которых у нас, к слову, огромное количество), зависит работа интернет-магазина.

Вот и получается, что наш отдел не относится ни к одной команде, а находится немного в стороне. Во всей этой истории наша задача понимать в комплексе, как работают информационные системы, их функциональность, интеграции, ПО, сеть, железо, и как все это связано между собой.

Платформа, на которой функционируют наши интернет-магазины, выглядит так:

  • front
  • middle-office
  • back-office

Как бы нам ни хотелось, но не бывает такого, чтобы все системы работали гладко и безукоризненно. Дело, опять же, в количестве систем и интеграций при таком, как у нас, какие-то инциденты это неизбежность, несмотря на качество тестирования. Причем как внутри какой-то отдельной системы, так и в плане их интеграции. И нужно следить за состоянием всей платформы комплексно, а не какой-нибудь отдельной её части.

В идеале наблюдение за состоянием здоровья всей платформы нужно автоматизировать. И мы пришли к мониторингу как к неизбежной части этого процесса. Изначально он был построен только для фронтовой части, при этом собственные системы мониторинга по слоям были и есть у сетевиков, администраторов ПО и аппаратного обеспечения. Все эти люди следили за мониторингом только на своем уровне, комплексного понимания тоже ни у кого не было.

Например, если упала виртуальная машина, в большинстве случаев об этом знает только администратор, отвечающий за hardware и виртуальную машину. Команда фронта в таких случаях видела сам факт падения приложения, но данных о падении виртуальной машины у неё не было. А администратор может знать, кто заказчик, и примерно представлять, что именно сейчас на этой виртуальной машине крутится, при условии, что это какой-то большой проект. Про маленькие он, скорее всего, не знает. В любом случае, администратору нужно идти к владельцу, спрашивать, что же на этой машине было, что нужно восстанавливать и что поменять. А если ломалось что-то совсем серьезное, начиналась беготня по кругу потому что никто не видел систему в целом.

В конечном счете такие разрозненные истории влияют на весь фронтенд, на пользователей и нашу основную бизнес-функцию интернет-продажи. Так как мы не входим в команды, а занимаемся эксплуатацией всех ecommerce-приложений в составе интернет-магазина, мы взяли на себя задачу по созданию комплексной системы мониторинга ecommerce-платформы.

Структура системы и стек


Мы начали с того, что выделили несколько слоёв мониторинга для наших систем, в разрезе которых нам потребуется собирать метрики. И все это нужно было объединить, что мы и сделали на первом этапе. Сейчас по этому этапу мы дорабатываем максимально качественный сбор метрик по всем нашим слоям, чтобы выстраивать корреляцию и понимать, как системы влияют друг на друга.

Отсутствие комплексного мониторинга на начальных этапах запуска приложений (так как мы начали строить его, когда большая часть систем была в эксплуатации) привело к тому, что у нас образовался значительный технический долг по настройке мониторинга всей платформы. Сосредотачиваться на настройке мониторинга какой-то одной ИС и детально прорабатывать мониторинг для неё мы не могли себе позволить, так как остальные системы остались бы на какое-то время без мониторинга. Для решения этой задачи мы определили список самых необходимых метрик оценки состояния информационной системы по слоям и начали его внедрять.

Поэтому слона решили есть по частям.

Наша система складывается из:

  • hardware;
  • операционной системы;
  • software;
  • UI-части в приложении мониторинга;
  • бизнес-метрики;
  • приложения интеграции;
  • информационной безопасности;
  • сети;
  • балансировщика трафика.



В центре этой системы собственно мониторинг. Чтобы в общем понимать состояние всей системы, надо знать, что происходит с приложениями на всех этих слоях и в разрезе всего множества приложений.

Так вот, про стек.



Используем ПО с открытым исходным кодом. В центре у нас Zabbix, который мы используем в первую очередь как систему алертинга. Всем известно, что он идеально подходит для мониторинга инфраструктуры. Что здесь имеется в виду? Как раз те низкоуровневые метрики, которые есть у каждой компании, которая содержит свой ЦОД (а у Спортмастера свои ЦОДы) температура сервера, состояние памяти, рейда, метрики сетевых устройств.

Мы интегрировали Zabbix с мессенджером Telegram и Microsoft Teams, активно используемыми в командах. Zabbix покрывает слой фактической сети, железа и частично ПО, но это не панацея. Мы эти данные обогащаем из некоторых других сервисов. Например, по уровню аппаратного обеспечения мы напрямую по API коннектимся в нашей системе виртуализации и забираем данные.

Что ещё. Помимо Zabbix мы используем Prometheus, который позволяет мониторить метрики в приложении динамической среды. То есть, мы можем получать метрики приложения по HTTP endpoint и не переживать по поводу того, какие метрики в нее загружать, а какие нет. На основании этих данных можно прорабатывать аналитические запросы.

Источники данных для остальных слоев, например, бизнес-метрик, у нас делятся на три составляющие.

Во-первых, это внешние бизнесовые системы, Google Analytics, собираем метрики из логов. Из них мы получаем данные по активным пользователям, конверсии и всему прочему, связанному с бизнесом. Во-вторых, это система UI-мониторинга. О ней следует рассказать более подробно.

Когда-то мы начинали с мануального тестирования и оно перерасло в автотесты функционала и интеграций. Из него мы и сделали мониторинг, оставив только основной функционал, и завязались на маркеры, которые максимально стабильны и не часто меняются со временем.

Новая структура команд подразумевает, что вся деятельность по приложениям замыкается на продуктовых командах, поэтому чистым тестированием мы заниматься перестали. Вместо этого мы из тестов сделали UI-мониторинг, написанный на Java, Selenium и Jenkins (используется как система запуска и генерации отчетов).

У нас было много тестов, но в итоге мы решили выходить на главную дорогу, верхнеуровневую метрику. И если у нас будет много специфических тестов, то будет сложно поддерживать актуальность данных. Каждый последующий релиз будет значительно ломать всю систему, а мы только и будем заниматься ее починкой. Поэтому мы завязались на совсем фундаментальные вещи, которые редко меняются, и мониторим только их.

Наконец, в-третьих, источником данных является централизованная система логирования. Для логов используем Elastic Stack, а потом эти данные можем затягивать в нашу систему мониторинга по бизнес-метрикам. В дополнение ко всему этому работает наш собственный сервис Monitoring API, написанный на Python, который опрашивает по API любые сервисы и забирает в Zabbix данные из них.

Еще один незаменимый атрибут мониторинга визуализация. У нас она строится на основе Grafana. Среди прочих систем визуализации она выделяется тем, что на дашборде можно визуализировать метрики из разных источников данных. Мы можем собрать верхнеуровневые метрики интернет-магазина, например, количество заказов, оформленных за последний час, из СУБД, метрики производительности ОС, на которой запущен этот интернет-магазин, из Zabbix, а метрики инстансов этого приложения из Prometheus. И все это будет на одном дашборде. Наглядно и доступно.

Отмечу про безопасность мы сейчас допиливаем систему, которую впоследствии будем интегрировать с глобальной системой мониторинга. На мой взгляд, основные проблемы, с которыми сталкивается e-commerce в сфере информационной безопасности, связаны с ботами, парсерами и брутфорсом. За этим нужно следить, потому что они все это может критично повлиять как на работу наших приложений, так и на репутацию с точки зрения бизнеса. И выбранным стеком мы эти задачи успешно покрываем.

Ещё важный момент уровень приложений собирается Prometheusом. Сам он он у нас тоже интегрирован с Zabbix. И ещё у нас есть sitespeed, сервис, который позволяет нам соответственно смотреть такие параметры, как скорость загрузки нашей страницы, боттлнеки, отрисовка страницы, загрузка скриптов и прочее, он тоже по API интегрирован. Так метрики у нас собираются в Zabbix, соответственно, алертим мы также оттуда. Все алерты пока уходят на основные способы отправки (пока это email и telegram, ещё подключили недавно MS Teams). В планах прокачать алертинг до такого состояния, чтобы умные боты работали как сервис и предоставляли информацию по мониторингу всем желающим продуктовым командам.

Для нас важны метрики не только отдельных информационных систем, но и общие метрики по всей инфраструктуре, которую используют приложения: кластеры физических серверов, на которых крутятся виртуалки, балансировщики трафика, Network Load Balancer-ы, сама сеть, утилизация каналов связи. Плюс метрики по нашим собственным цодам (у нас их несколько и инфраструктура довольно значительных размеров).



Плюсы нашей системы мониторинга в том, что с ее помощью мы видим состояние работоспособности всех систем, можем оценить их влияние друг на друга и на общие ресурсы. И в конечном счете она позволяет заниматься планированием ресурсов, что также входит в нашу зону ответственности. Мы управляем серверными ресурсами пулом в рамках e-commerce, вводим-выводим из эксплуатации новое оборудование, докупаем новое, проводим аудит утилизации ресурсов и прочее. Каждый год команды планируют новые проекты, развивают свои системы, и нам важно обеспечить их ресурсами.

И с помощью метрик мы видим тенденцию потребления ресурсов нашими информационными системами. И уже на их основании можем что-то планировать. На уровне виртуализации мы собираем данные и видим информацию по доступному количеству ресурсов в разрезе ЦОДов. А уже внутри ЦОДа видна и утилизация, и фактическое распределение, потребление ресурсов. Причем как со standalone-серверами, так и виртуальными машинами и кластерами физических серверов, на которых все эти виртуалки бодро крутятся.

Перспективы


Сейчас у нас готово ядро системы в целом, но осталось достаточно моментов, над которыми еще предстоит работать. Как минимум это слой информационной безопасности, но важно также добраться до сети, развить алертинг и решить вопрос с корреляцией. Слоев и систем у нас много, на каждом слое еще множество метрик. Получается матрёшка в степени матрёшки.

Наша задача в конечном счете сделать правильные алерты. Например, если случилась проблема с аппаратной частью, опять же, с виртуальной машиной, а там было важное приложение, и сервис был никак не зарезервирован. Мы узнаем, что виртуальная машина умерла. Затем будут алертить бизнес-метрики: пользователи куда-то пропали, конверсии нет, UI в интерфейсе недоступен, ПО и сервисы тоже умерли.

При таком раскладе мы получим спам из алертов, а это уже не укладывается в формат правильной системы мониторинга. Встает вопрос корреляции. Поэтому в идеале наша система мониторинга должна сказать: Ребята, у вас физическая машина умерла, а вместе с ней вот это приложение и такие метрики, с помощью одного алерта вместо того, чтобы яростно засыпать нас сотней алертов. Она должна сообщить о главном о причине, что способствует оперативности устранения проблемы за счёт её локализации.

Наша система оповещений и обработка алертов построена вокруг круглосуточной службы горячей линии. Все алерты, которые считаются у нас маст-хэвом и входят в чек-лист, передаются туда. Каждый алерт должен обязательно иметь описание: что произошло, что это, собственно, значит, на что влияет. А еще ссылку на дашборд и инструкцию, что же в этом случае нужно делать.

Это все, что касается требований к построению алертинга. Дальше ситуация может развиваться в двух направлениях либо проблема есть и ее нужно решать, либо произошел сбой в системе мониторинга. Но в любом случае, нужно идти и разбираться.

В среднем сейчас за сутки нам падает около сотни алертов, это с учетом того, что корреляция алертов еще не настроена должным образом. И если нужно провести технические работы, и мы что-то принудительно отключаем, их число вырастает в разы.

Помимо мониторинга по системам, которые мы эксплуатируем, и сбора метрик, которые на нашей стороне расцениваются как важные, система мониторинга позволяет собирать данные для продуктовых команд. Они могут влиять на состав метрик в рамках информационных систем, которые мониторятся у нас.

Наш коллега может прийти и попросить добавить какую-нибудь метрику, которая окажется полезной и для нас, и для команды. Или, например, команде может быть недостаточно тех базовых метрик, которые у нас есть, им нужно отслеживать какую-то специфическую. В Grafana мы создаём пространство для каждой команды и выдаём права админа. Также, если команде нужны дашборды, а они сами не могут/не знают как это сделать, мы им помогаем.

Так как мы вне потока создания ценностей команды, их релизов и планирования, мы постепенно приходим к тому, что релизы всех систем бесшовные и их можно выкатывать ежедневно, не согласовывая при этом с нами. А нам важно отслеживать эти релизы, потому что потенциально они могут повлиять на работу приложения и что-то сломать, а это критично. Для управления релизами мы используем Bamboo, откуда по API получаем данные и можем видеть, какие релизы в каких информационных системах вышли и их статус. И самое важное в какое время. Маркеры о релизах мы накладываем на основные критичные метрики, что визуально является весьма показательным в случае проблем.

Таким образом мы можем видеть корреляцию между новыми релизами и возникающими проблемами. Основная идея в том, чтобы понимать, как работает система на всех слоях, быстро локализовать проблему и так же быстро ее исправить. Ведь часто бывает так, что больше всего времени занимает не решение проблемы, а поиск причины.

И по этому направлению в будущем мы хотим сфокусироваться на проактивности. В идеале хотелось бы заранее узнавать о приближающейся проблеме, а не постфактум, чтобы заниматься ее предупреждением, а не решением. Порой случаются ложные срабатывания системы мониторинга, как из-за человеческой ошибки, так и из-за изменений в приложении.И мы работаем над этим, отлаживаем, и стараемся перед любыми манипуляциями над системой мониторинга предупреждать об этом пользователей, которые ее используют вместе с нами, либо проводить эти мероприятия в тех.окно.

Итак, система запущена и успешно работает с начала весны и показывает вполне реальный профит. Конечно, это не ее финальная версия, мы будет внедрять еще множество полезностей. Но прямо сейчас, при таком большом количестве интеграций и приложений, без автоматизации мониторинга на самом деле не обойтись.

Если вы тоже мониторите большие проекты с серьезным количеством интеграций напишите в комментариях, какую серебряную пулю нашли для этого.
Подробнее..

Ускоряем доставку изменений в классический windows-монолит

16.12.2020 16:22:14 | Автор: admin
Добрый день, коллеги! Позвольте представиться меня зовут Павел Бацев, я администратор сервисов в ГК Спортмастер. В системном администрирование 8 лет, второй год занимаюсь изучением и внедрением devops-практик.

Сегодня я предлагаю рассмотреть вам кейс, который, прежде всего, будет интересен администраторам и инженерам с парком windows-хостов и монолитными системами.

Под катом: некоторые особенности работы конвейера доставки, работающего с использованием windows-агентов bamboo; проблемы, возникающие при использовании dsc и jea-сессий powershell в домене с устаревшим уровнем леса, и варианты их решения; способ внедрения автоматического ui-тестирования без задействования профессиональных тестировщиков.

Итак, рассмотрим, исходные данные:

Имеем бизнес-критичную информационную систему, которая интегрирована с системой внутреннего документооборота, системой заявок в Службу горячей линии, 1С.

На момент получения системы в поддержку у нас не было стратегии по релизам, поэтому все операции, связанные с обновлением той или иной компоненты, выполнялись в мануальном режиме, зоны ответственности были размазаны, не было организовано четкой, взаимодополняющей работы между командами разработки, администрирования и аналитики (как представителя бизнеса).

Система, о которой идет речь, имеет классическую монолитную архитектуру и состоит из:

  • Базы данных MS SQL;
  • Веб-сервера IIS;
  • Веб-сервиса IIS;
  • Шедуллера регламентных заданий Служба Windows;
  • Кеша Redis, как служба Windows.


Как вы понимаете, это система, в которой полная потеря функциональности может возникнуть при выходе из строя любого из компонентов. Что сильно усложняет гибкость в подходе и частоте доставки изменений.

Исходя из рутинных задач были определены операции, которые требуют автоматизации и выполнение в рамках единого конвейера, а также учтён задел на последующие развитие:

  • Доставка сборок (сформированных артефактов) на целевые хосты веб-серверов;
  • Кастомизация сборок правкой файлов контента, параметров верстки, адресов сторонних плагинов и прочее.
  • Выполнение скриптов миграций утилитой (набором bat/ps-скриптов) от разработчика, находящейся в теле сборки;
  • Организация верной последовательности запуска системы;
  • Лёгкий откат при возникновении неполадок конвейера и ошибках кода.
  • Масштабируемость выполнения (при росте агентов bamboo, росте количества целевых контуров/хостов и т.п.) и унификация для различных контуров (dev, test, stage, prod);
  • Использование вычислительных мощностей агентов bamboo;
  • Вывод полного и читабельного лога выполнения всех шагов в ui bamboo;
  • Организация возможности выполнения конвейера и первичной диагностики возникающих проблем командой аналитики, а не техническим экспертом или т.п.
  • Реализация системы оповещения о результатах выполнения конвейера в удобный бизнесу инструмент: выбор пал на канал telegram (простейшая реализация chatops).


В нашей компании реализованы различные инструменты, позволяющие внедрять практики devops. На момент моего вступления в должность администратора сервисов наиболее развитым и способным покрыть поставленные задачи был стек от Atlassian, поэтому реализацию конвейера было решено выполнять, используя связку jira+bitbucket+bamboo.

Так как обслуживаемая система использует ОС Windows Server, а имеющийся на тот момент пул bamboo-агентов был на *nix, возникла идея проверки работы кроссплатформенного взаимодействия. Всё было хорошо, powershell core, установленный на *nix-агенты, работал исправно, но при тестировании сетевого взаимодействия выяснилась проблема не отрабатывали второй тап аутентификации между windows-хостами.

Какие варианты решения были рассмотрены


Попробовали мы вот что.

  • установка библиотеки Kerberos и работа по аналогии с Ansible for Windows;
  • использование Python PowerShell Remoting Protocol Client library и зависимых с ним пакетов;
  • использование windows агентов bamboo.

После обсуждения с коллегами предложенных вариантов мы решились на внедрение некоторого количества агентов bamboo на windows, что позволило унифицировать платформу агента и целевой системы, отказаться от длительной исследовательской деятельности, а также обезопасило от возможных проявлений неявных проблем при кроссплатформенной работе инструментов ci/cd.

Не обошлось без сложностей и при реализации конвейера доставки изменений на базе windows агентов bamboo, куда же без проблем. Собственно, вот они:

  • текущий лес ad не поддерживает групповые управляемые учетные записи служб (gMSA);
  • при использовании встроенного плагина bamboo по обработке скриптов Script и хранении скриптов в СКВ, при получении ошибок powershell встроенные интерпретатор bamboo не воспринимал их и завершал задачи\задания\шаги\планы, как удачные;
  • сторонний плагин Parse Log Task для простейшего парсинга ошибок по заданным паттернам было невозможно добавить в задачи Deployment Projects.

Реализованный конвейер


Остановимся на общей концепции, инструментах и некоторых особенностях.

Система контроля версий


В качестве СКВ используется bitbucket, но так как используется ПО с закрытым исходным кодом, то в СКВ хранится только обвес (скрипты и конфиги) для нормальной работы конвейера. Хранение скриптов конвейера организовано в рамках одного репозитория, разделение контуров\типа конвейера идёт по бранчам. Структура папок для всех бранчей унифицирована.



CI/CD


Реализация всех процессов CI/CD сведена в выполнение билд-плана bamboo по причинам, выявленным в процессе разработки концепта, и наличия некоторых недостатков инструментария от Atlassian.



Все шаги унифицированы и представляют собой задание, разделенное на несколько простых задач. Разберем на примере шага Build.

Так как система использует ПО с закрытым исходным кодом, то как такового классического билда нет. В рамках конвейера в этот термин вложен смысл получения сборки, загрузки сборки на целевой хост, обработка и кастомизация.

Да, отмечу, что при реализации всех шагов конвейера используется инструментарий powershell. В частности dsc и jea. А раз была проблема с использованием gMSA, то мы разработали концепцию с задействованием временных шар, срок жизни которых ограничен временем выполнения задания конвейера. Отсюда появляются задачи с характерным признаком TFP и DelShare:

  • создание временной области на текущем агенте:
  • удаление временной области на текущем агенте.


В итоге вроде бы простейшее задание разбивается на семь задач:

  1. получение кода скриптов на агент bamboo;
  2. создание временной области, для хранения dsc;
  3. парсер результата задачи создания временной области;
  4. выполнение основной смысловой задачи шага;
  5. парсер результата выполнение основной задачи;
  6. удаление временной области;
  7. парсер результата задачи удаление временной области.


В рамках билд-плана создали зависимость выполнения другого билд-плана для реализации оповещений в telegram.





Этот конвейер является базовым и разделен на бранч-планы поконтурно для минимизации количества отдельных идентичных планов. В дальнейших конвейерах мы доработали паттерны ошибок, именование тестов, доработали/переработали скрипты ps и сделали прочие полезные изменения.

Одним из результатов стал конвейер обновления версии платформы для продуктивного контура.

Также реализовали конвейеры, покрывающие другие типовые задачи: обновление сущностей БД, используя утилиту собственной разработки подрядчика или утилиту от redgate; автоматическое ui тестирование системы; обновление\добавление кастомного контента js\css; перезапуск системы непродуктивного контура; оповещения в telegram.

Написали инструкции для группы аналитиков и провели обучающие встречи по использованию инструментов CI/CD.

А ещё разработали концепт и протестировали выполнение конвейеров по переходам бизнес-процесса в jira\отложенному заданию (не востребовано, т.к. заказчик пожелал использовать ui bamboo).

Ближайшие планы


  • перенос хранения сборок с сетевой шары в Artifactory;
  • после обновления леса ad внедрение gMSA;
  • написание своего плагина bamboo для оповещений в telegram;
  • написание своего плагина bamboo для парсинга результатов выполнения ps-скриптов из файла.


Автотестирование без профессиональных тестировщиков


Теперь же про успешно реализованный кейс по разработке и внедрению UI-автотестов с минимальными трудозатратами и квалификацией по инструментарию.

От бизнеса были получены сценарии с описанием бизнес-процессов, критичных к отслеживанию.

В качестве инструментария мы взяли:

  • selenium ide как доступная и удобная платформа для формирования скелета автотеста с возможностью импорта в различные языки программирования;
  • selenium webdriver+node js+mocha как связка кроссплатформенная инструментов, подходящая к текущей конфигурации и набору установленных плагинов в bamboo;
  • windows-агенты bamboo как раннеры тестов;
  • allure как визуализатор результатов для бизнеса, удобный и простой в понимании;
  • канал telegram как простейшая реализация chatops.


В selenium ide были записаны скелеты автотестов по сценариям от бизнеса.



Сценарии были импортированы в js и доработаны для выполнения в рамках выбранного инструментария.

Полученные конечные скрипты для UI-автотестирования были загружены в СКВ и разбиты по контурам.



После успешного завершения конвейер релиза, в зависимости от контура, запускает конвейер UI-тестирования.

По завершении формируется артефакт с детальным логом выполнения.


Все тесты завершены успешно


Все или часть тестов завершены неудачно

Плюс в telegram-канал приходит информация о результате, с детальным логом результатов.


Все тесты завершены успешно


Все или часть тестов завершены неудачно

Затем проведена передача знаний команде аналитиков, которая на основе сформированных скелетов и завершенных скриптов автотестирования самостоятельно выполняет доработку\разработку.

Это дает возможность:

  • исключить лишние шаги по постановке/проверке выполнения заданий между командами администрирования и аналитики;
  • увеличить вовлечённость команд в общий процесс внедрения devops-практик;
  • де-факто организовать прообраз продуктовой команды;
  • ускорить реализацию заданий от бизнеса.


Если вы сталкивались с подобным и используете windows-монолит, поделитесь, пожалуйста, своим опытом доставки изменений.
Подробнее..

Как мы делали SM Lab Analyst Day первый митап по системной аналитике в Sportmaster Lab ( видео всех докладов)

25.03.2021 14:07:14 | Автор: admin

Всем привет. Меня зовут Кирилл Капранов, я руководитель направления системного анализа в компании Sportmaster Lab. 10 марта 2021 года мы с коллегами сделали первый митап по системному анализу, и я хочу поделиться с вами тем, как это было.

Что первым приходит в голову, когда слышишь фразу: "работаю в Спортмастере"? Уверен, у 90% людей промелькнет в голове: "Хм, наверное, продаёт кроссовки". Почему именно эти стереотипы?

Всё просто: в прошлом компания "Спортмастер" делала упор на развитие розничной сети, создание собственного производства, налаживание сети поставок, и, хотя ИТ в этом играло большую роль, знали об этом только внутри компании.

С каждым годом развивающая роль ИТ увеличивалась, но существующая структура компании не позволяла покрывать потребности бизнеса, и в компании началась цифровая трансформация. Внутри цифровой трансформации мы проделали и продолжаем делать большую работу, подробнее можно почитать тут и тут. Мне бы хотелось выделить 2 значимые вехи трансформации:

  • Создание продуктовых команд;

  • Создание центров компетенций.

Когда мы трансформировались, было сформировано отдельное ИТ-подразделение, которое получило название Sportmaster Lab. В это подразделение вошли центры компетенции разработки, системного анализа, QA и методологии.

На этом я подведу черту и перейду к теме статьи. Подробнее о трансформации и роли ЦК аналитики можете послушать в выступлении Сергея Павлова, руководителя направления системного анализа в Спортмастере.

Как мы делали SM Lab Analyst Day

Как появилась идея провести митап?

Центр компетенции (далее - ЦК) аналитики появился меньше года назад. За это время ЦК объединил больше сотни сотрудников из 30 разных команд. Мы выработали стандарты, процессы, подходы и до сих пор прорабатываем решения, которые помогают развивать сотрудников и поддерживать развитие компании.

Однажды мы задали себе вопрос : "А кто об этом знает?". Ответ был неприятный, но честный : "Никто, кроме нас".

Ну что ж, приняли. Пора действовать.

Как спланировали

Любая идея начинается с плана. Наш случай не исключение. Мы оформили план в виде следующего списка:

Цель митапа: Формат проведения: Продвижение: Целевое количество людей: Количество докладов: Тайминг: Этапы подготовки: Договоренности:

План готов, а что с ним делать дальше?

Подготовка к митапу

Для себя мы выделили такие этапы подготовки:

  • Анонс о проведении митапа на сотрудников ЦК, призыв к действию

    На данном этапе важно донести до сотрудников ценность проведения митапа, а также прояснить все оставшиеся вводные:

    • Формат проведения

    • Количество докладов

    • Дата проведения

    • TO-DO list

Эту активность провели в корпоративных чатах и на встречах с сотрудниками. А потом начался этап сбора заявок на выступление.

  • Сбор заявок на выступление

Часто бывает, что на старте подготовки к митапу докладов нет, а есть только идея и желание. Но как же понять суть доклада, его мессадж? Инструменты для выполнения этой задачи можно объединить в такие структурные блоки*:*

  • Идея доклада. Это опыт, трудности или факап, который вдохновил сделать эти выводы.

  • Описание. Краткое изложение материала.

  • Почему это интересно слушать.

Эта информация помогает получить представление о выступлении без подготовки доклада и презентации целиком.

В нашем случае удалось немного прочитерить :)

В SM Lab у нас регулярно проходят внутренние клубы, предназначенные для того, чтобы делиться опытом или показывать полезные инструменты, упрощающие жизнь. Поэтому на старте мы имели порядка 8 тем с готовыми докладами.

Ну всё: считай, дело сделано, расходимся! Но нет...

  • Отбор докладов

Когда хочешь пойти в кино, то вряд ли пойдёшь на фильм, которые тебе неинтересен, ведь так же?

То же самое происходит и при проведении ИТ мероприятий. Нужно заинтересовать своего слушателя.

О чем интересно слушать:

  • Улучшение процессов (с цифрами)

  • Как я могу переиспользовать полученную информацию

  • Практический опыт, разбор примера

  • Факапы и какие выводы из этого были сделаны

  • Как увеличить личную или командную эффективность

О чем слушать не хочется:

  • Мы придумали штуку, но мы её не попробовали

  • Я прочитал статью или книгу, теперь я вам её перескажу

  • Мы тут сделали у себя локальную штуку, послушайте

  • Я расскажу всем известную информацию

Мы взяли бритву Оккама и применили эти списки к своим 8 докладам. Таким образом, у нас осталось 6 докладов и 4 спикера. Так как у каждого из двух спикеров было по два доклада, то мы отдали право выбора им. Так получился тот список докладов, который решили рассказывать на нашем митапе. Теперь пора подумать о продвижении.

  • Начало продвижения

    Для продвижения любого мероприятия нужны деньги ... на самом деле, не cовсем :). Деньги нужны, но не так много, как вы могли бы подумать, особенно в 2021 году, в эру онлайна.

    Для продвижения мероприятия важно подсветить следующие пункты:

    • Где будет проходить запись на мероприятие

    • Целевая аудитория

    • Инструмент проведения мероприятия

    Для своего мероприятия мы выбрали площадкой Timepad. Сначала мы рассматривали его только как инструмент записи на мероприятие, но, изучив его, поняли, что Timepad идеально подходит для нашего мероприятия, так как позволяет делать трансляции на 500 человек.

    В качестве целевой аудитории выбрали профиль обычного системного аналитика специалиста с компетенцией в системном анализе, работающего в команде, не тимлида, не руководителя и не бизнес аналитика.

    И вот теперь, кажется, всё готово! Но нет...

    Заходя в анонс мероприятия, человек должен понимать, какую ценность он получит на выходе. Для этого необходимы тезисы краткие и емкие, отражающие суть доклада.

    Мы их сформулировали, теперь пора переходить к следующему этапу.

  • Тестовые прогоны

    Кажется, что тут всё просто: собирай встречи на спикеров и всех заинтересованных людей и проводи прогоны. Исправляй неточности, предлагай улучшения по презентации и докладу, задавай вопросы. Но много репетиций и правок совсем не гарант того, что финальный результат понравится публике. Мы посовещались и выбрали два прогона необходимым максимумом для митапа. И не прогадали.

Проведение митапа

Митап SM Lab analyst day состоялся 10 марта 2021 года. Пик слушателей составлял 200 человек. Среди участников митапа были cотрудники Сбербанка, Tinkoff, Райффайзенбанка, Альфа-Банка, МТС, EPAM, банка Открытие и РТЛабс и многих других компаний.

О чём мы рассказывали:

Пантелеева Елизавета -Работа в Спортмастере на примере проекта "Новый интернет магазин"

Лиза работает системным аналитиком в команде "Новый интернет магазин", которая состоит из 20 сотрудников (системные аналитики, бэкенд и фронтенд-разработчики, тестировщики).

В докладе Лиза затронула следующие моменты:

  • Как устроена работа продуктовой команды в компании Спортмастер

  • Как мы пришли к продуктовому подходу и какую проблему хотели решить

  • Кто и как проводит декомпозицию задач

  • Как задача переходит в работу и какие стадии она проходит

  • Какова роль системного аналитика

Полуян Артем -Практический кейс замещения аналитиками роли Тестировщик.

Когда ключевой сотрудник уходит из компании, это становится головной болью команды. Думаю, что многие из вас сталкивались с этой неприятной ситуацией. Появляются вопросы, требующие незамедлительного решения что же с этим делать, кто возьмёт на себя роль этого человека.

В докладе Артёма есть ответы на эти вопросы:

  • Как команда может остаться без одной из компетенций

  • Кто и каким образом может забрать на себя работу в момент поиска специалистов

  • Какие подходы в команде опробовали при замещении компетенции

  • Как происходил онбординг и обучение новых сотрудников

  • Какие выводы сделала команда и сам Артем

  • Практические советы по онбордингу нового сотрудника

Заев Артем -Ходим с разработчиками налево!Или Как уменьшить потери на пробелах в бизнес-постановках

Как мы знаем, cистемный аналитик выступает связующим звеном между бизнесом и командой, но зачастую аналитик смотрит на задачу верхнеуровнево и не может задать вопросы бизнесу, которые возникают из-за специфики слоев разработки. Системный аналитик становится "лишним звеном" в цепочке: бизнес-аналитик-разработчик. Как же построить прямой диалог?

Артем поделился кейсом о том, как смогли сначала наладить диалог между командой разработки и заказчика, а потом и уменьшить количество прямого общения c помощью интерактивных досок Miro. Он рассказал о функционале Miro применимо ко Спортмастеру, о том, как общаются с помощью инструмента участники команды, и о профитах от внедрения.

Хахарев Иван -Как мы пришли к Figma или зачем учиться готовить вкусно

Однажды к Ивану в команду пришли новые разработчики и сказали, что макеты это уже прошлый век, и будущее за прототипированием. Так как Ваня человек, который любит изучать новое, он загорелся идеей исследования инструментов прототипирования. В своем докладе он рассмотрел 3 популярных инструмента Axure, Adobe XD и Figma, сравнил их между собой, а также объяснил, почему он выбрал один из них. Бонусом Ваня устроил мини-воркшоп по созданию прототипа.

Заключение

Это был наш первый митап по системному анализу: не всё прошло гладко, как это бывает в первый раз, но мы получили классный опыт проведения подобных мероприятий и рассказали миру инсайдерской информации о системной аналитике в крупном спортивном ритейлере :)

На этом мы не заканчиваем. 20-21 мая мы участвуем в конференции Analyst Days, где выступим с докладами и пообщаемся с единомышленниками на стенде компании.

Нам нравится открыто рассказывать о своей работе. Увидимся на наших новых мероприятиях!

Подробнее..

От кровавого энтерпрайза к командной работе

12.11.2020 14:14:33 | Автор: admin

.model tiny
.code
org 100h
start: mov ah,9
mov dx, offset message
int 21h
ret
message: db "Hello Habr!", 00h, 0Ah, '$'
end start

Меня зовут Сергей Минаев, я руководитель направления администрирования веб-сервисов в компании Спортмастер. Моя группа занимается разворачиванием и поддержкой всего, что связано с вебом и мобилкой.

Большинство систем мы пишем сами, но в то же время мы иногда используем и коммерческий софт. В целом можно сказать, что мы стараемся работать модно-молодежно: у нас есть автоматизация на Ansible (именно автоматизация, а не деплой), у нас есть CI/CD на Bamboo + Bitbucket. Есть оркестрация на Mesos, от него мы постепенно переходим к Kubernetes.

Есть и заявки - это не только взаимодействие с другими отделами, но и взаимодействие разработки-эксплуатации. Поэтому мы смотрим в сторону GitOps.

Наши проблемы

Одна из самых тяжелых проблем - это взаимодействие на уровне перекидывания через забор: всё, я работу свою сделал, я закончил, а работает система или нет, это уже не так важно. Перестроить такое восприятие достаточно сложно, мы пытаемся исправлять ситуацию, но дается это нелегко.

Из предыдущего вытекает еще одна проблема это подход У меня локально все работает, если у коллег в деве/проде не запустилось это их проблемы, пускай сами разбираются. Подобная проблема есть, наверное, практически у всех. Как мы стараемся ее решать: по максимуму переносить окружения на единую платформу, в нашем случае Kubernetes с динамическими окружениями.

Но только применением инструментов здесь дело не решить, необходимо проводить большую социальную работу. То есть сделать так, чтобы команды в целом понимали, что, если все работает локально это не готово. Готово это когда работает в общем окружении.

Еще одна вечная проблема - разность в окружениях. Да, можно сказать, что это наследство, но не стоит недооценивать и наши заслуги желание что-то быстро запустить. Такие моменты нельзя решить чисто технологическим путем, надо перестраивать процессы и восприятие. Культивировать понимание, что сделанное наспех и с костылями обязательно необходимо в будущем отрефакторить.

Если этого не сделать, мы когда-нибудь обязательно выстрелим себе в обе ноги сжиганием времени на обнаружение багов. Да, полностью от костылей не уйти, но нужно стараться минимизировать ущерб.

А самое печальное из всего, с чем мы сталкиваемся, связано с откладыванием решения проблемы в долгий ящик. Продуктовая команда может внести изменения в свою платформу и не уведомить нас об этом. А потом постфактум обратиться за помощью с решением проблемы, о которой мы даже догадаться не сможем. Да, я счастлив, что в моей команде прекрасные инженеры и в принципе мы можем решить практически любые задачи. Но все же лучше изменения обсуждать с командами, которые так или иначе связаны друг с другом.

И напоследок: взаимодействие со смежниками и инфраструктурой. Чтобы что-то решить, нужно заводить заявку. И если нет заявки, то нет и работы. На этом моменте много чего рушится. История с заявками в целом штука очень тяжелая, от нее сложно уйти, и полностью она не исчезнет, как бы мы ни старались с GitOps и владением инфраструктурным кодом продуктовыми командами.

DevOps ожидание vs. реальность

В общем, все эти вещи очень мешают нам жить. И обычно в таких случаях предлагают решение DevOps, который быстро, качественно и надежно всем поможет, и будем мы жить довольно и счастливо. Примерно такое представление сложилось на рынке в целом. Минимум усилий, минимум времени, все само рассосется, главное наймите DevOpsов.

Но когда доходит до практики и DevOps вроде бы появляется, обычно все получается не так, как ожидалось. Потому что обычно DevOps воспринимается как системный администратор, который умеет и админить, и программировать, и еще много чего за одну зарплату. И в лучшем случае, продуктовая команда не теряет в производительности и качестве, но обычно теряют во всем.

Как же мы видим DevOps? Для нас это и командная работа с подключением инженера эксплуатации (админа), и процесс, и методология, и философия. И главное здесь донести все до людей. Договориться, объяснить, проговорить что изменится и что нет, и только потом подключать инженера. Просто прийти и сказать: Вы теперь работаете по DevOps - этого мало. Инженер к команде не просто подключается, приходит и решает все задачи. Если работать по этому сценарию, инженер просто выгорит, а у нас все останется, как было (в лучшем случае). Все вопросы должны решаться совместно.

Помимо просто теории, процессов, необходимо понимать, что вообще происходит. То есть вводить метрики. Стандартные это время выкаток и их количество. Есть мнение, что чем их больше, тем лучше, но я с ним не согласен. Не нужно забывать про качество. Согласитесь, что выкатить что-то, а потом откатиться, или выкатить, а затем выдать фикс это не одно и то же. Я считаю, что выкатка должна быть наиболее стабильной и качественной, но этого не всегда можно добиться. И это нормально. Не все дается с первого раза, второго

Мы хотим сделать так, чтобы все было надежно, безопасно и воспроизводимо. Мы всегда можем повторить то, что мы делали, и если что-то пошло не так, мы можем достаточно спокойно откатиться. Изменение не может произойти без быстрой обратной связи, общих каналов и обмена опытом. Нельзя просто позвать инженера работать в продуктовую команду с определенным списком технологий. Он помогает и обучает команду, которая должна понимать хоть какой-то базис о специфике его работы. А инженер должен хоть немного понимать специфику продуктовой команды.

Мы понимаем, что наш подход не панацея, и что угодно может пойти не так. Главное помнить о том, что любую проблему или просто задачу нужно решать совместно.

Инструменты и социальность

Мы сталкиваемся с тем, что продуктовая команда выбирает себе инструменты сама, и в этом вроде бы нет ничего плохого. Но плохо то, что об этом выборе никто за пределами команды не знает. И если вдруг что-то случится, может оказаться так, что помочь трудно.

Вы не можете просто поставить Kubernetes и сказать всем ура, у нас Kubernetes, работаем. Это не просто софт, это платформа, вопрос экосистемы, деплоев. Kubernetes добавляет много вопросов, на которые не всегда можно быстро ответить.

Инструменты это базис, фундамент, должен быть единый технологический стек. Но должна оставаться возможность этот стек пересматривать.

Самоорганизация. Все знают, что это модно, работает и вообще здорово. Но это обоюдоострый подход. Забастовка, по сути, это тоже своего рода самоорганизация. Надо обговаривать правила игры, чтобы каждый сотрудник понимал, что и как работает, чтобы все знали границы. Если этого не сделать, команда может закрыться от подключаемых инженеров и пытаться делать все своими силами. В итоге, возможно, двигаться ничего не будет.

Автоматизация. Идеальный способ что-то испортить в процессе работы - это абсолютно бездумно что-то применять в работе и, более того, навязывать это остальным. С автоматизацией главное не перестараться, надо понимать, что и зачем, когда и для чего. Например, деплой при помощи Ansible чаще всего не очень хорошее решение

Гибкость. Нужна во всем, DevOps не может быть гибким только с одной стороны. Если так работают только инженеры/команды, а бухгалтерия не может, то получится, что команды будут ждать новых серверов долгое время. И таких историй множество.

Облака. Сейчас мы все активнее их используем, особенно для каких-то тестов и проверок гипотез. Например, есть у нас MVP его проще развернуть в облаке в пару кликов, чем ждать выделения локальных ресурсов.

Знания. Внутри команд надо обязательно делиться знаниями и обсуждать их актуальность. Болевой точкой тут может быть так называемый сотрудник-дракон, который в силу опыта или амбиций уверен, что тут только он прав и он один знает, как правильно. Мы стараемся распространять знания и доносить до всех, что мир меняется, любые парадигмы надо пересматривать.

Команда. Часто забывают про то, что все сотрудники ценны, и игнорируют тот факт, что сотрудники в целом это система. А тут критичное значение имеет то, как именно эти сотрудники взаимодействуют между собой, как общаются, как принимают решения, как договариваются. Убрав одного человека из команды или заменив его, можно потерять ценность вся команда станет работать иначе.

Что и зачем. Самые важные вопросы, которые всегда надо задавать, когда что-то делаешь, если вы хотите видеть результат. Без понимания этих вещей у вас не будет прозрачности, а реальность будет расходиться с ожиданиями.

Выводы

В первую очередь люди. Какими бы ни были ваши инструменты, процессы и лозунги, без людей и их совместной работы ничего не получится. Автоматизация спасает и уменьшает рутину, но к ней надо подходить аккуратно, чтобы не увеличить число проблем. Инструменты необходимо подбирать осознанно.

DevOps - это работа, большая работа. Нужно смотреть на методологии, подходы, выбирать то, что применимо именно к вашей ситуации, а не просто взять что-то и пытаться использовать. Да, это, скорее всего, будет дорого, но в перспективе это даст плюсы. Мы понимаем, что командам помогает такая трансформация, да и бизнесу тоже. DevOps не всегда нужен, и, занявшись его внедрением, можно сделать хуже. Это обычно заметно, если команда маленькая или не готова. Поэтому необходимо оценивать каждую команду и ситуацию индивидуально.

Подробнее..

Что помогло нам быстро перестроиться на онлайн-торговлю в новых условиях

16.09.2020 16:23:32 | Автор: admin

Привет!

Меня зовут Михаил, я заместитель директора по ИТ в компании Спортмастер. Я хочу поделиться историей о том, как мы справились с трудностями, возникшими во время пандемии.

В первые дни новых реалий привычный формат офлайн-торговли Спортмастера замер, и нагрузка на наш онлайн-канал, в первую очередь в части доставки на адрес клиенту, возросла в 10 раз. За несколько недель мы трансформировали гигантский по объему офлайн-бизнес в онлайн, адаптировали сервис под потребности наших клиентов.

В общем, то, что по сути было нашей второстепенной операцией, стало основным бизнесом. Важность каждого интернет-заказа возросла экстремально. Нужно было сохранить каждый рубль, который клиент приносил в компанию.

Чтобы оперативно реагировать на запросы клиентов, мы открыли дополнительный контактный центр в главном офисе компании, и теперь можем принимать около 285 тысяч звонков в неделю. В то же время мы перевели 270 магазинов в новый формат бесконтактной и безопасной работы, что позволило клиентам получать заказы, а сотрудникам сохранить рабочие места.

В процессе трансформации у нас возникли две основные проблемы. Во-первых, ощутимо возросла нагрузка на наши онлайн-ресурсы (как мы боролись с этим, расскажет Сергей). Во-вторых, поток редких (до COVID) операций многократно возрос, что в свою очередь потребовало большого объема быстрой автоматизации. Чтобы решить эту проблему, нам пришлось оперативно перебросить ресурсы с направлений, которые были раньше основными. Как мы справились с этим расскажет Елена.

Эксплуатация онлайн-сервисов

Колесников Сергей, отвечает за эксплуатацию интернет-магазина и микросервисов

С того момента, как наши розничные магазины начали закрываться для посетителей, мы начали фиксировать рост таких метрик, как количество пользователей, количество заказов, оформляемых в нашем приложении, количество реквестов к приложениям.

Количество заказов с 18 по 31 мартаКоличество заказов с 18 по 31 мартаКоличество запросов к микросервисам онлайн-оплатыКоличество запросов к микросервисам онлайн-оплатыКоличество оформленных на сайте заказовКоличество оформленных на сайте заказов

На первом графике мы видим, что прирост составил примерно 14 раз, на втором 4 раза. Наиболее показательной при этом мы считаем метрику времени ответа наших приложений.

На этом графике мы видим ответ фронтов и приложений, и для себя мы определили, что как такового роста мы не заметили.

В первую очередь это связано с тем, что мы начали подготовительные работы в конце 2019 года. Сейчас наши сервисы зарезервированы, обеспечена отказоустойчивость на уровне физических серверов, систем виртуализации, докеров, сервисов в них. При этом мощности наших серверных ресурсов позволяют переживать многократную нагрузку.

Основным инструментом, который помог нам во всей этой истории, стала наша система мониторинга. Правда, еще совсем недавно у нас не было единой системы, которая позволяла бы собирать метрики на всех слоях, от уровня физического оборудования и аппаратного обеспечения до уровня бизнес-метрик.

Формально мониторинг-то в компании был, но как правило он был рассредоточен и находился в зоне ответственности конкретных подразделений. Фактически, когда происходил какой-нибудь инцидент, у нас почти никогда не было единого понимания, что же именно произошло, не было информирования, и зачастую это приводило к бегу по кругу в поисках и локализации проблемы для последующего устранения.

В какой-то момент мы подумали и решили, что хватит это терпеть нам нужна единая система, чтобы видеть всю картину полностью. Основные технологии, которые входят в наш стек, это Zabbix как центр алертинга и хранения метрик, Prometheus для сбора и хранения метрик приложений, Stack ELK для логирования и хранения данных всей системы мониторинга, а также Grafana для визуализации, Swagger, Docker и другие полезные и знакомые вам штуки.

При этом мы используем не только доступные на рынке технологии, но и разрабатываем кое-что самостоятельно. Например, мы делаем сервисы для интеграции систем друг с другом, то есть некое API для сбора метрик. Плюс работаем над собственными системами мониторинга на уровне бизнес-метрик мы используем UI-тесты. А также бот в Telegram для оповещения команд.

А ещё мы стараемся делать систему мониторинга доступной для команд, чтобы они могли самостоятельно хранить свои метрики и работать с ними, в том числе настраивать алертинг в каких-то узких метриках, имеющих значение не самое широкое применение.

В рамках всей системы мы стремимся к проактивности и максимально быстрой локализации инцидентов. К тому же, количество наших микросервисов и систем значительно выросло за последнее время, соответственно, растет и число интеграций. И в рамках оптимизации процесса диагностики инцидентов на уровне интеграции мы разрабатываем систему, которая позволяет проводить кросс-системные проверки и выводить результат, что позволяет находить основные проблемы, связанные с импортами и взаимодействием систем друг с другом.

Само собой, нам еще есть куда расти и развиваться в плане эксплуатации систем, и мы активно над этим работаем. Подробнее о нашей системе мониторинга можно почитать здесь.

Технические испытания

Орлов Сергей, руководит центром компетенции веб- и мобильной разработки

С начала закрытия физических магазинов нам пришлось столкнуться с различными испытаниями с точки зрения разработки. В первую очередь, скачок нагрузки как таковой. Понятно, что если не предприняты соответствующие меры, то при подаче на систему высокой нагрузки она может с грустным хлопком превратиться в тыкву, либо полностью деградировать в производительности, либо вообще потерять свою работоспособность.

Второй аспект, чуть менее очевидный, состоит в том, что систему под высокой нагрузкой нужно было очень быстро менять, адаптируясь под изменения бизнес-процессов. Порой по нескольку раз в день. Во многих компаниях есть правило, что при больших маркетинговых активностях не стоит вносить в систему никаких изменений. Вообще никаких, пускай работает, раз работает.

А у нас по сути была бесконечная черная пятница, в которую при этом нужно было менять систему. И любая ошибка, проблема, сбой в системе очень дорого обходились бы бизнесу.

Забегая вперед, скажу, что нам удалось справиться с этими испытаниями, все системы выдержали нагрузку, легко отмасштабировались и каких-то глобальных технических сбоев у нас не было.

Существует четыре кита, на которых держится способность системы выдерживать высокую скачкообразную нагрузку. Первый из них это мониторинг, о котором вы читали чуть выше. Без выстроенной системы мониторинга практически нереально найти узкие места системы. Хорошая система мониторинга это как домашняя одежда, она должна быть удобной и адаптированной под вас.

Второй аспект это тестирование. Мы очень серьезно относимся к этому моменту: пишем и классические юниты, интеграционные, нагрузочные тесты и многие другие для каждой системы. Ещё мы пишем стратегию тестирования, и при этом стараемся довести уровень тестирования до того, чтобы ручные проверки нам больше не были нужны.

Третий кит это CI/CD Pipeline. Процессы сборки, тестирования, развертывания приложения должны быть максимально автоматизированы, здесь не должно быть ручных вмешательств. Тема CI/CD Pipeline достаточно глубока, и я затрону ее только вскользь. Стоит упомянуть только, что у нас есть чеклист CI/CD Pipeline, по которому с помощью центров компетенции проходит каждая продуктовая команда.

А вот и чеклистА вот и чеклист

Таким образом достигается очень много целей. Это версионирование API, и feature toggle, чтобы избежать паровоза релизов, и достижение покрытия разных тестов такого уровня, чтобы тестирование было полностью автоматизировано, деплои были бесшовными и прочее.

Четвертый кит это архитектурные принципы и технические решения. Про архитектуру можно говорить много и долго, но я хочу подчеркнуть пару принципов, на которых я хотел бы заострить внимание.

Во-первых, надо выбирать специализированные инструменты под конкретные задачи. Да, звучит очевидно, и понятно, что гвозди забивать стоит молотком, а наручные часы разбирать специальными отвертками. Но в наш век многие инструменты стремятся к универсализации, чтобы охватить максимальный сегмент пользователей: базы данных, кеши, фреймворки и остальное. Вот, например, если взять базу данных MongoDB, она работает с мультидокументарными транзакциями, а база данных Oracle работает с json-ми. И казалось бы, что все можно использовать для всего. Но если мы ратуем за производительность, то нам нужно четко понимать сильные и слабые стороны каждого инструмента и использовать нужные нам для нашего класса задач.

Во-вторых, при проектировании систем каждое повышение сложности должно быть обоснованным. Мы должны постоянно держать это в голове, принцип low coupling всем известен. Я считаю, что его нужно применять и на уровне конкретного сервиса, и на уровне всей системы, и на уровне архитектурного ландшафта. Также важна способность к горизонтальному масштабированию каждого компонента системы на пути нагрузки. Если обладать этой способностью, масштабирование не составит никакого труда.

Если говорить про технические решения, мы попросили продуктовые команды подготовить свежий набор рекомендаций, идей и решений, которые они реализовали в процессе подготовки к очередной волне нагрузки.

Кеши

Необходимо осознанно подходить к выбору локальных и распределенных кешей. Иногда имеет смысл использовать и те, и другие в рамках одной системы, Например, у нас есть системы, в которых часть данных по сути является витринным кешем, то есть источник обновлений находится за самой системой, и системы эти данные не меняют. Для такого подхода мы используем локальный Caffeine Cache.

А есть данные, которые система активно изменяет в процессе работы, и тут мы уже применяем распределенный кеш с Hazelcast. Такой подход позволяет нам использовать преимущества распределенного кеша там, где они действительно нужны, и минимизировать сервисные расходы по циркуляции данных кластера Hazelcast там, где мы можем без этого обойтись. Про кеши мы много писали здесь и здесь.

Кроме того, смена сериализатора на Kryo в Hazelcast дала нам неплохой прирост. А переход от ReplicatedMap к IMap + Near Cache в Hazelcast позволил нам минимизировать движение данных по кластеру.

Небольшой совет: при массовой инвалидации кеша иногда применима тактика с прогревом второго кеша с последующим переключением на него. Казалось бы, при таком подходе мы должны получить двойное потребление памяти, но на практике, в тех системах, где подобное практиковалось, потребление памяти уменьшалось.

Реактивный стек

Мы используем реактивный стек в уже достаточно большом количестве систем. В нашем случае это Webflux или Kotlin с корутинами. Особенно хорошо реактивный стек заходит там, где мы ожидаем медленные input-output операции. Например, вызовы медленных сервисов, работа с файловой системой либо системами хранения.

Наиболее важный принцип избегать блокирующих вызовов. Под капотом реактивных фреймворков крутится небольшое количество живых сервисных потоков. Если мы неосторожно позволим себе сделать прямой блокирующий вызов, как, например, вызов JDBC-драйвера, то система просто остановится.

Старайтесь обращать ошибки в собственные runtime exception. Реальный поток выполнения программы отходит к реактивным фреймворкам, выполнение кода становится нелинейным. Как следствие, очень сложно диагностировать проблемы по стек-трейсам. И решением здесь будет создание понятных объективных runtime exception-ов на каждую ошибку.

Elasticsearch

При использовании Elasticsearch не выбирать неиспользуемые данные. Это, в принципе, тоже очень простой совет, но чаще всего именно про это забывают. Если надо за раз выбрать больше 10 тысяч записей, нужно использовать Scroll. Если проводить аналогию, это немного похоже на курсор в реляционной базе данных.

Не используйте postfilter без необходимости. При больших данных в основной выборке эта операция очень сильно грузит базу данных.

Используйте bulk-операции там, где это применимо.

API

При проектировании API закладывайте требования к минимизации передаваемых данных. Особенно это актуально на связке с фронтом: именно на этом стыке мы выходим за каналы наших ЦОДов и уже работаем на канале, связывающего нас с клиентом. Если на нем есть малейшие проблемы, слишком высокий трафик вызывает негативный user experience.

И, наконец, не вываливайте всю кипу данных, четко подходите к контракту между потребителями и поставщиками.

Организационная трансформация

Ерошкина Елена, заместитель директора по ИТ

В момент, когда случился карантин, и возникла необходимость резко наращивать темпы развития онлайн и внедрять омниканальные сервисы, мы уже находились в процессе организационной трансформации.

Часть нашей структуры была переведена на работу по принципам и практикам продуктового подхода. Сформировались команды, которые теперь отвечают за функционирование и развитие каждого продукта. Сотрудники в таких командах задействованы на 100% и строят свою работу по скрам или канбан, в зависимости от того, что для них предпочтительнее, настраивают конвейер развертывания, внедряют технические практики, практики обеспечения качества и многое другое.

По счастливой случайности основная часть таких продуктовых команд у нас как раз находилась в области онлайн и омниканальных сервисов. Это позволило нам в кратчайшие сроки (серьезно, буквально за два дня) перейти в режим удалённой работы без потери эффективности. Настроенный процесс позволил быстро адаптироваться к новым условиям работы и выдержать достаточно высокий темп поставки новой функциональности.

Кроме того, у нас возникла необходимость усилить те команды, которые находятся на фронтире онлайн-бизнеса. В тот момент стало понятно, что мы можем это сделать только за счет внутренних ресурсов. И порядка 50 человек за две недели сменили область, где они работали до этого, и встроились в работу над новым для них продуктом.

Для этого не потребовалось каких-то специальных управленческих усилий, потому как наряду с организацией собственного процесса, с техническим совершенствованием продукта, с практикой обеспечения качества, мы учим наши команды самоорганизации управлять собственным производственным процессом без привлечения административного ресурса.

Управленческий же ресурс мы смогли сфокусировать именно там, где это было необходимо в тот момент, на координации вместе с бизнесом: Что же именно сейчас важно для нашего клиента, какая функциональность должна быть реализована в первую очередь, что необходимо сделать, чтобы увеличить нашу пропускную способность по доставке и обработке заказов. Все это и четкая ролевая модель позволили в этот период нагружать наши производственные потоки создания ценности тем, что действительно важно и нужно.

Ясное дело, что при удалённой работе и высоком темпе изменений, когда от участия каждого зависят бизнес-показатели, нельзя полагаться только на внутренние ощущения из серии А всё ли у нас идёт хорошо? Да вроде неплохо. Необходимы объективные метрики производственного процесса. Такие у нас есть, они доступны каждому, кто интересуется метриками продуктовых команд. Прежде всего самой команде, бизнесу, смежникам и руководству.

Раз в две недели с каждой командой проводится статус, где в течение 10 минут анализируются метрики, выявляются узкие места производственного процесса и вырабатывается совместное решение: что можно сделать для того, чтобы эти узкие места устранить. Здесь же можно сразу попросить помощи у руководства в случае, если какая-то выявленная проблема находится вне зоны влияния команд, или экспертизы коллег, которые, возможно, уже сталкивались с похожей проблемой.

Тем не менее, мы понимаем, что для кратного ускорения (а именно такую цель мы себе ставим) нам еще многому необходимо научиться и внедрить в ежедневную работу. Прямо сейчас мы продолжаем масштабирование продуктового подхода на другие команды и на новые продукты. Для этого нам пришлось освоить новый для нас формат онлайн-школы методологов.

Методологи, люди которые помогают командам выстраивать процесс, налаживать коммуникации, повышать эффективность работы, по сути являются агентами изменения. Прямо сейчас выпускники нашего первого потока работают с командами и помогают им стать успешными.

Я думаю, что сложившаяся ситуация открывает для нас такие возможности и перспективы, которые, возможно, мы и сами пока ещё до конца не осознаём. Но тот опыт и та практика, которую мы получаем прямо сейчас, подтверждает, что мы выбрали правильный путь развития, не упустим в будущем эти новые возможности и сможем так же эффективно отвечать на те вызовы, которые будут стоять перед Спортмастером.

Выводы

За это непростое время мы сформулировали главные принципы, на которых держится разработка программного обеспечения, которые, думаю, будут актуальны для каждой компании, которая этим занимается.

Люди. Это то, на чем всё и держится. Сотрудники должны получать удовольствие от работы, понимать цели компании и цели продуктов, которыми они занимаются. И, конечно же, могли профессионально развиваться.

Технология. Необходимо, чтобы компания зрело подходила к работе со своим технологическим стеком и наращивала компетенции там, где это действительно необходимо. Звучит очень просто и очевидно. И очень часто игнорируется.

Процессы. Важно правильно выстроить работу продуктовых команд и центров компетенций, наладить взаимодействие с бизнесом, чтобы работать с ним как с партнером.


В общем, примерно так и выжили. Основной тезис современности подтвердился ещё раз, звонко щелкнув по лбу

Даже если ты огромный офлайн-бизнес со множеством магазинов и кучей городов присутствия, развивай свой онлайн. Это не просто дополнительный канал сбыта или красивое приложение, через которое тоже можно что-то купить (а еще потому что у конкурентов тоже красивое). Это не запаска на всякий случай, которая поможет переждать бурю.

Это сущая необходимость. К которой должны быть готовы не только ваши технические мощности и инфраструктура, но и люди и процессы. Ведь быстро докупить память, место, развернуть новые инстансы и прочее можно за пару часов. А вот людей и процессы надо готовить к такому заранее.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru