Был обычный вечер обычного осеннего рабочего дня, спокойный, тёплый, ненапряжный. Падали листья с каштанов за окном, падали зелёные буквы скрин-сейвера в стиле "Матрица форевер", где-то далеко за океаном тихо падал индекс Доу-Джонса, падала среднесуточная температура, а с крыши парадного соседнего дома упал потянувшийся во сне кот. Нарушая эту вертикальную идиллию, не падали только сервера одной известной компании 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-минутный 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 в продуктивных системах перед уходом в отпуск; тестируйте; храните код в системе контроля версий.