Коли інженерні організації виростають з кількох команд до десятків, DevOps‑романтика швидко стикається з реальністю: кожна команда будує свій CICD, свої скрипти, свої «кращі практики». У результаті — хаос, який важко підтримувати й майже неможливо масштабувати.
Про те, як галузь прийшла до ідеї платформних команд і внутрішніх developer‑порталів, розповідає Роберт Ерез, principal engineer в Octopus Deploy і експерт із CI/CD та систем розгортання. Колись він працював над великими релізами в Skype, а вже понад десятиріччя допомагає різним компаніям будувати процеси доставки ПЗ.
Від «кинути через стіну» до DevOps — і назад
Щоб зрозуміти, навіщо потрібні платформні команди, варто згадати, з чого все починалося.
Колись типовий процес виглядав просто й жорстко поділено: «In the old days, you’d write a bit of code and you’d throw it over the wall to the ops team… dev teams and ops teams». Розробники писали код, операційники його розгортали. Відповідальність була розділена, зворотний зв’язок — повільний, а конфлікти між «девами» і «опсами» — системними.
DevOps мав це зламати. Ідея була в тому, щоб інженерні команди брали участь не лише у створенні коду, а й у його роботі в продакшені: «you get faster feedback loops… you fix it, you ship it». Команди почали володіти повним циклом: від коміту до продакшену.
Але зі зростанням організацій DevOps у багатьох місцях переродився у знайому тінь старих структур: «As things start to scale up… there would end up being like a DevOps team again… and there’d be this separation of development and DevOps… it kind of goes against some of the principles of what DevOps was trying to destroy». Тобто Dev і Ops знову опинилися по різні боки — цього разу з проміжною «DevOps‑командою».
Коли кожна команда винаходить свій CICD
Навіть там, де окремої DevOps‑команди немає, інша проблема нікуди не зникає. Кожна продуктовa команда прагне самостійності й часто будує пайплайни «як вміє» і «як зручно саме їм». З часом це призводить до роздробленої картини.
Роберт описує це так: «There was just this this large number of different ways of doing things… and that becomes difficult at scale… you can’t really move between teams». Коли в компанії десятки команд, а в кожної — свій стек інструментів, свої шаблони пайплайнів, свій спосіб параметризувати розгортання, з’являються дві проблеми.
По‑перше, мобільність людей між командами різко падає. Інженер, переходячи з однієї команди в іншу, фактично вчить нову «локальну» платформу. По‑друге, підтримувати безпеку, надійність і єдині стандарти розгортання стає все складніше. Масштаб підсвічує те, що в невеликих командах виглядало як свобода й гнучкість, — як операційний борг.
До цього додається ще один дискомфорт: більшість розробників не горять бажанням ставати напівадмінами й напів‑build‑інженерами. «Dev teams rarely want to configure the deployment scripts and test them… it’s now a different job». У реальних командах це виглядає так, як згадує Ерeз: у невеликій мобільній команді з п’яти людей «one of us had to kind of specialize in Jenkins configurations», і це часто було більше примусом, ніж покликанням.
Інакше кажучи, DevOps‑ідеал «команда робить усе сама» зіштовхується з тим, що конфігурування CI/CD, пайплайнів і інфраструктури — це окрема спеціальність. І не всі готові, а часто й не повинні, робити її своєю основною роботою.
Платформа як продукт: новий організаційний стандарт
На цьому тлі з’являється й швидко закріплюється нова організаційна модель: платформні команди. «Platform teams are kind of… in the past several years, they’ve become this sort of new standard organizational structure to help teams manage their… deployment workflows.»
Головна відмінність від старих Ops чи навіть класичної DevOps‑команди — у фокусі. Платформна команда не забирає в продуктових команд право на розгортання й операційний контроль. Вона створює стандарти, інструменти й середовище, щоб ці команди могли робити все самі — але без необхідності винаходити базову платформу щоразу з нуля.
«Platform teams… more sort of define best practices and they provide a… self-service mechanism where application teams can… use an IDP an internal development portal.» Внутрішній developer‑портал (IDP) стає інтерфейсом між платформою та продуктами. Замість того щоб руками збирати пайплайн, підбирати образи, шаблони конфігурації чи n‑тий раз налаштовувати інтеграції, команда обирає затверджений шаблон, створений платформою, і запускає його в роботу.
Це дає одразу кілька ефектів.
По‑перше, зникає «зоопарк» пайплайнів. Шаблони й best practices, які розробляє платформна команда, поширюються на всі команди через механізми самообслуговування. Оновити стандарт безпеки чи змінити підхід до розгортання стає значно простіше: не потрібно переконувати кожну окрему команду переписати свій вручну створений скрипт.
По‑друге, зберігається те, що DevOps обіцяв із самого початку: відповідальність за роботу сервісу залишається в продуктової команди. Вони все ще «ship it and fix it», але не з нуля конфігурують Jenkins, GitHub Actions, Kubernetes‑манифести чи що б там не було в конкретній організаційній реальності.
І по‑третє, зменшується когнітивне навантаження на розробників. Вони не зобов’язані ставати експертами у всіх аспектах розгортання, хмарної інфраструктури й інструментів, щоб просто вивести нову версію в продакшен. Платформа формалізує це як сервіс.
Внутрішні портали як інтерфейс платформи
Ключовим будівельним блоком цієї моделі стають внутрішні developer‑портали. Вони можуть виглядати по‑різному, але розв’язують одне завдання: зробити доступ до платформи прозорим та уніфікованим.
Ідеальний сценарій, який описує Ерeз: команда хоче запустити новий сервіс — вона відкриває внутрішній портал, обирає затверджений шаблон (мови, рантайм, тип середовища, стандартний CICD), натискає кілька кнопок — і отримує проєкт, уже інтегрований із системою розгортання, логуванням, моніторингом, секретами, політиками доступу.
Платформна команда при цьому не втрачає зв’язку з реальністю. Вона спостерігає, як ці шаблони живуть у продакшені, збирає зворотний зв’язок, покращує best practices. Але критично важливо: вона не перетворюється на ще один «bottleneck‑департамент», через який має пройти кожна зміна.
Така модель дає змогу уникнути повернення до старої «стіни» між девами та опсами. Платформа — це сервіс, а не окреме царство, яке тримає в заручниках розгортання.
Кому взагалі потрібна платформна команда — і коли
Привабливість цієї моделі не означає, що вона універсальна. Ерeз прямо наголошує: «That’s not to say that every company everywhere should have a platform team… if you’re a smaller company… you’ve just got the apps team and they sort of are doing… DevOps.»
Там, де одна‑дві продуктові команди, платформа часто природно вбудована в них самих. Ті ж самі люди, які пишуть код, налаштовують пайплайни, хмарні ресурси, механізми розгортання. Це може бути ефективно, поки:
- кількість сервісів і команд невелика;
- вимоги до уніфікації й відповідності регуляціям не надто жорсткі;
- рішення, прийняті в одній команді, не створюють нефіксованого боргу для десятків інших команд.
Платформна команда стає доцільною там, де з’являється масштаб — у кількості продуктів, людей, регуляторних вимог або інфраструктурних рішень. Її завдання — не створити новий «відділ блокерів», а повернути контроль над складністю: стандартизувати те, що має бути стандартним, і дати командам свободу там, де це справді має значення для продукту.
І саме в цьому сенсі «platform teams are kind of… this sort of new standard organizational structure». Не тому, що це модний тренд, а тому, що без якогось варіанта платформи великі організації неминуче впадають у DevOps‑хаос із десятками несумісних способів робити одне й те саме — деплоїти код.
Висновок: платформа як відповідь на зрілість, а не як мода
Історія, яку окреслює Роберт Ерeз, показує еволюцію галузі: від жорсткого поділу Dev/Ops через DevOps‑ентузіазм до більш прагматичної моделі платформи як продукту для внутрішніх користувачів — інженерних команд.
Платформні команди виникли не як теоретична концепція, а як відповідь на дуже практичну проблему: «this large number of different ways of doing things» стає непідйомним у масштабі. Внутрішні developer‑портали й стандартизовані шаблони дають організаціям змогу тримати під контролем безпеку, надійність і швидкість доставки, не забираючи у команд автономію.
Водночас платформа — не панацея й не обов’язкова вимога для кожного стартапу. Для невеликих команд DevOps підхід «ми самі все робимо» залишається цілком працездатним. Але коли організація виростає настільки, що CI/CD і розгортання займають дедалі більшу частину уваги інженерів, які хотіли б писати продукт, а не налаштовувати Jenkins, саме платформа стає тим механізмом, що повертає фокус на бізнес‑цінність, а не на боротьбу з інфраструктурною ентропією.