Проектирование отказоустойчивых систем. Часть 3. До и после внедрения::Журнал СА 6.2015
www.samag.ru
Журнал «БИТ. Бизнес&Информационные технологии»      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы
1001 и 1 книга  
12.02.2021г.
Просмотров: 397
Комментарии: 0
Коротко о корпусе. Как выбрать системный блок под конкретные задачи

 Читать далее...

11.02.2021г.
Просмотров: 248
Комментарии: 0
Василий Севостьянов: «Как безболезненно перейти с одного продукта на другой»

 Читать далее...

20.12.2019г.
Просмотров: 7147
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 8191
Комментарии: 2
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 9385
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Проектирование отказоустойчивых систем. Часть 3. До и после внедрения

Архив номеров / 2015 / Выпуск №6 (151) / Проектирование отказоустойчивых систем. Часть 3. До и после внедрения

Рубрика: Администрирование /  ИТ-инфраструктура

Алексей Бережной АЛЕКСЕЙ БЕРЕЖНОЙ, независимый консультант, системный архитектор, специалист по системам виртуализации и резервного копирования, alexey.berezhnoy@tech-center.com

Проектирование отказоустойчивых систем
Часть 3. До и после внедрения

Завершающая публикация из цикла статей, в которых шла речь о внедрении и передаче в эксплуатацию отказоустойчивых ИТ-систем

В первых двух публикациях шла речь об используемой терминологии [1] и первых трех этапах [2] проектирования.

Вкратце напомним эти три этапа:

  • аудит имеющейся инфраструктуры и анализ бизнес-процессов;
  • составление технического задания;
  • создание технического проекта.

Хочется еще раз напомнить, что в данном случае не обсуждаются такие «тонкие материи», как правила ГОСТа для составления проектной документации, законодательная база при проведении тендера госзакупок и так далее.

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

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

Пилотный проект

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

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

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

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

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

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

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

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

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

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

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

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

Статью целиком читайте в журнале «Системный администратор», №6 за 2015 г. на страницах 15-19.

PDF-версию данного номера можно приобрести в нашем магазине.


  1. Бережной А. Проектирование отказоустойчивых систем. Часть 1. Термины и определения. // «Системный администратор», №4, 2015 г. – С. 10-15 (http://samag.ru/archive/article/2920).
  2. Бережной А. Проектирование отказоустойчивых систем. Часть 2. Этапы проектирования. // «Системный администратор», №5, 2015 г. – С. 22-26 (http://samag.ru/archive/article/2944).
  3. Джон Найманн, Кевин Браун, Виктор Авелар. Влияние изоляции горячего и холодного коридоров на температуру и эффективность ЦОД. // «Журнал сетевых решений/LAN», №10, 2013 г. (http://www.osp.ru/lan/2013/10/13037887).

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru