WEBVTT

00:00:00.000 --> 00:00:04.060
Ласкаво просимо до чергового випуску Microsoft Knowledge Nuggets на M365FM.

00:00:04.180 --> 00:00:05.780
Я ваш ведучий Мірко Петерс.

00:00:05.920 --> 00:00:10.540
Сьогоднішня тема – це те, про що майже всі чули, але мало хто справді розуміє, платформова інженерія.

00:00:10.700 --> 00:00:15.060
Ви, мабуть, чули про DevOps, ідею про те, що розробники та операційні команди працюють злагоджено,

00:00:15.180 --> 00:00:17.180
але десь по дорозі ця обіцянка стала складною.

00:00:17.320 --> 00:00:20.460
Розробники почали виконувати операційну роботу, і ця система зламалася.

00:00:20.620 --> 00:00:23.540
Наприкінці цього епізоду ви зрозумієте, що пішло не так із DevOps,

00:00:23.540 --> 00:00:28.200
що таке насправді внутрішня платформа розробника, як «золоті шляхи» дають командам чіткий орієнтир,

00:00:28.260 --> 00:00:30.720
і чому найрозумніші інженерні команди вже створюють її.

00:00:30.860 --> 00:00:32.680
Безлад, який залишив по собі DevOps.

00:00:32.900 --> 00:00:34.740
Повернімося до того, з чого все почалося.

00:00:34.880 --> 00:00:38.700
DevOps був чудовою ідеєю з простою метою – зруйнувати стіни між розробниками та операційниками.

00:00:38.880 --> 00:00:41.520
Більше ніякого перекидання коду через стіну в надії, що все спрацює.

00:00:41.520 --> 00:00:45.140
Зміщення вліво, шіфт-лефт, перенесення тестування безпеки та операцій на ранні етапи процесу.

00:00:45.240 --> 00:00:48.000
Швидша доставка, менше передач завдань, більше відповідальності.

00:00:48.120 --> 00:00:49.780
На папері все виглядало ідеально.

00:00:49.980 --> 00:00:51.580
На практиці щось пішло не так.

00:00:51.780 --> 00:00:55.340
Зміщення вліво не просто перерозподілило обов'язки, воно їх нагромадило.

00:00:55.520 --> 00:00:58.100
Розробник, який раніше просто писав код і створював тікет,

00:00:58.200 --> 00:01:00.760
тепер відповідає за інфраструктуру, безпеку, моніторинг,

00:01:00.760 --> 00:01:03.660
Кубанітаз, CI, CD-конвайери, управління секретами

00:01:03.660 --> 00:01:06.780
та близько 15-тьох хмарних сервісів, про які він раніше навіть не чув.

00:01:06.940 --> 00:01:10.240
Одна людина займається всім цим, паралельно створюючи сам продукт.

00:01:10.320 --> 00:01:12.120
Ось як це виглядає в реальному житті.

00:01:12.260 --> 00:01:15.240
Команді потрібно розгорнути нове середовище для тестування функції.

00:01:15.240 --> 00:01:17.560
До DevOps вони створювали тікет і чекали.

00:01:17.720 --> 00:01:20.360
Після DevOps вони роблять це самі, що звучить чудово в теорії,

00:01:20.480 --> 00:01:22.300
але тепер їм потрібно писати модулі Terraform,

00:01:22.420 --> 00:01:25.740
налаштовувати кластер Кубанітаз, мережеві правила, підключати моніторинг,

00:01:25.740 --> 00:01:29.160
розбиратися з управлінням секретами та стежити за дотриманням політик безпеки.

00:01:29.280 --> 00:01:32.220
Те, що раніше було тікетом, на який інший фахівець витрачав годину,

00:01:32.340 --> 00:01:33.940
тепер забирає три дні часу розробника.

00:01:34.120 --> 00:01:36.460
Три дні, протягом яких вони не пишуть продуктовий код.

00:01:36.600 --> 00:01:38.620
Вони борються з VML-файлами та шукають причину,

00:01:38.620 --> 00:01:40.920
чому балансувальник навантаження неправильно спрямовує трафік.

00:01:40.980 --> 00:01:42.760
Психічне навантаження тут величезне.

00:01:42.900 --> 00:01:44.720
Кожна команда зрештою створює власні конвейери,

00:01:44.820 --> 00:01:46.580
сценарії розгортання та дашборди моніторингу.

00:01:46.580 --> 00:01:49.540
І оскільки всі працюють на межі можливостей, доводиться йти на компроміси.

00:01:49.780 --> 00:01:51.960
Безпекою нехтують, бо дедлайн вже в п'ятницю.

00:01:52.120 --> 00:01:54.520
Рахунки за хмару подвоюються, бо ніхто не згадав про те,

00:01:54.640 --> 00:01:56.080
щоб вимкнути тестове середовище.

00:01:56.220 --> 00:01:57.920
І коли щось ламається о другій годині ночі,

00:01:58.040 --> 00:02:00.580
розробник, який це створив, єдиний, хто може це полагодити.

