Ласкаво просимо до чергового випуску Microsoft Knowledge Nuggets на M365FM. Я ваш ведучий Мірко Петерс. Сьогоднішня тема – це те, про що майже всі чули, але мало хто справді розуміє, платформова інженерія. Ви, мабуть, чули про DevOps, ідею про те, що розробники та операційні команди працюють злагоджено, але десь по дорозі ця обіцянка стала складною. Розробники почали виконувати операційну роботу, і ця система зламалася. Наприкінці цього епізоду ви зрозумієте, що пішло не так із DevOps, що таке насправді внутрішня платформа розробника, як «золоті шляхи» дають командам чіткий орієнтир, і чому найрозумніші інженерні команди вже створюють її. Безлад, який залишив по собі DevOps. Повернімося до того, з чого все почалося. DevOps був чудовою ідеєю з простою метою – зруйнувати стіни між розробниками та операційниками. Більше ніякого перекидання коду через стіну в надії, що все спрацює. Зміщення вліво, шіфт-лефт, перенесення тестування безпеки та операцій на ранні етапи процесу.

Швидша доставка, менше передач завдань, більше відповідальності. На папері все виглядало ідеально. На практиці щось пішло не так. Зміщення вліво не просто перерозподілило обов'язки, воно їх нагромадило. Розробник, який раніше просто писав код і створював тікет, тепер відповідає за інфраструктуру, безпеку, моніторинг, Кубанітаз, CI, CD-конвайери, управління секретами та близько 15-тьох хмарних сервісів, про які він раніше навіть не чув. Одна людина займається всім цим, паралельно створюючи сам продукт. Ось як це виглядає в реальному житті. Команді потрібно розгорнути нове середовище для тестування функції. До DevOps вони створювали тікет і чекали. Після DevOps вони роблять це самі, що звучить чудово в теорії, але тепер їм потрібно писати модулі Terraform, налаштовувати кластер Кубанітаз, мережеві правила, підключати моніторинг, розбиратися з управлінням секретами та стежити за дотриманням політик безпеки.

Те, що раніше було тікетом, на який інший фахівець витрачав годину, тепер забирає три дні часу розробника. Три дні, протягом яких вони не пишуть продуктовий код. Вони борються з VML-файлами та шукають причину, чому балансувальник навантаження неправильно спрямовує трафік. Психічне навантаження тут величезне. Кожна команда зрештою створює власні конвейери, сценарії розгортання та дашборди моніторингу. І оскільки всі працюють на межі можливостей, доводиться йти на компроміси. Безпекою нехтують, бо дедлайн вже в п'ятницю. Рахунки за хмару подвоюються, бо ніхто не згадав про те, щоб вимкнути тестове середовище. І коли щось ламається о другій годині ночі, розробник, який це створив, єдиний, хто може це полагодити. Це не стійка модель, і ось чому це важливо зараз, як ніколи. Складність хмарних технологій продовжує зростати. Щороку з'являється більше сервісів, більше інструментів, більше рішень, які потрібно приймати.

Тепер інструменти щі дозволяють розробникам створювати код швидше, ніж будь-коли у 10-ма, 20 чи навіть 30 разів більше коду за день. Але весь цей код все одно потребує інфраструктури, безпеки та моніторингу. Більше коду без кращої системи означає лише швидший хаос. Якщо вам здається, що ви тонете в IAML і Терафом, ви не одні. Це не ваша особиста невдача. Це системна проблема. Модель викривила справжню суть платформної інженерії. Тож, як це виправити? Це називається платформна інженерія, і ось найпростіший спосіб це зрозуміти. Ця дисципліна створює внутрішній рівень, який бере на себе складність для розробників. Уявіть, що ви заходите у великий офісний центр. Вам не потрібно турбуватися про те, хто має доступ до певного поверху, яка перепустка працює або де розташовані пожежні виходи. Стійка реєстрації бере все це на себе, а ви просто заходите і беретеся до роботи. Це саме те, що платформна інженерія робить для ваших розробників.

