Содержание


Достижение режима Always On: внесение изменений без нарушения обещания постоянной эксплуатационной готовности

Производите инновации, внося изменения без прерывания обслуживания

Comments

Когда вы в следующий раз будете в аэропорту, присмотритесь к замаянным бизнес-путешественникам. Часто они работают на своем планшете или ноутбуке, одновременно разговаривая по смартфону. Мы живем в мире, где прерывание обслуживания приводит к потере производительности труда. Любое изменение в приложении – за немногими исключениями – ведет к нарушению обслуживания, а это не нравится клиентам.

Мы живем в эпоху, когда перебои в обслуживании недопустимы. В современном мире облаков, анализа, мобильности и общения письменное соглашение об уровне обслуживания не имеет никакого значения. Люди ожидают, что их приложения будут работать бесперебойно. Аналитики отказываются от задач, решаемых бэкофисом, и становятся участниками бизнес-операций реального времени. Мы ожидаем, что мобильные приложения в наших телефонах и планшетах будут работать с момента включения в любое время и в любом месте. Реакция общественности на недоступность службы усиливается социальными сетями. Перебои способны уничтожить репутацию, завоеванную с таким трудом. Мы живем в сплошном мире, где круглые сутки кто-нибудь где-то хочет пользоваться нашими услугами. Больше не существует «нерабочего времени», которое можно использовать для плановых мероприятий. Другими словами, больше нет места для плановых отключений.

Для постоянной эксплуатационной готовности также требуется способность:

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

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

Начать нужно, пожалуй, с определения режима Always On:

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

В отчете Gartner Цикл ажиотажа вокруг управления непрерывностью работы ИТ-служб говорится:

Непрерывная готовность охватывает две стратегии: высокой надежности (минимизация времени внеплановых простоев) и непрерывной работы (минимизация плановых простоев).
 

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

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

Для обеспечения 100%-ой эксплуатационной готовности требуется радикально иной подход к разработке служб/приложений, способу их развертывания с компонентами избыточности для обеспечения режима Always On и способа их поддержки по мере выпуска новых версий. Это трудные задачи.

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

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

Необходимость введения ненарушающих изменений

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

  • менее 10% всех организаций полностью готовы идти в ногу с тенденциями в направлении мобильных систем, социальных сетей, больших данных/ анализа и облачных вычислений;
  • более 60% организаций планируют увеличить свои инвестиции в ИТ-инфраструктуру в течение ближайших 12-18 месяцев;
  • сегодня примерно 80% текущей рабочей нагрузки обрабатывается на существующих платформах ИТ-инфраструктур, а не на облачных платформах.

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

  • мобильные приложения и темпы изменений: потребители привыкли получать регулярные обновления на свои телефоны и ожидают исключительного удобства работы с приложениями;
  • среды, определяемые программным обеспечением (Software Defined Environments - SDE): SDE оптимизируют хранение, обработку и передачу данных, позволяя ИТ-организациям предоставлять услуги наиболее эффективным способом;
  • экспертно-интегрированные системы: эти системы включают в себя предварительно настроенное аппаратно-программное решение, содержащее встроенный опыт, изначально интегрированное и обеспечивающее упрощенную работу;
  • облако: облачные вычисления стали ключевой тенденцией, направленной на поддержку объединенной инфраструктуры и коллективного обслуживания как во внутренних, так и во внешних топологиях сетей организаций, что привело к созданию гибридных облаков;
  • непрерывная поставка/DevOps: этот процесс сближает группы разработки и эксплуатации систем.

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

В отчете Gartner Цикл ажиотажа вокруг управления непрерывностью работы ИТ-служб говорится:

«Хотя в целом качество обслуживания критически важных приложений (таких как системы бухгалтерского учета) улучшилось, на большинстве предприятий эксплуатационная готовность остается «недостаточно хорошей», так как стоимость простоев продолжает нарастать».
 

Но дело не только в том, чтобы избежать простоев. Успешные компании смотрят на эксплуатационную готовность иначе. В сегодняшней деловой и экономической среде у каждой компании должна быть возможность улавливать изменения тенденций рынка и быстро реагировать на них. Возьмите Netflix, Salesforce.com или Amazon. Ясно, что они нашли секрет непрерывной поставки (хотя иногда и у них бывают проблемы). Достижение максимального времени безотказной работы – это не только вопрос исключения рисков, это вопрос элементарного выживания, и если ваша организация правильно реализует этот подход, вы сможете получить конкурентное преимущество.

Структура, обеспечивающая ненарушающее внесение изменений

Отчет Gartner Цикл ажиотажа вокруг управления непрерывностью работы ИТ-служб выделяет сферу проектирования как часть подхода к непрерывному обслуживанию. В нем говорится:

«Для достижения 100%-й или почти 100%-й эксплуатационной готовности требуется подход сверху вниз по обеспечению готовности на уровне приложения, инфраструктуры и операционной архитектуры.

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

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

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

Традиционным подходом к введению любых из этих изменений является плановый останов. Если все работает, как запланировано, то окно в обслуживании должно быть небольшим. К сожалению, это не всегда так. Недавнее исследование IBM Экономика ИТ-рисков и репутация показало, что человеческий фактор приводит к нарушению работы на 70% чаще, чем ожидали ИТ-специалисты.

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

В чем трудность достижения ненарушающих изменений?

Одна из главных трудностей – организационные проблемы. Для внесения изменений без прерывания обслуживания требуется гибкая и адаптируемая организация. Традиционный подход к проектированию и разработке ИТ-решений, основанный на изолированных подразделениях, приводит к разрозненным навыкам и опыту. Для успеха подхода Always On требуется сотрудничество и координация. Кроме того, необходимо, чтобы руководство рассматривало этот подход как стратегический и выделяло в поддержку инициативы надлежащее финансирование.

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

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

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

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

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

Методы достижения бесперебойного обслуживания

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

DevOps позволяет установить связь между разработкой программного обеспечения и ИТ-операциями для поддержки быстрой реализации и развертывания программного обеспечения в производственной среде с помощью различных методов.

В отчете Puppet Lab Состояние DevOps за 2014 год говорится, что успешные организации развертывают код в 30 раз чаще, и при этом у них на 50% меньше отказов. В отчете описываются различные показатели производительности ИТ-организаций, такие как частота развертывания, время внесения изменений (пропускная способность), среднее время восстановления после отказа (стабильность) и интенсивность отказов при внесении изменений. DevOps – хороший помощник при реализации ненарушающего введения изменений. Существует ряд ключевых методов и практических подходов как с применением DevOps, так и без DevOps, которые организации могут использовать для создания фундамента непрерывного обслуживания.

Непрерывная поставка: гибкий подход к разработке программного обеспечения, непрерывная поставка упрощает процесс доставки изменений пользователям. Непрерывная поставка часто сочетается с непрерывной интеграцией (частое и регулярное внесение изменений в код), автоматизированным тестированием и непрерывным развертыванием. Это позволяет рассылать конечным пользователям изменения (исправления ошибок или обновления) предсказуемым и проверенным образом.

В качестве заметки на полях. Один из инфраструктурных методов, используемых в контексте непрерывной поставки, называется «светлый пул/темный пул». При этом методе запросы принимает (выполняет обслуживание) только светлый пул. Оба пула работают в производственном режиме. Темный пул используется для подготовки следующей версии приложения. Когда новое приложение готово, ИТ-служба меняет светлый и темный пулы местами. Темный пул становится светлым и начинает принимать запросы (с использованием новой версии приложения). Светлый пул становится темным и находится наготове на тот случай, если потребуется откат. Вскоре после этого светлый пул может использоваться как промежуточная платформа для следующей версии приложения.
 

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

Автоматизированное тестирование: внеплановые простои обычно бывают вызваны людьми (40%) и процессами (40%). Аппаратные и операционные систем становятся источником проблем лишь в 20% случаев. 80% охватывают сферу приложения, а также людей и процессы, участвующие в создании приложения. Автоматизированное тестирование повышает стабильность и качество, в максимально возможной степени исключает ручные шаги и ускоряет цикл поставки. Автоматизированное тестирование относится к регрессионному тестированию и приемочному тестированию пользователями.

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

Параллельное управление версиями: параллельное управление версиями позволяет организациям поддерживать поэтапное внедрение новых версий приложения. Часто новые версии развертываются в производственной среде постепенно, чтобы минимизировать потенциальные последствия ошибок. При таком подходе существует интервал времени, когда в производственной среде развертываются и принимают запросы две (или более) версии приложения. На этом этапе двум разным клиентам могут предложены разные версии приложения (например, в зависимости от номера клиента или его географического положения). Продолжительность интервала времени, в течение которого версии приложения N и N-1 могут (или должны) сосуществовать, зависит от бизнес-требований. Это относится и к A/B-тестированию.

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

Организационные аспекты непрерывного обслуживания

