Достаточно большой период времени занимался технической поддержкой СУБД Oracle. Накопилось некоторое количество историй и заметок на полях по этому поводу, не могу не поделиться ими с вами. В общем, садимся поудобнее, берем попкорн, чашку горячего чая или кофе.. Дело было так.

Введение

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

Расскажу две важные корректировки, которые дадут примерное представление – как я оказался здесь.

• Году так в 1997-ом я, проживая в Екатеринбурге, узнал про такую штуку как Интернет. Модемов тогда в широком доступе не было, чтобы получить доступ в сеть нужно было идти в библиотеку им. В.Г. Белинского. Это было первое мое знакомство с миром высоких технологий. Интернет-браузер Netscape – целая эпоха. Можно сказать, что это событие произвело на меня очень очень сильное впечатление. Да, я уже имел опыт работы с компьютерами, играл в игры и прочие активности – но это было другое. Мне дали список иностранных сайтов библиотек, я просто смотрел на английский текст, почти ничего не понимал, но точно знал, что за этим будущее.

• Завершение обучения в институте, написание диплома. Персональные компьютеры уже не такая и редкость, в общаге сообразили на троих один ПК и начали писать диплом. После первых моих попыток что-то напечатать двумя пальцами обеих рук, я понял что это медленно и неэффективно – расчеты подсказывали, что это можно делать как минимум в 5 раз быстрее и без подглядывания на клавиатуру. Быстрый поиск в Интернет через инфраструктуру института – и вот оно решение – слепая десятипальцевая печать "Соло на клавиатуре" В.В. Шахиджаняна. Я прошел курс по русской раскладке за недели две, успешно написал и защитил диплом в электронном виде (создателям Компаса - тоже спасибо) и начал свою трудовую деятельность.

Первые шаги в IT: от Access до Oracle

Начинал как оформитель договоров в одном из проектных бюро по электротехнической тематике, что было близко к моей специальности. Особого IT там не было, обычный офисный клерк. Но для облегчения работы придумал и написал систему на MS Access для учетов договоров. Инициатива снизу, как это часто бывает, поддержки не получила. Долго я там не задержался, так как уже понял что меня интересует сфера информационных технологий и заниматься бумажной работой было не очень интересно.

Нашел по направлению информационных технологий компанию, которая занималась разработкой ERP системы для крупного, якорного как это говорят, заказчика на базе технологий с приставкой Oracle: Database, Designer, Forms, Reports. После месяца обучения RAD-разработке я уже приступил к первым задачам. Работаю в основном как разработчик, постепенно я взял на себя задачи системного администрирования и работы с БД, первые шаги в DevOps. Занимаюсь в том числе доставкой обновлений на сервера заказчика, формирование патчей, бинарных артефактов – некоторое приближение к автоматизации CI/CD.

Разработка ПО в фирме была построена с использованием Waterfall, в наличии отделы аналитики и разработки. Хотел бы отметить Oracle Designer, его в основном использовали для создания шаблонов Oracle Forms по схеме данных, там же хранили и схему данных как single source of truth и использовали ее как VCS. До выхода SVN остается примерно один год, поэтому так. Модульное тестирование отсутствовало - больше от отсутствия таких возможностей в инструментах разработки. Как видно, движение было в правильном направлении. И это давало серьезные преимущества – скорость разработки features была очень высокая, за все время работы было разработано очень много функциональности для большого предприятия небольшой командой, просто грамотно наладив процессы и выбрав подходящие инструменты. Oracle Designer действительно на тот момент был очень неплохим решением и ускорял разработку.

Постепенно я более плотно начинаю заниматься СУБД Oracle и отхожу от разработки в администрирование. В это же время якорный заказчик постепенно начинает переход на SAP и просит руководство компании разработчика отечественной ERP освободить офис в здании.

Проводок отпал

Мне и коллеге поручили собрать всё и перевезти в офис разработки. Я руковожу процессом, мы аккуратно собираем и упаковываем все компьютеры, ЭЛТ-мониторы (здоровые и тяжелые, заразы), столы, стулья и прочую оргтехнику. Канцелярские принадлежности, календари, флаги с символикой Oracle и, конечно же, постеры Ларри Эллисона. Вроде все.

