in devops ~ read.
Анти-паттерны DevOps #2. DevOps - это только про Dev и Ops

Анти-паттерны DevOps #2. DevOps - это только про Dev и Ops

Бывает в разговорах проскакивает мнение, что DevOps начинается и заканчивается исключительно на взаимодействии разработчиков и системных администраторов (опсов, хотя как по мне сопровождение это не только люди, которые настраивают сервера, но и, скажем те, кто разбирает клиентские инциденты). Почему это не так? И кто вообще такие Developers в набившем оскомину акрониме?

Тут надо сделать лирическое отступление в сторону классического процесса разработки, который чаще всего сопровождается не менее классической жесткой специализацией специалистов разных мастей. Если у вас в компании есть отдел тестирования, который оторван от команды разработки, то у меня для вас плохие новости.

Так вот, при классической жесткой специализации в компании неизбежно появляются инженерные субкультуры (каждая со своими правилами и инструментами), появляются сервисные модели работы (я тестировщик и я протестирую твой код за условный человеко-день), преобладает процессный подход к решению проблем.

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

Проблема процессного подхода в том, что он не масштабируется никак, кроме как привлечением всё новых и новых человеческих ресурсов. В противовес ему, инженерный подход масштабируется за счёт новых, более эффективных подходов к решению тех же проблем. Вместо Пети и его незаменимого отдела, если уж нас действительно так волнует корректная версионность ПО, должна быть утилита/подсистема, которая просто не даст собрать поставку с кривой версией. И при увеличении команд/поставок нам чаще всего будет достаточно докинуть железных, а не людских, дровишек в топку.

Возвращаясь к исходному вопросу, а кто такие Developers и почему лечить нужно весь процесс разработки и внедрения, а не только сопряжённую часть между разработчиками и администраторами. Представим, что мы решили проблему с установкой поставок в бой, с выделением железных ресурсов под проект, и теперь любой условный разработчик в два клика может загнать свой артефакт в бой за пару другую минут. Достаточно ли этого, чтобы сказать, что наша цель по быстрой выкатке в бой выполнена?

Ответ здесь - нет. Вкатывать артефакт за пару минут в бой это хорошо, но обычно (и это вам любой человек из саппорта скажет) проблема не в скорости выкатывания, а в том что именно мы хотим выкатить. Фактически нам важна не только скорость, но и понимание насколько наша работа соответствует требованиям. И вот тут появляется штука, которая называется QA, и которой нет в акрониме DevOps.

Я привык понимать QA в достаточно широком смысле. У нас куча требований, которые можно проверять различными способами на различных этапах проектирования, разработки и внедрения ПО. Поэтому, если мы хотим внедряться быстро и с предсказуемым качеством, нам нужно сделать ПО самоверифицируемым, а это невозможно сделать без перестройки всего процесса разработки. Фактически, тестировщик должен перестать тестировать ПО руками, саппорт каждый раз тестировать скрипты деплоймента артефакта и его конфигурирования на всяких суррогатных средах, а документация формироваться автоматически при сборке артефакта.

Чтобы это работало мы должны перенести часть работ по проверке нашего ПО влево, то есть либо до, либо на время разработки, до выпуска артефакта, а другую часть - вправо, то есть улучшать качество мониторинга, снижать риски внедряя ПО только на часть серверов/пользователей, и уметь либо быстро фиксить проблемы, либо также быстро их откатывать.

Все эти задачи требуют от участников команды не только более развесистого набора навыков, но в первую очередь умение программировать, потому что я пока не знаю других способов эффективно автоматизировать свою рутинную деятельность. Даже, если вы берёте какие-то готовые решения, почти всегда есть задачи, связанные с интеграцией этих решений, или разработкой собственных, потому что всех хотелок сторонними решениями часто не решить.

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

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

Поэтому Developers - это не разработчики, это вся команда, которая работает над ускорением доставки ценности клиенту, а Operations - это всё та же команда, которая работает над тем, чтобы ценность не только доставлялась, но и работала прилично.

comments powered by Disqus