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

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

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

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

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

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

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

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

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

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

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

Друзья сайта  

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

sysadmins.ru

 Проектирование отказоустойчивых систем. Часть 2. Этапы проектирования

Архив номеров / 2015 / Выпуск №5 (150) / Проектирование отказоустойчивых систем. Часть 2. Этапы проектирования

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

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

Проектирование отказоустойчивых систем

Часть 2. Этапы проектирования

Продолжаем рассказ о нюансах, встречающихся на этапе проектирования [1]. В этой части затронем вопросы аудита, составления техзадания и проекта.

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

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

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

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

Этап первый. Аудит системы

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

Но в пользу внешнего аудита говорит несколько причин:

  • Человеческий фактор. Зачастую люди склонны закрывать глаза на собственные недоработки. Возьмем, например, известную проблему – беспорядок на файловых ресурсах. Даже термин специальный выдумали: «файлопомойка». Но до определенного момента (чаще всего до серьезного происшествия) многие склонны считать, что это обычная рабочая ситуация и все данные находятся в строгом соответствии с требованиями.
  • Дополнительная экспертная оценка. Любой профессионал не может быть специалистом абсолютно во всех областях. Например, системный администратор, прекрасно владеющий навыками развертывания веб-приложений, может не обладать нужным уровнем подготовки, когда дело доходит до организации системы хранения. Привлечение внешних аудиторов позволяет получить мнение не одного, а команды специалистов, каждый изкоторых имеет хорошую подготовку в определенной области.
  • Недостаток ресурсов. В данном случае речь идет прежде всего о высвобождении рабочего времени специалистов. Не секрет, что в большинстве организаций штатные специалисты загружены по полной (а чаще всего вынуждены работать сверхурочно для выполнения тех или иных работ). И высвободить хотя бы несколько часов на решение вопросов аудита бывает очень и очень трудно.
  • Необходимость специальных исследований или испытаний. Например, при аудите систем безопасности иногда осуществляют тестовую проверку устойчивости системы защиты к вторжениям извне, проще говоря, пытаются взломать систему в целях обнаружения слабых мест в системе безопасности. При проверке системы резервного копирования и/или Disaster Recovery выполняют попытку восстановления системы в тестовой среде (например, в арендованном на время ЦОД) и анализируют результаты, в первую очередь время, потраченное на восстановление. Разумеется, выполнить подобные задачи силами одного человека или даже целой командой системных администраторов, и без того загруженных работой, зачастую не представляется возможным.
  • Подробная документация, которая составляется также во время аудита. В своей статье «Кошмар, который закончится» [2] я писал о трудностях при документировании системы, особенно при определенных подходах кработе ИТ-системы. Могу только добавить, что часто волей-неволей люди упускают из виду определенные моменты, которые так и не документируются. Например, согласно существующему распорядку полное резервное копирование должно запускаться по выходным, но администратор баз данных попросил одну базу данных временно копировать в понедельник утром, потому что по выходным формируются отчеты. Расписание перенастроили, а в документацию не внесли («это ведь все временно»), а в итоге все так и осталось.

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

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

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


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

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

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

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

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