Но нет, мой взгляд падает на торчащие из под щитов, закрывающие батареи отопления, провода Ethernet для подключения компьютеров к сети. Непорядок, надо и их убрать — всё‑таки переезд, да и в ТЗ чётко сказано: собрать всё.. Комнаты две, начинаем с дальней. Вскрываем верхнюю крышку, и сматываем провода.. О, там ещё и коробочки — их тоже берём, в хозяйстве сгодятся! Проводов становится все больше, часть из них идут в соседние комнаты, выдрать их не представляется никакой возможности. Постепенно приходит понимание, что провода трогать не надо. Время уже поздний вечер, решили пока оставить как есть, завтра разобраться.

Из рассказов очевидцев. Утро. У руководства идёт совещание — решают, что делать дальше. Заходит сетевик и просит получить доступ в комнату со словами: «Что‑то сеть не работает, видимо проводок отпал». Открывает — а там... Все прошло без последствий, посмеялись и разошлись.

Вывод? Порядок должен быть! Провода должны быть уложены аккуратно в короба, на крайний случай с использованием стяжек и не торчать непонятно как. Непорядок рождает непорядок, такое мое мнение из всего произошедшего :)

Техническая поддержка Oracle в системной интеграции

И тут начинается новый этап — начинаю работать как инженер технической поддержки Oracle L1/L2 в системной интеграции. Это компании, официально аккредитованные Oracle для оказания технической поддержки через систему статусов. То есть это работа не в поддержке самого Oracle, а аутсорс, чтобы вы понимали.

Объемы данных стремительно увеличиваются, а hardware не всегда успевает за этим ростом и становится актуальным стабильное функционирование систем для работы с большими данными. С такими задачами исторически хорошо справляется RDBMS Oracle, в том числе и поэтому она занимала первое место в рейтингах самых популярных БД — это объективно так. Почему?

По моему мнению, все дело в архитектурных решениях, которые были приняты задолго до становления этой БД № 1 в мире. Oracle хорошо масштабируется и обеспечивает стабильную и удобную работу с большими объемами транзакционных данных, это если совсем‑совсем коротко и в общем. Вертикальная масштабируемость на высоком уровне, с Oracle RAC есть некоторые особенности — но используют этот режим скажем так немногие.

Для High‑End транзакционных систем — тут Oracle без вариантов, чем успешно и пользуется — устанавливает свои правила игры. Для небольших и среднего уровня — подойдут другие БД. Возможны варианты, но считать надо в каждом случае отдельно. Не сочтите за маркетинг, некоторый элемент ощущений из своего опыта работы.

В чем заключается работа по тех. поддержке на первой и второй линии Oracle системных интеграторов? Первичный прием запросов от клиентов, базовые диагностики, поиск по документации, разбор логов, поиск проблем, восстановление после сбоев, диагностика медленной работы запросов. Если не получается решить проблему своими силами — эскалация на 3 линию тех. поддержки — пишем запрос в системе My Oracle Support.

Работа в целом несложная. В наличии документация, полный доступ к базе знаний на My Oracle Support. Действительно сложных случаев, когда требовалось подключать 3 линию тех. поддержки с наивысшим приоритетом было, ну может раза 2–3 за все время и с десяток случаев когда действительно проблема решалась через My Oracle Support. Обычно до этого не доходит и проблемы решают сами администраторы БД на месте или обращаются когда действительно требуется помощь.

Есть и обратная сторона, долго в таком режиме не проработаешь — рутина затягивает, и тут есть несколько путей развития:

• Идтивширь. Изучать кроме СУБД Oracle другие продукты, чем я и занимался. Первое время это были сервера приложений, Singel‑Sing‑On, потом системы бизнес‑анализа(Essbase, Oracle Business Intelligence). С Oracle RAC (Real Application Clusters) тоже приходилось работать. Но кластерная конфигурация работала не стабильно — эту штуку надо было уметь готовить, то есть дорабатывать систему учитывая особенности кластерной реализации, поэтому установок таких было очень мало — можно сказать, почти не было.. Один раз переделывал установку Oracle RAC у заказчика (пакеты private network ходили по public сегменту — ой). Второй раз ставил Oracle RAC в учреждении, где интерконнект между узлами организовали просто соединив их через Ethernet провод — unsupported.. Допускаю, что сейчас все поменялось — но тогда это было вот так.

• Делать проекты, связанные с СУБД и другими технологиями. Тут вариантов было побольше. Привлекали на другие проекты, где нужна была компетенция по Oracle. Поставить, настроить и запустить. Проекты по диагностике проблем с производительностью, собрать информацию, логи и отчеты написать. Различные миграции на новые системы. Pre‑sale — тоже активность, жить то на что‑то надо. Техническая поддержка Oracle (да и не только) с точки зрения бизнеса дело совсем не прибыльное. Предполагаю, что только проекты и вытягивали все это на приемлемый уровень.

Встреча

Поступила задача — выполнить установку новой версии СУБД Oracle 10g в кластерном варианте. Причем сделать это надо было быстро, где‑то за неделю. У заказчика в production уже работала Oracle 9i. Дело, в общем‑то, было не такое сложное — прошли те времена, когда для запуска инсталлятора Oracle требовались бубен и магические заклинания. Все еще требовались заклинания, чтобы перевести БД на новую версию. Но это было не сложно — надо только аккуратно следовать инструкции. Дополнительно запросили аудит информационной безопасности в БД, политик резервного копирования и восстановления.

Всё происходило на территории заказчика, в специально отведённой для подрядчиков комнате — периодически заходили люди из других компаний, быстро делали своё дело и уходили. В один из дней в комнату вваливается группа из трех человек и начинают совещание. Главный начинает проводить рекогносцировку, ставит задачи по установке СУБД Oracle 10g, рассказывает подробности сложных взаимоотношений с заказчиком и другие несущественные для повествования детали.

Я сижу тихо и дописываю отчёт. Понимаю, что это основной подрядчик, который занимается поддержкой и сопровождением системы. И у них тут намечается работа, которая уже по сути сделана. Затем приходит начальник отдела, который заказал нам «second opinion». Выслушивает их план и сообщает что уже все сделано — и указывает на меня, они немного поменялись в лице — и, видимо чтобы как‑то разрядить обстановку, запросили экскурсию в ЦОД — посмотреть на сервера. Начальник выразил сомнения в необходимости проведения данного ритуала, и нашел в моем лице поддержку. Я подтвердил, что все сделано удаленно, я не видел физических серверов, и это не помешало мне выполнить свою работу.

После подписания всех необходимых документов по завершению проекта, за чашкой чая, мне рассказали историю решения проблем с производительностью текущей кластерной системы на Oracle 9i. Детали, в общем, не особо интересны, как и способ решения — главное, что проблему устранили, причём сделали это элегантно:). Интересное было в том, кто занимался решением — это был Андрей Криушин, хорошо известный в российском сообществе Oracle. Основатель Russian Oracle User Group, преподаватель, профессионал и просто хороший человек.

Грузим данные в память бочками

Прилетела заявка, проблемы с производительностью, медленно выполняется запрос. Смотрю текст запроса — сотни union all и конкатенация в результатах запроса строковых переменных. Добавление новой бизнес‑логики производится написанием еще одного запроса и дополнением в текущую портянку через union all. Понятно, что работать данная конструкция не будет — ведь оперативная память сервера не безгранична, и хранить всё это в shared pool — не есть best practice. Shared pool в Oracle предназначен для хранения разобранных SQL‑запросов, а не данных. Для хранения и обработки данных есть 1) таблицы, 2) специальная структура в памяти, называется буферный кэш и 3) Лучшие практики по работе с данными.

Переписываю запрос с добавлением справочной таблицы и отправляю заказчику, объясняю что в текущем виде сервер с таким типом запросов будет работать не эффективно.

