Перезагрузка. Руководство McKinsey по преодолению конкуренции в эпоху цифровых технологий и искусственного интеллекта

Приложения

API и платформа управления

1

Данные

От точки к точке к развязке

Продукты данных

Хранилище данных (по доменам)

Аналитика

Хранилище необработанных данных

Потоковая передача в реальном времени

4

От пакетной обработки данных к обработке данных в режиме реального времени

Основные системы обработки данных

Физические каналы

CRM

Веб-сайт

Мобильный

2

ПРИЛОЖЕНИЕ 17.1

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

Для создания такой архитектуры необходимо принять "облако" в качестве технологической основы (подробнее об этом в главе 18) и обеспечить следующие четыре ключевых изменения в его работы.

От точки к точке к развязке

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

Принять интерфейсы на основе API, но управлять их распространением

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

Джефф Безос из Amazon известен своей служебной запиской, которая изменила Amazon и мир программного обеспечения1. По сути, в ней говорилось следующее:

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

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

Неважно, какую технологию они используют. HTTP, Corba, Pub- sub, пользовательские протоколы - неважно. Безосу все равно.

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

Тот, кто этого не сделает, будет уволен.

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

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

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

Одна фармацевтическая компания, например, создала внутренний "рынок данных" для всех сотрудников с помощью API, чтобы упростить и стандартизировать доступ к основным информационным ресурсам, а не полагаться на собственные интерфейсы. Компания постепенно - в течение 18 месяцев - перевела наиболее ценные существующие потоки данных в структуру, основанную на API, и развернула платформу управления для предоставления API пользователям. Такая архитектура корпоративных данных позволила значительно ускорить разработку и внедрение инноваций, основанных на аналитике и искусственном интеллекте.

По их словам: Трансформация API

"[Сначала мы определили приоритетность наших API, структурировав] существующие сервисы в нашей корпоративной сервисной шине (ESB) по стандартным банковским доменам, таким как клиент и продукт. Мы также определили приоритетность некоторых небанковских

API как "общие" или "для взаимодействия с каналами", например, кампании, предложения и функции оптического распознавания символов (OCR).

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

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

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

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

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

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

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

Позже мы столкнулись с проблемой повышения производительности наших agile API-отрядов. Когда мы начинали, для наших команд было приемлемо создавать один API за два-три недельных спринта. Однако, чтобы следовать нашей дорожной карте, нам нужно было значительно повысить производительность. Мы использовали инструменты автоматизации DevOps для оптимизации интеграции и обеспечения непрерывного развертывания и доставки и удвоили объем выпускаемых API".

-Сауд Аль Дхавиани, директор по технологиям, Emirates NDB

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

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

На рисунке 17.2 представлен обзор современной архитектуры приложения, реализованной производителем медицинского оборудования для своего потребительского приложения. Шлюз на входе контролирует входящий трафик и обеспечивает безопасность. Уровень API определяет, какие сервисы приложения запрашиваются. Облачная платформа данных организована как хранилище больших объемов данных в озере данных и более специализированных продуктов данных, готовых к потреблению пользователем или приложением (например, данные о клиенте, медицинском изделии и местоположении для обеспечения соответствия местным нормам).

На рисунке 17.3 показана подробная схема, иллюстрирующая, как была собрана архитектура. Обычно на таком уровне детализации работают архитекторы решений и инженеры полного стека. Эта архитектура была построена в Azure с добавлением лучших в своем классе и/или открытых инструментов. Сопоставление один к одному между примерами 17.2 и 17.3 не должно вызвать затруднений. Все руководители компаний должны понимать архитектуру своего решения на уровне иллюстрации 17.2, а архитекторы и инженеры - на уровне иллюстрации 17.3.

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

Автоматизация создания инфраструктуры. Использование инфраструктуры как кода (IaC) позволяет agile-подразделениям создавать облачные среды, инфраструктуру, хранилища и любые другие необходимые им сервисы повторяемым, экономически эффективным и надежным способом. Явно прописывайте все спецификации инфраструктуры в конфигурационных файлах, чтобы создать "единый источник правды". Это также создает полезный след всех изменений и упрощает возврат к исходному состоянию в случае необходимости.

Современная архитектура приложений1 - обзор

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

Места

GraphQL / слой API

Шлюз и входная дверь

Модель 1

Модель 2

Данные о потреблении

Продукты данных

Аналитика / модели искусственного интеллекта

Клиенты Продукция

Модель 3

...

Озерный дом данных

Основные системы / системы учета

Цепь поставок HRS

ERP

...

Сырые данные

...

Курируемые данные

Основные системы/системы учета Системы, обеспечивающие работу основных систем

деловые операции

компания

Чтобы способствовать повторному использованию кода и избежать дублирования, при написании инфраструктурных скриптов обязательно создавайте блоки кода. Создайте простой и удобный способ каталогизации этих высококачественных блоков кода в одном месте, чтобы разработчики могли легко их находить (см. главу 20). Примерами блоков кода IaC в Google Cloud Platform (GCP) может служить настройка службы Cloud Asset Inventory, которая обеспечивает видимость ресурсов для мониторинга, анализа и понимания всех активов в рамках проектов. Другой пример - настройка Compute Engine, сервиса для предоставления высокопроизводительных виртуальных машин в виртуальном частном облаке.

Автоматизируйте доставку программного обеспечения на производство

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

От фиксированного к развивающемуся

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

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

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

От пакетной обработки данных к обработке данных в режиме реального времени

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

При подходе к обработке данных в реальном времени необходимо определиться со стандартом обмена сообщениями между приложениями (т. е. платформой обмена сообщениями) и стандартом потоковой передачи данных. Платформы обмена сообщениями предоставляют цифровым приложениям возможность публиковать сообщения, на которые подписаны приложения, способные действовать по мере их получения. На уровне предприятия существует множество вариантов платформ обмена сообщениями (например, Apache ActiveMQ, Apache Kafka, RabbitMQ или Amazon Simple Queue Service). Выбор стандартной платформы обмена сообщениями позволяет цифровым приложениям отправлять и получать дискретные сообщения, не связывая их между собой.

