Плюсы / минусы прекращения рабочего процесса DevOps?

Я пытаюсь оценить, стоит ли переходить от рабочего процесса в стиле devops к традиционному dev-then-ops (не знаю, как вы это называете).

Мы небольшой отдел из 5 человек, работающий в компании, занимающейся традиционными медиа (например, не программными продуктами), в которой работает 4000 человек. Два года назад мы начали создавать программное обеспечение, чтобы позволить нашему отделу значительно увеличить производство. Мы были довольно успешны, и большая компания начинает замечать. На сегодняшний день мы несем единоличную ответственность за проектирование, разработку и развертывание того, что стало микросервисной платформой AWS с ~ 10 сервисами. Наша команда не идентифицирует себя как DevOps, но, без сомнения, мы живем жизнью DevOps, и каждый разработчик хорошо знаком как с кодом, так и с системой, на которой он работает.

Один из вопросов, с которыми мы вскоре столкнемся, заключается в том, какую «эффективность» разделяют мы и ИТ-отдел нашей материнской компании. Владелец нашего проекта обычно предпочитает аутсорсинг, а не внутреннее обучение, поэтому в нашем случае такая эффективность, вероятно, означает получение как можно большего объема ИТ-работы "с нашей тарелки". В настоящее время я бы сказал, что наша команда на 70/30% разделена между опытом в программировании и инфраструктурой. ИТ-отдел находится в сфере ИТ без видимого перехода в разработку программного обеспечения.

Владелец нашего проекта (не технический специалист) надеется, что, отдав как можно больше работы ИТ-команде, мы увидим повышение производительности на ~ 1: 1 за каждый час работы, который мы потеряли. Я скептически отношусь к этому все же. Наш продукт все еще находится в предварительной бета-версии (несмотря на то, что он уже является значительным активом для бизнеса), и из-за нашего ограниченного опыта работы с ИТ-отделом обычно возникают значительные задержки в таких простых вещах, как изменение разрешений файловой системы.

Прямо сейчас, моим идеальным решением для ИТ-отдела было бы «усыновить» нас и позволить нам продолжать развертывание собственной работы, обеспечивая при этом соответствие стандартам и требованиям ИТ-офиса. Я не уверен, насколько это реалистично. Плюс это почти противоположный подход, который защищает наш владелец проекта, так как это добавило бы дополнительную оперативную работу в краткосрочной перспективе.

В нашей ситуации, каковы возможные плюсы / минусы использования подхода DevOps по сравнению с передачей ИТ?

Это не очень хорошая идея.

По моему опыту, вы получите недостатки обоих, в то время как любые предполагаемые преимущества так или иначе не будут реализованы.

Детализированный:

1. Вы потеряете скорость.
   ИТ будет соответствовать собственному стандарту. Новое задание (для них) будет следовать тому же «медленному» шаблону, что и вся их работа. Будьте готовы, они сочтут это сложным - поэтому даже меньше скорости, чем стандартные простые действия.
2. Вы не сможете разгрузить.
   Это будет зависеть от вас, ребята, за каждую аномалию. Вы приложите усилия для того, чтобы один парень набрал скорость - и теперь вы будете повторять следующее, потому что на следующей задаче / задаче / дне снова появится новый парень.
3. Документация потребуется, но это не поможет.
   Повторим, что шаблонное поведение будет заключаться в том, что короткие руководства не смогут уловить каждую аномалию, а подробные тексты не будут прочитаны, поскольку они слишком длинные. Таким образом, любые инвестиции здесь будут убыточными, равно как и огромные усилия, необходимые для реализации улучшений, чтобы привести ваши инструменты в «сжатое» качество.

И последнее, но не в последнюю очередь любые проблемы отразятся на вас, ребята. Смола, смолистый принцип.

Если вышесказанное звучит цинично, я боюсь, что был там. Несколько раз.

Что делать вместо этого?

Отправляйтесь за покупками в ИТ-отдел, найдите себе полезного кандидата и оставьте этого парня «в аренде», чтобы снять с вас нагрузку.

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

В среднем вам потребуется 1 дополнительный разработчик на каждые 4 человека, чтобы поддерживать одинаковый уровень разработки функций (38% против 49% времени, потраченного на новую работу). Ваше среднее время восстановления после сбоя снизится до 25 раз. Ваша работа будет на 20% менее приятной, и вы будете с вероятностью 40% рекомендовать свою работу другу. Только этих трех фактов должно быть достаточно.

То, что вы потеряете, вписавшись в ИТ-организацию, - это часть «Dev» вашей маленькой команды DevOps. Когда команды сегментируются на искусственные роли NetOps, SysOps и Dev, вы представляете следующие проблемы:

1. Ненужная волокита и изоляция. Чтобы сделать что-либо, разработчики должны будут отправить заявку в ИТ-отдел и ждать, пока они ее реализуют. Они больше не смогут самостоятельно внедрять и взаимодействовать с ним - вплоть до своих экземпляров Dev и QA, которые ограничат инфраструктуру, которую они могут кодировать. Они застряли на барьере виртуальной машины вместо того, чтобы кодировать весь стек. Если то, что они отправляют в ИТ-отдел, выглядит как код DevOps, они будут плохо оснащены для его обработки и могут вернуться к ручному развертыванию.
2. Пренебрежение - в качестве альтернативы, они могут просто развернуть его как есть, а затем пренебречь зверем, потому что они не знают, как с ним взаимодействовать - и они не разработчики, поэтому код не является их проблемой.
3. Отключения. Одним из часто забываемых преимуществ DevOps является его программный характер. Конечно, это может занять больше времени для развертывания этого сервера, рассматривая его как код, но это автоматизирует человеческие ошибки. То, как оно перешло в dev, это то, как оно войдет в QA / Test, это то, как оно войдет в prod, тем самым уменьшая простои. Когда разработчики теряют доступ к сетевому оборудованию, им необходимо развернуть свой сервис или вычислительную инфраструктуру, что не только занимает больше времени, но и приводит к появлению более подверженных ошибкам людей, что приведет к большему количеству простоев.
4. Документация. В некотором смысле код DevOps самодокументирован. Вы знаете, как был построен и развернут сервер, потому что код говорит вам. Через 5 лет, когда настанет время для обновления до CentOS 8 или чего-то еще, никто не будет знать, как развернуть ваше приложение, в том числе на уровне сети, хранилища, мониторинга и резервного копирования.

Короче говоря, вы должны предложить, чтобы ваш владелец проекта нашел время, чтобы прочитать « Мифический человеко-месяц», чтобы развеять его или ее мнение о том, что вы увидите соотношение производительности и производительности 1: 1, и проект «Феникс», который является хорошим романизированным (и развлекательный) иллюстрация того, что получено и потеряно при использовании DevOps на нетехническом языке для нетехнических людей. Если у владельца проекта есть какая-либо поездка, доступна аудиокнига The Phoenix Project.

Я бы посоветовал вам принять некоторых ИТ-специалистов и тщательно обучить их новой системе.

Как только они полностью понимают систему, тогда имеет смысл передать ее им.

В противном случае вы станете Центром поддержки для ИТ - и потратите много времени на борьбу с пожаром, изучая тонкости новой системы.