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

Контрибьютили: 

Михаил Солодягин, DevOps-инженер, эксперт по внедрению
Сергей Юнк, DevOps-инженер, руководитель группы по внедрению 
Вадим Суханов, руководитель группы разработки

Предыстория

Пара слов об Airflow — это open source инструмент для создания, оркестрации и мониторинга потоков операций по обработке данных, написанный на Python. Процессы описываются в виде операторов, которые объединяются в направленные ациклические графы, DAG-и. В нашей компании Airflow используется в основном аналитиками и дата-инженерами для запуска регулярных процессов по перегрузке данных и запуска различных расчётов.

Начинали мы с Production Airflow версии 1.10.12 в одном экземпляре, развёрнутом при помощи docker-compose на выделенной виртуальной машине. Рабочая нагрузка — 50–60 DAGов с частотой запуска от раза в 10 минут до раза в час плюс несколько DAGов с запуском раз в месяц. 

За основу мы взяли довольно известный образ от Puckel, который впоследствии модифицировали дополнительными библиотеками и драйверами, а затем перевели на CentOS. 

Что касается тестовой среды, схема будет такой же, только на одной виртуалке поднято сразу 4 инстанса Airflow. Хранение кода и деплой осуществлялись силами gitlab и gitlab CI, при этом деплой был в виде zip-архива, а коммуникация по стендам осуществлялась в Slack.

Когда количество пользователей Airflow в компании увеличилось, мы столкнулись с тем, что тестовых стендов стало не хватать. Для решения проблемы в моменте была придумана система «букинга» стендов через Slack: когда кому-то был нужен стенд, он объявлял об этом в специальном чате, и если стенд оказывался не занят, человек занимал его, а после окончания использования писал о том, что стенд освободился. 

Помимо проблемы доступности стенда, в первоначальной схеме были и другие слабые места:

1. Для работы DAG’ов необходим набор так называемых секретов. Обычно это логины и пароли, адреса подключений или же переменные, содержимое которых хотелось бы скрыть от посторонних глаз. Изначально airflow предполагает хранение секретов в своей БД, а это значит, что данных, которые есть на стенде А, могло не оказаться на стенде Б.

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

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

4. А ещё мы сталкивались с ситуациями, когда стенд мог кто-нибудь сломать. При этом продиагностировать ситуацию самостоятельно было не всегда возможно.

Задача

Нужное нам решение должно было закрыть все описанные выше проблемы и при этом содержать в себе следующие хотелки наших пользователей:

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

• Возможность экспериментировать с различными версиями и набором библиотек и версиями самого Airflow без опасения сломать стенд. 

• Возможность быстрой смены Executor’ов Airflow. 

• Разграничение прав и доступов пользователей.

• Вдобавок ко всему, нам необходимо было self-hosted решение. 

Сначала в качестве возможных решений мы думали в следующих направлениях.

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

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

Уход от Airflow в пользу чего-то модного и молодёжного. Будучи реалистами, мы понимали: велика вероятность того, что другое решение будет содержать свои подводные камни, о которых узнать мы сможем только во время переезда + потеряем все уже существующие наработки. А это большие потери по времени.

Когда эти варианты были отметены, стали смотреть, как другие компании реализуют Airflow с точки зрения инфраструктуры. Наиболее эффективными нам показались облачные решения — такие, как у Astronomer и Google Cloud Composer. SaaS-подход решал практически все проблемы и казался нам silver bullet в нашей ситуации, однако хотелось разворачивать его на своих мощностях, с возможностью докрутить недостающие фичи и полностью на нашей поддержке. «Ну и чем мы хуже?» — подумали мы, засучили рукава и стали продумывать архитектуру нашего нового проекта.

Архитектура

Требования к используемым решениям были следующие: 

• компоненты должны быть преимущественно open-source; 

• по возможности иметь нативную поддержку со стороны Airflow;

• быть простыми в обслуживании.

Инфраструктурным сердцем для SaaS-решения стал Kubernetes, на который, как нам казалось, будет просто переехать.

Для логов мы решили использовать Elasticsearch (позднее заменён на S3). Во-первых, потому что данное решение уже используется в компании; во-вторых, у Airflow есть готовый провайдер, который позволяет их оттуда читать. А после нашего Pull Request в проект — даже по порядку.

Сервисная БД — PostgreSQL. Для нас было непринципиально, где и как она будет существовать, так как ни пользователей, ни секреты хранить мы в ней не собирались. Поэтому пустая база разворачивается вместе с helm-поставкой, что достаточно удобно для нас.

В качестве хранилища DAGов и промежуточного хранилища для них мы используем механизм K8s Persistent Volume и данные volume’ы храним на Ceph.

Авторизация пользователей осуществляется через LDAP. Так как большинство сервисов в нашей компании используют Active Directory для авторизации, это было самым разумным решением.

В качестве мониторинга был выбран Prometheus, благо Airflow позволяет собирать огромное количество метрик. При помощи протокола StatsD мы посылаем их на развёрнутый у нас StatsD-экспортер, где преобразовываем в prometheus-like формат.

Секреты

Оставался вопрос, как мы будем хранить наши секреты. Для успешного решения проблем нам нужны:

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

