Или о чем Заказчики довольно часто забывают писать ТЗ и получают проблемы, которые потом преследуют их годами. На эту тему, со временем, будет много постов.
Сегодня мы поговорим о масштабировании информационных систем. История из практики.
Некая большая организация со многими тысячами сотрудников заказывает себе разработку новой довольно сложной информационной системы, которая должна стать одной из ключевых в автоматизации производственной деятельности этой организации. Пишется техническое задание с очень насыщенные функционалом, долго-долго согласовывается и отдается в реализацию.
Через некоторое время Исполнитель приносит результат и начинается его внедрение. Систему пытаются запустить в инфраструктуре Заказчика. Внезапно выясняется, что виртуальная платформа Заказчика, на которой работает 95% всех прикладных и инфраструктурных систем (~600 виртуальных машин) не может обеспечить функционирование серверов баз данных разработанной системы, по причине того, что они оказались крайне требовательны к производительности дисковой подсистемы. Разделить серверы БД на несколько серверов, разложить их по разным разделам разных СХД нельзя, т.к. такие требования к масштабируемости не были предусмотрены в ТЗ.
Что же делать? Заказчик в спешном порядке находить два самых мощных сервера, которые у него были, с твердотельными дисками, с большим объемом оперативной памяти, с хорошими процессорами... и на них выносятся два сервера БД (основной и реплика). Система задышала. Заказчик выдохнул.
Но не тут-то было. При оценке роста объемов обрабатываемых данных ошиблись примерно на порядок. И уже очень скоро, примерно через год дисковое пространство на сервере БД начало заканчиваться. А расширить его невозможно, т.к. больше дисков в сервер установить нельзя, а дисков бОльшего объеме не существует в природе. Что же делать?
В срочном порядке были освобождены два раздела на самой производительной СХД, они были напрямую подключены к серверам БД отдельными каналами и серверах появились дополнительные логические диски свободного пространства. Вроде бы все хорошо.
Но не ту-то было. Теперь исполнителю нужно было каким-то образом разделить единую базу данных на две части, чтобы отложить её часть на новое подключенное дисковое пространство. Исполнитель начал пилить боевую систему, делить данные, править прикладной код и героическими усилиями выделил часть данных и отложил их на подключенные диски. Вроде бы все должно стать хорошо.
Но не тут-то было. Производительность дискового пространства с СХД оказалась в несколько раз ниже, чем локального дискового пространства сервера, что ожидаемо. И система начала жутко тормозить. Что же делать? Более мощных серверов и Заказчика нет, более мощной СХД тоже. Исполнитель подумал и решил выделить для хранения на СХД только те данные, которые реже всего используются. И снова героическими усилиями начал пилить базу данных и прикладной код. В конечном итоге поставленная задача была решена и система вновь задышала и продышала в такой конфигурации примерно полтора года.
Система активно работала, объемы данных росли и выделенного дискового пространства вновь стало не хватать. Но на счастье Заказчика в природе появились твердотельные диски большего объема, которые были закуплены и заменены в серверах БД. Этого хватит еще на пару лет работы, а что будет дальше покажет время.
Чтобы не попадать в такие ситуации нужно очень вдумчиво писать требования к работам по прогнозированию объемов обрабатываемых данных и к требованиям по масштабируемости системы. Причем эти требования к масштабируемости должны быть не высосаны из пальца, они должны сочетаться с существующей инфраструктурой Заказчика и с возможностями Заказчика по внесению изменений в эту инфраструктуру.
Например, если мы говорим о гос секторе, то что-то серьезное в своей инфраструктуре госники могут сделать не ранее, чем через год от возникновения потребности. И это тоже необходимо учитывать.
---
Онлайн-школа руководителей IT-проектов