Как часто обращались с такими проблемами? Всего один раз. Ок, а где конфликт, драма и трагедия, в чем так сказать практическая полезность данной истории? А в том, что подобный подход по хранению и передаче различных данных через конкатенацию регулярно наблюдал во множестве информационных систем. Конечно, там не было сотен вот таких запросов с union all, запросы были по меньше, но занимали некоторые десятки мегабайт. Подобный шаблон работы с данными повторялся неоднократно и столько же раз в отчетах писал одно и тоже — не надо использовать shared pool БД Oracle не по его прямому назначению. Обрабатывать данные нужно другим способом. Не говоря уже о вопросах информационной безопасности..

Генератор запросов

Как‑то раз меня отправили в командировку разбираться с проблемами производительности. Дают доступы к консоли управления, смотрю историю активных сессий. Пытаюсь посмотреть длительно выполняющийся запрос — жду минуту, две, пять…. Где‑то через полчаса увидел сам запрос — ой. Огромный, просто чудовищный запрос — тысячи UNION ALL, явно сгенерированные автоматически.

Что я мог сделать в данной ситуации? Только посочувствовать пользователям системы. Оказать психологическую поддержку и принять истину, что есть класс проблем, технически не решаемых в принципе, увы. Только организационно. Где‑то поменять отношение к ним и.. разработать автоматическую генерацию SQL‑запросов в Dimension‑DB для запросов данных временных рядов и их визуализацию в Dimension‑UI.

Не злорадства для, а описания состояния IT на тот момент, это конец нулевых где-то. Тогда это было вот так.

ASH Viewer

Очередной вызов, проблемы с производительностью Oracle 9i. Система упала. После восстановления меня вызывают провести диагностику. Приезжаю на место — запрашиваю логи — в журналах чисто. Видимо, проблема в запросах или на уровне приложения — но доказать не могу.. Сижу перед начальством, сказать ничего не могу — данных на входе никаких нету. Неприятное ощущение, когда не знаешь, что сказать, но по должности обязан.

Тут такой момент еще, часть работы была — показать компетенции, на что способен в настоящей работе. По итогу принимается решение — продолжать сотрудничество или нет. Результат, как вы понимаете, был предсказуем — pre‑sale сорвался.

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

Не раз спасала меня в экстренных случаях, когда требовалось получить быстрый ответ — а что сейчас конкретно происходит в СУБД Oracle. Один раз даже была демонстрация в режиме реального времени, во время возникновения проблем на БД — управился минут где‑то за 10 на закрытом контуре, начиная с момента когда вытащил флэшку с дистрибутивом, проверили ее антивирусом, подключились к БД и посмотрели что происходит в системе online. Заказчик был впечатлен, и было успешное продолжение сотрудничества. Как говорится, почувствуйте разницу между «до» и «после». Data‑driven в действии.

Все свои отчеты по анализу производительности делал со скриншотами из ASH Viewer. Полезная утилита, рекомендую. Есть продолжение истории в виде Dimension-UI, но более универсальное.

High performance

Поставка новых серверов и установка на них СУБД Oracle. Всё стандартно и даже обыденно — привычная рутина для тех, кто этим долго занимается, но не в моем случае. Своего рода отдых, такая смена вида деятельности. Иногда даже приходилось физически поработать — потаскать тяжеленные сервера или СХД и смонтировать их в стойку.

Сервера от Oracle, точнее тогда еще SPARC‑и от купленной Sun Microsystems с переклеенными шильдиками, ОС Solaris. Не знаю, может это сильно субъективно — но Oracle на SPARC‑ах — это какая супер надежная связка была в то время в части производительности и стабильности работы. И по отзывам, и по личным ощущениям и статистике запросов.

Операционная система установлена, накатываю СУБД Oracle и переносим данные из старой системы на новые сервера. Проверяем подключение и первый вход в систему — работает медленно. Вход в систему занимает минуты. Еще проверки — на старом сервере и на новом — деградация производительности в разы. Собираю диагностику, трассировку — вижу приклад при входе делает большое количество расчетов, связанных с проверками доступов, ролей и прочей инфраструктуры. И на новой системе это работает медленнее, чем на старом сервере!

