Об DevOps и архитектуру

Об принятие инженерных решений

Последнее обновление: 06 Aug 2022

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

Для принятия таких решений нам важно понимать, нужна ли наша система пользователям (и каким) или им и без нее неплохо живется? Смогут ли они ей пользоваться или их нужно будет долго и трудно обучать? Какие технологии у нас есть в распоряжении? Удобны и пригодны ли эти технологии для использования в системе? Умеет ли наша команда пользоваться этими технологиями? Хватает ли у нас в команде людей и компетенций? В конце концов, есть ли у нас (или у нашего заказчика) бюджет и время, которые могут быть потрачены на создание разрабатываемой системы? Пусть в контексте нашей статьи нашей системой будет инфраструктурная платформа, но с тем же успехом можно говорить и о мобильном приложении или интернет-магазине.

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

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

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

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

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

Но каким образом использовать многофункциональные и гибкие, но дорогие в освоении инструменты? Есть же какая-то ниша, где они будут лучше всего для использования?

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

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

Наконец, мы подходим к цели нашей статьи, вопросу - использование каких из инфраструктурных инструментов оправдано с точки зрения снижения рисков проекта и повышения его предсказуемости?

Какие из инструментов помогают принимать наиболее качественные решения? Какие из них просты в освоении и при этом многофункциональны, а какие лишь немного превосходят своих конкурентов в функциональности и гибкости, но при этом содержат в себе много неизвестного, количество которого к тому же сложно предсказать? Для каких из этих инструментов можно дешево принять решение о том, чтобы использовать или не использовать их в своем проекте, а для каких из них процесс принятия качественного решения будет дорогим?
К каким категориям относятся средства виртуализации, облака, Ansible, Terraform, Zabbix, и наконец любимец публики Kubernetes?
Помогают ли они принимать проектные решения, или же затрудняют эту задачу?
К сожалению, в рамках данной статьи места на это уже не остается, и подробный анализ инструментов по данной методике остается читателю в качестве домашнего задания.