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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Версии API

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

Соавторы

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

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

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

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

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

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

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

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