Осторожно: под катом чрезвычайно много изображений.

Что такое Mission Control

Как заявляет в своем блоге сама компания, основная задача VMware Tanzu Mission Control — «привнести порядок в кластерный хаос». Mission Control представляет из себя управляемую через API платформу, которая позволит администраторам применять политики к кластерам или группам кластеров и устанавливать правила безопасности. Основанные на модели SaaS инструменты безопасно интегрируются в кластеры Kubernetes через агента и поддерживают массу стандартных операций с кластером, включая операции управления жизненным циклом (развертывание, масштабирование, удаление и пр.).

В основе идеологии линейки Tanzu лежит максимальное использование open-source технологий. Для управления жизненным циклом кластеров Tanzu Kubernetes Grid используется Cluster API, Velero — для бэкапов и восстановления, Sonobuoy — для контроля соответствия конфигурации кластеров Kubernetes и Contour в качестве ингресс-контроллера.

Общий список функций Tanzu Mission Control выглядит так:

• централизованное управление всеми вашими кластерами Kubernetes;
• управление идентификацией и доступом (IAM);
• диагностика и мониторинг состояния кластеров;
• управление конфигурацией и настройками безопасности;
• планирование регулярных проверок состояния кластера;
• создание резервных копий и восстановление;
• управление квотами;
• визуализированное представление утилизации ресурсов.

Почему это важно

Tanzu Mission Control поможет бизнесу решить задачу управления большим парком кластеров Kubernetes, расположенных локально, в облаке и у нескольких сторонних провайдеров. Рано или поздно любая компания, чья деятельность завязана на IT, оказывается вынуждена поддерживать множество разнородных кластеров, расположенных у разных провайдеров. Каждый кластер превращается в снежный ком, которому нужна грамотная организация, соответствующая инфраструктура, политики, защита, системы мониторинга и многое другое.

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

Архитектура решения

Tanzu Mission Control — это мультитенантная платформа, предоставляющая пользователям доступ к набору гибко настраиваемых политик, которые можно применять к кластерам и группам кластеров Kubernetes. Каждый пользователь привязан к Организации, именно она является «корнем» ресурсов — групп кластеров и рабочих пространств (Workspaces).

Что умеет Tanzu Mission Control

Выше мы уже кратко перечислили список функций решения. Давайте посмотрим, как это реализовано в интерфейсе.

Единое представление всех кластеров Kubernetes предприятия:

Создание нового кластера:

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

Подключение кластера:

Уже существующие кластеры можно просто подключить с помощью специального агента.

Группировка кластеров:

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

Workspaces:

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

Рассмотрим подробнее принципы работы Tanzu Mission Control в лабораторных работах.

Лабораторная работа #1

Разумеется, детально представить себе работу Mission Control и новых решений Tanzu без практики достаточно сложно. Для того, чтобы вы могли изучить основные возможности линейки, VMware предоставляют доступ к нескольким лабораторным стендам. На этих стендах можно выполнить лабораторные работы, используя пошаговые инструкции. Помимо собственно Tanzu Mission Control для тестирования и изучения доступны и другие решения. С полным списком лабораторных работ можно ознакомиться на этой странице.

Для практического ознакомления с различными решениями (включая небольшую «игру» по vSAN) отводится разное время. Не волнуйтесь, это весьма условные цифры. Например, лабу по Tanzu Mission Control при прохождении из дома можно «решать» до 9 с половиной часов. Кроме того, даже если таймер выйдет, можно будет вернуться и пройти всё заново.

Лабораторная работа #2

Здесь мы уже имеем дело с кое-чем посерьезнее. Эта лабораторная работа не настолько привязана к «рельсам», как предыдущая и требует более внимательного изучения. Приводить её здесь целиком мы не станем: ради экономии вашего времени разберем только второй модуль, первый посвящен теоретическому аспекту работы Tanzu Mission Control. При желании вы можете пройти ее самостоятельно полностью. Этот модуль предлагает нам окунуться в управление жизненным циклом кластеров через Tanzu Mission Control.

Примечание: лабораторные работы Tanzu Mission Control регулярно актуализируются и уточняются. Если при прохождении вами лабораторной работы какие-то экраны или шаги будут отличаться от приведенных ниже, следуйте указаниям в правой части экрана. Мы же пройдемся по актуальной на момент написания статьи версии ЛР и рассмотрим ее ключевые элементы.

