Анализ первопричин: 4 совета по быстрому устранению неполадок

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

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

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

Таким образом, научиться быстрому устранению неполадок – это одна из лучших инвестиций, доступных разработчику программного обеспечения или ИТ-работнику в целом.

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

Анализ первопричин: что это и почему необходимо о нем задуматься?

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

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

Мы поговорили о вопросах «что» и «почему». Вот четыре совета, которые помогут в использовании RCA для устранения проблем.

Используйте метод утенка
Да, я серьезно, метод утенка. И я его не выдумал. Вероятно, у него множество разных названий. Но суть – объясните вашу проблему резиновой уточке. Нет утенка под рукой? Не беспокойтесь! Вы можете использовать любой неодушевленный предмет, который окажется рядом. Или даже поговорить с другим человеком!

Что же такое метод утенка? Этот способ основан на том факте, что когда вы что-то кому-то объясняете, то одновременно организуете мысли в голове. Наш мыслительный процесс зачастую хаотичен и беспорядочен. И когда мы сталкиваемся перед неизбежным объяснением, то невольно раскладываем все по полочкам. Джефф Этвуд, соучредитель популярного сайта вопросов и ответов Stack Overflow, рассказывал о том, что разработчик программного обеспечения множество раз говорил о необходимости отправить новый вопрос на сайт, но в процессе находил ответ самостоятельно и ни разу так и не отправил вопрос!

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

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

Можно использовать следующие методы:
1. Напишите вопрос в Stack Overflow. Или притворитесь, что пишете вопрос Stack Overflow, но вместо этого используйте блокнот.
2. Составьте детализированный отчет об ошибках. Кому-то все равно придется это сделать, так почему бы не убить двух зайцев одним выстрелом?
3. Зайдите в кабинет к коллегам и поговорите несколько минут. Конечно, только если они не против. Не беспокойте коллег без нужды.


Соберите много данных журнала (и выполните эффективный поиск по ним)

Если вы успешно и очевидно объяснили проблему, но все еще не можете добраться до основной причины, то нужно идти дальше. Что необходимо сейчас, так это собрать всю информацию о проблеме и вычленить из нее аналитические выводы.

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

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

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


Используйте технику «пяти почему»
После сбора информации пришло время использовать ее и найти причинно-следственные факторы. «Причинный фактор» здесь означает непосредственную причину рассматриваемой проблемы. Чего не следует делать, так это выявлять один причинно-следственный фактор, а затем останавливаться. Нужно смотреть глубже. Одной из наиболее известных техник для этого является метод «пяти почему».

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

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

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

Метод «пяти почему» далек от совершенства. Он получил свою долю критики, и, безусловно, имеет ограничения. Но может оказаться полезен для того, чтобы подталкивать инженеров к поиску первопричины вместо остановки при первых признаках приближения к решению.


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

Итак, учитывая это, порекомендую ли я делать обзор кода? Конечно, да, но это не единственный способ заполучить дополнительную пару глаз. Я предлагаю использовать походные обзору процессы практически для каждой задачи, которую выполняет инженер. А лучше парочку. Выполняйте парное программирование, парную настройку сервера, парную отладку и парную поддержку клиентов. Вкратце: устраняйте проблемы вдвоем.

Наука или творчество?

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

Итак, примените эти способы для анализа первопричин:
1. Используйте метод утенка
2. Соберите множество данных журнала, выполните по ним поиск и проанализируйте с помощью подходящих инструментов
3. Используйте технику «пяти почему»
4. Найдите дополнительную пару глаз

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

Подробнее о ценах на Amazon OpenSearch Service

Перейти на страницу цен
Готовы приступить к разработке?
Начало работы с Amazon OpenSearch Service
Есть вопросы?
Связаться с нами