Замість того, щоб кожен розробник ставав експертом з кубанітаз, терафом мереж і безпеки, центральна команда платформи створює рівень, що керує всією цією складністю. Розробник отримує простий інтерфейс, натиснув кнопку, виконав команду, заповнив форму, а платформа бере на себе решту. Але є нюанс – це не те саме, що DevOps. DevOps вимагав, щоб кожна команда сама володіла своєю інфраструктурою, а платформна інженерія стверджує, що це шлях до вигорання. Натомість команда платформи прокладає асфальтовані шляхи, стандартні, протестовані й безпечні способи виконання типових завдань. Вони будують і обслуговують дорогу, а продуктові команди просто їдуть нею. Головним результатом платформної інженерії є так звана внутрішня платформа розробника, або скорочено IDP. Думайте про це як про систему самообслуговування, що автоматизує всю рутинну роботу. Надання інфраструктури, CI, CD-конвейери, перевірки безпеки, моніторинг – усе це вбудовано та стандартизовано.

Ось конкретний приклад.

Налаштування інфраструктури, написання конвейерів і налаштування моніторингу. За IDP він просто натискає «Розгорнути» в інтерфейсі або запускає одну команду, і платформа робить усе сама – налаштування, тести, моніторинг, розгортання – усе за хвилини, а не дні. Отже, що це означає для вас? Ви перестаєте бути майстром на всі руки в інфраструктурі і стаєте фахівцем у своєму продукті. Ви повертаєтеся до створення функцій, важливих для клієнтів, замість того, щоб з'ясовувати, чому пошкоджено файл стану Терафом. У цьому й полягає головна мета – внутрішня платформа розробника простою мовою. Тож давайте розберемося, що насправді являє собою внутрішня платформа розробника. Це двигун, який об'єднує все в одну систему. Ваші CI, CD-конвейери, шаблони інфраструктури, політики безпеки, моніторинг та логування. Замість шести окремих інструментів, які потрібно з'єднувати між собою. Ось аналогія. Уявіться, як приготування їжі з нуля порівняно з використанням торгового автомата.

Готувати з нуля – це купувати інгредієнти, різати овочі, відміряти спеції, стежити за плитою. Багато рішень, багато кроків, багато можливостей припуститися помилки. Торговий автомат видає результат після натискання однієї кнопки. Менше рішень, швидший результат, стабільна якість. IDP – це і є такий торговий автомат. Розробнику не потрібно знати, як розгортається інфраструктура або де зберігаються секрети. Він просто натискає кнопку, що всередині цього торгового автомата. Основні компоненти досить стандартні. CI – CD-шаблони для узгоджених збірок, забезпечення інфраструктури для автоматичного створення середовищ, керування секретами, щоб облікові дані не гуляли у файлах конфігурації і логування з вбудованою спостережуваністю для усунення несправностей без паніки. Все це попередньо налаштовано, протестовано та підтримується командою платформи. Ось конкретний приклад. Розробник вводить команду «Створити новий сервіс» у командному рядку або натискає кнопку на порталі.

За лаштунками IDP створює новий репозиторій із правильною структурою, налаштовує конваєр збірки, що автоматично запускає тести, розгортає сервіс у середовищі розробки та додає кінцеві точки перевірки працездатності з логуванням. Все це відбувається за лічені хвилини. Розробник жодного разу не торкнувся файлу Терафом або маніфесту Кубанітас. Просто ввів команду і отримав працюючий сервіс. Чому це важливо? Послідовність – головна причина. Коли кожна команда будує власні конваєри та пише власні скрипти розгортання, ви отримуєте унікальні сніжинки конфігурацій. 50 різних сервісів, 50 різних способів виконання завдань. Коли щось ламається, ніхто, крім розробника, не може це виправити. А якщо ця людина звільнилася, бажаємо успіхів. IDP виключає це, змушуючи кожен сервіс слідувати одним шаблонам, кожен деплій використовувати один конваєр, а кожну команду мати однакові налаштування за замовчуванням.

Коли щось ламається, шаблони знайомі, а спосіб виправлення задокументований. Отже, що це означає для вас? Якщо у вашій організації 50 команд роблять розгортання 50-ма різними способами, IDP – це рішення. Це не означає, що команди втрачають автономію. Це означає, що нудні, повторювані та схильні до помилок частини стандартизуються, тому цікава творча робота може бути різноманітною. Це компроміс, на який варто піти. Золоті шляхи – це напрямок, а не клітка. Давайте поговоримо про золоті шляхи Golden Pass. Ви, мабуть, чули цей термін, але ідея проста. Золотий шлях – це рекомендований, попередньо створений робочий процес, який робить правильний вибір найпростішим у виконанні. Ваша платформа-команда каже, ось як ми радимо вам це робити. Ми протестували це, воно працює, і ми допоможемо, якщо щось зламається. Зверніть увагу на слово «радимо». Золоті шляхи не є обов'язковими. Розробники можуть зійти зі шляху, якщо потрібно, але цей шлях – швидкий і безпечний стандарт.

