Я уже писал про таких SME (Subject Matter Expert) - специалистов, имеющих экспертизу в определенной области.

В контексте обмена знаниями, давайте рассмотрим первый кейс - мой любимый и ненаглядный GSMG.
Наша core команда - небольшая группа лиц, отвечающих за определенный “участок” (как это обычно бывает в стартапах).
Я отвечаю за эксплуатацию и AWS, наш бекендер лучше всего знает, собственно, бекэнд, фронтендер - фронтэнд, двое человек отвечают за маркетинг и PR, а наш “Один Всеотец” лучше всего шарит в торговле криптоактивами (с его небольшого скрипта на питоне все и началось) и диктует направление разработки.

Для того, чтобы эффективно разрабатывать и развивать нашу систему, мы постоянно взаимодействуем между собой, отдавая “авторитет” в принятии решений друг другу в контексте определенного участка.
Проще говоря, я не буду говорить нашему бекэндеру как использовать asyncio, а он не будет рассказывать мне, как конфигурировать proxy-кластер.

Нас очень мало (по количеству рук) в условиях такого масштабного проекта, поэтому обмен знаниями очень простой и работает в бОльшей части вербально - мы созваниемся, обсуждаем, приходим к выводам и принимаем решения. Что решили - быстренько документируем в базе знаний, либо в документации к приложению.
Разработчики при проектировании систем приходят ко мне за советом, как реализовать некий кейс в условиях AWS, а я консультируюсь у них по правилам балансировщика, чтобы Fargate task’и успевали подняться.

В этом ключе небольшой silo по экспертизе не мешает, поскольку разработка проекта хаотична, и Scrum головного мозга по нам не бьет.

Теперь рассмотрим другую ситуацию - моя основная работа, которая меня кормит.

В конторе есть департамент, в департаменте 5 команд - 4 команды разработки и 1 команда DevOps (хотя по факту больше Ops), в которой я и состою.

Взаимодействие между эксплуатацией (нами) и разработкой (ними) идет по сервисной модели.
То есть мы, как эксплуатация, предоставляем набор сервисов и инструментов разработчикам (AWS, CI/CD и прочие сис. админские прелести), а разработчики это настраивают под себя и разворачивают свои приложения направо и налево.

Я не могу сказать, что этот “тот самый” DevOps, который я хочу видеть, но до “того самого” у нас пока нет.

Главной проблемой такой “сервисной” модели являются те самые архитекторские решения, принимаемые разработчиками без нашего участия.

По процедуре у каждого продукта есть свой специальный чек-лист, в котором один из пунктов стоит: “Продукт одобрен одним или несколькими системными инженерами.”

Стоит ли говорить, что этот чеклист начинает отрабатываться, когда продукт спроектирован, разработан, запущен в тестовом окружении, и наша “подпись” нужна только для того, чтобы выкатить продукт в промышленное окружение?

А теперь представьте, что я изучаю продукт и вижу, что там используется та же DynamoDB для редкой обработки больших объемов данных (что, как я писал, дорого и неэффективно). Одобрю ли я такое решение? Разумеется, нет.
В итоге я оказываюсь в положении, что должен завернуть разработку и заставить все переписать, ломая весь план и архитектуру, а это - дни и недели потерянной работы.

Этого можно избежать, если члены инженерной команды будут участвовать в проектировании решения (что делается в любой конторе, где DevOps это культура, а не человек).

С этой проблемой я столкнулся сразу, как мы запустили on-call ротацию в нашей команде, и в следующем посте я напишу, как мы это дело “чинили”.