Как стать автором
Обновить

Про бэкапы, черную пятницу и коммуникации между людьми: как мы накосячили и научились больше так не делать

Время на прочтение9 мин
Количество просмотров22K
Всего голосов 51: ↑50 и ↓1+49
Комментарии36

Комментарии 36

Спасибо, очень поучительный пост!
Спасибо, рассказывать о таком, конечно, очень страшно.
Честные рассказы о том как вы факапили и исправляли ошибки делают вам большее доверие чем обычная реклама или сарафанное радио.
Спасибо.
Статья хороший сэлф анализ, но вам не кажется что все должно быть завязано словестно на «менеджера»? Как на счет начать использоваться CMS (Change Management System), всеобщий чат это прекрастно, но не удобно для маштабных работы. Чаты целесообразно открывать для каждой работы или проекта — для общего процесса работы нужен CMS, где поднимаются плановые работы на каждый конкретный участок с отметками что должно быть сделано, будет сделано и что остается в плане. Естесветнно все это должно сопровождаться нотификацими в NOC и ответственным инженерам + Project Manager. При необходимости включается пошаговая апрув система. Если работа с клиентом ведется прозрачно — необходимо заранее добавить в ключевые нотификации SPOC (Single Point of Contact) лицо, таким образом достигается прозрачность действий для всех звений процесса. Для NOC всегда указываются время начала и время конца плановых работ, Zabbix отлично справляется с такими задачами — в этом случае не возникает необходимости переподверждать временные рамки для конкретных действий

Для полного камильфо системы апрува привязываются к телеграмму или простым мэилам.
Как следствие накопленную базу плановых работ применяем к:
1. KPI для инженеров и проектов
2. База знаний для последующих работ
3. History лог для компаний
4. Расчет временных рамок работ для биллинга непосредственно для каждой компании

За статью спасибо, нравится когда люди анализируют ошибки
у нас основная работа идет в чатах, но чаты строго в телеграме и, при этом, серъезно интергрированы с системой управления проектами и мониторингом — вот здесь пишем об этом habrahabr.ru/company/itsumma/blog/335446

спасибо за коммент, приходите к нам в uptime.community поговорить ;), можно в телеграм канале telegram.me/uptime_community
можно в фб www.facebook.com/groups/uptime.community
Очень интересна судьба админа из первого случая, или его «простили»?
я бы не назвал это «простили», но если речь о штрафах/увольнениях — то нет, не штрафовали/не увольняли.
работу над ошибками проводили плотную и со всеми.
один раз ошибается каждый, и чаще всего — это из-за ошибок в процессах в компании
можно было бы опасаться за то, что такое повторится, но человек опытный а работа шла в огне.
А можно было спасти админа, если бы он видел все открытые алерты по клиенту и историю работы по ним? Например, один человек проводит какие-то работы по алерту, в результате чего приходит второй алерт (кончается место). Второй человек видит алерт и факт проведения работ на сервере. Стал бы он чистить xtrabackup?

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


Тут важно не наказывать, а разобрать кейс и изменить процессы таким образом, чтобы подобное не повторилось.

Это все хорошо, пока в роли менеджера разбирающийся человек, который не накричит на админа, который позвонил в 3 утра со словами «Что делать?».
Самое важное — здравый смысл, ответственность и умение думать наперед. А если у админов имеется такое качество как недоверчивость и желание перепроверить свои действия — то это замечательный администратор, на которого можно положиться.

Но от человеческого фактора избавиться невозможно, поэтому в бюджет компании следует закладывать такие неприятности :)

А у автора статьи в фирме весь бизнес как раз построен на том что менеджер разбирается.