Він уже працює, підтримується та задокументований. Вам не потрібно вигадувати все з нуля. Уявіть це як залізничні колії, а не як захисні бар'єри. Захисні бар'єри ловлять вас, коли ви вже розбилися. Вони реагують, вони не дають впасти у прірву, але не допомагають керувати. Залізничні колії ведуть вас плавно за маршрутом, тож не треба думати, куди повернути. Золоті шляхи – це і є колії. Вони рухають вас уперед, а не просто ловлять, коли ви схибили. Ось де багато команд, припускаються помилки. Вони будують золоті шляхи для платформної команди, а не для розробників. Вони оптимізують архітектурну чистоту, безпеку чи внутрішні правила, які ніхто за межами команди не розуміє. Результат чудово виглядає на дошці, але жахливий у роботі. Розробники потай шукають обхідні шляхи, прийняття падає, а команда платформи дивується, чому ніхто не цінує їхні зусилля. Рішення просте, але реалізувати його важко.

Вам потрібні аварійні виходи. Якщо шлях не підходить для завдання розробника, йому потрібен спосіб вийти. Можливість змінити налаштування, використати власний пайплейн, або повністю вийти за межі платформи. І ось важливий момент. Коли вони сходять зі шляху, це не провал, це зворотний зв'язок. Кожен вихід розробника із золотого шляху говорить вам про реальну проблему. Або шляху бракує важливої функції, або цей сценарій просто не підходить для нього. Обидва сигнали дуже цінні. Хороший золотий шлях на практиці виглядає так. Команда хоче розгорнути новий бекенд-сервіс. Вони використовують цей шлях. Він дає їм репозиторій шаблон з правильною структурою, стандартний перевірений CI-CD-пайплейн, вбудовані логування і моніторинг та відкат в один клік, якщо щось піде не так. Все це займає хвилини замість днів, і оскільки платформа-команда підтримує цей шлях, якщо щось ламається, вони це лагодять. Розробнику не потрібно ставати експертом із налагодження пайплейнів.

Що це означає для вас? Менше сюрпризів. Ви випускаєте релізи швидше, бо шлях перевірений. Ви випускаєте безпечніше, бо захист і моніторинг вже вбудовані. Ви працюєте впевнено, бо відкат робиться одним кліком. Шлях існує, щоб допомагати, а не стримувати вас. Користуйтесь ним. Зменшення когнітивного навантаження. Ось тут і проявляється справжня користь. Коли платформа бере на себе всю важку роботу, розробники можуть зосередитися на коді. Їм не потрібно знати, яка версія Кубанітас зараз працює. Їм не потрібно оновлювати модулі Терафом щоразу, коли хмарний провайдер змінює АРІ. Вони просто пишуть функції. Інженери платформи беруть цю складність на себе. Вони вирішують, що розробникам варто бачити, а що краще приховати. Це справжній дизайнерський вибір, а не просто технічне рішення. Важливо зрозуміти, які деталі важливі для користувача платформи, а які лише створюють шум. Ось конкретний приклад.

Розробнику, що розгортає новий сервіс, байдуже до розмірів вузлів кластера, типів інстанців чи порогів автоштабування. Його цікавить лише те, чи працює сервіс і як швидко він відповідає. Тому платформа попередньо налаштовує все це залежно від рівня застосунку. Малий сервіс – ось відповідні налаштування. Сервіс із високим трафіком – ось інша конфігурація. Розробник не робить цей вибір, бо йому це не потрібно. Чому це важливо? Тому що вигорання зменшується, коли розробникам не доводиться жонглювати 15-ма різними завданнями одночасно. Деякі зрілі команди платформ скоротили когнітивне навантаження майже вдвічі. Навіть 40 до 50% менше ментальних зусиль. Це величезний су. Це різниця між тим, щоб піти з роботи з енергією, і тим, щоб дивитися в термінал о 10-й вечора, гадаючи, чому впав конвейер. Але ось застереження. Не створюйте ілюзій. Деякі команди платформ потрапляють у пастку. Вони приховують налаштування, не даючи розробникам зрозуміти, що відбувається під капотом.

Це не абстракція, це хитрість, і вона вилазить боком, щойно щось йде не так. Розробники впираються в стіну, крізь яку нічого не видно, і платформа раптом стає чорною скринькою, що працює проти них. Термін для цього – дірява абстракція. Ви приховуєте складність, але зрештою вона виходить назовні. База даних уповільнюється, розгортання не вдається, політика безпеки блокує щось несподіване. А у розробника немає ментальної моделі того, що відбувається, бо платформа її не надала. Прозорість має значення. Показуйте розробникам те, що їм потрібно знати, коли це необхідно. Не просто ховайте все підряд, сподіваючись на краще. Що це означає для вас менше перемикання контексту і більше стану потоку. Ви починаєте ранок не з думок про оновлення кластера Кубанітаз, а з роботи над функцією, що має бути готова наступного тижня. Ваша робота знову стає вашою роботою. Ставтеся до платформи, як до продукту.

Сьогодні ми говоримо про те, що змінює саму роботу внутрішніх інструментів. Більшість людей вважає, що команда платформи – це просто інфраструктурна команда. Це не так. Команда платформи – це продуктова команда, а розробники, що використовують її – це клієнти, а не люди, що створюють тікети. Це змінює все. Команда продукту спілкується зі своїми клієнтами, вони з'ясовують, що насправді створює біль, вони пріоритизують функції на основі реальних потреб, вони вимірюють впровадження, вони не будують щось і не йдуть, вони продовжують ітерувати. Тож, як виглядає продуктова команда на практиці? Вони не працюють, як служба підтримки. Розробник подає запит, а платформа-команда виконує його вручну. Це не платформове інженерне забезпечення, це просто централізовані операції з новою назвою. Це не масштабується, не зменшує когнітивне навантаження, а просто переносить вузьке місце з однієї команди на іншу.

Ось що вони роблять натомість. Вони вимірюють правильні речі. Час до першого розгортання, швидкість онбордингу нових членів команди, показники задоволеності розробників. Це показники, які свідчать, чи платформа справді допомагає людям, чи просто додає ще один рівень складності. Spotify – хороший приклад. Їхня платформа-команда працює, як справжня продуктова організація. У них є дорожні карти ООКР, вони спілкуються з розробниками про те, що працює, а що ні. Вони ставляться до платформи як до чогось, що має виправдовувати своє використання щодня, і це головна ідея. Платформа, яку ніхто не використовує, це просто проект, що припадає пилом у кутку. Впровадження – це найвищий ступінь валідації. Якщо розробники обирають вашу платформу замість того, щоб будувати власні інструменти, ви досягли успіху. Якщо вони її уникають, жодна технічна досконалість це не виправить. Що це означає для вас?

Хайте з інтерв'ю з користувачами, поговоріть з розробниками, які використовуватимуть вашу платформу. З'ясуйте, що насправді викликає труднощі. Створіть одну річ, яка вирішує реальну проблему, а потім ітеруйте. Ось так ви створюєте те, чим люди справді хочуть користуватися. Чому саме зараз? Хвиля ЩІ. То чому ми говоримо про це саме зараз? Чому не п'ять років тому? Відповідь ЩІ. Інструменти для написання коду на основі ЩІ, як от GitHub Coopilot, дозволяють розробникам випускати код із небаченою раніше швидкістю. У 10-20 разів більше коду на день, ніж було можливо ще кілька років тому. Це звучить дивовижно, і це так і є. Але є нюанс. Усьому цьому коду все ще потрібна інфраструктура. Їй усе ще потрібна безпека. Її все ще потрібно розгортати, тестувати й обслуговувати. Більше коду без кращої системи не робить вас швидшими. Це просто пришвидшує хаос. Якщо ваші розробники вже тонуть у VAML та Terraform, ЩІ цього не виправить.

Це лише означає, що вони потонуть швидше, створюючи при цьому більше коду, який потребує підтримки. Зараз близько 55% організацій вже в тій чи іншій формі впровадили платформову інженерію. Датна прогнозує, що до кінця 2026 року цей показник сягне 80%. Це неповільна тенденція. Це зміни, що відбуваються прямо зараз. Компанії розуміють, що не можуть масштабувати інженерні команди без рівень платформи. Старий підхід, коли кожна команда робить усе сама, просто не працює, коли ви постачаєте код зі швидкістю ЩІ. Ось що багато хто втрачає з виду. ЩІ не просто створює потребу в платформах. Він також допомагає їх будувати. Платформові команди використовують ЩІ для генерації модулів Terraform, написання документації та налагодження конвейерів. Та сама технологія, що створює терміновість, також надає інструменти для її вирішення. А тепер застереження. ЩІ підсилює те, що ви вже маєте. Якщо ваші основи міцні, як от гарна архітектура та добре спроєктована платформа, ЩІ робить вас у два-три рази продуктивнішими.

