Было дело в начале двухтысячных. Работал я в крупной торговой компании; была, естественно, БД со всей жизнью компании внутри. Крутилась в тот момент база на Oracle 8.1.6. И была в учётной политике тогда дурная технология по очистке справочников от неактивных клиентов. Задача ерундовая, на пять-семь строк размашистого кода.
Накопилось опять несколько потенциальных клиентов на убиение. Запускается скрипт — «Получен конец файла по коммуникационному каналу». Это клиент так оповещает, что связь с сервером — тю-тю. Смотрю на службу, а она действительно тю-тю, то есть совершенно в дауне. Запускаем — всё нормально поднялось. Повторяем и... правильно, читаем про конец файла.
Становится интересно — начинаем грохать по одному клиенту. Первый — нормально, второй — нормально, и так далее, пока не попадается нечто с названием «Чего-то-там-Гранит». И на этом гранитном орехе происходил коллапс.
Потом, конечно, и версия движка была повыше, и дурные принципы были пересмотрены, но до сих пор я уверен: неспроста тогда это было, ох, неспроста!
С разным софтом приходится иметь дело приходящим админам. Плохо пишутся офлайновые банк-клиенты, и каждый плох по-своему. Плохо пишут ПО в рамках выигранных в госконторах тендеров. До сих пор перед глазами, как живая, аксессовая «субдина» для бухгалтерии организации, имеющей шестьдесят одновременно трудящихся бухгалтеров — кто по RDC, кто напрямую — на одну несчастную .mdb. Но речь пойдёт не о них.
Программу, которая на конкурсе кривых программ возглавляла бы жюри, написал иностранный специалист. Нет, не индус — болгарин. Во избежание узнавания реальных лиц, с которыми ещё работать и работать, предметная область в повествовании будет абстрактной.
Многие в курсе существования понятия нормализации реляционных баз данных. И некоторые даже знают, что есть формы этой самой нормализации — от первой до пятой. Но никто никогда не сталкивался с болгарской нормальной формой, с которой я вас сейчас познакомлю.
При нормализации реляционной базы данных до болгарской нормальной формы на каждый учитываемый объект заводится от 7 до 50 штук маленьких, но очень гордых .dbf, в каждом из которых парой строчек описывается очередной признак или атрибут объекта. И не ссылками на записи в библиотеках, а именно сами признаки и атрибуты — словами. Надо ли объяснять, что при накоплении пары сотен тысяч объектов база распухает до сотен гигов этих самых мелких файликов? Для пущего антуража пишется всё это безумие на болгарифицированном FoxPro. Вы знаете, что означают слова «грешка» и «забележка»? А любой специалист, пытавшийся работать с этим чудом, знает, что это «ошибка» и «ярлык».
База размещается строго в папке, в которой установлена программа, а программа — строго в C:\%ProgramName%\, и никаких компромиссов. Экзешник должен быть запущен из-под админской учётки — это защита от воровства такая, программа постоянно тычется в сервак горе-разработчика, подтверждая свою легальность. Папка программы обязательно должна быть расшарена на полный доступ. Мало того, должен быть открыт полный доступ к трём DLL в System32, как вы его организуете — ваша забота. Приложения работают непосредственно с базой напрямую, программист не слышал ни о каких технологиях доступа к данным.
Всё это венчает достойная отдельного абзаца монументальная Марья Петровна, «человек-за-всё», с ложкой в правой руке в качестве скипетра и литровой банкой домашних щей в левой в качестве державы ведущая активную работу на имеющем безлимитное подключение к инету P4 с одним IDE-винтом на 160 гигов — рядом с мокрыми зимними сапогами, без бесперебойника, на одном оплавленном удлинителе с калорифером. (Выдохнул.) Мечта админа.
Общение с разработчиком всегда проходит весело, потому что он полон энтузиазма и пишет кириллицей, но с очень-южно-славянским колоритом. Оказывается, о нормальных формах он тоже слышал от кого-то, кто когда-то видел тёщу живого программиста. Но он считает, что один большой файл может повредиться, и тогда умрёт вся база данных, а если накроются несколько мелких файлов, никто и не заметит.
К сожалению, рынок сбыта этой программы ограничен спецификой предметной области, и нормально профинансировать разработку ПО на замену этому безобразию — дело довольно рискованное. Так что конкурентов у этого чуда практически нет, и возрастает ценность меня как специалиста по болгарским нормальным формам, знающего, куда бить кувалдой в случае чего.
На работе прислали новую версию программы. Старая версия была ужасна — новую я уже «люблю» за вот такой пассаж из прилагаемой инструкции:
Пользователи версии 2.01 могли заметить ошибку при автоматической нумерации выдаваемых справок. Данная ошибка возникает из-за неравномерности записи данных в базу. Эта неравномерность вызвана неправильной эксплуатацией вашего компьютера, а именно возникает от частой записи и удаления файлов (или программ) больших объёмов. Чтобы устранить эту неравномерность, необходимо регулярно проводить дефрагментацию логических дисков вашего компьютера.
Зацените, как надо делать — валить глюки своей проги на фрагментирование диска! Это ж додуматься надо.
Руковожу хостингом одной некрупной, но гордой компании. Перлов при работе с клиентами много, но больше бывает при общении с разработчиками.
Решили мы тут озаботится вопросом, не расширить ли парк серверов баз данных — ресурсы есть, но нужно ли? Стали собирать статистику. Самым большим по количеству (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-сервер, каковым фактом мы радуем клиента и рекомендуем оптимизировать запросы. Клиент отвечает: «Сайт не использует базу данных этого сервера, а работает с удалённой базой».
Сообщаем клиенту, что его сайт на его же сервере не один, и остальные всё-таки потребляют ресурсы и «укладывают» машину. Ответ клиента ошеломил:
— Ммм, а сколько сайтов находится на нашем сервере, и каких именно?