00:02:00.740 --> 00:02:03.340
Це не стійка модель, і ось чому це важливо зараз, як ніколи.

00:02:03.520 --> 00:02:05.560
Складність хмарних технологій продовжує зростати.

00:02:05.780 --> 00:02:07.780
Щороку з'являється більше сервісів, більше інструментів,

00:02:07.780 --> 00:02:09.140
більше рішень, які потрібно приймати.

00:02:09.260 --> 00:02:11.820
Тепер інструменти щі дозволяють розробникам створювати код швидше,

00:02:11.940 --> 00:02:14.960
ніж будь-коли у 10-ма, 20 чи навіть 30 разів більше коду за день.

00:02:15.100 --> 00:02:18.400
Але весь цей код все одно потребує інфраструктури, безпеки та моніторингу.

00:02:18.620 --> 00:02:21.640
Більше коду без кращої системи означає лише швидший хаос.

00:02:21.780 --> 00:02:24.920
Якщо вам здається, що ви тонете в IAML і Терафом, ви не одні.

00:02:25.080 --> 00:02:26.640
Це не ваша особиста невдача.

00:02:26.780 --> 00:02:27.900
Це системна проблема.

00:02:28.140 --> 00:02:30.720
Модель викривила справжню суть платформної інженерії.

00:02:30.720 --> 00:02:32.020
Тож, як це виправити?

00:02:32.020 --> 00:02:35.600
Це називається платформна інженерія, і ось найпростіший спосіб це зрозуміти.

00:02:35.780 --> 00:02:39.340
Ця дисципліна створює внутрішній рівень, який бере на себе складність для розробників.

00:02:39.480 --> 00:02:41.760
Уявіть, що ви заходите у великий офісний центр.

00:02:41.920 --> 00:02:44.480
Вам не потрібно турбуватися про те, хто має доступ до певного поверху,

00:02:44.580 --> 00:02:46.860
яка перепустка працює або де розташовані пожежні виходи.

00:02:47.020 --> 00:02:50.260
Стійка реєстрації бере все це на себе, а ви просто заходите і беретеся до роботи.

00:02:50.380 --> 00:02:53.340
Це саме те, що платформна інженерія робить для ваших розробників.

00:02:53.340 --> 00:02:56.460
Замість того, щоб кожен розробник ставав експертом з кубанітаз,

00:02:56.580 --> 00:03:00.060
терафом мереж і безпеки, центральна команда платформи створює рівень,

00:03:00.180 --> 00:03:02.040
що керує всією цією складністю.

00:03:02.220 --> 00:03:05.820
Розробник отримує простий інтерфейс, натиснув кнопку, виконав команду,

00:03:05.960 --> 00:03:08.240
заповнив форму, а платформа бере на себе решту.

00:03:08.400 --> 00:03:10.500
Але є нюанс – це не те саме, що DevOps.

00:03:10.720 --> 00:03:13.440
DevOps вимагав, щоб кожна команда сама володіла своєю інфраструктурою,

00:03:13.500 --> 00:03:15.740
а платформна інженерія стверджує, що це шлях до вигорання.

00:03:15.740 --> 00:03:18.260
Натомість команда платформи прокладає асфальтовані шляхи,

00:03:18.360 --> 00:03:21.420
стандартні, протестовані й безпечні способи виконання типових завдань.

00:03:21.460 --> 00:03:24.860
Вони будують і обслуговують дорогу, а продуктові команди просто їдуть нею.

00:03:25.000 --> 00:03:27.500
Головним результатом платформної інженерії є так звана

00:03:27.500 --> 00:03:30.080
внутрішня платформа розробника, або скорочено IDP.

00:03:30.260 --> 00:03:32.460
Думайте про це як про систему самообслуговування,

00:03:32.640 --> 00:03:34.320
що автоматизує всю рутинну роботу.

00:03:34.500 --> 00:03:38.840
Надання інфраструктури, CI, CD-конвейери, перевірки безпеки, моніторинг –

00:03:38.840 --> 00:03:40.660
усе це вбудовано та стандартизовано.

00:03:40.800 --> 00:03:42.020
Ось конкретний приклад.

00:03:45.740 --> 00:03:48.940
Налаштування інфраструктури, написання конвейерів і налаштування моніторингу.

00:03:49.100 --> 00:03:53.160
За IDP він просто натискає «Розгорнути» в інтерфейсі або запускає одну команду,

00:03:53.240 --> 00:03:57.140
і платформа робить усе сама – налаштування, тести, моніторинг, розгортання –

00:03:57.140 --> 00:03:58.320
усе за хвилини, а не дні.

00:03:58.480 --> 00:04:00.140
Отже, що це означає для вас?

00:04:00.300 --> 00:04:02.680
Ви перестаєте бути майстром на всі руки в інфраструктурі

00:04:02.680 --> 00:04:04.360
і стаєте фахівцем у своєму продукті.

00:04:04.500 --> 00:04:06.920
Ви повертаєтеся до створення функцій, важливих для клієнтів,

