11:14 PM (леденящая душу история)
2006-09-24 10:32 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dastapovБыл обычный вечер обычного осеннего рабочего дня, спокойный, тёплый, ненапряжный. Падали листья с каштанов за окном, падали зелёные буквы скрин-сейвера в стиле "Матрица форевер", где-то далеко за океаном тихо падал индекс Доу-Джонса, падала среднесуточная температура, а с крыши парадного соседнего дома упал потянувшийся во сне кот. Нарушая эту вертикальную идиллию, не падали только сервера одной известной компании Z.
Криворукие программисты пытались валить их и глючными программами, и неоптимизированными запросами. Глупые пользователи пытались валить их странными запросами и бесконечными refresh-ами. Но сервера компании Z стояли насмерть.
Происходило это потому, что в компании Z была очень опытная "дежурная смена". Денно и нощно следили они за тем, чтобы все работало без сбоев и остановов. Все, что можно было "обнюхать" по SNMP - мониторилось, а где не было SNMP - были самописанные скрипты и программки, сводящие все жизненные показатели на большой монитор, на манер того, который можно увидеть в телевизоре, когда показывают центр управления полётами. Впрочем, я хотел рассказать не об этом ...
Вы замечали, что в жизни IT-специалистов поход на кухню за чашкой чая или кофе частенько играет прямо-таки судьбоносную роль, причем - не обязательно положительную? Именно во время вылазок на кухню в голову приходят судьбоносные идеи, тут обсуждаются самые сложные проблемы, но в то же время именно тут садятся пятна на новые джинсы, происходят Попадания На Глаза Злому Боссу и наполняются Роковые Чашки, которые затем опорожняются в клавиатуры и мониторы.
Также во время кухонных походов имеют обыкновение начинаться Большие Неприятности. Они подгадывают вое начало таким образом, чтобы вы, успели вернуться с чашкой тёплого ароматного напитка, разместить своё тело на стуле и сделать первый глоток, и тут - BANG! - "Houston, we've got a problem".
Об одной из таких неприятностей и пойдет речь.
В тот роковой день, в 23:09, ночной дежурный (назовем его, пожалуй, Марвин) окинул взглядом экран текущих alarm-ов и предупреждений ("все ОК") и пошёл налить себе ещё кофе. Вернувшись, он успел опустошить чашку примерно наполовину, прежде чем заметил, что "дело пахнет керосином". Судя по показаниям мониторов, стремительно росло количество необработанных запросов, которые система А не могла отправить системе B.
"Странно, неужели проспали переполнение дискового пространства у системы B? Или оракловую базу забили под завязку?". Марвин вызвал на экран соответствующие показатели и задумался. "Процент утилизации дискового пространства - 0%, размер БД - неизвестен, оракл недоступен".
Похоже, все было серьёзнее, чем казалось с первого взгляда. Что-то было не в порядке с системой B. Марвин открыл сеанс удалённого администрирования системы B (ssh root@systemb.z , su - systemb) и вывел список всех имеющихся директорий и файлов, т.к. наизусть средств администрирования системы B он не помнил. К его ужасу, вместо списка он увидел следующее:
Ни тебе файлов, ни тебе директорий. Ничего. Систему B как будто корова языком слизала. Марвина прошиб холодный пот, позабытый кофе тихонько остывал на краю стола. "Почему я? Почему именно на моей смене? Куда все делось? Кто виноват? Что делать?".
Последний вопрос был самым простым - надо было восстанавливать систему B из backup-ов, чем Марвин и занялся, решив отложить поиск ответов на все прочие вопросы на потом. Процесс восстановления затянулся до утра, но в конце-концов система B запустилась и заработала, как будто ничего особенного и не происходило. Довольный Марвин сделал запись в журнал, рассказал все сменщику и пошёл домой спать.
Сменщик пытался найти какие-то следы и причины, не накопал ничего особенного, а потом навалилась "текучка" и он забыл про ночное происшествие. Все сотрудники, имеющие доступ к системе B, клялись и божились, что "ничего не трогали". Странный инцидент обсудили на кухнях, но уже к вечеру жизнь вкатилась в привычную колею.
Ни завтра, ни послезавтра в поведении системы B не наблюдалось никаких заметных отклонений от нормы. А вечером третьего дня на ночную смену вышел Марвин, работавший по ночам в режиме "сутки через двое".
В 23:00 он чатился по Jabber со старым знакомым, периодически поглядывая на экран мониторинга. В 23:20 он пережил чёткое ощущение deja vu - растущая очередь запросов, 100% свободного дискового пространства, пропавшая с лица земли система В. Дальше - восстановление из backup-а (которое прошло гораздо быстрее, чем в первый раз), запись в журнале, доклад пришедшему на работу начальству, 30-минутный brainstorm-инг, не давший результатов, домой, спать. На кухне обсудили сложившуюся ситуацию и решили, что Марвин - парень неплохой, но дыма без огня не бывает. Уж больно подозрительно совпадало падение системы В с его ночными дежурствами.
Следующие два дня система В вела себя образцово.
На третий день Марвин опять выходил на работу в ночную смену. Первым делом он проверил, что система В - на месте. Система В как ни в чем не бывало перерабатывала байтики. Впрочем, расслабляться не стоило - до 23:00 было ещё далеко. Марвин исследовал crontab пользователя systemb, но не нашёл там ничего подозрительного. Более того - последний раз список периодически выполняемых процессов правили где-то год тому назад и запускались из него исключительно служебные скрипты системы В. Марвин исследовал историю логинов на сервер, но не обнаружил ничего подозрительного. Он исследовал системный crontab и crontab-ы других пользователей. Ничего. Он стал вычитывать служебные скрипты системы В. Все выглядело абсолютно нормально. Но Марвин понимал - если и сегодня система В упадет, ему будет очень сложно объяснить, что он не при чем.
В 23:00 Марвин запустил top и vmstat и твёрдо вознамерился поймать супостата.
23:05 ... 23:10 ... 23:14 ... Ага! Дисковая активность по vmstat, а в списке процессов появился rm! Марвин быстро "заморозил" его (kill -STOP) и начал искать, откуда он был запущен ... Система В была спасена.
Разгадка оказалось простой. Каждые три дня в 23:14 из crontab-а системы В запускался скрипт cleanup.sh, который (как видно из названия) занимался чисткой дискового пространства. Кто-то из администраторов системы В увидел, что одна из множества директорий с log-файлами архивируется, но почему-то не очищается и решил исправить этот досадный пробел. Тем более, что он собирался в отпуск и не хотел, чтобы в его отсутствие у системы В закончилось место на диске. Он нашёл нужное место в скрипте и дописал:
Дописал, и уехал в отпуск.
Ненужный пробел перед '*' привел к тому, что эта конструкция тихо и аккуратно сносила подчистую всю систему В. Раз в три дня. Как раз во время ночных дежурств Марвина.
Мораль: не занимайтесь last-minute fixes в продуктивных системах перед уходом в отпуск; тестируйте; храните код в системе контроля версий.
Криворукие программисты пытались валить их и глючными программами, и неоптимизированными запросами. Глупые пользователи пытались валить их странными запросами и бесконечными refresh-ами. Но сервера компании Z стояли насмерть.
Происходило это потому, что в компании Z была очень опытная "дежурная смена". Денно и нощно следили они за тем, чтобы все работало без сбоев и остановов. Все, что можно было "обнюхать" по SNMP - мониторилось, а где не было SNMP - были самописанные скрипты и программки, сводящие все жизненные показатели на большой монитор, на манер того, который можно увидеть в телевизоре, когда показывают центр управления полётами. Впрочем, я хотел рассказать не об этом ...
Вы замечали, что в жизни IT-специалистов поход на кухню за чашкой чая или кофе частенько играет прямо-таки судьбоносную роль, причем - не обязательно положительную? Именно во время вылазок на кухню в голову приходят судьбоносные идеи, тут обсуждаются самые сложные проблемы, но в то же время именно тут садятся пятна на новые джинсы, происходят Попадания На Глаза Злому Боссу и наполняются Роковые Чашки, которые затем опорожняются в клавиатуры и мониторы.
Также во время кухонных походов имеют обыкновение начинаться Большие Неприятности. Они подгадывают вое начало таким образом, чтобы вы, успели вернуться с чашкой тёплого ароматного напитка, разместить своё тело на стуле и сделать первый глоток, и тут - BANG! - "Houston, we've got a problem".
Об одной из таких неприятностей и пойдет речь.
В тот роковой день, в 23:09, ночной дежурный (назовем его, пожалуй, Марвин) окинул взглядом экран текущих alarm-ов и предупреждений ("все ОК") и пошёл налить себе ещё кофе. Вернувшись, он успел опустошить чашку примерно наполовину, прежде чем заметил, что "дело пахнет керосином". Судя по показаниям мониторов, стремительно росло количество необработанных запросов, которые система А не могла отправить системе B.
"Странно, неужели проспали переполнение дискового пространства у системы B? Или оракловую базу забили под завязку?". Марвин вызвал на экран соответствующие показатели и задумался. "Процент утилизации дискового пространства - 0%, размер БД - неизвестен, оракл недоступен".
Похоже, все было серьёзнее, чем казалось с первого взгляда. Что-то было не в порядке с системой B. Марвин открыл сеанс удалённого администрирования системы B (ssh root@systemb.z , su - systemb) и вывел список всех имеющихся директорий и файлов, т.к. наизусть средств администрирования системы B он не помнил. К его ужасу, вместо списка он увидел следующее:
systemb@systemb:~$ ls -l
total 0
Ни тебе файлов, ни тебе директорий. Ничего. Систему B как будто корова языком слизала. Марвина прошиб холодный пот, позабытый кофе тихонько остывал на краю стола. "Почему я? Почему именно на моей смене? Куда все делось? Кто виноват? Что делать?".
Последний вопрос был самым простым - надо было восстанавливать систему B из backup-ов, чем Марвин и занялся, решив отложить поиск ответов на все прочие вопросы на потом. Процесс восстановления затянулся до утра, но в конце-концов система B запустилась и заработала, как будто ничего особенного и не происходило. Довольный Марвин сделал запись в журнал, рассказал все сменщику и пошёл домой спать.
Сменщик пытался найти какие-то следы и причины, не накопал ничего особенного, а потом навалилась "текучка" и он забыл про ночное происшествие. Все сотрудники, имеющие доступ к системе B, клялись и божились, что "ничего не трогали". Странный инцидент обсудили на кухнях, но уже к вечеру жизнь вкатилась в привычную колею.
Ни завтра, ни послезавтра в поведении системы B не наблюдалось никаких заметных отклонений от нормы. А вечером третьего дня на ночную смену вышел Марвин, работавший по ночам в режиме "сутки через двое".
В 23:00 он чатился по Jabber со старым знакомым, периодически поглядывая на экран мониторинга. В 23:20 он пережил чёткое ощущение deja vu - растущая очередь запросов, 100% свободного дискового пространства, пропавшая с лица земли система В. Дальше - восстановление из backup-а (которое прошло гораздо быстрее, чем в первый раз), запись в журнале, доклад пришедшему на работу начальству, 30-минутный brainstorm-инг, не давший результатов, домой, спать. На кухне обсудили сложившуюся ситуацию и решили, что Марвин - парень неплохой, но дыма без огня не бывает. Уж больно подозрительно совпадало падение системы В с его ночными дежурствами.
Следующие два дня система В вела себя образцово.
На третий день Марвин опять выходил на работу в ночную смену. Первым делом он проверил, что система В - на месте. Система В как ни в чем не бывало перерабатывала байтики. Впрочем, расслабляться не стоило - до 23:00 было ещё далеко. Марвин исследовал crontab пользователя systemb, но не нашёл там ничего подозрительного. Более того - последний раз список периодически выполняемых процессов правили где-то год тому назад и запускались из него исключительно служебные скрипты системы В. Марвин исследовал историю логинов на сервер, но не обнаружил ничего подозрительного. Он исследовал системный crontab и crontab-ы других пользователей. Ничего. Он стал вычитывать служебные скрипты системы В. Все выглядело абсолютно нормально. Но Марвин понимал - если и сегодня система В упадет, ему будет очень сложно объяснить, что он не при чем.
В 23:00 Марвин запустил top и vmstat и твёрдо вознамерился поймать супостата.
23:05 ... 23:10 ... 23:14 ... Ага! Дисковая активность по vmstat, а в списке процессов появился rm! Марвин быстро "заморозил" его (kill -STOP) и начал искать, откуда он был запущен ... Система В была спасена.
Разгадка оказалось простой. Каждые три дня в 23:14 из crontab-а системы В запускался скрипт cleanup.sh, который (как видно из названия) занимался чисткой дискового пространства. Кто-то из администраторов системы В увидел, что одна из множества директорий с log-файлами архивируется, но почему-то не очищается и решил исправить этот досадный пробел. Тем более, что он собирался в отпуск и не хотел, чтобы в его отсутствие у системы В закончилось место на диске. Он нашёл нужное место в скрипте и дописал:
rm -rf system/logfiles/otherlogs/someobscurelogs/ *
Дописал, и уехал в отпуск.
Ненужный пробел перед '*' привел к тому, что эта конструкция тихо и аккуратно сносила подчистую всю систему В. Раз в три дня. Как раз во время ночных дежурств Марвина.
Мораль: не занимайтесь last-minute fixes в продуктивных системах перед уходом в отпуск; тестируйте; храните код в системе контроля версий.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2006-09-24 07:42 pm (UTC)уходом в отпуск
У меня с завтрашнего дня отпуск и я сегодня ваял программу. ;)
(no subject)
Date: 2006-09-24 07:46 pm (UTC)Эт хорошо что бекапы есть - но всеравно ж куча всего потерялась, что между бекапами...
(no subject)
Date: 2006-09-24 07:47 pm (UTC)На месте Марвина меня бы кондрат обхватил.
(no subject)
Date: 2006-09-24 07:51 pm (UTC)а вообще конечно, феерический нереальный censored :)
(no subject)
Date: 2006-09-24 08:54 pm (UTC)(no subject)
Date: 2006-09-24 09:30 pm (UTC)(no subject)
Date: 2006-09-24 09:35 pm (UTC)(no subject)
Date: 2006-09-24 11:00 pm (UTC)(no subject)
Date: 2006-09-25 04:07 am (UTC)В fido7 описывались случаи, когда работающую систему сносили rm -rf / и восстанавливали без перезагрузки.
(no subject)
Date: 2006-09-25 04:54 am (UTC)(no subject)
Date: 2006-09-25 04:57 am (UTC)(no subject)
Date: 2006-09-25 05:50 am (UTC)Разумеетрся, лишний пробел был опечаткой, а сервер был боевым. Backup'ов не было. Два дня чинили.
После длительного разбирательства и взаимных обвинений ("а ты не говори под руку!") вину возложили на неудобную клавиатуру ноутбука :)
(no subject)
Date: 2006-09-25 06:07 am (UTC)(no subject)
Date: 2006-09-25 07:44 am (UTC)(no subject)
Date: 2006-09-25 09:21 am (UTC)(no subject)
Date: 2006-09-25 09:56 am (UTC)(no subject)
Date: 2006-09-25 11:00 am (UTC)(no subject)
Date: 2006-09-25 11:01 am (UTC)(no subject)
Date: 2006-09-25 11:01 am (UTC)dpkg --get-selections | xargs -i apt-get install --reinstall {}
?
(no subject)
Date: 2006-09-25 11:02 am (UTC)(no subject)
Date: 2006-09-25 11:03 am (UTC)Те програмы, которым не требуется периодическое обращение к диску (типа /bin/init) даже будут продолжать нормально работать :)
(no subject)
Date: 2006-09-25 11:05 am (UTC)(no subject)
Date: 2006-09-25 01:26 pm (UTC)(no subject)
Date: 2006-09-25 03:45 pm (UTC)(no subject)
Date: 2006-09-25 03:47 pm (UTC)(no subject)
Date: 2006-09-25 04:00 pm (UTC)(no subject)
Date: 2006-09-25 04:14 pm (UTC)Более-менее помогают только 3 заповеди сисадмина:
1. backup
2. backup
3. backup
(no subject)
Date: 2006-09-25 05:20 pm (UTC)Тогда в лучшем случае попадет на бабло.
(no subject)
Date: 2006-09-25 05:24 pm (UTC)Не домашний ли каталог он просматривает? Он вполне может быть пустым. Или тут в конце пропущена / или одна ошибка наложилась на другую и был получен искомый результат.
(no subject)
Date: 2006-09-25 06:37 pm (UTC)(no subject)
Date: 2006-09-25 08:32 pm (UTC)Я сейчас вспомню только один:
/bin/ld-linux.so /bin/chmod +x /bin/chmod
Но все остальные были на порядок интереснее...
(no subject)
Date: 2006-09-26 02:36 am (UTC)Кстати, в копилочку неудачных опечаток - вместо find ./ -type f -exec chmod 600 {} \; однажды человек сделал find / -type f -exec chmod 600 {} \;
Чинили пол-дня, ладно рядом почти идентичная система была...
(no subject)
Date: 2006-09-26 02:38 am (UTC)(no subject)
Date: 2006-09-26 04:26 am (UTC)(no subject)
Date: 2006-09-26 05:47 am (UTC)(no subject)
Date: 2006-09-26 05:49 am (UTC)Всё было хорошо до тех пор пока DIR2 не был удалён со всей подсистемой которая его использовала...
(no subject)
Date: 2006-09-26 08:16 am (UTC)Если скриптописатель не обладает чутьём - почти обязательно.
Не знаю, насколько переносимо - bash точно умеет.
(no subject)
Date: 2006-09-26 09:39 am (UTC)(no subject)
Date: 2006-09-26 09:41 am (UTC)FreeBSD6 на 'rm -rf /' захочет ещё одно подтверждение (are you sure?)
(no subject)
Date: 2006-09-26 09:41 am (UTC)(no subject)
Date: 2006-09-26 10:31 pm (UTC)Мне тоже кажется, что в каждый человек должен быть на все руки мастер, и притом - непогрешимо правильный. А за саппорт должны отвечать люди, имеющие по 5 лет опыта за каждой строчкой в CV. И для тестирования любой ерунды должно быть время, тестеры, тестовые системы, спецификации...
Одна проблема - дороговато получается. Плюс - опять же проблема с тем, кто будет "сторожить сторожей", сиречь - проверять, что нормальные специалисты таки ничего не допустили ...
(no subject)
Date: 2006-09-26 10:32 pm (UTC)Вендоры, которые подороже, очень такие решения любят. Чтобы, значит, все было contained и manageable.
(no subject)
Date: 2006-09-26 10:32 pm (UTC)/etc/shadow и PAM он откуда возьмет, на голом диске-то?
(no subject)
Date: 2006-09-28 12:12 pm (UTC)Мусорный каталог кто-то пофиксил, как неиспользуемый, и *nix вместе с приложением исчезал на глазах изумленных админов с завидной периодичностью :-)