При развертывании приложений в облаке сейчас пока еще мало внимания уделяют вопросам их будущей эффективной работы, причем чаще всего с затруднениями сталкиваются компании малого и среднего бизнеса. Причина затруднений кроется в том, что облако позволяет автоматически адаптировать выделяемые ресурсы ИТ-инфраструктуры и быстро перестраивать их под изменяющиеся требования. Чтобы правильно использовать эти возможности, необходимо умение разбираться в хитросплетениях процедур управления ресурсами дата-центра или подключаемого оборудования. Однако соответствующая экспертиза пока еще имеется не везде.
Если у компаний нет достаточного опыта, они постепенно накапливают его, но почти всегда это происходит со значительной задержкой. За это время подключенная облачная инфраструктура становится сложно организованной, реальные затраты превышают заложенные прогнозы, недешевое облачное время растрачивается на нецелевые операции.
Недавно на сайте DevOPs.com были опубликованы рекомендации Роджера Фултона, директора по инфраструктуре и операциям компании Iron.io, сформулированные на основе реальной практики развертывания приложений в облаке. Они подходят для компаний любого уровня и позволяют избежать лишних затрат, быстрей пройти период адаптации к облачной работе и реализовать планирование будущих работ на современном уровне, чтобы добиться хороших итоговых результатов при проектировании облачного развертывания ИТ-ресурсов и их эксплуатации.
С самого начала осознайте тесную связь разработки облачных приложений и их эксплуатации
Когда ведется управление онпремисной ИТ-инфраструктурой, то всегда можно с высокой точностью оценить затраты на развертывание ресурсов и обеспечение их доступности во время эксплуатации.
Облачный подход переводит этот расчет на абстрактный уровень. Хотя осуществить начальный выбор конфигурации крайне просто, однако в реальности заранее определить требования к формальной модели взаимодействия разработчиков и тех, кто занимается эксплуатацией систем, непросто: каждый пользователь имеет возможность добавить новые ресурсы, принимая во внимание только собственное мнение и не учитывая, сколько уже ресурсов было привлечено к работе со стороны компании в целом, как они используются, какие дальнейшие планы.
Такое «накручивание» ненужных облачных ресурсов ведет к лишним затратам компании, если оценивать процесс эксплуатации в длительной перспективе. Возникает проблема нерационального расхода облачных ресурсов, облако разрастается и чтобы понять причину, требуется много времени и ручное вмешательства для реорганизации управления процессами.
Оценить сложность проблемы легко, если представить, что в эксплуатации в компании находятся тысячи виртуальных машин и нет ни малейшего представления о том, кто является их создателями, для каких задач они применяются и есть ли целесообразность в продолжении их работы.
Поэтому цикл взаимодействия между разработчиками и эксплуатационниками надо продумать уже с самого начала проекта перехода к работе в облачной среде. Это позволит добиться определенного баланса, контролировать действия разработчиков, получающих доступ к облачным ресурсам, будет гарантировать управляемость будущей работы и что расходы останутся в рамках отведенного бюджета. Это также поможет лучше понимать, как реально используется облачная инфраструктура в текущий момент и как будет использоваться в перспективе.
Отслеживайте запускаемые процессы и их назначение
На этапе проработки спецификации будущей облачной инфраструктуры необходимо четко представлять цели ее использования, какие процессы планируются к запуску и как в будущем будет осуществляться управление. Необходимо установить контроль за ресурсами, которые будут подключаться, и обозначить цели, ради которых они будут использоваться.
Некоторые облачные вендоры, например AWS, предлагают задать специальные параметры, через которые будет вестись отслеживание запуска каждой виртуальной машины, а также будет заранее известно, на каких этапах это должно происходить: эксплуатация, резервное копирование, балансировка нагрузки или тестирование.
Вне зависимости от выбранного метода контроля — через выбранные параметры или через традиционную таблицу учета, содержащую данные обо всех подключенных облачных ресурсах — собранная информация поможет иметь четкое представление о том, за какие ресурсы была внесена оплата, как они используются. Это позволяет наглядно контролировать, что происходит в облаке, упрощает управление ресурсами, повышает уровень контроля за текущими расходами.
Используйте автоматизацию
При использовании ИТ-оборудования и в облаке, и онпремис важно не упускать возможности автоматизации процессов. Это делается, чтобы оптимизировать применяемые практики. Цель состоит в том, чтобы добиться высокой надежности и простоты в практической работе, легко устранять ошибки, которые неизменно появляются при переходе на ручное управление.
При развертывании оборудования в нескольких облаках или в гибридной среде важно понимать, что облачные провайдеры не работают тесно друг с другом. Поэтому любой процесс внедрения распадается, как правило, на три этапа: первичная настройка будущей площадки, подготовка системы для новых условий работы и развертывание в автоматическом режиме.
Многие облачные системы позволяют распределять ресурсы динамически, выделение серверов и их поддержка не требуют ручного вмешательства. Но когда развертывание происходит сразу в нескольких облачных средах, то необходимо создавать общий, абстрактный шаблон, который будет применяться при распределении ресурсов во всех облачных средах. Базой для его создания будут служить конфигурации, формируемые динамически при реальной работе в разных облачных средах.
Проектируйте сети с учетом требований по безопасности
Если сеть спроектирована небрежно, то обеспечить ее полную безопасность практически невозможно. Проблема часто возникает тогда, когда компании допускают естественный рост сетей. В этих случаях их развитие часто идет вразрез с первоначальным планом. Учитывая такую перспективу, компании придерживаются следующего правила: они отделяют друг от друга сети, где работают сервисы, и сети, используемые для управления.
В сервисных сетях поддерживается работа всех компонентов, необходимых для функционирования прикладных служб в интересах заказчиков или пользователей. С другой стороны, управленческие сети обслуживают работу элементов, используемых для управления сетью изнутри. Такое разделение обеспечивается более надежную защиту от неавторизованного проникновения посторонних пользователей, которые могут пытаться получить доступ через Интернет.
Другое направление в развитии безопасности используемых сетей — это управление ключами доступа. В зависимости от облачного провайдера ключи могут предоставляться в виде массива данных либо через корневой сертификат, открывающий доступ ко всему клону ресурсов. Надо принимать во внимание, что реальные хакеры очень активно сканируют GitHub в поиске ключей, которые разработчики могли оставить по неосторожности или забывчивости. Поэтому если приходится работать с большим количеством активных ключей, то приходится тратить много сил на контроль, чтобы они не попали в открытый доступ.
Все это имеет прямое отношение к взаимодействию службы эксплуатации и разработчиков. Только при грамотной организации работы можно обеспечить надежную защиту всех ключей, предоставляемых сначала одной группе лиц на стадии разработки, а потом другой на стадии эксплуатации.
Правильно выбирайте параметры мониторинга
При развертывании оборудования онпремис принято заранее задавать параметры, подлежащие дальнейшему мониторингу. Однако когда это делается в облаке, то приходится работать с правилами, заданными по умолчанию. Отличие состоит в том, что компании предоставляется огромный объем учетных данных, большинство из которых не представляют для нее практического интереса.
Если опираться на то, как ведется мониторинг онпремис, то естественно воссоздать аналогичную модель учета и в облаке. Это позволит решить конкретные задачи и отфильтровать информацию, не имеющей отношения к поддерживаемой облачной сети или ее функциональности.
