ВУЗ и не учит ( не должен/обязан учить ), а должен предоставлять доступ к знаниям. По крайней мере точные науки по программе всяко лучше и проще учить, чем одному сидеть и читать.
Мой опус относился ровно к одной фразе —
«В том виде, в котором ВУЗы учат сейчас «компьютерщиков» не нужны чуть более чем полностью никому. Ну только, чтобы преподаватели работали и жаловались как было прекрасно в СССР.»
, не более.
Хоть и сам работаю в IT, но считаю, что уровень ожидания в IT несколько завышен, будь ты выпускником или нет.
Можете привести примеры профессий или специальностей, в которых после окончания учебы человек будет уверен, что будет получать нормальные для проживания деньги и найдет работу в своем городе?
Вас самого не пугает, что скоро ещё больше ИТ специалистов окажется на улице или на низкооплачиваемых работах?
Может быть я покажусь циничным, но нет. ИТ специалист, именно специалист, а не получивший диплом универсистета и/или не освоивший только переустановку ОС с флешки всегда найдет работу.
Ни одно учебное заведение не даст знаний, если человек не хочет учиться. Но при этом если студентов не будут протаскивать через годы учебы и закрывать на что-то глаза, то большей части студентов не останется. А кто пойдет в вуз, из которого выходит всего 10-20%, а остальных выгоняют?
Очень интересна техническая сторона вопроса. Трафик смотрите вразрез ( гоните через себя ) или сбоку ( используете свое оборудование на площадках заказчиков / используете оборудование заказчика и получаете только логи/трафик )? Используете в качестве захвата и анализа трафика самописное ПО или СПО/общеизвестное? В качестве анализа используете сигнатуры и/или эвристику?
Хорошо, когда есть возможность слушать трафик до хоста, либо с хоста перенаправлять трафик, но бывают случаи, когда это сделать невозможно. Тем более, что сбор логов с хостов и так есть.
без 777 в проде у вас php не сможет писать в свои же каталоги, потому как каталог создан от одного пользователя, а fpm пускается от nginx/www-data/apache, а стандартная маска запрещает other писать в каталог. надо либо в конфиге пула fpm менять user/group либо chown делать на каталоге.
Добавьте к этому чихающих в автобусе людей, коллег рядом, которые стойко переносят болезни на ногах, пробки и другие прелести улицы ( дождь, ветер, снег ).
Если будете поднимать из бекапа сайт до рабочего состояния сутки, то никто спасибо не скажет. Данные есть, но конфиги и список ПО потерян, а у вас хитрые рерайты, настройки СУБД, кастомные модули и куча взаимосвязанного ПО. Бекап без схемы восстановления — это только куча файлов в архиве.
В конфиге правильной сборки много мусорных ключей "--with-http_dav_module --with-http_flv_module -with-mail --with-mail_ssl_module". Зачем они нужны, если в Вашей текущей конфигурации не используются?
Даже если контейнер на сервере один docker-compose позволяет забыть про поиск параметров запуска текущего контейнера и отказаться от «history | grep docker».
Также я бы рекомендовал ( а может и посоветуют мне? =) ) отказаться от хранения рабочих файлов и конфигов внутри докер контейнеров и мапить их с самого сервера. Почему:
1. Чтобы изменить файл, нужно зайти сначала на сервер, потом сделать docker exec, изменить файл, выйти и закоммитить контейнер. А если у нас какой-нибудь легкий alpine образ, а не FROM: ubuntu:16.04, то это становится огромной проблемой.
2. При обновлении контейнера не нужно думать, что что-то в процессе обновления пойдет не так. Мы просто обновляем докер образ, убиваем контейнер, создаем заново из композа и вуаля, новый обновленный контейнер без лишних хлопот.
Также крайне рекомендую отдельные сайты разносить под отдельных пользователей :
В плане безопасности.
Ломают один сайт — вешают шелл, шелл запускается от пользователя, а не от www-data.
В плане стабильности и анализа нагрузок.
Через top и аналогичные сможем увидеть, какой пользователь насколько грузит систему
В плане работы с файлами
Стандартный umask 755, соответственно, файлы созданные из php будут иметь владельца www-data с разрешениями 755 и при работе из под пользователя, владельца сайта ( допустим через ftp ) пользователь будет не в состоянии изменять файл.
user = user
group = user
listen = /var/run/site.ru.sock
listen.owner = user
listen.group = www-data
listen.mode = 0660
Можете подсказать, для каких целей требуется использовать версии php не из репозиториев системы? Понятно, что для хайлоад проектов требуется собирать ПО с нужными опциями и отключать ненужные, но для среднего блога я не вижу разницы в использовании совсем новых сырых релизов, при том, что в новом новых версиях баги и дырки находят значительно чаще, чем в старых. Тут можно ( если можно ) сравнить с сопровождением Linux систем в целом. Выходит новый релиз, ждешь год для обкатки, выявления багов и уязвимостей, потом начинаешь внедрять для проектов.
dotdeb для продакшена крайне плох. По опыту — очень нестабильные пакеты у них. По поводу TCP/IP vs unix socket — не видел проектов, чтобы быстрый сокет проигрывал по скорости, стабильности, ресурсоемкости TCP/IP подключению, зато видел сотню висящих соединений в SYN_RECV. И по логике вещей при каждом новом подключении к tcp/ip сокету нужно будет ждать tcp handshake.
2. Бекапы складывать на том же сервере, где находится БД — так себе затея.
Ради интереса пролистал яндекс. Опыт работы от двух, трех лет либо за 10000
Мой опус относился ровно к одной фразе — , не более.
Хоть и сам работаю в IT, но считаю, что уровень ожидания в IT несколько завышен, будь ты выпускником или нет.
Можете привести примеры профессий или специальностей, в которых после окончания учебы человек будет уверен, что будет получать нормальные для проживания деньги и найдет работу в своем городе?
Может быть я покажусь циничным, но нет. ИТ специалист, именно специалист, а не получивший диплом универсистета и/или не освоивший только переустановку ОС с флешки всегда найдет работу.
Смысл самой системы бекапирования не полностью в сохранности данных, а еще и во времени восстановления после сбоя.
Также я бы рекомендовал ( а может и посоветуют мне? =) ) отказаться от хранения рабочих файлов и конфигов внутри докер контейнеров и мапить их с самого сервера. Почему:
1. Чтобы изменить файл, нужно зайти сначала на сервер, потом сделать docker exec, изменить файл, выйти и закоммитить контейнер. А если у нас какой-нибудь легкий alpine образ, а не FROM: ubuntu:16.04, то это становится огромной проблемой.
2. При обновлении контейнера не нужно думать, что что-то в процессе обновления пойдет не так. Мы просто обновляем докер образ, убиваем контейнер, создаем заново из композа и вуаля, новый обновленный контейнер без лишних хлопот.
1. Ищем, где инклудится конфиг:
2. В раздел добавляем:
Ломают один сайт — вешают шелл, шелл запускается от пользователя, а не от www-data.
Через top и аналогичные сможем увидеть, какой пользователь насколько грузит систему
Стандартный umask 755, соответственно, файлы созданные из php будут иметь владельца www-data с разрешениями 755 и при работе из под пользователя, владельца сайта ( допустим через ftp ) пользователь будет не в состоянии изменять файл.