Опыт многопоточной работы, или Как быть DevOps’ом для множества команд разработки

[Caraul]

Местами это называется "Управление ожиданиями".

[vkflare]

Мой опыт одновременной работы над core-задачами и тасками от команд разработки был чаще негативный, чем положительный. Фактически, это означает работу на две команды одновременно, выглядело, как антипаттерн от скрама. Когда пошла такая пьянка, лучшим решением на моей памяти было разбиение команды — часть людей работает над общими задачами (что-то типа platform), а часть девопсов заходят в команды разработки и работают по их спринтам. Опционально — ротации, КТ-сессии, демо и другие вещи, позволяющие избежать зоопарка.

Это к вопросу о том, что бездумно копировать SRE book стоит, только если вы — Google.

[RemiZOffAlex]

По факту:

• Куча команд, куча начальников, куча точек соприкосновения, куча проектов

• 99% сотрудников ничего не помнят, а ты один должен вести свои записи

• Постоянные вопросы и уточнения прозрачности задачи поставят на тебя ярмо токсика

• Посещение еждневное крупных проектов вытекает в постоянное посещение всего в течении рабочего дня, т.к. каждый ПМ считает свой участок крупным

• Проверка входных данных никогда не была прозрачной

Бегите из компании с кучей проектов!!!