«Пять почему» — это распространённый метод исследования первопричин события. Он основан на предположении, что задав вопрос «почему» пять раз, можно найти ответ, который и будет являться первопричиной. Программист Сергей Целовальников* уверен: такая практика может оказаться полезной, но её бездумное применение часто приводит к не самым лучшим результатам.

Под катом автор рассуждает о специфике этого метода на примере выдуманного инцидента в компании Acme Corp.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Познакомьтесь с командой

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

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

Познакомьтесь с Элис

Элис работает дежурным инженером. Её официальная должность — это SRE, и в число её обязанностей входит глубокое понимание состояния сервиса на основе доступных метрик. Она хорошо разбирается в индикаторах работоспособности сервиса и инфраструктуре мониторинга. Когда она начала расследование инцидента, то обнаружила, что приложение перегружено из-за высокой нагрузки на ЦПУ. Согласно рекомендациям шаблона «работы над ошибками», она начала анализ по методу «Пяти почему».

Анализ по методу «Пяти почему»:

• Почему пользователи не могли открыть веб-сайт? Потому что приложение было перегружено и начало выдавать ошибки.

• Почему приложение было перегружено? Потому что загрузка ЦПУ достигла 100%, и экземплярам не хватило ресурсов для обработки запросов.

• Почему загрузка ЦПУ стала такой высокой? Потому что мы не заметили вовремя, когда она достигла 90%, и не успели устранить проблему.

• Почему мы этого не заметили? Поскольку не было предупреждений о загрузке ЦПУ на 90%.

• Почему предупреждений не было? Потому что оповещения были удалены два года назад после миграции на новую систему мониторинга.

После проведения анализа «Пяти почему» была определена первопричина. Основной задачей после анализа стало восстановление предупреждений о высокой загрузке процессора (90%), чтобы вовремя выявлять подобные ситуации и предотвращать проблемы до того, как они затронут пользователей. Теперь, когда все вопросы решены, а уроки усвоены, Элис отправляется расследовать следующий инцидент.

Познакомьтесь с Бобом

Боб — бэкенд-разработчик, который первым реализовал новую функциональность на сайте и активировал её. У Боба больше всего информации об этом изменении, поэтому было бы разумно, если бы он написал «работу над ошибками». Боб может применить анализ «Пяти почему», выполняя «работу над ошибками», и понять, что сделать, чтобы в будущем изменения внедряли более плавно.

Анализ по методу «Пяти почему»:

• Почему пользователи не могли открыть веб-сайт? Потому что приложение было перегружено.

• Почему приложение было перегружено? Потому что загрузка ЦПУ достигла 100%.

• Почему это произошло? Потому что приложение вошло в бесконечный цикл сборки мусора.

• Почему процесс сборки мусора начал забирать все ресурсы ЦПУ? Потому что приложению не хватило динамической памяти.

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

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

Познакомьтесь с Чарли

Чарли — это фронтенд-разработчик, которая внедрила новую функцию и отвечает за общий вид новостного сайта Acme Corp. Чарли также является продактом Acme Corp Recommendations™ и очень заботится о его доступности, поэтому ей, возможно, стоит провести «работу над ошибками».

Анализ по методу «Пяти почему»:

• Почему пользователи не могли открыть веб-сайт? Потому что приложение было перегружено.

• Почему приложение было перегружено? Из-за внезапного наплыва запросов, что привело к высокой нагрузке на ЦПУ.

• Почему случился такой наплыв? Потому что пользователи начали отправлять большое количество запросов.

• Почему они стали так делать? Потому что каждый запрос повторялся до десяти раз.

• Почему происходило столько повторных попыток одновременно? Потому что не было экспоненциальной задержки.

Модель восприятия приложения Чарли основана преимущественно на потоках запросов. Изучая логи приложения, она обнаружила множество повторных попыток от одной и той же группы пользователей. При анализе кода, отвечающего за получение рекомендаций, она заметила, что все запросы повторялись немедленно без экспоненциальной задержки или джиттера. Таким образом, она внесла это в список задач с планом выполнить до пятницы.

Познакомьтесь с Дэйвом

Дэйв — инженер команды облачной инфраструктуры, ответственный за работоспособность кластера Acme News Corp. Дэйв придает большое значение надёжности, поэтому он может взять на себя проведение расследования и написание «работы над ошибками».

Анализ по методу «Пяти почему»:

• Почему пользователи не могли открыть веб-сайт? Потому что приложение было перегружено.

• Почему приложение было перегружено? Потому что нагрузка на каждый экземпляр резко увеличилась.

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

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

• Почему? Потому что время ожидания автомасштабирования было слишком долгим.

Для Дэйва каждая задача в кластере — это своего рода «черный ящик», способный обрабатывать определённое количество запросов. Дэйв контролирует стратегии для каждого типа задач, определяющие способность приложений масштабироваться с увеличением или уменьшением производительности. Дэйв изучил графики и обратил внимание: несмотря на то, что при резком увеличении нагрузки присоединились новые экземпляры, время ожидания не позволило автомасштабированию добавить еще больше задач, чтобы справиться с нагрузкой. Дэйв записывает задачу обновления стратегий автомасштабирования для очень активного увеличения нагрузки как основной пункт действий.