2. Наследуемость. Никто не хотел пересобирать свой набор «ходок» и по тысяче раз выяснять пароль от того или иного ресурса. Очевидно, что у команды полно командных секретов, которые накапливались годами и менять которые «под себя» не требуется.

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

Идею с тем, чтобы забирать секреты в обход встроенных в Airflow методов, мы сразу отмели: это потребовало бы переработки наших DAGов. Да и к тому же хотелось чего-то поддерживаемого производителем и иногда даже обновляемого. И, к нашему счастью, подобное решение нашлось — Hashicorp Vault.

Разработку Secrets Backend мы начали ещё для версии 1.10, поэтому листинги кода провайдера могут несколько отличаться от того, что присутствует в актуальной версии. Но кардинально сути это не меняет.

Казалось, что решение подходит нам сразу out of the box. При вызове get_connection() или get_variable() по указанному в конфигурации пути с указанным там же токеном провайдер ходит в каталог connections или variables на vault и ищет секрет с нужным id. Остаётся реализовать наследование секретов.

Сперва мы начали со схемы, где у каждого проекта своё пространство секретов: над определённым проектом в gitlab работает определённый отдел разработчиков, и они имеют тот самый накопленный годами пул общих секретов. Такие пространства мы решили хранить в виде airflow/master/название_проекта/ — это путь каталога в vault, и его мы называем проектным пространством хранения секретов. Рядовые разработчики имеют только Read-права на данное пространство, что позволяет им легко посмотреть, куда ведёт та или иная ходка, — изменить её они не могут. Права на изменения выдаются Team Leader’ам, и такой момент устроил всех.

Чтобы пользователь стенда мог подставить свой секрет, мы выделим ему своё пространство по принципу airflow/имя_пользователя / название_проекта. Это пространство будет иметь приоритет над проектным, и если Airflow находит в пользовательском пространстве SecretA, то выбирается именно он, даже если в проектном пространстве также присутствует SecretA. Но, если в пользовательском пространстве данного секрета нет, он будет взят из проектного.

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

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

Также Vault очень сильно выручил нас с добавлением небольших секретных файлов, вроде ssh-ключей или keytab’ов, которые мы, по понятным причинам, не хотели хранить в виде configmap’ов или volume’ов в K8s, потому что это шло вразрез с принципами безопасного хранения и SaaS в целом.

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

Gitlab CI и поветочный деплой

Когда мы определились с большей частью компонентов нашего SaaS, оставалось придумать, как его доставлять до конечного пользователя. В первую очередь отталкивались от того, что разработчики привыкли сами раскатывать новые версии своих DAGов и images до статических стендов, и выбор пал на GitLab CI.

Ещё в самом начале команда решила, что гораздо удобнее делать стенды не под конкретного пользователя, а под ветку в гите, так как периодически возникают задачи, в рамках которых требуется минимум изменений, но проверка может занимать значительное время, и pull таких задач может уходить в одного разработчика/аналитика. Также есть задачи proof-of-concept, которые делаются и тестируются в фоновом режиме. 

Стенд представляет из себя неймспейс в K8s, в котором развёрнута официальная helm-поставка Airflow. Решение показалось нам достаточно простым и лаконичным, плюс оно содержало все необходимые шаблоны для разворачивания вариантов как с Kubernetes, так и с Celery Executor’ом. В тот момент, когда мы начинали разработку, чарт ещё не был оптимизирован для версий старше 1.10.12, но при помощи определённых доработок он вполне успешно и по сей день разворачивает нам новые релизы. Например, мы добавили параметр Vault-аннотаций для всех deployment’ов и statefulset’ов, чтобы образы Airflow изначально поднимались с нужными нам секретами из коробки, шаблонизировали template worker pod’а для K8s executor’а, добавили kinit для прокинутых внутрь keytab’ов при старте пода, чтобы это не приходилось делать через DAGи, и ещё несколько мелких и не очень изменений.

Процесс деплоя происходит следующим образом. При коммите собирается артефакт с DAGами, после чего пользователь в gitlab-ci pipeline имеет выбор из трёх кнопок: создать стенд с Celery Executor’ом, создать стенд с Kubernetes Executor’ом или же скопировать на имеющийся стенд свои DAGи.

Ранее мы собирали все наши yaml-конфигурации и DAG-генератор в один zip-архив, после чего передавали его на под с Airflow в папку с DAGами. Если внутри папки уже находился предыдущий архив, он перезаписывался. Это вызывало целый ряд логических проблем, поэтому мы ушли от хранения DAGов в архиве и перешли на вариант с симлинками в директорию с распакованными DAGами. 

Технически мы всё так же собираем zip-архив, копируем его на под (в нашем случае в /opt/airflow/dags/), однако сразу же распаковываем его в директорию /opt/airflow/dags/ с timestamp’ом релиза в названии. В директории находится симлинк current (на который и смотрит airflow scheduler), папка с прошлым релизом, на который он нацелен, и с позапрошлым релизом. Мы переключаем симлинк current с прошлого релиза на текущий и удаляем из папки всё содержимое, кроме непосредственно current, текущего и прошлого релизов. Этим решением убиваем двух зайцев: первый — это уверенность в том, что file_processor отработает по старому дескриптору на файле в папке с прошлым релизом, и никто ничего из-под него не выдёргивает; второй — получаем лёгкую возможность сделать rollback неудачного релиза, просто переключив симлинк.

