"Крест ИТ", или как жить, если у вас в ИТ ландшафте выросло Кудрово/Мурино/Девяткино

Публикация № 1399393 09.03.21

Администрирование БД - HighLoad оптимизация

Добавлять новую функциональность в ИТ-ландшафт, базирующийся на тяжелых «монолитах», с каждым годом становится все сложнее. О способах преодоления проблем больших и сложных приложений на INFOSTART MEETUP Saint Petersburg.Online рассказал архитектор компании BIA Technologies Марат Шайхутдинов.

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

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

 

Концепция «Крест ИТ»

Хорошая модель, которая описывает концепцию этой идеи, называется «Крест ИТ». Она базируется на двух основных фактах:

  • Бюджет, выделяемый на ИТ, либо не растет, либо растет очень медленно.
  • Затраты на уже реализованные решения растут всегда, и растут достаточно быстро.

 

 

Из этой простой установки рождается печальный факт – рано или поздно любой бюджет, выделяемый на ИТ, будет «съеден» затратами на решения, которые были реализованы ранее.

Эта концепция хорошо описывается простым графиком. Посмотрите на две области: слева область с довольным человечком, справа – с грустным.

  • Область со смайликом описывает ресурс, который остается на реализацию новых интересных решений, полезных для бизнеса.
  • Правее человечек не такой веселый, показывает, как затраты на поддержку «съедают» весь выделенный на ИТ бюджет и продолжают расти, получая свое в виде постоянных аварий, инцидентов и тому подобное.

Что мы можем сделать как разработчики, чтобы оставаться в левой части как можно дольше? В контексте этой модели есть два глобальных решения:

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

Что влияет на угол наклона графика? Очевидно, что факторов будет много, и в разных компаниях эти факторы, скорее всего, будут разными. И для них при всей несхожести будет соблюдаться принцип Парето. Это значит, что два-четыре основных фактора будут генерировать максимальный, либо большую долю объема затрат. В нашем конкретном случае найти если не факторы, то причины и место обитания этих факторов, было достаточно просто.

 

Тяжелые системы как основа ИТ-ландшафта

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

 

 

Из анализа объема операций и долей задач, которые реализуются в наших основных системах, без всякой калькуляции можно сделать вывод, что почти все затраты приходятся на наш ТОП-3 систем. На первую – с большим отрывом.

Отсюда возникает предположение: если мы каким-то образом сможем сделать эти системы меньше, то кардинально уменьшим затраты на поддержку и освободим ресурсы для разработки новых систем и решений, полезных для бизнеса.

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

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

 

Как появляются монструозные системы

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

  • Есть как минимум несколько классов задач, которые в таких системах решаются лучше, чем в менее масштабных.
  • Монолитные системы удобнее разрабатывать: пользователю проще сформулировать свою задачу и понять свое пожелание относительно уже существующих объектов, возможностей и интерфейса. То же касается разработчиков с аналитиками.
  • Задача реализовать что-то новое связана с повышенными сложностями. А тут, когда вы разрабатываете в уже устоявшемся монолите, вся команда разработки освобождается от мук творчества. В монолите всегда есть один – максимум два – правильно работающих способа в отличие от разработки с нуля, где всегда куча вариантов, которые подходят, и сложно выбрать единственно правильный. А когда цель ясна, средства понятны – команде разработки комфортнее работать.

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

 

Ключевые проблемы больших систем

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

 

 

Я разделил факторы, оказывающие негативное влияние на систему, на три большие группы.

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

 

Первая группа факторов: растущие показатели

Давайте перейдем к первой группе факторов. Эта группа факторов – самая сложная и самая простая.

 

 

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

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