НЛО прилетело и опубликовало эту надпись здесь
А почему в первом случае (когда пришел клиент с критически важной инфой и БЕЗ БЭКАПОВ (ну вот откуда вообще такие берутся :()), сразу первым делом не сделать бы полный бэкап на уровне сервера (снять образ диска например) и потом уже спокойно ковырять скрипты? Ну и если у них до 18 нагрузка — значит договариваемся на maintenance window после 18-19 и спокойно работаем.
Собственно, план и состоял в том, чтобы в первую очередь сделать бэкап и горячий резерв базы, с которого можно будет круглосуточно безболезненно снимать данные.

Способы снятия бэкапа, конечно же, обсуждались разные. И как в самом начале заметки говорилось, база у клиента была немаленькая, больше 2Тб. Никакого локального хранилища с толстым каналом, к сожалению, рядом не было. А на 100Мбитах тащить такой объём данных — это больше трёх суток в идеальных условиях. Т.е. «за пару часов вечером после шести» это было, увы, не решить.

Потому и было принято решение снимать бэкап в фоне экстрабэкапом.
Если клиент близко — то можно просто приехать к нему с носителем. Если далеко — попросить его админов подключить винт к серверу. Если сервер в ДЦ — то можно и еще один сервер/хранилище арендовать на месяц там же для временного бэкапа.
Вероятно я не в курсе каких-то тонкостей, но вот эти мысли приходят в голову в первую очередь.
Ну или вы там про отсутсвие слейва говорили — а почему бы его не поднять? После 18 же можно перезапустить MySQL?
Ну или вы там про отсутсвие слейва говорили — а почему бы его не поднять? После 18 же можно перезапустить MySQL?

Перезапустить, конечно, можно. Но чтобы где-то сделать слейв, туда сначала нужно унести данные базы. А сложности с перенесением данных я уже описал в предыдущем комментарии:)
Насколько помню, на репликацию вроде можно и пустой MySQL завести, и база потихоньку подтянется туда. В отличие от вышеописанного переноса данных — это будет прозрачно и незаметно.
— Хотя нет, похоже что вру :( Данные надо.
Что-то у меня не сходится…
А почему ibdata у процесса xtrabackup оказался помечен как deleted?
Ведь админ занулял только удаленные файлы.

Админ искал только удалённые файлы и хотел очищать только удалённые. Но на деле получилось так, что поиск по выводу lsof делался правильно, но потом некорректно передавались данные на команду очистки. Что-то типа такого было:

for i in 'lsof -p id_xtrabackup| grep -i dele' ; do echo ""> /proc/id-mysql/fd/$i ; done


И вместо id-mysql нужно было подставить айдишник экстрабекапа. Но увы.

Ну так это меняет дело. Я не понял этого при чтении статьи. Это меняет ситуацию с "Админ кое-чего не знал, а потому не очень виноват" на "Админ допустил явную ошибку и стопроцентно виноват". Напишите это в тексте статьи, желательно прямо приведя эту команду (пускай она приблительная), ну или сославшись на этот ваш комментарий. В тексте статьи написано:


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

Я сделал из этого комментария вывод, что админ не знал, что xtrabackup создаёт этот временный лог, и что именно это и было причиной "трагедии". Ну имеет право человек не знать? Не все же всезнайки. Так что админа можно понять. Но сейчас вы объясняете, что там дело не в незнании этого, а в банальном баге, когда вместо одного PID указан другой. Тут уже на незнание списать нельзя. Это явная ошибка, и админ явно виноват.


Также в вашей статье написано следующее:


Админ, запуская скрипт, зануляющий уже предписанные файловые дескрипторы, запустил его по pid MySQL и убил ibdata, которая весила 200—300 ГБ.

Так вот, при первом чтении я это предложение попросту не понял, а потому пропустил. А вот уже сейчас, при написании этого комментария, я прочитал его ещё раз, и наконец понял. В общем, "запустил его по pid MySQL" — это вообще какая-то мутная фраза. Как можно запустить по? Тут управление глагола нарушено, как сказали бы лингвисты. Надо сказать, например, запустил для. А лучше: "запустил для PID MySQL вместо PID xtrabackup". Ещё лучше: "написал PID MySQL вместо PID xtrabackup, хотя номера файловых дескрипторов брались у процесса xtrabackup".


Ещё один момент. Вы скажете, мол, хоть админ и написал один PID вместо другого, он всё равно не совсем виноват, т. к. ошибиться может любой. Так вот, да, возможно. Но есть принципиальная разница между тем, чтобы просто не знать, что у xtrabackup невидимый растущий лог, и тем, чтобы написать один PID вместо другого. Во втором случае можно придумать меры, которые гарантированно не позволили бы ошибиться. Например, принять правило о том, что любая команда и любой скрипт, запускаемый в продакшене, должен быть проверен ещё одним человеком, кроме того, кто её/его запускает. Или принять правило о том, что нельзя набирать команды на проде. Вместо этого их нужно копировать из заранее приготовленного документа, набранного в текстовом редакторе (именно такое решение приняли в Gitlab после одного инцедента). Или принять правило о том, что нельзя программировать на bash, и что вместо него нужно всегда использовать, скажем, python. И даже нельзя набирать сколько-нибудь сложные команды в командной строке bash. То есть apt-get install mc набирать можно. Но вот любую команду, содержащую "for" писать уже нельзя. Хочешь написать "for"? Нельзя, руки оторву. Напиши скрипт на python вместо однострочника на bash. Пускай даже этот скрипт на python будет на целый экран

Удалось ли после первого инцидента сохранить отношения с компанией-владельцем базы? Как вообще разруливали с ними эту ситуацию?
мы, с давних пор, исходим из того, что надо быть прозрачным с клиентом.
с момента события сразу сообщили о том, что происходит и продолжали поддерживать связь до исправления (это каждые 10 минут в следующие два дня).
клиенты оказались понимающие, бэкапы с той операции стали сниматься (а до этого не снимались год или больше и предыдущие специалисты говорили, что бэкапы снять нельзя)
мы обсудили, что один раз накосячить можно и работу продолжили
спасибо клиентам, отношения сейчас очень хорошие
Странно, если было бы как-то иначе. Вспоминаю, что и у нас подобное было. После этого как-то сразу деньги на оборудование появилось… :)

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

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

