Platform Engineering Vocabulary: IDP, Golden Paths, and Developer Portals (англійською)
Внутрішня платформа розробника, золотий шлях, самообслуговування, будівельні леса і інженерний словник платформи для інженерів.
Платформа інженерія тихо стала однією з найшвидше зростаючих дисциплін у розробці програмного забезпечення. Оскільки організації масштабують свої інженерні команди, тертя при встановленні трубопроводів, налаштуванні інфраструктури і навігації внутрішніми інструментами починає сповільнювати всіх. Платформа інженерії існує для вирішення саме цієї проблеми - і вона розвинула свій власний багатий словник по дорозі. Незалежно від того, приєднуєтеся ви до команди розробників платформи, співпрацюєте з нею або просто читаєте описи робіт, у яких згадуються « золоті шляхи » і « ІДП », цей посібник допоможе вам впевнено говорити цією мовою.
Основні терміни
** Внутрішня платформа розробника (IDP) ** - шар самообслуговування, побудований на основі інфраструктури і інструментів компанії. Це зменшує складність, щоб розробники програм могли створювати середовища, розгортати служби і керувати налаштуваннями без підняття квитків або очікування на команди операцій.
“Ми нарешті відправили IDP в минулому кварталі. Тепер будь-який інженер може створити нове середовище мікросервісів за десять хвилин, не торкаючись Terraform безпосередньо»
«IDP не замінює нашого хмарного провайдера — він просто обгортає наші стандарти навколо нього, тому команди перестають робити речі дванадцятьма різними способами»
** Золотий шлях ** — рекомендований, добре підтримуваний шлях для створення і розгортання програмного забезпечення у організації. Це не обов’ язково, але це шлях, який йде з документацією, підтримкою інструментів і кимось, кому можна зателефонувати, якщо щось не так.
«Ми називаємо це золотим шляхом, тому що ми зробили всю важку роботу — сканування безпеки, маркування вартості, спостережність — це запечено. Ви можете йти по бездоріжжю, але тоді ви на самоті»
“Чи слідує ваша служба золотим шляхом? Якщо ні, перегляд безпеки займе втричі більше часу»
Paved road — синонім золотого шляху, широко використовуваний в Netflix і в більш широкому інженерному співтоваристві платформ. Метафора підкреслює, що шлях є гладким, а не просто правильним. Деякі команди використовують обидва терміни, де асфальтована дорога відноситься до інструментів і золотий шлях до загального потоку роботи.
«Ми витратили шість місяців, щоб прокладати дорогу для послуг gRPC. Тепер набір нового займає післяобідній час замість тижня»
** Самообслуговування ** — принцип, що розробники можуть виконувати інфраструктурні та операційні завдання самостійно, через портал або CLI, без залучення іншої команди. Самообслуговування є основним цінним пропозицією більшості внутрішньо переміщених осіб.
«До IDP, кожен запит на базу даних проходив через Jira-квиток до команди платформи. Тепер це самообслуговування — ви заповнюєте форму і вона забезпечується за кілька хвилин»
Портал розробників і каталогізація
** Портал розробників ** — веб- інтерфейс, який слугує як входи до внутрішньої платформи розробників. Зазвичай, це включає каталог програмного забезпечення, документацію, шаблони і посилання на внутрішні інструменти. Backstage є найбільш широко прийнятою відкритою платформою для створення порталів розробників.
«Наш портал розробників — це єдине місце, де ви можете знайти кожну службу, її власника, її runbook і як її розгорнути. Він замінив близько п’ятнадцяти розкиданих вікі»
Backstage — відкритий портал для розробників, створений Spotify, тепер проект CNCF. Команди використовують його для створення власних внутрішніх порталів, підключаючи плагіни для каталогізації послуг, видимості CI / CD, хмарних панелей вартості і багато іншого.
«Ми будуємо на Backstage, а не з нуля. Екосистема плагінів зберегла нам місяці роботи»
«Backstage не дасть вам портал з коробки — це дасть вам леса, щоб побудувати такий, який підходить вашій організації»
** Каталог програмного забезпечення ** — реєстр всіх служб, бібліотек, API і конвеєрів даних у організації, зазвичай з метаданими, такими як власник, стадія життєвого циклу, посилання на документацію і залежності. У контекстному меню каталог є основною функцією, до якої підключаються всі інші компоненти.
«Каталог програмного забезпечення нарешті відповів на питання «хто володіє цією службою?», У нас було шість речей, які називалися user-service, і ніхто не знав, які з них були канонічні
** Технічний радар ** — візуальний інструмент, популяризований компанією ThoughtWorks, який поділяє технології на чотири категорії: Прийняти, Випробувати, Оцінити і Тримати. Команди платформи публікують внутрішні технічні радари, щоб керувати технологічним вибором в організації.
“Перевірте технічний радар перед вибором нової бібліотеки. Якщо це на Затримці, вам знадобиться сильний аргумент, щоб отримати його схвалення»
“Ми перенесли Кафку на радар Adopt в минулому місяці. Команда платформи тепер має золотий шлях для цього»
** Скеле (шаблон служби) ** — попередньо налаштований шаблон проекту, який створює код, файли налаштувань і конвеєр CI для нової служби. Коли розробник створює нову мікросервіс, скелет робить важкий підйом, так що результат вже відповідає внутрішнім стандартам з першого дня.
«Використовувати шаблон для нових сервісів Go. Він дає вам журналювання, відстеження, Dockerfile і робочий конвеєр за близько двох хвилин»
“Ми модернізували лісові леса минулого тижня, щоб включити новий сканер безпеки. Кожна служба, створена з цього моменту, отримує його автоматично»
Структура та функції генома
** Команда розробників платформи ** — команда, яка створює і підтримує внутрішню платформу розробників. Вона відноситься до інших інженерних команд як до своїх клієнтів і приоритизує зменшення їх когнітивного навантаження. Команда платформи не доставляє функції кінцевого користувача безпосередньо; вона доставляє інструменти та інфраструктуру, що дозволяє іншим командам робити це швидше.
«Команда платформи, по суті, створює продукт — наш продукт — це IDP. У нас є backlog, дорожня карта, і ми проводимо дослідження користувачів з розробниками»
** Команда, вирівняна за потоком ** — термін з * Командних топологій *, що описує команду, вирівняну за потоком бізнес- цінностей або області продукту. Команди, вирівняні потоком, є основними споживачами того, що створюють команди платформи. Вони повинні мати змогу працювати автономно без важкої координації з іншими командами.
“Ми реструктурували в потокові команди минулого року. Кожна команда володіє повним стеком від бази даних до інтерфейсу користувача, що означає, що нам потрібна платформа для обробки недиференційованого важкого навантаження»
** Team Topologies ** — книга і організаційна структура, створена Matthew Skelton і Manuel Pais, яка визначає чотири типи команд (з потоком, платформою, підтримкою, складною підсистемою) і три режими взаємодії. Це стало домінуючим ментальною моделлю того, як інженерні команди платформи розташовують себе в організації.
«Якщо ви не читали Team Topologies, це пояснює, чому ми структурували команду платформи так, як ми це зробили. Вся ідея полягає в мінімізації когнітивного навантаження на потокові команди.»
** Зменшення когнітивного навантаження ** — мета полягає у тому, щоб полегшити розробникам зосередитися на їх власній області завдяки зменшенню розумових зусиль, необхідних для роботи з інфраструктурою, розуміння інструментів або навігації по внутрішніх системах. Платформа інженерії формує себе як когнітивне навантаження зменшення вправ для решти інженерії.
«Кожного разу, коли розробник повинен запам’ятати три різні CLI-інструменти, щоб їх розгорнути, це когнітивне навантаження, яке ми повинні зняти з їхнього диска»
Вимірювання досвіду розробника
** NPS розробника ** — чистий бал промоутера, адаптований для внутрішнього досвіду розробника. Команди платформи опитують розробників за допомогою запитань на кшталт «Наскільки ймовірно, що ви рекомендуєте нашу внутрішню платформу колегі?», Щоб відстежувати задоволення з часом.
«Наш розробник NPS піднявся з 12 до 38 після того, як ми відправили самообслуговування бази даних. Це найвищий показник за останні два роки»
SPACE framework — це рамка продуктивності розробників від Microsoft Research, яка вимірює п’ ять вимірів: Задоволеність і добробут, Виробнича продуктивність, Активність, Комунікація і співпраця, Ефективність і потоки. Він використовується як альтернатива спрощеним метрикам, таким як рядки коду або об’єднані PR.
«Ми використовуємо SPACE framework для вимірювання впливу платформи. Метрики активності самі по собі не розуміють суті — задоволення розробників і стан потоку мають таке ж значення»
«Коли виконавча команда запитує, чи IDP покращив продуктивність, ми звертаємо їх до доповіді SPACE, а не сперечаємося про частоту розгортання в ізоляції»
Як використовувати їх у розмові
Ці терміни з’являються в виступах, оглядах дизайну, розмовах про найм і інженерних блогах. Ось кілька реалістичних сценаріїв.
** Сценарій 1 — Впровадження нової служби: **
“Мені потрібно створити нову службу оповіщення про платежі. Чи я використовую шаблон леса в порталі розробника, або є золотий шлях документації, яким я повинен слідувати спочатку?»
** Сценарій 2 — Обговорення структури команди в інтерв’ю: **
“Моя теперішня роль - в команді платформи. Ми підтримуємо близько дванадцяти потокових команд, і наша основна увага в цій половині полягає в зменшенні когнітивного навантаження - зокрема, самообслуговування міграції баз даних і кращий каталог програмного забезпечення. ”
** Сценарій 3 — Оцінка технологічних варіантів:**
“Перед тим, як ми зобов’язуємося до цього нового інструмента спостережливості, давайте подивимося, де він сидить на технічному радарі. Если это в суде, мы должны документально оформить решение. Якщо він у режимі затримки, нам потрібна розмова з командою платформи»
** Сценарій 4 — Звітування про вплив платформи:**
«Ми представимо обзор платформи Q2 лідерам, використовуючи наш тренд NPS розробників і метрики SPACE. IDP заощадив приблизно 400 годин часу розробника в останньому кварталі на основі обсягу запитів самообслуговування»
Швидка реакція
| Term | Short Definition |
|---|---|
| IDP | Self-service layer over company infrastructure for developers |
| Golden path | The recommended, well-supported route for building services |
| Paved road | Synonym for golden path; emphasises smooth tooling, not just process |
| Scaffolding | Project template that generates a compliant new service automatically |
| Developer portal | Web UI that is the front door to an IDP (Backstage is common) |
| Software catalog | Registry of all services with ownership and metadata |
| Tech radar | Adopt/Trial/Assess/Hold categorisation of internal technologies |
| Cognitive load reduction | Removing mental overhead so developers focus on their domain |
| SPACE framework | Microsoft Research model for measuring developer productivity |
| Developer NPS | Internal satisfaction score for platform and tooling quality |