Облачный скачок: наработки на отказ

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

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

1. Оптимизация пакета приложений


Будем честны – в крупных предприятиях ситуация, когда несколько приложений выполняют во многом схожие функции, но остаются в использовании из-за удобства/проблем с наследственностью/потому что никто не обращает на это внимание – не редкость. Но переходя на облачную платформу вам придется платить за потребление этих вычислительных ресурсов. Оптимизируя пакет приложений вы должны определить таким места, где функциональность ваших приложений пересекается и консолидировать их в одно или просто избавиться от лишних. Это своего рода весенняя уборка в доме перед переездом на новую квартиру. Ликвидация всего ненужного сэкономит вам как средства на поддержание функционирования избыточной инфраструктуры, так и упростит процесс перехода. Чем проще будет программная платформа, тем проще будет ее адаптировать.

2. Рационализация в рамках бизнес-деятельности и определение целей


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

Техническая задача: Ежеквартальное обновление серверного ПО.
Мотивация: Отсутствие обновлений повышает риск взлома злоумышленниками, что повлечет за собой урон репутации и потерю прибыли.

3. Оценка состояния архитектуры (как приложений так и инфраструктуры)


Эта задача может выглядеть простой но на деле для большинства компаний довольно сложна. Что именно необходимо сделать? Оценка состояния инфраструктуры подразумевает под собой документацию компонентов развернутых приложений, инфраструктурных модулей, взаимозависимостей между приложениями. Но почему эта задача зачастую оказывается такой трудной? Большинство предприятий в попытке документировать такую информацию устанавливают и поддерживают у себя Базы данных управления конфигурациями, но такие базы данных как правило поддерживаются вручную и нерегулярно. По мере того как изменения в приложениях и инфраструктуре накапливаются, базы все меньше отражают истинное положение дел. Чтобы избежать такого результата, стоит использовать какие-либо автоматизированные средства. Они могут «сканировать» серверы, отмечая процессы, сетевые соединения, и прочие элементы через определенные промежутки времени. На выходе получается детализированная карта, отражающая все постоянные связи между хостами, независимо от того, относятся ли эти связи к приложениям. Однако, такая карта тоже может быть неполной. В ней могут отсутствовать короткоживущие соединения.

4. Оценка производительности текущей системы


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

5. Оценка влияния изменений на архитектуру


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

6. Планирование решения проблем


Как я уже говорил: мониторинг, мониторинг, мониторинг. Его роль значительно возрастает так как у вас уже не будет непосредственного доступа к «железу», а из-за виртуализации и динамического масштабирования нагрузки количество “узких мест” возрастет. Вы должны обладать инструментами, которые позволят точно локализовывать проблемы, иначе большую часть времени вы будете не устранять неполадки, а искать их причины. Постоянный мониторинг состояния приложений и инфраструктуры должен стать нормой жизни.

7. Переориентация процессов


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

8. Переработка приложений


Этот шаг является логическим продолжением этапа №5 и объем работ на нем зависит от результатов, полученных на этом этапе. Возможно, вашим приложениям понадобится только небольшая полировка, возможно — коренная переработка. Если код приложения меняется, его необходимо тестировать заново.

9. Тестирование функциональности и производительности приложений


Тестирование необходимо для обеспечения совместимости с облачной средой.

10. Обучение персонала


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

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

Комментарии (0)


Добавление комментариев доступно только зарегистрированным пользователям. Используйте свою существующую учетную запись для авторизации. Если у Вас еще нет учетной записи на сайте ее можно создать пройдя несложную процедуру регистрации. Кстати, для входа на сайт, наравне с учетной записью на cloudzone.ru, можно использовать аккаунт из следующих популярных сервисов: Яндекс, Facebook, Google и LinkedIn