Кто-то из коллег нечаянно нюкнул дб на проде. Пока никто не сознался, так что я жду расследования в духе агаты кристи.
ЛОГИ!!! Поднимите мне ЛОГИ! ‎- Все собаки попадают в рай
Заодно проверим, насколько хорошо работают сервисы rds по восстановлению этого всего. ‎- mark
^^ А теперь самая пикантная часть: логи системных команд хероку может и есть, но никто не знает, где их достать. Так что в принципе все, у кого есть доступ к рельсовой консоли, мог это сделать, что делает круг подозреваемых довольно широким. ‎- mark
Но с другой стороны в часовом поясе EST сейчас очень ранее утро, что делает круг подозреваемых довольно узким (если это произошло в ходе какой-то естественной операции). ‎- mark
@markizko: кажется что без Вия вам и правда не обойтись. Можно конечно со всех собрать каких-то локальных логов (не знаю каких правда). ‎- Все собаки попадают в рай
@larhat: На самом деле про детективное расследование это я художественно преувеличил, вроде ребята адекватные, хотя в такой экстремальной ситуации я еще с ними не работал. ‎- mark
rds point in time snapshot (http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PI... вот эта фича) кажется встал, если все пройдет хорошо, отделаемся легким испугом: двумя часами утреннего даунтайма (не критично) и потерей этих же двух часов данных ‎- mark
Предварительный постмортем такой: судя по всему, кто-то прогнал `heroku run rake db:reset` на проде и тем самым все сломал. К сожалению, системных логов либо нет, либо неясно где они (хероку не хранит их), нужно будет их обязательно ввести. По всей видимости, будем убирать у разработчиков доступ напрямую к командам на проде, теперь все манипуляции только через деплой/миграции. Общий ущерб, как и указано в комменте выше, два часа даунтайма и потеря данных за это самое время. Время восстановления снепшота 240гб базы составило примерно полтора часа. ‎- mark
Нашли логи команд хероку, ничего подозрительного там нет. Это значит, что скорее всего кто-то из разработчиков утащил credentials на доступ к дб (включая сертификат) с прода себе на локальную машину и уже на ней запустил `rake db:reset` или типа того. ‎- mark
@markizko: вот тут уже звучит опасно. Не так страшно что случилось, плохо что не понятно от чего ‎- Все собаки попадают в рай
@denistsyplakov: понятное дело. Просто у нас был процесс заточен под то, что совсем уж головотяпов нет, а теперь придется в каждую дырку защиту от дурака вставлять. ‎- mark
^ Вопрос не в головотяпах; такая защита всегда полезна. ‎- 9000
У меня такого в проектах пока не было, но я все равно разработчикам доступ на production и staging не даю, потому что в случае возникновения проблем велико искушение поправить все прямо там, а потом забыть фикс внести в version control. Очень мало кто с таким искушением справляется. ‎- Стадо овец
^ ^^ товарищи, доступ на прод разработчикам нужен не для фиксов (для них у нас миграции в коде), а для отладки проблем, на которые у нас нет ручек в админке. Корень проблемы тут, конечно, в том, что доступ к реплу в рельсах автоматически дает доступ ко всему вообще, если бы был вариант с ридонли, мы бы его уже использовали. ‎- mark
Ну понятно, что для отладки, но я таких случаях прошу команду заебаться, но сделать эмуляцию, мониторинг, протоколирование событий или в крайнем случае через desktop sharing из рук devops смотреть. Но тут понятное дело, что ситуации у всех разные. Бывают, наверное, варианты, когда это слишком сложно и дорого, поэтому проще выдать доступ прямой нужным людям. ‎- Стадо овец
доступ для отладки на прод - это так стремно, что я бы будучи разработчиком сам бы ни при каких обстоятельствах туда не полез бы. Я себя знаю и иллюзий не строю. ‎- Все собаки попадают в рай
Ну, случаи действительно бывают разные — у нас вот недавно от удара молнии временно накрылась вся локальная инфраструктура разработки, а баг чинить надо. Зашёл на сервер — не на прод, на тест, правда — отладил, починил и сделал патч, чтобы в гит выложить, когда он оживёт. Но это всё оттого, что сисадмина на том проекте практически и не было, иначе не было бы таких разрушений от грозы. ‎- и я ъувсесч вдруг
у меня на двух проектах отлаживались на продакшне и не парились. потому что 1) продакшн невоспроизводим в принципе 2) если девелопер может случайно подломать продакшн работая с одной из машин — надо чинить такой продакшн. (впрочем последний был настолько отказоустойчив, что успешно сопротивлялся, хаха, релизам нарушающим давно сформулированные и забытые инварианты) ‎- смешная третья опция
Что решили делать по итогу инцидента: убрали всякие ненужные доступы у разработчиков на прод (в т.ч. все виды heroku run и возможность подсмотреть/утащить credentials себе на рабочую машину). Для локальной отладки скорее всего запилим либо полную реплику прода на стейджинг-сервер, либо просто будем выдавать рид-онли аккаунты на дб (это покрывает добрые 99%, причин по которым разработчикам вообще нужен такой доступ). Ну и разная организационная фигня: более подробная документация восстановления после катастрофических сбоев, больше логгирования, большая гранулярность всяких там прав и так далее. ——— Банальные правила гигиены установим, короче. ‎- mark
@earwin: про инварианты интересно, расскажите. Это когда пытаешься сделать User.delete_all, а компьютер такой "к сожалению, я не могу тебе этого позволить, дейв"? ‎- mark
@markizko ещё хуже. специально обученный робот молча восстанавливал с соседних реплик то, что считал повреждённым, лез в архивы если целых реплик не оставалось, а когда поняли, что это он и попытались прибить или пропатчить — перезапускал и чинил сам себя до последнего. пикантность ситуации придавало то, что его основной автор уже уволился. ‎- смешная третья опция
^ звучит прикольно, конечно, но по-моему это один из самых легких способов завести "невозможные" баги, не? ‎- mark

2015-2016 Mokum.place