1) Моя личность никому не интересна. Я начинающий сисадмин и ничем от остальных не отличаюсь. Не хочу, чтобы это выглядело как реклама. Слушать меня или нет - пусть решает каждый сам для себя. Но я бы на их месте вгрызался бы в любую информацию. С чего вы решили, что статья провокационная и что автор хам? Что без профильного образования не следует идти дальше? Так это в большинстве профессий так. Что женщинам в технических специальностях делать нечего (с чем я не согласен)? Что (о ужас) надо читать книги? Что технари на дух не переносят менеджеров? Или что? Ладно, оставим этот вопрос.
Никто не говорит, что нужно рекламировать себя. Речь идет за то, что свою теорию (теория развития специалиста) было бы не плохо подкрепить некоторыми фактами, не более того. И более того, раз уж Вы позиционируете себя именно как начинающего специалиста, с чего Вы решили, что Ваши выводы истинны? Обратите внимание на другие статьи на этом ресурсе (речь идет за добротные, разумеется), они состоят из трех частей: постановка задачи, ее выполнение и полученные результаты.
Тот же Nagios позволить себе может далеко не каждая организация.
Интересно, почему? Он же вроде как opensource? Или речь идет за внедрение?
А про выбор между различными бесплатными решениями - я просто не могу терпеть зоопарк, когда разные организации используют разные решения для одних и тех же задач.
Вам не кажется, что это может быть ошибочным? Задачи могут быть на первый взгляд одинаковыми, но дьявол кроется в деталях. В каких-то ситуациях одно решение будет более эффективным, в других - другое. Не стоит быть столь категоричным.
Про выбор дистрибутива тоже рассказал: только Debian/Ubuntu, в целом без разницы. RHEL коммерческие, попробуйте купить лицензии на юр. лицо, открытое в РФ или РБ.
Интересно, как же сейчас львиная доля инфраструктуры в нашей стране вполне себе успешно крутится на чет-то похожем на RHEL (CentOS, AlmaLinux, Rocky)?
4) Про ЯП. Изучать программирование сисадмину средней руки (тот же Python) вовсе не обязательно. Без него можно спокойно жить, если это только не какие-то специфичные задачи. То же самое и про git, Ansible и т.п.
Ну что ж, тут можно посоветовать лишь одно - помониторить рынок. Если открыть около половины годных и около-годных вакансий, то в требованиях будет git и ansible. Вы не думали, что стек изучаемых технологий должен строиться не только на базе Ваших предпочтений, но и на требованиях рынка?
И да, не надо пытаться себе набить цену, как предыдущие комментаторы - DevOps и DBA. Показывайте свои навыки работодателю, а не мне и другим начинающим специалистам. Знаете и применяете - отлично, могу только позавидовать.
Даже и не пытался набить себе цену, в этом нет смысла. И уж тем более не пытался показать свои знания. Я лишь указал на огрехи в Вашей статье, не более того.
Перечитайте статью еще раз (хотя кто меня слушает). Статья для НАЧИНАЮЩИХ сисадминов, которым необходимы БАЗОВЫЕ (но лучше назвать это все же ОСНОВНЫЕ) вещи. То есть для людей, которые либо все еще учатся, либо недавно выпустились.
Да, тут согласен, вероятно я немного погорячился.
А так, в целом, статья то не плохая, просто дополнить некоторыми идеями и меньше резких высказываний, вроде разделения на людей на привелегированных (с профильным образованием) и нет, но это мое личное мнение. Также, лично я добавил бымысль о том, что идти в эту сферу нужно не за деньгами, а за идеей. То есть, оно должно просто нравиться, нужно любить это. Но, опять же, это мое личное мнение и мой личный опыт и наблюдения. Также, независимо от опыта работы, может быть полезным ходить по собеседованиям, это позволяет как проверить свои знания и навыки, так и прощупывать рынок.
Статья получилась достаточно провокационная. Если абстрагироваться от хамства и максимализма по тексту, можно сказать, что не хватает одной небольшой детали. Вы описали как нужно делать, при этом, местами проскакивало что эта статья - антипод Вашему опыту. Может стоило затронуть в том числе и свой опыт, чтобы начинающим было понятно не только как нужно делать, но и как не нужно, и почему? Плюс к этому, Вы опустили рассказ о себе, чтобы читатель мог поймать себя на мысли: да, этому парню можно доверять, я хочу также! Человек же должен понимать что может получиться, если он применит Ваши рекомендации?
Далее, очень сильно смущают рекомендации в плане ПО. Вот Вы рекомендуете Nginx. Ок, а под какую задачу? А почему Nginx, а не HAProxy? Почему не упоминаете достойных конкуретов Nginx, таких как тот же HAProxy. По мониторингу аналогично, Zabbix и баста. А как же Nagios? Чем не устроила связка Prometheus+Grafana? По поводу MTA тоже не очень понятна рекомендация exim. Почему не postfix? Не очень понятно на каком вообще основании рождаются подобные рекомендации и чем они подкреплены. Или это рекомендации типа "порекомендовал с чем сталкивался"?
Рекомендовать Ubuntu с формулировкой "все остальные изобретают велосипед" - просто смехотворно. Ubuntu и есть велосипед, собранный из Debian. Если так уж хочется дистрибутив с apt, тогда уже Debian. А что, если хочется что-то RHEL-образное?
Идем дальше. В разделе, посвящунному СХД, тоже заметна крайне странная рекомендация - TrueNAS и, что самое страшное, эта рекомендация для "нормальных" системных администраторов, которым GUI должен быть чужд (по Вашим же словам). Может нормальному системному администратору будет целесообразно изучить как построить RAID из пачки дисков (либо собрать ZFS пул из этой же пачки дисков) и руками настроить SMB- или NFS-шару? Или, как альтернатива, взять готовое решение (доступен ли сейчас NetApp и есть ли альтернативы ему на рынке?).
Вы, по какой-то неведомой причине (или эта причина - максимализм?) предоставляете очень узкий список ПО для изучения, но при этом, по какой-то причине, упускаете ряд весьма полезных инструментов, без которых жизнь в наше время практически невозможна: git, ansible/chef/saltstack.
Переходим к ЯП. А почему не стоит даже пытаться учить ЯП, отличные от одноклеточных shell-скриптов? А как же Python, который очень популярен в кругах системных администраторов? Почему бы не изучить PHP, чтобы была возможность уйти немного в сторону SRE в какой-нибудь маленькой продуктовой компании? Может даже и не уйти в SRE, а сделать какую-то автоматизацию, которая на несколько порядков сложнее одноклеточного shell-скрипта в кроне. Или, почему бы не научиться читать код на C/C++, с целью понимания работы того или иного opensource-продукта?
Подводя итог, Вам не кажется, что местами Вы даете вредные советы?
Вероятно, я не совсем корректно понял введение в статью, но тем не менее, почему nginx+haproxy? Почему бы не оставить просто haproxy, если он так же может проксировать? Также, было бы не плохо добавить в графики результаты тестов с одним лишь haproxy.
Вы это уже попытались сделать. В тексте статьи вы сравнили nginx и OLS. Разве нет? А теперь вы хотите денег за результаты тестов? Серьёзно? Более того, в чем я не прав? Я где-то говорил, что nginx быстрее? Не припомню. Я говорил за то, что он не так плох, и мировая практика это показывает. Также, я говорил, что вы не привели ни одного весомого аргумента. Так в чем я не прав? И что вы хотите доказать?
Как вы пытаетесь доказать? «X лучше чем Y, но я не покажу почему, просто верьте мне». Понимаете, если вы решили сравнить X и Y, то делайте это по-человечески. Не нужно ссылаться на маркетинговые тесты. Проведите свои тесты, раскройте методику тестирования, покажите результаты.
Идиотская практика? Почему? Понимаете, в статье вы высказались по поводу всего, но не пояснили свою точку зрения. Это хорошо, это плохо, надо так. Почему? Потому что так и все.
Вот вы можете аргументировать свою точку зрения?
Идём дальше. Что делать, если есть легаси, работающее через httpd+mod_php и нужно балансировать нагрузку? Что, reverse proxy — табу? Или есть другие, более привлекательные варианты?
PS: не хотел никого обидеть мухосранском. Сам живу за 1000км от МКАДа.
Очевидное? Ну это не для всех очевидно. Более того, nginx — это стандарт фронтенда де-факто. Вы это пытаетесь опровергает, но считаете, что нет смысла доказывать это, так как это очевидно. Не кажется вас странным?
Насчёт того, что я нашёл и нет. Разумеется удалось найти тесты, но они мне показались не совсем достоверными.
И последнее. Cloudflare — лентяи и бездари, Вам то с мухосранска виднее.
Интересное высказывание. Cloudflare и масса других крупных компаний — неудачники? Ну что ж, Вам виднее. Вопрос в другом, Вы лично проводили тесты? Если да, то можно результаты? И да, я видел результаты тестов в блоге OLS, но они не внушают доверия.
Тогда немного другой вопрос. Вы ранее использовали альтернативы, например, ELK-стек? Если да, то какова разница по «тактильным» ощущениям? Также, если ваша текущая «схема» используется в продакшене, какие впечатления от ее использования? Есть ли какие-то нюансы?
Спасибо за статью! Делал аналогичное с помощью Logstash, логика получилась весьма не простой. Обработка различных ситуаций с 499 — не совсем очевидная и тривиальная задача. Да, я видел, что в конфигурации используется proxy_ignore_client_abort, но там тоже могут проскакивать 499 с полупустым $upstream_status. Плюс есть забавные спец-эффекты, которые могут кому-то не понравиться. А если по теме, то не совсем понятно зачем используется avg(), когда CH имеет quantile().
PS: прошу прощения за возможные опечатки, пишу с телефона и не совсем удобно видеть всю мою писанину.
Интересное мнение. У нас немного другой опыт. Из всей связки мы используем только Logstash. ES выкинули на помойку по ряду причин. Во-первых, он таки тяжелый. Во-вторых, он не очень хорошо переживает «катастрофы» в виде отключения питания. Да, понимаю, тут сказывается небольшой опыт работы с ним. Но, если он исключительно для логов, далеко не все будут для этой цели искать нормального специалиста или глубоко изучать это решение. И третье — скорость работы. И последнее, документоориентированные СУБД позволяют вольности в виде содержимого документов, а это может превратить данные в помойку.
Собственно, на данный момент в роли хранилища логов используем ClickHouse. Из плюсов, достаточно быстрый, особенно на фоне ES (для сравнение, ClickHouse на аналогично наборе данных отдает ответ за 300мс против 1,5 сек у ES). Также, он не позволяет вольностей в виде содержимого записей, и как итог — предсказуемое наполнение базы.
А вот Logstash пока импонирует, вероятно потому что событий у нас не так много, порядка 150 событий/сек.
Ну тут небольшая поправка. В Бранске, Орле, Калуге и т.д. наверняка нет понятия эникейщик. Эникейщиков там называют сисадминами, поэтому и получается подобная статистика.
Это само собой разумеющееся, я всего-навсего немного развил мысли автора, не сильно углубляясь. Понятное дело, что при должном уровне паранойи необходимо заново поднимать сервер в такой ситуации.
Вопрос по проверке cron'а, что делать, если злоумышленник менял не пользовательскую конфигурацию, а системную? А если и пользовательскую, но создал еще одного root'а? А если изменил login shell для любого системного пользователя (плюс добавил пароль, разумеется), добавил его в sudoers и таким образом имеет backdoor с root'ом? Также, он мог банально повесить SUID-бит на /bin/bash, либо положить wrapper для оболочки с этим битом, чтобы иметь root'а при логине под любым пользователем.
Собственно, исходя из этого на мой взгляд нужно как минимум:
Ежедневно проверять список файлов с SUID-битом (интересно, но во FreeBSD есть periodic-задание для этого)
Проверять не crontab -l, а /var/spool/cron, /etc/crontab и /etc/cron.*
Регулярно проверять изменения в /etc/passwd, возможно даже настроить мониторинг на изменение этого файла (по дефолту в zabbix'е есть даже триггер на это)
Проверять /etc/sudoers
Диски, на которые происходит заливка файлов с внешнего мира, монтировать с флагами nosuid и noexec
Ну тут спорно, так как знание значения констант — как правило избыточно. «Хороший инженер не тот, кто все знает, а тот, кто знает где это найти» (с) инженер-конструктор
ИМХО, на собеседовании нужно узнать ход мышления соискателя и набор базовых знаний, но никак не значение констант.
Допустим, просто файловый сервер, но достаточно быстрый, емкий (20ТБ+) и отказоустойчивый. Подобную задачу тяжело решить одним серверов, забитым жесткими дисками, поэтому хотелось бы почитать о том, как реализуются подобные вещи, на что стоит обращать внимание при построении подобных хранилищ.
Никто не говорит, что нужно рекламировать себя. Речь идет за то, что свою теорию (теория развития специалиста) было бы не плохо подкрепить некоторыми фактами, не более того. И более того, раз уж Вы позиционируете себя именно как начинающего специалиста, с чего Вы решили, что Ваши выводы истинны? Обратите внимание на другие статьи на этом ресурсе (речь идет за добротные, разумеется), они состоят из трех частей: постановка задачи, ее выполнение и полученные результаты.
Интересно, почему? Он же вроде как opensource? Или речь идет за внедрение?
Вам не кажется, что это может быть ошибочным? Задачи могут быть на первый взгляд одинаковыми, но дьявол кроется в деталях. В каких-то ситуациях одно решение будет более эффективным, в других - другое. Не стоит быть столь категоричным.
Интересно, как же сейчас львиная доля инфраструктуры в нашей стране вполне себе успешно крутится на чет-то похожем на RHEL (CentOS, AlmaLinux, Rocky)?
Ну что ж, тут можно посоветовать лишь одно - помониторить рынок. Если открыть около половины годных и около-годных вакансий, то в требованиях будет git и ansible. Вы не думали, что стек изучаемых технологий должен строиться не только на базе Ваших предпочтений, но и на требованиях рынка?
Даже и не пытался набить себе цену, в этом нет смысла. И уж тем более не пытался показать свои знания. Я лишь указал на огрехи в Вашей статье, не более того.
Да, тут согласен, вероятно я немного погорячился.
А так, в целом, статья то не плохая, просто дополнить некоторыми идеями и меньше резких высказываний, вроде разделения на людей на привелегированных (с профильным образованием) и нет, но это мое личное мнение. Также, лично я добавил бымысль о том, что идти в эту сферу нужно не за деньгами, а за идеей. То есть, оно должно просто нравиться, нужно любить это. Но, опять же, это мое личное мнение и мой личный опыт и наблюдения. Также, независимо от опыта работы, может быть полезным ходить по собеседованиям, это позволяет как проверить свои знания и навыки, так и прощупывать рынок.
Статья получилась достаточно провокационная. Если абстрагироваться от хамства и максимализма по тексту, можно сказать, что не хватает одной небольшой детали. Вы описали как нужно делать, при этом, местами проскакивало что эта статья - антипод Вашему опыту. Может стоило затронуть в том числе и свой опыт, чтобы начинающим было понятно не только как нужно делать, но и как не нужно, и почему? Плюс к этому, Вы опустили рассказ о себе, чтобы читатель мог поймать себя на мысли: да, этому парню можно доверять, я хочу также! Человек же должен понимать что может получиться, если он применит Ваши рекомендации?
Далее, очень сильно смущают рекомендации в плане ПО. Вот Вы рекомендуете Nginx. Ок, а под какую задачу? А почему Nginx, а не HAProxy? Почему не упоминаете достойных конкуретов Nginx, таких как тот же HAProxy. По мониторингу аналогично, Zabbix и баста. А как же Nagios? Чем не устроила связка Prometheus+Grafana? По поводу MTA тоже не очень понятна рекомендация exim. Почему не postfix? Не очень понятно на каком вообще основании рождаются подобные рекомендации и чем они подкреплены. Или это рекомендации типа "порекомендовал с чем сталкивался"?
Рекомендовать Ubuntu с формулировкой "все остальные изобретают велосипед" - просто смехотворно. Ubuntu и есть велосипед, собранный из Debian. Если так уж хочется дистрибутив с apt, тогда уже Debian. А что, если хочется что-то RHEL-образное?
Идем дальше. В разделе, посвящунному СХД, тоже заметна крайне странная рекомендация - TrueNAS и, что самое страшное, эта рекомендация для "нормальных" системных администраторов, которым GUI должен быть чужд (по Вашим же словам). Может нормальному системному администратору будет целесообразно изучить как построить RAID из пачки дисков (либо собрать ZFS пул из этой же пачки дисков) и руками настроить SMB- или NFS-шару? Или, как альтернатива, взять готовое решение (доступен ли сейчас NetApp и есть ли альтернативы ему на рынке?).
Вы, по какой-то неведомой причине (или эта причина - максимализм?) предоставляете очень узкий список ПО для изучения, но при этом, по какой-то причине, упускаете ряд весьма полезных инструментов, без которых жизнь в наше время практически невозможна: git, ansible/chef/saltstack.
Переходим к ЯП. А почему не стоит даже пытаться учить ЯП, отличные от одноклеточных shell-скриптов? А как же Python, который очень популярен в кругах системных администраторов? Почему бы не изучить PHP, чтобы была возможность уйти немного в сторону SRE в какой-нибудь маленькой продуктовой компании? Может даже и не уйти в SRE, а сделать какую-то автоматизацию, которая на несколько порядков сложнее одноклеточного shell-скрипта в кроне. Или, почему бы не научиться читать код на C/C++, с целью понимания работы того или иного opensource-продукта?
Подводя итог, Вам не кажется, что местами Вы даете вредные советы?
Вероятно, я не совсем корректно понял введение в статью, но тем не менее, почему nginx+haproxy? Почему бы не оставить просто haproxy, если он так же может проксировать? Также, было бы не плохо добавить в графики результаты тестов с одним лишь haproxy.
Вы пару комментариев назад написали, что пытаетесь доказать.
Да, я не привёл аргументов, так как:
Вы это уже попытались сделать. В тексте статьи вы сравнили nginx и OLS. Разве нет? А теперь вы хотите денег за результаты тестов? Серьёзно? Более того, в чем я не прав? Я где-то говорил, что nginx быстрее? Не припомню. Я говорил за то, что он не так плох, и мировая практика это показывает. Также, я говорил, что вы не привели ни одного весомого аргумента. Так в чем я не прав? И что вы хотите доказать?
Вот вы можете аргументировать свою точку зрения?
Идём дальше. Что делать, если есть легаси, работающее через httpd+mod_php и нужно балансировать нагрузку? Что, reverse proxy — табу? Или есть другие, более привлекательные варианты?
PS: не хотел никого обидеть мухосранском. Сам живу за 1000км от МКАДа.
Насчёт того, что я нашёл и нет. Разумеется удалось найти тесты, но они мне показались не совсем достоверными.
И последнее. Cloudflare — лентяи и бездари, Вам то с мухосранска виднее.
Интересное высказывание. Cloudflare и масса других крупных компаний — неудачники? Ну что ж, Вам виднее. Вопрос в другом, Вы лично проводили тесты? Если да, то можно результаты? И да, я видел результаты тестов в блоге OLS, но они не внушают доверия.
Спасибо за статью! Делал аналогичное с помощью Logstash, логика получилась весьма не простой. Обработка различных ситуаций с 499 — не совсем очевидная и тривиальная задача. Да, я видел, что в конфигурации используется proxy_ignore_client_abort, но там тоже могут проскакивать 499 с полупустым $upstream_status. Плюс есть забавные спец-эффекты, которые могут кому-то не понравиться. А если по теме, то не совсем понятно зачем используется avg(), когда CH имеет quantile().
PS: прошу прощения за возможные опечатки, пишу с телефона и не совсем удобно видеть всю мою писанину.
Собственно, на данный момент в роли хранилища логов используем ClickHouse. Из плюсов, достаточно быстрый, особенно на фоне ES (для сравнение, ClickHouse на аналогично наборе данных отдает ответ за 300мс против 1,5 сек у ES). Также, он не позволяет вольностей в виде содержимого записей, и как итог — предсказуемое наполнение базы.
А вот Logstash пока импонирует, вероятно потому что событий у нас не так много, порядка 150 событий/сек.
Собственно, исходя из этого на мой взгляд нужно как минимум:
ИМХО, на собеседовании нужно узнать ход мышления соискателя и набор базовых знаний, но никак не значение констант.