Нагрузочное тестирование

Меня зовут Антон Дорошкевич, франчайзинговая сеть ИнфоСофт, город Новосибирск.

Я давно занимаюсь оптимизацией производительности 1С и сегодня хочу поделиться своей болью – тем, что на проектах очень часто пренебрегают нагрузочным тестированием. На него не обращают внимание, его игнорируют. А тем временем нагрузочное тестирование необходимо – это неотъемлемая часть любого крупного проекта по внедрению.

Поскольку доклад звучит на конференции «Анализ & Управление в ИТ-проектах», я не буду рассказывать, как технически проводить нагрузочное тестирование на практике. Будем затрагивать другие вопросы:

• зачем проводить нагрузочное тестирование;

• как к нему подготовиться;

• кому это нужно;

• когда это нужно и так далее.

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

Вроде бы полностью функциональная система, но не шевелится. Либо шевелится, но только если что-то перезапустить – тогда она начнет помаленьку что-то выполнять, а потом опять замирает.

Отдав несколько десятков, а иногда даже сотен миллионов за внедрение, заказчик остается с этой болью.

И самое обидное – вроде везде эксперты работали, навряд ли на проекте за сотни миллионов будут кодить стажеры. Но все равно накодили такого, что 1С не шевелится.

Причем, по закону Мерфи, все это произойдет, когда подрядчик выйдет с проекта. Пока исполнитель на проекте – все нормально. Пока за 1С кто-то смотрит, она работает. Как только подрядчик вышел с проекта, все сразу становится колом.

Сразу написать код на 100% идеально с точки зрения производительности не получится – быстро выдать на прод функциональность важнее, чем качественно написать код, который эту функциональность реализует. На момент сдачи проекта никого не интересует, чтобы код был правильным с точки зрения производительности, всем важно, чтобы циферки были правильными.

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

Одним из решений этой проблемы как раз и является нагрузочное тестирование.

Какие цели нагрузочного тестирования?

Важно: проводить нагрузочное тестирование без цели, просто ради нагрузочного тестирования – это деньги на ветер. Вы ничего не узнаете, ничего не получите, никому не поможете, непонятно, что сделаете.

Конечно, вы сможете сгенерить 300 страниц красивого отчета с графиками. Думаю что многие знают, что чем толще отчет, тем меньше шансов, что его прочитают. Зато он дороже стоит.

Отчет на двух страницах прочитают точно все, но денег много не дадут. А когда отчет на 300 страницах, его просто подпишут и дадут много денег. Что там написано – неизвестно, но красиво. Все переплетено, заламинировано – вообще красота.

Давайте определимся, для каких же целей можно проводить нагрузочное тестирование?

Одна из самых дешевых целей нагрузочного тестирования – это просто посмотреть, что будет. Эта цель – самая дешевая в реализации, но она годится только для новой системы. Если раньше у вас было что-то другое – УПП, Excel или тетрадка, а теперь стало ERP, тогда посмотреть, что будет – это нормальная цель.

Потому что когда мы собираемся внедрить ERP на 5000 пользователей, вам никто не предскажет, как поведет себя система – хватит ей производительности или не хватит. А если кто-то скажет: «Этого сервера хватит», он лукавит. Все случаи уникальны, и какой-то серебряной пули не существует.

Такое нагрузочное тестирование проводится, по идее, один раз. Но есть два важных правила:

• Самое главное – любое нагрузочное тестирование нужно проводить после полного внедрения функциональности. Если вы думаете, что достаточно провести нагрузочное тестирование на типовой ERP, а потом внедрить кучу доработок, и быть уверенным, что все будет работать так же – вы ошибаетесь. Я гарантирую, что вся ваша функциональность однозначно не будет работать так же быстро, как показало нагрузочное тестирование для типовой конфигурации. Сначала функциональность сдается заказчику, а затем вся эта функциональность нагружается.