Давайте пробежимся по способам решения для каждого из этих факторов.

  • Первый фактор, о котором думаешь, когда говоришь о большой системе – это объем данных. Понятно, что с этими данными можно делать – есть механизмы, которые позволяют базу обрезать, получать уменьшенную копию этой базы, новую систему, в которой меньше данных. Но надо понимать, что такой подход и постоянная обрезка имеют пределы своей производительности. Потому что при активной доработке системы скорость наращивания объема данных растет, и вам для сохранения понятного объема придется обрезать базу раз за разом. То есть пределы работы с объемом данных все равно есть, и в какой-то момент вам придется принять это и научиться работать с большими данными – решать все эти вопросы с обеспечением производительности, отказоустойчивости и восстановлением после сбоев.
  • Другое направление и фактор, который нельзя забывать – количество пользователей и те операции, которые они выполняют в системе. Начиная с какого-то момента некоторые пользователи могут создавать опасность для производительности и работоспособности системы, и надо понимать, каким образом работать с этими группами пользователей. И, по идее, желательно как-то от них избавляться. В нашем случае мы начали с достаточно наивных методов – развернуть копию базы данных для чтения и перевести туда всю работу этих пользователей. Постепенно перешли и на более хитрые механизмы формирования сложных витрин с большими данными, где пользователи спокойно работают и довольны качеством и актуальностью этих данных.
  • И третий фактор, который характеризуется объемом – это тот объем функциональности, который вы реализовали в системе. Чем больше его становится, тем больше и быстрее растет база данных, тем больше становится пользователей. Этим тоже необходимо как-то управлять, бороться со слишком большой скоростью. В нашем конкретном случае мы стараемся контролировать доработки, которые реализуем, но идея как-то вынести большой кластер функциональности не получается. Тот момент, когда мы упустили, и все жизненно важные функции для системы зародились именно в ней, они так активно в ней и развиваются.

Объем функциональности рано или поздно приводит к другой сложности. Это когнитивные сложности.

 

Фактор второй: когнитивные сложности

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

 

 

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

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

Необходимо разработать «базу знаний», которая позволит нам быстро и качественно спроектировать новое решение. Вовремя увидеть, что запроектированное решение повлияет так или иначе на какие-то процессы, которые мы не хотим затронуть.

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

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

 

Третий фактор: качество кодовой базы

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

 

 

На качество кодовой базы постоянно оказывается достаточно мощное влияние.

  • В нашей системе одновременно работает множество разных команд разработчиков, у каждой свой подход, своя доменная модель, и самих разработчиков достаточно много. Даже при небольшой текучке мы постоянно сталкиваемся с такими проблемами, когда важный кусок кода разрабатывал один разработчик, перед уходом передал эту работу другому, а другой разработчик передает третьему.
  • Специфика работы в монолите не позволяет правильно разделить доменные области. Очень сложно сказать, что эту часть разрабатывает одна группа разработчиков, вот эту – другая. Очень размыты границы между ответственностью команд. Есть большая куча объектов, которая разрабатывается одновременно несколькими разработчиками: это приводит к тому, что сложно разделить эти домены. Их границы размыты и малопонятны.
  • Плюс ко всему у нас есть вопросы к историчности. Как я говорил, база работает больше 10 лет. Сначала она работала на платформе 8.1, затем – 8.2, затем – 8.3. Все эти артефакты так или иначе остаются, и нам приходится что-то с этим делать.

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

  • Базовое решение – повысить общий уровень разработки. Обучение и адаптация, входной фильтр разработчиков. Наши разработчики понимают ряд вопросов лучше, чем в среднем по рынку, например: вопросы производительности, то, как работают индексы, как выполняются планы запросов, и как эти планы зависят от состояния статистик.
  • Использование общих шаблонов и подходов, плюс код-ревью и автоматизация проверок позволят выровнять, нормализовать качество кода, сделать новые доработки и сделать приемлемым и понятным поддержание старых.

 

Про подход к проектированию новых решений

Остается еще один важный момент – то, как мы проектируем новые решения.

 

 

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

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

Но есть задачи, которые делаются с расчетом, что доработки будут постоянно модифицироваться. Как пример: реализация бизнес-процессов, выполнение производственных функций. Тут подход – сделать раз-раз и в продакшн – не совсем оправдан. Надо вовремя увидеть, что задача относится именно к этому классу и отнестись к ней по-другому. Хороший пример такого подхода у нас был реализован при разработке нашей внутренней библиотеки стандартных подсистем.

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

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

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

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

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

