Комментарии 10
А как выглядит типичный день DevOPS специалиста? Что он такого особенного делает в отличии от linux админа?
Основное отличие в подходе к работе и зонах ответственности. Если у инженера есть четкие обязанности, например:
Он строго соблюдает свои протоколы, и как работают продуктовые сервисы его не особо волнует, а в прикладной команде случился факап, где приложение не справляется с нагрузкой и падает. Обычный инженер проверит мониторинги, скажет, что алертов по инфре не видит, «это что-то на вашей стороне» и пойдет пить чаек или продолжит делать задачи из бэклога.
Культура DevOps смывает размывает границы зон ответственности и подразумевает синэргию команд Ops и Dev. Проще говоря, админам становится интересно, как работает приложение и предлагают методы, которые по инфраструктурной части помогут найти способы оптимизации, а разработчики в свою очередь могут взять на поддержку инструменты, которые для них подготовили админы. И когда происходит проблема, linux админ не только смотрит на мониторинг и констатирует факт, но и предлагает воркэраунд решения, которые помогут в наикрайчайшие сроки устранить простой.
- следить за мониторингом
- делать задачи из бэклога
Он строго соблюдает свои протоколы, и как работают продуктовые сервисы его не особо волнует, а в прикладной команде случился факап, где приложение не справляется с нагрузкой и падает. Обычный инженер проверит мониторинги, скажет, что алертов по инфре не видит, «это что-то на вашей стороне» и пойдет пить чаек или продолжит делать задачи из бэклога.
Культура DevOps смывает размывает границы зон ответственности и подразумевает синэргию команд Ops и Dev. Проще говоря, админам становится интересно, как работает приложение и предлагают методы, которые по инфраструктурной части помогут найти способы оптимизации, а разработчики в свою очередь могут взять на поддержку инструменты, которые для них подготовили админы. И когда происходит проблема, linux админ не только смотрит на мониторинг и констатирует факт, но и предлагает воркэраунд решения, которые помогут в наикрайчайшие сроки устранить простой.
Проще: когда админ и программер спорят на чьей стороне проблема и не признают оба. То уволить обоих и нанять одного DevOps специалиста. Ему не на кого будет спихивать проблему, т.к. он и админ и программер.
Как показывает практика не проще) Такой специалист будет вынужден постоянно отвлекаться от своей основной задачи — создавать продукт, который будет приносить прибыль. Тот подход, что вы описали, возможно, будет релевантен в небольших компаниях.
Именно, возникает конфликт интересов, пилить фичу или чинить баги и обеспечивать отказоустойчивость.
Я думаю, можно так объяснить разницу межу админом и девопсером.
Девопсер — в основном про Change и автоматизацию работы как разрабов, так и админов в текущем ИТ ландшафте.
Админ — в основном про RUN — те выполнение типизированных операций с помощью инструментов, которые ему создал девопсер, программер, комюнити.
Девопсер — в основном про Change и автоматизацию работы как разрабов, так и админов в текущем ИТ ландшафте.
Админ — в основном про RUN — те выполнение типизированных операций с помощью инструментов, которые ему создал девопсер, программер, комюнити.
Скорее, вместо админа нанимается девопс, а у программиста меньше болит голова и он более эффективно создает продукт.
1) общается с программистами, тестировщиками и т.д.
2) настраивает для них инструменты
3) помогает чинить всё, а не только если сервак упал
:)
2) настраивает для них инструменты
3) помогает чинить всё, а не только если сервак упал
:)
Крутая статья, спасибо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стать инженером DevOps в 2021 году: подробное руководство