• Еще одно правило: нельзя заниматься аппроксимированием. Нельзя нагрузить систему на 50 человек, умножить все показатели на 10 и сказать: «Когда в системе будет 500 пользователей, будет вот так». Нет, так не будет, причем как будет, никто не скажет. Может быть, будет лучше, может быть, хуже, а может быть – совсем плохо (например, из-за блокировок, но я обещал техникой не грузить). Показатели производительности не имеют линейной зависимости от количества пользователей. Нельзя заниматься никакой аппроксимацией, все нагрузочное тестирование должно быть максимально честным. Чем честнее проведете, тем увереннее будете в результате.

Следующая цель немного дороже – это сохранить текущий APDEX.

Эта цель годится только тогда, когда вы нагружаете систему, которая у вас уже есть.

Например, вы уже работаете в ERP, но сейчас в ней работает 50 человек. А теперь сверху поступил приказ загнать туда еще 450 менеджеров по продажам. И нужно узнать – как она будет работать, когда в ней будет 500 человек?

Можно использовать первый случай и просто показать бизнесу, как теперь будет работать – что теперь мы будем ждать по три минуты открытия любой формы.

Или есть другая цель, которая чуть подороже – мы сначала снимаем APDEX текущей системы. Например, узнаем, что открытие РТУ – две секунды. А потом мы оптимизируем код, чтобы это значение сохранить при росте нагрузки.

Эта цель уже немного выходит за рамки нагрузочного тестирования, потому что само по себе нагрузочное тестирование произойдет точно так же – система будет нагружена согласно вашим целевым цифрам для 500 пользователей. И будут получены какие-то результаты.

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

Вполне возможно, что в лоб оптимизировать не получится. Потому что недостаточно просто посадить специалиста с сертификатом эксперта по технологическим вопросам, чтобы он что-то сделал, и все заработало. Он, конечно, попробует вам помочь, но все может не заработать так, как вы хотите. Тогда придется переделывать процессы – вы к этому должны быть готовы. Это гораздо более дорогая процедура.

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

На эту тему есть расхожая шутка еще с 7.7:

Спросите у стажера, сколько времени займет написать форму ТОРГ-12. Стажер ответит: «30 минут».
Спросите у эксперта, сколько времени займет написать форму ТОРГ-12. Эксперт ответит: «Года два – я же не знаю, чего вы хотите».

Тут то же самое – заниматься производительностью и пытаться сохранить ее показатели при повышении нагрузки можно бесконечно, поэтому когда-то придется просто сказать “стоп”.

Есть еще более дорогой вариант нагрузочного тестирования – это не только сохранить ваш APDEX, но и достичь нужного APDEX.

Например, вас не устраивает, как сейчас работает система – какой-то документ проводится 15 секунд. Т.е. мало того, что вы собираетесь расти – нагрузочное тестирование без роста никому не нужно, вы еще и хотите одновременно ускорить вашу систему. Причем ускорить уже на целевых цифрах – не на 50 пользователей, как сейчас, а на будущее, когда их будет 500.

Поэтому вы выставляете свои целевые значения APDEX для каждой операции: хотим 5 секунд вот здесь, 3 секунды здесь, 3 минуты здесь, и, естественно, закрытие месяца за полтора часа ))).

Обратите внимание, это многоэтапный проект:

• сначала вы нагружаете систему и смотрите, что будет;

• потом ваша цель – сохранить существующий APDEX;

• и наконец – достичь нужный APDEX.

Каждый последующий этап все дороже, дороже, дороже и дороже.

Для постоянного отличного самочувствия вашей системы есть отдельный тип нагрузочного тестирования – я его назвал «стабильная красота прода».

С точки зрения производительности продуктивный контур для нового кода 1С не должен сильно отличаться от контура, на котором работал старый код – они должны быть похожи друг на друга как эти близняшки. Новый прод может стать чуть-чуть лучше старого, но хуже точно не должен.

И это – самый дорогой вариант нагрузочного тестирования, потому что он тратит деньги вечно, практически каждый день.

Нельзя взять и просто так обновить прод:

• Сначала нужно обновить предпрод, который предназначен для нагрузочного тестирования.

• Прогнать на препроде нагрузку и получить результаты – сравнить их APDEX с тем, который нас сейчас устраивает.

• Если эти результаты вдруг куда-то поползли в ненужную сторону, опять запускается процесс оптимизации кода.

• И так мы прогоняем нагрузочное тестирование до тех пор, пока не достигнем приемлемых значений APDEX.

Не нужно путать нагрузочное тестирование с функциональными тестами, которые делает Vanessa – это другое. Функциональное тестирование – это один контур, а нагрузочное тестирование – вообще другой контур.

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

Дальше у меня будет еще несколько оговорок про этот идеальный мир – вы можете сильно не обращать на них внимание. Если это пока не про вас – окей, тогда стоит хотя бы начать разово делать нагрузочные тестирования.

Когда нагрузочное тестирование точно нужно?

Понятно, что если система рассчитана на пять пользователей, ей нагрузочное тестирование, скорее всего, не нужно – оно там никак не обосновано финансово. Для маленькой системы это громадные затраты по сравнению с выхлопом, который вы получите.

И тут возникает вопрос: когда оно вообще нужно, это нагрузочное тестирование?

Есть несколько триггеров, когда нагрузочное тестирование точно нужно. Понятно, что эти триггеры не залиты бетоном – вы можете их опускать, поднимать, двигать влево-вправо, но в целом нагрузочное тестирование нужно в следующих случаях:

• Когда у вас больше 100 пользователей. Речь не об элементах в справочнике пользователей, а именно об одновременных сеансах 1С.
  Для кого-то может быть критично 50 – все по-разному бывает. Но когда одновременных пользователей 100+ – тогда нагрузочное тестирование точно нужно. Без него вообще никак нельзя – это касается и проектов, где вы подрядчик, и внутренней автоматизации, если вы штатный программист. Если у вас на проекте пользователей больше 100, его обязательно нужно тестировать, хоть как-нибудь начните.
  Важно: вы не найдете в 1С зеленую кнопку, чтобы все быстро протестировать. Быстро протестировать не получится. Нагрузочное тестирование – это всегда долго, больно и дорого. Все синтетические тесты, которые что-то запускают, покажут на вашем ноутбуке гораздо больше попугаев, чем на сервере за несколько миллионов. Хотя ноутбук у вас 500 пользователей на ERP вряд ли потянет, а сервер обычно тянет.
  Поэтому готовых простых нагрузочных тестов не существует – там всегда очень сложные сценарии, и их сложно проводить. Придется применить много ума, денег и времени.

• Второй момент, когда нагрузочное тестирование нужно – это когда вы используете ERP, CRM, УХ, ДО и другие флагманы (флагманские конфигурации). Потому что навряд ли есть организации, где полторы тысячи бухгалтеров сидят в одной базе «Бухгалтерии предприятия». Может быть, есть организации, где действительно работает полторы тысячи бухгалтеров, но они, скорее всего, как-то разбиты по базам. Если не разбиты – на такой БП тоже нужно проводить нагрузочное тестирование.
  Почему флагманы? Потому что они очень сложные и многоблочные. Вы там один винтик повернули – с другой стороны все рухнуло. Если вы CRM поверх ERP поставите – попрощаетесь со скоростью навсегда. Все переписать придется.
  Тем более, что флагманские продукты на пять человек обычно не ставят, они нужны большим компаниям. Плюс они сами большие и очень сложные. Даже какой-нибудь мегаопытный специалист навряд ли вам скажет, где здесь станет плохо. Потому что он всех тонкостей доподлинно не знает, он не может предсказать – будет там плохо или нет. И когда там станет плохо, он тоже не знает. Хотя когда-то точно станет плохо.

• Следующий триггер – это переход на другую СУБД. При переходе с MS SQL на PostgreSQL нагрузочное тестирование обязательно. Без этого переходить нельзя. Не потому, что PostgreSQL хуже MS SQL, а потому, что код 1С под PostgreSQL надо писать лучше. MS SQL плохой код прощает, PostgreSQL не прощает.

