Это нельзя виртуализировать!

Нам постоянно говорят об этом в IT: вендор заявляет, что систему нельзя виртуализировать. Причин называется множество. С нашей стороны, IT-специалисты всегда поражаются тому, что вендор позволяет себе столь возмутительные заявления; и не меньше нас удивляет то, что клиент (или менеджер) им верит. Вендоры годами оттачивали этот рекламный приём, и я думаю, что важно разобраться в нём по существу.

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

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

Один из распространённых способов добиться этого — не поддерживать ни одну актуальную операционную систему, де-факто переводя собственное ПО в устаревшее состояние (например, сегодня это означало бы поддержку только Windows XP и более ранних версий). Другой пример — поддерживать только те продукты, которые не лицензированы для данного сценария использования (скажем, требовать использования Windows 10 в качестве сервера). И один из самых распространённых случаев — прямой запрет виртуализации.

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

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

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

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

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

Разве это не важно?

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

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

Поддерживается ли продукт? Тестируется ли он?

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

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

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

Если проприетарный продукт развёртывается в производственной среде и принято решение отказаться от лучших практик развёртывания ради соответствия требованиям поддержки, как это вписывается в матрицу принятия решений? Должно ли это означать, что надлежащей поддержки не существует? Снова, как и прежде, это указывает на несоответствие наших потребностей.

 

Ведётся ли разработка продукта?

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

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

 

Как можно поддержать продукт, если платформа не поддерживается?

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

Не хватает ли отраслевых навыков и знаний?

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

Главная проблема

Главная, всеобъемлющая проблема программного обеспечения, предъявляющего сомнительные требования к развёртыванию и обслуживанию в обмен на разблокировку иначе недоступной поддержки, заключается не в том, что мы обычно предполагаем, — это не вопрос общего качества программного обеспечения, а вопрос жизнеспособности поддержки и практик разработки. То, что эти проблемы указывают на серьёзные опасения относительно долгосрочной поддержки, должно заставить нас настойчиво задаться вопросом: почему мы вообще выбираем эти пакеты, рассчитывая на надёжную поддержку, когда с самого начала у нас есть весьма видимые и весьма серьёзные опасения?

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

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