Методики діагностики несправностей, Книги та статті, Різне, статті

Єрко Віктор

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

До самого останнього часу мало хто звертав увагу на ту обставину, що спілкування з ЕОМ провадиться до зміни самих людей, їх вчинків, звичок, характерів і навіть доль.

На наших очах народжується нове соціальне явище-homo computerus, що в перекладі з латинської означає “людина комп’ютеризований”. Але ідилія не вічна.

Пожежа! В бухгалтерії “поламалася” база даних. Файловий сервер на іншому поверсі летить до біса, документи тамтешніх користувачів летять туди ж. Малопомітна помилка привела до несумісності використовуваного на робочому місці програмного забезпечення. В результаті помилка “вішає” систему, комп’ютер відпочиває, а користувачі метаються в паніці з криками: “Нехай хоч 100 помилок лиш би комп’ютер працював!” (Завтра здавати замовлення, у величезній черзі стоять клієнти, не запускається улюблена іграшка і т.д.). Супроводжуючі програмісти весь свій день зайняті гасінням великих і маленьких загоряння і до кінця дня описані нижче методи лікарської діагностика можна, застосовувати до них.

Якщо реакція комп’ютера на дії користувача виявилася для вас несподіваною – це хороший привід зупинитися, подумати, проаналізувати дії користувача, пошукати в них те, що призвело до дивної реакції комп’ютера. І краще це робити не в змозі “гарячки”, в яку ви впали, а з холодною головою. Не потрібно намагатися піддати комп’ютер, молот безладно по клавішах. Придбайте стійку впевненість в тому, що комп’ютер правильно реагує на правильні команди. На жаль, людська психіка влаштована так, що допустивши одного разу помилку, користувачі схильні повторювати її знову і знову (Вам, напевно, знайомі так звані “очні помилки”, коли неправильне написання слова при читанні постійно не виявляється). В таких ситуаціях треба або на час відволіктися, або спробувати пояснити і про демонструвати комусь вашу проблему. Часто цього буває достатньо для того, щоб все зрозуміти самому.

Більшість причин збоїв виявляються дуже простими, коли, нарешті, зумієш їх вирахувати. Збої і зависання виявити легко, логічні помилки набагато складніше. Дуже часто на робочому місці встановлено кілька програмних та апаратні коштів, і помилка може критися в будь-якому з них або взагалі де-небудь на їх стику. Попередній збій “ховав” за собою іншу несправність, більш серйозну, яка тепер вилізла на поверхню і загрожує нам зривом, технологічного процесу. Користувачі отять виявили все нові і нові способи звести програму з розуму. Багато в чому це не наука, а мистецтво.

Більш ніж 10-річний досвід спілкування з комп’ютерами спонукає мене поділитися з вами деякими міркуваннями про відносини між користувачами і комп’ютерами. Виконання комп’ютером досить складних програм сприяє виникненню (особливо у новачків) ілюзії розумності його поведінки. З часом, звичайно, вона зникає, стає зрозуміло, що комп’ютер не складніший, ніж вкладені в нього програми. Але на перших порах! … Так от, працюючи на комп’ютері, користувачі ні на хвилину не повинні забувати, що перед ними машина і тільки машина, що вони мають справу з неживим предметом. “Немає нічого легше” – Подумаєте ви. Однак мій досвід показує, що це зовсім не таке просте і абсолютно необхідна умова для встановлення “правильних” відносин користувача з комп’ютером.

До того, як програма з’явиться на робочих місцях користувача, вона проходить декілька стадій – альфа версію, що представляє собою абияк працює скелет програми, і потім бета-версію, яка вже має робити, все, що від неї вимагається. До етапу бета-версії тестуванням програми займається лише кілька людей, проте, на етапі “бета” до них підключається ще не думка дюжини фахівців з відділу контролю якості. Зазирнувши до них у будь-який час доби, в будь-який день, ви застанете кілька людей за роботою. Ви, напевно, думаєте, що це не така вже і, погана, робота, тим більше, що за неї платять гроші. Однак мушу вас розчарувати: так, вони працюють з новими програмами, а й постійно знаходять помилки.

В Україні спостерігається дещо інша ситуація. Десь за десятки, сотні кілометрів знаходиться розробник або група розробників, на місцях застосування ПО створюються гуппі з 2-3 програмістів які й виконують функції бета-тестерів разом з користувачами. Від знань та умінь яких швидко локалізувати причину збою і залежить працездатність даного робочого місця або цілого технологічного процесу. Особливо це характерно для організацій з розгалуженою мережею відділень.

Дві основні завдання стоять перед практикуючим програмістом – розпізнати причину несправності (поставити діагноз) і мінімізувати наслідки. Можна виділити три шляхи, слідуючи якими програміст може забезпечити високу якість своєї роботи:

Якщо ці рядки попадуться на очі лікаря, то, швидше за все він вважатиме, що вони написані ненормальним людиною. Лікарські методики діагностики розроблялися для лікування людей та інших живих істот і людина пропонує застосувати їх до бездушному залозу, а тим більше до невагомому, абстрактного програмного забезпечення, здається, щонайменше, злегка звихнулися. Однак мене зрозуміють ті, хто весь свій робочий день присвячує роботі з користувачами і вирішення їх проблем.