• Следующий момент – это изменение инфраструктуры. Это к слову про тот самый тест, который все хотят провести одной зеленой кнопкой.
  Спросите админов: «Новый сервер лучше старого?» – они ответят: «Конечно!» – «А почему?» – «Ну потому что он новый». Вообще не факт.
  Не факт, что он правильно настроен, что там правильные драйвера, да и вообще – что он действительно лучше старого для вашей нагрузки.
  Поэтому если вы собираетесь менять инфраструктуру, нагрузочное тестирование обязательно.
  Особенно если вы собираетесь переехать в виртуальность.
  Или если вы собираетесь переехать с одной виртуальности в другую – был какой-нибудь VMWare, стал Proxmox.
  Или если вы собрались переехать между ЦОДами – они вообще ни капельки не одинаковые, они все очень разные, нужно производить нагрузочное тестирование. Иначе будут неожиданные моменты в самое неподходящее время.

• В идеальном мире нагрузочное тестирование нужно при обновлении платформы. Самый популярный вопрос на форумах 1С-ников: «Какую платформу ставить?» Все думают, что кто-то точно знает. Как это можно с уверенностью знать? Даже если кто-то успешно прогнал у себя какие-то тесты – это не значит, что у вас все тоже будет хорошо.
  Обновление платформы – очень важный шаг. Особенно если вы меняете третью циферку – например, переходите с 8.3.22 на 8.3.23.
  Менять четвертую циферку – не опасно, потому что она не приносит новых возможностей, она только исправляет ошибки предыдущих версий. А третья циферка приносит новую функциональность. И чем она в вашей системе обернется, вообще никто не знает.
  Это не значит, что фирма «1С» нам поставляет какую-то неправильную платформу – у них при выпуске нового релиза десятки тысяч тестов проходят. Но наши с вами инфраструктуры уникальны настолько, что их проблемы эти тесты не покрывают.
  Хотя количество тестов у разработчиков платформы постоянно растет. И платформа с каждой версией становится все качественнее – она вообще у нас самая лучшая в мире!.

• Еще один элемент идеального мира – это проводить нагрузочное тестирование вообще при каждом обновлении кода конфигурации 1С. Прежде чем залить код, даем нагрузку и проверяем. Серьезные проды по-другому не работают. Иначе будет больно.

Откуда взять сценарий?

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

Вот я говорю: «Протестируйте ERP» – а что это значит? Запустить? Запустилось. Закрыть? Закрылось. А пользователи-то что делают? Это один из самых больных вопросов.

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

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

В качестве основы для написания нагрузочных тестов вы можете использовать комплект сценариев для Тест-центра, который предоставляет фирма «1С». Его можно скачать на странице загрузки дистрибутивов для ERP. Правда, там скорее не нагрузочные, а функциональные сценарии. И это просто мнение фирмы «1С» о том, как надо работать в ERP. А как вы в реальности работаете – это еще нужно будет узнать.

Для ERP-шников, когда они пытаются вывести проект на нагрузочное тестирование, вопрос «Откуда взять сценарий для нагрузочного тестирования?» – самый больной, и очень часто – нерешаемый. Заказчик просто говорит: «Все, не мучайте меня, придумайте что-нибудь сами» и т.д.

В такой ситуации в целом выход есть – мы можем проанализировать APDEX или показатели CALL и SDBL из технологического журнала текущей системы.

APDEX – это показатель интегральной производительности 1С с текущей системы. Его удобно анализировать, если у нас уже есть система – это как отражение текущей системы.

Если мы запускаем новую систему, сценарий тестирования придется придумать. А если у нас система уже есть, но мы планируем резко вырасти в нагрузке, мы можем не мучить заказчиков, а просто проанализировать APDEX. Только для этого его нужно настроить на нужных элементах, если он вдруг у вас там не настроен. В типовой конфигурации он настроен практически на всем. Формируете отчет по ключевым операциям и вперед – вот ваш сценарий.

