Поломки в сложных системах
Одно из моих важных наблюдений по результатам долгой эксплуатации Яндекс.Новостей заключалось в том, что факапы как правило не случались по какой-то одной причине. В смысле, что для серьёзной аварии нужно было сочетание нескольких причём довольно редких условий. И я убеждён, что это стандартный паттерн для сложных систем не только в компьютерной и обычной инженерии, но и, например, в биологии.
Немного поясню.
Во-первых, Новости - это сервис 24x7 с миллионами пользователей в сутки, со сложной обработкой данных внутри (а вовсе не редакторским отделом как некоторые думают), в каком-то смысле Поиск в миниатюре.
Во-вторых, говоря про сложные поломки, не надо забывать, что они, конечно, не единственные, и кроме них бывает и человеческий фактор (откровенно ошибочные действия, непроверенные изменения на продакшне и прочие неудачные ручные вмешательства), и «простые» проблемы с единой точкой отказа (ну, скажем, упал незабекапленный сервер). Но эти два класса я рассматривать не буду, они мне сейчас неинтересны.
Поначалу у нас бывали поломки из-за разработки на продакшне неудачных ручных вмешательств, случались поломки и в свежесозданных и часто не до конца оттестированных решениях, но в основном лишь в начальный период их эксплуатации - часто всё же они отлавливались на этапе организации бет и предпродакшн тестирования.
В последние несколько лет нам, кажется, удалось выйти на уровень, на котором эти два типа поломок в продакшне практически не наблюдались - тому способствовали договорённости (не разрабатываемся на продакшне, не выкатываемся в пятницу и т.п.), автоматизированные или чётко описанные процедуры (выкатываем так-то, переключаемся так-то), да и общий накопленный опыт.
Но система временами всё равно ломалась. Каждый раз по-новому и очередным неожиданным способом. И неизменно каждый раз в процессе разбирательств выяснялось, что к поломке привело сочетание нескольких редких причин, причём каждая из которых в отдельности к поломкам не приводила. Могло быть, что два из трёх реализовавшихся условий были безвредны и вместе.
Пример: система перестаёт нормально функционировать (отвечать на все запросы пользователей и регулярно обновляться каждые X минут) если:
- работа сети сильно замедляется;
- алгоритм кластеризации сформировал сюжет очень большого размера и с большим количеством фотографий;
- из-за неоптимальности кода в одном из хэндлеров на веб-сервере производится заказ данных в большем чем реально нужно объёме;
- этот в обычном режиме довольно редко вызываемый хендлер вдруг вызывается очень часто (потому что напрямую связан с кликами на определённом блоке и в этом блоке по каким-то причинам оказалось что-то очень привлекательное для пользователей, скажем, клёвая картинка).
В данном примере, кажется, произвольные три из четырёх условий не приводят к поломке системы. По крайней мере три из этих условий довольно редки, но работа в области больших чисел, безусловно, прекрасна тем, что все достаточно редкие события рано или поздно наступают, и надо перестроить свои мозги на этот лад. Четвёртое условие присутствует в системе постоянно в качестве некой предрасположенности, но оно, вообще говоря, тоже может быть посажено случайно в какой-то момент времени с определённым релизом и отсутствовать в других ветках как до, так и после.
[офтопик про разработку и эксплуатацию: после того как всё случилось, безусловно понятно, как защититься от подобной ситуации, и больше одного раза подобное не происходит; понятно, что все потенциально слабые места при обнаружении надо устранять; понятно, по каким косвенным признакам можно найти такие потенциально проблемные места; но понятно также и то, что заранее придумать все возможные условия функционирования и перебрать их все возможные комбинации представляется не очень реальным, хотя и можно к этому как-то приблизиться, особенно уже обладая некоторой экспертизой. Но пост не про разработку и эксплуатацию, поэтому эту тему я сейчас развивать не буду].
У всех этих поломок прослеживается чёткая параллель с «обычными» катастрофами в реальном мире (типа обрушения зданий, падения самолётов, аварий в энергосетях и на электростанциях), которые, конечно, тоже случаются по разным причинам, включая и человеческий фактор, и брак, и глупые ошибки с единой точкой отказа, но среди прочего есть заметная группа случаев именно с таким же паттерном - редкое сочетание условий. Я не готов сейчас назвать конкретные события так, чтобы быть на 100% уверенным, что в них наблюдался именно такой паттерн, но из многолетнего регулярного чтения прессы у меня осталось чувство, что подобных событий было много. Знаете какой хороший пример - скажите. Навскидку есть чувство, что такое говорили про аварию на Чернобыльской АЭС, такое же говорили про какую-то из авиакатастроф. Характерна цитата Александра Нерадько, в тот момент, кажется, руководителя Федеральной аэронавигационной службы России: «Любая авиакатастрофа - это всегда сочетание нескольких неблагоприятных факторов».
Впрочем, аналогия с инженерными системами неудивительна. Мне больше нравится другая - эволюция. Точнее массовые вымирания в истории Земли.
Есть мнение, что такие массовые вымирания происходят из-за сочетания нескольких неприятных событий на одном отрезке времени. Например, массовое вымирание в конце мела, во время которого среди прочих вымерли и динозавры. Точная его причина так и неизвестна, более того, кажется, даже неизвестно было ли оно постепенным или быстрым. Но касательно причин, выбирать на рубеже мела и палеогена было из чего: назревал внутренний биотический кризис (появились цветковые растения и произошла смена растительности на Земле и динозавры умерли от запора, появилось зверьё, способное есть детёнышей динозавров), тогда же случился очередной этап траппового вулканизма и образовались Деканские траппы (основная часть извержений произошла недалеко от современного Мумбаи, а общая площадь покрытой лавой территории по оценкам составляла половину современной Индии), а вдобавок ко всему ещё и астероид прилетел. Какой знакомый паттерн.
Чем ещё эволюция жизни напоминает эволюцию технических систем (или скорее в обратную сторону в силу преемственности), так это тем, что «устойчивость» живых организмов со временем растёт - с течением времени средняя продолжительность существования видов, родов и семейств неуклонно увеличивалась [ Марков, «Рождение сложности», с.363]. Тот же трапповый вулканизм, поначалу приводивший к серьёзным экологическим катастрофам, после мезозоя стал оказывать гораздо более слабое влияние, так как океан стал более эффективным буфером для сглаживания колебаний углекислого газа в атмосфере [источник]. И, видимо, одного этого фактора для значительного эффекта стало уже не хватать, для серьёзной поломки нужно было что-то ещё. Вот, для мел-палеогенового вымирания добавки нашлись. Располагаясь среди других коррелирующих с трапповым вулканизмом (помеченным кружками на картинке) вымираний, оно ощутимо отличается от них по масштабам:
Другой пример из биологии - рак. Я не большой специалист по канцерогенезу, но по современной общепринятой теории рак вроде как моноклонален, то есть возникает из одной клетки. А чтобы эта конкретная клетка стала раковой, в ней должны произойти несколько мутаций. То есть несколько редких событий подряд.
Я давно хотел записать мысли на эту тему, но всё время откладывал. Вынудила меня это сделать неожиданно очень в тему попавшаяся работа «How Complex Systems Fail (Being a Short Treatise on the Nature of Failure; How Failure is Evaluated; How Failure is Attributed to Proximate Cause; and the Resulting New Understanding of Patient Safety)» [backup], Richard I. Cook, MD, Cognitive technologies Laboratory University of Chicago. Он даже есть в переводе на русский.
И это офигенный текст. В частности:
3) Catastrophe requires multiple failures - single point failures are not enough..
The array of defenses works. System operations are generally successful. Overt catastrophic failure occurs when small, apparently innocuous failures join to create opportunity for a systemic accident. Each of these small failures is necessary to cause catastrophe but only the combination is sufficient to permit failure. Put another way, there are many more failure opportunities than overt system accidents. Most initial failure trajectories are blocked by designed system safety components. Trajectories that reach the operational level are mostly blocked, usually by practitioners
Прочитайте, там ещё много интересного.
Вот, например:
14) Change introduces new forms of failure.
The low rate of overt accidents in reliable systems may encourage changes, especially the use of new technology, to decrease the number of low consequence but high frequency failures. These changes maybe actually create opportunities for new, low frequency but high consequence failures. When new technologies are used to eliminate well understood system failures or to gain high precision performance they often introduce new pathways to large scale, catastrophic failures. Not uncommonly, these new, rare catastrophes have even greater impact than those eliminated by the new technology. These new forms of failure are difficult to see before the fact; attention is paid mostly to the putative beneficial characteristics of the changes. Because these new, high consequence accidents occur at a low rate, multiple system changes may occur before an accident, making it hard to see the contribution of technology to the failure.
А это вообще шик (из серии «За одного битого двух небитых дают»):
18) Failure free operations require experience with failure.
Recognizing hazard and successfully manipulating system operations to remain inside the tolerable performance boundaries requires intimate contact with failure. More robust system performance is likely to arise in systems where operators can discern the “edge of the envelope”. This is where system performance begins to deteriorate, becomes difficult to predict, or cannot be readily recovered. In intrinsically hazardous systems, operators are expected to encounter and appreciate hazards in ways that lead to overall performance that is desirable. Improved safety depends on providing operators with calibrated views of the hazards. It also depends on providing calibration about how their actions move system performance towards or away from the edge of the envelope.
Про множественные поломки хороша наглядная иллюстрация в другой его работе, «A brief look at the New Look in complex system failure, error, safety, and resilience»
Эта метафора известна в управлении рисками как Swiss Cheese Model и она вполне хороша по части наглядности, хотя, конечно, не учитывает, скажем, взаимовлияние разных «слоёв» защиты, так что в жизни, наверное, всё сложнее.
Что особенно интересно, Кук - врач, как я понимаю, практикующий анестезиолог, и написан был этот текст, имея в виду здравохранение. Для книги «Web Operations: Keeping the Data On Time» Ричард Кук написал дополнение «As It Pertains Specifically to Web Operations». И там тоже есть замечательные вещи, подтверждаемые практикой:
5. Maintenance will be a major source of new failures
Hardware and software maintenance including routine maintenance and upgrades will cause many failures, directly or indirectly. “Simple” failures with catastrophic consequences induced by maintenance procedures are a recurring theme in IT. There are at least two reasons for this. First, because they fiddle with live systems, maintenance procedures themselves are inherently dangerous. Maintenance almost always involves some sort of suspension of operations with a subsequent restart, and starting complex systems is a recipe for the discovery of new dependencies. Second, although patches and upgrades may receive extensive testing before installation, it is virtually impossible to re-create the operating environment in enough detail for the testing to cover all the modes of failure available to the real, much more complex, system. Every maintenance activity is, ultimately, an experiment. Experienced owners of large, complex systems are reluctant to perform maintenance or upgrades and this may lead to a kind of managerial paralysis: a working system, even one with known flaws, is a precious entity and so maintenance and, especially, upgrades are deliberately delayed because of fear of the failures that come from work on the system.
Эта глава из книги также доступна.
В общем, очень достойный текст. Рекомендую.
В этом году Кука пригласили на орейлевскую конференцию Velocity, где несколько недель назад он выступил с докладом «How complex systems don´t fail» про resilience engineering. Видеозапись доступна:
Click to viewЗабавно, что происходит кросс-опыление веб-технологий и медицины. Вот ещё один пример про постановку диагнозов: «House MD: Solving Complex IT Issues Using Differential Diagnosis».
Впрочем, получился уже достаточно длинный пост, пора остановиться.
Из дополнительных бонусов у вас теперь есть инструментальный критерий для определения сложной системы - достаточно посмотреть на профиль её поломок :)