English for Internal Developer Platform Teams: Golden Paths and IDP Vocabulary (англійською)
Золотий шлях, леса, когнітивне навантаження, Backstage — освоїти англійську лексику платформи, яку інженерні команди використовують для обговорення досвіду розробників і дизайну IDP.
Внутрішні платформи розробників (IDP) змінюють те, як працюють інженерні організації, а мова навколо них швидко розвивається. Якщо ви працюєте у команді з розробки платформи або співпрацюєте з нею, розуміння того, як правильно використовувати цей словник, допоможе вам упевнено брати участь у обговореннях плану дій, презентаціях учасників і щоденних зустрічах.
Цей пост зосереджений на тому, як ці слова використовуються в реальних розмовах, а не лише на тому, що вони означають.
Основні інженерні терміни платформи
** Золотий шлях ** (також * асфальтована дорога *) стосується рекомендованого, підтримуваного шляху для створення і розгортання програмного забезпечення всередині організації. Метафора важлива: це шляхетний, а не правило — команди можуть залишити його, але це означає менше підтримки.
«Ми хочемо, щоб всі нові мікросервіси слідували золотому шляху — Kubernetes, стандартному шаблону CI і нашому внутрішньому стеку спостережливості»
“Команда фронт-енду пішла з золотим шляхом, використовуючи нестандартний пакет. Вони мають це рішення, але команда платформи не буде підтримувати його безпосередньо»
Зауважте, як інженери використовують follow з золотим шляхом, і go off, коли команда відхиляється.
** Брусована дорога ** майже синонім з золотим шляхом, але підкреслює зусилля команди платформи, які вона докладає для того, щоб зробити маршрут гладким. Ви почуєте обидві фрази, іноді в одній і тій же організації.
«Наша робота — зробити асфальтовану дорогу настільки привабливою, щоб команди вибирали її, а не тому, що вони змушені це робити»
** Портал розробників ** — це центральний інтерфейс користувача — зазвичай це веб- програма — за допомогою якого розробники знаходять служби, API, шаблони і документацію. Інструмент з відкритим кодом Spotify Backstage є найпоширенішою реалізацією.
“Ми запрошуємо шість нових команд у наступному кварталі. Портал розробників повинен бути єдиною точкою входу, щоб їм не потрібно було полювати через Confluence і Slack»
** Самообслуговування ** описує модель, де розробники можуть забезпечувати інфраструктуру, створювати сховища або розгортати середовища без очікування на схвалення іншої команди або ручні дії.
«Ми перейшли до моделі самообслуговування для забезпечення баз даних. Розробники надсилають запит через портал і отримують екземпляр Postgres, який запускається менш ніж за дві хвилини»
Протилежне самообслуговування часто називається * процесом, що керується квитками * або * ручним схваленням * - і в розмовах з інженерією платформи ці фрази мають негативну конотацію.
Розповідь про досвід розробника
** Досвід розробника (DX) ** — це якість досвіду, який інженери мають під час використання внутрішніх інструментів, API і потоків робіт. Це основний продукт команди платформи.
“Ми провели дослідження DX минулого місяця. Найбільшою проблемою був непослідовний локальний розробник — кожна команда мала свій підхід»
** Скелетобудування ** стосується шаблонів коду або скелетів проектів, які допомагають розробникам швидко розпочати роботу без прийняття рішень низького рівня. У контексті платформи, скелетування часто надається через портал розробника.
«Ми побудували шаблон для Go-сервісів — він включає в себе ведення журналу, відстеження і кінцеву точку перевірки стану безпосередньо з коробки»
Onboarding в контексті платформи не означає найняття нових працівників. Це відноситься до процесу введення нової команди або сервісу на платформу.
«Опитування на нових послугах все ще занадто ручне. Нам потрібен майстер в порталі, який веде команди через кроки налаштування»
** Когнітивне навантаження ** — це мірою розумових зусиль, необхідних для розуміння або виконання завдання. Зменшення когнітивного навантаження є центральною метою інженерії платформи.
«Розробникам не потрібно розуміти внутрішні процеси Terraform, щоб розгорнути службу. Нам потрібно абстрагувати це і зменшити когнітивне навантаження»
Ви часто почуєте reduce, lower або minimise у поєднанні з когнітивним навантаженням.
Команда проти платформи Продуктовий ринок
Поширена розмова в інженерії платформи пояснює різницю між ** платформою команди ** (яка створює внутрішні інструменти для інших інженерів) і ** командою продукту ** (яка створює функції для зовнішніх клієнтів). Розрізнення має значення, тому що команди платформи використовують * продуктове мислення * застосоване до внутрішніх користувачів.
«Ми ставимося до інженерії платформи як до розробки продукту. Розробники - наші клієнти. Ми проводимо інтерв’ю з користувачами, збираємо зворотній зв’язок і визначаємо пріоритети на основі проблемних питань розробників»
«Команда платформи відповідає за золотий шлях, але команда продукту володіє бізнес-логікою. Цей кордон важливий»
Фрази для зустрічей і презентацій
Використовуйте їх у виступах, оглядах планів і презентаціях для зацікавлених сторін:
- “Ми працюємо над тим, щоб скоротити час до першого розгортання нових сервісів.”
- “Робочий процес самообслуговування працює, але прийняття є низьким — нам потрібно інвестувати в документацію і просування.”
- “Команди, що слідують золотому шляху, мають приблизно на 30% швидші цикли розгортання.”
- “Backstage є нашим джерелом правди для власників послуг і контрактів API.”
- “Ми збираємо DX-метрики — час циклу, частоту помилок змін, і оцінки задоволення розробників.”
Ключові слова
| Collocation | Example |
|---|---|
| follow the golden path | ”All new teams are expected to follow the golden path.” |
| reduce cognitive load | ”This abstraction reduces cognitive load significantly.” |
| self-service provisioning | ”Self-service provisioning cuts ticket wait time to zero.” |
| improve developer experience | ”Our Q3 goal is to improve developer experience across all squads.” |
| onboard a new service | ”We onboarded three services onto the platform this sprint.” |
| drive platform adoption | ”We need to drive adoption before the end of the year.” |
Practice
Напиши три-речення оновлення для платформи команди standup. Включіть: одну річ, яку ваша команда відправила цього тижня (використовуйте * самообслуговування * або * скелі *), одну метрику, яку ви стежите (використовуйте * когнітивне навантаження * або * DX *), і один блокуючий або наступний крок (використовуйте * золотий шлях * або * впровадження *). Прочитайте його вголос — чи можете ви вільно сказати його, не затримуючись на словнику?
Наприклад, слово «навигація» означає: пошук невідомих об’єктів
Основні поняття золотих шляхів, скелі і когнітивного навантаження - терміни, які часто зустрічаються в дискусіях навколо внутрішніх платформ розробників (IDP) - можуть бути складними для не-англомовних носіїв англійської мови. Це не просто про те, щоб знати визначення; це про розуміння * як * ці поняття вкладені в професійний контекст. Нерозуміння тут може призвести до неправильних очікувань, неефективних робочих потоків і, врешті-решт, розчарування. Розглянемо деякі поширені пастки і те, як вони проявляються в повсякденних взаємодіях.
Одна з часто зустрічається областей плутанини виникає з тонких відмінностей між «Золотим шляхом» і просто «найкращою практикою». У той час як «найкраща практика» часто відчувається як набір правил – щось, що *слідувати * – Золотий шлях передбачає *оптимізований потік *. Подумайте про коментар перегляду коду: замість того, щоб сказати, « Цей перенесення порушує найкращі практики щодо іменування гілок, » більш ефективним формулюванням було б, « Давайте вдосконалити цей PR, щоб вирівняти з встановленим Золотим шляхом для розробки можливостей, забезпечуючи послідовне гілля і чітке спілкування протягом усього процесу. Це зменшить когнітивне навантаження для рецензентів.» «Золотий шлях» підкреслює ефективність і зменшує тертя, в той час як «найкраща практика» може відчуватися як довільне обмеження. Аналогічно, при описі нового інструмента леса в Pull Request, заява «Це лесопилка дозволяє нам дотримуватися найкращих практик» є менш вражаючим, ніж «Це лесопилка полегшує Золотий шлях для створення мікросервісів, зменшуючи вручну налаштування і прискорюючи розгортання»
Інша проблема полягає у використанні технічного жаргону. Такі терміни, як «позитивна навантаження» — що стосується розумових зусиль, необхідних для виконання завдання — можуть здатися абстрактними. Розробник може стикатися з проблемою з концепцією, якщо вони не є явно пов’язаними з ідеєю оптимізації робочих потоків для зменшення непотрібних кроків. Розробка його в рамках практичного сценарію допомагає: «Ми вводимо цей новий компонент IDP, щоб полегшити когнітивне навантаження під час процесу впровадження, що дозволяє розробникам зосередитися на кодуванні, а не на боротьбі з налаштуванням інфраструктури».
Нарешті, пам’ятайте, що ясність і точність є найважливішими. Неоднозначність у фразування може легко призвести до неправильного тлумачення. Під час обговорення налаштувань Backstage, уникайте нечітких тверджень, таких як «Це покращує платформу». Замість цього, вкажіть * як * це покращує платформу — «Реалізуючи цю конфігурацію Backstage, ми спрощуємо доступ до наших внутрішніх служб, вирівнюючи з Золотим шляхом для виявлення послуг і скорочуючи час набору розробників»
# Example: Using `backstage-cli` to deploy a new app configuration.
backstage-cli apps deploy --app my-new-app --config ./my-new-app.jsonЦя команда показує практичне застосування налаштування Backstage, підкреслює ідею структурованого шляху і керованого розгортання — основних елементів у вирівнюванні з проектом IDP. Сфокусування уваги на певних діях і їх впливі сприяє ясному спілкуванню і зменшує неоднозначність під час обговорення цих складних концепцій у вашій команді.