Системный архитектор должен следить, чтобы разрабатываемые задачи не требовали глубокого погружения, вовремя увидеть сложные задачи и найти ресурсы для их правильной проработки. Почему это важно? Потому что все равно придет момент, когда что бы мы ни делали, затраты на поддержку съедят весь имеющийся у нас ресурс. Мы придем к моменту, когда матрицу придется перезагружать. И чем больше и качественнее у нас будут проработаны эти механизмы, чем более они будут сконцентрированы, тем легче нам будет разнести систему. Растянуть расставание с большой тяжелой базой на более длительный период либо как-то минимизировать время разработки во время резкого перехода, если вдруг возникнет такая необходимость.

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

 

Вопросы

На одном из слайдов был рассказ про вынос функциональных блоков из большой системы. Расскажи про проблемы, которые были с этим связаны. Что мешает функциональность в большом монолите на сторонние, рядом стоящие решения?

Готовых 100% успешных решений для выноса этой функциональности в отдельные блоки у нас нет. К сожалению, все объемные кластеры функциональности – функциональность работы с заказами, то, как мы рассчитываем себестоимость и цены продукции – все это было реализовано в монолите и, конечно, требует выноса в отдельный функциональный блок. Но мы этого не смогли сделать? Почему? Потому что это действительно жизненно важные элементы бизнеса заказчика, они постоянно дорабатываются и вынос этой функциональности сродни операции на работающем сердце. Чтобы сделать это безопасно, с одной стороны, необходимо остановить разработку, на что не может пойти заказчик. Поэтому единственный вариант это реализовать – это либо дождаться, когда другого варианта не будет, либо второй вариант – когда бизнес скажет, что хочет что-то кардинально новое. Тогда естественно будет повод разработать новую систему и быстро перевести комплект функциональности на работу с внешней системой. Чтобы это сделать как можно более безопасно, нам и нужны хорошие разработчики и база знаний по всем кейсам, которые позволят сформировать задание на переход. Сергей Носков в одном из предыдущих докладов говорил: «У кого одна база, хочет ее разделить, у кого их несколько, хочет объединить». Это вечный цикл.

Как происходит обрезание системы? Сколько оно занимает по времени?

Мы не столько обрезаем старую базу данных – у нас есть волшебная штука, которая создает новую базу, в которой будет консистентные данные за последний период. При наших объемах – это единственный вариант. Из-за специфики хранения данных на MS SQL, альтернатив нет. По времени, так как это происходит зеркально, не останавливая процесс работы бизнеса, последний раз это заняло дня три-четыре.

Сколько человек занимается администрированием СУБД таких размеров?

DBA-шников – двое. А разработчиков у нас много.

 

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

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Saint Petersburg.Online. Больше статей можно прочитать здесь.

Приглашаем всех принять участие в тематических митапах Инфостарта и INFOSTART EVENT 2021 (6-8 мая, СПб).

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Terve!R 10.03.21 13:11 Сейчас в теме
Мне кажется, это все справедливо только для действительно крупных систем и больших команд разработки. Не все могут в таких поработать)
3. Aleksey.Polushin 18.03.21 12:09 Сейчас в теме
(1) у нас система почти на 4 000 пользователей - но уже чувствуется, что надо как минимум прекратить расширение функционала существующей системы и дальнейший функционал уводить на "микросервисы" с глубокой интеграцией, а лучше уже начать "дробить" существующую систему. А система вроде как и не очень крупная.
2. RustIG 12.03.21 06:27 Сейчас в теме
(0) рабочих примеров мало...вообще ничего не осталось в памяти после прочтения....что можно взять здесь и сейчас - и применить ?..
Оставьте свое сообщение

См. также

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) Промо

HighLoad оптимизация Бесплатно (free)

Если вы используете SQL Server 2016 или более позднюю версию, то у вас есть возможность использовать встроенную систему мониторинга, которая позволяет отслеживать самые базовые метрики выполняемых запросов и статистику ожиданий (потребления ресурсов). Эта информация позволяет быстро получить самые ресурсоемкие запросы с их планами и агрегированной статистикой выполнения.

26.04.2019    15858    Aleksey.Bochkov    8    

Нагрузочное тестирование в 1С:ERP

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

02.11.2022    2476    Tavalik    23    