Але якщо ваші основи слабкі, ЩІ лише допомагає робити більші помилки швидше. Погані конфігурації, діри в безпеці, зламана інфраструктура – все потрапляє в продакшній, перш ніж хтось це помітить. ЩІ не виправляє погані основи. Він їх викриває. Ось реальний приклад. Компанія з гарною внутрішньою платформою розробника дозволяє навіть неінженерам безпечно розгортати ЩІ інструменти. Платформа забезпечує запобіжники. Вона забезпечує дотримання політик безпеки. Вона бере на себе інфраструктуру. Тож продакт-менеджер може запустити прототип на базі ЩІ без необхідності розумітися на кубанітас чи хмарних мережах. Це потужно. Це саме те, що відділяє команди, готові до ереші, від тих, що залишаться позаду. Що це означає для вас? Вікно можливостей для створення платформи закривається. Не тому, що технологія зникає, а тому, що прірва між командами з платформами і без них швидко зростає. З кожним місяцем очікування команди, які вже мають платформи, вириваються вперед.

Вони випускають продукти швидше, менше вигорають і швидше адаптуються до нових інструментів. Команди без платформ дедалі більше відстають. Вибір за вами. Почніть з одного золотого шляху. Тож з чого насправді почати? Якщо ви сидите і думаєте, що вам потрібно побудувати цілу внутрішню платформу з нуля, зупиніться. Це найшвидший спосіб вбити проєкт ще до його початку. Найбільша помилка команд – намагатися побудувати все й одразу. Вони місяцями проєктують ідеальну платформу, намагаючись втиснути туди кожну функцію, яка спаде на думку. Потім вони запускають її, чують тишу. Ніхто нею не користується. Чому? Тому що вона вирішує проблеми, про які ніхто не просив, а для того, щоб просто почати, потрібно прочитати невелику інструкцію. Ось у чому справа – не робіть цього. Натомість почніть з малого. Справді спілкуйтеся з розробниками, а не з архітекторами, не з менеджерами і не з власними припущеннями.

Знайдіть людей, які щодня пишуть функціонал. Запитайте їх, що їм найбільше болить. Знайдіть робочий процес, який триває найдовше, дратує найбільше людей або який пропускають частіше, ніж варто було будинок. А потім побудуйте один золотий шлях від самого початку до кінця. Можливо, це створення та розгортання нового мікросервісу. Можливо, це налаштування середовища розробки з нуля. Можливо, це випуск термінового виправлення в продакшний безполомок. Оберіть те, що докучає найбільше, і побудуйте шлях, який усуне цей біль. Створіть його, протестуйте з реальними користувачами, зберіть відгуки, повторіть процес. Потім додайте ще один шлях, а після нього ще один. Не намагайтеся розв'язати всі проблеми одночасно. Вирішіть одну проблему дійсно добре і дозвольте цьому імпульсу рухати вас далі. Як зрозуміти, що це працює? Вимірюйте правильні речі. Час від ідеї до першого розгортання, кількість усунених ручних кроків та рівень добровільного прийняття.

Якщо розробники обирають ваш шлях, а не будують власний, ви перемагаєте. Якщо вони уникають його, вислухайте їх і змініть напрямок. Ось пастка, якої варто уникати. Не робіть платформу обов'язковою. Примушуйте розробників до свого шляху, і вони будуть обурюватися. Вони знайдуть способи обійти це. Вони створять власні скрипти і ховатимуть їх від вас. Натомість зробіть цей шлях легким. Зробіть його швидшим за альтернативи. Зробіть його очевидним вибором, але ніколи не єдиним. Перший шлях завжди найважчий. Він навчає вас усьому про продуктове мислення. Ви вчитися спілкуватися з користувачами, визначати пріоритети та розумієте, що створити те, що людям насправді потрібно, набагато важче, ніж просто щось робоче. Але коли ви зробите це одного разу, другий шлях стане легшим, а третій – ще легшим. Ви не будуєте платформу за один прийом. Ви будуєте її крок за кроком, шлях за шляхом. Отже, ось і вся система.

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