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

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

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

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

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

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

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

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

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

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

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

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