Мониторинг и логи 

Логи на момент разработки собирались в Elasticsearch (сейчас в S3) при помощи fluentd, а после вычитывались Airflow при помощи Elasticsearch provider.

Для отправки и хранения метрик стендов мы воспользовались классической связкой: Airflow нативно отправляет метрики в формате StatsD на шлюз, в качестве которого выступает StatsD Exporter, на лету преобразовывающий их в формат Prometheus. Затем происходит scrape данных метрик и их отправка в хранилище.

И пожалуй, единственная проблема, которая у нас возникла при использовании данного решения, — это рандомные дырки в метриках по процессингу DAGов. Баг мы в результате нашли, и фикс законтрибьютили https://github.com/apache/airflow/issues/17513 

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

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

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

В качестве признака «протухания» мы выбрали метрику в виде времени последнего запуска DAG’a. Таким образом появилось первое правило: любой тестовый стенд живёт не более 25 часов после того, как на нём не осталось DAGов в статусе Running.

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

Так как Airflow является мультикомпонентным приложением и все компоненты хранятся в выделенном Namespace, мы пришли к выводу, что для освобождения ресурсов лучшим выходом будет удаление Namespace, в котором он существует.

Для этой задачи такие инструменты, как Liveness probe и readiness probe, не подходят. По этой причине мы используем Kubernetes CronJob, представляющий из себя небольшой контейнер, отправляющий каждые 5 минут запросы к Prometheus для анализа метрик жизненного цикла стенда. В случае, если выполняется одно из условий, указанных выше, то CronJob обращается к API K8s — и весь Namespace удаляется. Такой подход обеспечивает эффективное высвобождение ресурсов и не создаёт проблем разработчикам.

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

Сразу после запуска DAG’a, в признаках которого указан данный функционал, создаётся Persistance Volume, подключаемый к каждой таске dagrun’a. После успешного или безуспешного исполнения dagrun’а, Airflow посылает callback на API K8s — и Persistance Volume удаляется, освобождая ресурсы хранилища.

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

Подводные камни и проблемы

Нам потребовалось доработать штатный K8sPodOperator, заменив DockerOperator, а именно:

1. Реализовать механику передачи конфигов для спарк-приложений, которые запускаются из отдельного докер-контейнера;

2. Реализовать поддержку временных хранилищ при помощи PVC.

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

В данном примере как раз typesafe_config и будет являться тем дополнительным конфигом, и его в переменную окружения мы передаём в виде base64encoded-строки. Кодирование происходит в самом операторе, что позволяет в конфиге использовать макросы Airflow.

Вторая доработка — это добавление создания вольюмов. Если в описание DAGа добавлены параметры для создания pvc, то в этом случае при запуске кубер-оператора будет создаваться pv, который будет удаляться через коллбеки на DAGе on_success_callback и on_failure_callback.

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

Что происходило:

1. Процессы, обрабатывающие файлы и исполняющие коллбеки, помещаются в одну и ту же переменную _processors, которая имеет тип dict, где ключом является filepath файла с DAGом.

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

3. Вспоминаем, что у нас всё лежало в рамках одного zip-архива, и мы переопределяли fileloc, в котором хранится путь до файла с DAGом, на путь до yaml-файла, чтобы его можно было смотреть в UI.

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

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

Поэтому возникшие проблемы мы решили на уровне пайплайна сборки артефактов для деплоя, то есть для каждого yaml-конфига мы начали генерить py-файл с генератором. Так нам ничего не пришлось делать в рамках самого генератора — мы получили независимый парсинг всех DAGов. Это дало нам возможность параллельно парсить DAGи, и проблемы с одним DAGом не влияли на остальные. 

Ко всему прочему кардинально выросла отзывчивость интерфейса. Впоследствии мы нашли причину долгого процессинга DAGов и поправили её, ещё ускорив процессинг.

Демонстрация

Результаты проекта Airflow SaaS

Перечислим преимущества, которые мы получили в ходе реализации проекта:

• Централизованное хранилище логов.
  Все логи Airflow SaaS хранятся в S3, мы можем гибко настраивать глубину хранения и имеем единую PoV.

• Версионированность Connections и Variables.
  Видим, кто, когда и что поменял в тесте или проде, да ещё и безопасность на высоте!

• Пользователь сам выбирает версию Airflow и набор библиотек.
  Есть обязательный набор пакетов — остальное на выбор пользователя. Указал желаемое в CI — через пару минут готовый инстанс.

• K8s-executor сократил затраты ресурсов.
  Для работы не требуется Redis, Worker, Flower.

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

• Масштабируемость проекта ограничена лишь ресурсами.
  10 «продов» и 75 «тестов»? Не вопрос, только дайте RAM 🙂

• Ресурсы больше не простаивают.
  Если нет большой нагрузки или огромной кучи «теста», то ресурсы эффективно используются другими сервисами в рамках k8s.

• Администрирование.
  Благодаря автоматизации и подходу IaaC большинство «админских» задач решаются быстро и «по кнопке».

• Отказоустойчивость Production.
  Падение нескольких физических серверов k8s никак не сказывается на процессах.

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

