2023-10-26: High Performance Systems - заглянуть в мир enterprise

Материал из MaksWiki
Перейти к: навигация, поиск
Короткая ссылка: HPS-2023

На этой неделе прошла конференция High Performance Systems. Планировался оффлайн, перенести в online. Интересные рассказы о том, что сейчас происходит в развитие ИТ корпораций сейчас, когда надо быстро изменять ИТ-ландшафт. В целом контент конференции — содержательный и полезный. Мои фавориты среди докладов:

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

Рассказ о конференции я начну со своего доклада, а далее пойду по порядку. Помимо докладов, было два круглых стола: «Разработка и DevOps с использованием ИИ» и «Параллельный импорт помогает или тормозит технологический суверенитет?» с любопытными мыслями, но пересказывать их — безнадежно, разговор шел причудливыми путями.

Содержание

Максим Цепков. Готовы к изменениям: адаптивная архитектура как часть ИТ-стратегии

Мой доклад — обобщение 25-летнего опыта Enterprise-разработки. Он говорит о том, что потребности в срочных изменениях в ИТ-ландшафте появились не в 2022 и даже не в 2020, они были всегда. И часто их решением является временный модуль, который решает проблему. Его часто делают, срезая углы и на ручной интеграции, но решение задач бизнеса он обеспечивает. Дальше этот модуль дальше живут своей жизнью, и тут возможны два сценария: либо надо доработать функционал, интеграцию и эргономику, чтобы в системе появился еще один небольшой модуль, либо в .тот модуль постепенно переводят функционал какой-либо из legacy систем, и тогда он становится полноценной системой. Договариваться о сценарии стоит сразу: в острой ситуации бизнес восприимчевее к изменениям.

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

AdaptiveArch-HPS-2023-Tsepkov-CUSTIS.pdf

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

  • Согласиться, что сложный мозаичный ИТ-ландшафт разномасштабных решений — норма. Сейчас так и есть, но я помню время, когда целевой картиной представлялось комплексное решение от одного вендора, быть может с дополнительными модулями.
  • Выделение в системах двух уровней: базы основных исполнительных систем, поверх которого распологаться специализированные рекомендательные и управляющие системы.
  • Постепенное развитие временных и промежуточных решений в полноценные, наращивая функционал: сначала база, реализующая основные сценарии и позволяющая особые случаи обработать вручную, а затем автоматизируем их по необходимости.
  • В системах должна быть устойчивая интеграция для создания и изменения документов и справочников, тоже двух уровней: через ручную загрузку-выгрузку и через API. Ручные загрузки и выгрузки часто могут служить основой для временной интеграции, позволяя преобразовывать данные на Excel.
  • Очень помогает сквозной мониторинг уровня бизнес-процессов для обеспечения целостности. Современные средства позволяют его сделать в мозаичном ландшафте и подключать новые компоненты.
  • Желательна база для быстрой разработки: документооборот, учёт, интерфейсы naked objects. Это могут быть low-code решения или решения на базе какого-то фреймворка.

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

Презентация — на странице доклада Готовы к изменениям: адаптивная архитектура как часть ИТ-стратегии (HPS-2023).

Ольга Латыпова из Сургутнефтегаза. Трансформация в стремлении к ИТ-суверенитету. Что нового?

В Сургутнефтегазе 30 лет формировался интегрированный ИТ-ландшафт на основе SAP. И это — не только софт, это еще и соответствующие методологии: стандарты, порядок управления проектами на PMBOK и ASAP, и управления изменениями на основе ITIL, проектно-методические группы по направлениям деятельности, порядок выполнения работ по заявкам.

Сейчас есть задача трансформации, ухода с SAP, и сделать это надо достаточно быстро. Поэтому монолит поделили на 18 проектов трансформации, дали полномочия руководителям дорожных карт, а координирует это совет по импортозамещению и архитектурный комитет. Определены принципы — private cloud, kubernetes, devops, релизная политика.

Уже выбрано 14 разных решений, на слайде они были. Правда замена ядерного решения на SAP, которое обеспечивает расчет себестоимости — пока не выбрано. Что интересно — 1С в числе выбранных решений нет. Оно было на первом этапе, когда для каждого проекта составляли списки кандидатов, его рассматривали для капстроя, казначейства и чего-то еще наряду с другими решениями. Но дальше был этап, когда они сделали постановки на небольшие контрольные примеры и предложили вендорам реализовать — и получилось, что для 1С нужна разработка с нуля, готового взять нельзя. После этого он отвалился. Следующий этап — системы развернули у себя, настроили интеграцию и провели нагрузочное тестирование.

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