Для немногих успешных организаций режим Always On и внесение изменений без прерывания обслуживания – в самой природе этих организаций. Принимая решения, большие или малые, сотрудники считают внесение изменений без прерывания обслуживания естественным, потому что режим Always On и ненарушающие изменения – часть корпоративной культуры. Для таких организаций задача номер один – обеспечение исключительного удобства для клиента, а не реагирование на изменения нормативных требований. Работники этих организаций, исполняя свои обязанности, легко могут опираться на важность режима Always On. Каждый знает и думает о том, что от простоя пострадают клиенты. Существуют приемы защиты качества обслуживания конечных пользователей путем предотвращения простоев. Имеются также средства постоянного повышения этого качества путем предложения клиентам новых возможностей. Инновации обеспечиваются культурой проб и ошибок, открытости, усвоения уроков и обмена передовым опытом.

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

  • Уровень зрелости: важно понимать, каков ваш текущий уровень зрелости. Это понятие охватывает ряд различных предметов. Например, предоставляете ли вы разработчикам возможность самообслуживания для воссоздания среды разработки? Поддерживаете ли вы A/B-тестирование? Как вы принимаете решения, когда нужно дать ход одному из двух конкурирующих проектов? Это понимание даст вам опору и послужит отправной точкой. Далее, установите цели по этим направлениям для продвижения к тому уровню зрелости, которого вы хотите достичь. Это и будет вашей задачей. Наконец, применяйте методы и реализуйте проекты, двигаясь от начального уровня к своей цели.
  • Связь: программа связи необходима для того, чтобы передавать поддержку и распоряжения руководства, регулярно сообщать о достижениях, отмечать успехи и выражать признание основным участникам. Как это делать, зависит от того, что лучше подходит вашей компании: объявления с городской ратуши, информационные бюллетени, блоги, email, плакаты, доски объявлений или что-то еще. Здесь также важно организовать последовательный и легко узнаваемый внутренний маркетинг и брендинг.
  • Знания: критически важное значение имеет использование всех доступных средств – от примера более опытного специалиста до ознакомительных и учебных программ, формального образования, повышения квалификации и поддержки. Здесь, вероятно, придется рассмотреть разные профессии и должности (разработчик программного обеспечения, ИТ-администратор и т.п.) и разработать для них соответствующие учебные программы. Некоторые компании успешно применяют игры и программы поощрений, в которых сотрудники зарабатывают награды за успешное окончание учебных курсов.

Возможности продуктов и услуг

Культура и процессы важнее инструментов, но, тем не менее, инструменты играют важную роль в достижении режима ненарушающих изменений. В этом разделе рассматриваются некоторые ключевые требования к продуктам и услугам поставщиков и партнеров, которые значительно помогают в достижении поставленных целей. Следующие критерии или возможности создают основу для обсуждения и оценки конкретных предложений, независимо от того, облачено ли предложение в форму решения «программное обеспечение как услуги» (SaaS) или это традиционное ПО.

  • Внедрение обновлений без простоев: этот критерий относится к области эксплуатационной технологичности. Продукт или услуга обновляется до уровней нового кода, не создавая видимых простоев или потери данных. Обратите внимание, что этот критерий относится как к самому продукту или услуге, так и к программным и аппаратным компонентам, на которые он(а) опирается.
  • A/B тестирование: новая версия продукта или услуги развертывается и тестируется с подмножеством пользователей в производственной среде. Эта новая версия работает параллельно с текущей версией и позволяет экспериментировать, например, развертывая новые выпуски.
  • Параллельное управление версиями: две версии продукта или услуги развертываются и эксплуатируются в производственной среде. Это требуется для A/B-тестирования, но чаще – для поддержки поэтапного выпуска новых версий кода.
  • Возврат/откат: экземпляр продукта или службы возвращается к предыдущей версии. Это необходимо в случае обнаружения ошибок.
  • Развертывание в нескольких зонах доступности: это относится к SaaS или способу развертывания программного обеспечения. Работая на разных уровнях доступности (уровень 1, уровень 2 и т.п.), а не только на самом широком необходимом уровне, легче вносить изменения и производить контроль качества, начиная с нижнего уровня.

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

Разработка плана действий для достижения режима ненарушающих изменений

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

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

В отношении организационной согласованности можно:

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

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

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

Заключение

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

Отчет Gartner Цикл ажиотажа вокруг управления непрерывностью работы ИТ-служб демонстрирует важность удовлетворения этого требования.

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

Из этой статьи вы узнали о внесении изменений без прерывания обслуживания и связанных с этим задачах и условиях, относящихся к людям, процессам или технологиям. Вы узнали о синергии между различными группами, такими как группа разработки и ИТ-операций, а также о возможностях продуктов, способных помочь в достижении этой цели. Режим Always On и внесение изменений без прерывания обслуживания даются не даром. Это возможно не для всех приложений. Некоторые внутренние приложения не следует делать целью этих усовершенствований, по крайней мере, на начальном этапе. Однако считается, что со временем большинство приложений будет двигаться к этой модели в соответствии с приоритетами организаций.

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=1012848
ArticleTitle=Достижение режима Always On: внесение изменений без нарушения обещания постоянной эксплуатационной готовности
publish-date=08072015