Ключевая разница между классическим системным администратором и DevOps не в инструментах, а в реакции на сбой. В типичной админской модели всё просто. Сервис упал, сеть деградировала, АТС перестала отвечать и об этом узнают от пользователя. Через звонок, жалобу или тикет. Инцидент уже произошёл, бизнес уже потерял деньги, реакция начинается постфактум. В DevOps-подходе иначе. Сервис только начал деградировать по метрикам, алерт уже сработал. Причина локализована, исправление внесено до того, как пользователи вообще что-то заметили. В идеале без простоя. Показательный пример из жизни. У моей жены на работе системный администратор с опытом больше 15 лет. При этом алерты на серверы, сайты и АТС настраивал я. Почему? Потому что жена работает в техподдержке и ей надоело узнавать о падениях постфактум, когда пользователи уже недовольны и звонят с проблемой, которая существует не первый час. Я так же строю свои проекты. Мониторинг и алертинг не как опция, а как обязательный слой. Неважно, CRM это, АТС или обычный лендинг. Если сайт лежит и об этом узнают через день, это не мелочь, а провал операционной модели. Лежащий лендинг это потерянные заявки. Лежащая АТС это пропущенные звонки. Отсутствие алертов это не экономия, а отложенные потери. Отдельная история это коробочные сетевые решения. Часто админы по привычке используют Cisco и подобные вендорские устройства. Закрытая экосистема, дорогое железо, минимум гибкости, сложная автоматизация или её отсутствие. При этом те же задачи спокойно решаются сервером с Linux. Маршрутизация, firewall, VPN, балансировка, мониторинг. Дешевле, гибче и полностью под контролем. Поэтому, когда говорят «у нас есть админ, он следит за сетью», всегда возникает один вопрос. Он действительно следит или просто узнаёт о проблемах от пользователей.
Прям вижу как автор набирает текст и зажимает alt + 0151. Я тоже всегда так делаю. С телефона копирую — и вставляю ибо не знаю как набрать длинное тире.
Если бы в начале был чек лист. Который ты мог скопировать и ставить галочки. Для человека который в первый раз настраивает ок. Так прочитать все статью заставляют.
Как реклама телеграм-канала - ок. Но как гайд именно для первичной настройки VPS — спорно: нету чек листа короткого веачале. Вынуждаете читать всю статью.
Плюс, сам подход с ручными командами плохо масштабируется. Новичок через месяц уже не вспомнит, что он правил в sshd_config, какие порты открывал в UFW и почему именно так. А если вы делаете это регулярно, то повторять одно и то же руками каждый раз - тоже нерационально: неизбежно появляется "дрейф" конфигурации и мелкие отличия между серверами. Потому и для опытных людей бесполезно.
На практике такие вещи лучше оформлять в репозиторий Ansible (или Terraform + Ansible): роли, переменные, идемпотентность, понятный порядок шагов. Тогда вместо полотна команд просто даёте ссылку на репозиторий и запускаете playbook — и через месяц/год сервер будет настроен ровно так же, как в первый раз. И 2–3 и тд VPS поднимаются значительно быстрее, без расхождений и забытых шагов.
LLM станет (идеальным программистом и работнико) не тогда, когда у него будет ещё больше параметров, а когда сложатся три вещи: длинная и управляемая память, дешёвые вычисления (вплоть до in-memory), контроль внимания, и контроль ошибок/галлюцинаций. Технически это уже в разработке
Мой клиент про средний бизнес. Контроль результатов — это минимум, с которого стоит начинать. Я, например, проводил аудит проекта на работе у жены, хотя меня об этом никто не просил. И что выяснилось: шесть лет люди получали зарплату, а дело шло самотёком. Технический долг вырос до неприличных размеров, инфраструктура устарела уже к моменту запуска проекта в 2019 году.
При этом в штате были специалисты, которые по идее должны были предупреждать руководство о рисках и проблемах. Зарплаты у них были вполне достойные. А по факту — один толковый технический специалист и пара фрилансеров могли бы сэкономить миллионы и сделать проект куда более устойчивым.
Ключевая разница между классическим системным администратором и DevOps не в инструментах, а в реакции на сбой.
В типичной админской модели всё просто. Сервис упал, сеть деградировала, АТС перестала отвечать и об этом узнают от пользователя. Через звонок, жалобу или тикет. Инцидент уже произошёл, бизнес уже потерял деньги, реакция начинается постфактум.
В DevOps-подходе иначе. Сервис только начал деградировать по метрикам, алерт уже сработал. Причина локализована, исправление внесено до того, как пользователи вообще что-то заметили. В идеале без простоя.
Показательный пример из жизни. У моей жены на работе системный администратор с опытом больше 15 лет. При этом алерты на серверы, сайты и АТС настраивал я. Почему? Потому что жена работает в техподдержке и ей надоело узнавать о падениях постфактум, когда пользователи уже недовольны и звонят с проблемой, которая существует не первый час.
Я так же строю свои проекты. Мониторинг и алертинг не как опция, а как обязательный слой. Неважно, CRM это, АТС или обычный лендинг. Если сайт лежит и об этом узнают через день, это не мелочь, а провал операционной модели. Лежащий лендинг это потерянные заявки. Лежащая АТС это пропущенные звонки. Отсутствие алертов это не экономия, а отложенные потери.
Отдельная история это коробочные сетевые решения. Часто админы по привычке используют Cisco и подобные вендорские устройства. Закрытая экосистема, дорогое железо, минимум гибкости, сложная автоматизация или её отсутствие. При этом те же задачи спокойно решаются сервером с Linux. Маршрутизация, firewall, VPN, балансировка, мониторинг. Дешевле, гибче и полностью под контролем.
Поэтому, когда говорят «у нас есть админ, он следит за сетью», всегда возникает один вопрос. Он действительно следит или просто узнаёт о проблемах от пользователей.
Прям вижу как автор набирает текст и зажимает alt + 0151. Я тоже всегда так делаю. С телефона копирую — и вставляю ибо не знаю как набрать длинное тире.
Если бы в начале был чек лист. Который ты мог скопировать и ставить галочки. Для человека который в первый раз настраивает ок. Так прочитать все статью заставляют.
Как реклама телеграм-канала - ок. Но как гайд именно для первичной настройки VPS — спорно: нету чек листа короткого веачале. Вынуждаете читать всю статью.
Плюс, сам подход с ручными командами плохо масштабируется. Новичок через месяц уже не вспомнит, что он правил в sshd_config, какие порты открывал в UFW и почему именно так. А если вы делаете это регулярно, то повторять одно и то же руками каждый раз - тоже нерационально: неизбежно появляется "дрейф" конфигурации и мелкие отличия между серверами. Потому и для опытных людей бесполезно.
На практике такие вещи лучше оформлять в репозиторий Ansible (или Terraform + Ansible): роли, переменные, идемпотентность, понятный порядок шагов. Тогда вместо полотна команд просто даёте ссылку на репозиторий и запускаете playbook — и через месяц/год сервер будет настроен ровно так же, как в первый раз. И 2–3 и тд VPS поднимаются значительно быстрее, без расхождений и забытых шагов.
LLM станет (идеальным программистом и работнико) не тогда, когда у него будет ещё больше параметров, а когда сложатся три вещи: длинная и управляемая память, дешёвые вычисления (вплоть до in-memory), контроль внимания, и контроль ошибок/галлюцинаций. Технически это уже в разработке
Мой клиент про средний бизнес. Контроль результатов — это минимум, с которого стоит начинать. Я, например, проводил аудит проекта на работе у жены, хотя меня об этом никто не просил. И что выяснилось: шесть лет люди получали зарплату, а дело шло самотёком. Технический долг вырос до неприличных размеров, инфраструктура устарела уже к моменту запуска проекта в 2019 году.
При этом в штате были специалисты, которые по идее должны были предупреждать руководство о рисках и проблемах. Зарплаты у них были вполне достойные. А по факту — один толковый технический специалист и пара фрилансеров могли бы сэкономить миллионы и сделать проект куда более устойчивым.