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

Решили мы тут озаботится вопросом, не расширить ли парк серверов баз данных — ресурсы есть, но нужно ли? Стали собирать статистику. Самым большим по количеству (75%) и объёму (90%) запросов оказался сайт Самого Важного Клиента, который занимал чуть ли не половину дискового пространства всего хранилища и отвечал за 60% всего трафика. Решили посмотреть, что они такое туда пишут.

Оказалось, разработчики этого чуда решили оптимизировать SQL-запросы и использовали какую-то чудо-библиотеку, которая на лету оптимизировала обращения к MySQL-кластеру. Результат оптимизации выглядел следующим образом: сначала происходит обращение на сервер с целью создания физического плана запроса, ждёт подтверждения, затем в него подсовываются входные параметры, забирается результат, но тут происходит самое страшное — физический план запроса удаляется. То есть при каждом однотипном запросе физический план создаётся заново. Но и это не самое страшное. Половина всех запросов выглядела так:

INSERT INTO `statistic_logs` VALUES ...

В результате простейший запрос, занимающий одну строку и являющийся элементарной операцией MySQL-сервера, после «оптимизации» занимал восемь строк и выполнялся в полтора раза медленнее.

Многие работающие в саппорте жалуются на неадекватных пользователей, а как быть, если саппорт сам не знает ничего о том, что поддерживает?

История произошла по причине моего увлечения опенсорсом. Как не крути, а GNU/Linux от известных мейнтейнеров работает на старом железе гораздо надёжнее и стабильнее, нежели «популярная» ОС. Всё началось с малых экспериментов над одной программой для оборудования с ЧПУ. Поставил Дебиан и Вайн, первый же блин вышел комом — нет связи по COM-порту, точнее, есть, но очень нестабильная. Погуглив, нашёл патч для драйвера, исправлявший этот недостаток. Накладывать пришлось, конечно же, напильником, благо С я немного знал.

Всё прекрасно работало в течение нескольких месяцев, пока не пришло обновление. Оно-то тоже работало, да вот только базы данных в этот раз должны были быть в клиент-серверном варианте, да ещё и через сторонний драйвер. Из-за некоторых ограничений Вайн не мог такие костыли поддерживать, но я немного покопался и нашёл-таки способ использовать локальные базы.

Далее состоялась феерическая переписка с саппортом, который уверял, что баз данных в нужном мне формате не существует и существовать не может. Плюнув на это, за два вечера была методом проб и ошибок составлена локальная БД, но вот беда: в программе использовали серверный SQL, который неприменим для локального использования.

Это уже была серьёзная проблема, которую пришлось «выпилить» банальным hex-редактором, благо сама же программа выдавала окна с указанием ошибок в синтаксисе запросов. Так-то, лучший саппорт — голова на плечах.

Третьего дня свёл знакомство с одной проблемой. Наши одиночества встретились весьма прозаичным способом: я жил и писал странные команды в консоли, а она родилась хоть и тихо, но зато сразу всех обрадовала — точнее, сначала заказчиков. Потом они вместе пришли и всем своим видом показали: «А вот и мы!» Бага была из разряда пренеприятнейших — пряталась умело, возникала внезапно и при возникновении сразу знала, куда наносить удар. Именно в то место, где сходятся интересы всех без исключения — в финансовые расчёты.

В процессе ловли ошибки я много времени провёл наедине с базой данных. Нужно упомянуть, что я работаю в области строительства цифрового телевидения. Так вот, обнаружилось странное — приличное количество абонентов по непонятной причине подписывает и отписывает один и тот же сервис по несколько раз за день, да и еще с завидным упорством повторяет эти действия на протяжении месяцев! Причину такого странного поведения понять стало даже интереснее, чем ловить багу, про которую уже все забыли. Так как в базе все сущности связаны хитросплетением ID, «констрейнтов» и прочих «форейнкеев», на первый взгляд кажется, что люди просто любят мелькание менюшек на телевизоре.

Всё обрело смысл, как только я выцепил человеческое имя этого сервиса. Им оказался пакет каналов «Досуг». Да-да, набор каналов с замечательными девушками и их хирургическими достижениями. Изучение результатов выполнения запросов показало, что для удовлетворения среднестатистическому пользователю нужно от двух до пятнадцати минут. Как правило, люди склонны к изучению своего внутреннего мира с утра и после работы. И самое главное — все склонны скрывать свою страсть к подобного рода времяпрепровождению, так как отключают сервис сразу после выполнения задуманного.

