Поделиться через

Рекомендации по обновлению мультитенантного решения

  • Статья

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

При планировании стратегии обновления решения необходимо выполнить следующие действия.

  • Определите требования клиентов.
  • Уточняйте собственные требования для работы службы.
  • Найдите баланс, который вы и ваши клиенты могут принять.
  • Четко общаться с вашей стратегией с клиентами и другими заинтересованными лицами.

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

Требования клиентов

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

  • Ожидания и требования: выявление любых ожиданий или требований, которые могут возникнуть у клиентов при обновлении их решения. Они могут быть официально переданы вам в контрактах или соглашениях на уровне обслуживания, или они могут быть неофициальными.
  • Периоды обслуживания. Узнайте, ожидают ли клиенты определенных служб или даже самоопределиемых периодов обслуживания. Может потребоваться сообщить пользователям о возможных сбоях или протестировать важные аспекты службы после завершения обновления.
  • Правила. Уточняйте, имеют ли клиенты какие-либо нормативные проблемы, требующие дополнительного утверждения перед применением обновлений. Например, если вы предоставляете решение для здравоохранения, включающее компоненты Интернета вещей, вам может потребоваться получить утверждение от США продовольственной и наркотической администрации (FDA) перед применением обновления.
  • Конфиденциальность. Сведения о том, являются ли ваши клиенты особенно чувствительными или устойчивыми к применению обновлений. Если они есть, попробуйте понять, почему. Например, если они работают с физическим магазином или розничным веб-сайтом, они могут избежать обновлений вокруг Черной пятницы, так как риски выше потенциальных преимуществ.
  • Журнал. Просмотрите собственную запись отслеживания успешного завершения обновлений без каких-либо последствий для ваших клиентов. Вы должны следовать хорошим рекомендациям DevOps, тестированию, развертыванию и мониторингу, чтобы снизить вероятность сбоев, и обеспечить быстрое выявление проблем, которые представляют обновления. Если клиенты знают, что вы сможете обновлять свои среды плавно, они менее вероятно, что они будут выполнять объект.
  • Откат: рассмотрите, хотят ли клиенты откатить обновления, если есть критическое изменение, и кто активирует такой запрос отката.

Ваши требования

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

  • Контроль, который вы готовы предоставить: Разумно ли для клиентов иметь контроль над применением обновлений? Если вы создаете решение, используемое крупными корпоративными клиентами, ответ может быть да. Тем не менее, если вы создаете решение, ориентированное на потребителей, вряд ли вы предоставите любой контроль над тем, как вы обновляете или работаете с решением.
  • Версии: Сколько версий решения можно поддерживать в один раз? Помните, что если вы нашли ошибку и хотите его исправление, возможно, потребуется применить исправление ко всем используемым версиям.
  • Последствия старых версий: Что такое влияние, позволяющее клиентам отстать от текущей версии? Если вы регулярно выпускаете новые функции, старые версии становятся устаревшими быстро? Кроме того, в зависимости от стратегии обновления и типов изменений может потребоваться поддерживать отдельные инфраструктуры для каждой версии решения. Таким образом, могут быть как операционные, так и финансовые затраты, так как вы поддерживаете поддержку старых версий.
  • Откат. Может ли стратегия развертывания поддерживать откаты до предыдущих версий? Это то, что вы хотите включить?

Примечание.

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

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

Дополнительные сведения о достижении развертываний с нулевой простоем см. в статье "Устранение простоя с помощью обновлений версий службы".

Поиск баланса

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

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

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

Другим способом может быть разрешение клиентам инициировать собственные обновления во время их выбора. Опять же, необходимо указать крайний срок, когда вы применяете обновление от их имени.

Предупреждение

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

Все, что вы делаете, убедитесь, что у вас есть процесс отслеживания работоспособности клиентов, особенно до и после применения обновлений. Часто критически важные рабочие инциденты (также называемые инцидентами live-site) происходят после обновления кода или конфигурации. Поэтому важно заранее отслеживать и реагировать на любые проблемы, чтобы сохранить доверие клиентов. Дополнительные сведения о мониторинге см . в рекомендациях по проектированию и созданию системы мониторинга.

Взаимодействие с клиентами

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

Оцените следующие вопросы.

  • Уведомите клиентов о предстоящих обновлениях?
  • Если вы делаете, вы неявно запрашиваете разрешение путем предоставления процесса отказа и какие ограничения при отказе?
  • У вас есть запланированное время обслуживания, которое вы используете при применении обновлений?
  • Что произойдет, если у вас есть аварийное обновление, например критическое исправление для системы безопасности? Можете ли вы принудительно обновить эти ситуации?
  • Если вы не можете заранее уведомить клиента о предстоящих обновлениях, можно ли предоставить ретроспективные уведомления? Например, можно ли обновить страницу на веб-сайте со списком примененных обновлений?
  • Сколько отдельных версий системы будет поддерживаться в рабочей среде?

Обмен данными с группой поддержки клиентов

Важно, чтобы ваша собственная группа поддержки полностью учитывала обновления, которые были применены к инфраструктуре каждого клиента. Представители службы поддержки клиентов могут легко ответить на следующие вопросы:

  • Недавно были применены обновления к инфраструктуре клиента или к общим компонентам?
  • Каков характер этих обновлений?
  • Что такое предыдущая версия?
  • Как часто применяются обновления к этому клиенту?

Если у одного из клиентов возникла проблема из-за обновления, необходимо убедиться, что у вашей группы поддержки клиентов есть сведения, необходимые для понимания изменений.

Стратегии развертывания для поддержки обновлений

Рассмотрите способ развертывания обновлений в инфраструктуре. Это сильно влияет на модель аренды, которую вы используете. Три распространенных подхода к развертыванию обновлений — метки развертывания, флаги компонентов и кольца развертывания. Эти подходы можно использовать независимо друг от друга или объединить их в соответствии с более сложными требованиями.

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

Шаблон меток развертывания

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

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

Флаги функций

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

Рекомендуется использовать флаги функций, если к вам применяются следующие ситуации:

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

Вы можете внедрить в приложение поддержку флагов функций, написав код самостоятельно или используя службу, например Конфигурация приложений Azure.

Круги развертывания

Кольца развертывания позволяют постепенно развертывать обновления в наборе клиентов или меток развертывания. Вы можете назначить подмножество клиентов каждому кольцу.

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

  • Canary: Канарное кольцо включает в себя собственные тестовые клиенты и клиенты, которые хотят иметь обновления сразу после их доступности, с пониманием того, что они могут получать более частые обновления, и что обновления могут не пройти как комплексный процесс проверки, как и в других вещах.
  • Ранний метод внедрения: кольцо раннего внедрения содержит клиентов, которые немного более рискованные, но которые по-прежнему готовы получать регулярные обновления.
  • Пользователи: большинство клиентов будут принадлежать кругу пользователей , которое получает менее частые и более проверенные обновления.

Версии API

Если служба предоставляет внешний API, рассмотрите, что любые обновления, которые вы применяете, могут повлиять на то, как клиенты или партнеры интегрируются с вашей платформой. В частности, необходимо быть в курсе критических изменений в API. Рекомендуется использовать стратегию управления версиями API, чтобы снизить риск обновлений API.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

  • Джон Даунс | Главный инженер программного обеспечения

Другие участники:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующий шаг

Учитывайте, когда вы будете сопоставлять запросы с клиентами в мультитенантном решении.