Ошибки случаются. Делали и будут. И мы не можем этого избежать — в том числе и в мире ИТ. Возрастающая сложность наших систем и решений делает их более уязвимыми для человеческих, машинных и интеграционных ошибок. Мы можем (и должны!) сделать все возможное, чтобы избежать их, написав хорошие тесты, смоделировав некоторые сбои, проводя регулярные проверки кода и т. д., но мы также должны быть готовы к проблемам. И не только исправлять их — важнее учиться у них. В этой статье я хочу поделиться своими мыслями о процессе под названием «Анализ первопричин» — одной из самых полезных техник для извлечения уроков из проблем.
Почему вы должны делать RCA?
Давайте будем честными — никто не любит говорить о своих ошибках. Кроме того, мы (как разработчики) предпочитаем создавать персонал, а не проводить долгие и трудные обсуждения и анализы. Но поверьте мне — исправление наших процессов стоит этих усилий. Существует популярная аналогия, описывающая, зачем нужны RCA. Представьте себе огромную компанию по производству автомобилей. Однажды один из сотрудников поскользнулся на полу и сломал ногу. Немедленным действием будет доставить его в больницу и наложить на ногу гипс. Но конец ли истории? Еще нет. Допустим, компания ничего не изменила после этого события. А следующий человек сломал ногу через несколько дней, а еще через неделю одна из машин перестала работать, что привело к задержке всего производства. Как и следовало ожидать, это не случайная последовательность событий. Следствие установило, что люди поскользнулись на утечке масла из машины. А отсутствие масла стало причиной заклинивания поршня в автомате. Выявление реальной первопричины первой аварии могло бы предотвратить травмы, задержки производства и огромные финансовые проблемы для компании. Та же история может случиться и с вашей системой. Если вы не найдете настоящий корень ошибок в вашей системе, а лишь поверхностно исправите их, они будут повторяться. Кроме того, эти небольшие проблемы могут быть лишь первыми симптомами настоящей проблемы. Не игнорируйте их! Чем быстрее вы отреагируете, тем ниже будут эффекты и затраты на ремонт! Вы должны не только устранить проблему, но и понять, почему она возникла и как улучшить свои процессы, чтобы избежать ее в будущем.
Как может выглядеть процесс RCA?
Хорошо, мы знаем, почему это важно, но вопрос в том, как провести полезный анализ первопричин? К счастью, многие люди задавали этот вопрос раньше, и мы можем использовать их знания. Существует множество различных подходов и схем, но я опишу, как я подхожу к этим проблемам, основываясь на методе из шести шагов, разработанном Американским обществом качества (ASQ), и методе «5 почему», разработанном Сакичи Тойодой из Toyota. Эти два подхода не исключают друг друга — на самом деле они дополняют друг друга. ASQ описывает общую картину и шаги, которые необходимо предпринять, когда Toyota сосредоточится на третьем этапе системы ASQ.
6-ступенчатая система от ASQ
Давайте будем честными — эта система не креативна и не захватывает дух. Через какое-то время вы, вероятно, могли бы придумать что-то подобное. Но мне нравятся простые и четко сформулированные контрольные списки — благодаря им вы знаете, что не пропустили ни одного важного шага, и можете сосредоточиться на более проблемных или специфичных для ваших проблемных областях. (Кстати, я настоятельно рекомендую книгу «Манифест контрольного списка», чтобы полностью понять, почему они такие замечательные). Итак, что такое структура RCA, определенная ASQ?
- Определите событие — проясните проблему и определите ее масштабы. Убедитесь, что все находятся на одной странице и понимают ее одинаково.
- Найти причины —найти потенциальные причины события, определенного на предыдущем шаге.
- Поиск основной причины (подробнее об этом шаге я расскажу в следующей главе).
- Найти решения , что вы можете сделать, чтобы решить основную проблему и предотвратить ее появление в будущем?
- Примите меры —говорить об изменениях недостаточно. Без действий ничего не изменится!
- Проверить эффективность решения —как проверить, действительно ли решение работает?
5 почему
Сосредоточимся на третьем шаге из верхнего списка «Поиск первопричины. Звучит просто, но как это сделать, спросите вы. Здесь мы можем использовать метод 5 почему, упомянутый ранее. Это также очень легко запомнить и выполнить. Единственное, что вам нужно сделать, это задать несколько раз (в оригинале 5, но иногда число меньше или больше) короткий, но сильный вопрос «почему?». Давайте посмотрим на предыдущий пример сотрудника, который сломал ногу в компании.
Наше событие: Один из сотрудников сломал ногу во время работы на мануфактуре.
- Почему? Потому что он поскользнулся и упал.
- Почему? Потому что пол был мокрым.
- Почему? Потому что на нем было масло.
- Почему? Потому что из машины вытекло масло.
- Почему? Потому что корпус машины был ржавый и в нем была проделана дыра.
Как видите, решение только первой проблемы будет малоэффективным — масло все равно вытечет, что вызовет дополнительные проблемы. Та же история может быть применена к нашим системам. Важно не только наложить пластырь на рану, но и вылечить настоящую проблему. И именно поэтому RCA так полезны!
Делимся знаниями
Лучший способ учиться — это учиться на ошибках… сделанных другими ☺ Будьте хорошим гражданином — делитесь знаниями о своих ошибках с другими, чтобы помочь им избежать ваших ошибок. Создайте публикацию в Slack вашей компании, поделитесь электронной почтой с мыслями или создайте статью на Medium. Кто знает? Может быть, вы станете для кого-то супергероем и спасете их систему?
Удачного кодирования!
Пс. Если вы нашли эту статью полезной, пожалуйста, нажмите на кнопку ниже или поделитесь ею с друзьями. Спасибо!
