АЛЕКСЕЙ БЕРЕЖНОЙ, независимый консультант, системный архитектор, специалист по системам виртуализации и резервного копирования, alexey.berezhnoy@tech-center.com
Проектирование отказоустойчивых систем
Продолжаем рассказ о нюансах, встречающихся на этапе проектирования [1]. В этой части затронем вопросы аудита, составления техзадания и проекта.
На тему проектирования отказоустойчивых систем написано много и одновременно совсем ничего. В Интернете и на книжных полках можно найти массу материалов, например, «как сделать отказоустойчивый кластер на FreeBSD», но совсем немного написано о том, как организовать разработку и внедрение этого самого кластера. К сожалению, таким вопросам, которые одновременно принадлежат и технической, и управленческой сфере, внимания уделяется до обидного мало.
Надо заметить, что в данной статье сознательно не делается никаких разграничений между реализацией системы «на заказ», командой системного интегратора для сторонней организации или созданием или модернизацией собственной инфраструктуры своими силами, например, одним-единственным системным администратором.
Почему так? Я отдаю себе отчет в том, что для каждого случая существует своя специфика, и проекты внешней интеграции сильно отличаются от внутренних решений. Но мной движет твердая уверенность, что любые внутренние работы по модернизации имеющейся инфраструктуры должны выполняться с той же тщательностью и с тем же уровнем профессионализма, как и решения для продажи стороннему потребителю. Но не стоит забывать и о различиях, поэтому там, где это необходимо, будет указано, в каких ситуациях и на что следует обратить внимание.
И еще один важный момент. При написании данной статьи я не ставил целью создать инструкцию на все случаи жизни. Поэтому, если читатель вдруг воскликнет: «А вот у нас было совсем не так!» – это будет вполне справедливо. С другой стороны, никто и ничто не может претендовать на истину в последней инстанции даже в такой важной сфере, как проектирование отказоустойчивых систем.
Этап первый. Аудит системы
Для чего нужен аудит? Для выявления сбора информации о нуждах заказчика. «Ну, вот еще! – скажет нетерпеливый читатель. – Я-то уж свою систему знаю лучше, чем кто бы то ни было!» Вроде бы правильно, кроме самого хозяина, кому еще свое хозяйство лучше знать?
Но в пользу внешнего аудита говорит несколько причин:
- Человеческий фактор. Зачастую люди склонны закрывать глаза на собственные недоработки. Возьмем, например, известную проблему – беспорядок на файловых ресурсах. Даже термин специальный выдумали: «файлопомойка». Но до определенного момента (чаще всего до серьезного происшествия) многие склонны считать, что это обычная рабочая ситуация и все данные находятся в строгом соответствии с требованиями.
- Дополнительная экспертная оценка. Любой профессионал не может быть специалистом абсолютно во всех областях. Например, системный администратор, прекрасно владеющий навыками развертывания веб-приложений, может не обладать нужным уровнем подготовки, когда дело доходит до организации системы хранения. Привлечение внешних аудиторов позволяет получить мнение не одного, а команды специалистов, каждый изкоторых имеет хорошую подготовку в определенной области.
- Недостаток ресурсов. В данном случае речь идет прежде всего о высвобождении рабочего времени специалистов. Не секрет, что в большинстве организаций штатные специалисты загружены по полной (а чаще всего вынуждены работать сверхурочно для выполнения тех или иных работ). И высвободить хотя бы несколько часов на решение вопросов аудита бывает очень и очень трудно.
- Необходимость специальных исследований или испытаний. Например, при аудите систем безопасности иногда осуществляют тестовую проверку устойчивости системы защиты к вторжениям извне, проще говоря, пытаются взломать систему в целях обнаружения слабых мест в системе безопасности. При проверке системы резервного копирования и/или Disaster Recovery выполняют попытку восстановления системы в тестовой среде (например, в арендованном на время ЦОД) и анализируют результаты, в первую очередь время, потраченное на восстановление. Разумеется, выполнить подобные задачи силами одного человека или даже целой командой системных администраторов, и без того загруженных работой, зачастую не представляется возможным.
- Подробная документация, которая составляется также во время аудита. В своей статье «Кошмар, который закончится» [2] я писал о трудностях при документировании системы, особенно при определенных подходах кработе ИТ-системы. Могу только добавить, что часто волей-неволей люди упускают из виду определенные моменты, которые так и не документируются. Например, согласно существующему распорядку полное резервное копирование должно запускаться по выходным, но администратор баз данных попросил одну базу данных временно копировать в понедельник утром, потому что по выходным формируются отчеты. Расписание перенастроили, а в документацию не внесли («это ведь все временно»), а в итоге все так и осталось.
По итогам аудита формируется экспертное заключение, в котором указываются выявленные «узкие места» и даются рекомендации по их устранению. Помимо наличия полезной информации, такой отчет служит хорошим аргументом при разговоре с руководством компании о необходимости модернизации имеющейся системы, соответственно о выделении на это денежных средств.
Статью целиком читайте в журнале «Системный администратор», №5 за 2015 г. на страницах 22-26.
PDF-версию данного номера можно приобрести в нашем магазине.