WEBVTT

00:00:00.000 --> 00:00:04.120
Добро пожаловать в очередной выпуск микрознаний от Microsoft на М365FM.

00:00:04.260 --> 00:00:05.780
Ваш ведущий – Мирку Петтерс.

00:00:05.980 --> 00:00:10.500
Сегодняшняя тема знакома почти всем, но мало кто понимает ее до конца – платформенная инженерия.

00:00:10.660 --> 00:00:17.220
Вы наверняка слышали о DevOps, идее о том, что разработчики и операционные команды работают вместе без швов, но в какой-то момент все пошло не так.

00:00:17.380 --> 00:00:20.560
Разработчики начали выполнять работу сисадминов, и эта система сломалась.

00:00:20.720 --> 00:00:26.900
К концу выпуска вы поймете, что пошло не так с DevOps, что такое внутренняя платформа разработчика, как «золотые пути»,

00:00:26.900 --> 00:00:30.820
упрощают работу командам и почему лучшие инженерные коллективы уже внедряют их.

00:00:31.060 --> 00:00:32.920
Беспорядок, оставшийся после DevOps.

00:00:33.120 --> 00:00:34.460
Давайте вернемся к истокам.

00:00:34.600 --> 00:00:38.720
DevOps был отличной идеей с простой целью – разрушить барьеры между разработкой и эксплуатацией.

00:00:38.900 --> 00:00:41.480
Больше никакой передачи кода через забор в надежде на лучшее.

00:00:41.640 --> 00:00:45.060
Сдвиг влево, перенос нестеравания, безопасности и операции на более ранние этапы процесса.

00:00:45.200 --> 00:00:48.160
Более быстрая поставка, меньше передач задач, больше личной ответственности.

00:00:48.300 --> 00:00:49.780
На бумаге все выглядело идеально.

00:00:49.960 --> 00:00:51.460
На практике что-то пошло не так.

00:00:51.660 --> 00:00:55.440
Сдвиг влево не просто распределил обязанности, он навалил их огромной горой.

00:00:55.700 --> 00:00:58.220
Разработчик, который раньше писал код и создавал заявку,

00:00:58.340 --> 00:01:01.520
теперь отвечает за инфраструктуру, безопасность, мониторинг, кубернетес,

00:01:01.660 --> 00:01:05.300
CI, CD-конвейеры, управление секретами и еще 15 облачных сервисов,

00:01:05.360 --> 00:01:06.760
о которых он раньше даже не слышал.

00:01:06.860 --> 00:01:10.460
Один человек занимается всем этим, продолжая при этом создавать сам продукт.

00:01:10.540 --> 00:01:12.080
Вот как это выглядит в реальной жизни.

00:01:12.280 --> 00:01:15.180
Команде нужно развернуть новую среду для тестирования функции.

00:01:15.380 --> 00:01:17.560
До DevOps они подавали заявку и ждали.

00:01:17.700 --> 00:01:19.260
После DevOps они все делают сами.

00:01:19.440 --> 00:01:20.580
В теории это звучит отлично.

00:01:20.800 --> 00:01:22.520
Но теперь им нужно писать модули Terraform,

00:01:22.520 --> 00:01:25.960
настраивать кластер кубернетес, сетевые правила, подключать мониторинг,

00:01:26.120 --> 00:01:29.040
разбираться с секретами и следить за выполнением политик безопасности.

00:01:29.160 --> 00:01:32.100
То, что раньше было заявкой, на которую у другого специалиста уходил час,

00:01:32.280 --> 00:01:34.180
теперь занимает три дня рабочего времени разработчика.

00:01:34.300 --> 00:01:36.400
Три дня, в которые они не пишут код продукта.

00:01:36.520 --> 00:01:38.520
Они сражаются с IML-файлами и выясняют,

00:01:38.520 --> 00:01:40.860
почему балансировщик нагрузки неверно перенаправляет трафик.

00:01:41.120 --> 00:01:42.780
Психологическая нагрузка здесь колоссальна.

00:01:42.900 --> 00:01:44.940
Каждая команда в итоге создает свои собственные конвейеры,

00:01:45.160 --> 00:01:46.680
скрипты развертывания и панели мониторинга.

00:01:46.800 --> 00:01:49.340
И поскольку все перегружаны, работа делается на коленке.

00:01:49.580 --> 00:01:52.040
Безопасностью пренебрегают, потому что дедлайн уже в пятницу.

00:01:52.240 --> 00:01:54.340
Счета за облако удваиваются, и никто не замечает,

00:01:54.500 --> 00:01:56.280
потому что все забыли отключить тестовую среду.

00:01:56.360 --> 00:01:58.000
А когда все ломается в 2 часа ночи,

00:01:58.120 --> 00:02:00.500
только разработчик, создавший это, может все исправить.

00:02:00.620 --> 00:02:03.400
Это неустойчивая модель, и вот почему сейчас это важно как никогда.

00:02:03.520 --> 00:02:05.560
Сложность облачных технологий продолжает расти.

00:02:05.740 --> 00:02:09.160
С каждым годом появляется все больше сервисов, инструментов и решений, которые нужно принять.

00:02:09.320 --> 00:02:12.000
Сегодня инструменты и позволяют разработчикам писать код быстрее,

00:02:12.180 --> 00:02:14.900
чем когда-либо в 10, 20 и даже 30 раз больше кода в день.

00:02:14.900 --> 00:02:18.560
Но весь этот код по-прежнему нуждается в инфраструктуре, безопасности и мониторинге.

00:02:18.700 --> 00:02:21.680
Больше кода без качественной системы – это просто путь к хаосу.

00:02:21.780 --> 00:02:25.080
Если вам кажется, что вы тонете в YML и Terraform, вы не одиноки.

00:02:25.220 --> 00:02:26.620
Это не ваша личная неудача.