У навчанні програмістів, як вузівському, так і пост дипломному, основна увага приділяється мовам і методам програмування велика частина часу йде на накопичення і розширення інформації. Про методах діагностики помилок згадується в ковзаючи. Існуюча система підготовки програмістів працює з величезним дефіцитом методик і знань пошуку несправностей. Мало часу приділяється навчанню методам переробки інформації, зокрема методам діагностики логічних помилок. Якщо за діагностикою помилок при написанні програми стежить компілятор то вважається, що з умінням шукати логічні помилки ви повинні народиться інакше не навіщо сунуться в програмісти. Діагностика помилок на робочих місцях користувачів знаходиться на рівні медицини середньовіччя. Тоді лікарі вже мали поняття про основні функції людського організму, але все одно причиною всіх хвороб вважалася погана кров, яку потрібно випустити. На відміну від людини основні “вузли” і “software” якого сформувалися кілька мільйонів років тому. Робоче місце користувача відрізняється величезним розмаїттям апаратних і програмних засобів та їх взаємодій. Тому дати конкретні рекомендації дуже і дуже складно. У першу чергу розраховуйте на свій розум і кмітливість.

Оскільки ми не чарівники, а все ще вчимося, то мова ми поведемо не про приголомшливих уяву чудеса, що дозволяють створювати безпомилкові програмні системи, а про невеликі, але корисних прийомчики “чаклунства”, допомагають швидко встановити причину помилки і намітити шляхи її усунення. Джерелом виняткових ситуацій можуть бути як помилки в програмі, так і не вірні вхідні дані, що задаються користувачем, зовнішня середа, в якій працює програма.

Процес встановлення причини несправності (діагнозу) в практиці програміста, і зокрема виявлення логічних помилок безпосередньо на робочих місцях користувачів, можна розглядати як окремий випадок проблеми прийняття рішень. У цьому зв’язку слід спиратися і використовувати положення добре розробленої в психології теорії прийняття рішень. Відповідно до цієї теорії, діагностування являє собою рішення задач з ризиком, тобто такого класу ситуацій, в яких є невизначеність щодо можливого одержуваного результату.

Людина, вирішальний такі завдання, в даному випадку супроводжуючий програміст інтуїтивно використовує певну стратегію правил мислення яка вже свідомо застосовується лікарями в їх роботі. Спробуємо застосувати ці методи для виявлення причин несправностей на робочих місцях користувача.

Як приймається рішення про діагноз? Принципи і методи діагностики

Розрізняють два принципи діагностичного мислення – нозологічний і синдромний.

Нозологічний принцип передбачає постановку діагнозу шляхом зіставлення симптомів несправності, виявлених на робочому місці, з симптомами конкретних несправностей (нозологічних одиниць), що зберігаються в пам’яті програміста.

Синдромний принцип – Це розпізнавання і розмежування несправностей, коли розумові операції проводяться тільки з тими групами аварійних станів або збоїв, які проявляються єдиним провідним синдромом. У сучасній літературі більш раціональним і надійним визнається другий принцип, оскільки синдроми значно відрізняються один від одного, кількість їх відносно невелика. Це полегшує діагностику синдромів і звужує коло діагностичного пошуку конкретних нозологічних форм. До методів діагностики відносять метод обгрунтування діагнозу і метод диференціального діагнозу.

Метод обгрунтування діагнозу (Діагноз за аналогією, іноді по інтуїції з урахуванням ознак) – це послідовне зіставлення симптомів на даному робочому місці з ознаками відомих програмісту несправностей. Якщо зазначається збіг двох-трьох симптомів, діагноз стає ймовірним, якщо збігається більшість симптомів – діагноз стає достовірним, обгрунтованим.

Метод диференціального діагнозу – Це розпізнавання несправностей за допомогою виключення тих процесів і причин, для яких не характерні ознаки, виявлені на даному робочому місці. У міру послідовного виключення коло ймовірних причин зменшується, поки не залишається одна причина – найбільш ймовірна.

Для достовірної діагностики необхідно використання обох методів, але найбільш раціональна така методика, коли розпізнавання причини починається і до останніх етапів триває переважно на основі диференціальної діагностики, і лише коли залишається розмежувати 2-3 нозологічних одиниці, слід застосувати метод обгрунтування діагнозу.

Принцип не нашкодь.

Зрозуміло, що не маючи досвіду – не знаєш, чого побоюватися, тому в перший час від неприємностей не вберегтися. Але поставте собі за правило намагатися прогнозувати очікуваний збиток і робити якісь дії для його запобігання або мінімізації. Робіть копії важливих даних до роботи з ними. Працюйте з захищеними від за дискетами, крім тих випадків, коли ви свідомо хочете щось на них записати. В нинішні часи вірусні підчепити заразу дуже і дуже просто.

Побутує хибна думка, що є програми, які відновлюють стерті файли. Не вірте цьому! Вдале відновлення можливо тільки в рідкісних щасливих випадках. Краще перш ніж щось знищити – подумати, ще раз подумати, ніж потім гарячково міркувати, чому “відновлена” програма не працює або де відшукати копії стертих даних. На щастя, інші операційні системи вже якщо що перуть, то назовсім.

Загальні способи обстеження

