Меня периодически спрашивают каким образом строить инфраструктуру для небольших проектов, когда в команде еще нет компетенций админа/девопс-инженера ни у руководителя или программистов, ни в в виде выделенного человека. Что при этом выбрать — выделенные сервера, облако или Kubernetes? Я сейчас не буду делать какие-то технологические рекомендации, но опишу на что нужно обратить внимание организационно, чтобы можно было сделать такой выбор.

При планировании развертывания любого приложения для продакшна важно всегда в том или ином виде продумывать как минимум следующие 5 бизнес-процессов / Value stream:

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

Любая инсталляция, которая выходит за пределы ноутбука разработчика будет состоять как минимум из компонентов указанных на иллюстрации (стикеры синего и зеленого цвета).

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

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

Соотвественно необходимо продумать каким именно образом это будет происходить, как будут происходить эти операции. Конечно, если мы хотим в той или иной мере сохранять контроль над нашей инсталляцией.

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

В начале статьи я намеренно написал “бизнес-процессы / Value Streams”, т.к. что именно это будет определяем мы как технический руководитель. Это могут быть классические инструкции в виде чеклиста или BPMN-диаграммы, в этом случае про них уместно говорить как о “бизнес-процессах”. Это могут быть насквозь автоматизированные Software Defined Processes и в этом случае мы о них скорее всего будем говорить как о Value Stream. Часто противопоставляя DevOps и “классическое IT” имеют в виду смену именно этой парадигмы — замену “бизнес-процессов” на “Value Stream”.

Ну либо мы можем полностью делегировать этот процесс некоему сотруднику (сисадмину, либо Devops-инженеру) не задумываясь о том, что в этом процессе происходит, и надеяться, что когда рано или поздно этот сотрудник уйдет, новый сотрудник на его замену сможет в этом хозяйстве разобраться. Если мы принимаем этот риск, то в этом случае строго говоря нам действительно не важно как этот сотрудник работает — копипастит ли артефакты через FTP, или же пишет портянки кода на Ansible и Terraform.

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

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

Для сложных инсталляций, естественно, компонентов может быть больше. Например из “Конфигурации приложения” зачастую можно выделить “Секреты”, “Endpoints” и “Функциональную конфигурацию” (относящуюся к логике приложения). Или “Среда выполнения” может состоять как из “Виртуальных серверов”, так и “Оркестратора”.

Для каждого из таких компонентов них необходимо тоже прорабатывать соответствующий процесс внесения изменения. Как мы уже говорили выше, в зависимости от того какой дорогой мы выбрали идти это могут быть как развесистые инструкции, так и скрипты автоматизации. Либо вообще у нас будут отдельные сервисы — они будут управлять этими компонентами и возьмут на себя всю сложность. К примеру, если держать секреты в Vault весь процесс внесения изменений в секреты будет состоять из минимум двух шагов:

• Меняем секрет через UI Vault
• Наши скрипты автоматизации раскатывают эти секреты по всем сервисам

Но тут встает интересный вопрос: что делать с внесением изменений в эту самую автоматизацию? Ответ простой — автоматизация это по сути код, мы применяем подход Infrastructure as Code. А точнее, у нас появляется Infrastructure as Code как процесс разработки, и это не то же самое, что Infrastructure as Scripts как очень часто бывает. Соответственно, для упрощения планирования и работы мы начинаем применять классические практики разработки: прорабатываем компонентную модель кода, описывающего нашу инфраструктуру, прорабатываем форматы и последовательности обмена сообщениями в нашей инфре (например, какой скрипт какие хуки дергает и что передает), строим релизный процесс для инфраструктурного кода, прорабатываем бэклог фич — одним словом, работаем с инфраструктурой так, как будто это еще один компонент приложения.

И наконец мы приходим к главному вопросу: что со всем этим знанием делать?

Если у вас маленькая инсталляция и небольшая частота изменений в инфраструктуре:

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

Если у вас инсталляция большая и изменений в инфраструктуре много:

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

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