Процедура устранения ошибок. Устранение неполадок в WordPress

09.10.2008 Игорь Панов

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

Локальные сети охватывают разнообразные компоненты: принтеры, терминальные устройства, персональные компьютеры, IP-телефоны, серверы, устройства хранения, сетевое оборудование, программное обеспечение безопасности, сетевые приложения, корпоративные приложения, офисные пакеты и многое другое. Мы сосредоточимся на первом и втором уровнях сетевой модели OSI: физическом уровне (среде передачи) и коммутаторах. Кабельная система и коммутаторы - это основа современных локальных сетей.

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

МЕТОД НА ВСЕ СЛУЧАИ ЖИЗНИ

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

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

ПОДХОД К РАБОТЕ

Успешно обнаружить и устранить сетевые неисправности может лишь тот, кому досконально известно, как должна работать сеть в нормальном режиме. Только при таком условии можно быстро распознать отклонение от нормы и диагностировать неполадку.

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

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

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

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

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

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

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

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

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

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

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

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

УСТРАНЕНИЕ СБОЕВ ЗА ВОСЕМЬ ШАГОВ

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

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

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

Шаг 2. Воссоздание проблемной ситуации. Спросите себя, правильно ли вы оценили симптомы и действительно ли уяснили суть неполадок. Гораздо проще устранить те сбои, которые удается воссоздать; тогда их можно наблюдать, посмотреть сообщения об ошибках и выявить признаки ошибок, о которых пользователь не знает или не говорит, потому что не считает их важными. В идеале можно собрать сетевую статистику прямо во время сбоя.

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

Шаг 3. Выявление причины сбоя. Определив проблему, а если нужно, и воссоздав ее, надо попробовать локализовать сбой: установить, к какому устройству, соединению или приложению он относится. Область поисков нужно последовательно сужать, отсекая лишнее. Рамки проблемы необходимо ограничить наименьшим элементом системы, в нем-то и будет заключаться причина. Заодно стоит проверить, нет ли вирусов, отсутствует ли какая-либо важная для работы функция, появляется ли необычный отклик. Данные, накопленные средствами мониторинга, окажутся весьма полезными.

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

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

Когда сбой затрагивает весь разделяемый сегмент сети, необходимо последовательно отсекать лишние переменные, сводя количество факторов к минимально возможному. В топологии шины стоит попробовать подключиться по более короткому сегменту кабеля; в топологии кольца или звезды - временно проложить другие кабели для создания минимально возможной сети, чтобы ее было проще диагностировать. Попробуйте подключить другой сетевой коммутатор или концентратор. Если проблема охватывает разделяемый сегмент, где находится сетевой ресурс, попытайтесь выключить или отсоединить от сети все рабочие станции, кроме двух. Если они взаимодействуют нормально, добавьте еще одну, затем еще. Если же соединение между ними отсутствует, то следует проверить физические элементы канала - концевые разъемы на кабеле, сам кабель, задействованные порты на активном оборудовании (в концентраторах и коммутаторах).

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

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

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

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

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

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

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

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

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

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

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

Шаг 8. Информирование пользователя. Зачастую после устранения проблемы возникает искушение на том и закончить. Однако пользователь, раз уж обратился за помощью, будет признателен, если вы все-таки объясните ему, что произошло. В случае повторения подобного сбоя он сможет быстрее распознать опасную ситуацию и сразу сообщить о ней, тогда и работоспособность сети будет выше. Кроме того, разъясняя, что можно делать, а чего нельзя, вы снижаете вероятность возникновения аналогичного сбоя в будущем.

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

Как известно, решение любой сетевой проблемы на 75% состоит в разрешении проблем с пользователем. Если он не согласился с вами, что дело доведено до логического завершения (и неважно, устранили ли вы неполадку или привели тысячу причин - финансовых, технических, политических, - по которым она не может быть устранена), это означает, что работу по заявке вы не закончили.

С ЧЕГО НАЧАТЬ

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

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

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

Никто не может знать все на свете, поэтому не стесняйтесь попросить помощи. Если вы в чем-то сомневаетесь, не поленитесь обратиться за информацией к нескольким источникам.

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

Игорь Панов - региональный менеджер по продукции и поддержке парт-неров Fluke Networks в России и СНГ. С ним можно связаться по адресу: [email protected] .

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

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

Порядок действий

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