00:04:06.920 --> 00:04:09.680
замість того, щоб з'ясовувати, чому пошкоджено файл стану Терафом.

00:04:09.820 --> 00:04:13.480
У цьому й полягає головна мета – внутрішня платформа розробника простою мовою.

00:04:13.620 --> 00:04:16.620
Тож давайте розберемося, що насправді являє собою внутрішня платформа розробника.

00:04:16.780 --> 00:04:18.920
Це двигун, який об'єднує все в одну систему.

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

00:04:23.400 --> 00:04:26.540
Замість шести окремих інструментів, які потрібно з'єднувати між собою.

00:04:26.680 --> 00:04:27.480
Ось аналогія.

00:04:27.480 --> 00:04:30.940
Уявіться, як приготування їжі з нуля порівняно з використанням торгового автомата.

00:04:31.080 --> 00:04:35.440
Готувати з нуля – це купувати інгредієнти, різати овочі, відміряти спеції, стежити за плитою.

00:04:35.620 --> 00:04:38.500
Багато рішень, багато кроків, багато можливостей припуститися помилки.

00:04:38.640 --> 00:04:41.480
Торговий автомат видає результат після натискання однієї кнопки.

00:04:41.660 --> 00:04:44.120
Менше рішень, швидший результат, стабільна якість.

00:04:44.120 --> 00:04:46.200
IDP – це і є такий торговий автомат.

00:04:46.320 --> 00:04:50.140
Розробнику не потрібно знати, як розгортається інфраструктура або де зберігаються секрети.

00:04:50.140 --> 00:04:53.720
Він просто натискає кнопку, що всередині цього торгового автомата.

00:04:53.880 --> 00:04:55.740
Основні компоненти досить стандартні.

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

00:05:00.820 --> 00:05:04.160
керування секретами, щоб облікові дані не гуляли у файлах конфігурації

00:05:04.160 --> 00:05:07.660
і логування з вбудованою спостережуваністю для усунення несправностей без паніки.

00:05:07.660 --> 00:05:11.320
Все це попередньо налаштовано, протестовано та підтримується командою платформи.

00:05:11.440 --> 00:05:12.620
Ось конкретний приклад.

00:05:12.620 --> 00:05:17.440
Розробник вводить команду «Створити новий сервіс» у командному рядку або натискає кнопку на порталі.

00:05:17.580 --> 00:05:20.720
За лаштунками IDP створює новий репозиторій із правильною структурою,

00:05:20.840 --> 00:05:23.540
налаштовує конваєр збірки, що автоматично запускає тести,

00:05:23.700 --> 00:05:28.120
розгортає сервіс у середовищі розробки та додає кінцеві точки перевірки працездатності з логуванням.

00:05:28.260 --> 00:05:30.140
Все це відбувається за лічені хвилини.

00:05:30.140 --> 00:05:33.840
Розробник жодного разу не торкнувся файлу Терафом або маніфесту Кубанітас.

00:05:33.940 --> 00:05:36.260
Просто ввів команду і отримав працюючий сервіс.

00:05:36.260 --> 00:05:37.340
Чому це важливо?

00:05:37.640 --> 00:05:39.240
Послідовність – головна причина.

00:05:39.380 --> 00:05:42.420
Коли кожна команда будує власні конваєри та пише власні скрипти розгортання,

00:05:42.540 --> 00:05:44.700
ви отримуєте унікальні сніжинки конфігурацій.

00:05:44.820 --> 00:05:48.000
50 різних сервісів, 50 різних способів виконання завдань.

00:05:48.180 --> 00:05:51.320
Коли щось ламається, ніхто, крім розробника, не може це виправити.

00:05:51.480 --> 00:05:53.900
А якщо ця людина звільнилася, бажаємо успіхів.

00:05:53.900 --> 00:05:56.800
IDP виключає це, змушуючи кожен сервіс слідувати одним шаблонам,

00:05:56.900 --> 00:05:58.480
кожен деплій використовувати один конваєр,

00:05:58.480 --> 00:06:00.900
а кожну команду мати однакові налаштування за замовчуванням.

00:06:01.000 --> 00:06:04.200
Коли щось ламається, шаблони знайомі, а спосіб виправлення задокументований.

00:06:04.340 --> 00:06:05.900
Отже, що це означає для вас?

00:06:06.040 --> 00:06:09.300
Якщо у вашій організації 50 команд роблять розгортання 50-ма різними способами,

00:06:09.380 --> 00:06:10.100
IDP – це рішення.

00:06:10.240 --> 00:06:12.300
Це не означає, що команди втрачають автономію.

00:06:12.440 --> 00:06:15.480
Це означає, що нудні, повторювані та схильні до помилок частини стандартизуються,

00:06:15.480 --> 00:06:17.500
тому цікава творча робота може бути різноманітною.

00:06:17.600 --> 00:06:19.300
Це компроміс, на який варто піти.

00:06:19.300 --> 00:06:21.360
Золоті шляхи – це напрямок, а не клітка.

