Розширений словник для інженерії платформи: IDP, Paved Road and More

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

---

Внутрішня платформа розробників (IDP)

** Внутрішня платформа розробників ** (IDP) — це набір інструментів, потоків робіт і можливостей самообслуговування, які команда платформи створює і підтримує для розробників програм.

IDP abstracts away infrastructure complexity so developers can deploy without filing tickets. — Ідентифікація інфраструктури

Ключові фрази:

• • build an IDP * — створити продукт платформи
• • поверхня IDP * — інтерфейси користувача і API платформи
• • Прийняття IDP * — ступінь, в якому розробники використовують його
• • вбудовувати IDP у роботу розробників * — інтегрувати його з існуючими інструментами

В. І. Павлюк

• IDP побудований вдома для потреб конкретної організації.
• PaaS (Platform as a Service) — комерційний продукт (наприклад, Heroku, Fly.io).
• «Наш IDP побудований на вершині Kubernetes, але ** приховує ** цю складність від команд застосунків.»

---

Пішохідна дорога

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

• «Слідуйте за ** асфальтованою дорогою ** і ви отримаєте моніторинг, попередження і CI / CD з коробки. ”
• Команди можуть ** вийти з асфальтованої дороги **, але повинні підтримувати власні інструменти
• «The paved road reduces decision fatigue by providing sensible defaults.» (англійською)

Споріднений термін: Золотий шлях

Деякі організації використовують золотий шлях (з інженерної культури Spotify) з тим же значенням:

• «Золотий шлях є позиційним потоком роботи, який рекомендує команда платформи»
• «Ми документуємо золотий шлях, щоб нові інженери були продуктивними з першого дня»
• «Золотий шлях не обов’язковий — команди можуть відхилятися з обґрунтуванням»

Різниця тонка: «мостова дорога» підкреслює інфраструктуру і операції; «золотий шлях» підкреслює подорож розробника і досвід впровадження.

---

Портал «Самопоміч»

** Портал самообслуговування ** (або портал розробника) дозволяє розробникам забезпечувати ресурси, переглядати документацію і керувати своїми службами без очікування відповіді від команди платформи.

Опис порталу

• Розробники можуть ** запустити ** нову службу за менш ніж п’ять хвилин через портал самообслуговування
• Портал ** виставляє ** каталог попередньо схвалених шаблонів інфраструктури
• «Ми відстежуємо портал рівень прийняття як ключову метрику інженерії платформи»
• Портал підтримується Backstage — платформою для порталу розробників з відкритим кодом

Спільні риси для обговорення

Feature	How to describe it
Service catalogue	”Lists all services, owners, and runbooks.”
Software templates	”Scaffolds a new service with all defaults baked in.”
TechDocs	”Hosts documentation co-located with the service repo.”
API catalogue	”Inventories all internal and external APIs.”

---

Зменшення когнітивного навантаження

Центральною метою інженерії платформи є **зменшення когнітивного навантаження ** - розумові зусилля, необхідні для розробників для створення і експлуатації програмного забезпечення.

Типи когнітивного навантаження (з Team Topologies framework)

• ** Внутрішня когнітивна навантаження ** — притаманна складність проблеми (неминуча)
• Зовнішнє когнітивне навантаження — складність, нав’язана інструментами і процесами (зменшується)
• ** Германе когнітивна навантаження ** — зусилля, що будують корисне розуміння (цінне)

Використовуючи ці терміни

• «Робота команди платформи полягає в тому, щоб **зменшити зайве когнітивне навантаження ** на потокові команди.»
• «Наш дев’ятиступінчастий процес розгортання додавав непотрібне когнітивне навантаження — ми автоматизували його»
• «Стандартизуючи CI-конвейер, ми дозволяємо розробникам зосередитися на логіці продукту»

---

Команди, що вирівняні за потоком і команди платформи

Ці концепції взято з ** Team Topologies ** (Skelton & Pais) і широко використовуються у дискусіях щодо розробки платформ:

• ** Команда, вирівняна за потоком ** — команда, вирівняна за потоком користувацької цінності (продукт або послуга)
• ** Platform team ** — забезпечує внутрішні продукти, які зменшують потокове вирівнювання когнітивного навантаження команди
• ** Вдосконалення команди ** — допомагає іншим командам прийняти нові інструменти або методи
• Команда складних підсистем — володіє технічно складним компонентом

У розмові

• «Команда платформи ** обслуговує ** потокові команди як внутрішні клієнти.»
• «Ми вимірюємо успіх платформи за тим, скільки ** труду ** ми вилучаємо з продуктових команд.»
• «Команда, що забезпечує, провела ** гільдію ** на найкращих практиках спостережливості.»