Потоковая передача данных обычно используется для аналитики или обработки данных в реальном времени. Существуют различные виды потоков, например датчики или биржевые сводки, и для каждого из них должен быть свой стандарт. Например, при выявлении мошенничества потоковая передача данных может помочь вам проанализировать и интерпретировать группу транзакций по сравнению с каждой отдельной транзакцией (см. Рисунок 17.4). Как и в случае с платформами обмена сообщениями, существует множество вариантов потоковой передачи данных на уровне предприятия (например, Kafka, Amazon Kinesis, Apache Spark или Apache Flink).

Передача сообщений по сравнению с потоковой передачей

СООБЩЕНИЕ

Сообщение/событие Логика Действие

Входящее электронное письмо

Фильтр спама Отправкав папку нежелательной почты, если письмо распознано как спам.

СТРИМИНГ

Группа сообщений/событий

Логика Действие

Группа сделок

Алгоритмы обнаружения мошенничества

Блокируйте кредитную карту при обнаружении мошенничества

ПРИЛОЖЕНИЕ 17.4.

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

Глава 18. Более

хирургический и ценностный подход к облачным технологиям

Откровения находятся в облаках.

-Сердж Кинг

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

Успешная интеграция облака в цифровую трансформацию и трансформацию с помощью ИИ требует подхода, основанного на том, где находится ценность.

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

Одновременно переосмысливайте бизнес-сферу и базовые технологии

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

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

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

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

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

Типовые варианты архитектуры для создания цифровых решений

Типичный

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

Создание нового облачного приложения

Используйте основное системное приложение "как есть" (с оберткой)

Повышение сложности

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

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

Изменение всей основной системы для повышения производительности и снижения стоимости единицы продукции

Примеры банковских операций

Создайте мобильное приложение для оформления кредитной карты с минимальным количеством кликов

Используйте приложение "KYC - Знай своего клиента" в основной банковской системе

Создание нового механизма принятия кредитных решений для замены основной системы оценки кредитных рисков

Перенос и рефакторинг всего приложения для оценки кредитных рисков в облако для ускорения вывода на рынок

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

Инженерные соображения

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

Использование API для доступа к приложению системы KYC и обеспечение производительности в режиме реального времени

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

Примите решение о выборе оптимального варианта миграции (см. варианты миграции в облако)

Параллельно запустить старую и новую базовую систему и разработать стратегию миграции данных

ПРИЛОЖЕНИЕ 18.1

Определите возможности использования облаков и подход к миграции

Если данное решение необходимо перенести в облако (в отличие от вывода из эксплуатации или замены на SaaS-решение), то вторичным решением будет "перевести" приложение в облако, "рефакторить/реархивировать" или что-то среднее, например "переплатформировать" (см. Рисунок 18.2).

Шесть вариантов утилизации/миграции унаследованных приложений

Уйти на пенсию

1

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

Выкуп

2

Приложение, которое устарело с технической или деловой точки зрения и нуждается в замене на облачный SaaS1

Rehost ("поднять и сдвинуть")

3

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

Реплатформа

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

4

Рефактор/архитектор

5

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

Сохраните

6

Приложения, которые не готовы к миграции или миграция которых не имеет смысла с точки зрения выгоды

1. При замене приложения вы можете создать приложение на заказ или настроить приложение SaaS в зависимости от зрелости рынка SaaS и потребностей бизнеса.

ПРИЛОЖЕНИЕ 18.2

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

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

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

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

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

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

Выбор поставщика облачных услуг

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

Создайте облачную основу

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

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

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

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

Шаблоны приложений. Это артефакты кода, автоматизирующие безопасную, совместимую и стандартизированную конфигурацию и развертывание приложений со схожими функциональными и нефункциональными требованиями. Шаблоны приложений могут отвечать за конфигурирование общих ресурсов, стандартизацию конвейеров развертывания, а также за обеспечение качества и соответствия требованиям безопасности. Примерами шаблонов приложений являются шаблоны обработки данных, такие как SQL DB, NoSQL DB, data mart/warehouse; веб-приложения, такие как статический веб-сайт или трехуровневое веб-приложение; API и т. д. Количество шаблонов, необходимых для поддержки перечня приложений, должно быть небольшим, что позволяет добиться максимальной рентабельности инвестиций. Например, один крупный банк успешно использовал всего 10 шаблонов приложений, чтобы удовлетворить 95 % необходимых сценариев использования.

Эти основополагающие элементы позволяют в восемь раз ускорить темпы миграции и внедрения облачных технологий и на 50 % сократить расходы на миграцию в долгосрочной перспективе.3

Наращивайте потенциал FinOps

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

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

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

Примечания

Абхи Бхатнагар, Бейли Колдуэлл, Альхарит Хуссин и Абдалла Салеме, "Облачная экономика и шесть самых вредных ошибок, которых следует избегать", McKinsey.com, 3 мая 2022 г., https://www.mckinsey.com/capabilities/ mckinsey-digital/our-insights/cloud-economics-and-the-six-most- damaging-mistakes-to-avoid.

Аамер Байг и Джеймс Каплан, "Пять шагов для поиска ценности в облаке", CIO, 2 февраля 2022 г., https://www.cio.com/article/304106/5- steps-for-finding-value-in-the-cloud.html; см. "Семь уроков о том, как технологические преобразования могут обеспечить ценность", McKinsey.com, 11 марта 2021 г., https://www.mckinsey.com/capabilities/mckinsey-digital/ our-insights/seven-lessons-on-how-technology-transformations- can-deliver-value.

Аарон Бауком, Себастьян Бекерра, Бо Беннетт и Билл Грегг, "Основы облачных технологий: Десять заповедей для более быстрой - и более прибыльной - миграции в облако", McKinsey.com, 21 апреля 2022 г., https://www.

.mckinsey.com/capabilities/mckinsey-digital/our-insights/ cloud-foundations-ten-commandments-for-faster-and-more-profitable- cloud-migrations.

Глава 19.

Инженерные практики для обеспечения скорости и высокого уровня кода качества

Инженеры воплощают мечты в реальность.

-Хаяо Миядзаки

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

Жизненный цикл разработки программного обеспечения (SDLC)

РАЗВИТИЕ

ПРОДУКЦИЯ

Непрерывная интеграция Непрерывная

развертывание

Код

Построить

Пакет

Обратная связь

Работайте на сайте

Тест

Развернуть

ПРИЛОЖЕНИЕ 19.1

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

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

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

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

Основание для быстрой доставки программного обеспечения в DevOps

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

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