Рустам Курамшин из Газпром ИД. Как инструменты быстрой разработки на Java могут помочь бизнесу

Рассказ про LowCode инструменты разработки в Java-стеке: Spring Data REST для разработки бэк-энда и Jmix, ранее CUBA Platform jmix.io — единственный full stack framework для web-приложений. Java, Spring — open source, у Jmix — run time open source, плата только за средства разработки. Рассказ был с примерами простых приложений.

Spring Data REST — LowCode для бэк-энд Rest API для редактирования записей базы данных: показ коллекций сущностей, фильтрация, в том числе через специальные end point, страницы, точки расширения, метаданные о сущностях ALPS и JSON Schema, JPA, Cassandra, MongoDB и другие базы данных. В примере: описываем класс репозиторий, помечаем аннотациями — и все, есть готовое приложение.

Jmix, ранее CUBA Platform, jmix.io — единственный full stack framework для web-приложений. Java и Kotlin, российская разработка. Готовые визуальные компоненты. Безопасность из коробки: аутентификация, авторизация, ролевая модель, keycloak. Мягкое удаление, аудит изменений сущностей. Декларативное описание сущностей бизнес-домена, GUI-дизайнер для редактирование моделей интерфейса. Есть связь с BPMN — Comunda. И дальше пример разработки вместе с бизнес-логикой. И сразу получаем приложение с экраном входя и так далее. В качестве пилота они сделали админку для одного проекта, успешно — и пошли тиражировать.

Николай Кувыркин из Райффайзен Банк. Система распределённой потоковой обработки платежей StarkNG

Рассказ про вынос compliance правил проверки платежей проверки платежей в отдельную систему. Исторически была система Stark — рабочее место compliance-офицера, по мере того, как платежей становилось больше, в нее вписывали автоматы обработки и принятия решений в виде хранимых процедур на MS SQL. Сложность и число платежей возрастали, и в какой-то момент решили вынести логику в отдельную систему StarkNG. Требования — Прозрачность и наблюдаемость, легкая модификация правил — схемы отмывания меняются. Ретро-тесты: проверка на старых платежах при изменении системы правил. Обновление без простоя, легкое масштабирования. И, что не тривиально, бизнес-логика — на python, потому что его понимают data scientist, а именно они ведут анализ и вырабатывают правила.

Дальше были архитектурные схемы решения. Обработка платежа: получение данных, обогащение по разным базам (списки рисковых лиц и так далее), обработка моделью и ответ: одобрить, запретить или отправить на ручную обработку. Платформа обеспечивает получение платежей и обогащение. а сама модель — stateless. Два кластера: Apache Ignite для выборки из разных списков и Open Search — поиск по текстовым полям, это часто необходимо при обработке валютных платежей (как я понимаю потому, что там часто цепочка платежей через банки-корреспонденты и конечные получатели упакованы в назначении платежа). Apach Active MQ (на него переходят), Activities, Kafka — стандратные технологии, типовой CI/CD, метрики Apache Ignite через jmx-prometheus. Мягкий переход в эксплуатацию: входную очередь дублируют на новую систему и сравнивают результаты по выходной очереди, и когда правила были отлажены — переключили выходную очередь.