---

Вимірювання успіху платформи

Команди платформи повинні обговорювати метрику англійською мовою:

• ** Метрики DORA ** — Частота розгортання, Час виконання, Частота помилок змін, MTTR
• «Наша платформа поліпшилася ** частота розгортання ** з щотижневої до щоденної у всіх потокових командах.»
• «Ми скоротили час на борту нової служби з двох тижнів до одного дня.»
• Задоволеність розробників (вимірюється за допомогою NPS або квартальних опитувань) є нашою північною зіркою

---

Ключеві моменти

• IDP — внутрішній продукт платформи, створений для самообслуговування розробників
• ** Брусована дорога / золота стежка ** — рекомендована, підтримувана інженерна стежка
• ** Портал самообслуговування ** — інтерфейс, за допомогою якого розробники отримують доступ до можливостей платформи
• Зменшення когнітивного навантаження — основна цінність пропозиції команди платформи
• Страйк-вирівняна проти платформова команда — Командний словник топологій для організаційної структури
• ** Метрика DORA ** — стандартна система вимірювання впливу платформи

Розвиток мовлення: проблеми та перспективи

Багато розробників, які вивчають професійну англійську, особливо ті, що переходять з мов з різними фразами, знаходять певні терміни в інженерії платформи на диво складними. Це не просто про те, щоб знати визначення; це про те, як ці терміни використовуються - тонкі наслідки і очікування, які вони передають в культурі DevOps. Давайте розглянемо деякі часті перешкоди і запропонуємо практичні рекомендації.

Одна з областей плутанини часто зосереджена навколо «мостової дороги». Ця фраза часто використовується для опису внутрішньої платформи розробників (IDP), яка забезпечує спрощений, добре визначений шлях для розробників для розгортання застосунків - по суті, зменшуючи тертя і неоднозначність. Однак, це * не * тільки про простоту використання; це означає рівень стабільності, передбачуваності і управління. «Брокова дорога» не означає, що розробники повністю звільнені від відповідальності або можуть просто ігнорувати найкращі практики. Замість цього, він пропонує IDP забезпечує фундаментальні інструменти і процеси для * підтримки * цих найкращих практик, мінімізуючи ручне втручення і зменшуючи ризик помилок. Подумайте про це як про добре утримувану автостраду проти некартографованої грязової доріжки — обидві доведуть вас до місця призначення, але одна з них значно надійніша і ефективніша. Це розуміння є ключовим при обговоренні з зацікавленими сторонами; сказати «ми будуємо асфальтовану дорогу» негайно повідомляє, що ви зосереджуєтеся на * надійності * і * послідовності *, а не просто на простоті.

Ще одне поширене нерозуміння пов’ язане з поняттям « зменшення когнітивного навантаження ». Це стосується не спрощення речей поверхневим способом, а стратегічного зменшення розумових зусиль, необхідних розробникам для виконання їх основних завдань. Розглянемо повідомлення Slack: « Привіт, команда, чи може хтось надати точну команду для розгортання цього на стадії тестування? Я спробував deploy --environment staging і він зазнав невдачі. ”  Розробник, який бореться з цим, буде відчувати високу когнітивну навантаження - вони борються з незнайомими командами, виправленням помилок і, можливо, консультуванням декількох джерел. IDP, розроблений для когнітивного зменшення навантаження, пропонує одну, інтуїтивну команду, або, можливо, навіть автоматизований процес розгортання, запускається простою дією, вилучаючи необхідність для розробників боротися зі складними конфігураціями.

Нарешті, при описі можливостей IDP у описі Запиту на завантаження, уникайте надмірно технічного жаргону, який може залякати менш досвідчених членів команди. Замість того, щоб сказати «Ми використовуємо декларативну інфраструктуру як код через Terraform і реалізуємо нестандартний рушій політики», спробуйте щось більш доступне: «Ця PR автоматизує процес розгортання нових функцій за допомогою нашої внутрішньої платформи розробників, оптимізуючи робочий процес і зменшуючи потенційні помилки»

# Example: Using kubectl to deploy a simple pod
kubectl apply -f my-pod.yaml

Сама по собі ця команда є простою, але * контекст * - що це частина автоматизованого процесу розгортання, яким керує IDP - це те, де лежить справжнє значення. Сфокусування на результатах і перевагах (зменшення когнітивного навантаження, підвищення надійності) буде резонувати більш ефективно, ніж просто перелік інструментів, що використовуються.