CNPA: Огляд основ платформ

Складність: [СЕРЕДНЯ]

Час на проходження: 75-95 хвилин

Передумови: Базові знання DevOps, концепції робочих навантажень Kubernetes, основи CI/CD та орієнтаційний модуль CNPA

Напрямок: Підготовка до іспиту CNPA | Основи платформ

Результати навчання

Після завершення цього модуля ви зможете:

• Проаналізувати, як платформенна інженерія знижує когнітивне навантаження розробників, не відбираючи у команд відповідальність та підзвітність.
• Порівняти платформенну інженерію, DevOps та SRE, оцінивши їхні цілі, операційні моделі та сценарії відмов у реалістичних ситуаціях.
• Спроєктувати простий золотий шлях (golden path), що поєднує самообслуговування, політику, спостережуваність та документацію в зручний робочий процес для розробника.
• Оцінити, чи діє внутрішня платформа для розробників як продукт, як портал, чи як черга тікетів із приємнішим брендингом.
• Діагностувати типові пастки іспиту CNPA, пов’язані з захисними механізмами (guardrails), автоматизацією, прийняттям, зрілістю платформи та досвідом розробника.

Чому цей модуль важливий

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

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

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

Основний зміст

1. Платформа існує, щоб зменшувати повторювану складність

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

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

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

+----------------------+        +------------------------+        +----------------------+
| Repeated team needs  |        | Platform capabilities  |        | Developer outcomes   |
|----------------------|        |------------------------|        |----------------------|
| Service scaffolding  | -----> | Golden path templates  | -----> | Faster first deploy  |
| CI/CD configuration  | -----> | Standard pipelines     | -----> | Fewer broken releases|
| Runtime environments | -----> | Self-service requests  | -----> | Less ticket waiting  |
| Secrets and identity | -----> | Guardrailed workflows  | -----> | Safer defaults       |
| Logs, metrics, traces| -----> | Observability baseline | -----> | Faster diagnosis     |
+----------------------+        +------------------------+        +----------------------+

Найважливіше слово на діаграмі — “результати” (outcomes). Можливість платформи цінна не тому, що вона існує. Вона цінна тоді, коли вимірюваним чином змінює досвід доставки. Шаблон, яким ніхто не користується, не є золотим шляхом. Портал, який пересилає запити до ручної черги, не є справжнім самообслуговуванням. Політика, яка блокує розгортання, не пояснюючи, як усунути проблему, не є корисним захисним механізмом. Питання CNPA часто ховають ці відмінності в правдоподібних формулюваннях, тож шукайте результат, а не ярлик.

Зупиніться та подумайте: Команда каже: “У нас є портал для розробників, отже, у нас є внутрішня платформа для розробників”. Які докази ви попросили б, перш ніж погодитися? Зосередьтеся на тому, що розробники справді можуть зробити, не чекаючи на ручну передачу.

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

Питання про платформу	Слабка відповідь	Сильніша відповідь у стилі CNPA
Яку проблему розв’язує платформа?	Вона дає розробникам портал.	Вона зменшує повторювану складність доставки через підтримувані можливості самообслуговування.
Хто є користувачами?	Будь-хто, хто подає тікети на інфраструктуру.	Внутрішні розробники й оператори, які споживають продукти платформи, щоб випускати та запускати сервіси.
Як вимірюється успіх?	Кількість встановлених інструментів.	Прийняття, час виконання (lead time), надійність, навантаження на підтримку, задоволеність розробників та безпечні результати доставки.
Що слід стандартизувати?	Усе можливе.	Повторювані робочі процеси, де спільні стандартні налаштування знижують ризик, не блокуючи виправдані відмінності.
Що має залишатися гнучким?	Нічого, бо гнучкість створює дрейф.	Специфічні для робочого навантаження рішення, які команди можуть обґрунтувати й опрацьовувати в межах захисних механізмів.

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

2. Платформенна інженерія, DevOps та SRE пов’язані, але не тотожні

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

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

+-------------------------+--------------------------+------------------------------+
| Practice                | Primary question         | Typical evidence             |
+-------------------------+--------------------------+------------------------------+
| DevOps                  | How do teams collaborate | Shared ownership, fast flow, |
|                         | across build and run?    | reduced handoffs             |
+-------------------------+--------------------------+------------------------------+
| SRE                     | How reliable should the  | SLOs, error budgets, toil    |
|                         | service be in practice?  | reduction, incident learning |
+-------------------------+--------------------------+------------------------------+
| Platform engineering    | How do teams consume     | Golden paths, self-service,  |
|                         | shared capabilities?     | adoption, product feedback   |
+-------------------------+--------------------------+------------------------------+

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

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

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

Сигнал сценарію	Найімовірніша концепція	Чому ця відповідь підходить
Команди заохочують спільно володіти обов’язками зі збирання та запуску.	DevOps	Фокус на співпраці та зменшенні організаційних бар’єрів.
Сервіс має SLO, а рішення про випуск змінюються, коли бюджет помилок вичерпано.	SRE	Фокус на цілях надійності та інженерних компромісах.
Розробники створюють нові сервіси зі схвалених шаблонів зі стандартними конвеєрами та спостережуваністю.	Платформенна інженерія	Фокус на повторно використовуваній внутрішній можливості, що споживається через самообслуговування.
Центральна команда вручну затверджує кожен запит на простір імен через чергу.	Операційне вузьке місце	Процес може бути тимчасово необхідним, але це не зріле самообслуговування.
Портал показує посилання, але не може нічого підготувати, налаштувати чи запустити.	Лише портал для розробників	Інтерфейс існує, але можливості платформи все ще може бракувати.

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