И был рассказ про две проблемы.

  • Массовые платежи одного клиента — система многопоточная, по клиентам есть лимиты, модель — stateless, все лимиты надо поднять на обогащении, а результат модели — сохранить. Поэтому если платежи попали в разные потоки, то возникает ожидание, и для больших клиентов типа Озона, Wildberries, которые раз в пару недель делают десятки тысяч платежей — они забивают все потоки. Сделали отложенную очередь и два счетчика: ClientFlight Counter и LockTime — они обеспечивают откидывание этих платежей.
  • Split Brain в Apache Ignine — кластер разваливается на два кластера, которые независимы — случается, если кластер по двум дата-центрам и нарушилась связь. И в момент развала платежи клиента пошли в разные половинки, то каждый платеж пройдет. В каждой половинке кластера к кэша полный набор партиций. Есть вероятность split brain для разных нод, и при 7+ нод — вероятность равна нулю. Борьба — только через логи, обработку операций, megre данных не работает (было 100, в одной списали 40, в другой — 50 — merge сделать нельзя, надо выполнить операции.

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

Лев Палей из WebmonitorX. API Security и API Management. Что было дальше?

Обзорный доклад про API security. Рост API. Среды разработки на разработку API не ориентированы, хотя докрутить можно. Типовые проблемы, как всегда, связаны с человеческим фактором и которые, по-моему, свойственны любой разработке: отсутствие описаний, swagger можно порождать и контролировать, но не делают; на тесты на производительность нет времени; не делают мониторинг; считают, что раз api не публичный — можно не думать о безопасности, а это заблуждение, есть злоумышленники внутри, а еще внутреннее api могут частично прокинуть наружу; срезание углов, когда надо быстро выпустить релиз; не сделали полные тесты после последних исправлений; не убрали временный функционал или тестовую фичу.

API и микросервисы. Микросервисы взаимодействуют по API, службы — тоже по API. Ingress Controller — еще одна точка сборки.

Service Mesh: Control plane — Data plane. Маппинг протоколов к приложению, управление приложениями. Новый уровень абстракции — контейнеризация.

В докладе — несколько слайдов с полезными ссылками. Open source системы для api: kong, gravitee.io, wso2 api microgateway. Есть ссылки на рейтинги и сравнения на хабре. Выигрывает gravitee, но он под сложные задачи, требует администрирования.

Появился российский nginx — angie pro и Ingress controller ANIC, довольно быстрое обновление. API Firewall — быстро что-то заблокировать. Open source. Reverse proxy на Go, поставляется как контейнер, много чего умеет.

Будущее: автоматическое создание swagger по трафику, автоконфигурация API-политик на gateway как тесты и нативная интеграция контекста api security в service mesh и api management, не только валидация.

Анастасия Кирилова. DataLabs Магнит: новый уровень работы с данными

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

Правда, для успеха надо уметь формулировать гипотезы о том, кто именно является вашей целевой аудиторией. При этом магнит не только сам проводит подобные компании, но и предоставляет такие возможности другим через сервис Datalabs, в том числе загружая собственные данные из CRM. Но нужна модель покупателя и товара, надо учитывать что какие-то товары покупают периодически, например, если человек только что купил стиральный порошок, то предлагать надо через некоторое время, а не сразу и так далее. У Магнита есть модель для выделения покупателей, склонных к промоакциям, есть модели предсказания покупок. Можно этим пользоваться, можно строить свое. Но в любом случае нужна собственная команда data scientist, которые умеют анализировать данные и создавать ML-модели, это — ограничение. И нужны аналитики, которые умеют переводить задачи от бизнеса на понятный data scientist язык. И бюджет.

И в докладе были любопытные примеры успешных кейсов с гипотезами о целевых группах.

  • Мужской гель для душа: выбирали женщин, которые покупали подарочные наборы мужчинам за последние 12 месяцев. И не только по целевому бренду и набору, но и по сопутствующим.
  • Запуск нового продукта по йогуртам: сегмент тех, кто покупал йогурты и сегмент тех, кто часто приходит в магнит. Реклама на тех, кто часто приходит реклама новых продуктов хорошо работает.
  • Бытовая химия: среди людей, склонных к промо в среднем сегменте (высчитывается); и те, кто НЕ покупали бытовую химию из линеек, не участвующих в розыгрыше, за последний месяц — у них уже есть.
  • Шоколадные конфеты, увеличение продажи без скидок. Перед праздниками собрали тех, кто совершал набор перед праздниками любых наборов, не только конфет.

Антон Бочкарев, Третья сторона. Путь информационной безопасности в компании — ошибки, заблуждения и предубеждения

Интересный взгляд на работу с информационной безопасностью через модель Кюблер-Рюсс 5 стадий принятия неизбежного: Отрицание — Гнев — Торг — Депрессия — Смирение. Неожиданно, что для описания ситуации, касающейся рационального принятия решений используется психологическая модель, разработанная для людей, которым надо принять инвалидность или неизлечимую болезнь. Но автору — виднее, он профессионально работает с этими вопросами, и считает модель адекватным описанием.

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

  • киберкриминалу (RaaS)
  • высококвалифицированным хактивистам — те, кто через взлом проводит лозунге
  • радикальный инсайдер — тот, кто готов совершить диверсию при обиде не компанию, в том числе при уходе
  • продвинутые угрозы (АРТ) — связка со спецслужбами и другими особыми организациями.

Наиболее массовой угрозой является киберкриминал. И тут надо понимать, что это — целая отрасль со своим разделением труда, которая работает по модели RaaS — криминальный софт как услуга. Есть разработчики, который пишет вредносное ПО, например, шифрует данные. Он поставляет это ПО распространителями за комиссию и жертв. Распространители — заражают жертву. Выкуп получают третьи люди, которые торгуются, потом отмывают деньги и пересылают. Они лично друг друга не знают, через форумы и систему репутаций. Арест любого участника не помогает добраться до других. Схему успользуют десятки группировок в мире. И эта схема будет жить независимо от политики, хотя события последнего года ее активизировали просто потому, что ослабили международное сотрудничество в противодействии. Остальные вызовы возникли или обострились с 2022. Под атакой хактивистов может оказаться любая компания, просто потому, что уязвима, независимо от потенциальной выгоды.

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

  • Отрицание: «нам это не надо». Работа — через известные примеры. Colonian pipeline — топливный кризис в США. Банки США в 2022 заплатили 1.2 млрд $. стадия заканчивается, когда руководство осознает неизбежность ИБ, готово принять, быть может в следствии инцидента или по другим причинам.
  • Гнев: стадия инцидента или внутрикорпоративного конфликта. Почему взломали именно нас? Зачем нам покупать такое дорогое? Тут надо выводить в рациональные аргументы, объяснять. что глупость вероятнее заговора, открыто проводить сравнение вариантов и рисков. Заканчивается, когда риски становятся понятными и эмоциональное противодействие уходит.
  • Торг. В компаниях часто экономят на маловажном, и ИБ оказывается в этом ряду. Мониторинг сделаем сами на открытом ПО, безопасность сделают наши разработчики. И здесь надо разъяснять, что ИБ — высокотехнологичная отрасль, где нужны профи. Софт же заказывают, не весь делают сами. При этом есть ситуации, когда собственная разработка оправдана, потому что надо что-то экзотическое, или актуальных угроз мало, а профессиональные разработчики есть. Хотя там тоже вопрос со стоимостью владения — ведь методы атак совершенствуются, это надо отслеживать. Перевешивать функции ИБ на ИТ — профи в обоих быть невозможно, потому что там всего очень много. Полезен аудит профи, но надо понимать, как проверять тех, кто проверяет вас. В любом случае экономия на страховке снижает ее эффективность. Стадия заканчивается, когда ИБ выделена как отдельная структура со своим бюджетом.
  • Депрессия. ИБ появилась, но есть внутреннее ощущение, что все равно не хватит штата, на текущих бизнес-процессах не заработает и так далее. Когда по ИБ есть документы, которые не работают и даже не читают. В этой ситуации важно делать лишь нужное, не делать документ ради документов. Не защищать все на 100 %, надо оказаться не самым низковисящим фруктом. Аутсорсинг и аутстаффинг дешевле, выгоднее, а иногда эффективнее. Достаточно директора по безопасности part time. Работать не по площади, а начиная со слабыми звеньев. Выход в следующую стадию — когда ИБ начинает реально влиять на процессы.
  • Смирение. ИБ начало действовать. Зачастую без плана и в рамках хоть какого-нибудь бюджета. И тут нужны roadmap, оценка рисков, business impact analysis, больше консультаций и внешних оценок аудиторов. Целевое идеальное состояние — Zero trust — все под контролем, идут только суперкрупные, а доходят единицы. Стадия завершается выходом в планомерное развитие.

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

Харитон Никишкин из Secure-T. Последствия низкой осведомленности персонала и процесс автоматизации с целью контроля воздействия человеческого фактора на ИБ

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

Было несколько примеров

  • В 2019 на территории штата Гавайи была ядерная тревога, через 50 минут отменили. Сотрудник центра мониторинга ядерных угроз, и на фото на стикере был виден пароль от учебной записи сотрудника — кто-то залез и по приколу нажал кнопку. А сразу написать, что ложная тревога не смогли, потому что оповещение было через твитер, сотрудник от стресса забыл пароль.
  • Предприятие пищевой продукции в России — в сеть была выставлена запись администратора, подобрали пароль. Зашифровали данные, предприятие стояло 3 часа. Потребовали заплатить 500$ но платить тут бесполезно — как правило никто не расшифрует.
  • Крупный бельгийский банк. Сделали фишинг от имени директора, сделайте быстрый перевод 70 млн евро — и бухгалтер выполнила.
  • В России от имени ЦБ письмо в compliance-отделы банков с увеличить деньги на депозитах в ЦБ с реквизитами — часть банков исполнила, не обратив внимания на странные реквизиты.

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

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

Мне лично это не кажется эффективным, потому что проколы — очевидные: не пиши пароль на стикерах, не переводи деньги по первому требованию даже начальника, не выставляй а интернет админку, а если выставил — меняй пароли. Это как вводить обязательное обучение правилам движения для пешеходов, рассказывая про очевидные вещи, например. о правилах перехода улицы. Люди — знают, только не выполняют. Впрочем, я бы согласился, если бы была статистика, которая показывала бы эффективность обучения. А ее я в подобных докладах пока не слышал. Более того, автор приводит примеры, которые опровергают, у них сотрудник, который профессионально занимался противодействием фишингу, разрабатывал средства, сам на него попался, открыл ссылку — потому что суббота вечер, а он спешил. И в целом у них статистика, что есть две группы риска, и это — не бухгалтеры, а топы и ИТ. Топы считают, что они слишком заняты, чтобы об этом думать, поэтому открывают ссылки не глядя, а виновато у них всегда ИТ. А ИТ — для них надо правильно оформить фишинг, например, замаскировав на сообщение от miro и аналогичных систем, и тогда они тоже доверяют…

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

Азамат Журсенов и Дмитрий Асланов из Ростелеком. Радикальное ускорение доставки бизнес ценности через построение конвейера непрерывной поставки. Опыт создания решения Базис

Система Базис — унифицированный CRM и биллинг. Делают 250 разработчиков, половина внутри, остальное — подрядчики. В условиях постоянного развития, появления новых продуктов.

Основная задача ускорить доставку с полугода-года до месяца. Ее декомпозировали.

  • Единая система управления требованиями и задачами
  • Сильный состав Product Owner
  • Гибкое управление мощностью
  • Fast Track — быстрая доставка, в том числе для неожиданно появляющихся требований
  • Квартальное планирование — фиксация договоренностей с бизнесом
  • Релизный календарь и управление синхронизацией. Не раз в полгода, как было. Цель 2-4 недели для релизов без жесткой фиксации, так как окна ограничены.
  • Критерии качества для выкатки на прод: дефектов не больше чем порога, отсутствие критичных дефектов
  • Отдельное требование: процессы продажи в comunda не должны переходить через релиз, так как некоторые из продаж идут долго.

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

Новая структура команд. Были фиксированные команды и единственный способ маневра — переход человека из одной команды в другую с онбордингом в новой команде. Что сделали?

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

В результате достигли 30 % уровня балансировки на любой команде — это маневр мощностью.

Квотирование мощности команд: 65 % на основные задачи бэклога, 10 % — отпуска и болезни, эмпирически вычисленная цифра, 10 % на развитие и техдолг, 15 % дефекты с промышленной среды. Это распределение по умолчанию, оно плавает, например, число дефектов зависит от уровня стабилизации продукта.

Ранее внедряли SAFe, но в некоторый момент внедрение остановили, начали делать гибридную конструкцию, добавляя Capacity Management, а из SAFe взяли только нужное. Квартальный pi-planing остался, но формат в результате сильно изменился, вместо 2-дневной сессии — 30 минутное окончательное увязывание планов.

На входе в pi-планирование — ролевая модель и мощность команд с учетом участия: новички в первый месяц 0, админы 50 % и так далее. Загрузка на планировании с точностью 10 % — точнее не надо, так как все равно будут изменения. Результат pi-плана — Цели релиза, включая тех.долг и план релизов внутри квартала. Ретро в конце квартала — что достигли, как попали в оценки. Обязательно ведут списание трудозатрат на задачи и анализ в Power BI.

Конвейер задачи: Исследования → Оценка (мин.ресурсами и в оптимизме) → PI-план + разработка → Отгрузки. Оценку надо сделать быстро и без обсуждения всей командой, для этого постепенно выделились типовые задачи, к этому шли постепенно.

Инструментарий.

  • Оценки — это отдельный процесс в jira
  • Система для ведения состава команд, %занятости и роли
  • Планировщик, который позволяет распределять задачи по спринтам, сопоставляет с мощностью.
  • Гант по релизам
  • Синхронизация релизов на планировании — плагин в Jira, туда завели все компоненты, в том числе от внешних подрядчиков с интеграцией с их таск-трекерами или вручную.

Результаты

  • Стабилизация релиза от 13 до 3 итераций, 1.5 недели
  • Не успели — переносим задачу, сырое — не льем.
  • Гибкость команд
  • Максимум тестов на средах разработки
  • Поэтапная отгрузка — feature toggle, ролью или продуктом
  • Бэклог 1500 -> 300
  • Время доставки 6м — 3w
  • SLA дефектов
  • PI plan — 2d — 20 min
  • Квартальный контракт 95 % — 55 %
  • Рост производительности 1.8

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

Есть задача импортозамещения jira, в эту сторону начали работать. Смотрели много продуктов, пока смотрят на собственное решение Ростелекома — Яга. Kaiten — смотрели, но порекомендовать не могут.

Я замечу, что реорганизация и достигнутые результаты — впечатляют. Но вот интересно, если бы на входе принять простое решение: «не успели — переносим задачу, сырое — не льем», то, возможно, этого было бы достаточно для сокращения времени стабилизации релиза и, как следствие, для достаточного увеличения их частоты? Потому что понятно, что если релиз стабилизируется 13 итераций, то часто такие релизы носить нельзя, а если всего 3 — то можно…

Лев Хакимов из Wildberries. Сказ о рулевом и прорехах на пиджаке. Как защитить kubernetes

Мне понравилась фраза Льва, когда он рассказывал о себе: «DevOps — не работа, а состояние души».

Kubernetes — как ядро linux. Это базовая технология, которая не очень самостоятельная. Чтобы работать безопасно — надо настроить достаточно много, в том числе сторонних программ. B дальше был рассказ о различных уязвимостях, которые требуют грамотного конфигурирования, а по умолчанию они открыты: создавали kubernetes разработчики для разработчиков.

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

  • Уязвимая конфигурация подов — потому что по умолчанию поды конфигурирует любой. Контейнер — не VM, изоляция идет средствами ОС, и есть набор механизмов: linux namespaces, capabilities и другие.
  • Опасные разрешения: cap_sys_admin — монтируем файлы, в том числе host — и дальше можем править, cap_net_raw — перехват и замена трафика, cap_sys_module — ставим свои модули
  • Через конфигурацию можно отключить изоляцию, включить привилегированный режим контейнера, заставить разместить под на мастере, и еще игнорировать запрет админа на мастер, а потом подключить себе файловую систему host и начать работать с файлами.
  • Выводы: не запускать privileged, root недопустим, и разрешение недопустимо
  • Как контролировать: OPA gatekeeper, Kyverno. Есть и другие. Если gatekeeper знаком — можно им, kyverno проще, yaml. Для них есть настройки по умолчанию: cis benchmark, pod security standard

Supply chain атаки.

  • целостность образов, которые стартуют — механизм подписи образов как часть деплоя cosign, notary, kyverno уже умеет
  • уязвимости библиотек — откуда они тянутся.
  • уязвимости open source продуктов

Для контроля — Software bill of materials — список зависимостей SBOM — можно скормить Tryvy-сканеру или другому. Living of Land — атака с использованием легитимного ПО, а в нем есть дыры, поэтому рекомендуют на проде использовать облегченные образы.

Роли

  • выключить автомаунт сервисных токенов
  • принцип наименьших полномочий
  • RoleBindings — только у доверенных систем
  • избегать роли cluster admin
  • RBAC аудит
  • контроль за ненужными ролями и аккаунтами, в том числе для сервисов
  • политики — настраиваем, и еще проверяем Admission controller

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

Authentification — authorisation — admission control

  • не использовать authentification по сертификатам — их нельзя отзывать
  • двухфакторная авторизация
  • не использовать сервисные аккаунты для подключения извне, надо — выпишете короткоживущий токен
  • конфигурация железа: dev и prod — разные кластеры и др. Service Mesh можно попробовать — но дорого в прогреве.

Не забывайте поглядывать за актуальными CVE (база данных уязвимостей) — не только когда кластер поставили.

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

Константин Аксенов из Флант. Как успевать больше за один спринт: высвобождаем ресурсы разработчиков с помощью Kubernetes-платформы Deckhouse

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

Флант — первый сертифицированный поставщик kubernetes в России, и № 1 контрибьютор в России. Deckhouse — 6 лет эксплуатации, более 1 млн кластеров.

Контейнеры. Похожи на vm, но без виртуализации железа и ОС снаружи — сильно меньше ресурсов и размер меньше. Когда такой способ стал распространенным, появилась задача управления контейнерами на большом количестве серверов, системы оркестрации контейнеров. Их несколько, но самый популярный — kubernetes, за ним — open shift.

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

Практики обеспечения надежности.

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

Любую систему можно сломать и использовать неправильно. Но Kubernetes многое гарантированно восстанавливает после аварии. Скрипт разработчика удалил по ошибке worker-узлы кластера в продакшн конфигурации, потому что в одном каталоге лежали разные конфиги. Но есть декларативное описание целевого состояния — и продакшн он восстановился.

Когда можно быстро откатиться — разработчики не боятся накатывать изменения на прод.

Гибкая инфраструктура. Облачные вычисления растят ключевые показатели и благополучие продукта. Cloud smart — свобода использования окружения. Единая платформа с единым интерфейсом и настройками kubernetes.

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

Платформенный подход: для команды разработки можно просто получить все инструменты, можно переиспользовать готовые компоненты, минимум накладных расходов. Platform Engineering — в топ-10 по Gartner. Reusable component, developer tools, self-service developer portal. Пример от Nike: Платформа позволяет выделить нужные ресурсы БЕЗ механизма заявок, по одной кнопке.

Основная проблема kubernetes — сложность технологии. Там надо много конфигурировать, чтобы сделать адекватно вашим задачам. Разъезжаются конфигурации кластеров, поддержка многих систем. Проблема отсутствия экспертизы и необходимого опыта, сложность найма специалистов. При этом интенсивное развитие, в год 3-4 релиза и патчи.

Пример. Автомасштабирование — из коробки его нет. Есть open source компоненты. по cpu и памяти — metric servers, если еще по числу запросов и длинне очередей — свои средства. И таких вопросов — много. И для каждого — свои компоненты. Multicloud — всем нужен, но он увеличивает и сложность. Решают эту проблему kubernetes платформы, которые нужные свойства добавляют из коробки. Такие как deckhouse.

Артем Каледин из Билайн. Лидерство по методу надежной базы — как эффективный процесс руководства команды в условиях ограниченных ресурсов

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

Я, пожалуй, помещу тут пару слайдов из его презентации, которые раскрывают понятие и продолжу конспект.

HPS-2023-Каледин-1.png
HPS-2023-Каледин-2.png

Зачем нужно лидерство? Объединение команды для достижения целей и передача ответственности. Но в жизни все равно люди увольняются, задачи не закрываются в срок, возникают конфликты. Лидерство по методу надежной базы это решает.

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

Лидер — товарищ, не коуч как в трансформационном подходе и не авторитет или дипломат, как в классике.

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

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

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

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

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

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

В докладе были опросы о лидерстве в ИТ-блоке Билайн, и это интересно.

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

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

HPS-2023-Каледин-3.png

И в конце доклада — универсальный todo лист — простые практики. Надо знать с кем работаем, что их мотивирует. Jobs to be done. Его я тоже публикую, тем более, что там был QR-код для всех желающих.

И хочу сказать, что концепция — интересная и требует обдумывания. В том объеме, в котором она изложена, я бы это кратко сформулировал в двух тезисах: (1) лидер должен быть взрослым человеком, а не импульсивным ребенком и (2) лидер должен видеть потенциал сотрудников и способствовать его раскрытию. Про первое все очевидно и верно, при этом все мы встречали руководителей, которые ведут себя не слишком по-взрослому. И безусловно важно позитивное и созидательное поведение этого взрослого. А вот со вторым — есть вопрос: не превращается ли лидер при этом в родителя для сотрудников? По идее нет, если он не только сам ведет себя как взрослый, но и учит сотрудников быть взрослыми. Взрослый человек, в том числе, умеет сам выбирать свой путь. Но вот этот аспект не раскрыт. И это — важно, потому что инфантилизм взрослых людей сейчас — относительно распространенное явление, оно вызвало даже такой феномен, как поколение снежинок (Snowflakes). Но это — первая реакция, я еще об этом подумаю.

Андрей Сухоруков из Лабораторим Касперского. Импортозамещение и миграции облаков — сказки на обочине

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

А еще мне понравились заключительные тезисы.

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

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

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

В чем же состоят грабли?

  • Реальная инфраструктура в облаке не будет соответствовать документациИ, особенно маркетинговой. Был обещан готовый open shift, и не так, чтобы его не было совсем, но он почти не работал. вообще продукты, предоставляемые облаком, например, базы данных, будут отличаться от оригинальных решений. Сетевых абстракций — больше, логика безопасности — другая и часто даже нет RBAC.
  • При этом все это в документации описано плохо, обычно там простые примеры, в которых все работает, а сложные вещи не описаны. И по сути 5 месяцев из года они разбирались с тем, что же на самом деле предоставляет облако и в каком виде.
  • И вот здесь критичную роль играет квалификация персонала devops: он должен разбираться в облачных технологиях на очень высоком уровне, чтобы прорываться через возникающие проблемы. А этого обычно нет, такие люди слабо доступны, их мало.
  • А дальше вопрос рабочих процессов в командах, которые дорабатывают сам продукт для переезда. Нужно общее понимание, куда едут, какие особенности с теми продуктами, которые предоставляет облако, в чем отличие от автономно устанавливаемых версий, например. нестандартный кубернетис. Синхронизация работ, совместное тестирование, инфраструктура для этого тестирования.

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

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

Базовые ошибки.

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

Проблемы российских облаков

  • Очень слабый сервис. Это — норма. Это особенность нашего менталитета, относится не только к облакам. На входе сервиса чаще всего специалисты-передатчики. а не те. кто решает проблемы. Документация слаба.
  • Слабая информированность клиента об обновлении инфраструктуры облаков — и постоянные аварии из-за обновлений. Облако при этом заявляет, что оно не виновато, оно просто соответствует стандартам безопасности и накат обновления был обязателен.
  • Облака дорабатываются на клиентах. Они выпускают обновления, которые могут все ломать. И они не виноваты, они тоже заложники ситуации «надо вчера». Облака вольны выпускать обновления когда хотят, тестируют слабо, и вообще это обновление безопасности, и любое обновление можно так квалифицировать.
  • Российский облака — часто не понимают, что делают, нет концепции развития. Бери больше, кидай дальше. Акронимы, а не логика. И при этом хотят посадить потребителя на вендорлок.

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

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

Владимир Пашковский из Магнит ИТ. Метрики производительности команды

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

В докладе была важная мысль, чем команда отличается от группы разработчиков. Команда вся работает на продукт. Есть цель спринта, ее KPI — релиз. Я знаю, чем занимаются коллеги, а они знают, чем занимаюсь я. И каждый знает, как работает продукт. И в этом отличие от разработчика, который делает только свои задачи и знает только свой код.

Метрики.

  • dev time: скорость, емкость, количество труда — можно брать из таск-трекера
  • t2m, частота релизов
  • предсказуемость: % выполнения целей спринта и роадмапа, таймлайн
  • качество: процент багов в спринте и их трудоемкость, доступность SLA
  • экономика
  • eNPS — удовлетворенность сотрудников.

И был разбор, как отдельные практики влияют на метрики. Что важно, влияние обычно комплексное, практики влияют на несколько метрик и наоборот, одна метрика зависит от применения набора практик. Метрики дают индикатор проблем, а дальше надо смотреть причины и понимать, какими практиками их исправить.

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

Важным фактором является agile-фреймворк, он влияет на все метрики, он определяет workflow снаружи, путь задачи в команду, и путь задачи внутри команды до релиза. Инженерные практики: git-flow, стандарты и практики, сервисы обработки. Качество: качество кода, техдолг, доступность SLA, зависимости. Качество — через стандарты написаняи кода, а не каждый как хочет.

Удовлетворенность сотрудников (eNPS) зависит от двух факторов: коммуникации — с PO, TL/SM, бизнесом, и комфорт — без бюрократии, интерес к работе, рабочее место.

Итого. Н

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

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 01:29, 26 октября 2023 • нет комментариев
Источник — «https://mtsepkov.org/index.php?title=Блог:Максима_Цепкова/2023-10-26:_High_Performance_Systems_-_заглянуть_в_мир_enterprise&oldid=7671»