Поток. Ускорьте процесс передачи результатов разработки, чтобы они быстро и эффективно попадали в руки пользователей. Начните с составления карты потока создания ценности в рамках SDLC, то есть с того, какие этапы включает в себя кодирование, сборка, тестирование, упаковка и развертывание программного обеспечения в среде. Изначально это ручной процесс. Затем определите время, которое требуется между этапами, и все ручные процессы, которым следуют инженеры в ходе SDLC. Например, можно определить, что инженерам в agile pod приходится просить другую команду, чтобы выполнить определенную работу от их имени. Наконец, систематически сокращайте или удаляйте все выявленные ручные шаги путем автоматического спаривания (см. ниже о CI/CD). Начните с тех этапов, которые больше всего отнимают времени, чтобы расставить приоритеты.

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

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

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

Заложив прочный фундамент DevOps, компании распространяют эти возможности на другие практики разработки кода, такие как DevSec- Ops, MLOps и DataOps (см. Рисунок 19.2). Суть этих возможностей заключается в постоянном продвижении автоматизации, машинного обучения и задач управления данными для увеличения скорости разработки, повышения безопасности и снижения затрат.

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

MLOps основан на DevOps, но для моделей машинного обучения (ML) и искусственного интеллекта. Любая компания, которая пытается разрабатывать, поддерживать и улучшать сотни моделей ML/AI в производстве, понимает, насколько сложно обеспечить стабильность и точность моделей прогнозирования, а также их калибровку в условиях изменяющейся среды данных. Именно здесь на помощь приходит MLOps. Мы подробно рассмотрим MLOps в главе 23.

Семейство практик xOps

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

Обеспечьте среду (среды) "песочницы" для исследований и экспериментов

Обеспечьте стабильную среду 24 часа в сутки,

7 дней в неделю,

52 недели/год

Обеспечивает доступ к данным как на платформах разработки, так и на производственных платформах

MLOps

DevOps/DevSecOps

DataOps

ДАННОЕ ОЗЕРО

ПРОДУКЦИЯ

РАЗВИТИЕ

DevOps/DevSecOps

Ускорьте безопасную доставку новых функций с момента разработки до

конечные пользователи

MLOps

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

DataOps

Ускорение процесса создания новых информационных ресурсов за счет автоматизации качества и надежности данных

ПРИЛОЖЕНИЕ 19.2

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

Повышение качества благодаря стандартам кодирования и удобству сопровождения кода

По мере роста числа agile-подразделений и увеличения объема генерируемого ими кода - типичное приложение для смартфона содержит 50 000 строк кода организациям стало необходимо уделять особое внимание стандартам кода. Генеральный директор компании по производству электромобилей включает качество кода в свою приборную панель.

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

Технический долг: Что это такое и как его измерить

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

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

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

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

Мы обнаружили, что компании, находящиеся в 80-м процентиле по уровню поддержания технического долга на низком уровне, имеют рост доходов на 20 % выше, чем компании, находящиеся в 20-м процентиле.

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

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

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

Системы контроля версий включают Git, CVS, SVN и многие другие. Эти системы также предоставляют такие важные возможности, как аудит кода, и позволяют agile-подразделениям внимательно изучать, как уязвимости могли попасть в систему, и вносить необходимые исправления.

Решите, какую программную основу использовать

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

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

Обеспечьте последовательность в написании кода

Линтер кода - это инструмент статического анализа кода, используемый для выявления ошибок программирования, багов, стилистических ошибок и подозрительных конструкций. Различные языки кода часто имеют свои собственные инструменты (Super Linter на GitHub поддерживает несколько языков). Например, для языка программирования Python есть такие инструменты, как Pylint, а для языка программирования JavaScript - JSLint. Эти инструменты могут запускаться agile-подразделениями для проверки соответствия создаваемого ими кода единым стандартам качества.

Определитесь с фреймворком тестирования для проверки кода

Agile-подразделения используют тестовый фреймворк для написания модульных тестов для кода, который они пишут. Различные языки программирования поддерживают свои собственные тестовые фреймворки: в языке Python есть pytest или unittest, а в языке программирования JavaScript - Jest. Независимо от выбранного тестового фреймворка (их существует множество), ключевым моментом является стандартизация фреймворка и обеспечение того, чтобы все подгруппы использовали его.

Существуют различные типы тестирования, которые пишут инженеры в agile pods (см. Рисунок 19.3).

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

Минимизация сложности кода

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

Стратегии тестирования - определения

Тестирование на проникновение

Регрессионное тестирование

Проверка устойчивости приложения к кибернетическим атакам

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

Увеличение стоимости и времени тестирования

Тестирование производительности/нагрузки

Приемочное тестирование

Сплошное тестирование (системы)

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

Обеспечивает корректную работу приложения с точки зрения пользователя

Убедитесь, что все приложение в целом ведет себя так, как ожидается

Интеграционное тестирование

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

Модульное тестирование

Тестирует отдельные блоки (модули, функции, классы) в изоляции от остальной части приложения

ПРИЛОЖЕНИЕ 19.3

Автоматизируйте создание документов для обеспечения соответствия нормативным требованиям

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

Генерировать документацию из кода предпочтительнее, чем заставлять разработчиков писать ее вручную, поскольку это более эффективно по времени и более точно (хотя разработчику все равно придется подтверждать, что документация точна на 100 %). В некоторых отраслях такая документация может помочь соблюдению нормативных требований и регуляторам "подписать" то, что выпускается в производство.

Обеспечьте сквозную автоматизацию с помощью непрерывной интеграции и непрерывного развертывания (CI/CD)

По мере усложнения программного обеспечения простые на первый взгляд изменения могут привести к непредвиденным побочным эффектам. Сложность может возрастать, когда над одним и тем же программным обеспечением работают несколько разработчиков из разных команд. Непрерывная интеграция/непрерывное развертывание (CI/CD) - это подход, который решает эту проблему. Вот краткий обзор процесса CI/CD (пример см. в Примеч. 19.4):

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

В одной глобальной фармацевтической компании agile-подразделение, разрабатывающее новую функциональность API, выбрало CircleCI в качестве инструмента CI. Жизненный цикл кода описан ниже:

Инженеры, работающие по принципу agile pod, вносили изменения в код, которые затем сохранялись в GitHub (система контроля версий).

CircleCI обнаруживает изменения кода, внесенные в систему контроля версий.