После обнаружения объекта, который вызывает проблему, Вы можете удалить его с сайта для устранения проблемы

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

Уровни

Я бы хотел разделить WordPress на четыре уровня:

плагины
ядро WordPress

В этом руководстве мы рассмотрим только первые три уровня.

Что поможет исправить этот процесс?

Приведем список самых распространенных проблем в WordPress, которые поможет исправить данное руководство:

«белый экран смерти»
ошибку «Заголовок уже был отправлен»
фатальные ошибки плагинов
ошибку «не достаточно памяти»
многие другие проблемы WordPress.

Сначала делаем бэкап

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

Плагины, вызывающие ошибки

При поиске причин возникновения ошибок, я всегда начинаю с плагинов. По моему опыту, около 80-90% сбоев в работе системы вызывают плагины. Это потому, что существует слишком много плагинов, зачастую, не очень хорошего качества. сами по себе они могут работать нормально, но в сочетании с другими плагинами, часто приводят к критическим ошибкам.

Моя методика устранения ошибок, связанных с плагинами:

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

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

Всё, что Вам нужно. это подключится к Вашему сайту через FTP, перейти в папку wp-content и переименовать каталог с плагинами, например, в plugins_old. Таким образом WordPress не найдет установленные плагины и все они, следовательно, не активны. После этого, скорее всего, Вы благополучно войдете в панель управления.

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

Устранение неполадок темы

После проверки плагинов переходим к следующему этапу – проверке тем. Действуем по следующей схеме:

Отключаем текущую тему.
Включаем тему по умолчанию.
Тест. Если проблема исчезла, вы знаете – проблема в Вашей теме.
Активируйте по одному все плагины, чтобы убедится, что проблема не в совместимости.

Далее следует попытаться отменить все изменения, внесенные в файлы темы, удалив весь код, который Вы недавно добавили. Если тема была обновлена, попытайтесь откатится до предыдущей версии. Если недавно был добавлен какой-то виджет – попробуйте его удалить. После каждого действия отслеживайте состояние сайта и Вы сможете восстановить работоспособность темы.

Опять же, если из-за неработоспособной темы Вы не можете войти в панель управления, подключите к вашему сайту через FTP, и перейдите в каталог wp-content/themes и измените имя папки, в которой находятся файлы вашего текущего шаблона. WordPress не сможет найти файлы шаблона, и всё, что Вы увидите на главной - белый экран, однако панель управления будет доступна и Вы сможете туда войти и последовать пункту 2 и активировать тему по молчанию.

Устранение неполадок основных файлов в WordPress

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

Процесс восстановления работоспособности блога после ошибок в ядре WordPress я бы разделил на такие этапы:

Скачать оригинальную версию версию WordPress с http://wordpress.org/download/ .
Подключиться к Вашему сайту через FTP.
Переименуйте папки wp-admin и wp-includes , и загрузите чистые копии этих папок
Сделайте резервную копию файла wp-config.php на всякий случай. В нем прописаны параметры подключения к БД и некоторые другие важные настройки.
Загрузите оригинальные файлы WordPress.
Тестируем. Если проблема не решена и сейчас, то пора обратится к экспертам.
Повторно активируйте Вашу тему и протестировать её.
Активируйте плагины и тестируем снова.

Исправление неполадок в компонентах

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

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

Посетите сайт разработчика плагина или темы и поищите у них форум поддержки или обратитесь напрямую к автору через форму обратной связи. Любой разработчик бесплатного дополнения будет рад оказать поддержку по своему продукту, ну а авторы премиум плагинов или шаблонов делать это просто обязаны.
Найдите замену теме или плагину. Существует, как правило несколько альтернатив любому дополнению. Так что, если есть возможность, то просто айдите альтернативу неисправному плагину
Воспользуйтесь помощью сообщества http://wordpress.org/support/ . Таким образом можно решить проблемы ядра WordPress. Там же, на форуме можно найти темы, посвященные многим плагинам и темам.
Привлеките к решению проблемы социальные сети. Да, это легко. Иногда для решения проблемы мне хватает одного твитта и пары минут
Наймите специалиста в области WordPress

Подводим итоги

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

Здравствуйте! у меня такая проблема: у меня Windows 98 SE, и вот при выключении или перезагрузке компьютера часто появляется ошибка в программе MPREXE.EXE и после этого дальше выключать получается только нажав 3 клавиши… Подскажите, пожалуйста, как устранить эту проблему?