Очевидно, не хватает процессорной мощности на сервере, запускаю стресс‑тесты производительности в части проверки скорости работы CPU на старом и новом сервере — тоже самое, разница в разы. Картина проясняется, когда я изучаю описание high‑performance new generation server system. Там, действительно high‑performance — цифры в разделе количество потоков показывают значение ~ 250 потоков на толи один то ли пару физических процессоров и в описании, что сервера best fit для серверов приложений с большим количеством одновременных подключений.

Пишу ответственными с нашей стороны что проблема — надо что‑то делать. Разработчики системы тоже из нашей банды — говорят, менять ничего не будем. Несколько дней нервотрепки crossfire, с меня требуют оптимизировать и настроить Oracle, чтобы все работало. Пишу развернутые эссе на тему, что это невозможно без переписывания кода или смены сервера. Заказчик устраивает совещания — все смотрят на меня как на врага:)

В итоге все заканчивается перетасовкой серверов, в поставке были еще x86 Intel, базу данных переводят на них и все успокаивается.

Солнцезащитные очки

Солнечное июльское утро, на небе не облачка, а у заказчика срочная проблема, упала база данных и не поднимается, используют специализированный volume manager Oracle ASM, с ним какие‑то проблемы. Прошу прислать логи на почту, по быстрому смотрю что и как — идей что делать нет. Ладно, надо ехать сразу к заказчику и на месте решать. Прыгаю в авто, не забываю надеть солнцезащитные очки — на небе ни облачка, и солнце по дороге светит прямо в лицо.

Захожу в офис заказчика и убираю очки на макушку. Коллега уже на месте, оказывает психологическую поддержку и смотрит уровень системы хранения — там все сделано экономно, по‑моему флэш диски напрямую в сервер были подключены. Поверх всего стоит ASM, на каждый flash‑диск — по дисковой группе с EXTERNAL REDUNDANCY, то есть без резервирования. И в этой конфигурации что‑то случилось с диском, ASM отреагировала это отключением одной или двух дисковых групп. Попытки переподнять все это не приводят к успеху. Какое‑то время после старта ASM всё работает, но затем внутренние проверки обнаруживают сбой, и все дисковые группы переводятся в OFFLINE. В общем данные на production системе недоступны. Бэкапы есть, но восстановление и применение журналов займёт минимум сутки, а то и больше, да и нет гарантии, что всё удастся вернуть. Поэтому задача восстановить работоспособность production.

Первым делом смотрю ошибки в логах ASM и захожу на My Oracle Support — может уже есть решение подобной проблемы. Стандартная практика на самом деле, у заказчика кстати тоже есть доступы и они облазили его насколько могли — решения нет. Дела плохи, дело идет к Service Request с Severity 1 в My Oracle Support. Но это надолго и без каких‑либо гарантий — отдельная большая и больная тема. А результат нужен здесь и сейчас.

Администратор БД заказчика сидит в терминале спиной к нам, пытается привести систему в чувство, все манипуляции по восстановлению делает сам, нас не подпускает. Этот тот тип людей, у которых все под присмотром, везде порядок, как должно — насколько это позволяют бюджеты. Им не нужна техническая поддержка Oracle, сами все делают и даже больше — с такими было одно удовольствие работать.

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

Долго думаю, перебираю варианты и тут приходит идея. А может запустить все одной командой и не ждать проверок ASM — и старт ASM и монтирование дисковой группы? Там каким‑то образом пропустить фазу проверки, по любому что‑то в заголовке несущественное и ASM кладет дисковую группу.

Предлагаю вариант — администратор БД сомневается и даже сопротивляется и я его понимаю. Но настаиваю на своем. Делаем скрипт, запускаем. Результат — дисковые группы ASM в ONLINE, данные доступны. Выдыхаем, стартуем инкрементальное резервное копирование production системы.

Пришло время убрать солнцезащитные очки со стола и положить их в карман.

Вспышка на солнце