00:06:21.500 --> 00:06:23.600
Давайте поговоримо про золоті шляхи Golden Pass.

00:06:23.800 --> 00:06:25.820
Ви, мабуть, чули цей термін, але ідея проста.

00:06:26.000 --> 00:06:28.700
Золотий шлях – це рекомендований, попередньо створений робочий процес,

00:06:28.800 --> 00:06:30.780
який робить правильний вибір найпростішим у виконанні.

00:06:30.940 --> 00:06:33.840
Ваша платформа-команда каже, ось як ми радимо вам це робити.

00:06:34.000 --> 00:06:37.560
Ми протестували це, воно працює, і ми допоможемо, якщо щось зламається.

00:06:37.740 --> 00:06:39.640
Зверніть увагу на слово «радимо».

00:06:39.640 --> 00:06:41.520
Золоті шляхи не є обов'язковими.

00:06:41.520 --> 00:06:43.600
Розробники можуть зійти зі шляху, якщо потрібно,

00:06:43.700 --> 00:06:45.460
але цей шлях – швидкий і безпечний стандарт.

00:06:45.640 --> 00:06:47.880
Він уже працює, підтримується та задокументований.

00:06:48.040 --> 00:06:49.720
Вам не потрібно вигадувати все з нуля.

00:06:49.900 --> 00:06:52.480
Уявіть це як залізничні колії, а не як захисні бар'єри.

00:06:52.620 --> 00:06:54.800
Захисні бар'єри ловлять вас, коли ви вже розбилися.

00:06:54.800 --> 00:06:58.100
Вони реагують, вони не дають впасти у прірву, але не допомагають керувати.

00:06:58.400 --> 00:07:02.020
Залізничні колії ведуть вас плавно за маршрутом, тож не треба думати, куди повернути.

00:07:02.180 --> 00:07:03.780
Золоті шляхи – це і є колії.

00:07:03.780 --> 00:07:06.520
Вони рухають вас уперед, а не просто ловлять, коли ви схибили.

00:07:06.680 --> 00:07:08.620
Ось де багато команд, припускаються помилки.

00:07:08.780 --> 00:07:11.920
Вони будують золоті шляхи для платформної команди, а не для розробників.

00:07:12.060 --> 00:07:15.380
Вони оптимізують архітектурну чистоту, безпеку чи внутрішні правила,

00:07:15.380 --> 00:07:17.380
які ніхто за межами команди не розуміє.

00:07:17.560 --> 00:07:20.460
Результат чудово виглядає на дошці, але жахливий у роботі.

00:07:20.620 --> 00:07:23.020
Розробники потай шукають обхідні шляхи, прийняття падає,

00:07:23.140 --> 00:07:25.780
а команда платформи дивується, чому ніхто не цінує їхні зусилля.

00:07:25.780 --> 00:07:27.960
Рішення просте, але реалізувати його важко.

00:07:28.140 --> 00:07:29.560
Вам потрібні аварійні виходи.

00:07:29.760 --> 00:07:32.840
Якщо шлях не підходить для завдання розробника, йому потрібен спосіб вийти.

00:07:33.000 --> 00:07:35.660
Можливість змінити налаштування, використати власний пайплейн,

00:07:35.720 --> 00:07:37.320
або повністю вийти за межі платформи.

00:07:37.320 --> 00:07:38.580
І ось важливий момент.

00:07:38.760 --> 00:07:41.400
Коли вони сходять зі шляху, це не провал, це зворотний зв'язок.

00:07:41.500 --> 00:07:44.680
Кожен вихід розробника із золотого шляху говорить вам про реальну проблему.

00:07:44.880 --> 00:07:48.720
Або шляху бракує важливої функції, або цей сценарій просто не підходить для нього.

00:07:48.720 --> 00:07:50.400
Обидва сигнали дуже цінні.

00:07:50.560 --> 00:07:52.860
Хороший золотий шлях на практиці виглядає так.

00:07:53.000 --> 00:07:55.080
Команда хоче розгорнути новий бекенд-сервіс.

00:07:55.260 --> 00:07:56.780
Вони використовують цей шлях.

00:07:56.920 --> 00:07:59.300
Він дає їм репозиторій шаблон з правильною структурою,

00:07:59.440 --> 00:08:01.520
стандартний перевірений CI-CD-пайплейн,

00:08:01.600 --> 00:08:05.100
вбудовані логування і моніторинг та відкат в один клік, якщо щось піде не так.

00:08:05.300 --> 00:08:06.780
Все це займає хвилини замість днів,

00:08:06.880 --> 00:08:08.900
і оскільки платформа-команда підтримує цей шлях,

00:08:08.980 --> 00:08:10.760
якщо щось ламається, вони це лагодять.

00:08:10.760 --> 00:08:13.840
Розробнику не потрібно ставати експертом із налагодження пайплейнів.

00:08:13.980 --> 00:08:15.240
Що це означає для вас?

00:08:15.400 --> 00:08:16.320
Менше сюрпризів.