00:02:26.720 --> 00:02:27.800
Это системная проблема.

00:02:28.040 --> 00:02:30.860
Текущая модель исказила само понятие платформенной инженерии.

00:02:30.960 --> 00:02:32.040
Так как же все исправить?

00:02:32.220 --> 00:02:35.500
Решение – платформенная инженерия, и вот как проще всего об этом думать.

00:02:35.620 --> 00:02:39.400
Эта дисциплина создает внутренний слой, который берет на себя всю сложность для разработчиков.

00:02:39.560 --> 00:02:41.840
Представьте, что вы заходите в большое офисное здание.

00:02:41.840 --> 00:02:46.820
Вам не нужно беспокоиться о том, у кого есть доступ на этаж, какой пропуск сработает или где находятся пожарные выходы.

00:02:46.960 --> 00:02:50.340
Стойка регистрации берет все это на себя, а вы просто входите и приступаете к работе.

00:02:50.480 --> 00:02:53.280
Именно это платформенная инженерия делает для ваших разработчиков.

00:02:53.420 --> 00:02:58.320
Вместо того, чтобы каждому разработчику становиться экспертом в Kubernetes, Terraform, сетях и безопасности,

00:02:58.540 --> 00:03:01.960
центральная команда платформы создает слой, управляющий всей этой сложностью.

00:03:02.180 --> 00:03:08.140
Разработчик получает простой интерфейс – нажать кнопку, запустить команду, заполнить форму, и платформа позаботится обо всем остальном.

00:03:08.140 --> 00:03:10.780
Но есть важный нюанс – это не то же самое, что DevOps.

00:03:11.000 --> 00:03:15.620
DevOps призывал команды владеть своей инфраструктурой, но платформенная инженерия утверждает, что это верный путь к выгоранию.

00:03:15.820 --> 00:03:21.360
Вместо этого команда платформы прокладывает асфальтированные дороги, стандартные, проверенные и безопасные способы выполнения типовых задач.

00:03:21.500 --> 00:03:24.760
Они строят и обслуживают дорогу, а продуктовые команды просто едут по ней.

00:03:24.900 --> 00:03:30.180
Ключевым результатом платформенной инженерии является так называемая внутренняя платформа разработчика, или сокращенно IDP.

00:03:30.300 --> 00:03:34.280
Представьте ее как систему самообслуживания, которая автоматизирует всю рутинную работу.

00:03:34.280 --> 00:03:40.800
Подготовка инфраструктуры, CI, CD-пайплайны, проверки безопасности, мониторинг – все это встроено и стандартизировано.

00:03:40.960 --> 00:03:41.960
Вот конкретный пример.

00:03:42.160 --> 00:03:49.020
Если разработчик хочет развернуть новый сервис без такой платформы, он тратит дни на настройку инфраструктуры, написание пайплайнов и конфигурацию мониторинга.

00:03:49.200 --> 00:03:58.400
С IDP он просто нажимает «развернуть» в интерфейсе или вводит одну команду, и платформа делает все сама – подготовку ресурсов, тесты, мониторинг и деплей – за минуты, а не за дни.

00:03:58.400 --> 00:04:00.060
Итак, что это значит для вас?

00:04:00.200 --> 00:04:04.420
Вы перестаете быть мастером на все руки в инфраструктуре и становитесь специалистом по своему продукту.

00:04:04.560 --> 00:04:09.640
Ваша работа снова сводится к созданию полезных для клиентов функций, а не к отладке поврежденного файла состояния терраформ.

00:04:09.780 --> 00:04:11.360
В этом и заключается главная суть.

00:04:11.540 --> 00:04:13.540
Внутренняя платформа разработчика простыми словами.

00:04:13.680 --> 00:04:16.560
Давайте разберем, что же на самом деле представляет собой внутренняя платформа разработчика.

00:04:16.700 --> 00:04:18.980
Это движок, который объединяет все в единую систему.

00:04:19.180 --> 00:04:23.480
Ваши CI, CD-пайплайны, шаблоны инфраструктуры, политики безопасности, мониторинг и логирование.

00:04:23.480 --> 00:04:26.580
Вместо шести отдельных инструментов, которые нужно связывать между собой.

00:04:26.740 --> 00:04:27.560
Вот вам аналогия.

00:04:27.720 --> 00:04:30.920
Представьте разницу между готовкой с нуля и использованием торгового автомата.

00:04:31.100 --> 00:04:35.460
Готовка с нуля – это покупка продуктов, нарезка овощей, дозировка специй, слежка за плитой.

00:04:35.620 --> 00:04:38.660
Множество решений, множество шагов и множество шансов все испортить.

00:04:38.800 --> 00:04:41.320
Торговый автомат выдает результат нажатием одной кнопки.

00:04:41.500 --> 00:04:44.140
Меньше решений, быстрее результат, стабильное качество.

00:04:44.280 --> 00:04:46.280
IDP – это и есть такой торговый автомат.

00:04:46.440 --> 00:04:50.280
Разработчику не нужно знать, как разворачивается инфраструктура или где хранятся секреты.

00:04:50.280 --> 00:04:51.760
Он просто нажимает кнопку.

00:04:51.960 --> 00:04:53.600
Что внутри этого торгового автомата?

00:04:53.740 --> 00:04:55.760
Основные компоненты довольно стандартны.

00:04:55.900 --> 00:05:01.020
CI, CD-шаблоны для стабильных сборок, подготовка инфраструктуры для автоматического запуска окружений,

00:05:01.180 --> 00:05:04.060
управление секретами, чтобы пароли не разлетались по конфигам,

00:05:04.220 --> 00:05:07.680
и логирование со встроенной наблюдаемостью для быстрого устранения неполадок.

00:05:07.760 --> 00:05:11.480
Все это предварительно настроено, протестировано и поддерживается командой платформы.