Мы настолько привыкли к размеренному ритму жизни и комфорту. Под рукой интернет — практически весь мир открыт. Все на расстоянии пары‑тройки кликов в смартфоне. Но бывает, что всё это перестаёт работать в одно мгновение. И я мог ощутить эти последствия так сказать на себе и поучаствовать в разборе завалов после такого сбоя. Детали можно посмотреть здесь.

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

Проверка достоверности

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

Жесткие диски (HDD) уходят в прошлое, им на смену приходят твердотельные накопители (SSD). Для сравнения: скорость одноблочного ввода‑вывода на HDD составляет около 10 мс, а на SSD — всего 1 мс, что даёт десятикратный прирост.. Ввод‑вывод традиционно был узким местом и в СУБД учитывали это ограничение и вводили различные способы ускорения получения данных через политики кэширования, сжатия и индексирования данных. Производители СХД, кстати, делают тоже самое.

Заказчик смотрит различные варианты не только по смене СХД, но и по перенастройке существующей системы работы с данными в Oracle. Все лежит в файловой системе, постоянные задачи по ручному управлению расположением данных — сплошные неудобства. В итоге выбирает из вариантов — использовать файловую систему Veritas или менеджер томов от Oracle ASM. Veritas — дорогой, неприлично дорогой, но позволяет привычно работать с данными в файловой системе плюс гибко управлять свободным местом — в наличии функции volume manager. В Oracle ASM нет привычного интерфейса, надо переучиваться — зато бесплатно и полная автоматизация. В результате выбирает ASM и стартует проект миграции по одной системе отдельным договором.

Предполагая худшее (и на то была веская причина — legacy), я подошёл к делу основательно. Разворачиваем тестовый стенд, проверяем и тестируем Oracle ASM, способы подключения дисков в ASM, варианты управления резервной системой Oracle Data Guard — вручную или через Oracle Data Guard Broker. Запускаем нагрузочное тестирование СУБД Oracle в связке с Oracle ASM, во время нагрузочных тестов делаем принудительное отключение/подключение дисков в дисковой группе. Смотрим журналы — как реагирует на это СУБД, упадет или выдержит? Кстати, смотрим что делается в Oracle ASM через просмотр истории активных сессий с помощью ASH Viewer — видно как стартуют потоки при ребалансинге и информация по другим процессам.

Еще смотрим работу текущей системы на старой СХД. Под пристальным наблюдением все сбои, разбираем причины, исследуем способы решения. То есть, смотрим все относящееся к производительности и стабильности работы. Ведем журнал всех ошибок, поднимаем старые логи — смотрим, что там.

Вроде все проверили, ничего супер критичного не обнаружили. В логах базы данных и ASM при нагрузках чисто. Выбрали ручное управление резервной системой, описали все в отчете, разработали инструкцию по переключению на резервный сервер в различных вариантах в рабочем (switchover) и в аварийном (failover) режиме. Все задокументировано, что и как делаем в каждом случае.

Начинаем готовиться к переезду путем создания резервной системы на новой СХД и переключения на нее в режиме switchover — downtime минимальный. Запускаем все и готовимся к переключению. До старта миграции в production остается где‑то неделя. И тут звонит заказчик и сообщает странное — они подключили standby систему к системе мониторинга СХД и она показывает аномалии в скорости доступа. Время обработки запросов на ввод‑вывод — неприлично высокие для флэш массива — 30-40-50 миллисекунд. Это в разы медленней чем на старом сервере! Ну думаю, приехали.

Поднимаю логи истории активных сессий базы данных, сохраненные через ASH Viewer — там все еще хужее. На некоторых операциях видны ожидания в 90 миллисекунд — что неудивительно, мы напрягали систему через скрипты нагрузочного тестирования плюс в это же время ребалансинг в 10–20 потоков при различных операциях. Я начинаю вспоминать, как я мог проглядеть такое — объяснение только в том, что фокусировался только на стабильности работы, а про скорость работы. Вспоминаю разговор с заказчиком и просьбы проверить системы на некоторых бизнес‑задачах, на что получил — отказ. Надо было настоять на своём! Это, конечно, немного утешало, но проблему не решало. И что мешало замерить все через orion — тоже непонятно. В голове были только оправдания, что все это делалось одним человеком — но это не решало проблемы. В таком состоянии и без каких‑либо идей что делать дальше, я пробыл остаток дней до четверга.