00:08:16.460 --> 00:08:18.440
Ви випускаєте релізи швидше, бо шлях перевірений.

00:08:18.580 --> 00:08:21.280
Ви випускаєте безпечніше, бо захист і моніторинг вже вбудовані.

00:08:21.400 --> 00:08:23.800
Ви працюєте впевнено, бо відкат робиться одним кліком.

00:08:24.000 --> 00:08:26.460
Шлях існує, щоб допомагати, а не стримувати вас.

00:08:26.820 --> 00:08:27.460
Користуйтесь ним.

00:08:27.700 --> 00:08:29.360
Зменшення когнітивного навантаження.

00:08:29.500 --> 00:08:31.320
Ось тут і проявляється справжня користь.

00:08:31.320 --> 00:08:34.780
Коли платформа бере на себе всю важку роботу, розробники можуть зосередитися на коді.

00:08:34.900 --> 00:08:37.500
Їм не потрібно знати, яка версія Кубанітас зараз працює.

00:08:37.660 --> 00:08:41.120
Їм не потрібно оновлювати модулі Терафом щоразу, коли хмарний провайдер змінює АРІ.

00:08:41.260 --> 00:08:42.540
Вони просто пишуть функції.

00:08:42.740 --> 00:08:44.600
Інженери платформи беруть цю складність на себе.

00:08:44.780 --> 00:08:47.200
Вони вирішують, що розробникам варто бачити, а що краще приховати.

00:08:47.320 --> 00:08:49.740
Це справжній дизайнерський вибір, а не просто технічне рішення.

00:08:49.740 --> 00:08:54.280
Важливо зрозуміти, які деталі важливі для користувача платформи, а які лише створюють шум.

00:08:54.420 --> 00:08:55.660
Ось конкретний приклад.

00:08:55.860 --> 00:09:01.660
Розробнику, що розгортає новий сервіс, байдуже до розмірів вузлів кластера, типів інстанців чи порогів автоштабування.

00:09:01.880 --> 00:09:05.160
Його цікавить лише те, чи працює сервіс і як швидко він відповідає.

00:09:05.280 --> 00:09:08.220
Тому платформа попередньо налаштовує все це залежно від рівня застосунку.

00:09:08.360 --> 00:09:09.740
Малий сервіс – ось відповідні налаштування.

00:09:10.480 --> 00:09:12.860
Сервіс із високим трафіком – ось інша конфігурація.

00:09:12.860 --> 00:09:15.380
Розробник не робить цей вибір, бо йому це не потрібно.

00:09:15.500 --> 00:09:16.440
Чому це важливо?

00:09:16.600 --> 00:09:20.940
Тому що вигорання зменшується, коли розробникам не доводиться жонглювати 15-ма різними завданнями одночасно.

00:09:21.100 --> 00:09:24.300
Деякі зрілі команди платформ скоротили когнітивне навантаження майже вдвічі.

00:09:24.420 --> 00:09:26.860
Навіть 40 до 50% менше ментальних зусиль.

00:09:27.020 --> 00:09:28.020
Це величезний су.

00:09:28.220 --> 00:09:33.400
Це різниця між тим, щоб піти з роботи з енергією, і тим, щоб дивитися в термінал о 10-й вечора, гадаючи, чому впав конвейер.

00:09:33.520 --> 00:09:34.620
Але ось застереження.

00:09:34.800 --> 00:09:35.940
Не створюйте ілюзій.

00:09:35.940 --> 00:09:38.360
Деякі команди платформ потрапляють у пастку.

00:09:38.540 --> 00:09:42.720
Вони приховують налаштування, не даючи розробникам зрозуміти, що відбувається під капотом.

00:09:42.840 --> 00:09:46.680
Це не абстракція, це хитрість, і вона вилазить боком, щойно щось йде не так.

00:09:46.800 --> 00:09:51.420
Розробники впираються в стіну, крізь яку нічого не видно, і платформа раптом стає чорною скринькою, що працює проти них.

00:09:51.560 --> 00:09:53.480
Термін для цього – дірява абстракція.

00:09:53.640 --> 00:09:56.300
Ви приховуєте складність, але зрештою вона виходить назовні.

00:09:56.300 --> 00:10:00.700
База даних уповільнюється, розгортання не вдається, політика безпеки блокує щось несподіване.

00:10:00.840 --> 00:10:04.660
А у розробника немає ментальної моделі того, що відбувається, бо платформа її не надала.

00:10:04.940 --> 00:10:06.140
Прозорість має значення.

00:10:06.300 --> 00:10:09.000
Показуйте розробникам те, що їм потрібно знати, коли це необхідно.

00:10:09.140 --> 00:10:11.380
Не просто ховайте все підряд, сподіваючись на краще.

00:10:11.520 --> 00:10:14.760
Що це означає для вас менше перемикання контексту і більше стану потоку.

00:10:14.880 --> 00:10:20.320
Ви починаєте ранок не з думок про оновлення кластера Кубанітаз, а з роботи над функцією, що має бути готова наступного тижня.