Мнения и выводы

Безусловно, говорить о практических вопросах работы с Tanzu пока рановато. Материалов для самостоятельного изучения не так уж и много, а развернуть тестовый стенд, чтобы «потыкать» новый продукт со всех сторон на сегодняшний день не представляется возможным. Тем не менее, даже по имеющимся данным можно сделать определенные выводы.

Польза Tanzu Mission Control

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

• Можно создавать кластеры через веб-панель и через консоль, что очень понравится разработчикам.
• Управление RBAC через воркспейсы реализовано в интерфейсе пользователя. В лабе пока не работает, но в теории — отличная вещь.
• Централизованное управление привилегиями на основе шаблонов
• Полный доступ к namespace’ам.
• Редактор YAML.
• Создание сетевых политик.
• Мониторинг здоровья кластера.
• Возможность делать резервное копирование и восстановление через консоль.
• Управление квотами и ресурсами с визуализацией фактической утилизации.
• Автоматический запуск инспекции кластеров.

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

Приведем несколько «высокоуровневых» примеров.

В чужой кластер со своим уставом

Допустим, у вас есть команда разработчиков, в которой четко распределены роли и обязанности. Каждый занят своим делом и не должен даже случайно помешать работе коллег. Или же в команде есть один или несколько менее опытных специалистов, которым вы не хотите давать лишние права и свободы. Предположим также, что у вас есть Kubernetes сразу от трех провайдеров. Соответственно, чтобы ограничить права и привести их к общему знаменателю, придется поочередно заходить в каждую панель управления и все прописывать вручную. Согласитесь, не самое продуктивное времяпрепровождение. И чем больше у вас ресурсов, тем муторнее процесс. Tanzu Mission Control позволит руководить разграничением ролей из «одного окна». На наш взгляд, очень удобная функция: никто ничего не сломает, если вы случайно забудете где-то указать нужные права.

Кстати, наши коллеги из МТС в своем блоге сравнивали Kubernetes от вендора и open source. Если вы давно хотели узнать, в чем отличия и на что смотреть при выборе — welcome.

Компактная работа с логами

Еще один пример из реальной жизни — работа с логами. Предположим, в команде также имеется тестировщик. В один прекрасный день он приходит к разработчикам и возвещает: «в приложении обнаружен баг, срочно фиксим». Закономерно, что первое, с чем захочет ознакомиться разработчик — это логи. Посылать их файлами через электронную почту или Telegram — моветон и прошлый век. Mission Control предлагает альтернативу: можно задать разработчику специальные права, чтобы они могли читать логи только в конкретном пространстве имен. В таком случае тестировщику достаточно сказать: «в таком-то приложении, в таком-то поле, в таком-то namespace есть баги», и разработчик без труда откроет логи и сможет локализовать проблему. А за счет ограниченных прав не полезет сразу её чинить, если компетенция не позволяет.

В здоровом кластере здоровое приложение

Еще одна отличная возможность Tanzu MC — отслеживание здоровья кластера. Судя по предварительным материалам, система позволяет просматривать некоторую статистику. На текущий момент сложно сказать, насколько именно детализированной будет эта информация: пока что все выглядит достаточно скромно и просто. Есть мониторинг загруженности CPU и RAM, показаны статусы всех компонентов. Но даже в таком спартанском виде это очень полезная и эффективная деталь.

Итоги

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

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

Остается только опробовать Tanzu на тестовом стенде, чтобы реально понять все его плюсы, минусы и нововведения. Как только такая возможность нам представится, мы поделимся с читателями Хабра подробным отчетом о работе с продуктом.

Атака на десктопное приложение, использующее фреймворк Electron, проводится в два этапа: исследователь сначала нашел способ задействовать два HTML-тега — area и map, а потом с их помощью загрузил скрипт, выполняющий произвольный код на машине жертвы. Сценарий выглядит просто: злоумышленник делится файлом, по клику на него выполняется вредоносный код. Альтернативный вариант — кража сессии пользователя с понятными последствиями: полный доступ к данным корпоративного чата. Информацию о баге передали разработчикам через платформу HackerOne в январе. В марте самую серьезную часть проблемы — запуск кода — устранили, но вендор еще полгода тянул время, не разрешая публикацию данных об уязвимости без особой на то причины.

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

