Комментарии 36
Class CTO {
work()=>null
}
Сейчас та же ситуация с безопасниками — от них больше вреда чем пользы: им всегда проще всё запретить, чем управлять сложными политиками безопасности. А разрабам проще хакнуть систему, чем ходить на поклон к безопасникам. Так что вот-вот должны появиться DevSec'и, которые будут именно разрабатывать и развивать системы безопасности, а не только всё затягивать по-максимуму.
… Админы… которым меньше изменений — хорошо
ну нет же, которым меньше работы и больше автоматизации — это хорошо.
Если админа постоянно дергают «создай нам тестовую среду и накати туда код и базу», то хороший админ по максимум это автоматизирует. т.е. тот же DevOps, нет?
Фишечка DevOps'ов, что они в одной команде с разработчиками. Разработчики пилят приложение, а DevOps скипты к terraform. Они на одном скрам-митинге друг перед другом стоят. И релиз у них общий. И цель выкатить релиз, а чтобы выкатить релиз надо инфраструктуру менять/развивать.
Есть админ, который управляет инфраструктурой компании — рабочие станции, AD/ldap, корпоративная почта, корпоративная сеть, безопасность эти все впн-ы, чтобы работать из дому. Он вообще может не знать что в проекте происходит, не иметь доступ к вашему коду и даже NDA не подписывать
Есть админ, который управляет инфраструктурой провайдера — магистрали, циски, маршрутизация, безопасность, биллинг. Он вообще не знает что у вас случается.
Есть админ, который работает внутри проекта — поднимает, настраивает, обслуживает все эти дженкинсы, тимсити, локальные фтп/артифактори, сервера где крутится дев/тест/прод, биллинг aws, кластера кубернетеса. Без него у вас будут нормально работать только одностраничники или команды максимум из 5-10 человек.
Та что же это за «классический админ», который всех тормозит? Вы с эникейщиком не путаете?
P.S. Тоже не люблю devops инжинер. Лучше software engineer, или configuration/release engineer
Так всё-таки кто это? Build (release) engineer, инженер по мониторингу, cloud engineer, dba или что-то из ещё длинного списка "специализаций"? Или многорукий (и, видимо, многозадый — чтобы сидеть на нескольких стульях) Шива?
Соглашусь с тем, что с подачи работодателей и HR как позиция devops engineer плотно вошла в нашу жизнь. И это отрицать уже нельзя
Относиться можно по-разному, но это уже ни на что не влияет.
DevOps — некоторая разновидность Шивы, соглашусь, но человек весьма уважаемый в коллективе, так как Cloud Environments становятся все сложнее и мощнее с каждым годом.
Тут палка о двух концах. С одной стороны, действительно круто, когда специалисты — то, что называется T-shaped и имеют и специализацию, и широкий кругозор. Но проблема в том, что невозможно быть специалистом во всех областях. И типичная agile-команда может столкнуться с тем, что у них не хватает компетенций, например, для оптимизации БД. И что делать?
В классическом подходе, когда есть, например, выделенный DBA такая проблема не возникнет, но он сам и его время может стать ограниченным ресурсом (вспоминаем истории, когда тикеты во внутренних учетных системах на какие-то изменения могут висеть месяцами, а ускоряются они попросту за счет личных отношений руководителей).
Я прошу не понять меня неправильно — я очень разделяю идеи agile/devops/lean-подходов. Они действительно при правильном применении дают возможность получить стабильную частоту и качество поставок (про наполнение — отдельный вопрос). Но при этом парадокс — с одной стороны, это требует очень высококвалифицированных и высокомотивированных (оба компоненты важны) сотрудников, иначе это попросту не будет работать, а средний уровень разработчика все так же падает куда-то в бездну.
С тех пор, как популярность монструозных DB типа Oracle сходит на нет, разработчики используют DB просто, чтобы хранить там данные, а для этого выделенный DBA не нужен. Обычно, один из backend-разработчиков или DevOps занимается проблемами базы. Например, когда стало не хватать производительности, это решается не очень сложно в mysql/postgres/mongodb — смотрим медленные запросы, добавляем ключи или меняем стуктуру хранения или берем более мощное железо. Проблему пофиксили — DB дальше живет сама по себе до следующих проблем. Если в команде квалификации не хватило — всегда можно привлечь сторонних консультантов, которые решат проблему. Это выгодней, чем иметь выделенного DBA.
Современный подход по хранению данных без схем(mongodb, json в mysql и postgres) позволяет избежать многих проблем при добавлении сотен новых полей что еще дальше откладывает потребность в DBA для проекта.
Есть админ, который управляет инфраструктурой компании — рабочие станции, AD/ldap, корпоративная почта, корпоративная сеть, безопасность эти все впн-ы, чтобы работать из дому. Он вообще может не знать что в проекте происходит, не иметь доступ к вашему коду и даже NDA не подписывать
Простой пример. Ваш админ — он создает учетки по заявкам в АД? Или этим техпод занимается, а админ только за сам сервис отвечает? Если все-таки сам создает, то он запросто может стать узким местом, т.к. вал заявок может быть неравномерный, в них может быть 100500 согласований и простая операция "создать учетную запись для нового пользователя" растягивается на неделю. Но здесь обычно не вина конкретного исполнителя (там делов на 5 минут создать учетку, тем более, если это уже автоматизировано), а скорее процессная — согласования, перепихивание между отделами и пр., чем славятся большие компании.
Как вы думаете, создать учетку для нового сотрудника и создать групповую политику для разных отделов компании с разным доступом — нужна одинаковая квалификация?
Системный администратор — планирует архитектуру, решает сколько нужно DC и где их разместить, согласовывет и планирует периметры безопасности с безопасниками.
Если компания большая, а в ней всего один админ, который не справляется с валом заявок — то это не проблема специальности «системный администратор». Это проблема конкретно этой компании.
Я не "опять" путаю, а конкретно спросил — у вас этим техпод занимается или нет? /Если есть автоматизация — опять же требования к сотрудникам, выполняющим типовые задачи могут снизиться /
И, да, я полностью согласен, что в некоторых организациях есть фактор организационных проблем, когда есть один админ, который вроде справляется, но ему помощников искать не хотят, "т.к. и так все хорошо"
Системный администратор — планирует архитектуру, решает сколько нужно DC и где их разместить, согласовывет и планирует периметры безопасности с безопасниками.
Ой, как это все по-разному у всех.
Я уж не говорю о том, что есть терминологическая путаница. Системный администратор — это и от мышку подоткнуть в системник, и до крупнейших веб-проектов. Что объединяет этих людей — они должны поддерживать порядок на вверенном им участке (техники, работ и пр.).
Мог физически видеть местного эникейщика, который подключал десктоп.
Но вернемся к началу треда — я не очень понимаю, почему «среднестатистический сисадмин» тормозит процесс разработки, если он наоборот — поддерживает порядок, автоматизирует рутину.
Если это будет делать один человек (без шизофрении), то очевиден перекос в одну из сторон
Но пока всё выглядит так, что с безопасностью швах: Sec'и запрещают, dev'ы хакают, чтобы легче и проще работать, а не бороться с sec'ами. В итоге получаем 100500 отчётов об утечках баз без поролей через левые порты. По моему опыту sec'и последнее, что хотят делать, это заботиться о продукте и прогрессе. В этом они ещё хуже классических админов.
Но то, что делают sec'и сейчас идёт в разрез не только удобству разрабов, но и интересам бизнеса. Интеграция Sec'ов в команду разрабов, чтобы они развивали систему безопасности, мне кажется единственным выходом из ситуации.
Посмотрим, как рыночек порешает.
Увидел такое мнение в одном из чатиков:
DevOps'ов нет и они не нужны.
а
Я СТО 10 конференции из 10 из Калининграда
а
Мы набираем челиков в Калининграде, потому что в Москве слишком дорого и поэтому мы эксплуатируем дешевую рабочую силу там
а
Не вижу разницы между админом и DevOps'ом, а потому называю их "Админ со знанием Kubernetes"
Надеюсь, что это не так и Вы действительно сколотили крутую команду и позволили ребятам заработать денег и заниматься интересной деятельностью.
Понимаете, в чем дело… Создание рабочих мест вне столицы — само по себе нейтральный факт. Он не несет ни позитивной окраски, ни негативной. Вопрос отношения к факту. Вот, например, давайте возьмем недавний пример с Амазоном — вроде как Безос открывает новый РЦ или что у них там и устраивает как будто обратный аукцион — какой регион даст ему максимальные преференции, чтобы именно в нем открыть новый объект. С одной стороны — да, здорово, создает рабочие места, позволяет людям хоть как-то заработать на жизнь. С другой стороны — что толку, если он эксплуатирует этих людей, выжимая последние соки (здесь можно поспорить, но провокационные материалы вида "сотрудникам амазона нельзя даже в туалет сходить" тут проскакивали), а еще и от властей штатов налоговые льготы и пр. получает — лучше бы он эти деньги вернул в казну США назад. А там глядишь и социалку можно было сделать какую-никакую.
Короче. Если упростить. Создал рабочие места — ок, молодец. Создал рабочие места и дал зарплаты на уровне московских или европейских (айтишники могут конкурировать на глобальном рынке, а не только локальном) — молодец вдвойне.
В регионах можно платить условные 30, а в Москве от 200. Проблем с вакансиями в ИТ в регионах нет, проблемы как раз в ЗП.
PS Открыл hh devops по Калининграду. Три вакансии, из них одна с ЗП в 30к. (:
> какие требования он видит для должности DevOps-инженера
thinking_emoji.gif
DevOps-инженер: «Я против такого понятия, как СТО БюроБюро»
Вот, интересно получается, Бэкэндщик у Артёма есть, а Девопса — нет.
???
Коротко о статье, "много букв не очем"...
Работая постоянно на одном продукте, довольно сложно внедрить новое. А нам чуть легче — начиная новый проект, мы внедряем новые технологии, которые изучили и обкатали. И от проекта к проекту мы развиваемся.
Я правильно понимаю, что Бюро не занимается поддержкой сделанного?
Артём Галонский, СТО БюроБюро: «Я против такого понятия, как DevOps-инженер»