Разработчики сервиса непрерывной интеграции Travis CI (https://travis-ci.org/) раскрыли сведения (https://blog.travis-ci.com/2018-04-03-incident-post-mortem) об инциденте с повреждением инфраструктуры проекта 13 марта, в результате которого случайно была инициирована операция удаления всех таблиц из СУБД. В течение 30 минут после удаления сервис оставался доступен с повреждёнными данными, после чего был отключен на пять с половиной часов для проведения восстановления.
После восстановления всплыл неожиданный эффект - пользователи которые подключились к сервису за те 30 минут, что база оставалась повреждена, оказались подключенными под совсем другими аккаунтами. Подобный эффект объясняется тем, что для пользователей, которые вошли при пустой БД, были созданы новые записи и первичные ключи (данные в Travis CI синхронизируются с GitHub). После восстановления новые токены аутентификации не были очищены и стали указывать на совсем другие записи. После того как проблема была замечена, разработчики Travis CI примерно через сутки после очистки БД удалили проблемные токены и по логу всего один пользователь успел подключиться к чужим данным. Тем не менее, всем этим пользователям было направлено уведомление с предложением сгенерировать новые токены доступа.
Что касается причины удаления всех данных, то она кроется в давно забытом сеансе tmux на одной из рабочих машин проекта - когда-то давно один из разработчиков выполнял в данном сеансе инспектирование основной базы и оставил выставленной переменную окружения DATABASE_URL, указывающую на первичную БД. Много дней спустя разработчик в том же сеансе запустил локальный тест, в котором вызывался скрипт Database Cleaner (https://github.com/DatabaseCleaner/database_cleaner), выполняющий очистку всех таблиц пред генерацией тестовой нагрузки. Так как переменная окружения DATABASE_URL указывала на основную СУБД, то и очистка была запущена в контексте первичной БД.
Для того чтобы подобное не повторилось в будущем в БД было отозвано право очистки таблиц. Во внутренние скрипты добавлен обработчик (spec_helpers), проверяющий наличие переменной окружения DATABASE_URL, а в утилитах обеспечен вывод соответствующего предупреждения. В
gem-пакет Database Cleaner добавлена проверка на наличие переменной DATABASE_URL.URL: https://blog.travis-ci.com/2018-04-03-incident-post-mortem
Новость: https://www.opennet.ru/opennews/art.shtml?num=48414
Красивая история :) Бывает когда нажмёшь энтер и через секунду мозг понимает что ты допустим в правилах фаервола допустил ошибку а уже придётся ехать :)
iptables-apply в Debian уже десятилетие, наверное, но мозги продолжают ехать...
Он написал "допустим", так что ..
> ..а уже придётся ехать :)Причем, не просто ехать, а вот прям быстро-быстро ехать, пока звонки не начались!..
Скорее очередная грустная история о хиптсерах, которые не могу настроить разграничение доступов.
да-да, нужно позвать эффектного манагера.
Народная примета: удалённая настройка фаервола - к дороге.
это когда в правой панеле mc выделенные файлы ненужного бэкапа, а в правой - выделенные файлы удаленно подключенной боевой БД. Ты нажимаешь F8 -> Удалить все И СУДОРОЖНО ВСПОМИНАЕШЬ КАКАЯ ПАНЕЛЬ БЫЛА АКТИВНА.
в левой и правой, попутался от остроты вспомненного
Нередко осознание приходит уже в процессе полёта пальца к кнопке, но сознание уже не успевает отозвать команду.
Купите IP-KVM или настройте аварийный PXE boot.Хотя, может, вам ездить проще. Ну, не знаю. Когда датацентр в другой стране, вариант "ехать" вообще отсутствует. :)
Ну если вы в Нижнем Уренгое а датацентр в Ларнаке... Может и не все так плохо
Нижний Уренгой? O_o
> Красивая история :) Бывает когда нажмёшь энтер и через секунду мозг
> понимает что ты допустим в правилах фаервола допустил ошибку а уже придётся ехать :)Я себе в таких случаях делаю "watchdog timer". Запускается нечто, что ожидает подтверждения моего присутствия. Допустим в пределах часа. Если я за час достукаться не смог - все возвращается в вид как было. Или в вид который заведомо работает.
DATABASE_URL указывала на основную СУБД (смех нельсона)
"бывает"
Не хватает на опеннете стикеров, да?
Никогда не понимал все эти сервисы непрерывной интеграции. Зачем это? Интеграция ради интеграции? А когда же отдыхать?
> Никогда не понимал все эти сервисы непрерывной интеграции. Зачем это?Серьезно? Непонятно зачем автоматизировать то, что можно автоматизировать?
Хотя бы ради того, чтобы не тратить свое время на прогон всех тестов и
чтобы каждый гарантировать что каждый коммит компилируется, чтобы
git bisect нормально работал.
это вы CT описали.
А travis это все же больше к CI, и там выгоды от "автоматизации" ненужной деятельности не всегда перевешивают минусы. (ci =!= автодеплой) Скорее речь, как всегда, об "экономии времени" альтернативно-одаренных кодошлепов и их горе-тимлидов на нормальный release-management, скорей, скорей, смузи скиснет! (а там девопы как-то подлатают - больше падучих узлов запустят, или автоподнималку ускорят. Админ из такой конторы уволился пять лет назад.)
> Никогда не понимал все эти сервисы непрерывной интеграцииЧего там не понимать-то? Если совсем упрощённо - это автомат, который работает по схеме: закоммитили в наблюдаемую ветку -> CI собирает проект -> не собралось - плохо, ищем что сломалось (логи и отчёты в помощь) / собралось - хорошо, CI гоняет автотесты -> тесты где-то сфейлились - плохо, но хотя бы собирется, выясняем где фейлы (логи и отчёты тестов в помощь) / тесты успешны - можно деплоиться или что-там ещё делать по желанию -> далее по кругу с первого шага.
> Зачем это?
Затем, чтобы не делать всё это вручную.
> Чего там не понимать-то? Если совсем упрощённо - это автомат, который работает
> по схеме: закоммитили в наблюдаемую ветку -> CI собирает проект ->
> не собралось - плохо, ищем что сломалось (логи и отчёты в
> помощь) / собралось - хорошо, CI гоняет автотесты -> тесты где-то
> сфейлились - плохо, но хотя бы собирется, выясняем где фейлы (логи
> и отчёты тестов в помощь) / тесты успешны - можно деплоиться
> или что-там ещё делать по желанию -> далее по кругу с
> первого шага.Это хорошо можно прочувствовать только если проект собирается/прогоняется под N разных платформ и даже сборка не то что прогон под каждую из них занимает существенное время.
Ага. А писание рукой (не путать с рукоблудием!), причем православными школьными чернилами - "развивает мелкую моторику" (тм).Никогда не понимал тех, кто живет не в шалаше или сырой пещере, как "близкие к природе" предки...
> Ага. А писание рукой (не путать с рукоблудием!),
> причем православными школьными чернилами -
> "развивает мелкую моторику" (тм).А уж когда лекцию наговаривают, не особо тормозя на поворотах (как у нас в лицее) -- так ещё и навыки сжатия на лету развиваются буквально за пару недель. Не путать с путаньем всего со всем.
>> "развивает мелкую моторику" (тм).
> А уж когда лекцию наговаривают, не особо тормозя на поворотах (как у
> нас в лицее) -- так ещё и навыки сжатия на лету развиваются буквально за пару недель.Ну раз за пару - смело увольняйте "умников", которые каждый раз заново "наговаривают" то, чему место на 99% в слайдах презентации и готовых конспектах.
Если ты не понимаешь, зачем тебе CI, тогда тебе она не нужна. Ты не программист и не участвуешь в разработке многоплатформенного проекта с несколькими вариантами исполнения готового продукта.
Наверное он не понимает, как можно доверять важные вещи какому-то мутному поделию, которое пилят забывашки сеансов, запускающие не глядя что попало, где попало и как попало, а ты уже раздухарился неуважение высказывать. Не помнишь штоли смешные истории про гитлаб, например?
> как можно доверять важные вещи какому-то мутному поделиюда вы поехавшие. Какие вещи? "Доверять"? Это всего лишь триггер! "Условие выполнено - зеленый. Не выполнено - красный".
Я понимаю, что в вашей среде zip архивы вместо контроля версий и неделя на сборку версии и еще две на то, что бы обеспечить хоть какой-то запуск её - это норма. Но зачем же этим хвастаться
ты новость-то читал?
это уровень понимания кодошлепами и их тимлидами как новостей, так и вообще используемых ими технологий.зато у всех остальных, конечно же, зип и они "ничего не умеют".
Чем ci от ct отличается, похоже, тоже им не объяснили, давай-давай, проект не ждет пока ты разберешься в используемых тобой инструментах.
ct? вы хотя бы аббревиатуры расшифровывайте что ли
Вот да. CI знаю, CD знаю, CT — что-то внезапно родившееся в мозге нашего дражайшего поха. Не иначе как continuous testing (хотя CI включает и тестирование в том числе).
> ты новость-то читал?Отвал CI на несколько часов разработке не помеха, многие его наверняка вообще не заметили. Если такое случается раз в несколько лет, а не каждый день, то фигня.
> Никогда не понимал все эти сервисы непрерывной интеграции.
> Зачем это? Интеграция ради интеграции? А когда же отдыхать?Когда дезинтегрируется, а чинить вон тому парню...
> Много дней спустя разработчик в том же сеансе запустил локальный тест, в котором вызывался скрипт Database Cleaner, производящий очистку всех таблиц пред генерацией тестовой нагрузки.А я вот всегда если вижу старый терминал -- делаю новый. Кто его знает какие там тараканы с пауками успели завестись.
>> Много дней спустя разработчик в том же сеансе запустил локальный тест, в котором вызывался скрипт Database Cleaner, производящий очистку всех таблиц пред генерацией тестовой нагрузки.
> А я вот всегда если вижу старый терминал -- делаю новый. Кто
> его знает какие там тараканы с пауками успели завестись.а монитор из спящего включаете по пробелу/ентеру или по контролу?
только NumLock, только хардкор
Сеансы - это дефицитнейший ресурс! Их надо сохранять и многократно повторно использовать!
Мда,терминальные окна надо экономить, а то закончатся - придется покупать новые
> Мда,терминальные окна надо экономить, а то закончатся - придется покупать новыеВот Вы ёрничаете, а у них, поди, терминальные лицензии и так заканчиваются.
PS: ну мне тоже решительно непонятно, как вообще можно лепить такой скрипт, не выставляя тестовое окружение в нём же самом... "defensive programming придумали трусы".
У них тестовое окружение - на .org, который для "нищ*бродов" (Максим, ну это дикость, а не фильтры "неприемлемой лексики"!) и прочего опенсорса.Кстати, вроде там ничего в тот раз не ломали.
Представил такую ситуацию в гугл - "аккаунты всех пользователей удалены, потому что один из инженеров случайно стер бд с аккаунтами, теперь разобраться кому какие данные принадлежат - невозможно"
Восстановят из архивной копии АНБ.
> Восстановят из архивной копии АНБ.это еще зачем? Все что вы разболтали в гугле, может быть использовано против вас, но кто вам обещал, что мы вам это покажем?
Инженеры гугла могут только скрывать, удалять запрещено решением АНБ. Та же ерунда с телеграмом дурова, но говорят что у дурова уже нет ключей шифрования (не об OTR речь).
> Инженеры гугла могут только скрывать, удалять запрещено решением АНБвот еще. Пусть хоть обудаляются - наша копия никуда не денется.
кстати, забавная идея, учитывая что акаунты всех гуглосервисов нынче объединены в единственную хранилку... (нет, вы не то подумали, мы не хотим потерять нашего замечательного информатора)
>когда-то давно один из разработчиков
>Много дней спустя разработчик
>днейКакая милая попытка загладить вину :)
Да какая разница, сколько времени эта сессия висела? Цимес не в этом, а в том, что разработчик руками что-то делает на проде. У Travis CI отсутствуют CI и CD то бишь. Сапожники без сапог.
#авосьпронесёт #яжнедурак
Вполне себе нормальная ситуация, когда разработчик проверяет, что происходит на прод или запускает какую-либо аналитику для компании.
Никогда не доверял этим конфигурациям через переменные окружения. Больные люди это придумали, банальный config.ini и то лучше.