00:05:11.600 --> 00:05:12.600
Вот конкретный пример.

00:05:12.800 --> 00:05:17.500
Разработчик вводит команду создания нового сервиса в консоли или нажимает кнопку на портале.

00:05:17.500 --> 00:05:21.220
За кулисами IDP разворачивает новый репозиторий с нужной структурой,

00:05:21.400 --> 00:05:23.340
создает пайплайн сборки с автотестами,

00:05:23.540 --> 00:05:28.000
деплоит сервис в среду разработки и добавляет инпоинты проверки состояния с логированием.

00:05:28.220 --> 00:05:29.980
Все это происходит за считанные минуты.

00:05:30.140 --> 00:05:33.940
Разработчик при этом не коснулся ни одного терраформ-файла и не настраивал кубернет-османифест.

00:05:34.080 --> 00:05:36.300
Просто ввел команду и получил работающий сервис.

00:05:36.440 --> 00:05:37.300
Почему это важно?

00:05:37.720 --> 00:05:38.280
Согласованность.

00:05:38.520 --> 00:05:39.260
Главная причина.

00:05:39.400 --> 00:05:42.420
Когда каждая команда создает свои пайплайны и пишет свои скрипты деплоа,

00:05:42.420 --> 00:05:44.900
вы получаете уникальные снежинки в конфигурациях.

00:05:44.940 --> 00:05:47.740
50 разных сервисов, 50 разных способов работы.

00:05:47.920 --> 00:05:51.520
Когда что-то ломается, никто не может это исправить, кроме того, кто это создал.

00:05:51.620 --> 00:05:53.920
А если этот человек уволился из компании, удачи.

00:05:54.100 --> 00:05:56.880
IDP устраняет это, заставляя каждый сервис следовать одним шаблонам,

00:05:56.960 --> 00:05:58.420
каждый деплай использовать один пайплайн,

00:05:58.580 --> 00:06:00.840
а каждую команду получать одинаковые настройки по умолчанию.

00:06:01.000 --> 00:06:04.320
Когда что-то ломается, шаблоны уже знакомы, а исправление задокументировано.

00:06:04.500 --> 00:06:05.820
Итак, что это значит для вас?

00:06:05.960 --> 00:06:09.060
Если в вашей организации 50 команд выполняют деплай 50-10 разными способами,

00:06:09.200 --> 00:06:10.160
IDP — это ваше решение.

00:06:10.160 --> 00:06:12.200
Это не значит, что команды теряют автономность.

00:06:12.320 --> 00:06:15.460
Это значит, что скучные, повторяющиеся и подверженные ошибкам части стандартизируются,

00:06:15.600 --> 00:06:17.540
чтобы интересная творческая работа могла быть разнообразной.

00:06:17.600 --> 00:06:19.300
Это компромисс, на который стоит пойти.

00:06:19.500 --> 00:06:21.640
Золотые пути — это направление, а не клетка.

00:06:21.800 --> 00:06:23.520
Давайте поговорим о «золотых путях».

00:06:23.520 --> 00:06:25.920
Вы наверняка слышали это название, но идея проста.

00:06:26.120 --> 00:06:28.600
Золотой путь — это рекомендуемый готовый рабочий процесс,

00:06:28.820 --> 00:06:30.720
который делает правильный путь самым простым.

00:06:30.900 --> 00:06:33.800
Ваша платформа, команда говорит, мы предлагаем делать так.

00:06:33.920 --> 00:06:37.360
Мы все протестировали, это работает, и мы поможем, если что-то сломается.

00:06:37.460 --> 00:06:39.700
Обратите внимание на слово «предлагаем».

00:06:39.700 --> 00:06:41.660
Золотые пути не являются обязательными.

00:06:41.880 --> 00:06:43.640
Разработчики могут сойти с пути, если нужно,

00:06:43.820 --> 00:06:45.480
но этот путь — быстрый и безопасный стандарт.

00:06:45.620 --> 00:06:47.960
Он уже запущен, поддерживается и задокументирован.

00:06:48.100 --> 00:06:49.740
Вам не нужно разбираться во всем с нуля.

00:06:49.920 --> 00:06:52.380
Представьте это как рельсы, а не как дорожные ограждения.

00:06:52.580 --> 00:06:54.840
Ограждения спасают вас, когда вы уже попали в аварию.

00:06:54.960 --> 00:06:58.220
Они реагируют, удерживают от падения, но не помогают управлять движением.

00:06:58.420 --> 00:07:02.000
Рельсы плавно ведут вас по маршруту, и вам не нужно решать, куда повернуть.

00:07:02.200 --> 00:07:03.940
Золотые пути — это и есть рельсы.

00:07:04.080 --> 00:07:06.680
Они двигают вас вперед, а не просто страхуют от ошибок.

00:07:06.680 --> 00:07:08.460
Вот в чем многие команды ошибаются.

00:07:08.460 --> 00:07:11.680
Они создают «золотые пути» для себя, а не для разработчиков.

00:07:11.740 --> 00:07:13.820
Они оптимизируют все ради архитектурной частоты,

00:07:14.060 --> 00:07:15.900
соответствия стандартам или внутренних правил,

00:07:16.060 --> 00:07:17.600
которые никто вне команды не понимает.

00:07:17.700 --> 00:07:20.520
На доске все выглядит отлично, но пользоваться этим неудобно.

00:07:20.660 --> 00:07:23.080
Разработчики тихо находят обходные пути, охват падает,

00:07:23.220 --> 00:07:25.900
а платформа-команда недоумевает, почему никто не ценит их усилия.

00:07:26.060 --> 00:07:28.000
Решение простое, но его трудно реализовать.

00:07:28.200 --> 00:07:29.480
Нужны аварийные выходы.

00:07:29.660 --> 00:07:32.840
Если путь не подходит для задачи разработчика, у него должен быть способ выйти.

