Как убрать слово в url?

Так ты заменяешь в bobik, а там 0.

console.log('http://site.ru/catalog/catalog/?arrFilter_10_2=Y&s... '.replace('/catalog/catalog', '/catalog'));

Какой sql запрос нужен чтобы получить последнюю дату события для каждого домена?

LIMIT надо в конце писать.

SELECT `domain`, MAX(`date`) as `max_date` FROM `crawls`
GROUP BY `domain`
ORDER BY `max_date` DESC
LIMIT 1000

Технический нейминг серверов. По какому принципу называть сервера?

shurshur,

Имя сервера риски не создаёт. Риски создаёт хаос ... если всё время переименовывать сервера

Какое то противоречие. Но не суть, я то и предлагаю за сервером уникальный ID закреплять, а не переименовывать i0823 в m0823. Точнее я ничего не предлагаю, я интересуюсь просто, спрашиваю.

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

Но вот вы другие идеи применяли. Зачем? Что бы найти решение, близкое к идеальному. А что бы это всё не пробовать сразу в продакшене, можно сначала в голове пофантазировать, понавыдумывать разных ситуаций, спроецировать гипотетические ситуации на гипотетические подходы. Анализ - прогноз - принятие решения.

Технический нейминг серверов. По какому принципу называть сервера?

shurshur,

Зачем фантазировать, если есть конкретные реалии?

Что бы минимизировать риски.

Вообще, ты как будто считаешь, что есть универсальное решение

Я не знаю есть ли решение, по этому и спросил "Может есть уже даже софт специальный?"

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

Нет. Просьба поделиться опытом подразумевает принятие существования других взглядов.

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

Вот я и пытаюсь разобрать разные ситуации, а не только одну как у тебя, как будто на ней мир замкнулся.
Да даже к твоей "уникальной ситуации" можно применить разные подходы.

Технический нейминг серверов. По какому принципу называть сервера?

shurshur,

Что нам с ней делать?

Да хотя бы документацию вести. Там и историю можно было бы видеть.

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

Технический нейминг серверов. По какому принципу называть сервера?

shurshur,

Я ещё раз повторю: у каждого своя специфика, свои традиции, свои возникающие проблемы.
Если бы мы меняли назначение серверов ежедневно, ... но мы это делаем эпизодически,

А как вы понимаете что условно i0823 - это бывший m0823. Ну вот есть физическая железка, ну или виртуальная. Она переустанавливается, переименовывается, пересобирается, переезжает. Какой то железобетонный уникальный ID это и есть XXserverX?

Технический нейминг серверов. По какому принципу называть сервера?

shurshur,

Бюджет тут причём?

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

Технический нейминг серверов. По какому принципу называть сервера?

shurshur,

Такой бред, как пихать на сервера hello.site.com приложения проекта foobar.co.il у нас не делают в принципе.

"Бред" потом у что это архитектурно чем то грозит или просто вы радуетесь что есть бюджет и не приходится заниматься таким "бредом"?)

Технический нейминг серверов. По какому принципу называть сервера?

Saboteur,

В общем я лет 20 работаю в очень разных проектах, и такого, чтобы сервера часто и быстро бегали по разным проектам в компании - не видел.

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

Если проект закупил сервера, которые настолько простаивают, что их можно отдать в другой проект, значит кто-то просто разбазаривает деньги.

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

Потому что неизвестно какие хвосты могут остаться на старом хостнейме

Опять же пример с докером приведу как всё может быть запутано. На хосте настраивается базовое ПО, всё остальное в контейнерах.
Есть проект project.com, спустя время появляется какой то микросервис к этому проекту (micro1.project.com), ставится контейнер рядом на туже виртуальку (путь будет a0).
Появляется ещё один микросервис micro2.project.com, но он уже не влезет сюда по требованиям мощности, ставится на другую виртуалку (a1).
Серверов больше нет, бюджета пока нет. Появилась задача сделать бота, он ничего не жрёт. Ставится контейнер на второй сервер (где micro2 крутится - a1). Потом появляется бюджет и новый проект project2.ru и сервер a3.
А micro2.project.com например больше не актуален. Но удалить сервер a2 мы не можем, там же ещё бот есть живой, по этому просто удаляем контейнер micro2. В итоге есть мощный сервер a2, на котором только хилый бот.
На проекте project2.ru появляется задача, как на project.com. Проект project2.ru начинает обращаться к микросервису micro1.project.com (a1), потому что он уже решает эту задачу. Нагрузка растёт. Вспоминаем что есть сервер с ботом (a2), выносим туда micro1 к которому обращается и project(a1) и project2(a3).
Если это не жонглировать, то получиться что первый сервер перегружен, а второй в простое.

