леденящая душу история
Был обычный вечер обычного осеннего рабочего дня, спокойный, теплый, ненапряжный. Падали листья с каштанов за окном, падали зеленые буквы скрин- сейвера в стиле "Матрица форевер", где-то далеко за океаном тихо падал индекс Доу-Джонса, падала среднесуточная температура, а с крыши парадного соседнего дома упал потянувшийся во сне кот. Нарушая эту вертикальную идиллию, не падали только серверы одной известной компании 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 он не помнил. К его ужасу, вместо списка он увидел следующее:
systemb@systemb:~$ ls -l
total 0
Ни тебе файлов, ни тебе директорий. Ничего. Систему B как будто корова языком слизала. Марвина прошиб холодный пот, позабытый кофе тихонько остывал на краю стола. "Почему я? Почему именно на моей смене? Куда все делось? Кто виноват? Что делать?".
Последний вопрос был самым простым - надо было восстанавливать систему B из backup’ов, чем Марвин и занялся, решив отложить поиск ответов на все прочие вопросы на потом. Процесс восстановления затянулся до утра, но в конце концов система B запустилась и заработала, как будто ничего особенного и не происходило. Довольный Марвин сделал запись в журнал, рассказал все сменщику и пошел домой спать.
Сменщик пытался найти какие-то следы и причины, не накопал ничего особенного, а потом навалилась текучка и он забыл про ночное происшествие. Все сотрудники, имеющие доступ к системе B, клялись и божились, что "ничего не трогали". Странный инцидент обсудили на кухнях, но уже к вечеру жизнь вкатилась в привычную колею.
Ни завтра, ни послезавтра в поведении системы B не наблюдалось никаких заметных отклонений от нормы. А вечером третьего дня на ночную смену вышел Марвин, работавший по ночам в режиме "сутки через двое".
В 23:00 он чатился по Jabber со старым знакомым, периодически поглядывая на экран мониторинга. В 23:20 он пережил четкое ощущение deja vu - растущая очередь запросов, 100% свободного дискового пространства, пропавшая с лица земли система В. Дальше - восстановление из backup-а (которое прошло гораздо быстрее, чем в первый раз), запись в журнале, доклад пришедшему на работу начальству, 30-минутный brainstorming, не давший результатов, домой, спать. На кухне обсудили сложившуюся ситуацию и решили, что Марвин - парень неплохой, но дыма без огня не бывает. Уж больно подозрительно совпадало падение системы В с его ночными дежурствами.
Следующие два дня система В вела себя образцово.
На третий день Марвин опять выходил на работу в ночную смену. Первым делом он проверил, что система В - на месте. Система В как ни в чем не бывало перерабатывала байтики. Впрочем, расслабляться не стоило - до 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 в продуктивных системах перед уходом в отпуск; тестируйте; храните код в системе контроля версий.
Dmitry Astapov //ADEpt
Происходило это потому, что в компании 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-минутный brainstorming, не давший результатов, домой, спать. На кухне обсудили сложившуюся ситуацию и решили, что Марвин - парень неплохой, но дыма без огня не бывает. Уж больно подозрительно совпадало падение системы В с его ночными дежурствами.
Следующие два дня система В вела себя образцово.
На третий день Марвин опять выходил на работу в ночную смену. Первым делом он проверил, что система В - на месте. Система В как ни в чем не бывало перерабатывала байтики. Впрочем, расслабляться не стоило - до 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 в продуктивных системах перед уходом в отпуск; тестируйте; храните код в системе контроля версий.
Dmitry Astapov //ADEpt
Сетевые решения. Статья была опубликована в номере 12 за 2006 год в рубрике PRIcall