3. Внутрішні платформи для розробників — це продуктові поверхні, а не просто портали

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

Портал — лише одна з можливих поверхонь. Команда може споживати платформу через pull request’и в Git, CLI, плагін Backstage, каталог сервісів, API чи кастомний ресурс Kubernetes. Іспит може подати блискучий портал так, ніби він доводить зрілість платформи. Будьте скептичними. Питання про зрілу платформу — не “чи є інтерфейс?”, а “чи можуть розробники виконувати типову роботу безпечно, швидко та узгоджено?”.

Хороша IDP робить типовий робочий процес видимим та керованим. Розробник має змогти дізнатися, як створити сервіс, зрозуміти, які стандартні налаштування будуть застосовані, запросити потрібні ресурси середовища виконання, побачити статус розгортання, знайти логи й метрики та знати, як отримати підтримку, коли щось ламається. Команда платформи має змогти бачити, де робочий процес ламається, де користувачі його полишають і яким командам потрібні винятки.

+--------------------------------------------------------------------------------+
|                         Internal Developer Platform                             |
+--------------------------------------------------------------------------------+
|                                                                                |
|  +----------------+    +----------------+    +----------------+                 |
|  | Service catalog|    | Golden paths   |    | Documentation  |                 |
|  | ownership data |    | templates      |    | support model  |                 |
|  +-------+--------+    +-------+--------+    +-------+--------+                 |
|          |                     |                     |                          |
|          v                     v                     v                          |
|  +----------------+    +----------------+    +----------------+                 |
|  | CI/CD systems  |    | Runtime layer  |    | Observability  |                 |
|  | build/release  |    | Kubernetes/IaaS|    | logs/metrics   |                 |
|  +-------+--------+    +-------+--------+    +-------+--------+                 |
|          |                     |                     |                          |
|          v                     v                     v                          |
|  +--------------------------------------------------------------------------+  |
|  |                 Policy, identity, audit, quotas, cost controls            |  |
|  +--------------------------------------------------------------------------+  |
|                                                                                |
+--------------------------------------------------------------------------------+

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

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

Найсильніший дизайн IDP починається з користувацьких подорожей (user journeys). Початківець може мислити функціями: каталог, шаблон, конвеєр, дашборд. Старший фахівець мислить робочими процесами: створити сервіс, розгорнути зміну, запросити залежність, діагностувати інцидент, ротувати секрет, вивести з експлуатації робоче навантаження. Кожен робочий процес має мати власника, очікуваний рівень обслуговування, чітку документацію та зворотний зв’язок від реальних користувачів. Без такого продуктового мислення IDP перетворюється на набір розрізнених інструментів.

Поверхня IDP	Що вона може надати	Що робить її зрілою
Портал для розробників	Виявлення, каталог, документація, точки входу в робочі процеси	Точні дані про відповідальність та посилання на робочі дії самообслуговування
CLI	Швидкі повторювані операції для інженерів, які надають перевагу терміналу	Узгоджена автентифікація, безпечні стандартні налаштування та корисні повідомлення про помилки
Робочий процес Git	Придатні до перегляду зміни інфраструктури та конфігурації застосунку	Перевірки політик, журнал аудиту та чіткі шляхи відкату
Шаблони	Стандартні відправні точки для сервісів чи інфраструктури	Підтримувані стандартні налаштування, версіонування та вказівки щодо міграції
API	Гачки автоматизації для команд та інших інструментів	Стабільні контракти, автентифікація, обмеження частоти запитів та документація
Подання спостережуваності	Логи, метрики, трейси, статус SLO, контекст інциденту	Дієві сигнали, прив’язані до відповідальності та кроків усунення проблеми

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

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

Золотий шлях — це рекомендований маршрут для типового робочого процесу. Він має власну думку (opinionated), бо команда платформи обрала стандартні налаштування, які працюють для більшості випадків. Він не повинен бути в’язницею. Шлях має зменшувати випадкову складність, водночас дозволяючи виправдані винятки для команд з особливими вимогами. Саме через цей баланс багато платформенних інженерів надають перевагу вислову “прокладена дорога” (paved road) над “єдиним правильним шляхом”.

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

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

+----------------------+      +----------------------+      +----------------------+
| Start with template  | ---> | Deploy through path  | ---> | Operate with defaults|
|----------------------|      |----------------------|      |----------------------|
| service scaffold     |      | CI/CD pipeline       |      | logs and metrics     |
| ownership metadata   |      | policy checks        |      | health checks        |
| dependency choices   |      | environment config   |      | incident runbook     |
+----------------------+      +----------------------+      +----------------------+
           |                             |                              |
           v                             v                              v
+--------------------------------------------------------------------------------+
|                      Feedback loop: adoption, friction, incidents, exceptions    |
+--------------------------------------------------------------------------------+

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

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