Суттєвим фактором, що відрізняє роботу програміста з користувачами від роботи з розробки програмного забезпечення, є неможливість повернутися в будь-який момент до вихідного тексту програми для перевірки отриманих даних або виявлення додаткової симптоматики. Звідси – з’ясування причин збою при роботі з користувачем повинно бути по можливості і характеру несправності вичерпним, а прийняте програмістом рішення – остаточним. Цього вдається досягти за короткий період спілкування програміста з користувачем на робочому місці тільки при дотриманні відомих умов і методики обстеження. Таким умовою є достатнє знання програмістом характеру різноманітних несправностей, причин її виникнення, особливостей перебігу, симптоматики, виявлення якої є на робочому місці користувача. Існуюча організація допомоги користувачам має зародкові допоміжні і вбудовані методи діагностики. Їх відсутність дає програмісту привід застосувати такі традиційні, але вимагають відомого часу діагностичними методами, як опитування (анамнез) і огляд робочого місця або збою ПЗ. Тим часом за допомогою цих методів вдається в більшості випадків швидко і точно поставити правильний діагноз вже при першій зустрічі з виниклою в користувача проблемою. Спеціальні методи зазвичай потрібні при цьому лише для підтвердження концепції програміста.

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

Скарги користувача

При першій зустрічі з користувачем програміст повинен вислухати його скарги. При цьому треба відокремити основні скарги від другорядних. У ряді випадків у користувача превалюють скарги на несправності, пов’язані часом з незначним несправностями, в той час як найбільш важкі збої дають менше відчуття користувачеві скаржитися, що особливо характерно для множинних і поєднаної несправності. У цих випадках відступ від схеми дослідження може привести до непоправних помилок.

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

Треба мати на увазі, що в процесі надходження скарг у програміста іноді можуть виникнути обгрунтовані сумніви в істинності отриманої інформації, пов’язані з неусвідомленим або свідомим небажанням користувача правильно орієнтувати програміста про стан несправності. У таких випадках спостерігаються такі варіанти поведінки користувача.

Симуляція – Спроба описати ознаки несправності, яких насправді не існує. Для розпізнавання симуляції програмісту можуть допомогти відомості про існування подібного збою в минулому у самого користувача або його змінників. Збіг скарг, які пред’являє сам користувач, зі скаргами передбачуваної несправності при відсутності відповідної об’єктивної симптоматики може дати програмістові підстави засумніватися в їх істинності. Користувачеві потрібно відлучиться з робочого місця, він втомився, хоче помститися програмісту і т.д.

Аггравация – Більш поширений синдром, пов’язаний з перебільшенням існуючої симптоматики. Зазвичай проявляється у НЕВРОПАТИЧНА користувачів і не переслідує мети свідомо ввести в оману програміста. Ступінь перебільшення завжди важко визначити. Єдиним критерієм є відсутність паралелізму зі ступенем вираженості об’єктивної симптоматики.

Диссимуляция – Свідоме (рідше несвідоме) затушовування чи заперечення користувачем суб’єктивних скарг. Часто диссимуляция є наслідком страху перед можливим зарахуванням користувача в ряд тупиць. Вона дуже небезпечна, особливо при несправності, які потребують термінового усунення, або призводять до значних втрат даних. Діссімуляцня являє собою реакцію користувача на ситуацію. Довести помилковість такої позиції користувачеві вдається не завжди. Достовірну інформацію для встановлення причини несправності в цих випадках дає об’єктивне обстеження. Програміст завжди повинен пам’ятати, що встановлення діагнозу “симуляція” і “аггравация” небезпечно і повинно грунтуватися на беззаперечних даних тільки після того, як будуть вичерпані всі існуючі способи верифікації діагнозу.

Психологія, логіка мислення і навіть поведінка професійних програмістів у багатьох випадках відрізняються від психології, мислення та поведінки “звичайних” людей. Спілкування з комп’ютером, розвиток логічного (Математичного) мислення виробляють звичку до чіткості, точності, однозначності. Зупинимося на деяких, до сих пір не всіма усвідомлених, особливості комп’ютерних професіоналів.

Чи цікаво вам грати в нову гру? Чи швидко ви пристосовуєтеся до нових, незвичних для вас правилами гри? Чи подобається вам отримувати несподівані результати, користуючись засобами, які на перший погляд для цього зовсім не підходять? Програмісти на ці питання зазвичай відповідають позитивно. Напевно, це не випадково. Отже, психологія, логіка мислення і навіть поведінка професійних програмістів у багатьох випадках відрізняються від психології, мислення та поведінки “звичайних” людей. Цей факт, що знаходить безліч підтверджень, можна пояснити двояко: або програмістами стають виключно люди, спочатку володіють деякими особливостями, або на їх мислення накладає отлечаток тривала професійна діяльність.

Двоє людей летіли на повітряній кулі, потрапили в бурю і заблукали. Через кілька годин вони приземлилися в зовсім незнайомому населеному пункті і, не вилазячи з кошика кулі, запитали перехожого:
Скажіть будь ласка, де ми знаходимося?
– Ви перебуваєте в кошику повітряної кулі, – відповів абориген.
– Напевно, це програміст, – задумливо сказав один з повітроплавців іншому. -Тільки програміст може дати такий абсолютно точний і абсолютно даремний відповідь.
На жаль, тривале спілкування з комп’ютерами, які самі, як правило, дають лише точні відповіді, призводить до того, що професіонали часто майже автоматично починають спілкуватися з людьми в такій же строго-марною манері. Коли професіонал задає питання користувачеві, то він розраховує на формальний, строгий, точну відповідь. Тобто він намагається сформулювати саме те питання, точну відповідь на який його насправді цікавить. Ці мільйони людей спілкуються з десятками мільйонів інших, не настільки звикли до чіткості, точності, однозначності, неухильного відповідності слів і вчинків. Це ви повинні враховувати, спілкуючись з користувачами …