CircleCI проверяет соответствие кода стандартам, запуская Pylint (инструмент для линтинга).

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

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

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

CircleCI упаковывает пройденный код в модульный строительный блок, который хранится в репозитории пакетов - в данном случае пакет хранится в контейнере (Docker) и хранится в Amazon ECR (хранилище образов Docker, управляемое Amazon). Контейнеры позволяют запускать приложения в любой среде, однако использовать их следует с умом.

Конвейер кода Python - непрерывная интеграция и развертывание - пример

КОД

Python

GitHub

1

2 CircleCI Обнаружение изменений в коде

3 Pylint Проверка соответствия кода стандартам

4 Pytest Проверьте поведение кода, запустив тест

5 SonarQube Проверка качества кода

6 Sphinx Автогенерация документации

7 Docker Код упаковывается и хранится в репозитории

Amazon ECR

8 Selenium Запуск интеграционных тестов

Инженеры вносят изменения в код

Контроль исходных текстов/сохранение кода

НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ

НЕПРЕРЫВНОЕ РАЗВЁРТЫВАНИЕ

ПРИЛОЖЕНИЕ 19.4

3 Argo Обнаружение изменений в коде

4 Checkmarx Проверка на наличие уязвимостей

5 Argo Скопируйте образ Docker на производственную платформу Kubernetes

6 Kurbenetes Представьте в виде API для тестирования поведения кода

7 Selenium Убедитесь, что API работает

8 Kurbenetes Активируйте API для пользователей

Затем CircleCI проводит интеграционные тесты, проверяя, работает ли новый модульный блок при интеграции со всем остальным программным обеспечением и любыми другими изменениями, внесенными другими членами команды - в данном случае с помощью Selenium (инструмента автоматизации веб-программ с открытым исходным кодом для автоматического написания тестов).

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

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

Фармацевтическая компания, о которой шла речь выше, выбрала инструмент Argo CD для развертывания в производстве (кластер Kubernetes). Процесс компании включал в себя следующие шаги (см. рисунок 19.4. Обратите внимание, что следующее перечисление отличается от приведенного на рисунке для наглядности).

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

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

Затем Argo CD копирует с Amazon ECR образ Docker на производственную платформу Kubernetes. Платформа Kubernetes упрощает управление контейнерами и делает приложения более переносимыми.

Затем Argo CD гарантирует, что у этого нового контейнера есть частный API, который можно использовать для проверки правильности поведения пакета.

Argo CD запрашивает Selenium (инструмент тестирования) для проверки правильности поведения API.

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

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

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

Примечания

Чандра Гнанасамбандам, Джанаки Паланиаппан и Джереми Шнайдер, "Каждая компания - это софтверная компания: Шесть "обязательных условий" для достижения успеха", McKinsey.com, 13 декабря 2022 г., https://www.mckinsey. com/capabilities/mckinsey-digital/our-insights/every-company-is-a- software-company-six-must-dos-to-succeed.

Оливер Боссерт, Крис Ип и Ирина Старикова, "Beyond agile: Reorganizing IT for faster software delivery", McKinsey.com, 1 сентября 2015 г., https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ beyond-agile-reorganizing-it-for-faster-software-delivery.

Сантьяго Комелла-Дорда, Джеймс Каплан, Линг Лау и Ник Макнамара, "Проворные, надежные, безопасные, отвечающие требованиям ИТ: Выполнение обещания DevSecOps", McKinsey.com, 21 мая 2020 г., https://www.mckinsey. com/capabilities/mckinsey-digital/our-insights/agile-reliable-secure- compliant-it-fulfilling-the-promise-of-devsecops.

Вишал Далал, Криш Кришнакантан, Бьорн Мюнстерманн и Роб Патенге, "Технологический долг: Восстановление технологического капитала", McKinsey.com, 6 октября 2020 г., https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ tech-debt-reclaiming-tech-equity.

Глава 20.

Инструменты для повышения квалификации ваших разработчиков

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

ожидали.

-Билл Гейтс

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

По мере масштабирования организации и перехода от пяти agile-подразделений к 20, 100 или даже 1 000+ подразделениям разработки следует переходить к средам самообслуживания (sandbox), которые самомасштабируются и предоставляют все современные и стандартизированные инструменты, необходимые agile-подразделениям для разработки решений. Это позволит избежать необходимости нагружать ИТ-отдел запросами на предоставление инфраструктуры и инструментов, а командам разрабатывать код, который будет работать в производственной среде.

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

По их словам: Пересмотр способов создания сервисов в облаке

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

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

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

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

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

Для этого мы полностью прекратили работу нашей команды по созданию облачной инфраструктуры и привлекли владельца продукта, который в партнерстве с нами полностью изменил наше представление об облаке. Затем мы переобучили персонал, ориентируясь на концепцию создания продукта, который разработчики приложений могли бы получать и использовать в режиме самообслуживания, а не просто создавать инфраструктуру. Конечный продукт, Atlas, позволяет команде разработчиков приложений начать работу с извлечения кода в конвейер непрерывной интеграции и непрерывного развертывания (CI/CD). Он сам себя обеспечивает.

-Мартин Кристофер, бывший старший вице-президент и директор по информационным технологиям CUNA Mutual Group

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

Гибкие и масштабируемые песочницы разработки

Раньше на запрос, создание и доступ к среде разработки у команды уходили недели, а иногда и месяцы. Теперь это уже не так. Среды разработки, или "песочницы", могут быть созданы за несколько минут или максимум часов с помощью автоматизации инфраструктуры как кода (IaC). Это быстро позволяет agile-подразделениям создавать свои собственные "песочницы" разработки (см. Рисунок 20.1). Каждая команда получает свою собственную "песочницу" в рамках более широкой облачной среды со стандартизированными инструментами, выделенной памятью и вычислительными возможностями, а также доступом к данным (либо тестовым данным, которые копируются автоматически, либо, в некоторых случаях, доступом к подмножеству производственных данных).

Пример платформы для разработчиков

Создайте командную атмосферу для под

Доступ к панели управления песочницы

Доступ

Все инструменты доступны через один верстак

Упрощение применения в строительстве

Облегчение выполнения общих действий из рабочего стола (без необходимости быть экспертом непосредственно в базовых инструментах)

Расширяемый

Со временем возможно добавление новых инструментов/функций

Портал для разработчиков