00:10:20.320 --> 00:10:22.620
Ваша робота знову стає вашою роботою.

00:10:22.820 --> 00:10:24.720
Ставтеся до платформи, як до продукту.

00:10:24.880 --> 00:10:28.360
Сьогодні ми говоримо про те, що змінює саму роботу внутрішніх інструментів.

00:10:28.520 --> 00:10:31.640
Більшість людей вважає, що команда платформи – це просто інфраструктурна команда.

00:10:31.800 --> 00:10:32.400
Це не так.

00:10:32.560 --> 00:10:37.520
Команда платформи – це продуктова команда, а розробники, що використовують її – це клієнти, а не люди, що створюють тікети.

00:10:37.680 --> 00:10:38.560
Це змінює все.

00:10:38.560 --> 00:10:47.640
Команда продукту спілкується зі своїми клієнтами, вони з'ясовують, що насправді створює біль, вони пріоритизують функції на основі реальних потреб, вони вимірюють впровадження, вони не будують щось і не йдуть, вони продовжують ітерувати.

00:10:47.820 --> 00:10:50.180
Тож, як виглядає продуктова команда на практиці?

00:10:50.340 --> 00:10:52.200
Вони не працюють, як служба підтримки.

00:10:52.400 --> 00:10:55.460
Розробник подає запит, а платформа-команда виконує його вручну.

00:10:55.460 --> 00:10:59.220
Це не платформове інженерне забезпечення, це просто централізовані операції з новою назвою.

00:10:59.220 --> 00:11:03.400
Це не масштабується, не зменшує когнітивне навантаження, а просто переносить вузьке місце з однієї команди на іншу.

00:11:03.500 --> 00:11:04.840
Ось що вони роблять натомість.

00:11:05.000 --> 00:11:06.440
Вони вимірюють правильні речі.

00:11:06.600 --> 00:11:11.000
Час до першого розгортання, швидкість онбордингу нових членів команди, показники задоволеності розробників.

00:11:11.120 --> 00:11:15.680
Це показники, які свідчать, чи платформа справді допомагає людям, чи просто додає ще один рівень складності.

00:11:15.840 --> 00:11:17.220
Spotify – хороший приклад.

00:11:17.420 --> 00:11:20.140
Їхня платформа-команда працює, як справжня продуктова організація.

00:11:20.140 --> 00:11:24.480
У них є дорожні карти ООКР, вони спілкуються з розробниками про те, що працює, а що ні.

00:11:24.640 --> 00:11:29.680
Вони ставляться до платформи як до чогось, що має виправдовувати своє використання щодня, і це головна ідея.

00:11:29.880 --> 00:11:33.680
Платформа, яку ніхто не використовує, це просто проект, що припадає пилом у кутку.

00:11:34.060 --> 00:11:35.980
Впровадження – це найвищий ступінь валідації.

00:11:36.160 --> 00:11:40.160
Якщо розробники обирають вашу платформу замість того, щоб будувати власні інструменти, ви досягли успіху.

00:11:40.280 --> 00:11:43.340
Якщо вони її уникають, жодна технічна досконалість це не виправить.

00:11:43.500 --> 00:11:44.840
Що це означає для вас?

00:11:50.140 --> 00:11:53.580
Хайте з інтерв'ю з користувачами, поговоріть з розробниками, які використовуватимуть вашу платформу.

00:11:53.740 --> 00:11:55.720
З'ясуйте, що насправді викликає труднощі.

00:11:55.880 --> 00:11:58.560
Створіть одну річ, яка вирішує реальну проблему, а потім ітеруйте.

00:11:58.740 --> 00:12:01.420
Ось так ви створюєте те, чим люди справді хочуть користуватися.

00:12:01.560 --> 00:12:02.560
Чому саме зараз?

00:12:02.680 --> 00:12:03.360
Хвиля ЩІ.

00:12:03.500 --> 00:12:05.260
То чому ми говоримо про це саме зараз?

00:12:05.380 --> 00:12:06.580
Чому не п'ять років тому?

00:12:06.900 --> 00:12:07.620
Відповідь ЩІ.

00:12:07.620 --> 00:12:13.060
Інструменти для написання коду на основі ЩІ, як от GitHub Coopilot, дозволяють розробникам випускати код із небаченою раніше швидкістю.

00:12:13.180 --> 00:12:16.540
У 10-20 разів більше коду на день, ніж було можливо ще кілька років тому.

00:12:16.720 --> 00:12:18.500
Це звучить дивовижно, і це так і є.

00:12:18.640 --> 00:12:19.420
Але є нюанс.

00:12:19.580 --> 00:12:21.560
Усьому цьому коду все ще потрібна інфраструктура.

00:12:21.760 --> 00:12:23.000
Їй усе ще потрібна безпека.

00:12:23.260 --> 00:12:25.580
Її все ще потрібно розгортати, тестувати й обслуговувати.

00:12:25.820 --> 00:12:28.280
Більше коду без кращої системи не робить вас швидшими.

00:12:28.440 --> 00:12:29.980
Це просто пришвидшує хаос.