00:07:33.040 --> 00:07:34.520
Возможность переопределить настройки,

00:07:34.520 --> 00:07:37.460
использовать свой пайплайн или вовсе выйти за пределы платформы.

00:07:37.540 --> 00:07:38.540
И вот что здесь важно.

00:07:38.740 --> 00:07:41.300
Когда они сходят с пути, это не провал, это обратная связь.

00:07:41.420 --> 00:07:43.520
Каждый раз, когда разработчик покидает «золотой путь»,

00:07:43.520 --> 00:07:44.780
это дает вам важную информацию.

00:07:45.000 --> 00:07:46.380
Либо пути не хватает функции,

00:07:46.640 --> 00:07:49.140
либо этот случай действительно не вписывается в стандарты.

00:07:49.260 --> 00:07:50.340
Оба сигнала ценны.

00:07:50.520 --> 00:07:52.920
Хороший «золотой путь» на практике выглядит так.

00:07:53.060 --> 00:07:55.200
Команде нужно развернуть новый бэкенд-сервис.

00:07:55.360 --> 00:07:56.500
Они выбирают этот путь.

00:07:56.660 --> 00:07:59.440
Он дает им шаблон-репозитория с правильной структурой,

00:07:59.440 --> 00:08:01.580
про тестированный CI, CD-пайплайн,

00:08:01.860 --> 00:08:03.620
встроенное логирование и мониторинг,

00:08:03.780 --> 00:08:05.160
а также откат в один клик.

00:08:05.280 --> 00:08:06.800
Все занимает минуты вместо дней,

00:08:07.040 --> 00:08:08.760
и поскольку команда поддерживает путь,

00:08:09.000 --> 00:08:10.900
при поломках они сами все исправляют.

00:08:11.100 --> 00:08:13.900
Разработчику не нужно становиться экспертом по отладке пайплайнов.

00:08:14.100 --> 00:08:15.120
Что это значит для вас?

00:08:15.300 --> 00:08:16.180
Меньше сюрпризов.

00:08:16.260 --> 00:08:18.500
Вы поставляете продукт быстрее, потому что путь уже проверен.

00:08:18.620 --> 00:08:21.260
Вы делаете это безопаснее, так как защита и мониторинг встроены.

00:08:21.260 --> 00:08:23.980
Вы уверены в результате, потому что откат занимает один клик.

00:08:24.080 --> 00:08:26.680
Путь существует, чтобы помогать вам, а не сдерживать.

00:08:26.880 --> 00:08:27.560
Пользуйтесь им.

00:08:27.560 --> 00:08:29.280
Снижение когнитивной нагрузки.

00:08:29.440 --> 00:08:31.100
Вот где проявляется настоящая выгода.

00:08:31.280 --> 00:08:33.060
Когда платформа берет на себя всю тяжелую работу,

00:08:33.280 --> 00:08:34.800
разработчики могут сосредоточиться на коде.

00:08:34.980 --> 00:08:37.520
Им не нужно знать, какая версия Kubernetes сейчас запущена.

00:08:37.680 --> 00:08:39.640
Им не нужно обновлять модули Terraform каждый раз,

00:08:39.800 --> 00:08:41.200
когда облачный провайдер меняет API.

00:08:41.380 --> 00:08:42.520
Они просто пишут функции.

00:08:42.720 --> 00:08:44.520
Инженеры платформы берут эту сложность на себя.

00:08:44.680 --> 00:08:46.140
Они решают, что разработчикам нужно видеть,

00:08:46.240 --> 00:08:47.240
а что должно оставаться скрытым.

00:08:47.340 --> 00:08:49.700
Это реальный выбор дизайна, а не просто техническое решение.

00:08:49.700 --> 00:08:52.860
Важно определить, какие детали действительно важны для пользователя,

00:08:53.080 --> 00:08:54.380
а какие — лишь лишний шум.

00:08:54.540 --> 00:08:55.560
Вот конкретный пример.

00:08:55.560 --> 00:08:57.740
Разработчику, внедряющему новый сервис,

00:08:57.920 --> 00:08:59.320
не важны размеры узлов кластера,

00:08:59.540 --> 00:09:01.740
типа инстанцев или пороги автомасштабирования.

00:09:01.940 --> 00:09:05.120
Их волнует только работоспособность сервиса и скорость его отклика.

00:09:05.220 --> 00:09:08.200
Поэтому платформа заранее настраивает все это в зависимости от уровня приложения.

00:09:08.380 --> 00:09:10.320
Небольшой сервис — вот подходящие настройки.

00:09:10.500 --> 00:09:12.640
Сервис с высокой нагрузкой — вот другая конфигурация.

00:09:12.840 --> 00:09:14.220
Разработчик не принимает эти решения,

00:09:14.400 --> 00:09:15.620
потому что в этом нет необходимости.

00:09:15.620 --> 00:09:16.540
Почему это важно?

00:09:16.700 --> 00:09:18.000
Потому что выгорание снижается,

00:09:18.200 --> 00:09:20.860
когда разработчики не жонглируют 15-ю задачами одновременно.

00:09:20.860 --> 00:09:24.360
Некоторые зрелые платформенные команды сократили когнитивную нагрузку почти вдвое.

00:09:24.500 --> 00:09:26.860
На 40-50% меньше ментальных усилий.

00:09:26.940 --> 00:09:28.120
Это колоссальные перемены.

00:09:28.280 --> 00:09:30.180
Это разница между уходом с работы с запасом сил

00:09:30.180 --> 00:09:32.480
и разглядыванием терминала в 10 вечера с вопросом,

00:09:32.560 --> 00:09:33.420
почему упал пайплайн.

00:09:33.580 --> 00:09:34.660
Но вот предостережение.

00:09:34.840 --> 00:09:35.920
Не создавайте иллюзий.