• Мы стали экономить и переиспользовать ресурсы, которые ранее зачастую просто обогревали ДЦ. Общий пул зарезервированных ресурсов сократился в 3 раза по CPU и более чем в 5 раз по RAM.

• За счёт всех изменений TTM сократился более чем на час!

• Ранее процесс тестирования новых пакетов в составе Airflow или новых версий самого Airflow занимал недели, а иногда и месяцы. Теперь это занимает несколько дней.

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

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

P. S. Многое из того, что мы реализовали своими силами, было добавлено разработчиками в новые версии Airflow (хочется думать, что в том числе благодаря нашим контрибьютам), так почему же нам просто не обновиться? Ответ простой: получившаяся конфигурация долгое время удовлетворяла запросы заинтересованных команд, а переезд на новую версию потребовал бы дополнительных ресурсов для отладки логики и багов, поэтому не представляется целесообразным. Но ничто не стоит на месте, и в планах у нас переезд на Airflow 2.6, так что скоро сможем рассказать и про него, а заодно про дагогенератор, переход на S3 и обновления в мониторинге.

Перевод данной статьи был выполнен с оригинального источника, автор — Tanveer Singh.

Управление состоянием является одной из самых больших проблем при использовании фреймворка React. Это касается не только пользователей. Разработчикам нужен простой и масштабируемый процесс управления состоянием для проектирования эффективных и сложных пользовательских интерфейсов.

Обычно используют хуки React для доступа и обмена состояниями между разными компонентами. Но при работе с их значительным количеством сложность становится слишком большой для хуков. В таких случаях необходимо использовать библиотеки управления состоянием.

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

Что такое управление состоянием в React?

Состояние представляет собой часть компонента, которая изменяется в зависимости от действий пользователя. Это объект JavaScript, который служит памятью компонента и хранит многие его свойства. Таким образом, управление состоянием в React — это процесс обмена данными между различными компонентами.

Когда пользователь взаимодействует с вашим React приложением, в состоянии одного или нескольких компонентов могут происходить изменения. Эти изменения могут повлиять на интерфейс (UI), представленный пользователю, поэтому вам необходимо управлять ими.

Почему управление состоянием важно в React?

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

Когда пользователи взаимодействуют с вашим React приложением, каждое их действие может изменить состояние нескольких компонентов. Возьмем, к примеру, приложение интернет-магазина, в котором покупка товара может повлиять на несколько компонентов посредством следующих действий:

• Добавление товаров в корзину

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

• Изменение количества купленных товаров

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

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

Что из себя представляют библиотеки управления состоянием в React?

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

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

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

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

Топ 7 библиотек для управления состоянием в React

На GitHub есть более 90 библиотек управления состоянием для React. Но по ряду ключевых характеристик некоторые из них выделяются среди остальных.

При выборе правильной библиотеки для вашего приложения на React вы должны учитывать следующие факторы:

• Удобство использования

• Производительность

• Масштабируемость

• Модифицируемость

• Сложность поддержки

• Возможность переиспользования

• Тестируемость

• Экосистема

• Сообщество

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

1. Redux

Redux существует с 2015 года и является первой библиотекой управления состоянием в React, созданной для упрощения этого процесса путем централизации хранилища состояний, которая достигается с помощью использования «Store», содержащего все состояния вашего приложения.

По результатам npmtrends на январь 2022 года, Redux по-прежнему занимает лидирующую позицию среди остальных подобных библиотек. В Redux используются экшены (actions) и редьюсеры (reducers). Экшены — это объекты, сообщающие хранилищу (store) о том, какие события должны произойти. Редьюсеры — функции, которые выполняются на основе входных данных экшена и начального состояния (initial state).

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

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

Благодаря тому, что Redux Toolkit заботится об удобстве использования Redux, простая логика и чистые функции делают его довольно удобным в сопровождении, производительным и тестируемым. Вы можете изменять и повторно использовать код Redux, так как он не зависит от фреймворка и поддерживает промежуточный слой (middleware).

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

2. Hookstate

Hookstate — это современная альтернатива хукам React и таким библиотекам, как Redux. Эта библиотека быстро завоевала репутацию за её минималистичность, производительность и масштабируемость.

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

Hookstate уникальна тем, что отслеживает отрисованные и обновлённые состояния. Использует такие понятия, как локальное и глобальное состояние, которые очень похожи на собственное управление состоянием в React. Но также представляет другие концепции, такие как вложенное состояние, состояние области видимости и асинхронное состояние. Эти возможности позволяют разработчикам получить доступ к сложным состояниям, отрисовывать большие состояния и использовать «обещания» (promises), чтобы задержать некоторые действия.

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

3. Recoil

Еще один новый участник сцены — Recoil, выпущенный в начале 2020 года. Известен тем, что был разработан Facebook и использует подход управления состоянием похожий на React. 

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

Основными концепциями, используемыми в Recoil, являются атомы (atoms) и селекторы (selectors). Атом — это единица с общим состоянием, которая представляет собой свойство единого состояния. Компонент может подписаться на атом, чтобы получить его значение. Атомы аналогичны локальному состоянию React, но с дополнительным преимуществом — они доступны между различными компонентами. 

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

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

4. Jotai

