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

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

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

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

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

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

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

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

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

• Регламент: Уточняйте, имеют ли клиенты какие-либо нормативные проблемы, требующие дополнительного утверждения перед применением обновлений. Например, если вы предоставляете решение для здравоохранения, включающее компоненты Интернета вещей, вам может потребоваться получить утверждение от Администрации пищевых продуктов и лекарств США (FDA) перед применением обновления.

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

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

• Откат: Рассмотрите, хотят ли клиенты откатить обновления, если есть критическое изменение и кто активирует такой запрос отката.

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

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

• Контроль, который вы готовы предоставить: Разумно ли для клиентов контролировать применение обновлений? Если вы создаете решение, используемое крупными корпоративными клиентами, ответ может быть да. Тем не менее, если вы создаете решение, ориентированное на потребителей, вряд ли вы даете любой контроль над тем, как вы обновляете или работаете с решением.

• Версии: Сколько версий вашего решения можно поддерживать в один раз? Если обнаружена ошибка или уязвимость безопасности и необходимо применить исправление, возможно, потребуется применить его ко всем версиям, которые в настоящее время используются.

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

• Откат: Может ли стратегия развертывания поддерживать откат до предыдущих версий? Вы хотите включить эту возможность?

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

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

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

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

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

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

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

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

Рассмотрим следующие вопросы:

• Уведомите клиентов о предстоящих обновлениях?

• Если вы это делаете, вы неявно запрашиваете разрешение путем предоставления возможности отказа, а также какие есть ограничения на отказ?

• У вас есть запланированное время обслуживания, которое вы используете при применении обновлений?

• Что произойдет, если у вас есть аварийное обновление, например критическое исправление для системы безопасности? Можете ли вы принудительно применить обновления в таких ситуациях?

• Если вы не можете заранее уведомить клиента о предстоящих обновлениях, можно ли предоставить ретроспективные уведомления? Например, можно ли обновить страницу на веб-сайте со списком примененных обновлений?

• Сколько отдельных версий системы будет поддерживаться в рабочей среде?

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

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

• Недавно были применены обновления к инфраструктуре клиента или к общим компонентам?

• Каков характер этих обновлений?

• Что такое предыдущая версия?

• Как часто применяются обновления к этому клиенту?

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

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

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

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

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

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

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

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

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

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

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

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

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

Этапы развертывания

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

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

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

• Ранний пользователь: Группа раннего внедрения включает клиентов, которые немного более консервативны, но все же готовы получать регулярные обновления.

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

Версии API

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основной автор:

• Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure

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

• Чад Киттель | Главный инженер по программному обеспечению, шаблоны и практики Azure
• Даниэль Скотт-Райнсфорд | Стратег технологий партнеров
• Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure

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

Связанный ресурс

• Сопоставление запросов к арендаторам в мультитенантном решении