Битва параллелизмов: MS SQL vs PostgreSQL

HighLoad оптимизация Бесплатно (free)

Чем отличаются подходы в построении плана запросов для PostgreSQL и MS SQL? Какие запросы хорошо параллелятся, а какие нет? Кто в итоге круче в параллелизме – MS SQL или PostgreSQL? Вадим Фоминых протестировал обе СУБД на эффективность параллельной работы и рассказал о своих выводах в докладе на конференции Infostart Event 2021 Post-Apocalypse.

31.10.2022    5516    Shmell    4    

MS SQL Server: ваши статистики не работают! Так ли все плохо на самом деле?

HighLoad оптимизация Бесплатно (free)

Состояние и качество статистик критически важны для эффективной работы системы. Но у заметной части типовых конфигураций статистики просто не могут работать эффективно. О том, почему так происходит и что с этим делать, на конференции Infostart Event 2021 Post-Apocalypse рассказал Александр Денисов.

27.09.2022    1926    Филин    11    

Опыт миграции из собственного датацентра в облако AWS Промо

HighLoad оптимизация Бесплатно (free)

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

29.07.2018    12809    Aleksey.Bochkov    9    

Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

От быстродействия запросов, которые обращаются к крупным таблицам, напрямую зависит скорость работы всей базы в целом. Артем Кузнецов, тимлид команды 1С в компании ООО «Финтех решения» на конференции Infostart Event 2021 Moscow Premiere рассказал, как оптимизировать производительность при поддержке больших систем. Показал, на что следует обращать внимание при код-ревью запросов, как оптимизировать RLS, виртуальные таблицы, индексы и условия, и как доработка архитектуры решения может ускорить работу базы.

29.08.2022    4662    Chernazem    44    

Ускорим проведение в 1С:Управление холдингом

HighLoad оптимизация Запросы Платформа 1С v8.3 1С:Управление холдингом Бесплатно (free)

В 1С:Управление холдингом есть "нехороший" запрос, который съедает значительную часть времени проведения документов. Если его подправить, то проведение заметно ускорится.

10.08.2022    4474    sapervodichka    60    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

HighLoad оптимизация Бесплатно (free)

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    69910    Sergey.Noskov    119    

Миссия невыполнима. Общие реквизиты разделители против временных таблиц

HighLoad оптимизация Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

05.08.2022    1383    1CUnlimited    0    

Методика похудения для 1С – 100%

Свертка базы HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

28.07.2022    4841    1CUnlimited    37    

Долго открывается конфигуратор Промо

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    46785    Gilev.Vyacheslav    1    

Экспертный кейс. История расследования одного небыстрого закрытия месяца в 1C:ERP. Пример неочевидных путей расследования в виде детективной истории

HighLoad оптимизация Механизмы платформы 1С Запросы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

В данной статье хотим рассказать об одном нашем непростом расследовании, в котором удалось собрать сразу несколько проблем на разных уровнях инфраструктуры заказчика и изначальной методологии ведения учета. Само расследование в какой-то момент стало напоминать детективную историю, с роялями в кустах, ошибками платформы, странным поведением пользователей и магическим поведением хорошо знакомых механизмов. Но мы реалисты, поэтому все проблемы были выявлены и устранены ;)

11.07.2022    4738    it-expertise    27    

10 «заповедей» эксплуатации крупной информационной системы 1С

Управление ИТ-подразделением Внедрение ИТ-системы HighLoad оптимизация Бесплатно (free)

Крупные системы 1С давно уже перешагнули и десятки терабайт, и тысячи пользователей, но во многих случаях подход к эксплуатации таких систем остаётся не на должном уровне. Антон Дорошкевич на конференции Infostart Event 2021 Post-Apocalypse поделился более чем 10-ти летним опытом эксплуатации подобных систем, сведя его к 10 «заповедям», соблюдение которых сделает 1С надёжнее, а труд разработчика – благодарнее и благороднее.

11.07.2022    6826    a.doroshkevich    33    

Производительный режим работы RLS

HighLoad оптимизация Роли и права Платформа 1С v8.3 8.3.14 8.3.6 8.3.8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Бесплатно (free)

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в данном материале.

