Надежная работа

Говоря об оптимизации 1С:Предприятие, можно например выделить следующие ключевые понятия - надежность, масштабируемость и производительность.

Сущность понятия  «надежность»

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

Высокая доступность 1С:Предприятия (отказоусточивость)

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

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

Существуют решения, с помощью которых возможно увеличение надежности до 99,999%, что соответствует нескольким минутам простоя системы в год. Обратной стороной медали является цена вопроса, так как увеличивается количество физического оборудования, используются технологии кластеризации. И главное, это все будет работать при наличии действий квалифицированного специалиста! Это крупные компании, эксплуатирующие сложные бизнес-приложения (ERP-, CRM-системы и другие), операторы услуг связи, банки, обслуживающие клиентские счета и проводящие расчёты по пластиковым карточкам, страховые компании и другие.

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

Сбой сети.

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

Сбой оборудования.

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

Отказ питания.

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

Сбой программного обеспечения.

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

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

Аппаратное резервирование

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

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

в серверах используется память Chipkill с "зеркалированием"

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

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

Реализовано резервирование вентиляторов с возможностью «горячей» замены,

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

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

Дублирование серверов, кластеры

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

Так что же это такое, кластер? К настоящему времени слово «кластер 1С:Предприятие» уже стал привычным для 1С-специалистов.

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

В тоже время отказоустойчивый кластер (MSCS) в Microsoft SQL Server 2005 обеспечивает высокий уровень доступности всего экземпляра SQL Server. Подробное описание здесь http://technet.microsoft.com/ru-ru/li...89134.aspx .

Когда Заказчик хочет ПОЛЬНОСТЬЮ ОТКАЗОУСТОЙЧИВОЕ РЕШЕНИЕ, надо понимать, что 1С:Предприятие официально такой возможности не предоставляет!

Что же делать, если речь идет о крупном проекте. Выкручиваться на том, что есть.
В настоящее время существуют два варианта решения проблемы:
1. Организовать (на свой страх и риск, потому что 1С официально пока не поддерживает) отказоустойчивость кластера 1С:Предприятие при помощи службы MSCS. Автором этого материала лично выполнялось такое внедрение в компании федерального масштаба.
2. Другой способ – использовать отказоустойчивые виртуальные сервера. Второй способ означает создание «виртуального сервера», не зависящего от места исполнения кода на реальном сервере.

Резервное копирование

Даже если вы обеспечили высокую доступность системы, это не значит, что пользователь не сможет сам себе не "испортить жизнь". Он возмет, удалить "случайно" работу за день, а потом будет требовать свои данные "назад". Либо программист "реализует" новую функцию в программе, которая не очень понравиться, и захочется вернуться ("откатиться") к предыдущему варианту программы. Вообщем, для системная администратора попрежнему действует правило, что все сисадмины деляться только на две катергории:

- те что делают бэкапы

- и те, что будут делать бэкапы.

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

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

Неизбежность наличия ошибок

Играли ли вы paintboll? Игра в paintball – это огонь и движение. Бизнес – это тоже paintball, это огонь и движение. Большие фирмы в основном стреляют и слегка движутся (чтобы не дать маленьким до них добраться), а маленькие в основном движутся, а стрелять обычно по большим бесполезно.

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

“Каждое утро где-то в Африке просыпается Газель. Она знает, что она должна бежать быстрее, чем самый быстрый Лев, либо она погибнет. Лев поднимаясь каждое утро, знает, что он должен догнать хотя бы самую медленную Газель, иначе он умрет от голода. И не важно, кто Вы - Газель или Лев. Когда солнце встает, Вам лучше уже бежать!”

1C хорошо бегает (а за счет большого количества выстрелов часто попадает).
А основное оружие – это решения на платформе 1С:Предприятие. Если Вы хотите оказаться победителем, Вам тоже надо бежать (или хотя бы делать шаги).

Отсюда постулаты (копирайт мой, Гилёва Вячеслава)

1)      1С:Предприятие постоянно развивается (бежит)
2)      Любая новая программа имеет ошибки и не полностью документирована, а 1С:Предприятие – это постоянно обновляемая , читай новая программа
3)      Для успеха надо применять то, что есть сейчас (т.е. если пока ждать исправления ошибок, остальные убегут вперед).

Как с этим жить (с ошибками)

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

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

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

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

Решению вопросов устранения неисправностей рекомендую посмотреть этот материал.

Подробней об утечках памяти можно прочитать здесь.

Методика восстановление разрушенных баз здесь.

Проблемы отключения пользователей от сервера (ошибка 10054) здесь.

Борьба с ситуацией "ошибка потока формата" здесь.

Проблема "неуникальных индексов" здесь.

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

Перейти к другим материалам сайта

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