«И это все о ней, или сколько волка ни корми» — Михаил Сусоров об эволюции производительности систем и стоимости ошибок корпоративного ИТ

11 мая 2023 3516 0

Сегодняшние условия российского ИТ-ландшафта требуют немедленных шагов к переходу с западных продуктов на отечественные — и здесь часто приходится «изобретать велосипед», сталкиваясь с проблемами, которые два-три года назад пребывали в «фоне» или не существовали вовсе. Одним из важных критериев успешности перехода становится сохранение или улучшение производительности систем, обеспечивающих критичные для компании бизнес-процессы.

Михаил Сусоров в приведённой ниже статье погружается в историю проблематики и демонстрирует, как можно использовать опыт прошлых лет в решении сегодняшних проблем — например, чтобы показать бизнесу в конкретных цифрах реальную выгоду компании от стабильной производительности систем.

Подробнее мы разберем вопросы сохранения производительности при переходе на отечественные системы в ходе вебинара — не забудьте зарегистрироваться!

Как известно, в переводе с древнеиндейского слово Windows означает — «белый человек, смотрящий сквозь прозрачное стекло на песочные часы».

В очень недалеком прошлом, в курилке одного очень известного в узких кругах подмосковного мероприятия коллега из транснационального ИТ-гиганта пожаловался на стабильное и многолетнее падение продаж высокопроизводительных систем. Тех, которые еще не штучные суперкомпьютеры, но и уже не обычные сервера. А нечто среднее, выпускающееся серийно.

И меня прямо в той же курилке посетило некоторое дежавю на эту тему. Перед глазами проплыли сначала зеленые терминалы EC-1033, потом машинный зал двухпроцессорной ЕС-1068, более разноцветные дисплеи Vax-9000, промелькнули синклеры-атари-векторы во всем их разнообразии, ДВК и наконец первые «настоящие» PC с «косыми флопами» (и далее со всеми вариациями архитектуры x86 по сей день). Я припомнил, как мы «грызли» уравнения Навье-Стокса на всем вышеперечисленном, что было тогда доступно в разных вариациях. И как каждый запуск расчета на процессоре 80386 аж с целыми двумя мегабайтами памяти занимал часов этак 12-15, если не очень настаивать на точности. Не менее хорошо запомнилось, что ЭВМ единой серии считали эти задачи примерно раз в сто быстрее чем тогдашние РС или раз в сто точнее за то же время. И это несмотря на то, что 80386 процессор со своими 20 Мегагерцами занимался моей персональной задачей не отвлекаясь, а на ЕС обычно висело человек по 200 в круглосуточном режиме.

С тех пор утекло не так уж и много времени и вот настали времена, когда обычные «бытовые» РС догнали по производительности в «бытовых» задачах типа ERP, CRM, MES и тому подобных прикладных задач те самые суперкомпьютеры конца прошлого и начала этого века. Да и сами суперкомпьютеры стали собирать из «бытовых» процессоров и памяти, продающихся на каждом углу. И уже ноутбук с шестиядерным процессором на 4 гигагерца и 128 гигабайт оперативной памяти никого не удивляет. Конечно, остались задачи, в которых вычислительная мощь никогда не бывает лишней (научные расчеты, те же уравнения Навье-Стокса или моделирования ядерных реакций и биржевых рисков). Но вот на бытовом уровне состояние «больше не надо» достигнуто по весьма большому перечню задач. На самом обычном ноутбуке можно монтировать видео высокой четкости, проектировать и рассчитывать параметры довольно сложных конструкций, рисовать картинки в графических редакторах и много чего другого. А на ноутбуке помощнее можно рисовать фильмы, которым позавидует SGI десятилетней давности и 3D модели с вполне промышленной детализацией. И все это все это не будет занимать как раньше многие часы, а будет похоже скорее на online, что наглядно демонстрирует киноиндустрия.

Для оценки масштаба «бедствия» приведу конкретный пример. Лет примерно 10 назад на просторах нашей родины было создано решение для биллинга весьма распространенной на планете услуги для физических и юридических лиц. Полностью наше местное. Смысл задачи прост — фиксируем показания «измерительной линейки» в начале периода и в конце, далее применяем десятка три-четыре различных тарифов и коэффициентов и на выходе имеем сумму к оплате.

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

Да еще и с пристрастием. Результаты довольно продолжительных, почти научных изысканий, удивили даже меня. Время расчета на 10 миллионов абонентов составило примерно 30 минут на двух серверах на сегодняшний день очень похожих на среднего калибра ноутбук. То есть, не сложный расчет говорит о том, что для расчета суммы за эту коммунальную услугу всем жителям нашей планеты (в количестве 8 миллиардов) в течении 30 минут будет достаточно 1500-2000 не самых мощных на сегодня ноутбуков. Или 150-200 серверов среднего уровня. Которые займут один весьма небольшого размера ЦОД.

