Работаем над ошибками, чтобы не приходилось краснеть после релизов
Привет! Меня зовут Иван Аксенов, я Ruby-разработчик в компании Домклик. Расскажу о своём подходе к анализу причин выпуска неудачных релизов.
Человек склонен совершать ошибки в любой деятельности. Иногда ошибки совсем незаметны и ни на что не влияют, иногда — неизбежны. А бывает, что они настолько глупые, что стыдно признаться в их совершении. В начале карьеры в IT я тяжело переживал каждый свой неудачный релиз, требовавший выпуска хот-фикса. Я корил себя за невнимательность, и лишь спокойствие более опытных коллег позволяло охладить голову и вернуться к нормальной работе. Со временем я стал понимать, что собственная внимательность — лишь один, и далеко не главный фактор на пути к стабильной работе системы.
Понять это мне помогла книга Мэтью Сайеда «Принцип «чёрного ящика». Как превратить неудачи в успех и снизить риск непоправимых ошибок». Автор рассказывает о том, как в разных отраслях принято работать с ошибками, выделяя два принципиально разных подхода:
Ошибка — естественная и неотъемлемая часть любого процесса. Каждая уникальная ошибка или неудача должна быть учтена и проанализирована. Всё это должно обогатить накопленный опыт, который поможет выстроить процессы таким образом, чтобы допускать меньше подобных ошибок в будущем.
Ошибка — досадная случайность. Отношение к ошибкам негативное, их стараются скрыть внутри, так как они могут бросить тень на авторитет специалистов или организаций.
В качестве примера отрасли с конструктивной системой анализа ошибок Мэтью приводит авиацию (отсюда и название книги про чёрные ящики). Среди отраслей, которым есть чему поучиться у авиации, он называет практическую медицину (опытные авторитетные доктора, прошедшие многолетнее обучение, не могут ошибаться, спорить с ними не принято; системный анализ врачебных ошибок развит очень слабо) и судебную систему (очень консервативно устроена, разные инстанции не заинтересованы в обнародовании ошибок друг друга).
По моим наблюдениям, в своём большинстве подход IT-компаний к «работе над ошибками» можно отнести к первому типу: как правило, в командах анализируют ошибки, выстраивают процесс таким образом, чтобы различные инциденты происходили реже. Допускать ошибки не считается зазорным, особенно если допустивший их делает соответствующие выводы.
Лучшие практики из отраслей, которые научились работать над ошибками качественнее других, стоит распространять. И речь не о простом копировании, а о гибком подходе к анализу неудач. Расскажу немного о том, как мы боремся за стабильность системы внутри Домклика.
В нашей компании почти нет QA-специалистов. Точнее, каждая команда сама несёт ответственность за качество своего продукта. Поэтому и личная ответственность разработчиков за написанный код повышается. Конечно, мы покрываем код автотестами, составляем тест-планы по каждой задаче, тестируем релизы и поддерживаем мониторинг своих приложений. Если случаются серьезные инциденты, они разбираются на еженедельной встрече с представителями всех команд.
Я задался вопросом, что лично я могу добавить к выстроенным процессам компании, и решил проанализировать каждый случай в нашей команде за последнее время (чуть меньше года), когда требовалось выпускать хот-фикс после релиза.
Причины, которые потребовали срочной починки системы (таких случаев в нашей команде набралось 16), разделил на три группы:
Ошибки, которые было сложно предугадать, так как они вызваны сочетанием факторов, которое раньше не встречалось. Например, при взаимодействии с API государственного сервиса мы наткнулись на не упомянутые в документации ограничения по запросам. Таких случаев я насчитал три. Это самые ценные ошибки, которые расширяют наше знание о системе и позволяют усовершенствовать процессы разработки и тестирования, а в некоторых случаях и бизнес-процессы.
Ошибки, вызванные несовершенством процесса. Например, какой-то важный кусок кода, который не был явно затронут при работе над задачей, не был ранее покрыт автотестами, или что-то невозможно было проверить на тестовых средах. Набралось пять таких ошибок. Инциденты в этой категории указывают на пробелы в процессах и позволяют их улучшать.
Самая частая причина (восемь случаев) — ошибки, которых можно было избежать, если бы не нарушался процесс разработки. Например, когда задачу докинули в спринт без полноценного обсуждения, или когда разработчик понадеялся на то, что «ломаться там нечему» и не стал полноценно тестировать релиз. Здесь большое количество самых разнообразных багов: опечатки, которые пропустил и сам разработчик, и его коллеги на проверке; неочевидные сценарии, которые не вошли в тест-план. Это самые обидные ошибки, которых легче всего избежать. Они не обязательно требуют изменения процессов, скорее, напоминают о том, что этим процессам нужно следовать.
Конечно, классификация эта условная, и не всегда можно чётко определить, относится ли та или иная проблема, например, ко второй или третьей группе.
Какой вывод можно сделать из этой информации? Можно существенно уменьшить количество релизов с ошибками, если не отступать от принятого в команде процесса. Стоит задуматься над тем, что может в этом помочь: возможно, стоит формализовать некоторые этапы тестирования, чтобы было меньше соблазна пропускать какой-то из этапов на пути к выпуску релиза. Какие-то шаги стоит автоматизировать, если это еще не сделано. Можно обратить внимание команды на повторяющиеся проблемы, обсудить возможные причины, проследить за динамикой появления схожих ошибок. В любом случае, беспристрастный и безэмоциональный взгляд на общую картину может принести пользу.
Каждый может сделать свой вклад в создание более стабильных систем: анализируйте свои ошибки, обсуждайте их с командой. Относитесь к ним без негатива, ведь они — важнейшая часть развития любой системы и команды.