Елемент золотого шляху	Тлумачення початківця	Тлумачення старшого фахівця
Шаблон	Стартовий репозиторій	Підтримуваний продуктовий артефакт з версіонуванням та очікуваннями щодо міграції
Конвеєр CI/CD	Скрипт збирання	Контрольований шлях випуску з доказами, відкатом, політикою та зворотним зв’язком
Перевірка політики	Бар’єр, що блокує погані зміни	Захисний механізм, який навчає усуненню проблем і запобігає відомим небезпечним станам
Документація	Інструкції для людей	Поверхня підтримки, яка зменшує повторювані питання та фіксує наміри
Аварійний вихід	Спосіб ігнорувати платформу	Керований процес винятків, що зберігає автономію, не приховуючи ризику
Метрика прийняття	Кількість команд, яким наказано це використовувати	Докази того, що команди обирають це, бо воно краще розв’язує їхній робочий процес

Аварійний вихід (escape hatch) особливо важливий в екзаменаційних сценаріях. Платформа, яка забороняє кожен виняток, може виглядати безпечною, але вона здатна виштовхнути команди в тіньові системи. Платформа, яка дозволяє кожен виняток без перегляду, може виглядати гнучкою, але втрачає стандартизацію та придатність до аудиту. Зріла платформа підтримує винятки свідомо, навчається на них і перетворює повторювані винятки на нові підтримувані шляхи, коли патерн стає достатньо поширеним.

5. Самообслуговування має містити захисні механізми, а не лише автоматизацію

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

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

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

+------------------+      +------------------+      +------------------+
| Before request   | ---> | During request   | ---> | After request    |
+------------------+      +------------------+      +------------------+
| supported options|      | identity check   |      | ownership record |
| clear defaults   |      | policy validation|      | audit trail      |
| cost visibility  |      | quota enforcement|      | observability    |
| docs and examples|      | automated action |      | cleanup path     |
+------------------+      +------------------+      +------------------+

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

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

mkdir -p cnpa-core-review
cat > cnpa-core-review/deployment.yaml <<'YAML'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-api
  labels:
    app: payments-api
    owner: payments-team
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payments-api
  template:
    metadata:
      labels:
        app: payments-api
        owner: payments-team
    spec:
      containers:
        - name: payments-api
          image: nginx:1.27
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
YAML

grep -q 'owner: payments-team' cnpa-core-review/deployment.yaml && \
grep -q 'requests:' cnpa-core-review/deployment.yaml && \
grep -q 'limits:' cnpa-core-review/deployment.yaml && \
echo "guardrail check passed: ownership and resource limits are present"

Реальна платформа використовувала б контроль допуску Kubernetes, Open Policy Agent, Kyverno, перевірки CI чи іншу систему політик замість grep. Навчальна суть усе одно зберігається. Корисний захисний механізм перевіряє відомий ризик перед розгортанням, дає зворотний зв’язок рано та допомагає розробнику виправити проблему. Це не просто стіна наприкінці процесу випуску.

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

Самообслуговування також має межі. Жорстко регульовані дії, доступ до виробничих даних, аварійні зміни через “розбити скло” (break-glass) та дорога інфраструктура можуть потребувати додаткового перегляду. Питання зрілості платформи полягає в тому, чи є ці перегляди свідомими, придатними до аудиту та пропорційними ризику. Ручний перегляд не є автоматично поганим. Ручний перегляд стає провалом платформи, коли він є стандартним шляхом для рутинної роботи, яку можна було б безпечно автоматизувати.

Патерн самообслуговування	Сигнал зрілості	Ризик за відсутності
Створення сервісу	Шаблон створює готовий до запуску сервіс з відповідальністю та стандартними налаштуваннями конвеєра	Команди копіюють застарілі приклади та пропускають обов’язкові метадані
Запит середовища	Політика перевіряє квоту, найменування, теги вартості та доступ	Ручна черга зростає, і команди створюють неофіційні середовища
Доступ до секретів	Ідентифікація та затвердження прив’язані до ролі та журналу аудиту	Облікові дані розповзаються через чати, тікети чи локальні файли
Розгортання	Конвеєр застосовує перевірки, вказівки щодо відкату та докази	Випуски залежать від кулуарних знань та ручних команд
Спостережуваність	Логи, метрики, трейси та оповіщення прикріплюються за замовчуванням	Команди виявляють відсутні сигнали під час інцидентів
Очищення	Шлях виведення з експлуатації безпечно видаляє невикористані ресурси	Вартість та ризик накопичуються після того, як сервіси покинуто

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

6. “Платформа як продукт” означає, що прийняття треба заслужити

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

Продукт-платформа має ціннісну пропозицію. Наприклад: “Створіть готовий до продакшну HTTP-сервіс за одну годину з вбудованим розгортанням, метаданими відповідальності та спостережуваністю”. Така обіцянка достатньо конкретна, щоб її можна було перевірити. Якщо розробникам усе одно потрібно кілька днів підтримки платформи, обіцянка ще не справдилася. Якщо згенерованому сервісу бракує оповіщень, обіцянка неповна. Якщо лише одна команда використовує робочий процес, бо всім іншим він здається надто жорстким, дані про прийняття повідомляють команді платформи щось важливе.

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

