Ваші правила усунення несправностей, підхід до усунення несправностей? [зачинено]

Чи є у вас загальні правила, на які ви потрапляєте, коли ви вирішуєте складну мережеву / апаратну / програмну проблему?

Наприклад: "Я ізолюю джерело проблеми, тестуючи периферійний пристрій за допомогою другого комп'ютера" або "Я видаляю стільки обладнання, скільки можливо для живлення пристрою, а потім додаю назад компоненти по одному, поки я не зможу відтворити проблему" тощо.

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

1. Яка ваша основна мета ? Слід зазначити чітко та стисло. Мета повинна бути дуже конкретною. Це не повинно бути загальним. Переважно одне речення .
   
2. Що з тобою таке ?
   
3. Чи є лише одна проблема чи багато ? Якщо їх багато, вирішуйте їх по черзі.
   
4. Спробуйте відтворити проблему в різних умовах . Чи можна його відтворити у всіх можливих умовах чи ні? Це щось говорить про природу проблеми?
   
5. Якщо це нагальна проблема, чи існує рішення ? Спробуйте знайти якомога більше обхідних шляхів.
   
6. Постарайтеся зробити якомога більше здогадок про те, що є причиною вашої проблеми.
   
7. Спробуйте довести свої здогадки, експериментуйте із системою.
   
8. Будьте готові до того, що ви намагаєтесь зробити. Робіть по одній справі.
   
9. Слідкуйте за тим, що ви робите, що ви вже пробували.
   
10. Не відхиляйтеся від своєї основної мети. Постійно перевіряйте, чи все-таки ви вирішуєте основну проблему, а не іншу.
    
11. Не фіксуйте жодного.

Також був чудовий список правил налагодження, він був у формі PDF з додатками та поясненнями для кожного з правил. Не вдалося швидко знайти PDF, але я думаю, що це плакат списку:

• Якщо проблема пов’язана з Інтернетом, можливо, це DNS.

• Якщо проблему важко діагностувати, ймовірно, це оперативна пам'ять.

• Якщо проблема пов’язана з робочою станцією Windows, можливо, швидше переробити її.

• Якщо проблема в п’ятницю, це, мабуть, щось серйозне.

Мені подобається повернутися до наукового методу .

