Примените алгоритм заземления в 1-2 ситуациях, в которых, по вашему мнению, есть какие-то проблемы: что-то уже идёт не так или что-то имеет все шансы пойти не так.
Хотелка звучит так: разработчики не могут самостоятельно развернуть свой сервис в окружении с нуля, недовольны работой дежурных, дежурные занимаются бессмысленной рутиной.
Сейчас процесс разворачивания приложений в новых окружениях автоматизирован в разных местах и между ними нет связи. Нужно подобрать название для роли, которая занимается первоначальной подготовкой окружения к разворачиванию приложения, назовём её “дежурный”. Так вот, дежурный должен подготовить зависимости приложений: создать сервера СУБД, выделить новую подсеть при необходимости, заказать сетевые доступы к СУБД и прочим зависимостям из подсетей приложения и GitLab-раннеров с terraform, создать через отдельный репозиторий в K8s неймспейс при необходимости и привязать его к выделенной подсети, настроить с помощью terraform из общего репозитория ресурсы для деплоя приложения и работы с секретами, добавить конфиги для разворачивания приложения в другом репозитории, настроить секреты, развернуть приложение через конфиги с применением миграций БД. По пути могут возникнуть ошбки в настройки сети, например, или неверных конфигов terraform, или несовпадении названий одних и тех же ресурсов в разных конфигах. Эти ошибки растягивают ручной процесс во времени, потому что нужно их диагностировать и исправлять. Сотрудники в роли дежурного иногда не могут это сделать самостоятельно и дёргают коллег в роли разработчиков средств/платформы автоматизации или откладывают задачу на потом. Коллеги в роли разработчика приложения выражают недовольство сроками разворачивания и начинают ныть и дёргать руководителя дежурных. Ему не нравится, что происходит.
Видимо, он как менеджер хочет ускорить разворачивание приложений на стендах, в идеале без участия дежурных (исполнителей роли дежурных).
Для этого можно сделать следующее:
- автоматизировать рутину, чтобы не было возможностей для совершения ошибок (названия автоматически будут проставляться везде)
- атоматизировать подготовку зависимостей приложений
- предоставить возможность взаимодействия со срествами автоматизации из единой точки, например, через IDP
- дать роли разработчика приложения возможность самостоятельно разворачивать приложение в новом окружении без привлечения роли дежурного
Измерять можно время разворачивания нового приложения (тут потребуется учитывать и время на подготовку новых серверов СУБД или чего-то аналогичного) и количество проблем/ошибок в процессе разворачивания, с которыми обращаются к дежурным. Сейчас измеряется время обработки заявки на разворачивание нового приложения, в будущем можно будет измерить время работы автоматизации с момента создания до разворачивания приложения. Ошибки можно будет измерять в реализации автоматизации, дальше только отслеживать количество обращений в связи с ошибками при эксплуатации этой автоматизации.
Полагаю, что дополнительно надо будет обращать внимание на выбор инструментов автоматизации и их работу, чтобы заранее понять, что они не подходят и нужно их заменить.
Загрузите описание в LLM, усиленную FPF. Дайте команду отвечать с опорой на FPF, но на языке вашей предметной области (подставьте название своей предметной области: разработка ПО, архитектура, продажи и тп). При необходимости прокритикуйте ответ LLM и поменяйте запрос столько раз, сколько нужно, чтобы LLM исправила ошибки в ответе. Если есть какие-то источники информации помимо FPF, на которые LLM должна опираться при ответе, укажите их в запросе тоже.
Промпт:
В приложении спецификация First Principles Framework (FPF). Отвечай дальше в чате с опорой на эту версию FPF, но не используй жаргон FPF, а отвечай на языке разработки ПО, Platform Engineering. Объясни мне как инженер-менеджер, правильно ли моё рассуждение, опираясь на паттерны C.2.1”. + C.2.1 + A.6.P из FPF.
LLM подстветила неточности в описании изменений, предложила ещё варианты метрик и сигналов, уточнила условия возможности и невозможности. В итоге переписал так, есть, куда ещё можно уточнять, но пусть это будет версия 0.3:
Контекст:
- приложения разворачиваются в кластерах K8s на своём железе, а не в облаке
- сеть настраивается руками по заявкам в Jira
- СУБД настраивается через запуск ansible и в GitLab CI, там же можно настроить БД и пользователей
- есть репозиторий с terraform, который запускается в GitLab CI и настраивает часть необходимых для разворачивания зависимостей (учётка для доступа к helm-чартам и docker-образам, секреты и политики в vault, проект в Sentry, БД и пользователи)
- есть GitOps-репозиторий flux, через который создаются подсети для calico
- есть GitOps-репозиторий flux, через который создаются неймспейсы и им назначаются подсети calico
- есть GitOps-репозиторий flux, через который разворачиваются сами приложения
- приложения разворачиваются в новых окружениях по заявкам в Jira
Проблема: разработчики не могут самостоятельно развернуть свой сервис в окружении с нуля, недовольны работой админов, потому что админы делают это долго и с ошибками, а админы фактически занимаются бессмысленной рутиной вместо более полезных задач, ещё и не всегда следуют инструкциям. Руководителю админов как менеджеру нужно, чтобы разработчики могли самостоятельно разворачивать свои сервисы в новых окружениях, процесс был автоматизирован и не требовал ручного вмешательства со стороны админов. В идеале, чтобы приложения поднималось с нуля за полчаса или меньше.
- Опишите, что (какие объекты) должно измениться в физическом мире после того, как задача будет сделана. Явно пропишите: с точки зрения какой роли вы будете смотреть на ситуацию. Альтернативно: опишите, что вас смущает, что у вас «дребезжит», то есть, распишите ситуацию/контекст с выбранной точки зрения.
Смотрю на ситуацию как platform engineer.
В физическом мире появится новая система, дающая разработчикам возможность самостоятельно разворачивать свой сервис с его зависимостями в новых окружениях.
Система предоставляет:
- API как единый source of truth для бутстрапа приложений
- UI для работы с API
- Шаблон для golden path бутстрапа из описания, где можно указать окружение, версию приложения, список высокоуровневых зависимостей, например:
- собственная БД (несколько вариантов типовых профилей) + роли в ней
- роль в чужой БД
- топик в Kafka
- токен аутентификации во внешнем сервисе
- и т.п.
- не даёт возможность разработчикам приложений явно описывать низкоуровневые зависимости
- оркестрацию создания инфраструктурных ресурсов в разных системах с соблюдение согласованности названий
- Выделите в описании агентов, которые начали действовать иначе. Назовите эти иные действия. Назовите результаты этих действий: какие объекты сменили состояния (с точки зрения выбранной роли), назовите артефакты. Опишите последствия.
Platform Engineer поддерживает IDP, исправляет баги в автоматизации.
Разработчик приложения больше не создаёт заявку в Jira, чтобы забутстрапить приложение в новом окружении.
Разработчик приложения использует шаблон в IDP и создаёт описание приложения в GitOps-репозитории команды (кластер, версия, тип приложения/типовой профиль, зависимости приложения типа БД, переменные конфигурации), чтобы забутстрапить приложение в новом окружении. В кластере K8s появилось новое описание деплоя приложения из GitOps-репозитория. Crossplane в кластере создал инфраструктуру для приложения из описания:
- проект в Sentry
- секреты и политики в vault
- учётку в Harbor для доступа к артефактам
- БД и пользователей в кластере patroni
- подсеть в Calico
- генерирует из описания зависимостей сетевые политики для доступа приложения к этим его зависимостям
Разработчик приложения отвечает за неверную конфигурацию, из-за чего приложение не работает (хелсчеки не проходят).
Админы-бутстраперы перестают обрабатывать заявки в Jira на бутстрап приложений в новых окружениях.
Админы-бутстраперы вместе с Platform Engineer перестают тратить время на диагностику и исправление ошибок из-за несовпадения названий в разных репозиториях.
Последствия:
- есть автоматизированный golden path для бутстрапа приложения
- админы-бутстраперы больше не участвуют в бутстрапе приложений и оркестрации репозиториев и переключаются на другие задачи, роль админа-бутстрапера перестаёт существовать, потому что не нужна, а специфические знания перенесены в код автоматизации
- при бутстрапе приложений перестают возникать ошибки несогласованности названий в разных репозиториях, админы-бутстраперы вместе с platform engineer не тратят время на диагностику и исправление этих ошибок
- бутстрап приложений выполняется за полчаса или менее
- сложность низкоуровневой инфраструктуры скрыта от разработчиков приложений за счёт выскоуровневого API и автоматизации
- дрифт конфигурации автоматически исправляется crossplane в reconciliation loop
- все зависимости приложения указаны в описание деплоя
- Распишите, каким образом/способом/методом вы будете проверять, что в физическом мире произошли нужные вам изменения. Какие замеры вы будете делать, чтобы увидеть, что изменения реальны? Что вы будете измерять?
- Считаем количество новых заявок в Jira на бутстрап приложений за последние пару недель, в идеале их должно быть 0
- Считаем adoption как количество деплоев созданных через IDP, пока что их число должно просто расти от месяца к месяцу
- Собираем метрики времени для golden path от заполенения шаблона в IDP (нажатие кнопки и коммит описания в репозиторий - это фактически одно и то же, когда коммит из IDP работает) на бутстрап приложения до работающего (проходит probes/хелсчеки) развёрнутого приложения в указанном кластере, должно быть менее 30 минут
- Считаем количество обращений (через заявки в Jira и в чате поддержки) из-за ошибок в автоматизации при бутстрапе приложений, допустим, менее 5 в месяц
- Собираем метрики ошибок работы автоматизации по бутстрапу приложений в новых окружениях (не ошибки кривого описания деплоя приложения, а именно реализации автоматизации), допустим, менее 5 в месяц
- При каких условиях результат возможно получить? А при каких невозможно?
Возможно:
- есть описанный golden path и типовые профиили для бутстрапа, который можно автоматизировать, но нестандартные требования он не учитывает, они реализуются пока что в ручном режиме
- у сотрудников компании есть capability для создания IDP
- есть автоматизация/API для управления сетью или сеть заранее готова, и её не нужно настраивать
- есть автоматизация/API для создания СУБД и настройки БД и пользователей в них
Невозможно:
- нет описанного и стандартизированного golden path для бутстрапа, в нём много условий для разных приложений, они постоянно меняются
- у сотрудников компании нет capability для создания IDP
- IDP/платформа умерла, нет метрик здоровья самой платформы
- нет возможности автоматизированно/через API управлять сетью
- нет возможности автоматизировано/через API создавать кластера patroni и настраивать в них БД
- Какие сигналы могут вам указать заранее на то, что делается что-то не то?
- разработчики приложений и админы продолжают работать через заявки
- разработчики приложений не в курсе о возможности self-service bootstrap и заводят заявки на админов, чтобы те за них бутстрапили приложения через IDP
- появление ручных обходов и исключений, указание на них в документации
- админы продолжают исправлять ошибки при бутстрапе руками
- частые ошибки в работе автоматизации
Сделайте выводы. Помогло ли заземление выявить ошибки? Составить план решения ошибок? В данной ситуации действительно стоило напрячья, или ваш «радар ошибок» сработал вхолостую?
Заземление особо не помогло, потому что проблема для меня достаточно понятная. Хотя всё-таки есть польза, потому что пришлось обратить внимание на такие важные вещи, как условия, метрики и сигналы. Пока что на раннем этапе проработки я их не учитывал.