Вполне распространённая ситуация мне кажется =)

Создать другую виртуалку с другим ID - это в том числе и SecOps

Вот это полезно, запомню. Иногда остаются обращения к несуществующему, их проще найти и отключить,/переключить а если тут что то новое заработает с кодом 200, будет проблематично.

Технический нейминг серверов. По какому принципу называть сервера?

Saboteur,

Среднестатистический девелопер даже не интересуется на каком именно сервере крутится его приложение

Согласен. Но есть главные разрабы. Если большая компания с большим количеством команд, там много главных разрабов. Есть компании где внутренние хакатоны проводятся, чем проект лучше, тот и пойдёт в продакшен, а тут надо экосистему из серверов выстроить. Но опять же есть личные сервера, я думаю у каждого разработчика есть несколько vps с тестами, неудачными/удачными проектами, родственники попросили сделать сайт итд.

менеджер/архитектор, кто выполняет эти функции и распоряжается бюджетом проекта/компании выделяемый на инфраструктуру

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

Технический нейминг серверов. По какому принципу называть сервера?

Vamp,

Но если ваша специфика предполагает частую перестановку серверов между стойками,

Частую не предполагает, просто наткнулся 2 раза, когда были локальные сервера и переезжали в другой офис.
Имеет место быть.

Не бойтесь экспериментировать. С первого раза вы точно не придумаете идеальный нейминг. Это эволюционный процесс.

Судя по ответам тут, вырисовывается такая картина, что у сервера должен быть некий базовый уникальный id. За которым в документации можно закрепить все ip адреса этого сервера, доступы и т.д.
А дальше уже сколько угодно DNS алиасов для разных нужд, которые прикрепляются в документации к этому уникальному id.
Получается id привязан к конкретной машине, виртуальной или физической неважно. А проекты и DNS адреса могут уже мигрировать между машинами как абстрактный слой.

Технический нейминг серверов. По какому принципу называть сервера?

shurshur,

Такое длинное имя есть только в hostname сервера. Его в DNS нет и никто им никогда не пользуется.

А если говорить про dns поддомены? Есть технические?

Например есть проект name.site.com
Он размазан балансиром по 10 серверам.
Разработчикам надо туда ходить по ssh, смотреть логи. Какой может быть нейминг?

Или другой пример. Один сервер, на нём несколько проектов от разных разработчиков. Все хотят туда ходить по разным причинам.
Допустим у одного там проект, есть в dns hello.site.com, у другого там скрипт, который он иногда запускает из консоли. Если первый будет ходят по ssh на hello.site.com, то второй по ip? Если ip поменялся, если hello.site.com разросся до нескольких серверов.

Технический нейминг серверов. По какому принципу называть сервера?

Saboteur,

Что за бред. Откуда у программиста появляется идея, и уж тем более портфолио?

Вы видимо не пересекались с программистами.

Он работает на работе. Что ему делать ему говорит заказчик.

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

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

Да, я наверное зря не уточнил что под "техническим" именем сервера скорее имею ввиду его "технический" сетевой поддомен. Хотя может и не зря. Я же сказал что это техническое имя сервера, а не имена продакшен проектов.

полезно по хостнейм понимать что там под капотом

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

Технический нейминг серверов. По какому принципу называть сервера?

shurshur,

При малом числе серверов и несложном распределении их ролей не очень-то важно, как они называются

Допустим у тебя vs01, vs02, vs03, vs04, vs05
Потому ты решаешь убить первые 4 за ненадобностью, а vs05 всё ещё нужен.
В итоге есть vs05, но где 04, где 01? Перфекционизм, ОКР и прочие неудобства.

Если брать название сервера из рандомных пустых ячеек таблицы, тогда ОКР не побеспокоит =)

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

Классно когда порядок в работе =)

Скажи, если бы допустим у вас вместо всех этих правил с инвентарными номерами было 4 символа какого то рандомного md5 к примеру (ed2c).
А инвентарный номер и прочая инфа всё так же в вашей красивой таблице. Это было бы удобней или нет или без разницы?
Всё равно же если серверов [буква]XXXX-YYYYsrv[номер] больше одного, то можно перепутать (человеческий фактор), а если их больше 50, то точно не запомнишь и нужно таблицу открывать.

