Алексей Пьянов

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

Еще в 2009 за это быстро забанил яндекс один наш сайт, еле спаслись. Сейчас даже страшно подумать)

Пожалуйста, не используйте каталоги в SEO.

Потратьте час-два, почитайте про продвижение, категорически фильтруя бред "инфобизнесменов".

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

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

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

Не эффективно.

redmine

https://trello.com

trello

за 10 лет эникея только винда да шара? а как же виртуализация впн свои почтовые и вэб сервера???

в IT уже лет десять, а по сути, застрял на уровне продвинутого эникейщика

Свободная касса. Серьезно, если вы имеете 10 летний опыт работы и не знаете что делать дальше.

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

Придумайте себе сеть организации. С доменами Active Directory, с внутренней почтой (сначала, допустим, на linux/FreeBSD/postfix/dovecot, а потом -- на Exchange, или наоборот), с внутренними DNS и DHCP-серверами.

С файловыми серверами, доступ к которым на уровне доменных учётных записей и групп распределяется. И запилите эту сеть на виртуальных машинах. Несколько виртуальных серверов Windows/Unix, парочку клиентских станций с виндой/линуксом.

Поднимите свой веб-сервер, нарисуйте на нём простенький веб-сайт на базе какой-нибудь популярной CMS типа Joomla, Wordpress, чо-там-ещё-нынче-модно.

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

А потом сделайте так, чтобы VPN-канал между филиалами был зарезервирован через двух разных провайдеров, да причём переключения производились автоматически и абсолютно прозрачно для клиентов. В этом вам поможет динамическая маршрутизация и протоколы OSPF или BGP.

Факультативно -- можете поднять в удалённом филиале так называемый RoDC -- read-only domain controller :-)

Вот когда всё это запилите, то приходите за новым заданием.

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

Актуально, но в совокупности с умением автоматизировать процесс администирования. Ключеввые слова: облака, контейнеры (docker в первую очередь), ansible, chef, pupet.

Администрирование web серверов: настройка nginx, mysql и других сервисов для работы сайтов для обеспечения максимальной производительности

Пишите себе классы и библиотеки для конкретных узких задач работы с данными.
Затем, просто подключаете и все.

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

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

Фреймворки нужно писать.
Понятия "код на самописном фреймворке" и "(говно)код без фреймворка" - это две большие разницы. Неважно для какой платформы этот код.

Могу только своим опытом поделиться: во-первых избавится от зоопарка дистрибутивов. На каком именно остановится - это уже каждый под себя решает, но главное - выбрать один. Далее локальный репозиторий сделать, если это rolling release дистриб, да даже если и нет, а просто много машин - с локального будет в разы быстрее. Ну а потом уже через Ansible все автоматизировать. Разумеется сначала на тестовой виртуалке тестить обновление, потом уже раскатывать на продакшен. У меня вот, по сути, есть десктоп-линукс (на всех десктопах конторы одинаков, соответственно и у меня на компе виртуалка с точно такой же системой, на которой проверяю обновления), есть базовый серверный шаблон (с которого все виртуалки серверные и создаются), его тоже копия на виртуалке есть и тестирую на ней. Ну а специфичные серверы только клонированием виртуалки и проверкой обновлений на ней.
Таким образом у тебя всегда система везде стоит, про которую ты сам уверен, что она рабочая и нет подводных камней вида "вот тут дистрибутив один, а тут другой". У меня несколько сервисов на php например, вот вышел php 7 - все эти машины склонировал, протестировал, программисты все поправили - я на все машины в продакшене php 7 накатил за 1 раз. И т.д. и т.п.
Учетки через LDAP, Samba-то зачем, когда Линукс? Просто один LDAP и все.
Про политику безопасности - это виндовое понятие, в линуксе по-другому слегка. Конфиг везде через ansible обновил и все, если он где-то вдруг его не смог поменять - он ж напишет об этом. Но если ты вначале позаботился и зоопарк дистрибутивов устранил - все будет четко работать в будущем, без головняков.

1. как происходит обновление в линукс, если в сети есть разные версии линукса, редхат, дебиан, с разными версиями ядра, по.?

У каждого - своим пакетным менеджером. У дебиана это apt-get, у шляпной линии (Red Hat, CentOS, Fedora) - yum

2. каким образом централизовано можно управлять политикой безопасности? я понимаю можно скрипт написать и запустить через ansible, но это думаю костыль.

Что есть в Вашем понимании "политика безопасности"? GPO Default Domain Policy? Права на файлы? Еще что-то?

3. каким образом происходит централизованное управление учетных записей?
только не самба4 и лдап, имитация АД, это костыль.

Ну щас. Это AD - надстройка над LDAP, с ней прекрасно работают скрипты и программы для LDAP-серверов. Есть альтернативные реализации Directory Server

4. допустим крутиться сервер, выпустили обновление, стоит ли обновлять ядро? ведь при обновлении есть вероятность что не будет работать субд

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