Англійська для платформ самообслуговування розробників

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

Ключовий словник

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

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

• “До IDP, розгортання нової служби вимагало черги з квитків, що тривала два тижні. Самообслуговування скоротило це до десяти хвилин робочого потоку. ”*

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

• “Ми створили золотий шлях для розгортання нової мікросервісу: шаблон сховища, попередньо налаштований конвеєр CI і майстер забезпечення середовища одним клацання.” *

** Escape hatch ** — навмисний механізм у платформі, який надає змогу досвідченим користувачам обійти золотий шлях і отримати доступ до примітивів інфраструктури нижчого рівня, коли стандартний робочий процес не задовольняє їх потреб. “Золотий шлях обробляє 90% наших випадків використання, але ми надаємо люк для виходу до необроблених манифестів Kubernetes для команд з незвичайними вимогами до планування.”

** Когнітивне навантаження ** — розумові зусилля, необхідні розробнику для розуміння, налаштування і роботи з інфраструктурою, що підтримує їхню програму. Зменшення когнітивного навантаження є основним цінним пропозицією IDP.

• “Приховуючи складність Kubernetes за командою розгортання платформи, ми зменшили когнітивне навантаження на команди продукту від необхідності розуміти 15 концепцій інфраструктури до необхідності розуміти три.” *

** Прийняття платформи ** — ступінь, до якого команди програм активно використовують IDP, а не керують власною інфраструктурою або використовують обхідні шляхи. *“Платформа прийнята на 70% продуктових команд. Ми проводимо інтерв’ю з іншими 30%, щоб зрозуміти, що їх блокує»

** Брусована дорога ** — синонім золотого шляху, який використовується у деяких організаціях, підкреслюючи інвестиції в інфраструктуру, які роблять рекомендований шлях гладким і швидким. “Ми називаємо це асфальтованою дорогою: ми зробили роботу з безпеки, спостережливості і відповідності, щоб команди не повинні були це робити.”

** Досвід розробника (DevEx) ** — загальна якість середовища, інструментів і потоків роботи, з якими щодня взаємодіють розробники програм, включаючи швидкість циклів зворотнього зв’ язку, ясність повідомлень про помилки і легкість впровадження. “Наша дорожня карта платформи керується показниками DevEx: частотою розгортання, часом відновлення і оцінками задоволеності розробників.”

Звичайні фрази

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

Приклади висловлювань

При подачі інвестицій в ІПП до інженерного керівництва:

• “Зараз, для впровадження нової мікросервісу розробник повинен приймати рішення щодо дванадцяти інфраструктурних доменів. Наша внутрішня платформа розробників зменшить це до трьох-полів форми і кнопки розгортання, скоротивши середній час до першого розгортання з трьох днів до менш ніж години. ”*

Коли я пояснював концепцію золотого шляху скептично налаштованому старшому інженеру: “Золотий шлях - це не мандат - це інвестиція. Ми підтримуємо його, документуємо його і підтримуємо його в стані стандартів безпеки. Команди, які слідують цьому, не витрачають часу на інфраструктурні роботи. Команди, які віддають перевагу іншому підходу, добре прийняті, але вони мають обов’язок підтримки.»

При представленні показників прийняття платформи у квартальному огляді: *“Прийняття зросло з 45% до 70% продуктових команд за шість місяців. Решта 30% — це в основному застарілі послуги з нестандартними залежностями. Ми будуємо цілеспрямовані люки для цих випадків, а не примушуємо міграцію»

Професійні поради

• Розрізняйте IDP (Internal Developer Platform — продукт) від IDPlatform team або platform engineering team (група, яка його створює) — абревіатуру іноді використовують для обох.
• Використовуйте “когнітивне навантаження”, а не “складність” в обговореннях зацікавлених сторін - це обрамляє проблему як проблему продуктивності розробника, а не технічну, яка краще резонує з лідерством.
• При введенні концепції ** люку для втечі ** завжди поєднуйте її з чітким твердженням про право власності: команда, яка використовує люк для втечі, є власником отриманої інфраструктури, а не команда платформи.
• Посилання ** CNCF’s Platform Engineering Maturity Model ** або ** Team Topologies ** при оформленні роботи IDP для керівництва - ці встановлені рамки надають довіри до дисципліни.