+----------------------+      +----------------------+      +----------------------+
| Product discovery    | ---> | Product delivery     | ---> | Product learning     |
+----------------------+      +----------------------+      +----------------------+
| user interviews      |      | templates and APIs   |      | adoption metrics     |
| journey mapping      |      | docs and workflows   |      | support tickets      |
| pain-point analysis  |      | policies and defaults|      | incident patterns    |
| priority decisions   |      | release management   |      | roadmap adjustments  |
+----------------------+      +----------------------+      +----------------------+

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

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

Метрика	Що вона може показати	Хибне тлумачення, якого слід уникати
Час до першого розгортання	Чи справді створення та розгортання сервісу швидкі	Припущення, що швидкість важлива, навіть якщо результат небезпечний чи непідтримуваний
Прийняття золотого шляху	Чи вважають команди підтримуваний шлях корисним	Трактування примусового використання як доказу хорошого досвіду розробника
Обсяг тікетів підтримки	Де робочі процеси створюють плутанину чи де бракує можливостей	Звинувачення розробників замість покращення продукту-платформи
Причини збоїв політики	Які захисні механізми потребують чіткішого усунення чи кращих налаштувань	Приховування збоїв, бо вони роблять платформу надто суворою на вигляд
Патерни інцидентів	Які стандартні налаштування чи документація не витримують реальної експлуатації	Трактування кожного інциденту лише як проблеми команди застосунку
Задоволеність розробників	Чи довіряють користувачі платформі та чи розуміють її	Оптимізація щастя при ігноруванні надійності та врядування

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

Активна перевірка: Команда платформи отримує багато запитів на кастомні кроки CI. Деякі запити справді різні, але багато з них — невеликі варіації того самого сканування безпеки. Що ви стандартизували б, що залишили б налаштовуваним і яка метрика підказала б вам, чи допомогла зміна?

7. GitOps та інфраструктура як код — це засоби, а не вся платформа

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

Іспит може намагатися подати інструмент чи практику так, ніби це вся дисципліна. “Компанія використовує Terraform, отже, у неї є платформа” — цього недостатньо. “Компанія використовує GitOps, отже, у розробників є самообслуговування” — цього теж недостатньо. IaC та GitOps можуть уможливити самообслуговування, якщо їх загорнути в зручні робочі процеси, політику, відповідальність та підтримку. Без цих частин вони можуть просто перенести ручну складність у pull request’и.

Зріла платформа може використовувати IaC для визначення хмарних ресурсів, GitOps для застосування маніфестів Kubernetes, рушії політик для перевірки змін та портал чи CLI для проведення користувачів через запити. Досвід розробника має приховувати непотрібну внутрішню проводку, зберігаючи достатньо прозорості для усунення несправностей. Старші фахівці комфортно почуваються з таким нашаруванням: продукт-платформа — це орієнтований на користувача робочий процес, тоді як IaC та GitOps — це механізми реалізації.

+----------------------+      +----------------------+      +----------------------+
| Developer action     | ---> | Platform workflow    | ---> | Automation mechanism |
+----------------------+      +----------------------+      +----------------------+
| Request environment  |      | validate and approve |      | IaC plan and apply   |
| Deploy application   |      | pipeline and policy  |      | GitOps reconciliation|
| Change configuration |      | review and audit     |      | versioned manifests  |
| Diagnose issue       |      | surface signals      |      | logs, metrics, traces|
+----------------------+      +----------------------+      +----------------------+

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

Ось невеликий приклад того, як платформа могла б представити підтримуване розгортання сервісу. YAML — це звичайна конфігурація Kubernetes, але цінність платформи походить зі стандартних налаштувань: мітки відповідальності, запити ресурсів, проби та передбачувана форма, яку автоматизація може перевірити.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
  labels:
    app.kubernetes.io/name: orders-api
    app.kubernetes.io/part-of: commerce
    platform.kubedojo.io/owner: orders-team
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: orders-api
  template:
    metadata:
      labels:
        app.kubernetes.io/name: orders-api
        platform.kubedojo.io/owner: orders-team
    spec:
      containers:
        - name: orders-api
          image: nginx:1.27
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /
              port: 8080
          livenessProbe:
            httpGet:
              path: /
              port: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

Якщо ви часто користуєтеся kubectl, багато тих, хто вивчає Kubernetes, створюють короткий інтерактивний псевдонім (alias), щойно зрозуміють, що це лише локальне скорочення оболонки. Навчальні матеріали та документація платформи все одно мають використовувати повну команду, бо учні копіюють приклади у скрипти, завдання CI та runbook’и, де псевдоніми можуть не розгортатися. У реальному кластері розробник міг би перевірити маніфест локально, перш ніж надсилати його через робочий процес платформи. Наступна команда виконує пробний запуск на стороні клієнта і не змінює стан кластера.

kubectl apply --dry-run=client -f orders-api.yaml

