Готовы ли вы к платформенной инженерии: чек-лист из 10 задач

Набирая группу обучающихся на наш курс мы сталкиваемся с типичной для всех проблемой. Возникает типичное возражение: «У меня пять лет DevOps, я и Kubernetes знаю». Через две недели обучения выясняется, что кластер он никогда не поднимал сам, а работал в готовом, где всё настроили до него.

Здесь «знаю Kubernetes» – не измеримая формулировка. Под ней одинаково помещаются и «умею читать вывод kubectl get pods», и «писал собственные операторы, понимаю reconcile-loop и паттерн observed generation». Между этими двумя людьми года три опыта. Поэтому мы собрали чек-лист. Не тест на знание команд – команды гуглятся. Список из десяти задач, каждую из которых вы либо делали руками от начала до конца, либо нет. Дальше будет сам чек-лист, разбор каждого пункта (почему формулировка именно такая и как проверить себя за вечер) и шкала интерпретации.

Что такое платформа и почему «просто делать инфру» перестало работать

Сначала о термине, потому что дальше он будет встречаться часто. Внутренняя платформа – это не портал и не конкретный продукт. Это набор проторённых путей, которыми разработчик решает свои задачи сам: завести новый сервис, получить тестовое окружение, выкатиться в прод, подключить базу. Инфраструктура при этом никуда не девается, но она перестаёт быть тем, о чём разработчик думает.

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

Платформенный подход эту очередь разбирает: типовые задачи оформляются как самообслуживание, а инженеры занимаются не заявками, а тем, что эти заявки закрывает автоматически. Отсюда и другой набор компетенций – шире, чем «эксплуатация», потому что теперь нужно не только запускать чужой софт, но и писать свой.

Цифры говорят о том же. По данным отчёта DORA за 2025 год, 90% организаций используют хотя бы одну внутреннюю платформу, а 76% выделили под неё отдельную команду. Gartner ещё раньше прогнозировал, что к 2026 году платформенные команды будут у 80% компаний, занимающихся разработкой ПО.

Цифры из отчётов стоит делить надвое: «используют хотя бы одну платформу» – формулировка растяжимая, под неё попадает и полноценный IDP, и внутренняя вики со ссылками на Jenkins. Но направление они показывают верно.

И ещё одно свойство платформы, которое отличает её от обычной инфраструктуры: платформу нельзя внедрить приказом. Разработчик всегда может обойти её стороной и собрать себе окружение по старинке, если так быстрее. Тот же DORA прямым текстом пишет, что платформа иногда снижает пропускную способность и стабильность, если ей не управлять как продуктом. Поэтому платформенная команда меряет не количество построенного, а то, сколько людей реально пошли по её пути.

Как устроен чек-лист

По каждому утверждению есть три варианта ответа: – Умею / делал – 2 балла – Знаком, но опыта мало – 1 балл – Пока не умею – 0 баллов

Максимум 20 баллов.

Одно очень важное правило: «делал» означает, что вы сделали это сами, целиком, и результат поехал в прод или хотя бы в полноценный стенд. «Был в команде, где это делали» – это единица, а не двойка. Соблазн поставить себе двойку велик, это вопрос честности перед самим собой!

Разбор по пунктам

Дальше по каждой задаче: что стоит за формулировкой, приземляем опыт на конкретные кейсы для преодоления завышения самооценок.

1. Развернуть и обновить приложение в Kubernetes без даунтайма

За формулировкой стоит связка из трёх вещей: стратегия RollingUpdate с подходящими под ваш сервис значениями maxUnavailable и maxSurge; настроенные readiness-, liveness- и startup-пробы; PodDisruptionBudget, который не даст выселить все реплики разом. Универсально правильных значений тут нет – они зависят от того, сколько реплик держит нагрузку и как долго сервис прогревается.

Отдельно про preStop-хук и terminationGracePeriodSeconds. Ими часто затыкают обрыв соединений при выкате, и они действительно помогают. Но если без них приложение теряет запросы, чинить надо в первую очередь приложение: корректная обработка SIGTERM и дозакрытие соединений – это его работа, а не задача оркестратора. Хук здесь костыль, а не решение.

Как проверить. Поднимите деплоймент, пустите на сервис постоянную нагрузку (hey, vegeta, k6 – что привычнее) и выкатите новую версию. Смотрите на счётчик 5xx. Ноль – зачёт. Несколько сотен ошибок за двадцать секунд выката означают, что readinessProbe у вас формальная: под отвечает «готов» раньше, чем действительно готов.