14.06.2022    4899    Neti    6    

Видеодемонстрация применения Теста-центра для нагрузочного тестирования конфигураций Промо

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

16.09.2012    37180    Aleksey.Bochkov    29    

Любовь. Быстродействие. 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Несколько эпизодов на общую тему, собранные за последние полгода. Первый вариант, будет исправляться и дополняться.

26.05.2022    3559    vasilev2015    20    

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

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 8.3.14 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

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

24.05.2022    3529    avolsed    15    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

HighLoad оптимизация Бесплатно (free)

С проблемой повышенной нагрузки на диски (дисковые хранилища и массивы, далее просто диски), сталкиваются почти все администраторы и специалисты технической поддержки при эксплуатации средних и крупных информационных систем на базе SQL Server (от 50 активных пользовательских сессий). Но всегда ли правильно идет интерпретация проблемы, попробуем разобраться на нескольких практических примерах.

15.03.2015    48087    gallam99    17    

Заметки эксперта. Расследование длительного выполнения отчета “Движение ТМЦ и затрат в производстве” (1С:ERP 2)

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Кратко: в ходе проведения нагрузочного тестирования “1С:ERP 2” под ОС Linux на СУБД Postgres выявлено существенное замедление формирования отчета “Движение ТМЦ и затрат в производстве” - до 60 минут. После проведенного расследования и точечной корректировки СКД в отчете, без изменения бизнес-логики результатов его работы, работа отчета была ускорена в 80 раз - средний показатель формирования составил 30 секунд.

19.05.2022    1963    it-expertise    19    

Нагрузочное тестирование 5000+ пользователей онлайн — играем в игру

HighLoad оптимизация Тестирование QA Бесплатно (free)

Тестируем ERP под Postgre SQL. Альтернативный нагрузочный тест.

16.05.2022    6109    ivanov660    52    

Тестирование - игровое моделирование

HighLoad оптимизация Тестирование QA Платформа 1С v8.3 Бесплатно (free)

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    1302    ivanov660    0    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    71469    yuraos    112    

Анализ кода, потребляющего ресурсы СУБД MS SQL, контекстами 1С

HighLoad оптимизация Бесплатно (free)

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

21.04.2022    2039    pashamak    1    

Несколько слов про платформенный механизм оптимизации RLS

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Смотрим, как работает платформенный механизм оптимизации RLS, сравним поведение на разных СУБД MS SQL, Postgres 11,13,14.

07.04.2022    3366    ivanov660    23    

Почему после обновления Бухгалтерии в марте 2022 года отчеты стали такими медленными

HighLoad оптимизация Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Статья раскрывает причину, почему время формирования отчетов после обновления Бухгалтерии в марте 2022 сильно увеличилось. И рассказывает, как можно исправить ситуацию.

05.04.2022    4471    DBOdin_Lab    33    

Ускорение реструктуризации таблиц Промо

HighLoad оптимизация Бесплатно (free)

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

12.09.2013    54482    OLEG4120    32    

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

HighLoad оптимизация Механизмы типовых конфигураций Запросы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости. Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

25.03.2022    4844    it-expertise    92    

Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

Механизмы платформы 1С Запросы HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

В ходе проведения нагрузочного тестирования одним из наших клиентов была выявлена сильная деградация производительности системы в целом и, в частности, выполнения ключевой операции “Проведение документа поступление товаров и услуг” в течение выполнения теста. Согласно данным подсистемы БСП “Оценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале.

02.03.2022    3605    it-expertise    47    

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

HighLoad оптимизация Технологический журнал Платформа 1С v8.3 Бесплатно (free)

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    10507    ivanov660    18    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

HighLoad оптимизация Платформа 1С v8.3 1С:Управление торговлей 10 1С:Управление производственным предприятием Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    60544    Антон Ширяев    117    

Ускорение работы конфигуратора 1С с большими прикладными решениями

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Ускорение работы 1С конфигуратора с большими прикладными решениями путем размещения системных каталогов 1С на RAM диске.

13.01.2022    6656    stg2005    105    

AMD RYZEN 5600X: погоня за попугаями

