Год 2008. Нанимаем подрядчиков для хостинга БД с поддержкой. Лентяй-начальник требует пароль для сотрудника, который и будет работать с БД, и для себя, чтобы держать всё под контролем. В силу своей лени пароль начальник никуда не записал, а запомнить возможности не было по простой причине: к БД шеф ни разу не прикасался, а всю работу спихивал на подчинённых.

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

На следующий день начальник решил-таки изучить БД, дабы передать её другому специалисту. Утро началось так:

— Какой адрес у БД?

— Точный адрес был у %name%.

— @#$, а какой у меня пароль?

— Все пароли были у %name%.

— @#$%&! Где контакты подрядчика?

— (тишина)

— @#$%&! Позвоните кто-нибудь %name%!

— (тишина)

Весь отдел мысленно пожал %name% руку.

Звонит мобила — сотрудник из соседнего отдела. Ситуация следующая: он сейчас находится у клиента, а там ЧП. Местный сисадмин чего-то не поделил с руководством и грохнул базу данных 1С, изменив за компанию и пароль администратора на сервере (лихие девяностые вспоминаются). Пароль админа уже благополучно сломан моим коллегой, осталась проблема с 1С: «Каталог базы данных не обнаружен». Это уже моя специализация.

Запускаю TeamViewer. Действительно, упомянутый каталог отсутствует. Ну и ладно, конфигурационные файлы восстанавливаем из ближайшего бэкапа, а база данных... База всё это время мирно лежала на SQL-сервере, куда во время диверсии явно забыли заглянуть. Вся операция заняла полчаса, включая проверку по окончании и хохот над местным «сисадмином». Блин, ну кто же так базы сносит? Ломать — не строить, это верно. Но ведь ломать тоже надо уметь!

Никогда не работал программистом, но чтобы облегчить себе жизнь, всегда что-то ваял — по специальности я инженер-автомобилист.

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

Я всегда с трепетом относился к финансовым программам, но тут Остапа понесло. Слил копию БД (благо с безопасностью было всё очень криво), за две недели написал новый фронт-энд — на русском, естественно. Функции нужные сделал так, как мне удобно. Неделю назад запустил — всё работает.

Местный админ и так был в шоке от того, что я не дёргаю его по вопросам CMS, но когда увидел, в чём я работаю...

Работаю переводчиком с китайского языка в консалтинговой компании, хотя в неразумном отрочестве увлекался HTML, PHP и MySQL. В числе моих обязанностей — перевод названий компаний с китайского языка, которые добавляются в базу через специальную форму сотрудниками этих самых компаний. Всё было более-менее терпимо, пока какой-то умник не добавил порядка 50 записей одной и той же компании. Естественно, набивать перевод каждый раз, тем более что это бессмысленно, мне не хотелось, поэтому я обратился к программисту с просьбой что-нибудь с этим сделать.

— Извини, — говорит он, — но функции группового удаления нету, так что придётся потерпеть.

— А давай сделаем запрос в базу. У этой компании название уникальное; я тебе дам пару иероглифов, и ты удалишь все записи, где они встречаются.

Сказано — сделано. Когда я пересылал программисту нужные иероглифы, почувствовал себя, будто обращаюсь к колдуну или знахарю, дабы навести порчу. В качестве отвара — консоль MySQL, в качестве волос жертвы — парочка иероглифов, в качестве жертвы — невинные записи.

Есть у меня несколько серверов, в задачу которых входит сбор и обработка статистики от нескольких сервисов. Вся статистика хранится в базах MySQL. И вот однажды сервер, на котором крутилась база, начал тормозить. Это было вполне предсказуемо: объём поступающих данных постоянно рос, и требовалось всё большее время на его обработку. Так как оптимизация работы базы уже не помогала, а оптимизация скриптов уже была проведена до этого, было принято решение о переносе базы на более мощный сервер. Сказано — сделано. Железо настроено, установлена CentOS 5, MySQL, подобраны оптимальные настройки базы и написан скрипт для автоматического переноса данных.

В пятницу утром запускаю тестовый прогон, который должен был воссоздать структуру таблиц. Результат успешен. Запускаю основной скрипт и наблюдаю, как начинают передаваться данные. К шести вечера скрипт всё ещё работает, хотя должен был закончить часам к трём, и рапортует о том, что успешно передаёт в среднем по 70 записей в секунду, Стоп! Как так? До этого шло по три-четыре тысячи в секунду, а сейчас 70? Начинаю проверять всё, что пришло в голову: интернет-канал в норме, нагрузка на обоих серверах в норме, зависших запросов в базе тоже нет, генерацию отчётов отключил...

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

Невнимательность — враг системного администратора. В следующий раз я напишу план работ и буду расставлять в нём галочки, чтобы не пропустить что-либо ненароком, чего и вам советую!

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

Не буду рассказывать о том, какими ухищрениями мне удалось этого добиться, но в скором времени заветный файлик был у меня. Ага! Вот она, таблица users. Находим нужные поля, копируем их значения. Имя пользователя: «admin», пароль... Ах ты засранец! Ну и пароль у тебя!

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

Лишь через некоторое время, всерьёз взявшись за изучение веб-технологий, я узнал волшебные слова «хеш» и «MD5».

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

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

Руки сами набрали rm -rf ~/web_project/buh_prj.

Есть в нашем маленьком городке одна конторка на девять угрюмых человек. Делаю я в этой конторке не только свою прямую работу, но и по мере возможности обслуживаю электронное барахло, которого за многие годы скопилось приличное количество, в пределах «собери, установи, настрой, денег не проси». У Самого Мощного Компьютера, как несложно догадаться, целых девять пользователей, из которых семь путают правую и левую кнопки мыши, а на любой объект на мониторе кликают дважды, после чего удивляются результатам.

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

Две недели спустя нахожу на столе конвертик с двумя дисками и пояснительной запиской: «Уважаемый Пользователь! Приносим извинения за допущенные технические неполадки, вызванные некорректной записью компакт-дисков с обновлениями ЭБД, и просим провести обновление с повторно полученных дисков». Интересно, если в следующий раз пришлют апдейт на грампластинках, я всё равно заставлю базу обновиться?

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

1. Не существует отношений «один к одному». Все такие отношения вырождаются в «один ко многим». Проявляются после написания полного и подробного ТЗ.

2. Не существует отношений «один ко многим» — все они вырождаются в «многие ко многим». Появляются после слов заказчика: «Может быть только так и никак иначе».

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

4. Не существует направленных графов. Есть просто графы. Появляются после описания всех возможных и невозможных связей.

5. Не существует графов. Есть хаос.

Через полтора месяца ежедневного выноса мозгов к работе над проектом подключился главный директор, через три дня был уволен технический директор (тот, с которым я всё это время общался), а через пару недель макет БД был полностью написан и передан прикладным программистам для интеграции.

Отсылаю очередную выделенную порцию из базы данных на удалённый компьютер. Приходит ответ на посылку с ошибкой:

s2i_loader: Неожиданный конец файла среди информационных полей.

Задумался о жизни.