Закончив интересный анонимный соцопрос, я подумал: «Как же хорошо быть айтишником!»

Не секрет, что хороший программист должен обладать даром предвидения, чтобы знать, что нужно заранее предусмотреть в проекте и к каким модификациям проект должен быть готов. Те, у кого такого дара нет, либо выкручиваются перестраховками, либо по нескольку раз переписывают одну и ту же программу.

Недавно мне на глаза попались исходники одного скрипта регистрации на сайте; среди прочих была и графа «пол» — пара радиокнопок. Не знаю, сколько раз человек, писавший этот скрипт, сталкивался с бесконечно меняющимися требованиями заказчиков, но этот перл, по-моему, является верхом перестраховочной паранойи.

Среди прочих таблиц в базе данных была таблица «sexes»: идентификатор и название, две строки. В профиле у каждого пользователя хранился идентификатор нужной строки. Интересно, предусмотрел ли что-нибудь автор на тот случай, если на ключ этой таблицы перестанет хватать четырёх байт?

Довелось мне работать в местном интернет-провайдере. Помимо предоставления телекоммуникационных услуг, фирма зарабатывала на создании различных тематических сайтов. Одним из них был сервис по отсылке SMS-сообщений, которые клиенты нашей сети могли отправлять бесплатно.

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

В один прекрасный день клиент пришёл прямо к нам в офис и попросил поменять пароль на его логин в SMS-системе. Быстро найдя в базе номер его записи, я слепым десятипальцевым методом быстро ввожу типичный запрос:

update users set password='newpass' where id - 1234;

...и жму Enter. Вместо знака равенства нажалась клавиша «минус». В результате база данных, вычислив разность между номерами клиентов и заданным числом, поменяла пароли всем, кроме этого клиента.

Следующие два часа ушли на восстановление паролей недельной данности, а ещё где-то месяц мы отвечали на гневные звонки тех, кто за эту неделю менял свой пароль.

Проверяйте запросы перед выполнением!

Служба поддержки клиентских серверов неоднократно упомянутого датацентра.

Один из серверов был сильно перегружен клиентскими сайтами и в конце концов перестал отдавать контент: пошел в своп, а load average зашкаливал за полсотни. Начинаем вместе с клиентом выяснять, чем же его так. В выводе top налицо активно лопающий память MySQL-сервер, каковым фактом мы радуем клиента и рекомендуем оптимизировать запросы. Клиент отвечает: «Сайт не использует базу данных этого сервера, а работает с удалённой базой».

Сообщаем клиенту, что его сайт на его же сервере не один, и остальные всё-таки потребляют ресурсы и «укладывают» машину. Ответ клиента ошеломил:

— Ммм, а сколько сайтов находится на нашем сервере, и каких именно?

Много лет в крупном операторе фиксированной связи российского масштаба не было постоянного и квалифицированного системного администратора. Люди приходили и уходили, а знания, пароли и учётные записи уходили вместе с ними. Сервера безвозвратно падали, с ними падал софт, включая базы данных, хитрый, созданный ещё в советское время биллинг, подсистемы программирования кристаллов таксофонных карт и прочее.

Вот уже не осталось носителей знаний, и даже некому было поставить клиент Navision Axapta. Каково же было моё изумление, когда хрупкая девушка попросила меня подойти к ней! На экране — удалённая оснастка, вход в локальную базу и какой-то мелкий вопрос, как правильно делать бэкап. Оказалось, что многие годы эта героическая девушка из бухгалтерии по инструкции еженедельно делала бэкап самой важной базы, как ей и заповедовал один из основоположников всей этой системы.

Факап, конечно, не такой страшный, как слетевшая с направляющих каретка или заваленный мусором кот, но тоже неприятный.

Был я айтишником в одном турагентстве. Как-то, шерстя базу данных, я нашёл информацию о ценах в отелях на ближайшие три года. Спрашиваю у генерального директора, как это так: то ли у нас ясновидец в штате появился, то ли отели по три года не меняют цены в условиях инфляции? Босс ответил, что данные туда попали по ошибке, и их надо удалить.