Решение же от именитого заморского производителя укладывалось с расчетом в два часа полностью загружая двухметровую серверную стойку с количеством процессорных ядер, измеряемых десятками и количеством памяти измеряемом в терабайтах. Стоимость железа отличалась на два порядка. То есть в сто раз.

Можно еще для примера припомнить задачи с расчетом зарплаты на почти полмиллиона сотрудников, сборы консолидированной отчетности со 100 ДЗО и тому подобные задачи, для решения которых в нормальное, с точки зрения бизнеса, время, применялось весьма «ширпотребное» по нынешним временам «железо». То есть тенденция как минимум понятна.

Казалось бы — на текущий момент соотношение цены и производительности имеющейся в широкой продаже компьютерной техники должны удовлетворить 95% потребностей широких слоев потребителей ИТ. И с большим запасом в большей части задач. Но вот на практике вопросы по производительности тех или иных систем возникают с пугающей периодичностью.

Теоретически — это лошадь. А практически — не едет

Для понимания «обратной стороны медали» обратимся к весьма интересному исследованию на эту тему. В котором подробно рассматривается вопрос о зависимости времени отклика системы от параметров «железа». Более подробно можно ознакомиться по ссылке. А показательную табличку я приведу тут.

Общий вывод исследования говорит о том, что количество мегагерц, транзисторов на квадратный метр на время отклика системы влияют скорее в сторону его увеличения, хотя по идее должно быть наоборот.

Так же в исследовании справедливо было отмечено, что в нормальном состоянии время отклика системы должно быть сравнимо со скоростью реакции обычного человека которое в среднем, составляет 100-200 миллисекунд. Все что откликается медленнее — вызывает дискомфорт пользователя. И именно поэтому время отклика современных систем находятся как раз в районе среднестатистического физиологического минимума среднестатистического пользователя — меньшее время отклика может оценить только очень узкий круг людей, например кибер-спортсменов.

Дальнейшее сокращение времени отклика систем, экономической целесообразности, соответственно, не имеет. Этот «предел желаний» в 200 миллисекунд и рекомендуется взять в качестве целевого показателя при анализе производительности систем.

Aliena vitia in oculis habemus, a tergo nostra sunt

Собранная за много лет статистика говорит о том, что можно выделить три основных причины «торможения» систем.

Причина первая, проявляющаяся в 2% случаев и условно называемая «проблемы с железом». Сюда входят, например, «оригинальные» настройки BIOS и гипервизоров.

Причина вторая, отвечающая за 3% проблем и условно называемая «архитектурные проблемы». К ним условно относятся архитектуры и настройки прикладных серверов и серверов баз данных.

Ну и в 95% случаев причина заключается в «грамотно» написанном коде системы. На этом моменте можно остановиться подробнее. Выросшая в миллионы раз производительность «железа» в значительном количестве случаев позволила действовать писателям кода по упрощенной схеме создания программ — сначала как можно быстрее получаем функционал и запускаем его в работу (естественно, под хоровое выступление бизнес-пользователей по темам «мы теряем деньги», «этот функционал нужен был год назад», «отчет нужен вот прямо завтра», «если в понедельник не будет — все клиенты разбегутся»). Главное, чтобы этот функционал хоть как-то «шевелился» и на момент сдачи в эксплуатацию быстродействием сильно не раздражал. А уже «потом» планируем занимаемся техническим совершенствованием полученного решения. «Потом» подумаем над масштабированием, производительностью при количестве пользователей больше двух и на другие очень правильные темы. Только вот это «потом» имеет обыкновение растягиваться на годы, если последствия такого «потома» не проявляются в течении короткого периода времени. И проявляются они обычно в двух вариантах.

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

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

В следующем году мы посадим 100 га овса — нехай зараза подавится

Реакции ИТ-шников на падение производительности, в основном, стандартны. На практике обычно встречается три разновидности.

Разновидность № 1. Залить железом

Способ простой, понятный и очевидный даже финдиректорам и бухгалтерам — раз система «тормозит» — значит нужен сервер побольше, потолще и, естественно, подороже. И ИТ-директор пускается во все тяжкие закупая или арендуя гору «железа» с запасом «производительности» ну хотя бы года на три. Но вот часто получается результат почти обратный ожидаемому — количество процессоров памяти и прочего увеличилось вдвое, а время отклика — сократилось на 10-15%.