Сам по собі YAML не є золотим шляхом. Він стає частиною золотого шляху, коли платформа його підтримує, документує передбачуване використання, перевіряє важливі поля, підключає його до автоматизації доставки та допомагає командам усувати збої. Те саме стосується модулів Terraform, чартів Helm, композицій Crossplane, шаблонів Backstage чи будь-якого іншого артефакту платформи. Артефакт — це засіб для досягнення результату.

8. Розбір прикладу: оцінка рішення щодо платформи

Розгляньмо такий сценарій. Зростаюча компанія має двадцять продуктових команд. Кожна команда готує простори імен Kubernetes, відкриваючи тікет до операційної команди. Тікет запитує назву простору імен, власника, середовище, квоту, мережевий доступ та центр витрат. Тікети чекають кілька днів, бо операційна команда вручну перевіряє правила найменування, створює простір імен, застосовує ResourceQuota, надає RBAC та надсилає повідомлення про завершення. Розробники скаржаться, що черга гальмує експерименти, тоді як операційна команда скаржиться, що багато тікетів неповні.

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

Крок перший — визначити повторювані точки прийняття рішень. Назва простору імен, власник, середовище, квота, мережевий доступ та центр витрат не є випадковими. Це вхідні дані врядування. Крок другий — закодувати прості перевірки: обов’язкові поля, дозволені середовища, конвенцію найменування, стандартні розміри квот та метадані відповідальності. Крок третій — автоматизувати стандартний шлях, спрямовуючи незвичні запити через видимий процес винятків. Крок четвертий — виміряти, чи зменшується час виконання, чи покращується якість тікетів і чи зменшується кількість питань до підтримки.

+---------------------------+       +---------------------------+
| Current ticket process    |       | Platform self-service path |
+---------------------------+       +---------------------------+
| Developer fills ticket    |       | Developer selects template |
| Operations checks fields  |       | Workflow validates fields  |
| Operations creates object |       | Automation creates object  |
| Operations applies quota  |       | Defaults apply quota       |
| Operations sends message  |       | Status is visible          |
| Audit is scattered        |       | Audit is recorded          |
+---------------------------+       +---------------------------+

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

Рішення	Рекомендована відповідь платформи	Обґрунтування
Стандартний простір імен для розробки	Повністю автоматизоване самообслуговування	Низький ризик і часте повторення, тож ручний перегляд додає мало цінності
Виробничий простір імен зі звичайним контролем	Автоматизований робочий процес із сильнішою політикою та обов’язковою відповідальністю	Робочий процес усе ще повторюваний, але ризик вимагає суворішої перевірки
Простір імен, що потребує незвичного мережевого доступу	Робочий процес винятків з переглядом та аудитом	Запит може бути виправданим, але він змінює профіль ризику
Відсутні метадані власника	Блокувати з чіткими вказівками щодо усунення	Відповідальність необхідна для інцидентів, вартості та керування життєвим циклом
Повторювані запити на кастомну квоту	Дослідити як можливий новий підтримуваний рівень	Повторення підказує, що стандартні налаштування платформи можуть не відповідати реальному попиту

Тепер пов’яжімо приклад з іспитом CNPA. Найкраща відповідь не казала б “купіть портал” чи “приберіть операційну команду з процесу”. Вона казала б забезпечити самообслуговувальну підготовку просторів імен через внутрішню платформу для розробників, закодувати захисні механізми для політики та відповідальності, зберегти придатний до аудиту шлях винятків та виміряти прийняття разом із часом виконання. Така відповідь застосовує мислення “платформа як продукт”, самообслуговування з врядуванням та покращення досвіду розробника в одній узгодженій відповіді.

9. Модель старшого перегляду для питань CNPA

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

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

+--------------------------------------------------------------------------------+
|                         CNPA Core Decision Checklist                            |
+--------------------------------------------------------------------------------+
| 1. What repeated developer workflow is painful or risky?                         |
| 2. Does the solution reduce cognitive load or just rename the handoff?           |
| 3. Are guardrails automated, explainable, and close to the workflow?             |
| 4. Can developers complete routine work without waiting for manual tickets?      |
| 5. Is there an exception path for real edge cases without hiding risk?           |
| 6. Are adoption, reliability, lead time, and support load measured?              |
+--------------------------------------------------------------------------------+

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

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

Екзаменаційна фраза	Що перевірити, перш ніж її обирати	Краща звичка міркування
”Єдине вікно” (single pane of glass)	Чи виконує воно роботу, чи лише показує посилання?	Надавайте перевагу можливостям над дашбордами.
”Автономія розробника”	Чи присутні все ще захисні механізми та підзвітність?	Автономія — це не відсутність врядування.
”Стандартизація”	Чи зменшує вона повторювану складність, чи блокує виправдані відмінності?	Стандартизуйте спільний шлях, керуйте винятками.
”Самообслуговування”	Чи може рутинна робота завершитися без ручної передачі?	Автоматизація має містити політику, аудит та підтримку.
”Прийняття платформи”	Прийняття заслужене цінністю чи нав’язане мандатом?	Використовуйте дані про прийняття разом із задоволеністю та результатами.
”Зсув ліворуч” (shift left)	Чи справді ранній зворотний зв’язок допомагає розробникам усувати проблеми?	Раннє блокування без підказок — це просто раннє роздратування.

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

Рекомендована карта повторення KubeDojo

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

