 |
|
|
|
Проектирование отказоустойчивых систем. Часть 3. До и после внедрения
Проектирование отказоустойчивых систем Завершающая публикация из цикла статей, в которых шла речь о внедрении и передаче в эксплуатацию отказоустойчивых ИТ-систем В первых двух публикациях шла речь об используемой терминологии [1] и первых трех этапах [2] проектирования. Вкратце напомним эти три этапа:
Хочется еще раз напомнить, что в данном случае не обсуждаются такие «тонкие материи», как правила ГОСТа для составления проектной документации, законодательная база при проведении тендера госзакупок и так далее. Также напомню, что при написании этого материала я специально не акцентировал внимание на различиях при проведении работ собственными силами ИТ-отдела и внешними интеграционными проектами. Основной целью было познакомить читателей с фазами создания или модернизации отказоустойчивых ИТ-систем, а никак не дотошное погружение в детали взаимодействия с заказчиками или рассказ о нюансах бумажной волокиты при составлении проектной документации. Стоит еще раз подчеркнуть, что при работе с государственными структурами заказчик предъявляет гораздо более жесткие требования к оформлению документации, нежели при работе с некоторыми коммерческими структурами, а приработе с внутренними проектами основной акцент делается на полноте и ясности подачи материала, а не внешнем оформлении. Но в любом случае внедряемая система должна соответствовать поставленным задачам и работать без сбоев иосложнений. Пилотный проект Итак, мы будем считать, что у нас уже готов технический проект, авторы которого постарались учесть большинство положительных или отрицательных факторов. Но что произойдет, если мы вот так, с бумажной документацией, «в глаза не видя» внедряемых систем, оборудования, программного обеспечения, придем к заказчику и скажем: «Все готово для конечного внедрения, нужно только купить вот это и это, и можно будет с ходу запустить все в работу»? Разумеется, ни один человек, ни одна команда не в состоянии учесть все возможные нюансы. Возможно, нам повезет, и мы сможем провести внедрение системы, которая доэтого существовала исключительно на бумаге. Но в любой лотерее выигрышей бывает гораздо меньше, чем участников, и, если ориентироваться исключительно на удачу, рано или поздно наступит сокрушительное фиаско. Будет куда как лучше, если заранее подстраховаться и провести хотя бы минимальные тесты на проверочном стенде. Например, создается система резервного копирования. Что мешает развернуть в тестовой среде фрагмент некой абстрактной инфраструктуры, схожей с той, что имеет заказчик, установить на нее пробную версию ПО для резервного копирования и провести ряд операций по сохранению и восстановлению информации? Это позволит не только убедиться в правильности основных положений нашего технического проекта, но и провести ряд тестовых замеров. Например, проследить время создания резервной копии нужного объема при определенных характеристиках (пропускная способность сети, скорость работы дисковой подсистемы и так далее). Конечно, далеко не всегда есть возможность создать точно такую же систему, как у заказчика, но никто не запрещает провести экстраполяцию полученных данных и сравнить результаты с требуемыми характеристиками из технического задания. Аналогичным образом поступают, например, при создании системы виртуализации, создавая «уменьшенную копию» и проверяя на ней основной функционал будущей системы: развертывание гостевых систем, миграцию виртуальных машин, выполнение операций по обеспечению отказоустойчивости и много другого. Вышеописанные действия называются стадией пилотного проекта, который обязательно должен присутствовать при создании любой отказоустойчивой системы, чтобы обезопасить заказчика от неприятных «сюрпризов», а исполнителя – от потери репутации и штрафных санкций. Разумеется, на создание тестовой инфраструктуры придется затратить некоторые материальные ресурсы, а это значит, что кто-то должен за это заплатить. Есть несколько путей минимизации расходов на пилотный проект. Самый простой способ сэкономить – не «затачивать» тестовую среду под конкретный проект, а создать некое универсальное решение для работы с множеством проектов. Например, если речь идет о проектировании отказоустойчивых систем с применением виртуализации, то инфраструктура для пилотных проектов должна обеспечить тестирование различных виртуальных сред на одном и том же оборудовании. К счастью, в настоящее время существует достаточное количество решений, в том числе и на базе бесплатного ПО, позволяющих развернуть тестовую среду для проверки любых систем, в том числе и резервного копирования. Другой способ – договориться с поставщиками и заказчиком, чтобы разделить процесс приобретения оборудования для проекта на несколько этапов, при этом в состав первой партии включить все необходимое для организации пилотного проекта. Пока прибудет остальное приобретаемое оборудование и будут получены лицензии на все используемое программное обеспечение, у группы тестировщиков появляется время на отработку основных решений. Иногда бывают случаи, когда после такого этапа приходится корректировать список аппаратного обеспечения и ПО, заменяя одни позиции на другие, более соответствующие требованиям проекта. Ну и, наконец, третий способ – предложить заказчику приобрести оборудование тестового стенда, например, для дальнейшего расширения уже имеющейся инфраструктуры или для обучения персонала, а также для отработки нестандартных ситуаций, например, проведения учений по восстановлению данных. Так как это оборудование фактически уже выполнило свою основную задачу, то для дополнительной привлекательности возможно предложить егозаказчику со скидкой, в рассрочку и так далее. Следует также отметить важный момент: если предполагается дальнейшее сотрудничество исполнителя с заказчиком в виде технической поддержки, проведения платных консультаций, обучения персонала и других услуг в рамках аутсорсинга, то наличие собственного стенда, частично имитирующего инфраструктуру заказчика, является важным конкурентным преимуществом. Как видим, при должном уровне планирования и организации работы из стадии пилотного проекта можно извлечь выгоду при небольших затратах. Статью целиком читайте в журнале «Системный администратор», №6 за 2015 г. на страницах 15-19. PDF-версию данного номера можно приобрести в нашем магазине.
|
АЛЕКСЕЙ БЕРЕЖНОЙ, независимый консультант, системный архитектор, специалист по системам виртуализации и резервного копирования, Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