Познакомьтесь с Эрин

Эрин — инженер в команде, работающей над базовыми библиотеками, она занимается разработкой общего набора таких библиотек. Когда Эрин впервые узнала об инциденте, связанном с библиотекой кэширования, она предложила провести «работу над ошибками» и не побоялась взять на себя ответственность.

Анализ по методу «Пяти почему»:

• Почему пользователи не могли открыть веб-сайт? Потому что приложение было перегружено.

• Почему приложение было перегружено? Потому что закончилась память.

• Почему у приложения закончилась память? Потому что кэш занимал слишком много памяти.

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

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

Оригинальную библиотеку кэширования создала Эрин. Библиотека оказалась очень успешной, так как она идеально подходит для задач, стоящих перед Acme Corp. Но до сих пор внимание было сосредоточено на пропускной способности, а не на экономии памяти. Посмотрев на библиотеку под другим углом, Эрин обнаружила возможности для совместного использования базовых структур данных и решила разработать версию кэширования, специально оптимизированную для экономии памяти.

Анализ

Давайте взглянем на ситуацию в целом и рассмотрим результаты этого упражнения. У нас есть пять человек и пять разных историй. Главный вывод — результаты анализа по методу «Пяти почему» не повторяются. Итог анализа сильно зависит от того, под каким углом на инцидент смотрит человек, проводящий анализ. Взгляд Дэйва на произошедшее сильно отличается от взгляда Чарли, так как они ежедневно работают над разными частями системы, что сильно влияет на их анализ.

Но даже если рассмотреть только одно исследование, можно заметить, что число «пять» само по себе представляет интерес. Оно запоминается, оно привлекает внимание, но оно необоснованно ограничивает глубину исследования. Может быть, Элис стоило бы заняться программной археологией, чтобы понять, почему оповещения были удалены после миграции. Боб мог бы вникнуть глубже, собрав несколько дампов кучи, чтобы разобраться в распределении данных в кэше. Зачем останавливаться только на пяти, если можно задать больше вопросов?

Первопричина

Как мы увидели, анализ по методу «Пяти почему», как и любой другой подход, имеет свои недостатки. Однако его можно эффективно применять для более глубокого анализа! Так достаточно ли серьезны эти недостатки, чтобы отказаться от этого подхода?

Реальная проблема возникает, когда методика становится частью шаблона. Как только она включена в шаблон, форма анализа становится неизменной. Шаблон ограничивает анализ, заковывая исследователя в рамки. Недостатки анализа становятся недостатками «работы над ошибками».

Но если не применять метод «Пяти почему», то как мы обнаружим первопричину? Во-первых, важно осознать, что редко существует одна первопричина. Часто бывает несколько причин, которые становятся видны при рассмотрении инцидента с разных точек зрения.

Во-вторых, что более важно, речь идет вовсе не о поиске первопричины. Важно глубоко понять, что произошло, и затем, на основе этого, определить, какие действия следует предпринять, чтобы предотвратить повторение инцидента. Зачастую эти действия могут сильно отличаться от первопричины. К примеру, Acme News могла бы ограничить «зону поражения» и гарантировать загрузку страницы даже при недоступных рекомендациях. Такие меры не всегда выявляются при поиске первопричины. В связи с этим возникает вопрос — если не анализ по методу «Пяти почему», то что должно быть указано в шаблоне? В конце концов, он же не может быть пустым!

Прежде чем искать альтернативу, важно осознать, что шаблон должен способствовать формированию понимания и детального описания ситуации, а не стимулировать поиск первопричины. В статье «Бесконечные как» Джон Оллспоу подчеркивает: «Обучение является целью. Любые профилактические меры зависят от этого обучения». Он предлагает использовать подсказки для подведения итогов из книги Сидни Деккера «Руководство по пониманию человеческих ошибок».

Наличие подсказок может стать отличной отправной точкой, так как они предлагают рассмотреть систему с разных сторон и понять, как вела себя каждая её отдельная часть во время инцидента. Кроме того, этот подход можно дополнить вопросами, которые помогут создать полную картину происходящего и облегчить обучение. Можно даже предложить разные подсказки для различных компонентов, которые были затронуты. Если Алиса, Боб или любой другой член команды начнут использовать эти подсказки, им придётся рассмотреть систему с разных точек зрения, что придаст исследованию необходимую глубину.

Заключение

Анализ по методу «Пяти почему» — это полезная техника, которую можно легко запомнить и которая напоминает о необходимости всегда смотреть глубже. Однако его прямое использование приведёт только к выявлению причины, а не первопричины, так как редко существует единственная первопричина. Этот подход может быть применён для расширения области поиска последующих действий. Тем не менее превращение этого инструмента в шаблон и основной стимул для анализа первопричин, может принести больше вреда, чем пользы.

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