С пятницы на суббота миграция. Надо ехать сдавать проект, блин. Оформляю командировку, загружаюсь в свое авто и еду объясняться. Утешаю себя, мол сделал все что мог. Предупреждал, что будут проблемы, сопротивлялся миграции на новую версию операционной системы, не дожал в вопросе проверок работы. Уже тогда можно было отловить проблему. Ладно, это все отговорки. Задача не выполнена, скажем прямо.

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

До конца рабочего дня остается полтора часа. Сижу, и чу — слышу от одного из участника мозгового шторма высказанное вслух размышление про трассировку. Так, трассировку на уровне БД я уже делал, погоди.. А трассировку системных вызовов — нет. Кстати, в Solaris с этим полный порядок (смотри DTrace, которую портировали и на Linux тоже). Ну‑ка, ну‑ка. Выбираю серверный процесс через который идет восстановление на резервной системе — запускаю. И что же мы видим? Множество вызовов асинхронных операций ввода‑вывода с большим timeout‑ами. Это жжж неспроста. И тут я вспоминаю..? Погодите, а в ведь в СУБД Oracle можно отключить асинхронный ввод‑вывод. Делаю необходимые изменения — неприлично большие ожидания уходят. Еще проверка, ждем несколько десятков минут. Выдыхаем.

Что это было? Баг, как я уже говорил — legacy и ничего с этим поделать нельзя было. Затраты на перевод всего этого на новую систему были бы очень дорогим, поэтому без вариантов.

Почему загорелась лампочка? А потом что это было в моей оперативной памяти, потому что в процессе разбора, когда смотрели работу текущей системы на старой СХД, столкнулись с подобной проблемой и как решение предлагалась покрутить типы ввода‑вывода. И заметьте, как смена обстановки и окружения ускоряют некоторые процессы. Это наверное самое интересное, что можно взять на заметку из этой истории — командная работа здорового человека выглядит именно так. Каждый работает на своём месте, порой даже не осознавая, что является важной частью общего процесса.

Потом была вторая миграция. Тоже не без проблем, но не такого уровня конечно. Но заставила поволноваться CTO и лично посетить отдел администрирования. Я стоял, скрестив руки на груди, смотрел вдаль, излучал уверенность и вещал что проблема понятна, решение есть — надо только дождаться окончания рабочего дня, чтобы внести изменения в настройки. Потом была еще третья миграция — все прошло в штатном режиме.

Итоги

За годы работы с ошибками выработалось философское к ним отношение, знаете, такая часть процесса. Свои и чужие, большие и маленькие, человеческие по большей части, программные и аппаратные, даже ошибки природы — и те встречаются, которые надо разгребать. Смотри всплески напряжения в энергосети главного термоядерного реактора по имени Солнце. Но, Non Je Ne Regrette Rien, как поется в известной песне в исполнении Э. Пиаф.

Как‑то так получается, что без ошибок — никуда. Чего‑то только не делаем — всегда что‑то происходит незапланированное. Может это и есть секретный ингредиент человеческого разума, созданного в результате ошибок: через случайные мутации, и какого‑то встроенного несовершенства?

Повидал всякое, всего не напишешь — тут только малая (но очень важная) часть, с чем приходилось работать. Некоторые темы чтобы развернуть надо писать полноценную статью, а таких даже тут несколько. Есть что вспомнить, надеюсь и вам было интересно, а возможно и что‑то пригодится.

И, в завершение, дабы снизить градус серьезности и для поднятия настроения — предлагаю вспомнить видео «Служба поддержки в Средние века» — юмористический скетч из норвежского шоу «Øystein og jeg» (NRK, 2001). Норвежские юмористы Øystein Backe (помощник), Rune Gokstad (отчаявшийся монах) и автор сценария — Knut Nærum сотворили шедевр на все времена. Ссылка на YouTube.

Вроде все, спасибо за внимание!