Jotai был анонсирован в 2021 году и реализует атомарное управление состоянием. Он обладает многими преимуществами подобных библиотек, такими как производительность, простота, а также интеграция с React Suspense и другими библиотеками из этого списка.

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

Благодаря своей утилизации памяти Jotai чрезвычайно производителен, не требует ключей и зависит от JavaScript для отслеживания своих атомов. Это приводит к автоматической утилизации памяти и оптимизированному её использованию.

Jotai делает ещё один шаг вперед в управлении атомарным состоянием, обрабатывая практически всё как атом.

5. Rematch

Если вам чем-то не подошли ранее описанные библиотеки, то Rematch может убедить вас своим лёгким, быстрым и простым в использовании функционалом. Он упрощает настройку, уменьшает количество шаблонного кода и лучше обрабатывает побочные эффекты.

Ему удаётся вместить всё это в пакет размером 1,7 КБ. Rematch, по своей сути, работает с моделями. Модели объединяют состояние, редьюсеры и эффекты в единое целое, используя лучшие практики Redux и упрощая управление состоянием.

И это ещё не всё. Rematch написан на TypeScript, поддерживает широкий набор плагинов и не зависит от фреймворка. Вы можете использовать его в работе с Vue, Angular и другими. Все эти возможности делают Rematch очень удобным, производительным и масштабируемым.

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

6. Zustand

Написанная людьми из Jotai и весом менее 1 КБ, Zustand может быть самой маленькой библиотекой в этом списке. Но придраться точно не к чему. Zustand предлагает простой и минималистический API, который делает его быстрым и масштабируемым.

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

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

Zustand также может управлять обновлениями временного состояния без повторного рендеринга компонентов. Этой библиотеке удалось получить более 23k звёзд на Github, что больше, чем у Rematch, Jotai и MobX.

7. MobX

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

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

Еще одной особенностью MobX является иммутабельность (неизменяемость). Это позволяет вам автоматически обновлять состояние, избегая побочных эффектов.

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

Удобство использования, производительность и масштабируемость не вызывают проблем для MobX. Он также отличается модифицируемостью и возможностью переиспользования. И как зрелая библиотека (почти 26к звезд на GitHub), MobX не имеет недостатков в сообществе поддержки или развивающейся экосистеме.

Как выбрать правильный инструмент для управления состоянием в React

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

Redux и MobX — это старые любимцы в сообществе и естественный выбор для большинства проектов. Знание Redux, в общем, даёт вам дополнительные преимущества при управлении состоянием в ваших проектах. 

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

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

Вывод

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

ALD Pro — софтверный продукт компании РусБИТех-Астра («Научно-производственное объединение Русские базовые информационные технологии»), которая разрабатывает и продвигает операционную систему Astra Linux. Это служба каталогов с групповыми политиками для управления и администрирования всеми устройствами и пользователями в компьютерной сети.

Система предполагает импортозамещение аналогичных зарубежных продуктов типа Microsoft Active Directory и Red Hat Directory Server (RHDS).

Функциональность крайних версий:

• Управление иерархией организационной структуры
• Управление объектами домена: компьютерами, пользователям и группами
• Создание и назначение групповых политик на компьютеры и пользователей
• Настройка параметров домена и репликации
• Настройка доверительных отношений с доменом MS Active Directory
• Автоматизированная установка ОС и ПО по сети на компьютеры в домене
• Управление и настройка системных сервисов и служб
• Журналирование событий и просмотр системных логов
• Миграция данных из домена MS Active Directory
• Удаленный доступ к рабочим столам пользователей домена
• Мониторинг состояния домена и серверов

Но сначала стоит сказать пару слов о системе, на базе которой работает ALD Pro. Это Astra Linux, один из лучших отечественных Linux-дистрибутивов по результатам голосования пользователей Хабра.

Astra Linux

Сегодня ОС Astra Linux получила уже довольно широкое распространение. Она сертифицирована для использования в госучреждениях и признана пригодной для обработки и защиты информации, связанной с гостайной, в том числе особой важности. Astra Linux используется в министерстве обороны РФ, ФСБ, в Росатоме, Газпроме, РЖД и включена в единый реестр программ Минкомсвязи.

Astra Linux представляет собой основательно доработанную и модифицированную сборку Debian. Стандартный пакетный менеджер системы, Advanced packaging tool (используется в операционных системах Debian и основанных на них Ubuntu, Linux Mint и других) автоматически устанавливает и настраивает программы из предварительно собранных пакетов или из исходных кодов.

Помимо специализированных программ, репозиторий Astra Linux включает графический менеджер Fly, LibreOffice, браузер Firefox, почтовый клиент Thunderbird, графический редактор GIMP.

Fly — тоже разработка ООО «РусБИТех-Астра», которая позволяет использовать Astra Linux в похожем на Windows интерфейсе, к которому привыкли многие обычные пользователи, и поддерживает функции системы по мандатному контролю. Fly создан на основе графического сервера Xorg и утилит, написанных с помощью кроссплатформенного фреймворка QT 5, а также KF5 Framework (библиотеки оболочки рабочего стола KDE5).

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