В общем, все закончилось хорошо. Однако примечательна сумма вознаграждения: 1750 долларов за серьезную прореху в безопасности. Мало того, легко эксплуатируемую — достаточно иметь доступ к атакуемому чату. Так как исследователь не стал публиковать статью самостоятельно, а попросил сделать публичным тикет в HackerOne, можно посмотреть на полную переписку независимого специалиста с вендором. Претензия к столь низкой сумме вознаграждения поступила не от самого исследователя, а от возмущенной общественности. Да, действительно, продать такую прореху легитимному брокеру уязвимостей можно было бы дороже. На черном рынке — еще выгоднее. С другой стороны, Slack, в отличие от более крупных компаний, много денег и не обещает: у них прямо на странице bug bounty указан потолок в 1500 долларов. Так что дело не только в деньгах: даже теперь, когда у большинства вендоров работают программы вознаграждения за поиск багов, выбор «на чьей стороне быть» все равно остается.

Что еще произошло

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

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

Уязвимость в браузере Safari позволяет красть файлы пользователя. В этом случае тоже есть спорный момент в программе bug bounty: специалисты Apple признали наличие бага, но пообещали закрыть его весной 2021-го, почти через год после уведомления. Другую критическую уязвимость закрыли уже в браузере Chrome.

Компания Facebook предупреждает рекламных партнеров о том, что нововведения в iOS 14 серьезно затруднят профилирование пользователей для показа релевантной рекламы. Речь идет о запрете использования единого рекламного идентификатора устройства, если того пожелает владелец устройства.

Сижу я вчера спокойно, как водится никого особо не трогаю. Тут с двух разных контактов, почти одновременно присылают ссылку на небезызвестный твит про JSON из SQL. Одно из сообщений выглядело так:

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

В то благословенное время все грезили криптой, занимались ICO и ваяли криптобиржи. Это было действительно что-то новое. У меня был опыт создания систем для классического управления активами (акции, облигации и т.п.). Проблема была в том, что он был сформирован вокруг учетных систем. Мне хотелось реализоваться в создании биржи. Не удивительно, что я с удовольствием нырнул в этот кипящий котел.

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

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

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

В нашем случае разговор шел о сотнях сделок в сутки.

Матчер у нас был на Java от стороннего вендора. Эта штука регулярно валилась, требовала ресурсов, и стоила денег по подписке. Плюс имела свою экосистему, которую без разрешения вендора развивать было нельзя. Отсюда мы попросту не могли предоставить те самые “уникальные” инструменты трейдеру. Именно это стало причиной писать свой матчер.

В своей практике я всегда стараюсь придерживаться пути селекции решений. Под селекцией я понимаю выбор перспективных решений, затем их сравнение, прототипирование и возможное “скрещивание” для получения лучших результатов. В этот раз все пошло по той же схеме. В результате появился прототип матчера на С, который был способен выдавать около 270К сделок в секунду на моем компе. Принимал заявки и отдавал сделки он в RabbitMQ. Но….

Но матчер требовал доработок. Пока это был прототип. Оценка была около 2х месяцев. И, к сожалению, допилить мог его только я. Конечно, если бы он взлетел, то речь бы шла о включении С в стек и наем персонала.

Состоялся разговор с фаундером. Он скептически отнесся к идее. Т.е. да, это здорово… но требует времени, людей и т.п. И это не весело. Честно сказать я расстроился и брякнул что-то типа:

Для наших объемов матчер можно и в мускуле наваять! (с)

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

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

Фишка в том, что заявка может матчиться с несколькими заявками. Например, есть несколько заявок на продажу по 100р, каждая с объемом 5. В этом случае заявка на покупку по 100р с объемом 7 должна полностью погасить первую по хронологии заявку и частично погасить вторую по хронологии заявку. Если же заявка на покупку превосходит цену продажи, то сматчиться она должна по цене продажи.

Из этого рисуется не сильно простой и быстрый SQL код. Я искренне надеялся, что результат окажется плачевным. Но дело было с MySQL и обнаружилась интересная фича. Дело в том, что внутри запросов MySQL можно менять значение переменной. Т.е. есть возможность считать накопительный итог построчно выполняя запрос. Выглядит это примерно так:

SET depth_sell.`limit` = depth_sell.`limit` - IF(                     ((@tofill := IF(                             depth_sell.`limit` <= @limit,                             depth_sell.`limit`,                             @limit                         ))                         + (@limit := @limit - @tofill)),                     @tofill,                     @tofill                 ),         depth_sell.`executed` = @tofill WHERE @limit > 0;

и отдельно

@limit := @limit - @tofill

В голове быстро родился план как филить (исполнять) заявку по стакану.

Второй прекрасной фичей оказались IN MEMORY таблицы. Т.е. данные этих таблиц хранятся в ОЗУ сервера. Что делает операции с ними ощутимо быстрыми.

Все внезапно срослось и родился прототип. Имя мы ему дали — Скулятчер. Во многом это название отражало мое отношение к нему. В гит я класть его не стал, спрятал тут, в подкате.

CREATE TABLE transactions (     id INT AUTO_INCREMENT PRIMARY KEY,     moment TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,     side1 INT NOT NULL,     side2 INT NOT NULL,     price BIGINT NOT NULL,     volume BIGINT NOT NULL );  CREATE TABLE depth_buy (     id BIGINT PRIMARY KEY NOT NULL AUTO_INCREMENT,     order_id  BIGINT NOT NULL,     type INT DEFAULT '0' NOT NULL,     market INT DEFAULT '0' NOT NULL,     account INT NOT NULL,     price BIGINT DEFAULT '0' NOT NULL,     `limit` BIGINT DEFAULT '0' NOT NULL,     taker INT,     rev_price BIGINT NOT NULL,     executed BIGINT ) ENGINE = MEMORY;  CREATE TABLE depth_sell (     id BIGINT PRIMARY KEY NOT NULL AUTO_INCREMENT,     order_id  INT NOT NULL,     type INT DEFAULT '0' NOT NULL,     market INT DEFAULT '0' NOT NULL,     account INT NOT NULL,     price BIGINT DEFAULT '0' NOT NULL,     `limit` BIGINT DEFAULT '0' NOT NULL,     taker INT,     rev_price BIGINT NOT NULL,     executed  BIGINT ) ENGINE = MEMORY; 

CREATE PROCEDURE `make_order_v2`(IN order_id INT,                                  IN order_type INT,                                  IN order_account INT,                                  IN order_market INT,                                  IN order_limit BIGINT,                                  IN order_price BIGINT) BEGIN     START TRANSACTION;     SET @limit := order_limit;     IF order_type = 21 THEN         UPDATE depth_sell             INNER JOIN (                 SELECT id                 FROM depth_sell                 WHERE market = order_market                   AND depth_sell.price <= order_price                 ORDER BY depth_sell.price + id ASC             ) source ON depth_sell.id = source.id         SET depth_sell.taker      = order_id,             depth_sell.`limit`    = depth_sell.`limit` - IF(                     ((@tofill := IF(                             depth_sell.`limit` <= @limit,                             depth_sell.`limit`,                             @limit                         ))                         + (@limit := @limit - @tofill)),                     @tofill,                     @tofill                 ),             depth_sell.`executed` = @tofill         WHERE @limit > 0;          INSERT INTO transactions (moment, side1, side2, price, volume)         SELECT now(), depth_sell.id, order_id, depth_sell.price, depth_sell.executed         FROM depth_sell         WHERE depth_sell.`taker` = order_id;          DELETE         FROM depth_sell         WHERE market = order_market           AND depth_sell.`limit` = 0;          IF @limit > 0 THEN             INSERT INTO depth_buy (order_id, type, market, account, price, rev_price, `limit`)             VALUES (order_id, order_type, order_market, order_account, order_price, -order_price, @limit);         END IF;     ELSE         UPDATE depth_buy             INNER JOIN (                 SELECT id                 FROM depth_buy                 WHERE market = order_market                   AND depth_buy.price >= order_price                 ORDER BY depth_buy.rev_price - id ASC             ) source ON depth_buy.id = source.id         SET depth_buy.taker      = order_id,             depth_buy.`limit`    = depth_buy.`limit` - IF(                     ((@tofill := IF(                             depth_buy.`limit` <= @limit,                             depth_buy.`limit`,                             @limit                         ))                         + (@limit := @limit - @tofill)),                     @tofill,                     @tofill                 ),             depth_buy.`executed` = @tofill         WHERE @limit > 0;          INSERT INTO transactions (moment, side1, side2, price, volume)         SELECT now(), depth_buy.id, order_id, depth_buy.price, depth_buy.executed         FROM depth_buy         WHERE depth_buy.`taker` = order_id;          DELETE         FROM depth_buy         WHERE market = order_market           AND depth_buy.`limit` = 0;         IF @limit > 0 THEN             INSERT INTO depth_sell (order_id, type, market, account, price, rev_price, `limit`)             VALUES (order_id, order_type, order_market, order_account, order_price, -order_price, @limit);         END IF;     END IF;     COMMIT; END;