Запускаю Outlook - появляется «мессага» типа: «MSMIN выполнила недопустимую операцию и будет закрыта». :(Такого вот типа… Либо «Программа MSIMN вызвала сбой при обращении к странице памяти в модуле INETCOMM.DLL по адресу 0167:5ec22198». Помогите…

Довольно часто происходит ошибка типа: «Программа EXPLORER вызвала сбой при обращении к странице памяти в модуле MSHTML.DLL по адресу 0167:70db56f5». Что это?

Мне постоянно приходят подобные вопросы, но, к сожалению, однозначного универсального решения таких проблем не существует, и дать какой-то определённый ответ чаще всего просто невозможно. Причин таких сбоев множество, и никто не в состоянии знать их все. Дело в том, что каждая система, каждая связка «операционная система - программное обеспечение - оборудование - драйвера» неповторима, и устранить причину такого сбоя можно только потратив немало времени непосредственно на месте, то есть, препарируя по винтику и по байтику конкретный компьютер. Если «глюк» появился в какой-то определённый момент, например, после установки какой-то программы или драйвера, то проще всего после удаления такой программы восстановить реестр или всё содержание жёсткого диска из резервной копии. (Ну сколько же можно говорить, что слово «резервировать» должно буквально сниться пользователю Windows?). Не так уж сложно потратить несколько минут раз в неделю на создание резерва - нервов и времени это в результате сэкономит гораздо больше. Как всё это делается, и как вообще проводится профилактика сбоев, мы уже неоднократно писали в Upgrade - просто пролистайте подшивку журнала или проштудируйте сайт upgrade.computery.ru . Если же нет возможности столь легко вернуть систему к «безглючному» состоянию, либо сбои в работе Windows и оборудования происходит прямо на свежеустановленной ОС, то выход один - пользователю придётся искать причину сбоя самостоятельно. В принципе, технология «отлова глюка» тоже мной уже приводилась в одном из журналов, но было это очень давно, вопросы по-прежнему продолжают поступать, «глюки» активно размножаются, так что, думаю, есть смысл технологию диагностики причин сбоев Windows усовершенствовать.

Итак, вы поимели «ГЛЮК». Приступим к его устранению. Обязательно запоминайте все свои действия, чтобы можно было их потом отменить! А ещё лучше - хотя бы сейчас сделайте резервную копию реестра, конфигурационных файлов или всей системы, чтобы не получить в результате своих экспериментов ещё большие проблемы.

Первым же делом (пунктом «ноль», как я уже говорил, у грамотного пользователя должно являться восстановление системы или реестра из резервной копии) запишите в точности сообщение об ошибке, которое выдаёт система, и зайдите на сайт технической поддержки Microsoft search.support.microsoft.com/kb/c.asp либо на его русский аналог www.microsoft.com/rus/support/kbrus.htm . Постарайтесь на основе своего сообщения об ошибке сформулировать запрос для поисковой системы таким образом, чтобы получить наиболее внятный ответ - несколько попыток, думаю, помогут вам найти если не чёткое решение проблемы, то хотя бы примерное представление о причине «глюка». Поверьте, найти решение в базе данных Microsoft - самый простой и быстрый способ устранения «глюка», и пренебрегать им нельзя ни в коем случае.
Если вам не повезло, и Microsoft не знает о таком «глюке», то запустите специализированную утилиту поиска в Интернете типа Copernic или отечественной WebMachine и также попытайтесь найти в Сети материалы по схожим проблемам. Либо воспользуйтесь поисковиками типа Yahoo или Google. Искать следует не только на обычных веб-страницах, но и в конференциях UseNet - именно там часто сосредоточена самая ценная информация.
Загляните на сайт www.techadvice.com - там собрана неплохая коллекция ссылок на статьи, посвящённые устранению конкретных сбоев. Почитайте же, наконец, FAQ"и на сайте журнала Upgrade!!!
Посетите сайт разработчика сбойной программы или устройства - возможно, он знает о проблеме и предлагает какой-нибудь патч.
Откройте, в конце концов, документацию к сбойной программе или плате расширения!
После вышеобозначенных мероприятий, не увенчавшихся успехом, зайдите на какую-нибудь веб-конференцию, например, на конференцию журнала Upgrade и, предельно подробно сформулировав описание «глюка» и конфигурации своей системы, попробуйте узнать мнение других пользователей - возможно, кто-то уже знает решение либо может подсказать направление дальнейших поисков. Попытайтесь вспомнить, после каких действий появился сбой.
Полностью удалите сбойную программу и либо откажитесь от неё, либо установите заново, желательно - самую свежую версию (либо наоборот - более старую)
Удалите несколько программ, которые вы устанавливали последними - возможно, какая-то из них вызывает сбой системы или конфликтует с другими программами и оборудованием, вызывая их сбои. Непременно используйте качественный специализированный деинсталлятор при установке и удалении программ - только так можно полностью очистить систему от всех следов удаляемой программы или драйвера!
Проверьте в Панели Управления все настройки системы и проконтролируйте установки в опциях используемых приложений - установите все в положение «По умолчанию». Отмените ограничения размера файла подкачки, проверьте, достаточно ли места на диске.
Верните в исходное состояние настройки в реестре, в конфигурационных файлах USER.INI, SYSTEM.INI и MSDOS.SYS, сделанные с помощью утилит типа WinBoost, MTU Speed. Проверьте установки AUTOEXEC.BAT и CONFIG.SYS. Запустите поиск в реестре по слову «Policies» и удалите все параметры в найденных разделах - возможно, ваш сбой - всего-навсего ограничение прав пользователя.
Обновите систему и поставьте свежие «заплатки» на сайте Windows Update . Обновите Internet Explorer. Учтите, что установка IE версии 5.5 и выше на Windows 98 чаще всего, к сожалению, сопровождается «глюками», так что есть смысл оставить старую версию браузера.
Обновите DirectX. Иногда оказывается полезным сначала удалить DirectX специальной программой, а потом поставить его заново. Впрочем, есть и такие дистрибутивы, которые сами полностью переустанавливают DirectX, даже если установлена более свежая его версия - их объём около 25 мегабайт, а в названии файла присутствует слово «REDIST»: DX8a_Redist.exe.
Некоторые проблемы загрузки (возникшие из-за воздействия вируса, например) устраняются, если заново сделать диск С: системным, загрузившись с компакт-диска Windows 9х и выполнив команду «SYS C». Восстановите главную загрузочную запись жёсткого диска (MBR) командой «FDISK /MBR», если она оказалась повреждена. Разумеется, проверьте систему свежими антивирусами.
Удалите все временные файлы, очистите кэш браузера, Корзину, Журнал, очистите папку C:\Program Files\Internet Explorer\PLUGINS с плагинами IE. Очистите папки, из которых производится автозапуск скриптов MS-Office (типа C:\WINDOWS\Application Data\Microsoft\Excel\XLSTART, C:\WINDOWS\Application Data\Microsoft\Word\STARTUP), удалите шаблон NORMAL.DOT, используемый MS-Office. Очистите папки C:\WINDOWS\Downloaded Program Files, C:\WINDOWS\APPLOG, C:\WINDOWS\NETHOOD, C:\WINDOWS\PRINTHOOD, C:\WINDOWS\RECENT. Удалите файлы AUTORUN.INF со всех локальных дисков.
В случае с драйвером - загрузите ПК в режиме защиты от сбоев, удалите проблемное устройство и после загрузки в обычном режиме установите самый свежий драйвер. Впрочем, иногда как раз более старый драйвер оказывается более стабильным, так что попробуйте разные версии. Учтите, что устранению «глюка» иногда способствует использование вместо перезагрузки полного выключения ПК и последующего его включения через несколько минут обесточенного простоя. Если «глюк» имеет какое-то отношение к сети, то в свойствах Сети удалите все сетевые компоненты и после перезагрузки поставьте всё необходимое заново. Удалите все принтеры, если с ними есть проблемы, и тоже после перезагрузки переустановите их драйвера.
Обновите все драйвера всех устройств, в особенности - драйвера, что идут в комплекте с материнской платой, а ещё точнее - драйвера чипсета (Intel INF Update + Intel Ultra ATA Storage Driver либо VIA-4-in-1 + прочие драйвера и патчи от VIA).
Попробуйте вернуть в исходное - «Default» - состояние настройки в BIOS, поэкспериментируйте с разными опциями, например, отключите DMA, уменьшите тайминги памяти, отключите интегрированные устройства, включите «дыру» в районе 15 мегабайта памяти. Обновите BIOS. И откажитесь от разгона!
Установите в CMOS Setup параметр PnP OS Installed = NO и отключите ACPI, чтобы распределением ресурсов заведовал BIOS, а не ОС. Отключите в CMOS Setup всё, что касается управления питанием. Либо наоборот - включите все эти опции, если они отключены.
Проверьте исправность оборудования, правильность установки перемычек на нём, протестируйте его с помощью таких утилит, как Memory Test , CPU Stability Test и им подобных. Проверьте всё, вплоть до батарейки, напряжения блока питания и качества крепления материнской платы - никаких спонтанных замыканий или ненадёжных контактов нигде не должно быть! Включите в файле CONFIG.SYS проверку памяти драйвером HIMEM: DEVICE=C:\WINDOWS\HIMEM.SYS /VERBOSE /TESTMEM:ON. Временно замените все модули памяти - именно она является тем устройством, которое сбоит чаще всего. Проверьте температуру и работоспособность устройств охлаждения всех компонентов системы! Заземлите ПК, установите сетевой фильтр или источник бесперебойного питания. Проверьте качество телефонного кабеля, сетевого кабеля, электрической разводки.
Переставьте проблемное устройство в другой слот, в свойствах системы проверьте отсутствие конфликтов, переназначьте вручную прерывания (или ещё и другие ресурсы, например, каналы DMA или диапазоны I/O). Попробуйте заменить проблемное устройство на точно такое же, либо на устройство другой марки - возможно, у вас просто бракованный экземпляр, или смена производителя платы расширения устранит конфликт. Для дисков попробуйте другой шлейф, вместо 80-жильного шлейфа попробуйте 40-жильный и наоборот, проверьте правильность установки перемычек мастер-слейв, переставьте диск на другой шлейф, установите для него в CMOS Setup либо режим автоопределения, либо задайте его параметры явным образом, либо установите для него «NONE». Не подключайте на один шлейф с проблемным диском другие устройства.
Удалите все дополнительные устройства из ПК, в Свойствах Системы удалите в режиме защиты от сбоев их драйвера и посмотрите - не пропал ли «глюк». Если пропал, то устанавливайте их обратно по-очереди и каждый раз повторяйте процедуру, приводящую обычно к появлению сообщения об ошибке - возможно, имеет место какой-то аппаратный конфликт и таким способом вы либо выявите его источник, либо система заново распределит ресурсы и сама его устранит.
Загляните в свойства проблемного устройства - возможно, там имеются настройки, использование которых устранит сбой, например, для диска отключите или включите режим DMA. На вкладке «Быстродействие» - «Файловая Система» - «Неполадки» («Perfomance» - «File System Properties» - «Troubleshooting») меню свойств системы можно, установив флажки, отключить некоторые функции, которые иногда бывают причиной неполадок. Аналогичная вкладка, предназначенная для устранения некоторых проблем, имеется в программе настройки системной конфигурации System Configuration Utility (C:\WINDOWS\SYSTEM\MSCONFIG.EXE): «Общие» - «Дополнительно» («General» - «Advanced»). Если компьютер не загружается, то доступ к этим меню попытайтесь получить из Режима Защиты от Сбоев (Safe Mode).
Если готового рецепта найти не удалось, никакие настройки не помогли, и обновление ПО не принесло результата, то придётся диагностировать систему. Просканируйте для начала диск и ОС для выявления всевозможных ошибок программами типа:
- ScanDisk или Norton Disk Doctor - они проведут поиск сбойных мест на винчестере и ошибок файловой системы, с обязательным включением тестирования записи. Если, например, невозможно загрузить Windows даже в режиме Safe Mode, попробуйте «вылечить» посыпавшийся диск тем же ScanDisk из-под MS-DOS.
- System File Checker - поиск испорченных или подменённых системных файлов в Windows 98. Не забудьте сначала в опциях программы включить поиск изменённых файлов! При изменении файлов проверяйте, чтобы устанавливаемая версия была новее предыдущей - если вдруг на диске оказалась версия файла более старая, чем в дистрибутиве Windows, то восстановите «родной» файл.
- Norton Win Doctor - поиск ошибок в реестре. Не доверяйте программе автоматически исправлять ошибки, постарайтесь сами определить лучший метод их устранения. Для этого надо попробовать выяснить, к какой программе относится запись в реестре, просмотрев самостоятельно ту ветвь, о которой сигнализирует WinDoctor - иногда по названиям файлов, по прописанным там путям, или названиям элементов ActiveX несложно установить приложение, породившее ошибку. Если эта программа удалена, то и запись в реестре можно стереть, если же нет, то надо выяснить причину ошибки и устранить её: чаще всего встречается просто неправильный путь к файлу, который надо исправить.
Попробуйте использовать и другие специализированные диагностические утилиты, например, такие как DirectX Diagnostic Tool из состава Windows - проверка файлов DirectX, драйверов, настроек некоторых устройств. Проверьте систему мощнейшим информационным пакетом SiSoft Sandra . Некоторые «глюки» устраняет программа TweakUI, для этого в ней предусмотрена вкладка «Repair».

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

Registry Monitor - анализ обращений к реестру,
File Monitor - мониторинг обращений к файлам,
DllView - информация о библиотеках, используемых текущими процессами,
OpenList - сведения обо всех открытых файлах,
PortMon - обращения к портам,
VxD Monitor - анализ загруженных драйверов,
TCPView - информация о соединениях по протоколу TCP,
TaskInfo 2002 - отображение всех запущенных программ.

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

Если при загрузке в Режиме Защиты от Сбоев (Safe Mode) проблема пропадает, что чаще всего и бывает, то можно попытаться выявить причину сбоя, если приблизить нормальный режим к Режиму Защиты От Сбоев, отключая некоторые устройства, отменяя запуск фоновых программ, предотвращая загрузку потенциально «глючных» драйверов и используя драйвер стандартного VGA-видеоадаптера. То есть надо попробовать методом исключения определить, в чём источник проблемы. Для этого надо в стартовом меню (вызывается нажатием кнопки F8 при загрузке компьютера), выбрав режим пошаговой загрузки («Step-by-Step Confirmation»), обойти файлы конфигурации AUTOEXEC.BAT и CONFIG.SYS (часто неполадки возникают из-за менеджеров памяти или совершенно лишних DOS-драйверов, например, EMM386 приводит к зависанию ScanDisk при загрузке русской версии Windows), отключить драйвера Windows, а также предотвратить автозапуск всех фоновых программ. Такие программы запускаются не только из меню «Автозагрузка» кнопки «Пуск», но и из реестра: ключи

HKEY_LOCAL_MACHINE\Software \Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software \Microsoft\Windows\CurrentVersion\RunServices
HKEY_USERS\.DEFAULT\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

и из файла WIN.INI: строки «LOAD» и «RUN» раздела . Удобнее всего для этого пользоваться утилитой MSCONFIG.EXE - в «Миллениуме» она умеет отменять даже загрузку VxD-драйверов. Не забудьте и про ещё один файл, из которого могут запускаться некоторые программы - WINSTART.BAT. Выбрать стандартный VGA-видеоадаптер надо на вкладке «Дополнительно» («Advanced») программы настройки конфигурации системы MSCONFIG.EXE (это делается в режиме защиты от сбоев, если система не хочет грузиться нормально). Если проблема возникает при выходе в режим MS-DOS, то проверьте файл DOSSTART.BAT, из которого грузятся DOS-драйвера и программы при переходе в DOS.

Как это всё выглядит на практике, если говорить немного проще? Например, вы регулярно получаете такой привет от «Виндов»:

«Программа EXPLORER вызвала ошибку такую-то в модуле таком-то.DLL по адресу такому-то». Сразу же загрузите режим «Safe Mode» и повторите все операции, приводящие к такому «глюку». Если «глюк» не появился, то проблема, скорее всего, вполне решается. Перезагружайте ПК, выбрав теперь режим пошаговой загрузки, и обходите файлы AUTOEXEC.BAT и CONFIG.SYS - опять повторяйте процедуру вызова сбоя, и если всё нормально, то ищите виновника всех проблем в этих файлах. Если же система по-прежнему выдаёт сообщение об ошибке, то вызывайте утилиту MSCONFIG.EXE и отменяйте автозагрузку всех модулей, прописанных в реестре, а заодно и уберите все ярлыки из папки «Автозагрузка» (MSCONFIG умеет делать и это), снова перезагружайте ПК и повторяйте всё ту же процедуру вызова «глюка». Следующий этап - отмена загрузки программ из WINSTART.BAT, WIN.INI. Опять проверяем, не пропал ли сбой. Затем выставляете в том же MSCONFIG.EXE на закладке «Дополнительно» режим VGA - на тот случай, если конфликтует видеокарта. И, наконец, остаётся искать причину всех несчастий в драйверах виртуальных и не совсем виртуальных устройств. При загрузке Windows в пошаговом режиме отмените загрузку «виндовых» драйверов - это VXD-файлы, либо файлы с расширениями «.386», «.DRV», которые грузятся в самом конце. Пропал сбой - отменяйте «глючный» драйвер. В реестре вы найдёте его в качестве значения параметра «StaticVXD» где-то в разделе

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD

либо поищите вызов этого файла в SYSTEM.INI. Программа конфигурирования системы MSCONFIG.EXE из состава Windows Me, как я уже говорил, позволяет очень удобно отменять не только всю автозагрузку, но и показывает на одной из своих страниц все VXD-драйвера, в Win98, к сожалению, придётся либо полазать в реестре вручную, либо взять MSCONFIG из «Миллениума».

Необходимо проверить ошибки, возникающие при загрузке ПК и инициализации драйверов по отчёту в файле C:\BOOTLOG.TXT, для чего удобно воспользоваться программами RegRepair 2000 (http://www.easydesksoftware.com/down.htm ) или Boot Log Analyser (http://www.vision4.dial.pipex.com/ ).

Переустановите Windows. Помните, что при установке «Виндов» поверх предыдущей версии, сохраняются установки в реестре, поэтому, если причина «глюка» в неверных параметрах реестра, то такая переустановка, скорее всего, ничего не исправит. Попробуйте перед переустановкой системы удалить файл VMM32.VXD, в котором упакованы самые основные драйвера, используемые на вашем ПК. Можно также в свойствах системы из режима защиты от сбоев удалить всё оборудование, чтобы Windows заново переустановила все драйвера. Попробуйте запускать установку Windows со следующими параметрами: /d - запрещает использование текущих настроек Windows, хранящихся в файлах конфигурации Win.ini, System.ini и пр.

/p f - удаляет реестр Windows при переустановке из-под MS-DOS (не забудьте сделать его резервную копию!). Попробуйте разные диски с дистрибутивом ОС - возможно, ваш диск просто повреждён.

Полностью стерев «виндовые» папки C:\WINDOWS, C:\PROGRAM FILES и C:\RECYCLED и настроив конфигурацию MS-DOS (либо переразбив и отформатировав диск), установите Windows «по-голому». Иногда требуется отформатировать диск специальной утилитой от производителя винчестера.

Вот, собственно, и всё - надеюсь, конечно, что вам не придётся прибегать к этой методике, но в любом случае жду ваших советов, дополнений и усовершенствований моей технологии выявления причин «глюков» Windows. Пишите!

upgrade.computery.ru
search.support.microsoft.com/kb/c.asp
www.microsoft.com/rus/support/kbrus.htm
www.techadvice.com
windowsupdate.microsoft.com
www.aha.ru/~alegr/download/memtest.htm
www.saunalahti.fi/jv16/download.html
www.sisoftware.demon.co.uk/sandra
www.sysinternals.com
www.iarsn.com
www.easydesksoftware.com/down.htm
www.vision4.dial.pipex.com

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

Последовательность

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

Лог файлы программных продуктов;
Форум Microinvest и коммуникация с другими пользователями;
Техническая документация от Microinvest .

Анализ поведения программного продукта является очень важной частью для дальнейшего сервиса. В качестве примера можно указать несколько типов проблем:

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

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

Задача клиентов

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

Техническая помощь от партнеров

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

Действия со стороны разработчиков продукта

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

Процедура устранения ошибки

Нет универсального способа устранения всех возможных ошибок , но существует практика, которая помогает при реальном использовании продуктов:

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

Выполнение всех этих действий достаточно для решения повторяющихся проблем.

Другое

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

Некоторые полезные ресурсы

Документация по всем продуктам;
Форум технической поддержки Microinvest , где Вы сможете быстро получить ответ на интересующий вопрос;
Примеры автоматизации ресторанов и торговли на базе Microinvest в России и странах СНГ;
График предстоящих обучений в России и странах СНГ;