Astra Linuх, без проблем устанавливается на компьютер через VirtualBox, при инсталляции подключается графический менеджер, благодаря чему установить ОС на свой компьютер может любой, мало-мальски грамотный пользователь. Это большой плюс системы. Дальнейшая работа в ОС также не представляет каких-либо трудностей — выбор программ, папок, копирование, drag-n-drop, всё функционирует примерно как в Windows.

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

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

Стоит добавить, что конечному пользователю (если речь идет о сети), скорее всего, и не придется ничего настраивать: за него все сделает администратор ALD Pro.

Система защиты информации ОС основана на механизмах мандатного контроля целостности (аналогичные механизмы Windows — Mandatory Integrity Control и User Account Control), замкнутой программной среды (запуск исполняемых файлов в которой возможен, только если они подписаны ЭЦП) и мандатного контроля доступа (пользователь root в нем не имеет таких прав, как в традиционной системе, так как в Astra Linuх используется дополнительный механизм распределения прав по уровням целостности). Эти инструменты входят в подсистему безопасности PARSEC, разработанную на основе формальной модели безопасности управления доступом и информационными потоками.

В ОС Astra Linux разработаны и применяются три режима защиты информации — Базовый («Орел»), Усиленный («Воронеж») и Максимальный («Смоленск»).

Пересесть на Astra Linux и использовать ее в качестве домашней или рабочей системы можно, хотя это и не покажется слишком удобным для обычного пользователя Windows. Но тут уж надо выбирать: либо ехать, либо шашечки. То есть или внедрение отечественных разработок и импортозамещение, или привычная Windows с реально замаячившей возможностью в перспективе перспективой в час Ч получить вместо кареты тыкву с невозможностью поддержки и обновлений.

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

ALD Pro

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

В основе ALD Pro лежит хорошо известное, надежное и эффективное open-source решение FreeIPA (Free Identity, Policy and Audit, система управления учетными записями и аутентификацией).

FreeIPA — инструмент для Linux/UNIX (аналогичный по функционалу MS Active Directory), который обеспечивает централизованное управление учетными записями и централизованную аутентификацию с помощью веб-интерфейса и командной строки. FreeIPA объединяет сразу несколько компонентов с открытым исходным кодом. Это 389 Directory Server (служба каталогов LDAP, предназначенная для централизованного управления доступом к ресурсам на множестве сетевых серверов), MIT Kerberos (служба сетевой аутентификации по протоколу Kerberos V5), Chrony (отказоустойчивый, масштабируемый сервис синхронизации времени по протоколу NTP), Bind9 (DNS), Dogtag (систему сертификатов).

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

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

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

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

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

В ALD Pro встроен мощный механизм настройки и управления групповыми политиками. Он достаточно гибок, удобен и легко настраивается при помощи визуального интерфейса. «Под капотом» — система управления конфигурациями SaltStack, одно из самых быстрых и эффективных решений для подобных задач. В ALD Pro система SaltStack используется для реализации групповых политик и заданий автоматизации.

Хотя в интерфейсе ALD Pro есть все необходимые инструменты для администрирования каталога, можно получить и прямой доступ к каталогу, создавать, изменять и удалять любые объекты, будь то пользователи, компьютеры или группы. Для этого можно воспользоваться такими утилитами как ldapsearch, ldapadd, ldapmodify, ldapdelete и др. Доступ из графического интерфейса можно получить с помощью приложения Apache Directory Studio. Для его работы потребуется Java.

Apache Directory Studio

Важный функционал, которым обладает ALD Pro — возможность настройки двусторонних доверительных отношений с AD DS (Active Directory Domain Services). Он позволяет обеспечить прозрачную аутентификацию при обращении к любым ресурсам с помощью протокола Kerberos.

Возможна в ALD Pro и миграция объектов домена из MS AD (Microsoft Active Directory). Для ее обеспечения используется свой модуль миграции и синхронизации данных. Он позволяет проводить миграцию с учетом всех необходимых требований и автоматически синхронизировать Microsoft Active Directory и ALD Pro.

Справочный центр ALD Pro

Кроме того, в ALD Pro имеется возможность настроить дополнительные службы для домена: Zabbix — (система мониторинга сетевых сервисов, серверов и сетевого оборудования), Graphana (инструмент визуализации данных), Fluentd (система централизованного сбора и анализа журналов), ISC DHCP (динамической настройки сети узла), подсистема репозиториев ПО (Reprepo), автоматической установки ОС (TFTP + PXE), печати (CUPS), файловый сервер (Samba).

ALD Pro: перспективы

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

Ясно одно: чем больше будет появляться основанных на ALD Pro проектов, тем быстрее и эффективнее будет развиваться это интересное решение.

Привет, Habr! На связи Алексей Пешков, старший менеджер по развитию направления в GlowByte. Не так давно я рассказал о ZenTao – новом интересном решении для команд разработки, которое может успешно заменить Jira. Сегодня хочу поделиться кейсом внедрения этого ПО в известной обувной компании Skechers China. Из этой статьи вы узнаете о том, как ZenTao повысил операционную эффективность ИТ-отдела Skechers и открыл новые возможности для роста прибыли компании.

Поставщик программного решения для управления проектами и автоматизации ITSM  процессов ZenTao Software сотрудничает с компанией Skechers China, чтобы помочь ей стать самым популярным в мире брендом обуви. В настоящее время Skechers является 2-м по величине обувным брендом на рынке США после Nike.