Всего один короткий запрос. Всего две забытые кавычки:

delete from prices where price_date>unix_timestamp(2009-12-31)

Сервер радостно подсчитал: 2009 – 12 – 31 = 1968. Как и было заказано, база данных грохнула цены на все даты позже 1968 секунд от начала юникс-эпохи (то есть после 0 часов 32 минут 42 секунд 1 января 1970 года). На тот момент не существовало не только самой фирмы, но даже и самого гендиректора.

В итоге все отели лишились всех цен. Вытаскивать в авральном режиме из бэкапов несколько сотен тысяч строк вручную было ой как весело...

Говорят, что если усадить миллион обезьян за печатные машинки, то с ненулевой вероятностью одна из них наберет «Войну и мир». У одной обезьяны, похоже, получился CMS.

Отдел поддержки клиентских серверов датацентра. Приходит клиентское письмо с жалобой: «После обновлений базы товаров нашего интернет-магазина сайт перестаёт работать и вообще». Сайт вольготно размещён в одиночку на сервере с двухъядерным процессором и 2 ГБ памяти — проблем с производительностью быть не должно. Прошу пнуть нас именно в момент обновлений.

Дожидаюсь ответа «вот сейчас не работает!» Смотрю — на машине оба ядра под завязку нагрузил MySQL. Логинюсь в «мускуль», даю запрос show full processlist. Изумляюсь — терминал виснет наглухо. Передёрнув терминал и залогинившись обратно на машину, запускаю тот же запрос с выводом в файл. Смотрю в результаты: сервер отрабатывает два запроса общей длиной в 1,2 с копейками мегабайта.

Как выяснилось, чудо-фронтэнд магазина выгребал какие-то данные запросом вида «Select * from Таблица where productID='такой-то' and enabled=1 or productID='еще_какойто' and enabled=1 or...», и так до упора. Несчастный MySQL вдумчиво проверял каждую строку немаленькой таблицы на соответствие десяткам тысяч логических условий.

Клиенту отписал, приложив результаты show full processlist. Молчит уже сутки. Видимо, проникается идеей...

Сижу себе вечером дома, пересобираю компьютер, плавненько добираюсь до распределения информации на винчестеры, раздаю задания несчастному Акронису, запускаю его работать и иду на кухню пить чаёк.

Душевное равновесие начал нарушать мобильник. Заговорив голосом сменщика, он слёзно закричал о том, что всё пропало. После оказания скорой антисуицидальной помощи оказалось, что это криворукое тело по ошибке снесло всю базу данных фирмы. Хватаюсь за голову, но тут же успокаиваюсь: предвидя такой исход, я время от времени бэкаплю базу.

Наливаю чаёк, возвращаюсь в комнату к компьютеру, пытаюсь вернуть себе душевный покой. Акронис покорно копирует раздел, на котором находится тот самый бэкап. Лампочка над головой начинает неслабо моргать. «Напруга!» — проносится в голове. Перед глазами всплывают картины бурной молодости: сожженные сетевухи во время грозы в общаге, несколько блоков питания, отказавшихся питаться тем, что было в розетке... От сердца снова отлегает — компьютер-то воткнут через фильтр! За пять секунд до достижения мной стабильного уровня душевного равновесия лампочка тухнет.

Первые полсекунды я в священном ужасе смотрю на монитор, на котором только что изображался процесс переноса раздела с бэкапом базы. Вторые полсекунды я с наслаждением, граничащим с оргазмом, наслаждаюсь писком бесперебойника. Но спокойно чай попить мне все равно не удалось, потому что через две минуты бесперебойник сказал «кряк-кряк-кряяяяяяк-бзжжжжжжжжж», а в воздухе запахло горелым. Не успев сообразить, что к чему, с трудом в темноте выдёргиваю из бесперебойника все провода — треск прекращается.

Только наутро отпоенному корвалолом и слегка выспавшемуся мне улыбнулась удача: бэкап нашелся и на флэшке в тридцать два гига, на которой я таскал его домой. С конторы, продавшей мне бесперебойник, я таки срубил «компенсацию ущерба», но вот к своим нервам я с тех пор отношусь очень бережно.