Словник для інженерів платформи

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

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

---

Основні поняття

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

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

“Наша IDP дозволяє розробникам запустити нову службу за менше ніж десять хвилин, включаючи CI/CD конвеєр, моніторинг і забезпечення баз даних.”

“Ми розробляємо IDP поступово — починаючи з автоматизації розгортання, а потім переходячи до самообслуговування створення бази даних.”

** Зауваження: ** IDP іноді плутають з * Portal * внутрішнього розробника (також IDP). Портал є * інтерфейсом користувача * для платформи; платформа є ширшим набором можливостей.

Портал розробників

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

“Портал розробників містить все, що потрібно розробнику: каталог послуг, runbooks, стан розгортання і панелі вартості.”

• “Ми використовуємо Backstage як основу для нашого порталу розробників.” *

Самообслуговування

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

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

---

Шляхи і стандарти

Золотий шлях

Золотий шлях (іноді називається мостом) є обраним, підтримуваним і рекомендованим способом створення і розгортання служб в організації. Це не мандат — але це шлях, який команда платформи робить найпростішим для дотримання.

“Наш золотий шлях використовує TypeScript, GitHub Actions і PostgreSQL на RDS. Команди можуть відхилятися, але вони мають право на підтримку будь-чого з шляху.»

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

Дорога асфальтована

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

• “Якщо ви залишитеся на асфальтованій дорозі, платформа автоматично обробляє спостереження, масштабування і латки безпеки.” *

Каталог послуг

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

“Каталог послуг показує, що служба платежу належить команді Bravo, працює на двох екземплярах і має 99,95% доступності SLO.”

---

Список топонімів Слов’янська

Топологія команди є широко відомою книгою і основою для організації інженерних команд. Його словник став поширеним в дискусіях з інженерії платформ.

Команда Stream-Aligned

** Stream-aligned team ** зосереджена на наданні цінності вздовж одного продукту або подорожі користувача. Більшість продуктових команд є потоково-вирівняними.

“Команда з оформлення оплати є збалансованою — вони є власниками всіх можливостей оформлення оплати клієнта від початку до кінця.”

Команда платформи

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

“Команда платформи забезпечує інструменти розгортання, стеки спостережливості і середовища розробників, щоб командам продукту не потрібно було будувати їх самостійно.”

Увімкнення команди

** Вдосконалююча команда ** допомагає іншим командам прийняти нові можливості або практики - тренування, а не робити.

“Команда з безпеки провела семінари, щоб допомогти командам продукту реалізувати моделювання загроз у процесі проектування.”

Когнітивне навантаження

Когнітивна нагрузка - это умственные усилия, необходимые для эффективной работы. Платформа інженерії має на меті зменшити когнітивне навантаження на команди продукту.

“Кожне рішення щодо інфраструктури, яке розробник продукту повинен прийняти, є когнітивним навантаженням, яке ми не змогли поглинути як команда платформи.”

---

Досвід розробника (DevEx)

Досвід розробника (DevEx або DX)

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

“Ми вимірюємо досвід розробників за допомогою квартальних опитувань і відстежуємо такі показники, як час до першого затвердження для нових інженерів.”

Пересунути ліворуч

** Пересунути ліворуч ** означає пересунути практику (зазвичай тестування або безпеку) на початок циклу розробки.

“Наша платформа переносить безпеку вліво, автоматично запускаючи сканування SAST при кожному запиті на витягування, замість очікування перегляду безпеки перед випуском.”

Дора Метрікс

** Метрики DORA ** (з програми досліджень і оцінки DevOps) є чотирма ключовими показниками продуктивності доставки програмного забезпечення:

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

• “Ми відстежуємо показники DORA щоквартально. Наша частота розгортання тепер 12 разів на день, з двох разів на тиждень до інвестицій платформи. “*

---

Практичні фрази для інженерів платформи

• • “Це дозволить зменшити навантаження на команди, що працюють у потоці.” *
• “Ми визначили золотий шлях для розгортання нової служби — документація знаходиться на порталі.”
• • « Самообслуговування бази даних доступне за допомогою IDP — не потрібні квитки. » *
• • “Ми вимірюємо вплив цих змін на показники DORA.” *
• “Команді, яка відхиляється від викладеного маршруту, належить відповідальність за оперативні наслідки цього рішення.”

---

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

Навигація ландшафтом — практичний підхід до інженерії платформ

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

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

Розглянемо повідомлення Slack від розробника, який бореться з новим API: “Це так заплутано! Я не знаю, як інтегрувати це в мій робочий процес. ” Відповідь, зосереджена виключно на технічних деталях - “Вам потрібно використовувати метод POST з даними JSON і обробляти коди помилок…” - ймовірно, погіршить проблему. Замість цього, досвідчений інженер може відповісти: «Давайте дослідимо золотий шлях для інтеграції зовнішніх служб. У нас є попередньо створений коннектор, який спрощує цей процес і надає чітку документацію. Давайте пройдемо через це разом. “Ця рамка підкреслює ширший дизайн системи і доступну підтримку, а не занурюється в низькорівневі технічні аспекти, визнаючи потенційне розчарування розробника незнайомою термінологією.

Іншою областю, де чіткість є критичним є розуміння * Командні топології *. Визнаючи, що різні команди працюють найкраще, використовуючи різні структури - від Streamlined до Nexus - може запобігти неправильному спілкуванню і дублюванню зусиль. Формування його як «як команди * працюють разом *», а не жорсткий набір правил дозволяє більш гнучке впровадження і зменшує ризик відчуття пригніченості складними організаційними моделями. Це розуміння того, чому структура існує, а не просто запам’ятовування термінології.

# Example CLI Usage (Terraform) - Demonstrating Infrastructure as Code

terraform {
  required_providers {
    aws = { ~> 1.38 }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "example" {
  ami           = "ubuntu/latest"
  instance_type = "t2.micro"

  tags = {
    Name = "MyExampleInstance"
  }
}

Цей простий приклад Terraform ілюструє, як реалізована основна інженерна концепція платформи — інфраструктура як код. Використання ami, instance_type, і tags є чітко визначеними термінами в контексті управління хмарною інфраструктурою, яка є спільною областю для роботи інженерів платформи. Ключовим моментом тут є не тільки сам код, але і те, як він сприяє добре визначеному, автоматизованому процесу - вирівнюючи принцип «викладеної дороги» для розгортання і управління ресурсами. Зрозуміння цих основних концепцій дозволяє ефективніше спілкування і співпрацю в інженерній команді.