А менеджер — у своего менеджера? Через полгода, глядишь, можно и приступать к работе.

Если вы фриленсер и работаете с 5-10 постоянными клиентами то вы сам себе менеджер фактически. Вы все сами помните. Сами общаетесь с клиентами, выясняя все нюансы. Сами являетесь гарантом.


А теперь поднимаемся вверх и смотрим масштабы работы предприятия.


Вы предлагаете отдать все на откуп только одному админу? И зачем тут будент нужна фирма как таковая?

НЛО прилетело и опубликовало эту надпись здесь
В первом случае, всё-таки, надо было втыкать локальные диски в сервер и делать бэкап в туда. Вплоть до запуска второго мускула на нестандартном порту и подключения слейвом уже его.
А в первом случае не думали сделать снапшот диска, на котором жил MySQL что бы потом вытащить его и поднять из него бэкап. Или не было возможности?
Выше про это уже спрашивали:) Не было хранилища поблизости, на которое смогли бы за приемлемое время перенести такой объём данных. А через основной канал в 100Мбит не уложились бы ни в какой возможный даунтайм.

Всего-то надо было включить бинарный лог, а потом сделать обычный дамп с сохранением отметок из бинарного лога. Типа так:


mysqldump --single-transaction --flush-logs --master-data=2 --all-databases

В начале лога будет писаться что-то типа такого:


-- CHANGE MASTER TO MASTER_LOG_FILE='mysqld-bin.089207', MASTER_LOG_POS=107;

Потом этот дамп заливаем на слейве и запускаем репликацию, указывая начало в логе на мастере командой выше.


Да, конечно, всё это будет не быстро. Но наверняка.

А вы же точно понимаете, что xtrabackup именно так и работает, да? Только он, в отличие от мускульдампа не лочит базу при этом.
--single-transaction

This option sets the transaction isolation mode to REPEATABLE READ and sends a START TRANSACTION SQL statement to the server before dumping data. It is useful only with transactional tables such as InnoDB, because then it dumps the consistent state of the database at the time when START TRANSACTION was issued without blocking any applications.

Какие слова или фразы из этой цитаты из документации наталкивают вас на идею блокировки базы?


Для первичного бэкапа на слейв есть целый набор ключей для автоматизации этого счастья.

Да, действительно, --single-transaction в первом комментарии проглядел:)

Но в целом, это не отменяет того, что экстрабэкап делает, в общем-то, то же самое, только другими средствами. Ну и интересен ещё вопрос скорости выполнения на таком большом объёме данных.

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

В общем, «Всего-то надо было» звучит слишком оптимистично в контексте ситуации:)

Экстрабэкап может и отработал быстрее (только не отработал!), но в отличии от него обычный дамп не вызвал бы никаких вопросов у пришедшего по тревоге администратора. Ему из вывода ps сразу всё было бы ясно и понятно. Делается бэкап.


В статье пишут что вот — не информировали других сотрудников, а я о том что можно и не информировать вовсе, если не делать неожиданных вещей без необходимости. Всего-то.

[запоздало]
Хороший пост, все ошибаются. Но мне кажется, первая история немного про другое. Про то, что надо уметь говорить клиенту — нет. Не хочет выключать сервер и делать образ дисков, его нежелание понятно, но надо уметь настоять. Раз уж не сделали сразу по нормальному, кто-то должен страдать. Почему этим кто то должны были стать вы?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий