В эфире снова Радио SQL, здравствуйте, согалактчики!

Сегодня у нас обещанный разбор задачи на поиск последней цены.

Здравствуйте! В эфире снова Радио SQL.

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

Здравствуйте, в эфире опять Радио SQL! Сегодня у нас решение задачи, которую мы передавали в нашем предыдущем эфире, и обещали разобрать в следующий раз. И вот этот следующий раз наступил.

Задача вызвала живой отклик у гуманоидов галактики Млечный путь (и неудивительно, с их-то трудовым рабством, которое они до сих пор почитают за благо цивилизации). К сожалению, на третьей планете отложили запуск космической обсерватории «Спектр-РГ» в конце июля 2019 года РХ (летоисчисление местное), с помощью которого планировалось транслировать эту передачу. Пришлось искать альтернативные пути передачи, что привело к небольшому опозданию сигнала. Но всё хорошо, что хорошо кончается.

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

Здравствуйте, в эфире Радио SQL!

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

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

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

Обращаю внимание, что это именно разбор, а не готовое решение. Чтобы избежать тупого copy-paste, я намерено предприму пару действий, которые позволят получить готовый результат только тем, кто немного поработает головой.

Продолжаю рассказ о том, как мы делали олимпиаду по SQL. Это продолжение предыдущей статьи, в которую всё просто не уместилось.

Краткое содержание предыдущей серии: прошло два заочных тура олимпиады в декабре 2016 и марте 2017 соответственно, где претенденты на победу прошли жёсткий отбор как с теорией, так и с практикой применения SQL в базах данных Oracle. Далее про третий тур — очный финал олимпиады в Сочи в начале июня 2017 г.

В самом начале осени 2016 года руководство поставило мне задачу подготовить техническую часть олимпиады по SQL. Обсудив ситуацию с коллегами, в том числе с бывшими, я был ткнут (ткнён?) в статью, где в декларативном стиле на SQL решалась задача по построению кратчайшего выхода из лабиринта. Собрав в одну кучку части запроса и запустив его на настоящей базе, я прошептал "магия!.." и понял, что олимпиаде быть.

Думаю, что типичный читатель Хабра на олимпиадах хоть раз да бывал, но скорее в роли участника, а не организатора. Я тоже бывал на разных, и мне всегда было удивительно, почему на одних олимпиадах интересно, а на других тоска смертная. Могу показать, как выглядит этот театр с другой стороны занавеса, и как я старался, чтобы эта олимпиада оказалась из тех, которые интересные. Интриги, скандалы, расследования — ничего этого не будет. Зато расскажу как готовились задания, что от них ожидали и что получалось в результате.

Вступление

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

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

Продолжаю цикл статей про SLA, публикуя то, что не уместилось в основную статью Как написать хороший SLA.

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

За много-много лет работы в поддержке самых разных ИТ-систем, мне очень понравилась система из четырёх приоритетов, о которой речь и пойдёт ниже. Эта система настолько хорошо показала себя на практике в самых разных проектах, что я искренне удивляюсь, встречаясь с другими подходами к приоритетам. Так что я готов приложить определённое количество усилий для популяризации таких определений приоритетов. Чтобы они чаще всеми использовались и чаще встречались в жизни.

В своей статье "Как написать хороший SLA", я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.

Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или "кручу-верчу, обмануть хочу", или банальной некомпетенции.

Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая "эскалация" запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая "эскалация", которая переназначает запрос на кого-то другого. Профит!.. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему "эскалаций" и применяют, выдавая за лучшие практики IT!

Так что же такое эскалация, кому и зачем она нужна? Сейчас расскажу своё понимание, после которого Вы, как я надеюсь, полюбите эскалацию также, как и я. Держитесь крепче за стул.

Как написать хороший SLA (Service Level Agreement, оно же Соглашение об уровне сервиса). И какой SLA будет хорошим.

Эта статья является попыткой обобщить имеющийся опыт, а также на неё я собираюсь ссылаться, когда меня будут в дальнейшем спрашивать, как должен выглядеть SLA. Работая в индустрии не первый десяток лет, я к своему удивлению регулярно сталкиваюсь с серьёзным непониманием основ, на которых строится SLA. Наверное, потому что документ довольно экзотический. После прочтения данного текста, я надеюсь, у вдумчивого читателя точечки над ё должны встать на свои места. Целевая аудитория — те, кто пишет SLA, и им сочувствующие.