Казалось бы, в наш технологический век увеличение нагрузки не должно быть неожиданностью для ИТ-персонала, так в чем же дело? Оказывается, аспектов здесь много.
Почему критически важные ИТ-системы часто не справляются с нагрузкой? Мы регулярно читаем в новостях, что по этой причине отказывают банковские системы, порталы государственных услуг, биржи и даже системы цифровых пропусков для контроля режима самоизоляции во время пандемии COVID-19.
Казалось бы, в наш технологический век увеличение нагрузки не должно быть неожиданностью для ИТ-персонала, так в чем же дело? Оказывается, аспектов здесь очень много, но, поскольку это короткая статья, а не диссертация, опишу лишь несколько наиболее распространенных ошибок, совершаемых ИТ-руководителями.
1. ИТ-руководители слишком доверяют вендорам оборудования
Довольно часто покупка самого производительного сервера в модельном ряду IBM, HP или других производителей воспринимается как серебряная пуля, которая должна всерьез и надолго избавить организацию от низкого быстродействия систем, а также отказов и сбоев, связанных с производительностью. Иногда вера в это подкрепляется официальной документацией вендора, где написано, например, что оборудование обеспечивает производительность 100 килосапсов в час!
Опытный ИТ-менеджер знает, что серебряной пули не существует. Неважно, сколько процессоров у вашего сервера, если код выполняет вычисления в одном потоке. Неважно также, сколько оперативной памяти на сервере приложений, если в java-приложении она утекает, не так ли? А что касается «килосапсов», то вендор имеет в виду конкретную коробочную версию SAP, которая не похожа на вашу ничем. К сожалению такие данные нельзя использовать даже для грубой прикидки производительности.
2. ИТ-руководители слишком доверяют разработчикам софта
Ответьте, пожалуйста, на вопрос: есть ли в вашем контракте на разработку или внедрение ИТ-системы техническое задание, которое содержит требования к производительности? Например, такое: время отклика операции «Перевод денежных средств клиенту банка» не превышает 8 секунд при рабочей нагрузке 500 операций в час. Если ответ «нет», то у вас нет оснований ожидать от ИТ-системы заданного быстродействия. Если же «да», то вы входите в 5% зрелых организаций и, я надеюсь, проводите тестирование производительности в ходе приемки софта от разработчика.
К сожалению, львиная доля российских разработчиков не тестирует производительность своих продуктов и больше ориентирована на выполнение дедлайнов по разработке.
3. Не выполняется тестирование производительности ИТ-систем
Ваша новая система может хорошо справляться, когда в ней работает 10 пользователей. А когда их будет 1000 или 10 000? Чтобы ответить на этот вопрос, нужно провести нагрузочное тестирование, в ходе которого проанализировать производительность системы на разных уровнях нагрузки. Для критичных ИТ-систем делать это нужно перед внедрением любых изменений, а также при выполнении миграций и централизаций. Тестирование производительности позволяет обнаружить узкие места, ограничивающие быстродействие системы, и устранить их до того, как реальные пользователи столкнутся со сбоями в продуктивной эксплуатации. Хорошей практикой является проведение нагрузочного тестирования перед закупкой оборудования. Вендоры обычно предоставляют оборудование для этого бесплатно. рейтинг букмекеров Узбекистана
Глядя на эти типичные ошибки, легко заметить, что привести ИТ-систему к отказам при увеличении нагрузки совсем несложно. В то же время вы видите, что выход есть – ключом к стабильной работе под нагрузкой является анализ производительности. Это действительно сложная инженерная задача, которая требует специальных компетенций, наличия тестовой среды, средств мониторинга и профилирования, поэтому планировать данный процесс следует заранее.