Анамнез

Вислухавши скарги користувача починайте розпитування вести розпитування, користувача необхідно змусити згадати і розповісти про початок несправності або аварії, про механізм збою, його перебігу, проведеному дослідженні і результатах. Історія несправності або аварії повинна відображати розвиток або динаміку пошкодження від її початку до моменту дослідження. Окремі групи несправностей, пошкоджень мають ряд загальних ознак . Так, на робочих місцях з підозрою на постійний характер збоїв з’ясовується наявність аналогічних збоїв на робочих місцях з однотипною технікою і ПО в інших відділах. При расспросе користувача, необхідно встановити, якою фірмою виготовлена ​​техніка, чи були якісь збої в даній серії повідомлені фірмою виробником …

З’ясування механізму збою і встановлення місця і причин події мають велике значення. На підставі типового механізму несправності можна встановити у ряду несправностей безпомилкову причину. Разом з тим знання обставин збою може бути підставою для розробки профілактичних заходів, спрямованих на зниження простоїв робочого місця. Важка аварія може в найближчі години привести до повного виходу робочого місця і технологічного процесу. Тому, розпитуючи користувача про обставини, за яких стався збій, програміст може виявитися важливим і єдиним джерелом інформації для слідчих органів.

Розпитування користувача про початок і перших ознаках збою, його динаміці, що передують ремонтах повинен проводитися докладно: Є несправності і пошкодження, при яких один тільки ретельно зібраний анамнез або пошкодження дозволяє не тільки запідозрити, а й встановити правильну причину. На деяких робочих місцях з плином часу багато об’єктивні симптоми можуть зникнути і під час обстеження їх виявити не вдається. Прикладом може служити постановка діагнозу ушкодження секторів вінчестера. Якщо в анамнезі виявляється класичний механізм збою з блокуванням роботи ПЗ, характерне течія, а потім періодично повторювані збої вінчестера, то діагноз відмови секторів НDD не викликає сумнівів. Цілеспрямованим обстеженням, робочого місця необхідно лише виключити або, навпаки, виявити пошкодження секторів вінчестера.

В процесі розпиту користувача з’ясовують стан різних систем: Размер вільного місця, швидкодія, робота друкувального пристрою, клавіатури і ін Як і при всіх інших збоях, бажано зібрати (Знати) історію робочого місця. Тут виявляють: стан систем при створенні. Умови праці та виробничі шкідливості істотно можуть вплинути на функції апаратури. Завжди необхідно з’ясувати, які збої відбувалися раніше на цьому робочому місці.

Порядок обстеження аварійної ситуації на робочому місці полягає в опитуванні користувача та виявленні об’єктивної симптоматики. Опитування має бути по можливості коротким, цілеспрямованим і ставитися до тим фактам, які можуть безпосередньо вплинути на постановку діагнозу. Процес власне з’ясування причин несправності на робочому місці користувача складається з опитування (скарги, анамнез несправності), оцінки загального стану та вивчення патологічних даних (status localis). В умовах реального часу нерідко доводиться починати з вивчення об’єктивних даних, щоб обмежити обсяг зібраної інформації тільки найсуттєвішими моментами.

Огляд

Найбільш доступним і в той же час простим методом об’єктивного обстеження збою робочого місця є огляд. Загальний огляд – це важливе діагностичне дослідження. Постарайтеся добре освоїти ті інструментальні програми, якими встановлені на робочих місцях користувачів. Ви повинні розуміти, як вони працюють. Спробуйте дізнатися, які сюрпризи і підводні камені приготували вам розробники. Це вдасться не відразу, а для початківця програміста буде досить важким і тривалим процесом: він адже ще не розуміє, що може перешкодити, що добре, що погано … Поступово ви придбаєте досвід, сформуєте підхід до освоєння нових програм. Головне – домагатися ясного розуміння того, як працює програма і робоче місце в технологічному процесі. Це потрібно робити весь час, розширюючи сферу своїх інтересів, вникаючи в найдрібніші подробиці і вловлюючи найтонші нюанси. Будьте цікаві!

Правильніше було б сказати, що знайомство програміста з конкретним робочим місцем починається з огляду, а не з розпитування. Побачивши робоче місце, уважний програміст повинен помітити особливості поведінки користувача, зовнішній вигляд техніки, вимушену і незвичайну послідовність дій, порушення звичайного порядку технологічного процесу. Огляд робочого місця дозволяє виявити безліч достовірних симптомів пошкоджень і несправностей апаратури і ПО.

Проведення огляду повинно здійснюватися з дотриманням певних правил, послідовно і повно. У момент обстеження робоче місце має бути повністю доступно.

Персональні комп’ютери роблять так, щоб вони працювали як електричний праска: включив в мережу і гладь. Але це не означає, що комп’ютер не вимагає ніякого догляду. Забороніть користувачам розводити на столі, де стоїть комп’ютер, свинарник, оранжерею з кактусами. Привчіть стирайте пил і з екрану монітора, і з системного блоку і т.п

