Анализ первопричин

Когда вы тестируете новые крупные релизы, вы иногда можете быть удивлены появлением новых ошибок в производственной среде. Почему? Что пошло не так? Испытательные среды не всегда бывают настолько близки к производственным, как вы надеетесь. Изменения инфраструктуры могут быть внесены в среду без документального подтверждения, в результате чего среды постепенно отдаляются друг от друга.

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

Анализ первопричин (RCA) – это особая техника, которую можно использовать для устранения проблем. С помощью него вы анализируете проблему, используя определенный набор шагов для поиска основной причины. В основе RCA лежит принцип, согласно которому бесполезно устранять симптомы проблемы, игнорируя ее истоки.

Анализ первопричин (RCA) – это особая техника, которую можно использовать для устранения проблем. С помощью него вы анализируете проблему, используя определенный набор шагов для поиска основной причины. В основе RCA лежит принцип, согласно которому бесполезно устранять симптомы проблемы, игнорируя ее истоки.

Используйте подход резиновой утки (rubber-duck debugging), чтобы просто объяснить свою проблему. Объясняя что-то, вы будете вынуждены упорядочить свои мысли. Джефф Этвуд, соучредитель популярного сайта вопросов и ответов Stack Overflow, рассказывал о том, что разработчик программного обеспечения множество раз говорил о необходимости отправить новый вопрос на сайт, но в процессе находил ответ самостоятельно и ни разу так и не отправил вопрос!

Попробуйте использовать следующие подходы, которые помогут вам просто сформулировать проблему:

1. Напишите вопрос Stack Overflow - даже если вы никогда его не отправите.
2. Составьте детализированный отчет об ошибках.
3. Объясните это коллеге по работе.

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

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

Затем следует определить «причинный фактор» – непосредственную причину рассматриваемой проблемы. При этом не следует выявлять только один причинно-следственный фактор, а затем останавливаться. Вы должны пойти дальше, используя технику «пяти почему». Задавайте вопросы «почему?» последовательно, пока не доберетесь до корня проблемы. Например, ваш сайт показывает ошибку 500.

1. Почему? Потому что маршрутизатор веб-платформы вышел из строя.
2. Почему? Потому что для работы ему требуется другой компонент, который также неисправен.
3. Почему? Потому что для этого компонента веб-платформы требуется расширение intl, которое не работает.
4. Почему? Потому что оно было случайно отключено после обновления программного обеспечения сервера.

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

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

Одним из основных предложений AWS для анализа первопричин является помощь в получении и анализе данных журналов. Для этого мы рекомендуем Сервис Amazon OpenSearch.