З ( http://en.wikipedia.org/wiki/Scientist_method )

1. Визначте питання
2. Збирайте інформацію та ресурси (спостерігайте)
3. Форма гіпотези
4. Виконайте експеримент та збирайте дані
5. Проаналізуйте дані
6. Інтерпретувати дані та робити висновки, які служать відправною точкою для нової гіпотези
7. Результати документа

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

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

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

У O'Reilly є хороша книга Інструменти усунення несправностей у мережі, яка має набір кроків, які слід виконати, що дуже схоже на науковий метод. Я вважав книгу дуже корисною і настійно рекомендую. Книга детальніше описується та пропонує багато корисних інструментів.

З Інструментів усунення несправностей у мережі

1. Сформулюйте свою мету
2. Визначте систему
3. Визначте можливі результати
4. Визначте і виберіть те, що вимірюєте
5. Якщо необхідно, визначте параметри тесту та фактори
6. Виберіть інструменти
7. Встановити обмеження вимірювання
8. Перегляньте експериментальний дизайн
9. Збір даних
10. Проаналізуйте дані

Дивись також:

• 3COM має посібник з усунення несправностей
• Закон Мерфі - все, що, можливо, піде не так.
• Occam's_razor - за інших рівних умов найкраще найпростіше рішення.

(Ці основні моменти парафразовані з розділу "Налагодження" розділу "Практика системного та мережевого адміністрування" )

Слід знати дві речі:

1. Знайте, як виглядає "фіксована" версія. Переважно команду, яку можна виконати, яка дає певний вихід, коли справи працюють. Наприклад: я намагаюся з’ясувати, чому SSH запитує пароль, коли я правильно встановив ключі (або я так подумав). Тож мій тест такий: "ssh servername uptime", і він повинен працювати, не запитуючи пароль.

2. Опишіть проблему на потрібному рівні. Користувач, який скаржиться, що не може пінг-сервера, не повинен надсилати вас запускати та виправляти сервер. Завдання людини - не сидіти і пити автомат цілий день. Вони хочуть виконати якесь завдання, як використовувати машину як свій DNS-сервер. Приклад: Одного разу користувач поскаржився, що не може пінг машини на півдорозі. Я проводжу день, відстежуючи сисадміни в тій частині компанії, щоб з’ясувати, що не так у цій машині. Це було знято з експлуатації, і вони були в паніці, бо думали, що, можливо, вони вимкнули неправильну машину. Я зв’язався з користувачем і сказав: "окрім того, що потрібно писати цю машину, що б ви хотіли з цим робити?". Виявилося, що він хотів би виконати певну роботу на ньому, і якби він дотримувався належної процедури, його завдання були б автоматично перенаправлені на машину заміни. Я витратив цілий день і час місцевих сисадмінів. Ще одна причина "Я не можу пінг" - це не те, що потрібно тестувати: часто брандмауери налаштовані на викидання пакетів ping, але дозволяють пропускати інші пакети. Перевірте, що ви хочете пройти.

Дві стратегії:

1. Добавка: продовжуйте додавати компоненти, поки проблема не почнеться. Останнє, що ви додали, - це проблема. Приклад: веб-браузери не можуть спілкуватися з сервером. Між сервером і користувачем знаходиться балансир завантаження, брандмауер, кеш-пам'ять та локальний веб-проксі. Спершу спробуйте надсилати запити безпосередньо на сервер, потім через LB на сервер, потім через брандмауер на LB на сервер і т. Д. І кожен раз, додаючи один компонент.

2. Віднімання: продовжуйте видаляти компоненти, поки проблема не зникне. Останнє, що ви усунули, - це проблема: Приклад: Машина з десятками карт не завантажиться. Зберігайте картки, поки машина не завантажиться.

Два шматочки тупого удачі:

1. Забудьте все, що я сказав. Проблема викликана останньою зміною, внесеною до системи. (це працює 99% часу ... проблема полягає в тому, що 99% часу ви не знаєте, що насправді була остання зміна)

2. Коли все інше не вдається, перевірте , чи немає дурних речей. http://whatexit.org/tal/mywritings/dumb-things-to-check.html Приклад: шалену проблему просто неможливо пояснити. Потім ми перевірили файл конфігурації: користувач редагував його, скопіювавши його у вікно Windows, відредагувавши його, а потім скопіювавши його назад. Тепер він мав ^ M в кінці кожного рядка. Ми ніколи не помічали, тому що наш текстовий редактор мовчки приховував цей факт. На жаль, програмне забезпечення, яке читає файл конфігурації, перетворило ці ^ Ms у нерозривний простір, який накрутив багато інших процедур.

Загальні практики, які я пам’ятаю протягом усього процесу:

1. Запиши все, що я роблю.
2. Внесіть лише одну зміну за раз.
3. Якщо можливо, скасуйте зміну, перш ніж спробувати іншу, якщо не буде досягнуто певного прогресу.

Під час усунення несправностей тут визначається моя основна методологія:

• Коли система працює і працює, перш ніж з’явиться проблема, я намагаюся навчитися бачити, що це робить. Джо Річардс пояснює, чому набагато краще, ніж я міг у цьому короткому просторі .
• Почну з найпростішого рішення. Наприклад, немає підключення до мережі? Перевірте фізичний шар. Я не можу вам сказати, скільки разів переривчасті проблеми з підключенням не були проблемою із сервером, а з мережевим кабелем, який був напівздійсненим, або з помилкою.
• Я намагаюся зафіксувати всі симптоми, які я бачу з усіх вірогідних джерел, перш ніж почати вносити зміни.
• Я проходжу попередні діагностичні тести. Наприклад, коли мені повідомляють, що сервер не працює, перше, що я роблю, - це використовувати ping і nbtstat (Windows), щоб перевірити це. Проблема може бути в віддаленому кінці (запозичити стару приказку з технічного контролю ВВС).
• Я не боюся робити дослідження. Google, support.microsoft.com, eventid.net та подібні веб-сайти є вашим другом.
• Я не боюся просити допомоги у громади. Не лише такі сайти, як serverfault.com, але у мене є гарний асортимент людей, яким я довіряю та поважаю у Twitter, з якими я підтримую контакт.
• Я оцінюю відповіді, які я знаходжу, з тим, що бачу. Я не вважаю, що будь-яке одне рішення є правильним, доки я не можу зробити достатньо міркувань доказів, які я бачу, про що повідомляється у рішенні.

Ставлення, яке я намагаюся притримуватись:

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

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

Способи, які я думаю про усунення несправностей:

• Системи мають багато частин, якщо вони з'єднані разом або налаштовані випадковим чином, тоді вони не працюватимуть за бажанням. Є одна-дві дуже специфічні конфігурації, які будуть працювати - з усіх мільйонів способів набивати цеглу та метал, лише кілька - це мости, і лише один-два - досить хороші мости. Причиною може бути символ у текстовому файлі або невдалий сервер, але кожна частина повинна бути правильною, щоб вся справа була правильною. Мені потрібно бути готовим бути ретельним і ретельним, якщо потрібно. Системи не можуть робити "шоу має продовжуватися".
• Ви починаєте з цілої системи, як карта, уявляєте, що хмара ймовірностей пливе над картою, що представляє "де проблема", і ваше завдання полягає в тому, щоб використовувати досвід і знаходити тести, щоб відштовхувати ймовірність від одних областей і до інших, і щоб ущільнити його до точок, які є проблемними місцями з високою ймовірністю, а потім атакувати їх. Це повертається до причини та наслідків - проблема в системі, це не магія. Це проблема, яка існує, тому вона повинна десь існувати.
• Налаштувати все можна будь-яким чином, хто хоче. Єдиний спосіб, як ми можемо визначити одну поведінку як "ОК", а іншу як "проблему", тому що те, що хтось отримує, - це не те, чого вони хочуть. Ви повинні розуміти, чого вони хочуть, що вони отримують чітко і конкретно.

Процес усунення несправностей:

• В чому проблема. Переконайтесь, що ви бачите, що це відбувається, і зможете відтворити його самостійно, щоб не було жодної комунікації. Тож часто проблеми виникають через декількох людей у ​​нашій службі технічної допомоги до моменту, коли вони потрапляють до мене, і все ще ніхто не може мені пояснити, у чому проблема.
• Це рекурсивна бісекція знову - розділяйте і перемагайте, двійковий пошук - ви придумали тест, який доведе, чи проблема в цій стороні тесту чи тієї сторони, і зробить тест, щоб він максимально усунув. Повторіть, поки не вирішиться.
• Не вчіться, чи зможете цього уникнути - краще заблокувати обліковий запис бази даних і довести, що проблема все-таки виникає, коли база даних не задіяна, ніж витрачати години на вивчення, як використовується база даних.
• Це занадто просто, щоб знайти себе, думаючи, що "я не знаю, що робити далі". Зверніть увагу, коли це станеться, і поверніться до розробки тестів, які визначають проблему.

Інтернет не працює? Перевірте проблему, знайдіть веб-сайт, на який вони не можуть потрапити. Швидкі тести включають їхнє підключення до Інтернету (працює), чи завантажується воно для мене (ні). Швидкі тести вказують на те, що це сайт. Бачачи, що ця проблема трапляється зі мною, я швидко відштовхнув цю ймовірність від їхнього ПК, браузера, DNS, брандмауера офісних кабінетів користувачів тощо.

Отже, сайт не завантажується, що тепер? Це ще не можна виправити, тому шукайте місця, щоб вирішити проблему на менший. Сервер увімкнено? Це пінг? чи працює DNS? Так. Чи відповідає служба на порту 80? Ні. Чи працює служба? Ні. Це починається? Ні. Це помилки в журналі подій / журналах подій? Так! Що вони кажуть?

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

Викресліть шматки "речей, яких не може бути" якомога більше.

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

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

Я думаю, що це вміння, а не наука. Бувають випадки, коли ви йдете неправильним шляхом, але здебільшого:

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

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

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

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