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