00:12:29.980 --> 00:12:33.840
Якщо ваші розробники вже тонуть у VAML та Terraform, ЩІ цього не виправить.

00:12:33.960 --> 00:12:38.020
Це лише означає, що вони потонуть швидше, створюючи при цьому більше коду, який потребує підтримки.

00:12:38.180 --> 00:12:42.900
Зараз близько 55% організацій вже в тій чи іншій формі впровадили платформову інженерію.

00:12:43.060 --> 00:12:46.900
Датна прогнозує, що до кінця 2026 року цей показник сягне 80%.

00:12:46.900 --> 00:12:48.300
Це неповільна тенденція.

00:12:48.460 --> 00:12:50.320
Це зміни, що відбуваються прямо зараз.

00:12:50.440 --> 00:12:53.920
Компанії розуміють, що не можуть масштабувати інженерні команди без рівень платформи.

00:12:53.920 --> 00:12:58.420
Старий підхід, коли кожна команда робить усе сама, просто не працює, коли ви постачаєте код зі швидкістю ЩІ.

00:12:58.540 --> 00:13:00.160
Ось що багато хто втрачає з виду.

00:13:00.320 --> 00:13:02.300
ЩІ не просто створює потребу в платформах.

00:13:02.460 --> 00:13:04.040
Він також допомагає їх будувати.

00:13:04.280 --> 00:13:09.160
Платформові команди використовують ЩІ для генерації модулів Terraform, написання документації та налагодження конвейерів.

00:13:09.280 --> 00:13:13.220
Та сама технологія, що створює терміновість, також надає інструменти для її вирішення.

00:13:13.380 --> 00:13:14.700
А тепер застереження.

00:13:14.900 --> 00:13:16.860
ЩІ підсилює те, що ви вже маєте.

00:13:16.860 --> 00:13:23.180
Якщо ваші основи міцні, як от гарна архітектура та добре спроєктована платформа, ЩІ робить вас у два-три рази продуктивнішими.

00:13:23.320 --> 00:13:27.000
Але якщо ваші основи слабкі, ЩІ лише допомагає робити більші помилки швидше.

00:13:27.160 --> 00:13:31.540
Погані конфігурації, діри в безпеці, зламана інфраструктура – все потрапляє в продакшній, перш ніж хтось це помітить.

00:13:31.700 --> 00:13:33.340
ЩІ не виправляє погані основи.

00:13:33.500 --> 00:13:34.480
Він їх викриває.

00:13:34.680 --> 00:13:35.720
Ось реальний приклад.

00:13:35.720 --> 00:13:40.300
Компанія з гарною внутрішньою платформою розробника дозволяє навіть неінженерам безпечно розгортати ЩІ інструменти.

00:13:40.420 --> 00:13:42.020
Платформа забезпечує запобіжники.

00:13:42.240 --> 00:13:44.080
Вона забезпечує дотримання політик безпеки.

00:13:44.220 --> 00:13:45.740
Вона бере на себе інфраструктуру.

00:13:45.860 --> 00:13:51.200
Тож продакт-менеджер може запустити прототип на базі ЩІ без необхідності розумітися на кубанітас чи хмарних мережах.

00:13:51.340 --> 00:13:52.160
Це потужно.

00:13:52.300 --> 00:13:57.220
Це саме те, що відділяє команди, готові до ереші, від тих, що залишаться позаду.

00:13:57.420 --> 00:13:58.860
Що це означає для вас?

00:13:58.860 --> 00:14:01.580
Вікно можливостей для створення платформи закривається.

00:14:01.760 --> 00:14:07.160
Не тому, що технологія зникає, а тому, що прірва між командами з платформами і без них швидко зростає.

00:14:07.320 --> 00:14:11.360
З кожним місяцем очікування команди, які вже мають платформи, вириваються вперед.

00:14:11.500 --> 00:14:15.460
Вони випускають продукти швидше, менше вигорають і швидше адаптуються до нових інструментів.

00:14:15.580 --> 00:14:17.900
Команди без платформ дедалі більше відстають.

00:14:18.100 --> 00:14:18.880
Вибір за вами.

00:14:19.080 --> 00:14:20.960
Почніть з одного золотого шляху.

00:14:21.080 --> 00:14:22.540
Тож з чого насправді почати?

00:14:22.540 --> 00:14:26.960
Якщо ви сидите і думаєте, що вам потрібно побудувати цілу внутрішню платформу з нуля, зупиніться.

00:14:27.140 --> 00:14:29.720
Це найшвидший спосіб вбити проєкт ще до його початку.

00:14:29.900 --> 00:14:32.740
Найбільша помилка команд – намагатися побудувати все й одразу.

00:14:32.920 --> 00:14:36.820
Вони місяцями проєктують ідеальну платформу, намагаючись втиснути туди кожну функцію, яка спаде на думку.

00:14:36.960 --> 00:14:38.900
Потім вони запускають її, чують тишу.

00:14:39.040 --> 00:14:40.320
Ніхто нею не користується.