• Що таке платформенна інженерія?
• Досвід розробника
• Внутрішні платформи для розробників
• Золоті шляхи
• Самообслуговувальна інфраструктура
• Зрілість платформи
• Що таке GitOps?
• Основи IaC
• Що таке спостережуваність?
• Керування інцидентами

Патерни та антипатерни

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

Патерн	Коли його використовувати	Чому він працює	Міркування щодо масштабування
Продуктизований золотий шлях	Багато команд створюють схожі сервіси, середовища чи конвеєри доставки.	Він перетворює повторювану експертну роботу на підтримувані стандартні налаштування, яким розробники можуть довіряти.	Версіонуйте шаблони, публікуйте вказівки щодо міграції та вимірюйте прийняття за результатом робочого процесу, а не за мандатом.
Самообслуговування з підтримкою політики	Рутинні запити потребують врядування, але не людського перегляду щоразу.	Він робить безпечні дії швидкими, зберігаючи відповідальність, аудит, квоти та усунення проблем.	Тримайте політики близько до робочого процесу та трактуйте повторювані збої як продуктовий зворотний зв’язок.
Каталог сервісів із відповідальністю	Командам потрібно швидко знаходити сервіси, власників, runbook’и та операційні сигнали.	Він пов’язує виявлення з підзвітністю, реагуванням на інциденти та керуванням життєвим циклом.	Автоматизуйте оновлення відповідальності, де це можливо, бо застарілі дані каталогу створюють хибну впевненість.
Спостережуваність за замовчуванням	Нові робочі навантаження раз за разом запускаються без корисних логів, метрик, трейсів чи перевірок справності.	Він запобігає виявленню відсутніх сигналів командами під час інцидентів.	Стандартизуйте базові сигнали, дозволяючи специфічні для навантаження SLO та дашборди.

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

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

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

Антипатерн	Що йде не так	Чому команди в це потрапляють	Краща альтернатива
Портал як розфарбована черга тікетів	Розробники все одно чекають на ручні передачі, тож час виконання майже не змінюється.	Інтерфейс простіше запустити, ніж автоматизацію робочого процесу та інтеграцію політик.	Почніть з одного робочого процесу великого обсягу й автоматизуйте стандартний шлях від початку до кінця.
Захисні механізми як непояснені блокувальники	Команди бачать політику як свавільну та обходять офіційний шлях.	Правила реалізовано з погляду контролю без зворотного зв’язку від розробників.	Повертайте дієві помилки, додавайте відповідні стандартні налаштування та публікуйте приклади усунення проблем.
Обов’язкове прийняття до відповідності продукту	Дашборди показують використання, тоді як довіра розробників падає.	Керівники хочуть видимої стандартизації, перш ніж платформа заробила довіру.	Покращуйте робочий процес, вимірюйте тертя та робіть обов’язковими лише мінімальні засоби контролю ризику.
Команда платформи як нова операційна черга	Команда стає відповідальною за кожен рутинний запит і кожен виняток.	Централізована експертиза здається безпечнішою, ніж раннє відкриття самообслуговування.	Автоматизуйте низькоризикову повторювану роботу та резервуйте людський перегляд для високоризикових винятків.

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

Гіпотетичний сценарій: команда платформи запускає сторінку порталу для запитів просторів імен Kubernetes, але портал лише записує тікет у стару операційну чергу. Команда оголошує, що самообслуговування існує, бо розробники більше не пишуть операційній команді напряму. Сильніший аналіз каже, що виявлення покращилося, а самообслуговування — ні. Кращий наступний крок — автоматизувати звичайний шлях простору імен з обов’язковими метаданими, стандартними налаштуваннями ResourceQuota, прив’язкою RBAC через схвалені ролі, журналюванням аудиту та маршрутом винятків для незвичного мережевого доступу.

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

Рамка прийняття рішень

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

+-------------------------------+
| Start with one painful workflow|
+---------------+---------------+
                |
                v
+-------------------------------+
| Is it repeated across teams?   |
+---------------+---------------+
        | yes                    | no
        v                        v
+----------------------+   +---------------------------+
| Standardize defaults |   | Document or consult first |
+----------+-----------+   +---------------------------+
           |
           v
+-------------------------------+
| Can routine risk be encoded?   |
+---------------+---------------+
        | yes                    | no
        v                        v
+----------------------+   +---------------------------+
| Add policy guardrails|   | Keep reviewed exception   |
+----------+-----------+   +---------------------------+
           |
           v
+-------------------------------+
| Measure adoption, lead time,   |
| support load, and reliability  |
+-------------------------------+

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

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

Третє рішення — чи має платформа розкривати деталі реалізації. Робочі навантаження Kubernetes 1.35 усе одно потребують конкретних об’єктів середовища виконання, ресурсів, проб, міток та політик, але більшість розробників не повинні повторно відкривати кожне низькорівневе рішення для кожного сервісу. Хороша поверхня платформи дозволяє розробникам обирати осмислені варіанти, такі як середовище, відповідальність, тип сервісу, клас залежності та ціль надійності. Вона приховує шаблонний код, залишаючи достатньо прозорості, щоб команди могли налагоджувати збої та розуміти операційні наслідки.

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

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

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