Не тягніть на комп’ютер все підряд! Не робіть з нього програмну “смітник”!. Йдеться про один із “рефлексів програміста”. Чітко визначте діапазон комп’ютерних програм для даного робочого місця. На світовому ринку персональних комп’ютерів продаються десятки тисяч пакетів програм. Таку прірву навіть тільки переглянути навряд чи можливо, не кажучи вже про те, щоб все спробувати. Висновок такий – не можна осягнути неосяжне. Крім того, чим більше програм встановлено на робочому місці користувача, тим вища ймовірність того, що ні в міру цікавий користувач запустить щось не покладене про можливість занесення в комп’ютер вірусу або троянської програми, особливо якщо програми дісталися вам через другі, треті або Бог знає які руки. Слідкуйте за версіями, не тримайтеся без потреби за старі варіанти програм. Чим більше у вас програм, тим важче підтримувати програмне забезпечення в належному порядку.

Доцільно попросити користувача виконати постійні операції. В цей час визначають можливі не вірні дії користувача і не вірну настройку тумблерів і перемикачів, установок в програмному забезпеченні. Спробуйте самому виконати дії, які викликають проблему в користувача. У цей момент ви повинні перетвориться в “професійного ідіота”. “Професійний ідіот” – це не завжди буквальна характеристика. В колективах, що створюють складні – і не тільки комп’ютерні – системи, так називають висококваліфікованих професіоналів, в чиї завдання входить знаходження слабких місць в здаваних розробках. Вони отримують у своє розпорядження систему безпосередньо перед або відразу після проходження ВТК і намагаються вивести. її з ладу законними способами.

Коли представник цієї професії візьметься за чергову модель принтера, то він, ймовірно, спробує:

Уміння перетвориться в професійного ідіота надзвичайно важлива. Саме вона дозволяє знаходити в системах місця, що мають недостатню “захист від дурня” і можливу причину збою.

“Захист від дурня”, як і вираз “професійний ідіот”, не метафора, а цілком серйозний, знайомий фахівцям термін, що стосується надійності людино-машинних систем. Це, інакше кажучи, захист від непродуманих дій при користуванні системою – скажімо, тим же принтером або нагрівальним приладом.

При неповної перевірки особливих ситуацій можливо, наприклад, що через помилка одного квиткового касира буде надовго паралізована продаж залізничних квитків у всьому місті або навіть в декількох містах. Тому як “професійних ідіотів” зазвичай використовуються фахівці з великим власним досвідом роботи по створенню складних систем. Вони можуть чуттям вловити місця, де розробник не передбачив достатнього захисту програми від малоймовірною помилки людини або обладнання.

Якщо кавоварку або інший електричний водонагрівальний прилад включити без води, прилад вийде з ладу. Тому в багатьох таких приладах передбачена “захист від забудькуватих”: якщо вода не налита, нагрівальний елемент не включається. Виробіть в собі звичку до аналізу самих неймовірних для “звичайних людей” ситуацій. Це може здатися страшно нудним. Але аналіз деяких не цілком буденних ситуацій показує, що над ними стоїть все ж поміркувати.

Сучасне робоче місце характеризується множинними поєднаннями взаємодіючих технічних і програмних засобів. Огляд таких робочих місць при повному доступі за певною схемою дозволяє уникнути перегляду найважливіших ознак несправності. Після загального огляду та виявлення провідних симптомів вивчається будова ділянок по областях. Це: монітор, системний блок, з’єднувальні кабелю, друкуючий пристрій, інша периферія, ПО. У момент первинного огляду стан робочого місця або збою сегмента апарату може бути активним, пасивним.

Активне стан робочого місця, як правило, свідчить про відносне благополуччя, коли несправність знаходиться в початковій стадії або збій не настільки значний і не вплинула на функціонування робочого місця. В діагностичному відношенні істотне значення мають пасивне і вимушене положення. Пасивне стан робочого місця найчастіше свідчить про важку несправності або пошкодженні системного блоку. Пасивне стан будь-якого сегмента апаратури буває настільки характерним, що розцінюється як симптом певного поразки. Установка перемикачів в певних положеннях часто дозволяє припустити те чи інше ушкодження апаратури або збій ПЗ. Особливу увагу треба звернути на вимушене порушення функцій і окремих частин далеко від ураженої ділянки.

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

ДИВІТЬСЯ НА ЕКРАН! Як правило, там все написано! Звичайно, це відноситься до професійних програм, призначених для масового використання. Вони побудовані дуже продумано в сенсі зручності спілкування користувача з комп’ютером. Дослідні, експериментальні, нарешті скроєні нашвидкуруч саморобні програми, безумовно, не приділяють такої уваги дизайну екрану, відбору інформації, індіціруемие на екрані, – про них я й не кажу.

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

Роботу користувачів з новою програмою краще починати з освоєння клавіатури, оскільки, на жаль, для різних програм, навіть однотипних, одні й ті ж клавіші (кнопки, панелі) мають різне призначення. Поки користувачі не навчилися користуватися клавіатурою усліпу, їм не до написів на екрані – всі сили, всю увагу йдуть на пошуки потрібної клавіші. Попутно користувач невірної рукою натискаєте ще щось, ну зовсім трохи, – у всякому разі вони цього не помічають. І нехай комп’ютер про щось попереджає, щось виводить на екран – їм не до того, вони шукають свою заповітну клавішу … Дуже дивно, що раптом екран змінив колір або з ним сталося щось жахливе! Вони все робили абсолютно правильно, точно так, як їх навчили вчора. Коротше, справжня робота з програмою починається тільки після того, як користувачі навчилися бачити те, що відбувається на екрані. Особливо яскраво це виявляється при освоєнні нової гри.

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