00:09:36.120 --> 00:09:38.440
Некоторые платформенные команды попадают в ловушку.

00:09:38.580 --> 00:09:39.680
Они скрывают настройки,

00:09:39.680 --> 00:09:42.640
не давая разработчикам понять, что происходит под капотом.

00:09:42.740 --> 00:09:45.360
Это не абстракция, это обман, который выходит боком.

00:09:45.500 --> 00:09:46.640
Как только что-то идет не так,

00:09:46.640 --> 00:09:48.820
разработчики упираются в стену, которую не могут разглядеть,

00:09:48.960 --> 00:09:51.520
и платформа внезапно становится черным ящиком, работающим против них.

00:09:51.640 --> 00:09:53.400
Это называется дырявая абстракция.

00:09:53.560 --> 00:09:56.440
Вы скрываете сложность, но в конечном итоге она проявляется наружу.

00:09:56.580 --> 00:09:58.520
База данных тормозит, деплы не проходят.

00:09:58.720 --> 00:10:00.880
Политика безопасности блокирует что-то неожиданное.

00:10:01.000 --> 00:10:02.840
И у разработчика нет понимания ситуации,

00:10:03.020 --> 00:10:04.800
потому что платформа никогда его не давала.

00:10:05.140 --> 00:10:05.880
Прозрачность важна.

00:10:06.040 --> 00:10:07.680
Показывайте разработчикам-то, что им нужно знать,

00:10:07.820 --> 00:10:09.160
и тогда, когда это действительно необходимо.

00:10:09.360 --> 00:10:11.220
Не скрывайте все подряд в надежде на лучшее.

00:10:11.360 --> 00:10:12.180
Что это значит для вас?

00:10:12.380 --> 00:10:14.680
Меньше переключений контекста и больше состояния потока.

00:10:14.680 --> 00:10:17.240
Вы не начинаете утро с мысли об обновлении кластера Kubernetes,

00:10:17.420 --> 00:10:20.280
вы начинаете его с работы над функцией, которая нужна на следующей неделе.

00:10:20.440 --> 00:10:22.840
Ваша работа снова становится именно вашей работой.

00:10:23.020 --> 00:10:24.900
Отношение к платформе как к продукту.

00:10:25.060 --> 00:10:28.340
Сегодня мы говорим о том, что меняет работу внутренних инструментов.

00:10:28.460 --> 00:10:31.640
Многие думают, что платформенная команда – это просто команда инфраструктуры.

00:10:31.780 --> 00:10:32.360
Это не так.

00:10:32.460 --> 00:10:34.240
Платформенная команда – это продуктовая команда,

00:10:34.300 --> 00:10:36.240
а использующие платформу разработчики, их клиенты,

00:10:36.400 --> 00:10:37.660
а не те, кто просто подает заявки.

00:10:37.780 --> 00:10:38.540
Это меняет все.

00:10:38.720 --> 00:10:40.280
Продуктовая команда общается с клиентами,

00:10:40.400 --> 00:10:42.080
выясняет, что им действительно доставляет боль,

00:10:42.080 --> 00:10:44.140
приоритизирует функции на основе реальных потребностей,

00:10:44.280 --> 00:10:45.240
измеряет уровень использования,

00:10:45.400 --> 00:10:46.620
не бросает проект после релиза,

00:10:46.700 --> 00:10:47.780
а постоянно его дорабатывает.

00:10:47.920 --> 00:10:50.180
Так как же продуктовая команда выглядит на практике?

00:10:50.320 --> 00:10:52.060
Они работают не как служба поддержки.

00:10:52.280 --> 00:10:53.480
Разработчик создает тикет,

00:10:53.660 --> 00:10:55.580
а команда платформы выполняет его вручную.

00:10:55.720 --> 00:10:56.900
Это не платформенная инженерия,

00:10:57.020 --> 00:10:59.200
это просто централизованные операции под новым названием.

00:10:59.360 --> 00:11:01.340
Это не масштабируется, не снижает когнитивную нагрузку,

00:11:01.480 --> 00:11:03.320
а лишь переносит узкое место из одной команды в другую.

00:11:03.460 --> 00:11:04.800
Вот что они делают вместо этого.

00:11:04.800 --> 00:11:06.500
Они измеряют правильные показатели.

00:11:06.700 --> 00:11:07.540
Время до первого дипла,

00:11:07.540 --> 00:11:09.460
скорость онбординга новых членов команды,

00:11:09.640 --> 00:11:11.020
уровень удовлетворенности разработчиков.

00:11:11.140 --> 00:11:12.600
Это те метрики, которые показывают,

00:11:12.760 --> 00:11:13.780
помогает ли платформа людям

00:11:13.780 --> 00:11:15.760
или просто добавляет еще один уровень сложности.

00:11:15.900 --> 00:11:17.160
Spotify – хороший пример.

00:11:17.340 --> 00:11:18.500
Их платформенная команда работает

00:11:18.500 --> 00:11:20.080
как полноценная продуктовая организация.

00:11:20.280 --> 00:11:21.340
У них есть дорожные карты,

00:11:21.580 --> 00:11:22.140
есть ОКР,

00:11:22.320 --> 00:11:23.540
они обсуждают с разработчиками,

00:11:23.680 --> 00:11:24.620
что работает, а что нет.

00:11:24.720 --> 00:11:26.500
Они относятся к платформе как к чему-то,

00:11:26.620 --> 00:11:28.620
что должно доказывать свою ценность каждый день.

00:11:28.760 --> 00:11:29.760
И в этом главная мысль.

00:11:30.000 --> 00:11:31.680
Платформа, которую никто не использует,

00:11:31.820 --> 00:11:33.520
это просто проект, пылящийся в углу.

00:11:33.660 --> 00:11:34.820
Принятие пользователями –