Перед запуском покращення платформи запишіть очікувану поведінку одним реченням. Наприклад: “Розробник може створити простір імен для розробки з метаданими відповідальності, квотою, стандартною мережевою політикою, журналом аудиту та видимим статусом менш ніж за одну робочу годину, не відкриваючи ручного операційного тікета”. Це речення можна перевірити. Воно також тримає команду чесною, бо форма порталу, сторінка вікі чи модуль Terraform поодинці не можуть виконати всю обіцянку, якщо навколишній робочий процес не працює.

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

Чи знали ви?

• Факт 1: Багато успішних платформ починаються з покращення одного болісного робочого процесу, як-от створення сервісу чи запити середовищ, перш ніж розширюватися до повноцінної платформи для розробників.
• Факт 2: Портал для розробників може покращити виявлення, але стає стратегічно цінним лише тоді, коли пов’язаний з підтримуваними робочими процесами, даними про відповідальність та операційними сигналами.
• Факт 3: Захисні механізми найефективніші, коли вони працюють близько до звичайного робочого процесу розробника, бо пізній зворотний зв’язок створює переробку та заохочує обхідну поведінку.
• Факт 4: Команди платформ часто вимірюють як продуктові, так і операційні метрики, бо прийняття без надійності або надійність без зручності дають неповну картину.

Типові помилки

Помилка	Чому це неправильно	Краща відповідь
Трактування платформенної інженерії як вибору інструмента	Іспит перевіряє операційну модель та продуктову дисципліну, а не лише наявність інструмента.	Почніть з робочого процесу розробника, можливості платформи та результату, який покращується.
Плутання порталу для розробників з усією платформою	Портал може бути парадними дверима, але платформа охоплює робочі процеси, автоматизацію, політики, документацію та підтримку.	Опишіть межу абстракції та можливості за інтерфейсом.
Думка, що самообслуговування прибирає врядування	Зріле самообслуговування містить політику, ідентифікацію, квоти, придатність до аудиту та шляхи відновлення.	Поєднуйте самообслуговування з автоматизованими захисними механізмами та чітким усуненням проблем.
Припущення, що прийняття є необов’язковим чи автоматичним	Платформа, якій ніхто не довіряє чи не користується, не зменшує організаційну складність.	Трактуйте прийняття, задоволеність та результати робочого процесу як основні сигнали успіху.
Опис золотих шляхів як жорстких мандатів	Надто жорсткі шляхи можуть створювати тіньові системи та локальні обхідні рішення.	Подавайте золоті шляхи як рекомендовані, підтримувані робочі процеси з керованими аварійними виходами.
Зведення DevOps, SRE та платформенної інженерії в один ярлик	Практики перетинаються, але мають різні центри ваги та екзаменаційні наслідки.	Порівняйте головний фокус сценарію: співпраця, надійність чи внутрішня продуктова можливість.
Вимірювання успіху лише випущеними функціями	Платформа може випустити багато функцій, тоді як час виконання та навантаження на підтримку погіршуються.	Використовуйте метрики результатів, такі як час до першого розгортання, зменшення тікетів, надійність та якість прийняття.
Перенесення ручних тікетів у Git без покращення робочого процесу	Контроль версій покращує перегляд та аудит, але сам по собі може не зменшити когнітивне навантаження.	Загорніть GitOps чи IaC у зручні робочі процеси, зворотний зв’язок політики, документацію та підтримку.

Тест

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

   Відповідь

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

2. Команда стверджує, що платформенна інженерія означає, що розробники ніколи не повинні торкатися інфраструктури, бо команда платформи має керувати всім. Інша команда стверджує, що DevOps означає, що кожна команда застосунку має сама керувати всіма деталями інфраструктури. Як оцінити обидва твердження?

   Відповідь

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

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

   Відповідь

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

4. Політика безпеки блокує розгортання без міток власника, але повідомлення про помилку каже лише “відмовлено”. Команди раз за разом питають платформенних інженерів, що пішло не так. Яке покращення продукту-платформи найкраще вирішує цю ситуацію?

   Відповідь

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

5. Компанія використовує GitOps для всіх розгортань Kubernetes. Розробники надсилають pull request’и для зміни маніфестів, але структуру репозиторію важко зрозуміти, а невдалі узгодження дають незрозумілі повідомлення. Який висновок CNPA найсильніший?

   Відповідь

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

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

   Відповідь

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

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

   Відповідь

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

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

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

Сценарій: Компанія має процес “нового сервісу”, який починається зі сторінки вікі. Розробники вручну копіюють репозиторій, вставляють файл CI від іншої команди, просять операційну команду про простір імен, просять службу безпеки про патерн секретів і відкривають тікет на моніторинг після першого виробничого інциденту. Керівництво називає це платформою, бо сторінка порталу посилається на всі інструкції.

Кроки:

1. Створіть локальний робочий простір для вправи.

   mkdir -p cnpa-core-review/exercise
   cd cnpa-core-review/exercise

