Понимание проблемы, когда вещи ломаются в производстве

Сценарий:

• Вы подталкиваете к производству
• Толчок сломал несколько вещей
• Эта же сборка не сломала QA или Dev
• Как разработчик, у вас нет доступа к продукту.
• Существует много давления со стороны выше , чтобы получить вещи работать agian.

Особенности:

• Приложение PHP / MVC, которое управляется API в Zend.
• Развернуто на нескольких серверах.

Мой вопрос:

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

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

Затем попробуйте посмотреть, сможете ли вы воспроизвести проблему в среде разработки. Если можете, то исправьте это и попробуйте снова выпустить.

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

Если это невозможно, посмотрите более внимательно на различия между производством и средой dev / qa и постарайтесь приблизить среду разработки к производству.

Насколько хорошо вы понимаете проблему? Какой риск, что твоя догадка ухудшит положение? Можно ли вернуться и воспроизвести проблему в регионах DEV / QA? Что вы можете сделать, чтобы синхронизировать регион DEV / QA, чтобы приблизить его к PROD? Возможно, вам придется изменить некоторые параметры среды или базы данных, может быть, вам придется импортировать данные PROD в DEV, может быть, вам придется изменить некоторые параметры отладки.

В общем, я бы не рекомендовал выдвигать вашу догадку о решении PROD, если вы не можете подтвердить, что оно действительно правильно в другом регионе. Я понимаю, какие проблемы возникают, когда ошибка возникает в PROD и не может быть воспроизведена где-либо еще. Именно тогда все сводится к тому, чтобы увидеть, что еще отличается между DEV / QA и PROD, и сосредоточиться на них. По моему опыту, это обычно окружающая среда или какая-то другая конфигурация, особенно для PROD. И я знаю, что, вероятно, сверху большое давление, чтобы исправить это, поэтому можно ли вернуться к предыдущему рабочему состоянию и затем попытаться воспроизвести проблему в DEV, придумать исправление в DEV, а затем попробовать опять в ПРОД? Вот что я бы предложил.

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

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

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

Обычно это проблемы конфигурации или данных, при условии, что код и БД идентичны между Prod, QA и dev.

Я бы сначала посмотрел на следующее:

• Любые данные регистрации вашего кода.
• Проверьте средство просмотра событий на наличие необработанных исключений.
• Проверьте данные, представляющие прогресс вашего приложения, это может быть в БД, файлах и т. Д. Имеет ли это смысл или нет? Это то, что вы ожидаете?

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

В то время как ваша среда - PHP, я сделал презентацию о том, как думать об этом для Java: http://www.infoq.com/presentations/maintainment-production-java-apps

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

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

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

Краткий ответ: нет, если у вас есть выбор.

Длинный ответ: Если вы не понимаете проблему, в таком патче есть несколько рисков:

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

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