Скарги і об’єктивні дані повинні бути виявлені досить повно, тому що швидко змінюється у невідкладних випадках картина може пізніше утруднити правильну діагностику і визначення тактики усунення несправності.

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

Схема обстеження робочого місця

  1. Скарги і уточнення їх характеру.

  2. Початок і розвиток несправності (anamnesis morbi) і чинники, що безпосередньо йому передували. Для невідкладних станів – точне зазначення часу початку збою.

  3. Проведені ремонти та їх ефективність. Особливу увагу слід звернути на саморемонту, їх форму та тривалість. Якщо техніка на робочому місці раніше проходила технічний огляд третіх фірм, то бажано мати відомості про отримані результати та рекомендації (технічні документи, акти).

  4. Орієнтовна ознайомлення з функціональними особливостями основних систем техніки (зі слів користувача): швидкодія процесора, принтера, мережі і т.д.

  5. Коротка історія робочого місця (anamnesis vitae) з акцентом на виникали раніше аварії, що можуть зробити істотний вплив на діагнозностірованіе збою.

  6. Об’єктивне обстеження робочого місця (загальний стан індикаторів, положення тумблерів, швидкість обміну інформацією з локальними пристроями).

  7. Вивчення місцевих даних (status localis) і виявлення симптомів, властивих передбачуваної несправності.

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

  9. Призначення і проведення лабораторних і спеціальних методів дослідження.

В принципі в умовах робочого місця допустимо відступ від наведеної схеми обстеження (скарги, anamnesis morbi, anamnesis vitae, послідовне вивчення всіх органів і систем, locus morbi і т. д.).

Першочергове обстеження уражених систем або органів дозволяє значно скоротити час, необхідний для встановлення причини несправності і надання раціональної допомоги, особливо при локальних несправності. Однак при існуванні труднощів у правильній інтерпретації отриманих даних необхідно точно дотримуватися наведеної схеми.

Методика пошуку причини збою повинна бути строго послідовною, навіть в абсолютно очевидних для досвідченого програміста випадках. Наступним положенням є перехід від менш “трав матичного” способів обстеження до більш “трав-матичного”. Очевидно, найбільш безпечним є огляд. При огляді обов’язкові наявність гарного освітлення і можливість порівняти показники індикаторів і положення перемикачів з працюючою аналогічної технікою. В процесі огляду проводиться вивчення активних рухів контактів і перемикачів відповідної частини пристрою викликала підозри. Допомога програмістів на робочих місцях користувачів передбачає обстеження для встановлення причини збою, оцінки загального стану і пов’язаної з ним ступеня ризику повного виходу робочого місця з експлуатації. Перелік обов’язкових заходів визначається характером несправності і показаним методом усунення (можливість виправлення ситуації на робочому місці, заміна окремих вузлів на резервні силами програмістів, напрямок техніки в спеціалізовані ремонтні установи).

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

Розмовляйте з іншими програмістами, що працюють з аналогічним soft і hard ware! Часто кілька хвилин такої розмови можуть коштувати тижневих власних зусиль. Виразне виклад своїх труднощів іншій людині дозволяє іноді по-новому поглянути на проблему або просто чітко сформулювати її для самого себе. Саме це найчастіше виявляється найскладнішим. Поговоріть з більш досвідченими людьми; а краще, якщо вони зможуть вам щось показати на практиці. Надалі ж, якщо з’явиться якась проблема, спочатку постарайтеся розібратися в ній за допомогою документації самі. Якщо ви будете постійно користуватися послугами друзів, чи до вас прийде впевненість у власних силах. Що легко прийшло-легко й піде. Не слід вважати, що консиліум замінить читання документації. Потрібні й самостійна робота з документацією, і спілкування з колегами. У кожному конкретному випадку тільки ваш досвід може підказати, як швидше і простіше відшукати відповідь.

При обстеженні збійної ситуації визначають не тільки причина викликала збій і показання до заміни техніки на резервну. Не менш важлива загальна оцінка несправності. У невідкладних ситуаціях, коли складності збою надається менше значення, робоче місце автоматично кваліфікується до заміни на резервні елементи. Ряд симптомокомплексов (збій жорсткого диска, відсутність ініціалізації, не можливість підключення до сервера) самі по собі можуть служити показанням до нагальних заходів і виключення робочого місця з технологічного процесу. У таких випадках в умовах робочого місця важливіше не намагатися точно встановити діагноз як причину загрозливого стану, а надати необхідну допомогу для продовження нормальної роботи на даному робочому місці.

Після накопичення інформації приступимо до розглянемо способи установки причини несправності.

Характеристика систем пам’яті

Процес прийняття рішень про діагноз, призначення заходів усунення у великій мірі залежить від характеристик пам’яті програміста, саме рішення приймається в короткочасній або оперативної пам’яті.

Довготривала пам’ять – Головне сховище знань людини. Інформація, що надходить в ДП, кодується у вигляді символів, між якими утворюються асоціативні зв’язки. Ємність ДП практично необмежена, вона вміщує в собі величезну кількість символів. Але до цієї величезної інформації немає безпосереднього доступу, її потрібно зчитувати, витягувати в короткочасну пам’ять, щоб потім там використовувати ля прийняття рішень. За даними психологічних досліджень це зчитування, вилучення інформації буде тим швидше і ефективніше, ніж більш організована, систематизована інформація в ДП.