Быстрый рост бизнеса привел к расширению продуктовых линеек компании: на данный момент в Skechers China работает более 1 000 человек, из которых более 200 – работники IT-отдела. В связи со стремительным ростом количества сотрудников и развитием производства для управления проектами компания Skechers выбрала ZenTao в качестве рабочей ИТ-платформы компании. Благодаря новым методам совместной работы в продуктовом, R&D, операционном и других отделах у ZenTao получилось значительно повысить эффективность процесса разработки, сократив количество итераций в спринтах разработки на 67%. 

«До того как мы начали использовать ZenTao, нам было очень трудно угнаться за темпами роста из-за быстро растущей команды. Программное обеспечение для управления проектами ZenTao полностью объединило фронтенд и бэкенд и помогло разработать интегрированный процесс, учитывающий все аспекты работы: от требований пользователей до управления R&D. Метод Agile позволил десяткам направлений бизнеса и тысячам сотрудников эффективно работать вместе. В итоге результат превзошел все наши ожидания: процессы в командах ускорились, а бизнес стал расти быстрее и стабильнее».

Процесс разработки ИТ-отдела Skechers выглядит следующим образом: Бизнес-отдел → ITBP (IT Business Partner) → требования к ИТ от R&D → обзор → итеративная разработка.

Бизнес-группа представляет пользовательскую часть продуктовой команды, в ее обязанности входит передача требований пользователей ИТ бизнес-партнеру (ITBP). 

В обязанности бизнес-группы входит анализ осуществимости проекта, оценка рисков, планирование проекта, инвестиций в проект и доходы от него (ROI), управление данными, сбор обратной связи для повышения удовлетворенности клиентов и т. д. Цель этих действий – наладить тесное сотрудничество внутри компании и добиться бесперебойной работы всех отделов. 

ИТ бизнес-партнер отвечает за преобразование пользовательских историй в ИТ-требования и своевременную передачу их в ИТ-отдел. После окончательной проверки сотрудниками отдела R&D ИТ-требования преобразуются в документы по разработке продукта.

Ранее ИТ-команда Skechers использовала решение Teambition для управления процессами исследования и разработки. Однако, поскольку Teambition мог поддерживать разработку только небольших команд, когда количество пользователей превысило 100 человек, неэффективность традиционной «водопадной» (Waterfall) модели разработки стала более очевидной. Чтобы обеспечить организованное выполнение большего объема работы и постоянно стимулировать творческий потенциал команды, Skechers решили усовершенствовать процесс управления командными проектами, реструктурировать команду и провести Agile-трансформацию. После нескольких контактов с командой ZenTao они решили использовать ZenTao Max для управления проектами и всем процессом развития продукта.

Кристин Мо: «Использование профессиональных инструментов управления R&D, таких как ZenTao, не только позволяет лучше внедрить методологию Agile, но и построить эффективную команду, которая всегда быстро реагирует на запросы пользователей и поддерживает развитие компании. После общения с командой ZenTao и изучения Scrum-фреймворка мы попытались реорганизовать и скорректировать процесс. Теперь это отлично работает, каждая Scrum-команда стала более динамичной и ответственной, а эффективность всего центра разработки программного обеспечения естественным образом повысилась«.

Полный цикл ИТ-решений

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

Бизнес-отделы компании Skechers по своей сути являются “официальными представителями” пользователей продукта. Пользователи зачастую не понимают деталей процесса разработки продукта, поэтому при передаче их требований разработчикам часто возникают недопонимания. Таким образом, ZenTao помог оптимизировать рабочий процесс, добавив роль ITBP, чтобы помочь бизнес-группе на понятном разработчикам языке сформулировать потребности клиентов. Преимущество этой оптимизации заключается в том, что время обратной связи между бизнес-реализацией и технической реализацией значительно сокращается, что способствует увеличению эффективности работы как команды разработки, так и бизнес-команды. 

Кроме того, ранее отдел R&D Skechers использовал различные инструменты в процессах исследований и разработок, но данные в этих процессах не были связаны. Различные стороны процесса работали отдельно, поэтому управлять ими приходилось вручную, что снижало эффективность работы. ZenTao позволяет интегрировать цепочку инструментов R&D таким образом, что все звенья разработки продукта (проектирование, разработка, тестирование, запуск и валидация) происходят на одной платформе, создавая решение полного жизненного цикла для команды Skechers.

Плавный и прозрачный рабочий процесс с эффективным сотрудничеством между отделами

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

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

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

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

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

Анализ нагрузки на членов команды и своевременные коррективы

В R&D-команде из 200+ сотрудников важно четко понимать, кто и за что отвечает. Открыв функцию «Статистика» в проекте, владелец проекта может просмотреть общее количество задач по данному продукту, завершенные и отложенные задачи, а также статистику по завершенным задачам для каждого участника проекта. 

В «Управлении отчетами» можно удобно отфильтровать данные для построения отчетов. 

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

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

Заключение

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

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

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

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

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

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

1. Они рассчитаны на масштабность (то есть большое количество пользователей).
2. Большая часть бизнеса у них сосредоточена на таргетировании потребителей.
3. Они предоставляют свои услуги за низкую плату (или бесплатно).
4. Они занимают нишу на крупных рынках.
5. У них много свободных денег.

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

