Розуміння проблеми, коли речі ламаються у виробництві

Сценарій:

• Ви підштовхуєте до виробництва
• Поштовх розбив кілька речей
• Та сама збірка не зламала ні qa, ні dev
• Як розробник, ви не маєте доступу.
• Існує великий тиск зверху, щоб змусити працювати по-справжньому.

Особливості:

• Додаток PHP / MVC, що керується API в Zend.
• Розгорнуто на декілька серверів.

Моє запитання:

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

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

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

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

Якщо це неможливо, то уважніше подивіться на відмінності між виробництвом та середовищем dev / qa та спробуйте зробити середовище розробників ближчим до виробництва.

Наскільки добре ви розумієте проблему? Який ризик, що ваша думка погіршить ситуацію? Чи можливо повернутися назад і відтворити проблему в регіонах DEV / QA? Що ви можете зробити, щоб синхронізувати ваш регіон DEV / QA, щоб наблизити його до PROD? Можливо, вам доведеться змінити деякі налаштування навколишнього середовища чи бази даних, можливо, вам доведеться імпортувати дані PROD в DEV, можливо, вам доведеться змінити деякі налаштування налагодження.

Загалом, я б не рекомендував підштовхувати ваше рішення до програми PROD, якщо ви не зможете підтвердити, що це дійсно правильно в іншому регіоні. Я розумію, які проблеми виникають, коли помилка відбувається в PROD і не може бути відтворена більше ніде. Саме тоді доводиться бачити, що ще відрізняється між DEV / QA та PROD, і зосереджуватися на них. На мій досвід, зазвичай це налаштування навколишнього середовища чи інша конфігурація, спеціально для PROD. І я знаю, що, ймовірно, є великий тиск зверху, щоб виправити це, тож чи можна повернутись до попереднього робочого стану, а потім спробувати відтворити проблему в DEV, придумайте виправлення в DEV, а потім спробуйте знову в PROD? Саме це я б запропонував.

Залежить від виду виправлення. Найчастіше проблеми у виробництві, які не з'являються у програмі dev, пов'язані з суперечками в базі даних. Тож застосування помилки, яка змінює вміст бази даних, не будучи впевненою, що саме там "там", може бути першим кроком у великій катастрофі. Якщо ви можете легко повернути зміни назад, можливо, ви зможете спробувати. Але загалом, якщо у вас немає прямого доступу, для тестів повинна бути принаймні копія бази даних або всього сервера. Людям з правильними привілеями все одно доведеться запускати новий код, але принаймні без ризику втрати даних. (Іноді розмір бази даних або складність інфраструктури забороняє таке налаштування)

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

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

Зазвичай це або проблеми з конфігурацією або даними, якщо припустити, що код і БД ідентичні між Prod, QA і dev.

Я б спершу подивився на наступне:

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

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

Хоча ваше середовище PHP, я зробив презентацію, як думати про це на Java: http://www.infoq.com/presentations/maintain-production-java-apps

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

Крім того, є кілька інструментів для полегшення усунення несправностей: Wireshark для усунення несправностей у мережі - це абсолютно найкраще і варто вивчити його. Інші залежать від O / S, який ви використовуєте. Для Windows все від SysInternal (зараз це частина Microsoft) є геніальним. Для Unix / Linux, дивіться на ферму / strace.

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

Коротка відповідь: Ні, якщо у вас є вибір.

Довга відповідь: Якщо ви не розумієте проблему, у такому патчі є кілька ризиків:

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

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