Одной из задач, которую приходится решать в рамках помощи команде организоваться – приблизить ее к пониманию ответов на один из часто возникающих вопросов:
Как привлекать специлистов, которые не работают над развитием продукта fulltime: Compliance, UX, CI/CD? Входит ли в группу этих деятельностей Ops?
Ответ на этот вопрос лежит в способности (и готовности) команды делегировать эту ответственность на условный аутсорс. Рассмотрим ситуацию на примере Ops и эксплуатационной деятельности в чистом виде.
В идеальной сферической команде в вакууме вся ответственность за продукт, за работу и взаимодействие всех его составных частей лежит внутри её области ответственности и компетенций. Но мы с вами, к счастью, и не сферы, и не в вакууме. За последние годы многие компании неплохо научились как получать, так и предоставлять условно-статичные commodities в виде IaaS и отдельных SaaS.
Таким образом, слой базовой вычислительной инфраструктуры до уровня контейнера с операционной системой в настоящее время не вызывает особых вопросов. Все взаимоотношения в этой области формируются в формате SLA, т.к. и стоимость конкурентная, и высокая надежность сочетана с высочайшей стандартизацией. API во все поля.
Серый слой находится в зоне развертываемого на узлах Middleware: настройка его под нужды продукта/приложения очень часто специфична, кроме того, работы требуют весьма глубокой (не свойственной) для Dev команды экспертизы в части Ops этого самого Middleware. Т.е. мало поднимать стандартный Nginx: он должен быть адекватно настроен под текущие нужды/загрузку/назначение узла, взаимодействие различных компонент, потоков данных, безопасность.
В идеальном для разработчиков мире, если мы получаем инфраструктуру по модели IaaS, то и вспомогательные технологические сервисы тоже должны приобретаться по подписке. В этом случае команда сохраняет за собой компетенции по конфигурированию этого middleware (а также по автоматизации этого конфигурирования в зависимости от задач и условий) и управляет всем этим зоопарком через CMS, систему контроля версий. При этом, мы не занимаемся настройкой запущенных узлов, мы убиваем их по необходимости и создаем новые с новой конфигурацией.
Этог путь обладает наибольшими возможностями по масштабированию, ускорению (т.к. все – код), мгновенному восстановлению, но требует значительных по сложности пререквизитов. Мы должны:
- обладать высокой эксплуатационной компетенцией по этому Middleware почти по существенной ширине команды разработчиков (очень трудно и дорого, малореалистично из-за высокого уровня специализации труда администраторов и разработчиков);
- на все 200% использовать архитектуру микросервисов, контейнеров;
- научиться жить в парадигме неизменности узлов приложения (изменяются только данные).
Если мы не на 100% в контейнерах или потворствуем греху и вносим настройки в параметры запущенных узлов/компонентов приложения (умолчу о CMS), то мы автоматически теряем возможность быстрой перестройки всей инфраструктуры, т.к. тут в цепочке изменений “инженерного” слоя появляются человеческие руки и головы.
Эти руки и головы в идеале будут или полностью в команде, если их работа востребована в полном объеме, или во внешней функции. При этом, чем больший вклад эксплуатации требуется для обеспечения нормальной работы, тем требуется более сильная привязка сотрудников к продуктам для сохранения и передачи эксплуатационных компетенций.
Заметим, что внешняя к команде функция может очень хорошо послужить в деле сохранения специальных компетенций и ноу-хау, интеграции и унификации практик и технологий между разными продуктовыми командами. Развить практику предоставления командам определеных ресурсов, экспертизы и технологий до уровня P(latform)aaS, в идеале, учитывая наработанный за годы опыт и экпертизу автоматизации.
Безопасность, непрерывность, поддержка конвейера могут быть востребованы не каждый день, с другой стороны дежурный офицер здоровья сервиса (мониторинг), или наблюдение над парой тысяч узлов СУБД в приложении могут требовать активного 100% вовлечения и вывод таких практик из команды может быть нерациональным.
Максимально противоположный вакуумо-сферичному подходу вариант состоит в том, чтобы максимально зааутсорсить эту экспертизу. В этом случае все будет зависеть от степени нашей зависимости от выводимой экспертизы: для координации штучных работ по архитектуре UI можно привлечь и третью сторону, особенно если у вашего приложения нет пользовательского интерфейса. Полностью зааутосорсить критическую способность вашей команды сопровождать приложение и кастомизированный middleware – вам вряд ли удастся.
Определить фактическую потребность в наличии тех или иных компетенций, принять решение продуктовая команда может только сама.