2. Створіть короткий опис поточного робочого процесу.

   cat > current-workflow.md <<'EOF'
   # Current new-service workflow
   
   Developers start from a wiki page.
   They manually copy an existing repository.
   They paste a CI file from another team.
   They open an operations ticket for a namespace.
   They ask security how secrets should be handled.
   They request monitoring only after the first production incident.
   EOF

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

   cat > platform-review.md <<'EOF'
   # Platform Review
   
   ## Workflow weaknesses
   
   - The portal is mainly a link collection, not a working self-service platform.
   - The service template is informal because developers copy another repository manually.
   - Guardrails arrive late because security guidance is requested after scaffolding.
   - Namespace provisioning is still a manual ticket instead of a policy-backed workflow.
   - Observability is reactive because monitoring is requested after an incident.
   - Adoption cannot be evaluated because there is no defined golden path metric.
   
   ## Improved golden path
   
   The platform should provide a maintained service template that includes ownership metadata,
   CI/CD defaults, resource guidance, secret integration instructions, and observability defaults.
   Namespace provisioning should be self-service with policy validation for owner, environment,
   quota, and cost center. The workflow should expose deployment status, policy feedback, logs,
   metrics, and support guidance from the first deployment.
   
   ## Success metrics
   
   - Time from service request to first successful deployment
   - Percentage of new services created from the maintained template
   - Number of manual tickets required per new service
   - Policy failure reasons and remediation completion rate
   - Percentage of services with owner metadata and observability defaults
   - Developer satisfaction with the new-service workflow
   EOF

4. Додайте мінімальний маніфест Kubernetes, який представляє кращі стандартні налаштування платформи для нового сервісу.

   cat > service-default.yaml <<'YAML'
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: catalog-api
     labels:
       app.kubernetes.io/name: catalog-api
       app.kubernetes.io/part-of: retail
       platform.kubedojo.io/owner: catalog-team
   spec:
     replicas: 2
     selector:
       matchLabels:
         app.kubernetes.io/name: catalog-api
     template:
       metadata:
         labels:
           app.kubernetes.io/name: catalog-api
           platform.kubedojo.io/owner: catalog-team
       spec:
         containers:
           - name: catalog-api
             image: nginx:1.27
             ports:
               - containerPort: 8080
             readinessProbe:
               httpGet:
                 path: /
                 port: 8080
             resources:
               requests:
                 cpu: "100m"
                 memory: "128Mi"
               limits:
                 cpu: "500m"
                 memory: "256Mi"
   YAML

5. Запустіть прості локальні перевірки, що моделюють мислення захисних механізмів.

   grep -q 'platform.kubedojo.io/owner: catalog-team' service-default.yaml
   grep -q 'readinessProbe:' service-default.yaml
   grep -q 'resources:' service-default.yaml
   grep -q 'Time from service request to first successful deployment' platform-review.md
   echo "exercise checks passed"

6. Якщо у вас є kubectl, перевірте маніфест на стороні клієнта. Команда використовує повну назву бінарного файлу, щоб залишатися безпечною для копіювання в скрипти, завдання CI та спільні runbook’и.

   kubectl apply --dry-run=client -f service-default.yaml

Критерії успіху:

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

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

Джерела

• https://kubernetes.io/docs/concepts/overview/
• https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
• https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
• https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
• https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
• https://kubernetes.io/docs/reference/kubectl/generated/kubectl_apply/
• https://opentelemetry.io/docs/concepts/
• https://opentelemetry.io/docs/concepts/signals/
• https://sre.google/sre-book/service-level-objectives/
• https://sre.google/workbook/error-budget-policy/
• https://tag-app-delivery.cncf.io/whitepapers/platforms/
• https://tag-app-delivery.cncf.io/wgs/platforms/maturity-model/readme/
• tag-app-delivery.cncf.io: platforms — Біла книга CNCF Platforms прямо описує платформи як визначені користувачем набори можливостей, що зменшують типову роботу та когнітивне навантаження для внутрішніх користувачів.
• tag-app-delivery.cncf.io: glossary — Глосарій CNCF Platforms прямо визначає DevOps та пояснює платформенну інженерію як спосіб масштабувати принципи DevOps через уніфіковану платформу.
• tag-app-delivery.cncf.io: platform eng maturity model — Модель зрілості платформенної інженерії CNCF прямо протиставляє ручні кастомні процеси рішенням самообслуговування та називає самообслуговувальні портали й шаблони золотих шляхів сигналами зрілості.
• raw.githubusercontent.com: PRINCIPLES.md — Першоджерельний файл принципів OpenGitOps зазначає чотири визначальні властивості: декларативність, версіонованість та незмінність, автоматичне витягування та безперервне узгодження.
• hashicorp.com: what is infrastructure as code — Вступний матеріал HashiCorp про IaC прямо визначає інфраструктуру як код у термінах конфігураційних файлів, що замінюють ручні процеси через GUI чи командний рядок, і наголошує на версіонуванні та повторюваності.
• kubernetes.io: kubectl apply — Офіційна довідка kubectl apply прямо зазначає, що пробний запуск на стороні клієнта виводить об’єкт, який було б надіслано, не надсилаючи й не зберігаючи його.
• CNCF CNPA Certification Page — Це канонічний публічний огляд контексту іспиту CNPA, до якого готує цей модуль повторення.

Наступний модуль

Продовжте з Огляд CNPA: доставка, API та спостережуваність.