Тут остается только вопрос: что считать ключевыми, а что – не ключевыми операциями? На это есть простой ответ: если операцию за месяц выполнили больше 100 раз, она, наверное, ключевая. Сгруппируйте запросом операции за месяц из регистра APDEX по видам и отберите те, которые появлялись в этом регистре больше 100 раз – это и будут ваши ключевые операции.

Если в системе APDEX не настроен либо выключен, практически ту же самую информацию можно достать из технологического журнала:

• показатели CALL – для современных конфигураций на управляемых формах;

• показатели SDBL – для конфигураций на неуправляемых формах. На той же УТ10 или УПП еще куча людей работает. Берем SDBL и получаем то же самое отражение системы – это и есть наш сценарий.

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

Элементы хорошего сценария

Но если мы отберем только те операции, которые у вас совершались более 100 раз за месяц, мы многое упустим: процедуру закрытия месяца, расчет себестоимости, или не учтем сезонность бизнеса, когда в последнюю неделю мая оборотов столько, сколько потом за весь год нет.

Поэтому ваш план должен содержать все эти нюансы.

• Если есть сезонность – берем только самый высокий сезон. Низкие сезоны нам брать не интересно, там мы получим искаженную информацию.

• Если есть тяжелые регламентные операции, нужно узнавать – когда. И совмещать их с работой других пользователей. Хороший план обязательно должен совмещать закрытие месяца и расчет себестоимости с работой пользователя.
  До сих пор на достаточно больших инсталляциях нам ИТ-шники говорят: «Ой, да когда мы месяц закрываем, базу блокируем вообще». Как вам бизнес такое позволяет? Красавцы, конечно, но так вообще-то не делается.
  Когда вы запустите нагрузочное тестирование, параллельно с работой в текущем месяце обязательно должно идти закрытие предыдущего месяца.

• Еще один элемент хорошего плана – не забудьте про RLS и роли. Не надо тестировать под полными правами. Это беда всех разрабов: «Я протестировал, все работает». Добавил какой-то новый регистр, а права не добавил – как ты тестировал?
  Многие знают, что RLS – убийца скорости. Поэтому тестируйте с RLS в обязательном порядке. Если в базе планируется RLS, либо уже настроено, вы должны им пользоваться.

• Следующий элемент хорошего плана – база должна быть с данными. И желательно данные заполнены еще и на будущее – на тот момент, когда у вас будет 500 пользователей. Вы же планируете вырасти – что с данными будет? Есть же все равно какой-то прогноз или статистика данных за прошлые года? Если вы хотите протестировать базу в полтора терабайта, а нагрузку даете на базу в 50 гигов, вы получите что попало. Аппроксимировать в обратную сторону тоже нельзя. База должна быть примерно такая же, но лучше еще и с запасом на два-три года в данных.
  Понятно, что нагрузочное тестирование вас подстрахует примерно на 80%, потому что любую систему всегда можно положить поиском в динамическом списке. 100% ответ вам нагрузочное тестирование никогда не даст – пользователь всегда сможет сделать так, что все ляжет.

• Следующий момент – количество операций должно быть совместимо с реальностью. Если вы делаете в день 100 РТУ, в нагрузке не надо делать 10 или 10 тысяч РТУ. Нужно учитывать, сколько человек их делает? Например, у вас сидит 20 операторов, каждый делает за рабочий день по 5 РТУ – это значит, у вас должно быть в нагрузке 20 потоков, каждый из которых делает по 5 РТУ. И не нужно делать так, чтобы у вас все 100 РТУ как в пулемете за 15 секунд создались. В нагрузочном тестировании все должно происходить точно так же, как вы работаете в реальности. Сколько РТУ в час вбивает один пользователь? Сколько таких пользователей? Именно так и нужно делать нагрузку, иначе опять получаете искаженные данные, как будто вместо пользователей работают роботы.

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

Технические подходы

Ну и немного технических моментов.