Типичное завышение: «у нас в CI есть кнопка Deploy, я её нажимал». Кнопку настроил кто-то другой, и вопрос был не про неё.

2. Настроить RBAC для нескольких команд по принципу least privileges

Здесь важна не сама настройка ролей, а слова «для нескольких команд». Разделить доступы между двумя командами так, чтобы они не мешали друг другу и при этом никому не выдали cluster-admin, – задача другого класса, чем «дал права себе».

В Kubernetes есть два вида ролей: обычная Role, которая действует в пределах namespace, и ClusterRole, действующая на весь кластер. Высший пилотаж – описать собственные ClusterRole с нужным набором прав и выдавать их через RoleBinding конкретным командам на конкретные namespace. Так вы не дублируете одно и то же описание прав в десяти местах и при этом не расширяете область действия.

И сразу про меру. Права можно закрутить до состояния, когда мышь не проскочит, – вот только толку от безопасности, при которой разработчики не могут делать свою работу и идут просить доступ в чат, ровно ноль. Хороший RBAC незаметен, пока человек не лезет туда, куда ему не нужно.

Как проверить. Смотреть надо не только на сервисные аккаунты. Во многих командах их толком не используют, а работают под личными учётками, и самое интересное обнаруживается именно там.

# что может ваш прод-ворклоад
kubectl auth can-i --list \
--as=system:serviceaccount:production:my-app
 
# что может обычный разработчик или вы сами
kubectl auth can-i --list --as=user@company.ru

Если у среднего разработчика найдётся cluster-admin, дальше можно не смотреть: разговор не про тонкую настройку ролей, а про то, что их фактически нет.

Типичное завышение: путать аутентификацию с авторизацией. Настроенный OIDC – это про то, кто вы. RBAC – про то, что вам можно.

3. Настроить автоматический деплой сервиса через CI/CD-пайплайн

Ключевое слово – автоматический. Пайплайн должен доставить до кластера сам, а не собирать артефакт и останавливаться в ожидании, пока человек сделает kubectl apply.

Как проверить. Внесите изменение, закоммитьте и не трогайте ничего руками, пока оно не окажется в проде. Замерьте время. Если между мержем и продом есть шаг, где человек что-то нажимает не потому, что это осознанный гейт согласования, а потому что иначе не поедет, – пункт не закрыт.

Типичное завышение: считать пункт закрытым, потому что пайплайн собирает образ и пушит его в реестр. Сборка – это половина. Вторая половина начинается там, где образ должен попасть в кластер и не уронить его.

4. Описать и развернуть инфраструктуру через IaC-инструменты с нуля

Ключевые слова – с нуля. Поправить существующий модуль умеют почти все. Развернуть пустой аккаунт или пустую стойку в работающую инфраструктуру из кода – заметно меньше людей. Как проверить. Самый честный и самый неприятный тест: снести тестовый стенд целиком и поднять заново из кода.

terraform destroy -auto-approve
terraform apply -auto-approve

Если после этого что-то не работает – значит, часть инфраструктуры живёт руками без четкого описания, а не в репозитории. Обычно всплывают DNS-записи, которые кто-то добавил через панель, и права, выданные разово «на пять минут» полгода назад.

Типичное завышение: state, который давно разъехался с реальностью, и никто не рискует запускать plan, потому что страшно смотреть на diff.

5. Настроить сетевую изоляцию между сервисами

Формулировка в чек-листе длинная, но точная: так, чтобы один сервис не мог обратиться к другому без явного разрешения. То есть default deny, а не «мы закрыли то, что показалось опасным».

В Kubernetes это NetworkPolicy – и здесь важная деталь: политики обрабатывает CNI, а не сам Kubernetes. Если у вас flannel в базовой конфигурации (или облачный k8s с настройками по умолчанию), вы можете написать сколько угодно NetworkPolicy, и ни одна не сработает. В облаке аналог – security groups, на железе – VLAN и файрвол.

Как проверить. Зайдите в под сервиса А и попробуйте достучаться до сервиса Б в соседнем namespace.

kubectl exec -n team-a deploy/frontend -- \
 curl -sS -m 3 http://payments.team-b.svc:8080/health

Пришёл ответ – изоляции нет. Типичное завышение: считать, что namespace изолирует. Namespace – это про пространство имён и квоты. Сетевого барьера в нём нет.

6. Настроить алертинг, который сообщает о деградации раньше пользователей