CREATE PROCEDURE do_load_matcher_v2(IN market INT) BEGIN     DECLARE count INT DEFAULT 100000;     WHILE count > 0 DO             call make_order_v2(                     count,                     IF(count % 2 = 0, 21, 22),                     1,                     market,                     FLOOR(1 + (RAND() * 1000)),                     FLOOR(1 + (RAND() * 1000))                 );             SET count = count - 1;         END WHILE; END;

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

1. depth_buy — содержит заявки на покупку;
2. depth_sell — содержит заявки на продажу;
3. transaction — исполненные заявки = сделки.

Вызывая процедуру make_order_v2 ей передаются параметры заявки:

1. order_id — Уникальный идентификатор заявки.
2. order_type — Тип заявки. 21 — покупка, 22 — продажа.
3. order_account — Идентификатор клиента (владельца ордера).
4. order_market — Идентификатор торговой площадки. Сделки по площадкам не должны пересекаться.
5. order_limit — Объем заявки. Дробные значения закодированы в целые числа путем умножения на десятки. Например, на 100. Т.е. 1.15btc в этом случае будет равно 115.
6. order_price — Цена заявки. Также кодируется в целые числа.

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

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

Производительность, зависит от глубины стаканов. В подкате можно найти процедуру нагрузки. Она генерирует 100К заявок. В результате получается около 95К сделок. На моей машине процедура выполняется за 1.46 минуты. Это около 570 сделок в секунду. Более чем достаточно для задач биржи на тот момент.

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

Почему до сих пор во мне бушуют чувства, когда я вспоминаю этот опыт? С одной стороны:

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

С другой стороны:

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

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

Всем добра!

Оригинальный тивит

Возможности и перспективы agile-трансформации обсуждаются сейчас очень широко, привлекая аудиторию от IT-аналитиков до менеджеров CxO-уровня. Известно несколько западных (пока) школ по достижению так называемого Enterprise Agility – это действительно интересно и даже модно. И как любой hype согласно методике Gartner, по ощущениям, данное направление неуклонно движется к «пику завышенных ожиданий», за которым видимо ждёт «пропасть разочарований» и только потом устойчивое «плато продуктивности».

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

Итак, представим, умудренные опытом руководители некой большой компании озабочены повышенными ожиданиями акционеров, ростом конкуренции, перераспределением выручки в пользу цифровых каналов и связанными с этим вызовами. Как всегда, ищутся способы увеличить производительность труда, усилить присутствие бренда на рынке и просто не потерять ставших более разборчивыми клиентов в условиях турбулентности. Прочитаны бизнес-бестселлеры, проведено много часов консультаций, принимается решение последовать актуальному тренду и начать (или ускорить) трансформацию модели управления. Кто-то говорит пора звать «большую четверку», которая всё объяснит, кто-то предлагает внедрять Scrum of Scrum или делать большую общую Kanban-доску…

Первое, с чего стоит начать

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

Далее оказывается…

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

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

Второе определяется повышением зрелости менеджмента компании — это критично, поскольку, если верить исследованиям, проведенным авторами книги «Лидер и племя», культура команды не сможет держаться выше культурного уровня её лидера (личные наблюдения с этим вполне согласуются). И в целом, необходимо создание условий для вовлеченности сотрудников и мотивации большинства ценить командные достижения выше личных – здесь важно не только обучение, но и ревизия системы компенсаций.

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

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

И лишь на следующем этапе

мы приходим к выстраиванию собственно «кросс-командного» agile: фокусируемся сначала на запуске, потом на взаимодействии конкретных продуктовых команд, руководствуясь прикладными методологиями, основанными на SAFe, LeSS или их производных. Многое можно делать параллельно, однако забывая о вышеописанных фундаментальных основах, вся трансформация рискует потерять смысл и превратиться в игрушку для привлечения талантов.

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