Agile Pod

(100% автоматизация)

1a

Создайте песочницу

2a

Открытие/доступ к данным

1b

Развертывание готовых шаблонов

2b

Инструменты для написания кода

1c

Настройте контроль исходных текстов

2c

Поиск существующего кода

1d

Настройка CI

2d

Эксперименты на дорожках

1e

Настройте инструменты для совместной работы

2e

Код сборки

1f

Автоматизируйте сканирование системы безопасности

2f

Опубликовать

2g

Монитор

2h

...

ПРИЛОЖЕНИЕ 20.1

Запуск сценариев IaC, способных создавать такие среды за секунды или минуты, может показаться некоторым инженерам несколько пугающим. А что, если в этих сценариях есть элементы, которые вы хотите, чтобы команды могли контролировать, например память, вычисления или даже приложения для предварительной загрузки? Разработка эффективной возможности самообслуживания в песочнице, способной удовлетворить множество потребностей, привела к появлению внутренних платформ разработчика (IDP) - легкого слоя пользовательского интерфейса (UI), который абстрагирует все сложности обеспечения инфраструктуры, безопасности и инструментов, но при этом предоставляет единый пользовательский интерфейс (UX) для настройки этих сред.

Пример из практики: Spotify решает проблему производительности разработчиков

По мере того как Spotify расширялась до множества agile-подразделений, а используемые компанией технологии становились все сложнее, выяснилось, что не все ее инженеры хорошо разбираются в этих технологиях, таких как Terraform для инфраструктуры, GCP/AWS/Azure CLI для различных облачных провайдеров, GitLab CI для контроля версий, Prometheus для мониторинга, Kubernetes и Docker для контейнеров и многие другие инструменты. Все усложнялось тем, что разным agile-подразделениям требовались разные инструменты для разработки внутренних API, внешних мобильных приложений и т. д.

Чтобы решить эту проблему, Spotify создала UX-инструмент под названием Backstage (который впоследствии был открыт). Backstage избавил инженеров от необходимости изучать огромное количество технологий и инструментов. Вместо этого инженеры могли нажать одну кнопку на простом веб-портале, чтобы добавить больше вычислительных мощностей на машину, над которой они работали, или получить доступ к журналам отладки. Со временем Spotify добавила дополнительные функции, чтобы помочь agile-командам обнаружить библиотеки, приложения и сервисы, разработанные другими agile-подразделениями, и дать им возможность двигаться быстрее - и все это на едином портале, что упрощает и улучшает работу разработчиков.

В нашей компании команда разработчиков платформы создала индивидуальный, легкий, самообслуживающийся веб-портал для разработчиков под названием Platform McKinsey, чтобы дать возможность сотням agile-команд McKinsey создавать цифровые и искусственные продукты, не заботясь о базовой инфраструктуре или инструментах. Веб-портал выполняет две задачи (см. Рисунок 20.1):

Действует по запросу команды на создание среды "песочницы", автоматически выполняя следующие действия:

Создайте "песочницу" с правильным контролем доступа для членов команды и правильными инструментами.

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

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

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

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

Инструменты для обнаружения и доступа к данным

Инструменты для написания кода

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

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

Инструменты для просмотра статуса CI-сборки (например, повлияли ли изменения кода на качество продукта в целом?)

Простой способ публикации кода в продакшн одним нажатием кнопки

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

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

Современная и стандартизированная оснастка

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

Существует пять основных категорий инструментов, связанных с разработкой, которые важны для любого agile-команды, разрабатывающей цифровые решения. Следует отметить, что выбор инструментов в первых двух категориях во многом зависит от того, какой продукт создает agile pod (например, front-end, back-end, API, data-pipeline или модель).

Инструменты разработчика. Это инструменты, используемые для экспериментов и создания кода, к которым также относятся интегрированные среды разработки (IDE). Набор инструментов зависит от языка (например, Python, R, JavaScript и т. д.). Хорошие инструменты разработчика обеспечивают проверку синтаксиса и валидацию кода, а также позволяют нескольким инженерам сотрудничать и работать над одним и тем же файлом в одно и то же время.

Инструменты для упаковки программного обеспечения (для производства). Для рабочего решения, которое должно упаковывать несколько блоков кода, например, webpack, который упаковывает js, css и html, этот код должен быть связан с другими версиями другого кода вокруг него и другими зависимостями. Это позволяет разработчикам лучше модулировать программное обеспечение и легче выпускать обновления.

Инструменты для хранения пакетов. Это инструменты для хранения пакетов кода. Такие инструменты, как Nexus, Docker Hub и JFrog Artifactory, позволяют хранить пакеты, готовые к производству.

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

Инструменты мониторинга. Среды песочницы необходимо контролировать, чтобы убедиться, что они работают должным образом и не сжигают деньги (например, многие инструменты лицензированы без пользователей, или люди используют инфраструктуру для добычи биткоина без выходных - да, такое случается). Примерами таких инструментов являются Grafana и Graphite.

Команда разработчиков платформы предоставляет набор стандартизированных общих инструментов, которыми могут воспользоваться все песочницы. Некоторые разработчики предпочитают выбирать те инструменты, с которыми им удобно работать. Организациям следует придерживаться подхода core/common/custom, то есть определить, что является "ядром", от которого нельзя отступать; что является "общим", то есть необязательным для использования и предоставляется всем; а что является "пользовательским", которое приобретается/загружается/устанавливается для конкретного пользователя или группы. Последнее следует делать только в том случае, если от этого есть реальная польза для бизнеса.

Глава 21. Цифровые решения производственного уровня

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

-Кэрролл Смит

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

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

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

Стремитесь к высокой степени контроля и проверяемости

Учитывая, что производственная среда обслуживает критически важные для бизнеса приложения, необходима высокая степень контроля и проверяемости. Это необходимо не только для обеспечения надежности, но и для соответствия требованиям, например, SOC 2, ISO 27001, PCI и т. д. Эти возможности должны быть сосредоточены в двух областях (см. Рисунок 21.1):

Сама производственная среда, в частности то, как она была настроена, какие политики безопасности были применены, какие (ограниченные) пользователи имеют доступ, какой входящий (ingress) доступ разрешен, какой исходящий (egress) доступ разрешен и т. д. Указывая эти производственные задачи в сценариях IaC и сохраняя их в системе контроля версий, организации могут получить полную видимость и возможность аудита изменений, вносимых в среду. Изменения в среде могут вноситься только командой инженеров платформы и только с использованием CI/CD.