За формулировкой – алерты на симптомы, а не на причины. Latency, доля ошибок, насыщение очередей, отставание реплики. «CPU выше 80%» само по себе не инцидент: сервис может прекрасно работать на 95% CPU и лежать на 30%.

Как проверить. Не нужен стенд, нужна история. Откройте последние десять инцидентов и посчитайте, сколько из них начались с алерта, а сколько – с сообщения в чате «у нас что-то тормозит». Если второе больше половины, пункт не закрыт, каким бы красивым ни был дашборд.

Типичное завышение: считать, что дашборд – это и есть мониторинг. Дашборд смотрят, когда уже пришли смотреть. Алерт приходит сам.

7. Настроить управление секретами

Требование в чек-листе минимальное: секреты не лежат в открытом виде в CI или репозитории. На практике за ним стоит внешнее хранилище (Vault, облачный secret manager, SOPS с ключом в KMS), ротация и выдача доступа по идентичности Workload identify, а не по токену, вписанному в переменную окружения три года назад.

Как проверить: по всей истории репозитория, а не по последнему коммиту.

gitleaks detect --source . --redact -v

Часто находится что-то из времён, когда репозиторий был приватным и «ну там же только свои».

Типичное завышение: считать, что Kubernetes Secret решает вопрос. base64 про кодирование, а не шифрование, и по умолчанию в etcd секреты лежат в открытом виде.

8. Написать оператор для Kubernetes

Формулировка в чек-листе честно проговаривает суть: CRD плюс reconcile-логика, код, который делает больше, чем просто применяет YAML. Оператор это контроллер, который непрерывно приводит фактическое состояние к желаемому, а не просто скрипт по крону. Этот пункт важен, так как до него вы эксплуатируете Kubernetes. После него вы его расширяете.

Как проверить. Возьмите kubebuilder (или shell-operator), опишите CRD на три поля, напишите reconcile, который создаёт Deployment по вашему ресурсу. Потом удалите этот Deployment руками и посмотрите, вернётся ли он. Это вечер работы, и после него вы поймёте про устройство Kubernetes больше, чем за год эксплуатации.

kubebuilder init --domain example.io
kubebuilder create api --group apps --version v1 --kind Widget

Типичное завышение – наоборот, заниженная планка со стороны индустрии: писать оператор там, где хватило бы Helm-чарта. Понимать, когда оператор не нужен ровно такая же часть того же навыка.

9. Написать инструмент, который автоматизирует рутину и работает автономно

Ключевое слово автономно. Без вас, без запуска руками, с обработкой ошибок, с логом, который читает не только автор, и с понятным поведением, когда что-то пошло не так.

Как проверить. Назовите инструмент, который вы написали и который прямо сейчас работает, а вы про него не вспоминали хотя бы месяц. Если такого нет - у вас есть скрипты, а не автоматизация. Это нормальная стадия, но пункт не закрыт.

Типичное завышение: считать автоматизацией bash-скрипт в ~/bin на своём ноутбуке. Проверка простая: что произойдёт с этой рутиной, если вы уйдёте в отпуск на две недели.

10. Найти root cause инцидента по логам и метрикам

За формулировкой не «перезапустил, и заработало». Нужно восстановить цепочку: что изменилось, что деградировало, почему одно связано с другим.

Как проверить. Возьмите свой последний инцидент и напишите постмортем на страницу: таймлайн, причина, сопутствующие факторы, что чинить в системе, а не в конкретном поде. Если писать нечего, кроме «под ушёл в OOM, мы подняли лимиты», – причину не нашли, убрали симптом. Вопрос «почему потребление памяти выросло именно сейчас» остался без ответа.

Типичное завышение: путать триггер и причину. Релиз, после которого всё упало есть триггер. А причина это то, что позволило одному релизу всё уронить.

Что означает результат

Сложите баллы. Дальше – четыре диапазона.

Итог

Чек-лист занимает десять минут, а пользы от него ровно столько, сколько честности вы в него вложите. Ставьте единицу там, где сомневаетесь: завышенная самооценка обойдётся дороже, чем неприятная цифра в конце.

И самое полезное – не итоговый балл, а список пунктов с нулями. Он и есть ваш план на ближайшие месяцы.

Источники: DORA 2025 (Google Cloud), dora.dev/capabilities/platform-engineering Прогноз Gartner про 80% компаний-разработчиков ПО с платформенными командами к 2026 году: https://www.gartner.com/en/experts/top-tech-trends-unpacked-series/platform-engineering-empowers-developers

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.