00:11:34.820 --> 00:11:36.200
это высшее подтверждение качества.

00:11:36.400 --> 00:11:37.980
Если разработчики выбирают вашу платформу,

00:11:38.100 --> 00:11:39.220
они создают свои инструменты,

00:11:39.340 --> 00:11:40.120
вы добились успеха.

00:11:40.220 --> 00:11:41.240
Если они ее избегают,

00:11:41.420 --> 00:11:43.520
никакое техническое совершенство этого не исправит.

00:11:43.700 --> 00:11:44.700
Что это значит для вас?

00:11:44.840 --> 00:11:46.440
Это значит, что если вы создаете платформу,

00:11:46.540 --> 00:11:47.800
не начинайте с архитектурных диаграмм,

00:11:47.900 --> 00:11:49.120
не начинайте с кластеров Кубернетес

00:11:49.120 --> 00:11:49.900
или модулей Терраформ.

00:11:50.040 --> 00:11:51.240
Начните с интервью с пользователями,

00:11:51.300 --> 00:11:52.240
поговорите с разработчиками,

00:11:52.320 --> 00:11:53.780
которые будут использовать вашу платформу.

00:11:53.840 --> 00:11:55.580
Выясните, что именно причиняет им боль.

00:11:55.760 --> 00:11:56.480
Создайте что-то одно,

00:11:56.640 --> 00:11:57.600
что решает реальную проблему,

00:11:57.780 --> 00:11:58.640
а затем развивайте это.

00:11:58.640 --> 00:11:59.780
Именно так создается-то,

00:11:59.900 --> 00:12:01.380
чем люди действительно хотят пользоваться.

00:12:01.500 --> 00:12:02.580
Почему именно сейчас?

00:12:02.800 --> 00:12:03.460
Волна ИИИ.

00:12:03.620 --> 00:12:05.320
Итак, почему мы говорим об этом сейчас?

00:12:05.480 --> 00:12:06.600
Почему не пять лет назад?

00:12:06.800 --> 00:12:07.580
Ответ ИИИ.

00:12:07.700 --> 00:12:08.800
ИИИ-инструменты для Кудинга,

00:12:09.000 --> 00:12:10.080
такие как GitHub Капайлот,

00:12:10.300 --> 00:12:11.740
позволяют разработчикам выпускать код

00:12:11.740 --> 00:12:12.940
с невиданной ранней скоростью.

00:12:13.060 --> 00:12:14.820
В 10-20 раз больше кода в день,

00:12:15.000 --> 00:12:16.460
чем было возможно всего пару лет назад.

00:12:16.620 --> 00:12:17.700
Это звучит потрясающе,

00:12:17.820 --> 00:12:18.540
и так оно и есть.

00:12:18.700 --> 00:12:19.580
Но вот в чем подвох.

00:12:19.700 --> 00:12:21.600
Для всего этого кода все еще нужна инфраструктура.

00:12:21.780 --> 00:12:23.080
Ему все еще нужна безопасность.

00:12:23.080 --> 00:12:24.500
Его все еще нужно развертывать,

00:12:24.680 --> 00:12:25.700
тестировать и обслуживать.

00:12:25.700 --> 00:12:27.320
Больше кода без лучшей системы

00:12:27.320 --> 00:12:28.320
не делает вас быстрее.

00:12:28.480 --> 00:12:29.800
Это просто ускоряет хаос,

00:12:29.960 --> 00:12:32.760
если ваши разработчики уже тонут в IML и Terraform.

00:12:32.960 --> 00:12:33.920
И этого не исправят.

00:12:34.000 --> 00:12:34.480
Это лишь значит,

00:12:34.680 --> 00:12:35.640
что они будут тонуть быстрее,

00:12:35.840 --> 00:12:37.040
создавая при этом еще больше кода,

00:12:37.140 --> 00:12:38.040
который нужно поддерживать.

00:12:38.180 --> 00:12:40.580
Прямо сейчас около 55% организаций

00:12:40.580 --> 00:12:42.080
уже внедрили платформенную инженерию

00:12:42.080 --> 00:12:42.900
в том или ином виде.

00:12:43.100 --> 00:12:43.860
Гартнер прогнозирует,

00:12:43.980 --> 00:12:45.380
что к концу 2026 года

00:12:45.380 --> 00:12:47.080
этот показатель достигнет 80%.

00:12:47.080 --> 00:12:48.200
Это немедленный тренд.

00:12:48.340 --> 00:12:50.160
Это сдвиг, который происходит прямо сейчас.

00:12:50.360 --> 00:12:51.060
Компании понимают,

00:12:51.060 --> 00:12:52.080
что не могут масштабировать

00:12:52.080 --> 00:12:53.040
свои инженерные команды

00:12:53.040 --> 00:12:54.000
без платформенного уровня.

00:12:54.180 --> 00:12:54.620
Старый подход,

00:12:54.620 --> 00:12:55.640
при котором каждая команда

00:12:55.640 --> 00:12:56.260
делает все сама,

00:12:56.380 --> 00:12:56.960
просто не работает,

00:12:57.120 --> 00:12:58.580
когда вы выпускаете код со скоростью I.

00:12:58.720 --> 00:13:00.220
Вот что многие упускают из виду.

00:13:00.360 --> 00:13:02.380
IML не просто создает потребность в платформах.

00:13:02.500 --> 00:13:03.920
Он также помогает их создавать.

00:13:04.140 --> 00:13:05.440
Платформенные команды используют

00:13:05.440 --> 00:13:07.000
и для генерации Terraform модулей,

00:13:07.160 --> 00:13:08.120
написания документации

00:13:08.120 --> 00:13:09.060
и отладки конвейеров.

00:13:09.200 --> 00:13:09.940
Та же технология,

00:13:10.120 --> 00:13:11.040
что создает срочность,