Технический нейминг серверов. По какому принципу называть сервера?

Валентин,

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

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

Например: krv-srv-010-monitor01 - сервер в Кирове десятый по счету с целью мониторинга.

krv-srv-011-telegram-bot01
Если появится другой телеграм бот, с другим функционалом, то это будет krv-srv-012-telegram-bot02?
А если это сильно нагруженные боты и надо обеспечить отказоустойчивость четырьмя серверами?
Так?
krv-srv-012-telegram-bot02 (тут уже нельзя bot02-1, потому что мы сначала не знали про 4 сервера и уже есть bot02, хотя придётся этот переименовывать)
krv-srv-013-telegram-bot02-2
krv-srv-014-telegram-bot02-3
krv-srv-014-telegram-bot02-4

А если это бот для мониторинга? krv-srv-010-monitor01. Его нельзя на этот же сервер? Нужно krv-srv-015-telegram-bot01-for-krv-srv-010-monitor01?

Технический нейминг серверов. По какому принципу называть сервера?

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

Вот и я так подумал. "некий каталог" - есть что то более или менее подходящее для такой задачи?

Технический нейминг серверов. По какому принципу называть сервера?

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

Не такая уж и слишком.

Взять например любого программиста. У него появляется идея сделать что то сетевое, допустим html страница с портфолио. Он берёт самый дешёвый vps где то, называет её porlf-01-moscow. Эта html живёт себе, ресурсов не требует.
Появляется другая идея. Какой то веб калькулятор расхода топлива от фазы луны. По идее он должен потратить ещё денег и купить новый vps с названием calk-01-spb. Но зачем? Есть же уже сервер, на котором 0 трафика и 100% свободных ресурсов.

Потом он решает убрать портфолио, работа найдена, проект больше не нужен. Но появилась идея другого проекта, при этом есть сервер porlf-01-moscow, на котором уже настроена OS и всё необходимое окружение - пользователь, права, nginx, cerbot итд
Во первых зачем его удалять, брать новый и заново всё настраивать. Во вторых там всё ещё крутится портфолио его жены, да и своё он просто отключил, не удалять же сервер.

Сейчас олимпиада, лям компаний сделали спецпроекты одностаничники под это событие. Эти сервера получается "однодневки"? Завтра новое событие, новый спец проект. Новый сервер?

то в другую стойку перехать то еще что-то

Это конечно редкий случай. Но есть сервер в стойке, а есть сервер в облаке. Есть сервер в стойке, на котором много виртуалок. Виртуалка может сменить физический сервер. итд
Да сама стойка может географически переехать в другой офис. Поменять и своё расположение и свой номер.

Если у сервера нет конкретного назначения, используетс просто геолокация и бренд.

А зачем бренд? Это же лишняя информация. Бренд, материал, толщина корпуса сервера, его ip и географию - всё это можно где то отдельно хранить в описании.

Технический нейминг серверов. По какому принципу называть сервера?

Талян,

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

Как раз хочется уйти от ассоциаций проет-сервер.
Сервер из стойки может переехать в другую стойку. Или сервер в облаке.
Сервер может поменять своё предназначение.
Докера на сервере может не быть. Иногда может хватить bash в кроне и на этом его полномочия всё =)

Ну вы как себе по другому представляете нейминг?

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

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

Технический нейминг серверов. По какому принципу называть сервера?

Так как непонятно - что у вас за организация

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

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

Технический нейминг серверов. По какому принципу называть сервера?

Неподходит например под идею докер контейнеров.
Когда есть машина (1) с каким то проектом, у неё есть в простое некоторый запас мощности, который можно использовать. Есть нагруженный проект на втором сервере (2), можно его скопировать на сервер (1) в контейнере каком то и балансировать между ними нагрузку.

Ну и география в названии сервера не особо что то даст. Может даже помешает.
Допустим есть сервер MOW-1. Там лежит к примеру бот для соц сети. Захотелось уйти из этого дц в Питербург, а ты уже привык что бот на MOW-1, в питерском дц такой сервер уже не повторить.
Да и буквы лишние.

Это уже похоже на более высокий слой нейминга. Например техническое имя b1.example.com, а имя для географиической какой то логики mow1. Тогда можно mow1 домен перевязать на сервер a1 или балансировать между a1 и b1