Ненадежные системы могут навредить пользовательскому опыту, а значит — репутации компании. Чтобы держать ситуацию под контролем, инструменты должны адаптироваться, что открывает путь к самовосстанавливающейся инфраструктуре. Технический директор Puppet Дипак Гиридхарагопалис рассказывает на портале The New Stack о том, что это такое и как ее построить.

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

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

Надежность не подлежит обсуждению

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

Самовосстанавливающиеся системы — это как раз то, о чем говорит их название: автоматизированные системы, которые могут обнаруживать и устранять ошибки без вмешательства человека. Самовосстанавливающаяся инфраструктура — это применение этой идеи ко всем объектам, которыми управляют операционные команды. Она охватывает широкий спектр подходов, включая низкоуровневые инструменты «инфраструктура как код» (infrastructure-as-a-code, IaC), механизмы внедрения политик, инструменты оркестровки контейнеров и многое другое.

Чтобы понять что это, нужно подняться на уровень абстракции выше IaC и подумать о «намерении как коде» (intention-as-a-code). Как и в большинстве ситуаций в мире ИТ-операций, некоторые компании опередили других. Поскольку приложения и инфраструктура становятся все более сложными, сейчас как никогда трудно автоматизировать все ее составляющие. Один из способов решить эту проблему — переосмыслить работу плоскости автоматизации. Каждое приложение, инфраструктура каждой команды, каждый объект — все это части этой плоскости, которая включает набор компонентов, задействованных во всех рабочих процессах разработки, эксплуатации и безопасности. Эта плоскость представляет собой все процессы, которые связывают все вместе и поддерживают работу. Теоретически она представляет собой все, что можно автоматизировать.

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

Но, как хорошо известно, технологии меняются. Инфраструктура развивается. Архитектуры приложений и платформы меняются. С ростом популярности микросервисов, IaC и облачных инструментов ОС составляет все меньший процент от общей плоскости автоматизации по сравнению с компонентами и сервисами, с которыми команды взаимодействуют через API.

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

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

Цифровой скотч

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

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

Намерение как код

Для этого нужно подняться на уровень абстракции, который располагается выше IaC и настроить мышление на намерение как код: «Когда это произойдет, вот что должно произойти в ответ». Это «основной цикл» самовосстанавливающейся системы и фундаментальная часть операций. Мы фиксируем набор триггеров, указывающих на проблему, ошибку или ситуацию, требующую внимания, а также действия, которые необходимо предпринять для устранения проблемы. Какие действия могут выполняться параллельно? Какие действия должны дождаться завершения предыдущего шага? Когда, если это вообще нужно, потребуется вмешательство человека в контуре?

Действия не обязательно должны ограничиваться только инфраструктурой; они могут включать подачу заявок, обращение к коллегам в Slack, обращение к API для работы с облачными ресурсами и многое другое. Если это поможет решить проблему, то почему бы не автоматизировать эту часть процесса? Механизмы рабочих процессов, ориентированные на операционную деятельность, позволяют пользователям выражать эти триггеры и действия в виде кода и в упрощенной нотации, которую операционная команда сможет понять и настроить под свои нужды.

Объединение триггеров и действий в повторяющиеся рабочие процессы ведет к реальной оперативной автоматизации, которая может охватить весь спектр сценариев, с которыми регулярно сталкиваются команды и с необходимой им скоростью. Большинство компаний понимают ценность полной автоматизации конвейеров CI/CD. Ручные шаги задерживают конвейер и создают ненужные риски. Однако доставка ПО еще не означает, что оно «готово». Момент развертывания — это только начало оставшегося жизненного цикла приложения, за которым операционные команды должны постоянно следить и управлять. Когда речь идет об управлении приложениями на протяжении всего их жизненного цикла, CD охватывает начало, а самовосстанавливающаяся инфраструктура — конец. Необходимо и то, и другое. Какой бы инструмент вы ни использовали для этого, главное, чтобы системы стали более надежными и чтобы тратилось меньше времени на экстренное устранение неполадок.