00:13:11.220 --> 00:13:13.020
предоставляет инструменты для ее решения.

00:13:13.160 --> 00:13:14.900
Теперь несколько слов предостережения.

00:13:15.080 --> 00:13:15.980
IML усиливает то,

00:13:16.140 --> 00:13:17.040
что у вас уже есть.

00:13:17.220 --> 00:13:18.520
Если у вас солидная база,

00:13:18.520 --> 00:13:19.620
хорошая архитектура

00:13:19.620 --> 00:13:20.880
и продуманная платформа,

00:13:21.040 --> 00:13:23.080
IML сделает вас в 2-3 раза продуктивнее.

00:13:23.080 --> 00:13:24.280
Но если основы слабы,

00:13:24.440 --> 00:13:25.580
IML лишь поможет вам быстрее

00:13:25.580 --> 00:13:27.000
совершать более крупные ошибки.

00:13:27.140 --> 00:13:27.900
Плохие конфигурации,

00:13:28.020 --> 00:13:28.660
дыры безопасности,

00:13:28.780 --> 00:13:29.520
сломанная инфраструктура

00:13:29.520 --> 00:13:30.700
все это попадает в продакшн раньше,

00:13:30.880 --> 00:13:31.820
чем кто-либо успеет заметить.

00:13:31.900 --> 00:13:33.440
IML не исправляет плохую базу.

00:13:33.560 --> 00:13:34.520
Он ее обнажает.

00:13:34.680 --> 00:13:35.520
Вот реальный пример.

00:13:35.700 --> 00:13:37.100
Компания с хорошей внутренней платформой

00:13:37.100 --> 00:13:37.740
для разработчиков

00:13:37.740 --> 00:13:38.720
позволяет даже неинженерам

00:13:38.720 --> 00:13:40.280
безопасно развертывать и инструменты.

00:13:40.420 --> 00:13:42.080
Платформа обеспечивает защитные барьеры.

00:13:42.260 --> 00:13:44.140
Она обеспечивает соблюдение политик безопасности.

00:13:44.300 --> 00:13:45.720
Она берет на себя инфраструктуру.

00:13:45.720 --> 00:13:47.060
Так что менеджер по продукту

00:13:47.060 --> 00:13:48.500
может запустить и прототип,

00:13:48.700 --> 00:13:50.800
не вникая в кубернетис или облачные сети.

00:13:50.960 --> 00:13:52.380
Это впечатляющая возможность.

00:13:52.680 --> 00:13:54.320
Именно это отличает команды,

00:13:54.540 --> 00:13:55.740
готовые кэри и...

00:13:55.740 --> 00:13:57.400
от тех, кто останется позади.

00:13:57.620 --> 00:13:58.760
Что это значит для вас?

00:13:58.920 --> 00:14:00.820
Окно возможностей для создания платформы

00:14:00.820 --> 00:14:01.420
закрывается.

00:14:01.640 --> 00:14:03.420
Не потому, что технология исчезает,

00:14:03.660 --> 00:14:05.360
а потому, что разрыв между командами

00:14:05.360 --> 00:14:07.240
с платформами и без них быстро растет.

00:14:07.360 --> 00:14:09.000
С каждым месяцем ожидания команды,

00:14:09.000 --> 00:14:10.320
у которых уже есть платформы,

00:14:10.480 --> 00:14:11.480
уходят все дальше вперед.

00:14:11.660 --> 00:14:13.040
Они быстрее выпускают продукты,

00:14:13.240 --> 00:14:13.900
меньше выгорают

00:14:13.900 --> 00:14:15.740
и скорее адаптируются к новым инструментам.

00:14:15.740 --> 00:14:17.840
Команды без платформ все больше отстают.

00:14:18.080 --> 00:14:18.740
Выбор за вами.

00:14:18.960 --> 00:14:20.760
Начните с одного золотого пути.

00:14:20.960 --> 00:14:22.700
Итак, с чего же начать на самом деле?

00:14:22.900 --> 00:14:24.020
Если вы сидите и думаете,

00:14:24.300 --> 00:14:26.240
что нужно строить всю внутреннюю платформу с нуля,

00:14:26.400 --> 00:14:26.920
остановитесь.

00:14:27.080 --> 00:14:28.760
Это самый быстрый способ убить проект,

00:14:28.980 --> 00:14:29.780
даже не начав его.

00:14:30.000 --> 00:14:31.260
Самая большая ошибка команд

00:14:31.260 --> 00:14:32.780
пытаться построить все и сразу.

00:14:33.000 --> 00:14:34.780
Они месяцами проектируют идеальную платформу,

00:14:34.920 --> 00:14:35.920
добавляя туда все функции,

00:14:36.040 --> 00:14:37.020
которые приходят в голову.

00:14:37.020 --> 00:14:38.620
Затем они запускают ее и...

00:14:38.620 --> 00:14:38.960
Тишина.

00:14:39.140 --> 00:14:40.240
Никто ее не использует.

00:14:40.360 --> 00:14:40.660
Почему?

00:14:40.900 --> 00:14:41.920
Потому что она решает проблемы,

00:14:42.060 --> 00:14:42.980
о которых никто не просил.

00:14:43.160 --> 00:14:43.900
А чтобы просто начать,

00:14:43.900 --> 00:14:45.160
нужно прочитать целое руководство.

00:14:45.360 --> 00:14:46.760
Суть в том, что так делать не надо.

00:14:46.940 --> 00:14:48.160
Вместо этого начните с малого.

00:14:48.340 --> 00:14:49.440
Действительно общайтесь с разработчиками,

00:14:49.520 --> 00:14:50.080
а не с архитекторами,

00:14:50.160 --> 00:14:50.600
не с менеджерами

00:14:50.600 --> 00:14:51.800
и не опирайтесь на собственные предположения.

