Вступление Гибкие Блокировки   

   

Вступление

  Целью данной статьи будет рассказать, что же из себя представляет технология компании Softpoint «Гибкие блокировки» tm, решающая проблемы производительности и масштабируемости в крупных ИТ системах. Пояснения будут, как для людей от бизнеса, так и для ИТ специалистов. Мне лично приходилось слышать различные мнения по поводу этой технологии. Начиная от того, что это «хакерские методы», заканчивая, «там же просто блокировки убрать – подумаешь!». Даже наши многочисленные клиенты не все до конца понимали концепцию этой технологии. В конечном случае они ведь видели результат и их это устраивало, зачем вникать в детали? А ведь именно в деталях, во множестве деталей и кроется секрет!

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

  Исторически так сложилось, что наибольшее количество наших клиентов использовали наиболее распространенную систему 1С в связке с MSSQL. Это легко объяснить тем, что система 1С является наиболее распространенной платформой в России, также как и СУБД MSSQL. Обвинения в том, что это все проблемы производительности объясняются неэффективностью работы системы 1С - беспочвенны. Последняя платформа 1С 8.3. является одной из самых технологичных и масштабируемых на российском ИТ рынке. Наличие неэффективных конструкций, методов и т. п. объясняется только лишь большим объемом функциональных возможностей, и является приемлемым для корпоративной ERP системы. В силу истории развития технологии «гибкие блокировки» - она является наиболее адаптированной для систем 1С. В целом же эта технология покрывает большинство систем работающие под управлением СУБД MSSQL.

  Из того, что может дать технология «гибкие блокировки» бизнесу можно резюмировать следующее:
В кратчайшие сроки: от одной недели до 5-и недель, гарантированно, решить все проблемы производительности в ИТ системе. С помощью специализированных средств мониторинга производительности результат будет оцениваемым и будет гарантирован на уровне договора. Запас производительности ИТ системы будет на уровне договора – один год, в среднем этот показатель 2-а и более лет. Бизнес процессы существующей системы не меняются, что позволяет избежать дополнительных проблем.

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

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

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

Приведу пример нескольких таких ситуаций:
 

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

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

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

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

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

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

Давайте заставим разработчика оптимизировать свой код!
  SLA требование, например, время выполнения тех или иных операций в системе.  Непроведение работ по оптимизации кода, конечно, делает проекты более дешевыми, но при этом в случае возникновения в дальнейшем подобных ситуаций юридически взыскать потери с разработчика не представиться возможным. Да и с этической точки зрения если разработчик предупреждал клиента о необходимости подобных работ, а клиент их проигнорировал, то виноват будет только клиент.
 
 С точки зрения ИТ, «гибкие блокировки» представляет собой набор сложного программного обеспечения и набор технологий. Данное ПО интегрируется в системы под управлением MSSQL. Для систем 1С,MSSQL предусмотрена наиболее тесная интеграция и, соответственно, наибольший эффект.  Данное ПО легко отчуждаемо, и все сделано для простоты дальнейшего сопровождения. То есть после проекта внедрения, дальнейшее сопровождение в подавляющем большинстве случаев осуществляется собственным  ИТ отделом компании. Внедрение данной технологии не предусматривает изменения функционала существующей ИТ системы. Соответственно, сроки и риски внедрения – минимальны.
  В некоторых случаях клиент  в случае возникновения проблем производительности хочет возложить ответственность на разработчика системы.  Это возникает от того, что большинство как разработчиков так и заказчиков не задумываются о подобных проблемах заранее. Поэтому в большинстве проектов автоматизации не планируется создание систем нагрузочного тестирования, не предусматривается внедрения систем мониторинга производительности.

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

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

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

Бесплатное предварительное обследование является обязательным этапом проекта внедрения технологии "Гибкие блокировки". В большинстве случаев обследование и неспоредственно сам проект внедрения проводится удаленно.
Для заказа бесплатного предварительного обследования заполните заявку расположенную ниже:


Перепечатка, воспроизведение в любой форме, распространение, в том числе в переводе, любых материалов с сайта 
www.softpoint.ru возможны только с письменного разрешения компании "СофтПоинт". Это правило действует для всех без исключения случаев, кроме тех, когда в материале прямо указано разрешение на копирование (основание: Закон Российской Федерации "Об авторском праве и смежных правах").

Статья: Вступление Гибкие Блокировки

Перейти на главную страницу компании "Софтпоинт"