Что выполняется в среде, в частности, как планируется запуск развернутого приложения или API, кто может его развернуть и т. д. Agile pods применяют непрерывное развертывание, чтобы гарантировать, что то, что попадает в производство, поддается аудиту и легко обратимо. Благодаря тому, что все состояние среды задается в виде кода внутри

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

Контроль и возможность аудита производственной среды

CI/CD

ПРОИЗВОДСТВЕННАЯ СРЕДА

Въезд/выезд

Контроль доступа

Политики безопасности

Конфигурация

Контроль версий

Цифровое решение

ПРИЛОЖЕНИЕ 21.1

Обеспечьте безопасность, масштабируемость и доступность среды.

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

Безопасность. Большинство данных, которые хранятся или передаются в среде про- дукции, должны быть зашифрованы. Шифрование гарантирует, что только авторизованные пользователи или приложения могут получить доступ к данным с помощью ключа. Поставщики облачных услуг предоставляют управляемые сервисы для управления ключами, например AWS Key Management Service, Azure Key Vault или Google Cloud Key Management Service.

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

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

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

Включить мониторинг и наблюдаемость

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

Мониторинг приложений. Решения, которые разрабатывают agile pods, нуждаются в мониторинге для обеспечения надежности, а также для сбора обратной связи и телеметрии о том, как бизнес-пользователи взаимодействуют с решением. Обычно используются такие инструменты, как Datadog, New Relic или Dynatrace.

Мониторинг облаков и инфраструктуры. Сюда входит информация о том, какие данные поступают в ваше облако, кто его использует и какова производительность. Для этого можно использовать такие инструменты, как New Relic или Zabbix. Например, если вы используете традиционные виртуальные серверы в облаке, то понимание их поведения и нагрузки очень важно, особенно при диагностике проблем с производительностью приложений. Виртуальные серверы обычно имеют фиксированный размер, поэтому скачки нагрузки могут повлиять на производительность и скорость отклика для конечных пользователей. Мониторинг надежности потока данных и их качества - менее развитая область. Помимо упомянутых ранее инструментов, существуют и другие, например, инструменты мониторинга в Azure Data Factory, которые позволяют следить за поступлением данных.

Обратите внимание, что не существует единого инструмента мониторинга, который позволил бы организациям понять сквозной поток информации. Для целей производства команда разработчиков платформы должна определить, какие инструменты ей нужны, чтобы не только обеспечить надежность среды, но и быстро диагностировать проблемы, если они возникнут. На рис. 21.2 показана панель мониторинга производительности для решений McKinsey по аналитике корпоративных финансов. Эти решения доступны клиентам через веб-интерфейс или API.

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

Образец панели мониторинга для цифрового решения

30

15K

0

0

0K

5pm

7 вечера

9 вечера

5pm

7 вечера

9 вечера

11 вечера

5pm

7 вечера

9 вечера

11 вечера

ТРЕУГОЛЬНИК

30K

ФИЗИЧЕСКАЯ ПАМЯТЬ

60

ЗАГРУЗКА ПРОЦЕССОРА

9

6

3

ОБЗОР VM 1/31-2/7

20.7 61.5

Avg. CPUОбщее физическое использование память

Февраль 7 Февраль 8 Февраль 9 Февраль 10 Февраль 11 Февраль 12 Февраль 13

ОПЕРАЦИИ ПО ДНЯМ

ПОСЛЕДНЯЯ ОШИБКА

С 1 недели назад

О сайте

5 часов назад

TOP FAILED TRANSACTIONS Since 1 week ago

WebTransaction/Go/POST/run_binary 0.36%

WebTransaction/Go/POST/run/:section/:template 0.13%

WebTransaction/Go/POST/calculate 0.049%

WebTransaction/Go/POST/calculate/batched 0.012%

1.56 k

Неудачные транзакции

ОБЗОР ОШИБОК С 1 недели назад

0.017%

Неудачные транзакции в %

11 вечера

9 вечера

5pm 7 вечера

Продолжительность Предыдущая продолжительность

ОЦЕНКА ADPEX СЕГОДНЯ ПО СРАВНЕНИЮ С 1 НЕДЕЛЕЙ НАЗАД

С 7 часов назад по сравнению с 1 неделей назад

1.0

0.5

0

0.211

Самые медленные 10%/

продолжительность (90%)

ПРИБОРНАЯ ПАНЕЛЬ ПРИЛОЖЕНИЯ CPAT

ОБЗОР ТРАНЗАКЦИЙ С 1 недели назад

9.43M 0.124

Всего Среднее

транзакции продолжительность

САМЫЕ ПОПУЛЯРНЫЕ ОПЕРАЦИИ

WebTransaction/Go/POST/Calculate 2.74M Webtransaction/Go/POST/data 2.74M Webtransaction/Go/POST/batchgeo 1.05M Webtransaction/Go/GET/curencies 42.8K

ПРИЛОЖЕНИЕ 21.2

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

Глава 22. С самого начала создайте

для обеспечения безопасности и автоматизации

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

-Клиффорд Столл

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

Сдвиг влево в вопросах безопасности

"Сдвиг влево по безопасности" - это движение индустрии программного обеспечения, направленное на внедрение безопасности на более ранних этапах SDLC, а не на последнем (см. Рисунок 22.1). Этому есть два обоснования.

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

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

Этот переход начинается с составления схемы ручного контроля и процессов управления, используемых для управления рисками и безопасностью на протяжении всего SDLC - как для инфраструктуры, так и для приложений. Сюда же относятся все обзоры рисков и безопасности. Как только это будет сделано, ищите инструменты и технологии, которые можно использовать для минимизации или устранения ручного (человеческого) контроля. Например, использование IaC (которые хранятся в системе контроля исходных текстов) дает дополнительное преимущество - возможность использовать инструменты для анализа уязвимостей безопасности или неправильной конфигурации до того, как они будут использованы другими командами. Статический анализ кода на IaC может гарантировать отсутствие уязвимостей в коде инфраструктуры (например, tfsec, checkov). Аналогично, многие команды используют модульные и многократно используемые компоненты с открытым исходным кодом для создания этих решений. Хотя открытый исходный код имеет много преимуществ, он также может создавать уязвимости безопасности, которые могут быть встроены в эти цифровые решения. Вы можете выявить и устранить эти уязвимые компоненты на ранних этапах SDLC с помощью таких инструментов, как Synk.