Практичні вправи

1. Розробник скаржиться, що золотий шлях IDP не підтримує їхній випадок використання. Які два варіанти ви б запропонували, і як би ви їх сформулювали з точки зору власності і підтримки?
2. Поясніть різницю між золотим шляхом і люком для втечі у двох реченнях, які підійдуть для нового члена команди, який приєднується до команди розробників платформи.
3. Напишіть одноречення, що визначає «досвід розробника», спрямований на керівника C-рівня, який запитує, чому компанії потрібна команда платформи.

Переклади: «Переклад з німецької мови»

Основна мета навчання професійної англійської мови в середовищі ІПП - це не тільки знати визначення таких термінів, як “пізнання” або “золотий шлях”. Це про те, як ви виражаєте ці поняття таким чином, щоб це було чітко, реалізовувалося і з повагою до ваших колег. Багато нерідних носіїв, зрозуміло, зосереджуються на прямому перекладі, що часто призводить до надмірно формального або заплутаного фразування. Розгляньте різницю між словами « Платформа має високе когнітивне навантаження » проти « Нам потрібно спростити досвід розробника, щоб зменшити когнітивне перевантаження. » Останнє набагато більш зрозуміле і запрошує до продуктивної дискусії.

Поширена пастка виникає при обговоренні потенційних проблем - особливо під час перегляду коду. Простий переклад критичного зауваження може звучати так: «Це затвердження вводить значний технічний борг». Хоча це технічно вірно, воно може звучати обвинувачуючим і демотивуючим. Кращий підхід був би: «Я турбуюся про довгострокову підтримку цієї секції через накопичену складність. Давайте обговоримо стратегії для переробки або розбиття завдання на менші, більш управлянні шматки.” Формулювання зворотнього зв’язку конструктивно - зосереджуючись на * впливі *, а не просто вказуючи на недоліки - є ключовим. Аналогічно, при описі змін у запиті на завантаження, уникайте надто технічного жаргону без контексту. Замість « Оптимізовано кінцеву точку API » спробуйте « Покращено продуктивність API для зменшення затримки для критичних потоків користувачів. »

Іншою ключовою областю є розуміння і використання стратегій прийняття платформи. Недостатньо просто збудувати самообслуговуючий IDP; вам потрібно активно заохочувати розробників ефективно використовувати його. Повідомлення Slack на кшталт: «Давайте всіх підключимо до нового процесу розгортання», звучить неоднозначно. Більш цілеспрямоване повідомлення може бути таким: «Щоб допомогти розробникам плавно перейти до автоматизованого конвеєра розгортання, ми створили короткі навчальні відео і спеціальний канал підтримки - будь ласка, звертайтеся, якщо у вас є якісь запитання!»

Нарешті, пам’ятайте, що точна мова має значення при обговоренні евакуаційних люків - тих ретельно розроблених резервних механізмів, вбудованих в систему. Погано сформоване твердження про люк для втечі може випадково заохотити розробників обійти стандартні процедури. Замість «У нас є вихід для цього», яснішим поясненням буде: «У разі непередбачених проблем, документована процедура відновлення доступна для швидкого відновлення сервісу»

Ось короткий приклад використання kubectl для ілюстрації керування розгортаннями і розуміння концепції послідовних оновлень:

kubectl set image deployment my-app --replicas=3 --image=my-app:v2.0

Ця команда показує просту зміну — оновлення версії штампу — яку, якщо її ефективно описати, можна описати як « Розгортання останньої версії програми з трьома репліками ». Ця коротка фраза набагато більш практична, ніж довгий технічний опис.