Від адміністратора кластера до інженера платформи

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

Діагностика — чи ви готові?

• Ви вмієте написати SLO, який не є ані надмірно жорстким, ані надто розпливчастим, щоб скеровувати рішення.
• Ви можете пояснити різницю між SLI, SLO, SLA та бюджетом помилок.
• Ви випустили Terraform-модуль, Helm-чарт, шаблон чи шлях автоматизації, яким справді користувалися інші люди.
• Ви знаєте, що таке золотий шлях і чим він відрізняється від навчального матеріалу чи сторінки вікі.
• Ви вимірювали час циклу розробника, частоту розгортань, час виконання замовлення або частку невдалих змін.
• Ви брали участь у розборі інциденту (postmortem), який виявив системні та процесні причини.
• Ви можете пояснити узгодження GitOps і те, чому ручні зміни в кластері створюють прихований дрейф конфігурації.
• Ви можете описати модель відповідальності за сервіс, яка охоплює чергування на виклику, документацію, ескалацію та очікування щодо життєвого циклу.
• Ви вмієте відрізняти можливості платформи від платформних продуктів.
• Ви можете пояснити, чому самообслуговування без запобіжників перетворюється на операційний борг.
• Ви можете визначити, коли проблема кластера насправді є проблемою організаційних меж.
• Ви здатні сказати «ні» функції платформи, коли вона не покращує надійність, швидкість доставки, відповідність вимогам чи зручність експлуатації.

Карта прогалин у навичках

Що ви маєте	Що вам потрібно	Де це вивчати
Вільне володіння об’єктами Kubernetes	Системне мислення в межах команд, сервісів і циклів зворотного зв’язку	Що таке системне мислення?
Усунення несправностей у кластері	Цілі надійності та рішення на основі бюджету помилок	Інженерія надійності
Використання метрик і логів	Спостережуваність як дисципліна проєктування	Теорія спостережуваності
Заходи безпеки	Принципи безпеки, вбудовані у стандартні налаштування платформи	Принципи безпеки
Адміністрування ресурсів	Відповідальність за сервіси та операційні моделі	SRE
Доставка YAML	Узгодження GitOps і контроль дрейфу	GitOps
Разова автоматизація	Багаторазові золоті шляхи та досвід розробника	Інженерія платформ
Знайомство з інструментами	Вибір інструментів на основі шляхів користувача та обмежень платформи	Набори інструментів платформи
Керування доступом	Робочі процеси для секретів і політик, які команди здатні впровадити	Vault
Розгортання застосунків	Патерни внутрішнього порталу розробника	Backstage

Послідовний маршрут

1. Почніть зі Що таке системне мислення?. Чому цей крок: робота з платформою — це про цикли зворотного зв’язку, стимули, обмеження та межі сервісів, а не лише про стан кластера.

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

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

4. Перейдіть до SRE. Чому цей крок: SRE поєднує цілі надійності, реагування на інциденти, зменшення рутини та операційну відповідальність.

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

6. Вивчіть GitOps. Чому цей крок: дисципліна узгодження перетворює операції Kubernetes на придатну до рев’ю, відтворювану й аудитовану зміну системи.

7. Додайте Argo CD, коли вам знадобляться деталі реалізації. Чому цей крок: інструменти легше оцінювати, коли ви розумієте узгодження, відповідальність, просування та вимоги до відкату.

8. Додайте Backstage, коли будете готові проєктувати точки входу для розробників. Чому цей крок: внутрішній портал розробника корисний лише тоді, коли він відображає реальну відповідальність за сервіси та робочі процеси золотих шляхів.

9. Додайте Vault, коли секрети та ідентичність стають примітивами платформи. Чому цей крок: команди платформи повинні зробити безпечні стандартні налаштування простішими за небезпечні обхідні шляхи.

Антипатерни

• Сприйняття інженерії платформ як просто «YAML у масштабі».
• Побудова золотих шляхів, якими ніхто не користується, бо жоден робочий процес розробника не був попередньо виміряний.
• Ігнорування даних про час циклу розробника й оптимізація лише чистоти кластера.
• Ототожнення SRE з графіком чергувань на виклику.
• Встановлення Backstage, Argo CD чи Vault до того, як визначено операційну модель, якій вони мають слугувати.
• Створення API самообслуговування без відповідальності, підтримки, шляхів припинення підтримки та реагування на інциденти.

Як виглядає успіх

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

Перший модуль для читання

Почніть зі Що таке системне мислення?.