Привет, Хабр! Меня зовут Захар Пикуль, я руковожу в СберТехе отделом сопровождения инфраструктуры тестовых сред. Созданием и внедрением ИТ‑решений в компаниях различного размера и уровня я занимаюсь уже более 15 лет.
Облачные решения стали неотъемлемой частью жизни современной компании. А с ростом числа виртуальных машин, развёрнутых в облаке, возникает всё больше ситуаций, которые требуют комплексного подхода к управлению. Мы планируем цикл статей, в которых поделимся нашими текущими и перспективными наработками по решению этих задач, основанными на нашем видении и накопленном практическом опыте автоматизации взаимодействия с облачной инфраструктурой.
Эта статья — вводная. В ней мы разберём вызовы, с которыми может столкнуться компания в процессе переезда в облако, и возможные способы их решения.
Фактор, без которого ничего не получится
Облачные решения, как я уже сказал, — неотъемлемый атрибут современной бизнес‑среды. Компании используют их по двум причинам.
Во‑первых, такие технологии позволяют значительно сократить затраты на ИТ‑инфраструктуру. Вместо того, чтобы покупать и обслуживать серверы и оборудование, можно арендовать виртуальные ресурсы и оплачивать только фактическое использование по модели оплаты pay‑as‑you‑go или pas‑as‑you‑use. Это снижает стоимость инфраструктуры и освобождает средства для других нужд, таких как развитие бизнеса или инвестиции в новые технологии.
Во‑вторых, облачные провайдеры предлагают высокую степень гибкости и масштабируемости, что критично в условиях динамично меняющегося рынка. Компании могут быстро адаптироваться к изменению спроса, оперативно увеличивая или уменьшая объём ресурсов.
Один из важнейших факторов, который гарантирует успешный переход на облачные технологии — это эффективное использование инструментов DevOps. Когда компании автоматизируют процесс разработки и операции, это позволяет им оптимизировать развёртывание и управление ИТ‑инфраструктурой.
К распространённым инструментам DevOps можно отнести:
Terraform, Ansible — для управления конфигурациями;
Jenkins, Gitlab, Argo CD — для непрерывной интеграции и доставки;
Kubernetes, OpenShift — для оркестрации контейнеров.
Эти инструменты значительно упрощают процессы развёртывания и управления, так как соответствуют высоким требованиям к безопасности и производительности.
Пять причин, которые затруднят переход в облако
Тем не менее, управление большим парком виртуальных машин представляет собой нетривиальную задачу. И вот почему.
Причина 1: всё растет. Возникает необходимость отслеживать и управлять большим количеством экземпляров. Это увеличивает вероятность ошибок и приводит к дополнительным затратам.
Причина 2: дебри тарифов. У каждого облачного провайдера своя схема тарификации, и если в них не разобраться, то это может привести к лишним расходам. А отсутствие возможности точно предсказать затраты на облачные ресурсы может стать причиной финансовых рисков для компании.
Причина 3: сложные процессы. Различные процессы внутри компании могут быть не оптимизированы, а это усложняет взаимодействие между командами: плохо налаженные процессы развёртывания, настройки и управления виртуальными машинами могут привести к затруднениям в работе.
Причина 4: перегрузка ИБ. Если ресурсы выдают децентрализовано, то на отдел кибербезопасности ложиться повышенная нагрузка, так как им необходимо проделать большую работу:
проверить на соответствие политикам КБ скрипты автоматизации, настройки операционной системы, настройки выдаваемого ПО;
обеспечить наличие ролевой модели и необходимых учётных записей,
регулярно проверять и сканировать, ставить на мониторинг,
обеспечить надёжный доступ к информации, защиту от кибератак и соответствие принятым нормам и стандартам, как в компании, так и с точки зрения законодательства.
Причина 5: кадровый вопрос. Высокая стоимость персонала или его недостаточная квалификация тоже риск, который чреват ошибками, увеличением времени на развёртывание решений, а также затруднениями в их масштабировании. Если используются различные скрипты автоматизации выдачи инфраструктуры (Terraform, Ansible, написанные самостоятельно и взаимодействующие с API облачного провайдера), то требуется квалифицированный инженер, который эти скрипты напишет и будет понимать, как они работают, для эффективной настройки и управления ресурсами. Если команд разработки много, то требуется и значительно больше инженеров, а это — затраты на найм и обучение, а также время на погружение во внутренние процессы компании.
Два возможных решения
СберТех — не исключение: когда мы переносили инфраструктуру в облачные сервисы и расширяли её, то столкнулись с частью сложностей, описанных выше.
Что мы предприняли?
1. Использовали связку инструментов Terraform и Ansible. Это стало одним из вариантов решения части задач, связанных с созданием, конфигурированием виртуальных машин и настройкой ПО на них.
Terraform позволяет создавать, изменять виртуальные ресурсы в различных облачных провайдерах, при этом используя подход IaC (Infrastructure as Code) — управление инфраструктурой как кодом.
Ansible также решение из подхода IaC, которое служит для автоматизации развёртывания и управления конфигурацией серверов.
Оба инструмента хорошо себя зарекомендовали во всём мире, обладают большим количеством плагинов и модулей, имеют развитое сообщество, позволяют значительно ускорить создание виртуальных машин, сократить ручные операции. Тем не менее, чтобы использовать эту связку, требуется определённый — системный — подход. И у такого решения, несмотря на значительные плюсы, есть и минусы.
Terraform, особенно при работе в команде, требует определённой степени осторожности при использовании state‑файлов: не у каждого облачного провайдера может быть рабочий Terraform‑плагин под все нужды потребителя. Кроме того, при работе с большим количеством ресурсов требуется время на планирование изменений.
Ansible, в свою очередь, при работе с большим количеством хостов может иметь проблемы с производительностью. А при написании сложных плейбуков могут возникнуть проблемы в отладке.
Кроме того, оба инструмента требуют времени на обучение и понимание технологии. Учитывая тот факт, что в СберТехе много команд, многочисленные dev‑ и test‑стенды, а также необходимо устанавливать различные версии ПО под разные задачи, это приводит к значительному увеличению времени на подготовку инфраструктуры, написание и отладку скриптов автоматизации, установку ПО. Иными словами, этого оказалось недостаточно.
2. Разработали собственный продукт. Стало понятно, что нужно своё решение. В процессе разработки команда прошла сложный технический и творческий путь: началось всё с консольной утилиты, а теперь это портал для управления инфраструктурой, который обладает большим списком версий и конфигураций выдаваемого ПО (в том числе кластерные конфигурации).
Продукт уже успешно используется в компании более трёх лет. Вот на что он способен:
может работать с несколькими провайдерам;
готовит инфраструктуру под требования компании;
работает с системами оркестрации контейнеров;
имеет развитый UI;
имеет редактируемую по требованию ролевую модель и другие функции.
Этот инструмент позволяет нам решить ещё часть проблем, обозначенных выше. Среди них, например, такие:
Управление большим количеством виртуальных машин. В зависимости от потребностей команд разработки портал позволяет группировать выдаваемые ресурсы по стендам или средам (например, dev1, dev2, test4), выдавать стенды по предлагаемому или ранее сохранённому шаблону. Команды могут легко повторить ранее выданный стенд, при необходимости отредактировать параметры, изменить список выдаваемого на стенде ПО. Возможность быстро создавать, изменять, удалять ресурсы позволяет командам быстрее адаптироваться к различным проектам и условиям.
Соблюдение требований кибербезопасности. На портале организована централизованная выдача виртуальных машин. Так мы сократили объём используемых скриптов, снизили вариативность настроек операционной системы. Кроме того, заранее настроены необходимые учётные записи и настройки ПО, а постановка на мониторинг может выполняться в автоматическом режиме. В результате, если используется централизованный подход к выдаче, то решаются сразу две задачи: повышения уровня защиты информации в компании, а также снижение нагрузки на отдел кибербезопасности.
Высокие требования к квалификации сотрудников. Наше решение для автоматизации выдачи ресурсов значительно упрощает процесс управления ИТ‑инфраструктурой: команды могут выдавать ресурсы по нажатию нескольких кнопок, не погружаясь в нюансы конфигурирования и настройки инфраструктуры.
Иными словами, продукт позволил нам автоматизировать управление облачной инфраструктурой, сократить время на рутинные задачи, повысил общую эффективность работы команд. В планах команды разработки портала — решение задач по биллингу, оптимизация процессов, ускорение выдачи кластерных решений, интеграции с внешними инструментами и многое другое.
Подробнее нашими текущими и перспективными наработками мы поделимся в следующих статьях.
Заключение
Ещё раз отмечу, что переход на облачные технологии — это современные реалии любого бизнеса. Несмотря на кажущуюся легкость, компаниям приходится учитывать множество аспектов и задач. Подготовка безопасной инфраструктуры — одна из них. Но при наличии инструмента по автоматизации, который даже частично позволяет решить некоторые задачи, значительно экономит время, необходимое на переход и адаптацию команд.
P. S. Также есть вопрос к сообществу: сталкивались ли вы с вызовами, которые мы описали выше или, возможно, с какими‑то другими? Как вы их решали? Какие решения по автоматизации используете? Поделитесь, пожалуйста, в комментариях.