00:14:51.980 --> 00:14:53.000
Найдите тех, кто пишет код

00:14:53.000 --> 00:14:54.140
и создает функции каждый день.

00:14:54.300 --> 00:14:54.800
Спросите их,

00:14:54.900 --> 00:14:56.160
что доставляет им больше всего боли.

00:14:56.320 --> 00:14:57.160
Найдите рабочий процесс,

00:14:57.300 --> 00:14:58.540
который занимает больше всего времени,

00:14:58.760 --> 00:14:59.440
раздражает многих,

00:14:59.540 --> 00:15:00.600
или которого стараются избегать.

00:15:00.760 --> 00:15:02.540
Затем создайте ровно один золотой путь

00:15:02.540 --> 00:15:03.420
от начала до конца.

00:15:03.420 --> 00:15:04.720
Возможно, это создание

00:15:04.720 --> 00:15:06.460
и развертывание нового микросервиса.

00:15:06.660 --> 00:15:07.840
Возможно, это настройка

00:15:07.840 --> 00:15:09.000
среды разработки с нуля.

00:15:09.220 --> 00:15:10.320
Возможно, это выпуск

00:15:10.320 --> 00:15:12.040
хатфиксов продакшн без поломок.

00:15:12.120 --> 00:15:12.640
Выберите то,

00:15:12.760 --> 00:15:13.740
что болит сильнее всего,

00:15:13.960 --> 00:15:14.680
и постройте путь,

00:15:14.820 --> 00:15:15.940
который избавит от этой боли.

00:15:16.120 --> 00:15:16.600
Создайте его,

00:15:16.780 --> 00:15:18.120
протестируйте с реальными пользователями,

00:15:18.280 --> 00:15:19.360
соберите отзывы и доработайте.

00:15:19.560 --> 00:15:20.760
Затем добавьте еще один путь,

00:15:20.920 --> 00:15:21.960
а после него еще один.

00:15:22.100 --> 00:15:23.660
Не пытайтесь решить все проблемы сразу.

00:15:23.880 --> 00:15:25.340
Решите одну проблему действительно хорошо

00:15:25.340 --> 00:15:26.780
и позвольте импульсу двигать вас вперед.

00:15:26.780 --> 00:15:28.280
Как понять, что это работает?

00:15:28.500 --> 00:15:29.720
Измерите правильные вещи.

00:15:29.940 --> 00:15:31.300
Время от идеи до первого релиза,

00:15:31.500 --> 00:15:33.100
количество исключенных ручных этапов

00:15:36.460 --> 00:15:37.160
вытроят свой собственный,

00:15:37.300 --> 00:15:37.880
вы побеждаете.

00:15:38.080 --> 00:15:38.980
Если они избегают его,

00:15:39.140 --> 00:15:40.520
прислушайтесь и смените направление.

00:15:40.720 --> 00:15:41.240
Вот ловушка,

00:15:41.400 --> 00:15:42.360
которой следует избегать.

00:15:42.520 --> 00:15:43.920
Не делайте платформу обязательной.

00:15:44.080 --> 00:15:45.480
Заставьте разработчиков использовать ваш путь,

00:15:45.660 --> 00:15:46.480
и они будут им недовольны.

00:15:46.600 --> 00:15:47.820
Они найдут способы обойти его.

00:15:48.000 --> 00:15:49.320
Они напишут свои собственные скрипты

00:15:49.320 --> 00:15:50.060
и скроют их от вас.

00:15:50.220 --> 00:15:51.660
Вместо этого сделайте путь простым.

00:15:51.840 --> 00:15:53.700
Сделайте его быстрее альтернативных вариантов.

00:15:53.860 --> 00:15:55.260
Сделайте его очевидным выбором,

00:15:55.260 --> 00:15:56.320
но никогда не единственным.

00:15:56.420 --> 00:15:57.980
Первый путь всегда самый трудный.

00:15:58.100 --> 00:15:58.840
Он учит вас всему,

00:15:59.060 --> 00:16:00.400
что связано с продуктовым мышлением.

00:16:00.600 --> 00:16:01.840
Вы учитесь общаться с пользователями,

00:16:01.940 --> 00:16:03.220
расставлять приоритеты и понимаете,

00:16:03.400 --> 00:16:04.540
что создавать-то, что нужно людям,

00:16:04.680 --> 00:16:05.260
гораздо сложнее,

00:16:05.460 --> 00:16:06.600
чем просто делать-то, что работает.

00:16:06.740 --> 00:16:08.180
Но как только вы сделаете это один раз,

00:16:08.400 --> 00:16:09.380
второй путь станет проще,

00:16:09.540 --> 00:16:10.560
а третий еще проще.

00:16:10.720 --> 00:16:12.480
Вы не строите платформу одним махом.

00:16:12.640 --> 00:16:14.100
Вы строите ее путь за путем.

00:16:14.280 --> 00:16:15.220
Такова эта система.

00:16:15.460 --> 00:16:16.480
Платформенная инженерия –

00:16:16.480 --> 00:16:17.920
это создание асфальтированной дороги,

00:16:17.920 --> 00:16:19.920
чтобы разработчики могли сосредоточиться на движении,

00:16:20.120 --> 00:16:20.760
а не на ремонте ям.

00:16:20.840 --> 00:16:22.400
Если вы устали бороться с инфраструктурой,

00:16:22.560 --> 00:16:24.160
начните с поиска одного золотого пути

00:16:24.160 --> 00:16:24.880
в своей команде.

00:16:25.040 --> 00:16:25.460
Всего одного.

00:16:25.460 --> 00:16:26.440
Поделитесь этим с тем,

00:16:26.620 --> 00:16:27.560
кому это нужно услышать,

00:16:27.720 --> 00:16:29.000
и подпишитесь на новые разборы,

00:16:29.200 --> 00:16:29.780
подобные этому.