Короткочасна або оперативна пам’ять є головною системою, де відбувається переробка інформації і, отже, прийняття рішень. На відміну від ДП ємність КП різко обмежена, в ній може знаходитися не більше 5 – 9 (7 ± 2) одиниць інформації, правда ємність цих одиниць може бути різна – сім букв, але сім пропозицій, сім симптомів несправності, але сім синдромів і т.д. Найважливіше значення КП в тому, що інформація в ній безпосередньо доступна людині. Інформація в КП надходить з ДП, навколишнього середовища, а також із зовнішньої пам’яті – ВП.

Зовнішня пам’ять є сукупністю інформації, яка знаходиться в зовнішньому оточенні людини – книги, таблиці, викладачі, комп’ютери. Ця інформація може використовуватися для прийняття рішення. Завдяки можливості використання зовнішньої пам’яті темпи людської розумової діяльності багаторазово зростають.

Роботу з новим для себе устаткуванням або новою програмою починайте с, уважного читання їх описів. При наявності деякого досвіду відразу можна визначити, що цілком зрозуміло, а що – не дуже. Новачкові ж здається на перших порах, що майже все неясно. Звичка починати роботу з чимось новим з читання документації повинна виробитися на рівні безумовного рефлексу ще й тому, що можна легко сплутати схожі контакти або з’єднувачі і перше ж включення виявиться фатальним для вашого обладнання. Вам необхідний певний світогляд. який не придбати з читанням тільки фірмової документації. Кожен автор, кожна фірма любить свій продукт і дуже привабливо описує його не тільки в рекламі, а й у своїх інструкціях. При цьому створюється враження, що єдиний правильний шлях до мети – той, який вони вам пропонують, що, очевидно, не зовсім так.

Читайте спеціальну літературу! Крім того, постарайтеся оволодіти хоча б англійською мовою. На цій мові друкують безліч різних книг і журналів, з яких ви зможете постійно черпати свіжу інформацію. Слідкуйте за рекламою! По ній за наявності деякого досвіду ви навчитеся приблизно визначати рівень пропонованої програми. Не нехтуйте комерційними оглядами ситуації на ринку.

Стратегії прийняття рішень – метод проб і помилок, алгоритм, евристики

Програміст в пошуку причини несправності для вирішення завдань використовує певну систему правил мислення. Психологи виділяють три основних види таких стратегій – випадковий перебір або метод проб і помилок, діагностичний алгоритм і дотримання певних евристика.

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

Діагностичний алгоритм – Це розпорядження і поетапне виконання в певній послідовності розумових операцій для встановлення діагнозу. Дотримання алгоритму гарантує вирішення завдань певного класу, найчастіше типових, забезпечує обов’язкову результативність пошуку.

Евристична стратегія будується на певних правилах та інструкціях, менш визначених і жорстких, ніж кроки алгоритму. Дотримання цих правил не дає повної гарантії виконання завдання, але раціонально зменшує її труднощі і тим самим полегшує її рішення. Кількість евристик – вирішальних правил – зазвичай невелика, менше, ніж в етапах алгоритму, що також полегшує їх запам’ятовування.

Останні дві стратегії мислення розвиваються найчастіше в процесі навчання. В літературі практично відсутні вказівки, в яких наводяться алгоритми діагностики багатьох несправностей. На наш погляд широке впровадження цієї стратегії лімітується двома причинами – по-перше, діагностичні завдання далеко не завжди типові, часто являють собою проблемні ситуації, по-друге, ряд алгоритмів містять велика кількість кроків, що ускладнює введення їх в короткочасну пам’ять програміста.

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

Виявлення симптомів несправності

Вирішальне правило – ретельне суб’єктивне і об’єктивне обстеження робочого місця. Це найважливіший етап діагностики. Неповне або недостатньо деталізоване дослідження нерідко призводять до помилок в діагностиці.

Усі міркування про етапи і правила діагностичного пошуку мають сенс тільки в тому випадку, якщо достатньо повно виявлені симптоми несправності.

Розпитування користувача і об’єктивне дослідження рекомендується проводити за чітким алгоритмом: скарги, їх деталізація, розпитування по системам, історія розвитку несправності, історія робочого місця, загальний огляд, об’єктивне дослідження по системам. Стан кожної з систем оцінюється також на підставі місцевого огляду.

Чим менше практичний досвід програміста, чим більш “незрозумілий” або “загадковий” збій, тим скрупульозніше треба проводити обстеження робочого місця. Разом з досвідом приходить все більше розуміння важливості обстеження робочого місця, але в той же час з’являється тенденція до феномену “згортання” деяких етапів обстеження, що веде до небезпеки “пропустити” якісь симптоми або недооцінити їх.

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

Виділення загальних і місцевих симптомів

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

Угруповання симптомів у синдроми і виділення провідного синдрому

Постарайтеся згрупувати, наскільки це можливо, виявлені симптоми в синдроми (СМ) і виділіть провідний синдром (ВСМ). В літературі немає загальноприйнятого поняття синдрому. Найбільш суворо синдром визначається як сукупність симптомів, об’єднаних загальним механізмом розвитку, характерних для ряду несправностей або одного збою з різними причинами виникнення. Більшість з виділяються в керівництві по діагностиці синдромів відповідають цим критеріям.

