Инциденты Ч.1.
Если вы работаете над системами, которые делают что-то для пользователя вот прямо сейчас, вы так или иначе хотите видеть эту самую систему в стабильном работающем состоянии.
Сколько бы девяток вы не имели, две или пять, рано или поздно вы упадёте. Возможно, упадёте сильно.
Сегодня тлдр нескольких жирных инцидентов, которые произошли по абсолютно базовичковым причинам.
Knight Capital 2012
Когда-то это была одна из крупнейших трейдинговых фирм на американском рынке.
Что случилось:
- реализовали новую фичу под флагом (флаг взяли от старой фичи, а не сделали новый)
- раскатка нового бинарника происходила руками. На один из 8 подов сервиса забыли положить новый бинарник
- включили фичу
- с началом торгового дня заработала новая логика на 7/8 подов. На восьмом включилась старая логика (на самом деле даже не старая, а частично отпиленная старая).
Из-за того, что старая логика была частичной, её действия свелись к покупке некоторых активов в бесконечном цикле.
У чуваков не было адекватного обсервабилити, процесса дебага и инцидент-менеджмента.
Через 45 минут проблему починили, но за это время всадили >400kk$, что фактически обанкротило компанию.
Понятно, что проблема не в коде конкретного разработчика, и не в руках человека, отвечающего за деплой. Проблема скорее в общей инженерной культуре компании, которая, очевидно, идёт с самого верха к низу.
Но всё-таки прикиньте, каково быть тем самым/теми самыми разработчиками, действия которых привели к такому крупному инциденту. Пипяу.
Link: https://specbranch.com/posts/knight-capital/
British Airways 2017
Проблема британской авиакомпании -- подрядчик неаккуратно отключил питание в основном ДЦ.
Вообще-то был второй. Но он был запасным. На нём не было постоянной нагрузки. На него надо процессно переключаться при наличии проблем. Этого сделано не было, из-за чего авиакомпания осталась без возможности обслуживать фактически все пользовательские запросы.
Последствия: 75k пассажиров не улетели куда планировали, 1000 рейсов отменены.
Восстановление было довольно сложным, т.к. не было произведено аккуратного переключения на второй ДЦ, из-за чего много данных фактически стали битыми.
Link: https://www.theguardian.com/business/2017/jun/05/ba-inquiry-it-meltdown-airline-willie-walsh-passengers
Azure 2012
В посте про время я уже писал про один инцидент, связанный со временем (Cloudfare и не монотонность часов), но там это хотя бы что-то нетривиальное.
А вот в Azure ребята рофланули мощнейше.
Создавали они значит где-то в коде у себя какие-то сертификаты на доступность. Код был примерно таким:
DateTime issuedAt = DateTime.UtcNow;
DateTime expiresAt = issuedAt.AddYears(1);
Конечно же сертификаты, созданные 29ого февраля получали
expiresAt значение 29.02.2013, что не является валидной датой. В связи с особенностями архитектуры, ошибка привела к большому outage в нескольких регионах, т.к. с точки зрения системы очень много железа было неисправно.Это ж надо было такую либу написать, которая +1 год делает буквально +1 год.
Потрясающе ещё, что фактически этот код мог не меняться годами и стрельнуть только в этот самый отличный день. Не зря на собесах вас просят крайние случаи проговорить.
Link: https://www.wired.com/2012/03/azure-leap-year-bug/
Следующая порция когда-нибудь!
Ещё позже расскажу про мои любимые инциденты из личного опыта.