Повышение безопасности путем "сдвига влево"

От: Оставляем безопасность напоследок - Проверка безопасности после развертывания программного обеспечения

Тест

Пакет

Построить

Развернуть

Безопасность

Работайте на сайте

Код

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

Для: "Смещение влево" в вопросах безопасности - проверки и процедуры безопасности включены в каждый этап SDLC

Безопасность

Развернуть

Работайте на сайте

Тест

Безопасность

Безопасность

Пакет

Безопасность

Безопасность

Построить

Код

Заблаговременное устранение последствий может помочь избежать катастрофических проблем в дальнейшем

ПРИЛОЖЕНИЕ 22.1

Внедрение безопасности в SDLC с помощью DevSecOps

Реализация подхода "сдвиг влево" требует DevSecOps, который встраивает безопасность в подход DevOps. Это означает интеграцию экспертов по безопасности в команды DevOps и внедрение средств обеспечения безопасности на протяжении всего процесса SDLC. Автоматизация - один из основных принципов этого подхода. В рамках одного и того же сквозного процесса CI/CD команда разработчиков платформы внедряет инструменты для проверки и устранения рисков безопасности (см. Рисунок 22.2). Цель состоит в том, чтобы со временем перейти к 100 % автоматизации проверок безопасности.

Внедрение DevSecOps в процесс доставки

Примеры тестирования безопасности, выполняемого в течение всего жизненного цикла разработки программного обеспечения

Непрерывная интеграция и непрерывная доставка

Код Build

Тест Пакет

Развернуть Эксплуатировать

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

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

Проверка уязвимостей в технологии упаковки перед развертыванием на производстве

Проведение динамического тестирования безопасности приложений для обнаружения уязвимостей в создаваемых приложениях

Устранение уязвимостей в компонентах сторонних разработчиков с помощью анализа компонентов программного обеспечения

Запустите Runtime Application Security Protection для выявления угроз во время выполнения и отслеживания необычного поведения приложений.

ПРИЛОЖЕНИЕ 22.2

Реализация проверок безопасности в CI/CD:

Код

С помощью таких инструментов, как Synk, проверьте, не были ли установлены разработчиками вредоносные плагины интегрированной среды разработки (IDE), которые вносят уязвимости в код. Проверьте, не хранятся ли в системе контроля исходных текстов секреты (например, с помощью git-секретов от AWS или встроенных инструментов проверки секретов, которые есть в некоторых системах контроля исходных текстов, например, сканирование секретов GitHub). Наконец, запустите статическое тестирование безопасности приложений (SAST), которое анализирует написанный код. Это зависит от языка; для IaC можно использовать инструмент типа tfsec, а для кода на Python - инструмент типа semgrep.

Построить

Проведите динамическое тестирование безопасности приложений (DAST), которое ищет уязвимости в создаваемых приложениях. Для этого можно использовать такие инструменты, как appcheck или инструмент OWASP Zed Attack Proxy с открытым исходным кодом. Проведите интерактивное тестирование безопасности приложений (IAST), которое ищет уязвимости во время работы цифрового приложения. Для этого можно использовать такие инструменты, как Synopsys или Veracode.

Тест

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

Пакет

Убедитесь, что уязвимые компоненты сторонних разработчиков не были внедрены, используя анализ компонентов программного обеспечения (SCA).

Развернуть

Проверьте все уязвимости, которые могли быть устранены до развертывания в производстве. Это может быть технология упаковки (например, Docker) или поиск внутри пакета с помощью SCA.

Работайте на сайте

Запустите защиту безопасности приложений во время выполнения (RASP), которая ищет внутренние данные цифрового приложения, чтобы идентифицировать угрозы во время выполнения. Отслеживайте необычное поведение приложений с помощью традиционных инструментов мониторинга/наблюдения, таких как Datadog.

По их словам: Правильное мышление и сдвиг влево

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

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

Кейси Сантос, ИТ-директор Asurion

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

Примечания

Арул Элумалай, Джеймс Каплан, Майк Ньюборн и Роджер Робертс, "Обеспечение безопасного перехода к публичному облаку", McKinsey.com, 1 января 2018 г., https://www.mckinsey.com/capabilities/mckinsey- digital/our-insights/making-a-secure-transition-to-the-public-cloud.

Джим Боэм, Чарли Льюис, Кэтлин Ли, Дэниел Уолланс и Деннис Диас, "Тенденции кибербезопасности: Заглядывая за горизонт", McKinsey

.com, 10 марта 2022 г., https://www.mckinsey.com/capabilities/risk- and-resilience/our-insights/cybersecurity/cybersecurity-trends-looking-over-the-horizon.

Глава 23.

MLOps

, чтобы ИИ мог масштабироваться

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

-Яан Таллинн

Для того чтобы AI/ML внес значительный вклад в итоговый результат компании, организации должны масштабировать технологию по всей организации, внедряя ее в основные бизнес-процессы, рабочие процессы и путешествия клиентов для оптимизации принятия решений и операций в режиме реального времени. Это особенно сложно в случае с моделями AI/ML, поскольку они представляют собой "живые организмы", которые меняются вместе с базовыми данными. Они требуют постоянного мониторинга, переобучения и дебилизации, что является сложной задачей даже для нескольких ML-моделей, но просто непреодолимой для сотен.

Определение ключевых терминов

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

Машинное обучение (ML) - это подмножество искусственного интеллекта. Это метод, который "учится" на данных, чтобы повысить эффективность выполнения некоторого набора задач.

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

В последние годы масштабное совершенствование инструментов и технологий ML значительно изменило рабочие процессы ML, ускорило жизненный цикл приложений и позволило последовательно и надежно масштабировать AI в бизнес-области. Однако, несмотря на все эти новые возможности, необходимо помнить, что эффективная работа с ML (MLOps) требует сосредоточения на всем комплексе работ по разработке приложений, а не только на самих моделях. По нашим оценкам, до 90 % неудач в разработке ML связаны не с разработкой плохих моделей, а с неэффективной практикой продуктивизации и проблемами интеграции модели с производственными данными и бизнес-приложениями, которые не позволяют модели масштабироваться и работать как положено. Эффективная продуктизация требует разработки интегрированного набора компонентов для поддержки модели (или, зачастую, набора моделей), таких как активы данных, алгоритмы ML, программное обеспечение и пользовательский интерфейс.

