Упрощенная HTML-версия
49
август 2010
Банки и деловой мир
Информационные технологии
спецификаций, что нередко требует де-
тальной проработки решения с произ-
водителями оборудования и системного
программного обеспечения и непосред-
ственно с разработчиками приложения.
При разработке архитектуры решения
в части IT-инфраструктуры следует всег-
да учитывать имеющийся у заказчика IT-
ландшафт, требования к выбору постав-
щиков оборудования, предпочтительных
платформах и технологиях… Нужно так-
же детально понять бизнес-требования к
приложению, фактические параметрына-
грузки, требования к масштабированию
системы в будущем. Во многих случаях
рекомендуется проведение 1–3-дневного
аудита непосредственно на площадке и
предоставление заказчиком информации
в соответствии с предпроектным опро-
сником. В результате появится понимание
ряда значимых аспектов.
Средняя допустимая продолжитель-
•
ность незапланированного простоя
в день.
Возможность плановых остановок
•
системы в заранее оговоренное время
для выполнения регламентных работ,
установки обновлений и проч.
Целевая точка восстановления (RPO;
•
интервал времени, за который допу-
стимо потерять транзакции).
Целевое время восстановления (RTO;
•
допустимый интервал времени вос-
становления после аварии).
Режим планируемой эксплуатации
•
внедряемой системы.
Общее количество пользователей си-
•
стемы.
Количество одновременно работаю-
•
щих пользователей системы.
Переченьпланируемыхкиспользованию
•
функциональных модулей системы.
Иногда для оптимизации решения и
проверкиосновныххарактеристикнапред-
метпроизводительностиивзаимодействия
может потребоваться проведение опреде-
ленных тестов (сайзинга) на подлинных
данных и с использованием оборудования
и программ, планируемых к приобрете-
нию. В таких случаях проводится:
разработка методологии и плана те-
•
стирования;
создание стенда на выбранной
•
программно-аппаратной платформе;
подготовка тестовых данных;
•
генерация максимально адекватных
•
нагрузок;
возможная оптимизация решения,
•
корректировка спецификаций;
согласование решения с вендорами
•
оборудования и ПО.
Но прежде чем окончательно остано-
вить свой выбор на конкретной архитек-
туре, технических решениях отдельных
компонентов и приложения в целом,
целесообразно проработать и получить
правильные, построенные на достовер-
ных данных ответы на стержневые во-
просы, в том числе такие.
Оптимальна ли выбранная архитекту-
•
ра в принципе?
Перспективна ли выбранная платфор-
•
ма, каков ее жизненный цикл?
Оценены ли риски выбранного реше-
•
ния?
Обеспечена ли совместимость отдель-
•
ных компонент между собой и с при-
ложением?
Пример IT-инфраструктуры программно-аппаратного комплекса
дистанционного обслуживания клиентов банка