Как делать нагрузочное тестирование – это большой спор. Каждый делает по-своему – кто что придумал, тот так и делает. Но вообще-то есть решение от вендора – нашей любимой фирмы «1С». Это конфигурация «Тест-центр» – единственный рекомендуемый фирмой «1С» вариант организации нагрузочного тестирования

На слайде – страшная картинка со страницы описания, там вы можете ознакомиться с предлагаемой методикой «Тест-Центра» подробнее.

Но если пойти этим единственным правильным путем, вам придется поднять копию всей инфраструктуры заказчика – причем инфраструктуру не только серверную, но и клиентскую.

Тест-центр от 1С на каждого пользователя реально запускает тонкого клиента 1С. Если у вас планируется, что будет работать тысяча клиентов, вам нужно запустить тысячу 1С – поверьте, это вообще не тривиальная задача.

Более того, из-за этой особенности 70% всей нагрузки серверов 1С будет тратиться на запуск пользователя в систему – не на его работу потом, а на запуск.

Но самое главное, что это и в жизни так. У вас и потом с утра, когда все в 9 пришли, кофе попили, в полдесятого на сервере будет пик нагрузки, а потом все опять выровняется и пойдет помаленьку.

Единственное, что пользователей, как и документы РТУ, не нужно запускать в систему сразу всей тысячей. Не так у вас пользователи работают – каждый в какой-то свой момент запускает свои 1С. Тоже размажьте этот запуск 1С – пусть один уже проводит РТУ, а второй только пока запускается. Там еще ночная смена должна закрыть 1С – это все тоже по идее нужно соблюдать.

Есть другой популярный подход, позволяющий немного схитрить. В этом случае:

• На каждую роль запускается отдельный тонкий клиент 1С (про толстый уже не будем говорить). Например, есть у вас роль «Бухгалтер» – и мы запускаем под нее тонкий клиент.

• Но поскольку у вас 20 таких бухгалтеров, каждый из которых делает по пять РТУ, по шесть ПТУ, по шестнадцать счетов, по восемнадцать выписок из банка и так далее – под все эти операции из тонкого клиента запускаются фоновые задания. Фоновые задания не потребляют лицензии 1С, вам не нужна инфраструктура на пятьсот или тысячу пользователей. Даже если нужно протестировать работу тысячи пользователей, ролей все равно двадцать, максимум тридцать – вы запустите всего тридцать тонких клиентов. А каждый тонкий клиент запустит нужное количество фоновых заданий под каждого реального пользователя. Каждый бухгалтер что-то свое делает – все свои документы шарашат.
  Такое нагрузочное тестирование запустить гораздо проще, чем настоящий Тест-центр. И инфраструктурно проще, и с кодом, и с лицензиями.
  Если у вас сейчас система на сто пользователей, а вам сказали, что через три года их будет тысяча – вам придется прямо сейчас купить тысячу лицензий, просто ради того, чтобы пройти нагрузочное тестирование. Эта тысяча никому не нужных лицензий будет лежать на балансе три года. Зачем такие бессмысленные затраты, если можно схитрить?

• Следующий момент – это рандомный старт. Вы можете заложить, что не все пользователи стартуют в одно и то же время.

• И ещё момент – это не только рандомный старт, но и рандомное завершение. Пользователи же у вас не по звонку в шесть вечера закрывают 1С – они тоже выходят по очереди.

Так мы максимально приблизим нагрузочное тестирование к реальной жизни и обеспечим своему заказчику радость работы с 1С – она станет гораздо энергичнее, чем та умирающая девушка с первого слайда. Без проверки системы под нагрузкой функциональность будет крутой, но 1С-ка не факт что будет летать.

Поэтому призываю всех – и управленцев, и аналитиков: всегда включайте в план проекта нагрузочное тестирование, чтобы мы на выходе получали и счастливых клиентов, и быструю, счастливую 1С-ку.

Дорошкевич Антон, с заботой о вас и вашем проекте.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции "Анализ & Управление в ИТ-проектах".