MLOps - это набор практик, которые применяются на протяжении всего жизненного цикла модели ML (см. Рисунок 23.1):

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

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

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

Разработка и масштабирование: Усовершенствование компонентов обработки данных и обучения моделей для работы в масштабе, включая добавление тестов, проверку, безопасность, CI/CD и переобучение моделей.

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

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

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

Обеспечение доступности, качества и контроля данных для питания системы ML

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

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

Жизненный цикл модели AI/ML

Импорт соответствующих наборов данных (извлечение из общих данных) Понимание структуры и статистики данных

Очистка и дезинфекция

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

Перекрестные связи между признаками и корреляционный анализ Создание прототипов моделей и оценка важности признаков

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

Интеграция с API и источниками данных в режиме реального времени Предварительная обработка и обогащение данных

Прогнозирование модели Постобработка

Начало действий или ответных мер

Автомасштабирование

Контейнеризация моделей

Добавление фреймворков автоматизации

Мониторинг

Сопровождение модели Валидация производительности Непрерывное совершенствование Поддержка пользователей

Операции в реальном времени

Обратная связь

Модель данных и конвейеры

Разработка модели

Данные

Производство и масштабирование

ПРИЛОЖЕНИЕ 23.1

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

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

Предоставление инструментария для оптимизации разработки ОД

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

Специалисты по исследованию данных любят экспериментировать, пробуя различные данные/функции и различные алгоритмы, чтобы разработать модель, удовлетворяющую бизнес-результатам. Эти эксперименты необходимо где-то хранить вместе с любыми связанными с ними метаданными (например, использованные функции или дополнительные конфигурации модели). Такие инструменты, как MLflow и MLRun, обеспечивают управление моделью и возможность воспроизведения этих экспериментов, а также отслеживают, какие эксперименты привели к лучшему бизнес-результату.

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

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

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

Мониторинг производительности модели для постоянного совершенствования

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

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

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

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

Пример из практики: Сокращение времени разработки приложений ИИ

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

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

Примечание

1. Джакомо Корбо, Дэвид Харви, Найюр Хан, Николас Хон, Киа и Джаванмардиан, "Масштабирование ИИ как технарь: Роль генерального директора", McKinsey

.com, 13 октября 2021 г., https://www.mckinsey.com/capabilities/ quantumblack/our-insights/scaling-ai-like-a-tech-native-the-ceos-role.

Раздел 4

Ниже приведен набор вопросов, которые помогут вам определить, какие действия следует предпринять:

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

Сколько компаний могут разрабатывать и непосредственно выпускать новые версии своих цифровых решений для клиентов/пользователей?

Каково время цикла выпуска (и уверены ли вы, что измеряете его правильно)?

Как узнать, что вы строите хорошо/ответственно, а не просто быстро?

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

Какая часть ваших инженерных разработок использует подход непрерывной интеграции/непрерывной доставки?

Какова доля ваших рабочих нагрузок в облаке и какой должна быть цель?

Насколько хорошо функция безопасности интегрирована в процесс разработки и автоматизирована?

Хорошо ли откалиброваны ваши модели AI/ML, находящиеся в производстве? Как вы узнали об этом?

Встраивание данных

Везде

Что нужно, чтобы сделать данные удобными для использования в организации

В крупных компаниях данные часто становятся источником разочарования. По нашему опыту, до 70 % усилий по разработке решений на основе искусственного интеллекта приходится на работу с данными и их согласование. Многие из этих проблем могут быть связаны с унаследованными, изолированными друг от друга системами, поэтому очень важно продумать архитектуру данных для удобства их потребления и повторного использования; в противном случае масштабирование становится проблематичным. Цель состоит в том, чтобы иметь чистые, актуальные и доступные данные, чтобы agile pods могли использовать их для принятия лучших решений и создания лучших решений на основе данных.

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

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

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

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

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

Глава 26: Архитектура данных, или система "труб" данных. При построении целевой архитектуры данных учитывайте потребности вашей организации как в BI (бизнес-аналитике), так и в AI (искусственном интеллекте). Используйте существующие эталонные архитектуры, чтобы снизить сложность реализации.

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

Примечания

Вирал Десаи, Тим Фаунтейн и Кайваун Роушанкиш, "Как раскрыть всю ценность данных? Управляйте ими как продуктом", McKinsey.com, 14 июня 2022 года, https://www.mckinsey.com/capabilities/quantumblack/our-insights/ how-to-unlock-the-full-value-of-data-manage-it-like-a-product.

Верал Десаи, Тим Фаунтейн и Кайбаун Роушанкиш, "Лучший способ заставить ваши данные работать", Harvard Business Review, июль-август 2022 года, https://hbr.org/2022/07/a-better-way-to-put-your-data-to-work; "Предприятие 2025 года, управляемое данными: Семь характеристик, определяющих новое предприятие, управляемое данными", McKinsey.com, 28 января 2022 г., https://www.mckinsey.com/capabilities/quantumblack/our-insights/ the-data-driven-enterprise-of-2025?linkId=150307929.

Определите, какие данные важны

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

Определение и приоритизация данных

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

Определение ключевых терминов

Элемент данных: Базовая единица информации, имеющая уникальное значение, например, имя клиента, адрес клиента, название продукта, дата.

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

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

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

Такая расстановка приоритетов должна распространяться и на элементы данных в каждом домене данных, чтобы определить, что имеет наибольшее значение. Например, в домене данных о клиенте могут быть сотни или тысячи элементов данных, таких как имя, адрес и номер кредитной карты. Определите элементы, которые наиболее важны для реализации сценария использования (обычно это ~10-15 % всех элементов данных), и сосредоточьте на них большую часть своих усилий. Для одной американской страховой компании, желающей предложить своим клиентам рекомендации по усиленной защите имущества, процесс расстановки приоритетов означал сосредоточение внимания на данных о катастрофах и безопасности (например, данные о риске бедствий, полученные от Национального управления океанических и атмосферных исследований, Геологической службы США и Федерального агентства по управлению чрезвычайными ситуациями), а также на данных о рынке активов, таких как исторические цены на недвижимость, история покупок и индексы района (см. Рисунок 24.1).