Як мені підходити до виправлення помилки, що не може бути відтворена / випадково виникає?

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

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

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

• Як виявляється мова? Чи ґрунтується на інформації з HTTP-запиту? Чи заснована вона на інформації про сеанс ?, чи базується на полях бази даних? По суті, чи може це бути проблемою, пов’язаною з тим, як програма вибирає мову для кожного розділу?
• Як відображається мова? Витягуєте з файлу властивостей чи бази даних? Чи можливо посилання на правильну мову дещо втрачається? Чи змішана мова, яку ви бачите, завжди є сайтом за замовчуванням?
• Чи існує кореляція із середовищем клієнта? Це пов’язано з першою кулею, але йде трохи далі. У мене виникли дивні проблеми з візуалізацією через проксі-сервери кешування нижче. Зазвичай ці типи проблем - це ціла сторінка, яка застаріла або надає сторінку однієї людини іншим користувачам (це бентежить).
• Використовуєте значення "Місцева нитка"? Якщо запит обробляється моїм більше ніж одним потоком, локальне значення потоку матиме різну інформацію на основі потоку, який працює в той час. У середовищі веб-сервера ви не можете припустити, що потік, з якого ви розпочали обробку, буде тим самим потоком, на якому ви закінчили обробку - якщо тільки це не є специфікацією для вашої платформи. Письменники-сервери виявили, що якщо вони повторно використовують невеликий пул потоків і мультиплексну роботу з ними, вони можуть одночасно обробляти більше запитів. Навіть якщо у вас є один потік від початку до кінця запиту, сервер може одночасно мультиплексувати інші запити до цього потоку. Замість локальних локальних потоків розгляньте прив'язку цього значення до атрибутів запиту чи сеансу.

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

• Використовуйте рясний журнал навколо проблемних зон. Це місце, де такий інструмент, як Log4J або Log4Net може дійсно світити. Ця рамка ведення журналу тощо, як вона, дозволяє вам підсилювати журнал для певних категорій, зберігаючи шум для всього іншого - все, змінюючи файл конфігурації. Ви хочете ввести нові заяви ведення журналу, щоб з’ясувати, чи може виникнути проблема у тому, що ви підозрюєте. Також переконайтеся, що ваші журнали доступу до HTTP мають всю необхідну інформацію про кожен запит (куки, параметри заголовка http тощо).
• Спроба моделювати проблему. Оскільки це відбувається епізодично, яке навантаження на сервер у той момент, коли воно відбувається? Чи потрапляєте ви в ряд одночасних запитів з різних мов? Якщо так, спробуйте змоделювати таке навантаження у вашому тестовому середовищі. Інструмент, подібний до JMeter, може бути тим, що вам потрібно. Ви також хочете мати можливість підробляти IP-адреси для своїх підроблених клієнтів. Пам’ятайте, що IP-адреси розміщені в розділі, щоб ви могли зрозуміти, на якій країні / регіоні заснований ІР-адрес на перших двох сегментах адреси.
• Проблема буде так само , як спорадична в тестовому середовищі, але , як ви звузити в вашу справжню причину ви можете спотворити результати , щоб це відбулося більш часто , ніж це робить в дикій природі. Крім того, ви можете легше переглянути файли журналів і спробувати навчитися з них.
• Це ітеративний процес, тому будьте терплячі. Ви повинні викликати тип навантаження, який, на вашу думку , відтворить помилку, перевірити журнали та уточнити ваші тести на основі того, що ви знайдете. Важливим є визначити проблему , тому опирайтеся на прагнення зробити кілька простих виправлень, які можуть спричинити лише справжню проблему рідше.

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

Тепер ви можете виправити це та бути впевненим, що він не повернеться знову до вас.

Помилка не відтворюється. Ви просто ще не дізналися, як її відтворити.

Жодна помилка не є випадковою, якщо ви не кидаєте виняток на основі значення повернення деякого оператора Random ().

Я знаю, що це може здатися семантикою, але це заспокоює подумки розповісти це про себе.

Дуже важко і засмучує дізнатися, як відкорити помилку, яка трапляється лише через складні умови перегонів.

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

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

Сподіваємось, вам вдасться знайти ведучий.

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

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

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

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

Ви можете виявити , коли проблема буде відбувається? Якщо так, чи можете ви надійно скинути інформацію про стан системи на той момент?

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

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