Є, однак, більш широке розуміння синдрому, який розглядають як симптомокомплекс, зовні єдиний для несправностей різних органів і систем, незалежно від причини. З прагматичної точки зору, в даній ситуації з точки зору діагностичного пошуку важливо, щоб в розумінні програміста симптомокомплекс розглядався як синдром, а не випадкова сукупність синдромів.

Як приклад синдрому в першій інтерпретації можна назвати синдром мережі, для якого характерні єдиний механізм розвитку (зниження пропускної спроможності мережевого обладнання), чітко визначені клінічні, і який зустрічається при багатьох несправностей різного походження.

Як приклад синдрому в більш широкому розумінні цього терміна можна навести синдром зниження швидкодії, який не має єдиного механізму розвитку. У той же час і той і інший синдроми можуть бути використані як провідні для проведення діагностичного пошуку.

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

Висування ПДГ (первинних діагностичних гіпотез) та їх ДД (диференційний діагноз), встановлення попереднього діагнозу

На підставі виділеного провідного синдрому висуваються первинні діагностичні гіпотези для прийняття рішення про попередній діагноз. Як уже зазначалося цей процес протікає в оперативній короткочасної пам’яті, тому кількість ПДГ обмежена, зазвичай їх 5-6, але якщо вдатися до допомоги зовнішньої пам’яті, то кількість ПДГ може бути великим. ПДГ можуть висуватися у вигляді припущень про конкретні нозологічних формах або про групи захворювань або синдромів.

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

Існують три принципи диференціювання:

Визначення плану лабораторного та інструментального обстеження робочого місця, виявлення симптомів за допомогою цих методів

З урахуванням попереднього діагнозу і найбільш важливих в плані прогнозу та усунення збою діагностичних гіпотез визначається план з’ясування причин збою за допомогою додаткових інструментальних методів дослідження. При цьому виявляється ряд нових симптомів.

Додаткові методи дослідження можуть класифікуватися за різними критеріями.

В залежності від способів виконання вони поділяються на лабораторні та інструментальні.

В залежності від мети виділяють методи:

Виділяють також інвазивні та неінвазивні методи, перші більш ризиковані в плані виведення робочого місця з технологічного процесу. Нарешті, є вирішальні методи, “позитивний результат” яких дозволяє відразу ставити точний діагноз. При виборі їх також корисно користуватися деякими правилами.

Загальні правила вибору методів дослідження:

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

  2. Призначення по можливості неінвазивної методики.

  3. Призначення необтяжливого для робочого місця методу.

  4. Призначення по можливості вирішального методу дослідження.

  5. Призначення мінімально необхідного для даної ситуації числа методів дослідження

Якщо виконаний вирішальний метод і поставлений діагноз нозологічної форми, то діагностичний пошук закінчується.

Угруповання раніше виявлених і знову виявлених симптомів у синдроми і виділення провідного синдрому

Симптоми, виявлені за допомогою розпитування та інструментальних досліджень, а також в результаті додаткових методів дослідження знову групуються в синдроми і серед них знову виділяється провідний синдром.

Висування ВДГ (вторинних діагностичних гіпотез), їх ДД – встановлення остаточного діагнозу НФ (нозологічної форми)

На основі знову виділеного провідного синдрому висуваються вторинні діагностичні гіпотези (ВДГ), і проводиться їх диференціальний діагноз. При необхідності можна знову повернутися назад, призначити додаткові нові дослідження.

У результаті найчастіше найбільш ймовірна вторинна діагностична гіпотеза є остаточним діагнозом опредленія нозологічної форми (НФ).

У важких для діагностики випадках може виникнути необхідність висування і третинних діагностичних гіпотез, їх диференціальний діагноз. Приводиться евристична схема позбавлена ​​”жорсткості” алгоритму, що особливо важливо при вирішенні діагностичних завдань у нетипових ситуаціях.

Формулювання розгорнутого клінічного діагнозу для даної нозологічної форми

Після встановлення остаточного діагнозу нозологічної форми формулюється з урахуванням існуючої класифікації розгорнутий діагноз.

Кожна людина, який обрав своїм професійним заняттям розробку програмного забезпечення для ЕОМ, рано чи пізно, яких би висот майстерності в цій області він не досяг, усвідомлює неспростовність невблаганного закону програмування: коли в програмі виправлена ​​остання помилка, вона стає нікому не потрібною.

І хоча автор статті завжди готовий вкотре після чергової “поломки” якої-небудь програми в абсолютно не відповідний момент, коли впав новий програмний шедевр, в серцях, вимовити перед здивованим користувачем цю виробляє враження на непрофесіонала фразу, перед тим як кинуться шукати цю “передостанню” помилку, і ще не втратив надії навчиться хай не зараз, а через якийсь час і навчиться створювати потрібні комусь програми, більш складні, ніж 2Х2, в яких не буде помилок. А кому з вас, цього не хочеться? Всім хочеться, але хто може?

Література
1.Травматологія та ортопедія Москва “Медицина” 1983
2. Довідник фельдшера Москва “Медицина” 1984
3.Компьютер і завдання вибору Москва “Наука” 1983

  

Увага! Передрук даної статті або її частини без узгодження з автором. Якщо ви хочете мати цю статтю на своєму сайті або видати в друкованому вигляді, зв’яжіться з автором.
Автор статті:  Єрко Віктор

  

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*