00:14:40.500 --> 00:14:40.800
Чому?

00:14:41.000 --> 00:14:45.140
Тому що вона вирішує проблеми, про які ніхто не просив, а для того, щоб просто почати, потрібно прочитати невелику інструкцію.

00:14:45.140 --> 00:14:46.760
Ось у чому справа – не робіть цього.

00:14:46.960 --> 00:14:48.200
Натомість почніть з малого.

00:14:48.360 --> 00:14:51.920
Справді спілкуйтеся з розробниками, а не з архітекторами, не з менеджерами і не з власними припущеннями.

00:14:52.060 --> 00:14:54.120
Знайдіть людей, які щодня пишуть функціонал.

00:14:54.240 --> 00:14:56.000
Запитайте їх, що їм найбільше болить.

00:14:56.120 --> 00:15:00.700
Знайдіть робочий процес, який триває найдовше, дратує найбільше людей або який пропускають частіше, ніж варто було будинок.

00:15:00.720 --> 00:15:03.480
А потім побудуйте один золотий шлях від самого початку до кінця.

00:15:03.660 --> 00:15:06.280
Можливо, це створення та розгортання нового мікросервісу.

00:15:06.280 --> 00:15:08.940
Можливо, це налаштування середовища розробки з нуля.

00:15:09.100 --> 00:15:12.220
Можливо, це випуск термінового виправлення в продакшний безполомок.

00:15:12.340 --> 00:15:15.880
Оберіть те, що докучає найбільше, і побудуйте шлях, який усуне цей біль.

00:15:16.040 --> 00:15:19.400
Створіть його, протестуйте з реальними користувачами, зберіть відгуки, повторіть процес.

00:15:19.540 --> 00:15:21.740
Потім додайте ще один шлях, а після нього ще один.

00:15:21.880 --> 00:15:23.860
Не намагайтеся розв'язати всі проблеми одночасно.

00:15:24.000 --> 00:15:26.760
Вирішіть одну проблему дійсно добре і дозвольте цьому імпульсу рухати вас далі.

00:15:26.880 --> 00:15:28.340
Як зрозуміти, що це працює?

00:15:28.340 --> 00:15:29.780
Вимірюйте правильні речі.

00:15:29.920 --> 00:15:34.440
Час від ідеї до першого розгортання, кількість усунених ручних кроків та рівень добровільного прийняття.

00:15:34.620 --> 00:15:37.820
Якщо розробники обирають ваш шлях, а не будують власний, ви перемагаєте.

00:15:38.000 --> 00:15:40.540
Якщо вони уникають його, вислухайте їх і змініть напрямок.

00:15:40.660 --> 00:15:42.280
Ось пастка, якої варто уникати.

00:15:42.440 --> 00:15:43.920
Не робіть платформу обов'язковою.

00:15:44.060 --> 00:15:46.360
Примушуйте розробників до свого шляху, і вони будуть обурюватися.

00:15:46.360 --> 00:15:47.920
Вони знайдуть способи обійти це.

00:15:48.060 --> 00:15:50.060
Вони створять власні скрипти і ховатимуть їх від вас.

00:15:50.060 --> 00:15:51.760
Натомість зробіть цей шлях легким.

00:15:51.920 --> 00:15:53.620
Зробіть його швидшим за альтернативи.

00:15:53.760 --> 00:15:56.220
Зробіть його очевидним вибором, але ніколи не єдиним.

00:15:56.340 --> 00:15:58.020
Перший шлях завжди найважчий.

00:15:58.200 --> 00:16:00.300
Він навчає вас усьому про продуктове мислення.

00:16:00.460 --> 00:16:01.920
Ви вчитися спілкуватися з користувачами,

00:16:02.040 --> 00:16:03.940
визначати пріоритети та розумієте, що створити те,

00:16:04.060 --> 00:16:06.620
що людям насправді потрібно, набагато важче, ніж просто щось робоче.

00:16:06.620 --> 00:16:08.160
Але коли ви зробите це одного разу,

00:16:08.240 --> 00:16:10.220
другий шлях стане легшим, а третій – ще легшим.

00:16:10.340 --> 00:16:12.100
Ви не будуєте платформу за один прийом.

00:16:12.100 --> 00:16:14.340
Ви будуєте її крок за кроком, шлях за шляхом.

00:16:14.480 --> 00:16:15.720
Отже, ось і вся система.

00:16:15.880 --> 00:16:18.300
Платформена інженерія – це про створення асфальтованої дороги,

00:16:18.400 --> 00:16:20.700
щоб розробники могли зосередитися на русі, а не на латаній ям.

00:16:20.820 --> 00:16:22.100
Якщо ви втомилися боротися з інфраструктурою,

00:16:22.760 --> 00:16:25.580
почніть із пошуку одного золотого шляху у вашій команді лише одного.

00:16:25.760 --> 00:16:27.960
Поділіться цим із тими, кому це потрібно почути,

00:16:28.040 --> 00:16:29.840
і підпишіться на інші подібні розбори.