Падение

4 января 2021 года для многих людей во всем мире, также как и для большинства работников Slack был первым рабочим днем после нового года (за исключением специалистов горячей линии и службы поддержки, которые никогда не спят). В день Азии и утро в Европе прошло спокойно, но когда забрезжил рассвет в Америке мы стали получать сообщения от внешней службы мониторинга о росте количества ошибок. Мы начали разбираться, в чем дело. Ситуация с ошибками ухудшалась и мы инициировали процесс расследования инцидентов (о том, как у нас устроено управление инцидентами подробнее можно почитать в статье Райана Каткова (Ryan Katkov) All Hands on Deck https://slack.engineering/all-hands-on-deck/).

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

Чтобы сократить список возможных причин мы по-быстрому откатили некоторые изменения, которые были сделаны сегодня (забегая вперед дело было не в них). Также мы подключили еще нескольких человек из инфраструктурных групп, потому что процесс поиска сбоя шел медленно из-за того, что не работали панели мониторинга и оповещения. У нас сохранялся доступ к различным внутренним консолям и страницам статуса, к некоторым консольным утилитам, а также к системе сбора логов. Система сбора метрик тоже функционировала и мы могли запускать запросы к ней напрямую, но это было и совсем не так результативно, как как использование наших панелей мониторинга с преднастроенными запросами. Хотя наша инфраструктура в целом функционировала, мы видели признаки деградации сети, о чем мы сообщили AWS, нашему основному облачному провайдеру. На тот момент Slack работал в 6:57 по тихоокеанскому стандартному времени 99% сообщений успешно доставлялись (хотя это не было нормой, поскольку наше обычное значение этого параметра 99.999%).

Трафик в Slack имеет характерные всплески в начале и середине каждого часа, когда уведомления и другие типы автоматически создаваемых сообщений (большая часть из них внешняя это задачи cron со всего мира). У нас настроено масштабирование звена веб-служб и бэкэнда для того, чтобы подстроится под эти пики. Тем не менее всплеск нагрузки в 7 утра в сочетании с проблемами сетевой инфраструктуры привел к перегрузке звена веб-служб. С ростом нагрузки стали расти потери пакетов. Это, в свою очередь, привело к большим задержкам обращений веб-служб к бэкэнду, и их перегрузке. Slack упал.

В это время независимо друг от друга происходили две вещи. Во-первых, некоторые инстансы были автоматически помечены системой как проблемные, потому что они не могли достучаться до служб бэкэнда, от которых они зависели. Система попыталась заменить их новыми. Во-вторых, наша система автоматического масштабирования уменьшила размеры звена веб-сервисов. Так как мы работали без панелей мониторинга, некоторые инженеры, которые вели работы по данному инциденту подключались напрямую к сервисам, работающим на проде. У многих из них начали прерываться сессии SSH, потому что инстансы, с которыми они работали были отключены системой. Это еще больше затрудняло наши попытки разобраться в ситуации, поэтому мы отключили автоматическое уменьшение размеров системы. Это упростило работу по поиску сбоя и позволило стабилизовать производительность системы.

Наше звено веб-сервисов масштабируется на основании двух видов сигналов. Один из них, это загрузка процессоров (метрика, которая используется для масштабирования практически везде) а другой, это загрузка доступных рабочих потоков Apache. Проблемы с сетью до 7:00 означали, что потоки находились больше времени в режиме ожидания, что приводило к уменьшению загрузки процессоров, а это инициировало автоматическое уменьшения количества инстансов. Поскольку состояние сети продолжало ухудшаться, из-за чего звено веб-служб больше времени находилось в ожидании ответа от бэкэнда, что приводило к увеличению загрузки рабочих потоков, и система автоматически увеличила количество инстансов веб-служб. Между 7:01 и 7:15 мы попытались добавить 1200 серверов в наше звено веб-сервисов.


К сожалению, наше масштабирование не отработало как полагается. У нас работает сервис, удачно названный службой обеспечения (в оригинале provision-service прим. пер.) и его название полностью отражает его функционал, в который входит настройка и тестирование новых инстансов, а также выполнение роли управляющего для инфраструктуры. Службе обеспечения нужно взаимодействовать с внутренними системами Slack и c API AWS, а поскольку это взаимодействие происходило по той же нестабильной сети и поскольку, как и большинство систем Slack на тот момент, он тратил больше времени на соединение и получение ответа, и использовал больше ресурсов, чем обычно. Пиковая нагрузка, связанная с необходимостью ввести одновременно большое число инстансов в условиях нестабильной сети привело к тому, что служба обеспечения уперлась в системные ограничения (наиболее значимым из которых было ограничение количества открытых файлов в Linux, но также были превышены и квоты AWS).

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

В один прекрасный момент служба обеспечения заработала (было около 8:15) и начала запускать работающие инстансы. Ситуация стала понемногу улучшаться. У нас по-прежнему были некоторые проблемы с продом, часть из которых удалось смягчить, а другая была в процессе решения. Также мы до сих пор испытывали проблемы связанные с повышенным уровнем потери пакетов в сети. Несмотря на это в 9:15 у нашего звена веб-сервисов было достаточно работающих узлов чтобы переваривать входящий трафик. Из-за проблем с сетью балансировщики нагрузки показывали большое число проблемных узлов, но к счастью у них был режим panic mode https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/panic_threshold в котором балансеры начинают распределять нагрузку на все узлы независимо от результатов проверки их состояния. Это, плюс повторные соединения и паттерн circuit breaking, помогли нам возобновить работу сервиса. Да, Slack был медленнее, чем обычно, и частота ошибок была выше, но в 9:15 он уже работал, а не лежал, как до этого. Целый час ушел на то, чтобы снизить частоту ошибок до приемлемого уровня по двум причинам. Во-первых, из-за нестабильности сети нам требовалось больше инстансов, чем обычно, чтобы нормально обслуживать входящий трафик. Во-вторых, больше времени ушло на процесс развертывания опять же из-за проблем с сетью.


К тому времени, как Slack восстановился, инженеры AWS нашли причину сбоя: часть нашей сетевой инфраструктуры AWS действительно была перегружена, что и приводило к потерям пакетов.

Чтобы было проще понять, что же произошло, стоит рассказать немного подробней о некоторых архитектурных особенностях Slack. На старте, не так уж много лет назад, все, что касается работы Slack работало в одном аккаунте AWS. По мере роста размера, сложности и количества специалистов, задействованных в обслуживании системы, мы отказались от этого решения и разнесли сервисы по различным аккаунтам и VPC (Virtual Private Clouds). Это решение позволило нам добиться большей изолированности между различными сервисами, и позволяло более точно контролировать привилегии операторов. Для того, чтобы связать наши VPC, в качестве хаба мы использовали AWS Transit Gateways (TGWs).

4 января наши TGWs оказались перегружены. TGWs обслуживаются AWS и предполагается, что они должны масштабироваться незаметно для нас. Но в первые дни после нового года трафик Slack имеет необычную структуру, он ниже в выходные дни, поскольку все отвлекаются от работы (молодцы, что поддерживаете баланс работы и лично жизни, пользователи Slack, так держать!). В первый рабочий день кэши клиентов не прогреты и при первом подключении они подгружают больше данных, чем обычно, после нескольких дней затишья нагрузка растет до самых больших значений за год буквально в течении одной ночи.

Наши системы позволяют быстро отмасштабировать производительность систем, чтобы переварить нагрузку такого рода (и в прошлые годы мы всегда хорошо с ней справлялись). Но наши TGWs не смогли отмасштабироваться достаточно быстро. В ходе данного инцидента специалисты AWS были оповещены о нашей проблеме с потерей пакетов их внутренним мониторингом и вручную увеличили емкость TGWs. К 10:40 это изменение вступило в силу во всех зонах доступности (Availability Zones) и наша сеть вернулась к нормальному режиму работы, а с ним вернулись обычные уровни ошибок и задержки.


AWS заверили нас, в процессе разбора данного инцидента ими были пересмотрены алгоритмы масштабирования TGW для резких скачков объема трафика. А мы поставили себе напомнание (конечно же это было напоминание Slack slack.com/intl/en-ie/help/articles/208423427-Set-a-reminder) превентивно увеличить емкость TGWs в конце следующих новогодних каникул.

Выводы

Мониторинг является одним из наших наиболее критичных сервисов благодаря ему мы узнаем в порядке ли службы, с которыми взаимодействуют пользователи, а помимо этого это один из наших наиболее важных инструментов для выявления проблем. Мы прилагаем все усилия, чтобы наши инструменты мониторинга были как можно более независимыми от инфраструктуры Slack, чтобы они были доступны тогда, когда мы нуждаемся в них больше всего. В данной ситуации наши панели мониторинга и оповещения упали, поскольку базы данных, из которых они брали информацию оказались расположены в другом VPC, что привело к зависимости от TGWs. Запуск их в одном VPS позволит избавиться от этой зависимости.

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

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

---

Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Вы оказались на высоте десяти километров, и падаете без парашюта. Шансов у вас немного, однако небольшое количество людей, оказавшись в подобной ситуации, сумели выжить

6:59:00, высота 10 000 м

Вчера вы рано легли, а сегодня у вас был ранний рейс. Вскоре после взлёта вы засыпаете. И вдруг вы резко просыпаетесь вокруг вас свистит холодный воздух и раздаётся шум. Ужасный и громкий. Где я? думаете вы. Где самолёт?

Вы на высоте 10 км. Один. И вы падаете.

Неприятная ситуация. Самое время сконцентрироваться на положительных сторонах (да, кроме той, что вы выжили после разрушения самолёта). Гравитация работает против вас, зато другая сила на вашей стороне: время. Хотите верьте, хотите нет, но эта ситуация лучше той, в которой вы упали с балкона верхнего этажа отеля, приняв на грудь слишком много.

Ну, по крайней мере, она станет лучше. На таких высотах недостаточно кислорода, и у вас начинается гипоксия. Скоро вы потеряете сознание, и пролетите не меньше полутора километров до того момента, как очнётесь снова. А после этого вспомните этот текст. Ведь ваша следующая остановка поверхность Земли.

Конечно, шансы выжить после падения с десятикилометровой высоты чрезвычайно малы, однако оказавшись в подобной ситуации, вы ничего не потеряете, если хорошенько в ней разберётесь. С самолёта можно упасть двумя способами. Первый свободное падение, без всякой защиты и средств для замедления спуска. Второй стать наездником на обломках, как назвал эту ситуацию историк-любитель из Массачусетса Джим Гамильтон, собравший страничку исследований случаев свободного падения. Это что-то вроде онлайн-базы по всем случаям падений людей с высоты, после которых они выжили.

Во втором случае вы можете получить преимущество, если прицепитесь к какой-то части развалившегося самолёта. В 1972 году сербская стюардесса Весна Вулович находилась в самолёте McDonnell Douglas DC-9, летевшем над территорией Чехословакии, и внезапно взорвавшемся в воздухе. Она упала с высоты 10160 метров, будучи зажатой между сиденьем, тележкой с едой, частью фюзеляжа и телом ещё одного члена экипажа. Она приземлилась на заснеженном склоне, и перед полной остановкой соскользнула с него. В результате она получила серьёзные травмы, но выжила.

Выжить после падения, будучи окружённым немного защищающими тебя предметами, получалось чаще, чем выжить после падения без посторонних предметов. Известен случай Алана Маги, героя американского сборника удивительных фактов Ripley's Believe It or Not!. В 1943 году его самолёт B-17 сбили над Францией. Лётчик из Нью-Джерси упал с высоты 7 000 м, и столкнулся с крышей железнодорожного вокзала, после чего провалился внутрь. Впоследствии его взяли в плен немецкие войска, поражённые тем, что он выжил.

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

В зависимости от вашего размера и веса, и факторов типа плотности воздуха, ваша максимальная скорость окажется равной примерно 190 км/ч. Достигнете вы её удивительно быстро пролетев всего порядка 450 м (высота Останкинской башни 540 м). А равенство скорости означает, что вы врежетесь в тротуар с одинаковой силой. Разница только в промежутке времени. Спрыгнув с Останкинской башни, вы упадёте через 13 секунд.

После того, как вы выпадете из самолёта, у вас будет столько времени, что вы сможете прочитать почти всю эту статью.

7:00:20, высота 6700 м

Вы спустились достаточно низко для того, чтобы спокойно дышать. Ваше сознание резко вернулось. На такой высоте до падения остаётся около 2 минут. Ваш план простой: вам нужно войти в состояние дзена и решить выжить. Вы поймёте, что, как отметил Гамильтон, вас убивает не падение, а приземление.

Не теряя присутствия духа, вы прицеливаетесь.

Но во что? Падение Маги на каменный пол французского вокзала смягчила его стеклянная крыша. Стекло наносит травмы, но и помогает вам. Как и трава. Стога сена и кусты смягчали падение людей, которые потом удивлялись, что выжили. Деревья тоже подойдут, хотя на дерево можно и нанизаться, как на шампур. Снег? Конечно. Болота? С грязной поверхностью, покрытой растительностью ещё лучше.

У Гамильтона описан один случай с парашютистом, который после полного отказа парашюта спасся, спружинив от проводов линии электропередачи. А вот вода ужасный выбор, несмотря на популярное заблуждение. Жидкость, как и бетон, не сжимается. Упасть в океан по сути, то же самое, что упасть на тротуар. Только тротуар не раздвинется, поглотив ваше разбитое тело, как поясняет Гамильтон.

Выбрав цель, можно переходить к правильному положению тела. Чтобы замедлить спуск, изобразите парашютиста. Расправьте руки и ноги, грудь поверните к земле, выгните спину и голову вверх. Вы увеличите трение, и вам будет легче маневрировать. Но не расслабляйтесь эта поза не для приземления.

К сожалению для вас в такой ситуации, вопрос о наилучшей позе для приземления остаётся предметом споров. В исследовании от 1942 года в журнале War Medicine отмечалось, что распределение и компенсация давления играют большую роль в уменьшении травм. Рекомендация: приземление всей площадью тела. Однако в отчёте от 1963 года федерального агентства авиации утверждается, что переход в классическую позу парашютиста ноги вместе, пятки вверх, колени и бёдра сжать увеличивает шансы на выживание. В том же исследовании отмечалось, что людям помогают выживать навыки акробатики и борьбы. Особенно полезными для падения на твёрдые поверхности признаны занятия единоборствами. Обладатель чёрного пояса может, по отзывам, ломать дерево одним ударом, пишут авторы, считающие, что подобные навыки пригодятся в рассматриваемой ситуации.

Лучшим уроком по методу обучение методом проб и ошибок будет история японского парашютиста Ясухиро Кубо, обладателя мирового рекорда в банзай-категории парашютного спорта. Этот парашютист выбрасывал из самолёта парашют, затем прыгал следом за ним, выжидал максимально возможное время, потом догонял его, надевал и дёргал за кольцо. В 2000 году Кубо прыгнул с высоты в 3000 метров, и падал 50 секунд перед тем, как схватить свой парашют. Более безопасный метод обучения использования симуляторов-аэротруб, которые можно найти в различных парках аттракционов.

Но эти методы не помогут вам натренировать самую сложную задачу приземление. Для этого можно рассмотреть такой вариант хотя не сказать, что мы его советуем как прыжок с самого высокого моста в мире (на момент строительства), виадука Мийо. Одна из его опор имеет высоту в 341 метр, а внизу расположена упругая пашня.

Если вам приходится приземляться в воду, нужно очень быстро принимать решение. Изучение случаев, когда люди выжили после прыжка с моста, показывает, что максимизирует шансы выжить поза ноги вперёд, вытянувшись (карандашиком или солдатиком). При этом знаменитые прыгуны со скал в Акапулько [профессиональные артисты, участвующие в ежедневном шоу по прыжкам с высоты 30-40 м в воду в мексиканском местечке ла Кебрада / прим. пер.] предпочитают позу головой вперёд, со сжатыми вместе ладонями и вытянутыми руками для защиты головы. Что бы вы ни выбрали, сначала как можно дольше удерживаете позицию парашютиста. Затем, если вход в воду ногами вперёд неизбежен, самым важным в этой ситуации, по причинам как очевидным, так и неприличным, будет посильнее сжать ягодицы.

Какой бы ни была поверхность, определённо не стоит приземляться на голову. В исследовании о переносе ударных нагрузок при свободном падении 1977 года исследователи Института изучения безопасности шоссе установили, что основной причиной смерти при падениях а изучали они падения со зданий, мостов и в шахту лифта было повреждение затылка. Если уж вам приходится падать горизонтально, пожертвуйте красотой и приземляйтесь на лицо, а не на затылок. Также можете подумать над тем, чтобы брать с собой в полёт защитные очки Гамильтон говорит, что иначе при падении вам будет сложно прицелиться, поскольку из-за сильного потока воздуха у вас будут слезиться глаза.

7:02:19, высота 300 м

Учитывая вашу первоначальную высоту, к моменту, когда вы дочитаете до этого места в статье, вы уже будете подлетать к земле.

Прим. пер.: автор оригинала основывает расчёты на объёме английского текста и среднюю скорость чтения в 250 слов в минуту; на самом деле количество слов в оригинальном тексте статьи к этому моменту приближается к 1250, что отняло бы 5 минут на чтение, а речь идёт о трёхминутном падении. В русском переводе слов к этому моменту примерно столько же, но средняя скорость чтения по-русски оценивается в 180 слов в минуту. Всё-таки лучше прочитать эту статью до того, как вы упадёте с высоты.

Всё необходимое мы уже рассмотрели, поэтому можете концентрироваться на главной задаче. Однако, если что, вот вам дополнительная информация хотя, к этому моменту она уже мало вам поможет.

Статистически в данной ситуации шансов больше у члена команды воздушного судна, у ребёнка или у пассажира военного самолёта. За последние сорок лет произошло около десяти авиакатастроф с единственным выжившим. Среди описанных случаев четыре человека относились к команде воздушного судна, как, к примеру, стюардесса Вулович, а семерым не исполнилось 18. К ним относится и двухлетний Мохаммед эль-Фате Осман, прокатившийся на обломке реактивного самолёта Boeing, упавшего в Судане в 2003.

Возможно, члены команды выживают чаще из-за того, что их ремни лучше работают. А вот о том, почему детям удаётся чаще выжить, пока идут споры. В исследовании федерального авиационного агентства отмечается, что у детей, в особенности до 4 лет, скелет более гибкий, мускулы более расслабленные, а пропорция подкожного жира по отношению к весу тела больше это помогает защитить внутренние органы. Люди маленького роста когда голова оказывается ниже, чем спинка переднего сиденья лучше защищены от обломков разваливающегося самолёта. Меньший вес уменьшает предельную скорость падения, меньшая площадь тела уменьшает шансы наткнуться на что-либо при падении.

7:02:25, высота 0 м

Земля. Вы, как мастер из Шаолиня спокойны и подготовлены. Удар. Вы живы. Что дальше? Если повезёт, травмы будут не очень серьёзными, и вы сможете встать и выкурить в честь этого сигаретку, как британский хвостовой стрелок Нитколас Алкемейд в 1944-м. Он упал с высоты в 5500 м и приземлился на заснеженные кусты. Но скорее всего, вас ждёт тяжёлая работа.

Возьмём пример Джулианы Кёпке. Накануне рождества 1971 года её самолёт Lockheed Electra взорвался над Амазонкой. На следующее утро 17-летняя немка очнулась в джунглях, всё ещё будучи пристёгнутой к сиденью, и окружённой горой упавших рождественских подарков. Одна, с травмами, она сумела отвлечься от мыслей о гибели матери, сидевшей с ней рядом. Вместо этого она вспомнила совет отца, биолога: потерявшись в джунглях, в поисках цивилизации следуй за водой. Кёпке переходила от небольших ручейков к более крупным. Она обходила крокодилов, и тыкала палкой в грязи перед собой, чтобы распугивать электрических скатов. Во время падения она потеряла один ботинок, а её юбка была разорвана. Единственной едой, которую она нашла, был пакетик с конфетами, а пить ей приходилось только грязную воду. Ей приходилось не обращать внимания на сломанную ключицу и открытые раны, кишащие личинками.

На десятый день она присела отдохнуть на берегу реки Шибонья. Когда она встала, она вдруг увидела привязанное к берегу каноэ. Много часов у неё ушло на то, чтобы забраться на высокий берег, где стояла хижина, в которой её на следующей день нашли дровосеки. В Перу это случай посчитали чудом, и по статистике тут действительно не обошлось без божественного вмешательства. Согласно женевскому управлению регистрации авиакатастроф, в период с 1940 по 2008 года в 15 463 катастрофах погибло 118 934 людей.

Даже если включить в список выживших парашютистов, счёт подтверждённых или хотя бы убедительных случаев выживания в базе Гамильтона идёт на 157 человек из них только 42 случая произошли при падении с высоты более 3 км.

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

Или к этому моменту вы уже давно не спите, а колёса самолёта безопасно коснулись посадочной полосы. Вы понимаете, что вероятность катастрофы коммерческого самолёта невероятно мала, и что только что прочитанная информация вам вряд ли пригодится.