HighLoad оптимизация Бесплатно (free)

Все по-взрослому...

08.12.2021    6458    starik-2005    266    

Ошибка производительности при проведении этапа 2.2 в ERP 2.4 и ERP 2.5

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Хочется поделиться одним подводным камнем, с которым могут встретиться другие пользователи ERP. Искал решение в интернете, но ничего похожего не нашел. Поэтому решил создать эту тему.

06.12.2021    1565    Rokky78    6    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    62893    Gilev.Vyacheslav    46    

Инструкция по получению плана запроса через Extended Events

HighLoad оптимизация Бесплатно (free)

Доброго времени суток, коллеги. Хочу рассказать, как можно посмотреть план запроса через механизм Extended Events. Я хочу ответить на вопрос - как разработчику через SQL Management Studio посмотреть, что запрос, который он сделал, работает оптимально. На Инфостарте есть несколько статей, которые посвящены трассировкам в этом механизме. Мне, когда я не понимал, как это правильно делать, не хватало простой пошаговой инструкции. Я напишу инструкцию, выполняя которую можно будет увидеть план запроса, который выполняется из базы данных.

22.11.2021    2171    Andrei_Ivanov    3    

Подходы к организации информационной безопасности в корпоративных проектах

HighLoad оптимизация Государственные, бюджетные структуры 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Оформили в виде статьи наш доклад на недавно прошедшем семинаре партнеров 1С на тему требований к информационной безопасности на проектах, с которыми всё чаще встречаемся мы и наши партнеры. В статье рассмотрено, почему этими вопросами стоит озаботиться уже сейчас. Куда бежать и что делать, если вы попали на проект с требованиями по информационной безопасности…

29.10.2021    4347    it-expertise    11    

Повышение производительности веб-сервисов. Переиспользование сеансов

WEB-интеграция HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    4004    sorter1    2    

Параллельные вычисления в 1С 8 Промо

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    38898    gallam99    19    

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода Технологический журнал Платформа 1С v8.3 Бесплатно (free)

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

07.09.2021    11308    ivanov660    26    

Показатель Page Life Expectancy (PLE)

HighLoad оптимизация Администрирование СУБД Бесплатно (free)

От переводчика: публикация составлена по материалам BrentOzar.com (Brent Ozar).

18.08.2021    3770    vasilev2015    7    

Кластер для отказоустойчивости

HighLoad оптимизация Администрирование СУБД Бесплатно (free)

На Infostart Meetup «PostgreSQL VS Microsoft SQL» выступил руководитель проектов в по разработке ПО в компании «Газинформсервис» Денис Рожков. В рамках доклада Денис рассказал о том, какие механизмы кластеризации используются для PostgreSQL и в MS SQL и поделился с коллегами, какие решения можно использовать для построения отказоустойчивого кластера на PostgreSQL.

18.08.2021    10950    FB_3393521717335803    2    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    46026    madmpro    32    

Адекватный параллелизм в 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    11293    Shmell    8    

Создаем счетчики производительности Windows для 1С

HighLoad оптимизация Бесплатно (free)

В статье описан подход, позволяющий создавать счетчики производительности Windows для 1С:Предприятие.

09.08.2021    4651    blackhole321    8    

Распространенные ошибки разработчиков, приводящие к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    14369    ivanov660    77    

1С:Предприятие 7.7. Оптимизация. Промо

HighLoad оптимизация Платформа 1С v7.7 Конфигурации 1cv7 Россия Бесплатно (free)

Разгоняем 1С:Предприятие 7.7. Выжимаем последние соки.

31.01.2009    50973    alexk-is    110    

Fill factor

HighLoad оптимизация Бесплатно (free)

От переводчика: Публикация составлена по материалам BrentOzar.com (Brent Ozar).

02.08.2021    3535    vasilev2015    6    

Parameter sniffing и генерация планов для разработчиков 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021    14141    vasilev2015    17    

Поиск причин блокировок СУБД

HighLoad оптимизация Платформа 1С v8.3 Управление блокировками Конфигурации 1cv8 Бесплатно (free)

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    7619    vasilev2015    14    

Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С. 

22.04.2021    7183    a.doroshkevich    6