что создание системы в целом (всеми автономно работающими разработчиками, архитектором и DevOps) приносит прибыль, а не убыток.
• Архитектурная практика (выполняет архитектор, ответственный за архитектурные характеристики): установить приоритетные архитектурные характеристики, принять решения по способам их достижения путём предписания деления системы на части и указания способа взаимодействия этих частей, а также отслеживать, что создание системы в целом улучшает эти характеристики (то есть, что не накапливается «технический долг» как долг по проведению работ, предотвращающих ухудшение архитектурных характеристик в долгосрочной перспективе)
• Инженерия «производственного конвейера» (выполняет DevOps/инженер «производственного конвейера»/internal development platform, ответственный за средства/технологию воплощения проектных и архитектурных решений, а также технологию эксплуатации результата): создание условного завода-автомата/pipeline/internal development platform («конвейер»: оборудование и софт в компьютерах, но иногда это всё не работает без людей-операторов – и это не совсем «автомат», а «обычный завод»), который используется разработчиками и архитекторами, чтобы воплотить проектные и архитектурные решения, провести инженерное обоснование (испытания, проверка соответствия архитектурным решениям и т.д.), а затем выдать пользователям/клиентам для эксплуатации. Современный взгляд на это – «изготавливают» фичи системы разработчики, а DevOps только предоставляют им полностью работающее и обслуживаемое «заводское оборудование»/конвейер/pipeline/IDP (internal development platform). DevOps становится инженером конвейера, он осуществляет platform engineering, разрабатывает тот самый «завод-автомат», «конвейер», internal development platform. Редко бывает, что это именно завод/фабрика с настоящим конвейером или трубопроводом, ибо системы бывают крайне разные. Конвейер/platform начинается с правильной системы автоматизации проектирования, заканчивается системой поддержки цифрового двойника и не требует от разработчика никаких специальных знаний по его запуску и наладке, разработчики его просто используют. Вы как разработчик сами пользуетесь лопатой, чтобы копать, и точно так же сами пользуетесь internal development platform, чтобы создавать системы. Эту платформу вы сами их не создаёте, её создают инженеры производственного конвейера/DevOps/инженеры платформы разработки, но пользуетесь платформой вы сами, это называется «самообслуживание»/self-service35. Если таки надо дорабатывать IDP, то это обеспечивают инженеры конвейера/платформы, то есть исполнители ролей DevOps, но они сами ничего не изготавливают в целевой системе, занимаются только «станочным парком». Кнопку «изготовить» нажимает сам разработчик, а не DevOps, и он же имеет дело с последствиями, это принципиально: you build it, you run it – ты это строишь, ты и эксплуатируешь36). Тут сразу сложно, ибо мы получаем «систему создания внутри системы создания», создатели-операторы целевой системы «холдинг из конструкторского бюро (КБ) и завода» и «создатели-операторы КБ плюс завода». При этом понимаем, что в большинстве
https://humanitec.com/blog/what-developer-self-service-shouldnt-look-like
Особенности, отличающие platform engineering от традиционных DevOps и SRE ровно в этом: кто строит конвейер и кто нажимает кнопки на оборудовании конвейера – https://thenewstack.io/how-is-platform-engineering-different-from-devops-and-sre/