1. Не связывайтесь с крупномасштабным бизнесом

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

Я вынес этот урок из тяжелого опыта одной из первых своих попыток создать стартап. Идея была такая: свадебный каталог, который я позиционировал как «TripAdvisor для свадеб» (TripAdvisor тогда был в зените славы). Этот был двусторонний маркетплейс, таргетировавший весь британский свадебный рынок целиком. Оказалось, что я замахнулся на слишком крупный рынок. Чтобы бизнес сложился, требовались сетевые эффекты в больших масштабах, а с нулевым бюджетом привлечь нужное количество обрученных пар и поставщиков услуг для свадеб не представлялось возможным. В итоге, мне приходилось раз за разом менять фокус своей деятельности и втискиваться во всё более узкие ниши в попытках ужать размеры рынка, чтобы могли подключиться сетевые эффекты. В конце концов, я потерпел неудачу: мне не удавалось достаточно быстро запустить эти эффекты на таком изменчивом рынке как свадебная индустрия. Я закрыл проект. Из идеи ничего не вышло. Создавать сетевые эффекты крайне сложно, когда работаешь над этим в одиночку – не хватает ни денег, ни времени, чтобы довести дело до ума.

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

2. Не берите с пользователей слишком мало

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

Часто приходится видеть, как люди создают бизнес с услугами по подписке и устанавливают плату «в стиле Netflix», что-то типа 10 $ в месяц. Мы настолько приучены к подобным расценкам, что естественным образом стремимся воспроизводить эту модель. Но конвертация потребителей для десятидолларовой подписки – задача куда более сложная, чем может показаться. Если даже очень постараться и набрать сотню пользователей, всё равно в месяц у вас выйдет около тысячи долларов, и это без вычета затрат на поддержание деятельности и убытка от тех, кто отменит подписку. Взамен выбывших придется постоянно нагонять новых.

С другой стороны, вы могли бы найти одного B2B-клиента, который платил бы за услуги 10 000 $ в месяц и заработали бы на нем в десять раз больше, с меньшими затратами на поддержание и без текучки. Одна продажа против ста. Десятикратная прибыль против однократной.

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

3. Таргетируйте компании, а не отдельных потребителей

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

1. Компании охотно тратят деньги на услуги, которые способствуют их развитию. Такие вложения приносят прибыль.
2. Затраты на ведение бизнеса снижают прибыль и, соответственно, налоги на эту прибыль. Расходы компенсируются за счет будущих налоговых выплат.
3. Компании специально выделяют средства на обучение, продвижение и т.д. То есть они буквально ищут, на чтобы потратить деньги.
4. Зачастую есть особый сотрудник, в обязанности которого входит распорядиться этими деньгами. Вы можете выяснить, кто в той или иной компании отвечает за расходы такого рода, и продавать свои услуги прицельно этому человеку.

В мире потребителей всё устроено не так. Люди с большой осторожностью выкладывают свои деньги. 49 $ за подписку – для потребителя это большая сумма, в то время как компания и глазом не моргнет.

Вот пара примеров, которые показывают разницу в подходе к тратам между человеком и компанией:

• Голубые метки на Twitter вызвали скандал в сообществе, когда за них стали просить 6 £ в месяц. С организаций за те же галочки, только другого цвета берут 1140 £ в месяц — все платят, все довольны.
• Gmail – один из самых популярных почтовых сервисов, которые когда-либо существовали. Если бы владельцы установили ежемесячную плату за обслуживание хоть в один доллар, то потеряли бы около 90% своей аудитории – люди перешли бы на бесплатные альтернативы. Тем временем, пару лет назад был запущен потовый сервис Superhuman, который таргетировал строго корпоративных клиентов. Они здорово встряхнули рынок тем, что установили цену в 30 $ за право пользоваться почтой. Все мы приучены к тому, что электронная почта бесплатна, и другого не ждем. Но продукт был превосходный, он позволял корпоративным пользователям экономить время на переписке, а значит, тратить его на что-то еще и приносить больше денег. Бизнес стал расти как на дрожжах.

Основателям-одиночкам нужно свести к минимуму временные затраты на привлечение пользователей (потому что разорваться вы не сможете) и установить как можно более высокую цену. Продажи B2B решают обе эти проблемы.

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

4. Не замахивайтесь на крупные рынки

Чем больше рынок, тем многочисленнее конкуренты. Где, по-вашему, золотой рыбке будет житься лучше – в океане или в садовом прудике? Вероятно, в прудике. В океане придется бороться с миллионами других рыб, большинство из которых крупнее вас, и в конце концов вас съедят. В прудике у вас есть шансы оказаться самой крупной рыбой. Именно в таком русле и следует размышлять о своем бизнесе. Выберите рынок, где можно стать самой крупной рыбой. Если вы решите создать собственный бренд спортивной обуви, вам придется конкурировать с Nike, Adidas и бесчисленными другими компаниями. Сузьте нишу до бренда обуви для пикбола, и вы внезапно окажетесь единственным игроком на рынке, самой крупной рыбой. Тогда вы сможете подстроиться под потребности конкретного типа потребителя и захватить весь рынок обуви для пикбола.

Обобщая сказанное

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

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

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