Суперсовременное хранилище купили — а отчеты быстрее не формируются. Бывает, что мощность нужна раз в 10-20 больше, чтобы система вообще хоть как-то позволяла работать и не остановить бизнес. Обычно это происходит в вышеописанном варианте № 1 когда времени на выяснение причин падения производительности нет, а работать хоть как-то надо. Или часто наблюдается в окологосударственных компаниях, где «железо» закупали по принципу «на все деньги и сейчас, что бы бюджеты не порезали». В результате имеем классический вариант «стрельбы из пушки по воробьям», то есть замороженные в оборудовании, потраченные амортизацию и эксплуатацию деньги, которые можно было бы использовать в более приличных целях. В других областях деятельности перевозка мешка картошки карьерным самосвалом если и встречается, то намного реже чем в ИТ.

Разновидность № 2. Заткнуть дырки

Если Разновидность № 1 по разным причинам либо не реализуема, либо ее реализация ситуацию не улучшила — переходим к Разновидности № 2, то есть пытаемся привести систему в рабочее состояние в аварийном режиме. Меняются конфигурации и архитектуры, правится код, привлекаются сторонние специалисты и работа продолжается до тех пор, пока крики пользователей не перестают быть слышны в кабинете ИТ-директора. В данной разновидности все познается в сравнении — если расчет себестоимости составлял, к примеру, 48 часов, а в результате выполнения работ было уменьшено до 6 часов — то это же явный успех. Если не знать, что это время можно было сократить до 15 минут... Хотя пользователи оказались полностью удовлетворены результатом в 12 часов...

Разновидность № 3. Борьба с причинами

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

«Его пример другим наука» или из последнего непонятого

• Случай первый. Небольшая окологосударственная корпорация в течении полугода наблюдает, как примерно 3000 ее сотрудников смотрят на песочные часы примерно 10% своего рабочего времени, усугубляя эти 10% еще и перекурами, так как время формирования оперативных документов в системе стало сравнимым. Не считая частых аварийных «вылетов» клиентской части. Система, само собой, работает на «железе» уровня ЦОД среднего европейского государства. Причина — в «высочайшей» квалификации администратора, который не в состоянии отрегулировать один параметр в настройках системы.
• Случай второй. Весьма известная торговая марка на уровне топ-менеджмента без тени сомнения обсуждает вопрос разделения баз данных по юрлицам, модернизации ЦОД, аренду серверов и тому подобные масштабные изменения инфраструктуры, так как общая база «тормозит». Первичный анализ нагрузок показал, что средний ноутбук перекроет текущие потребности трехсот пользователей с троекратным запасом по производительности.
• Случай третий. Не менее известной торговой компании года три назад были выданы рекомендации по управлению производительностью недавно принятой в эксплуатацию системы. Думать не надо — надо делать. Раз-два-три. Причем месяца за три эти рекомендации можно было выполнить, не торопясь и с перекурами. Однако срок выполнения рекомендаций, скажем так, несколько растянулся. До того момента, как очередной релиз выпущенный в продуктив сделал время отклика системы превышающим длительность среднего перекура 2500 пользователей. Аварийные срочные мероприятия привели к экстренной аренде «железа», которому позавидуют многие банки из первой десятки, но время отклика системы по-прежнему далеко от общепринятых. А общее направление развития компании в этом направлении говорит о том, что в недалеком будущем время реакции системы позволит пользователям после перекура еще и чая попить. Возможно даже с тортиком...

Как гуляли — веселились

Оценим примерную стоимость всего этого банкета. В расчет примем:

• Среднюю зарплату пользователя. Возьмем для примера 100 000 рублей в месяц
• Среднее время наблюдения за песочными часами средним пользователем. Возьмем скромную цифру в 10% от рабочего времени, то есть 48 минут в день от стандартного рабочего времени
• Среднее количество пользователей в размере 1000 человек

Сделав несложные вычисления, можно понять, что прямые потери составят в районе 10 млн рублей ежемесячно. Если сюда добавить косвенные расходы вроде излишне употребленного отопления, амортизации, электричества и тортиков — то цифру можно легко удвоить. Инструментов же для сбора времени показа любой системой «песочных часов» и измерений времени отклика на сегодня достаточное количество, поэтому любой финансовый директор может запросто запросить у ИТ нужные показатели и посчитать во сколько денег обходятся проблемы с производительностью на конкретно его предприятии.

Присоедяняйтесь 25 мая в 19:00 к нашему вебинару «ERP-системы 1С: переходим без потерь» с Михаилом Сусоровым.