Выбор версий программного обеспечения для развёртывания

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

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

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

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

Начнём со второго случая, поскольку для него гораздо проще дать рекомендации.

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

Программное обеспечение — это не то же самое, что другие типы продуктов, особенно в современном мире онлайн-выпуска исправлений и обновлений. Я предполагаю, что менталитет о том, что старые версии программного обеспечения могут быть предпочтительнее текущих, возникает из сочетания физических продуктов (часы, автомобили, посуда, мебель, вино), где определённый год или модель может быть лучше более новой модели по разным причинам, и из устаревших способов поставки программного обеспечения, когда готовые программные продукты просто «перебрасывались через стену» и конечное состояние было, по сути, просто конечным состоянием без разумных возможностей для обновлений, исправлений или правок. Ни один из этих случаев не применяется к современному корпоративному программному обеспечению (за редчайшими исключениями).

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

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

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

В рамках того, что я уже сказал, важно поговорить о зрелости кода. Часто зрелость кода называется причиной развёртывания «старого кода», но я думаю, что это ИТ-недоразумение процессов разработки программного обеспечения. Если мы думаем о выпущенной версии кода, просто то, что она выпущена и используется, не делает её действительно более зрелой. Код не меняется в реальной жизни, он просто там лежит. Его зрелость «заморожена» в день выпуска. Если он исправляется, то да, он «созреет» после выпуска. Более поздние версии того же программного обеспечения, основанные на той же кодовой базе, но более актуальные, являются действительно более «зрелым» кодом, поскольку они были проверены, обновлены, протестированы и т.д. в большей степени, чем ранний выпуск того же кода.

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

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

Воспользуемся реальным примером, очень актуальным сегодня. Вы в компании и собираетесь установить первый(-е) сервер(-ы). Windows Server 2012 R2 только что вышел. Следует ли вам устанавливать Windows Server 2008, 2008 R2 (2010), Server 2012 или Server 2012 R2 (конец 2013)?

Для многих компаний это звучит так, будто речь идёт о двух-четырёх совершенно разных продуктах, у каждого из которых, вероятно, есть разные причины для выбора. Это, в целом, неверно. Каждая более новая версия — это просто обновление, апдейт, исправление и увеличение функций предыдущей. Каждая из них, в свою очередь, более продвинута и зрела, чем предшествующая. Каждая новая версия извлекает пользу из работы, проделанной над исходным выпуском её предшественника, а также из исправлений ошибок, патчей и дополнений функций, внесённых в промежутке между исходным выпуском и выпуском преемника. Каждый новый выпуск по сути является «минорным выпуском» предыдущего. Если мы посмотрим на номера ревизий ядра вместо маркетинговых названий выпусков, это может иметь больше смысла.

Windows Server 2008 был Windows NT 6.0. Windows Server 2008 R2 был Windows NT 6.1 — очевидно, минорная ревизия или даже «патч» предыдущего выпуска. Windows Server 2012 был Windows NT 6.2, а текущий Windows Server 2012 R2 — это Windows NT 6.3. Если бы мы использовали номера ревизий вместо маркетинговых названий, звучало бы почти безумно намеренно устанавливать старую, менее зрелую, менее обновлённую и менее пропатченную версию. Мы хотим последние обновления, последние исправления ошибок и чтобы последние проблемы безопасности были устранены.

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

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

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

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

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

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

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

Чтобы снова применить пример Microsoft, возьмём организацию, в которой сегодня развёрнута Windows XP. Бизнес решает инвестировать в цикл обновления до более новой версии, а не просто продолжать исправление. Существует несколько версий настольной платформы Windows, которые всё ещё находятся под активной поддержкой Microsoft. К ним относятся Windows Vista, Windows 7, Windows 8 и Windows 8.1. Обновление до одной из менее актуальных версий приводит к меньшему времени до окончания срока жизни этой версии, что увеличивает организационный риск. Использование старых версий означает продолжение инвестиций в уже устаревшие технологии, что означает увеличение технического долга и меньший доступ к новым функциям, которые могут оказаться полезными, как только станут доступными. В этом конкретном примере более новые версии также считаются более безопасными и требуют меньше аппаратных ресурсов.

Каждый бизнес должен найти правильный баланс для себя в циклах обновления существующего программного обеспечения. Каждый бизнес и каждый пакет программного обеспечения индивидуальны. Корпоративное программное обеспечение, такое как Microsoft Windows, Microsoft Office или Oracle Database, следует этим моделям очень хорошо. Небольшие программные проекты и те, что ближе к заказным, могут иметь более динамичный и непредсказуемый цикл выпуска, но в целом по-прежнему будут следовать большинству этих правил. Рассмотрите возможность применения понимания процесса разработки программного обеспечения, чтобы понять, как вы и ваш поставщик программного обеспечения можете наилучшим образом сотрудничать для обеспечения наибольшей ценности для вашей организации, и сочетайте это с вашей потребностью в сокращении технического долга, чтобы использовать ваши инвестиции в программное обеспечение наилучшим для вашей организации способом.

Но основные правила относительно просты:

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

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