Как стать автором
Обновить

DevOps: что же это такое на самом деле

Время на прочтение6 мин
Количество просмотров13K
Всего голосов 10: ↑9 и ↓1+8
Комментарии21

Комментарии 21

Читал эту книгу. Там в основном только философия и теория. Очень мало примеров.
Хотя пища для размышлений тоже есть.
НЛО прилетело и опубликовало эту надпись здесь
Опять когда говорят про DevOps, то говорят про всё что угодно кроме подробного объяснения того чем DevOps занимается конкретно и методов его работы. У меня создаётся ощущение того, что в половине случаев DevOps это про что-то мифическое о связи управленческих и инженерных должностей в обход (или в дополнение?) руководителей отделов и групп. Из чего рождается вопрос о том, а зачем это нужно если уже есть люди которые занимаются близкими вопросами (этим самые руководители)?
Поясните, пожалуйста, запутавшемуся мне, как глупому и неразумеющему инженеру, за DevOps.
НЛО прилетело и опубликовало эту надпись здесь
Работаю девопсом, прочитал статью и ничего не понял. Совсем.
В моем понимании на проекте девопс должен реализовать:
1. Инфраструктуру проекта. Подразумевается возможность работы с контейнеризацией и микросервисной архитектурой.
2. Непрерывную интеграцию, тестирование. Каждый коммит билдится, тестируется и деплоится в зависимости от требований проекта.
3. Сбор логов и статистики. С девопсом у вас явно больше 1 сервера, но логи и health сервисов всегда лучше смотреть в одном месте.
4. Гибкость проекта к нагрузкам. Автоскейлинг, даунскейлинг, алертинг и т.д.
Вы не можете работать девопсом, потому что DevOps-это методология, а не должность.
Вам придется смириться с тем, что на IT рынке присутствует должность DevOps Engineer.
Не могу не согласиться, даже в понимании должностей тут полный бардак. Есть developers, есть operations (админы), вместе они реализуют методологию DevOps. К сожалению слишком много хайпа вокруг обычный оптимизации разработки и деплоя.
Не знаю, почему Вас заминусовали. Определенно, отрасль во многих местах настолько нахваталась модных неологизмов, что зачастую ее участники перестали понимать, что DevOps — это философия разработки и доставки, HR — это не рекрутинг, а Architect — про архитектуру, а не когда Senior BE нужно зарплату повысить за выслугу лет.

За последние пару лет провёл технические интервью с толпой “DevOps Engineer” — чаще всего они понимают свою специальность как опыт с одним из облаков, умеют какой-нить оркестратор и парочку инструментов от HashiCorp. Никакого понимания о выстраивании процессов непрерывной доставки и философии вокруг этого. Тупо хайповые админы с небольшой специализацией в облачные вычисления.
Жаль что со мной не собеседовались.
Мне кажется, что вы путаете DevOps и какую-то смесь Project-manager'а, Team-lead'а и эникейщика в одном лице :) Попробую пояснить, как я понимаю, кто такие DevOps, ни разу не претендуя на истину в последней инстанции:

Со времени возникновения IT до его текущего состояния прошел очень большой период:

От голых языков программирования с бедными стандартными библиотеками мы пришли к вееру библиотек, сред исполнения, операционных систем, платформ (включая веб, мобильные платформы, серверы, IoT и другие), виртуализации, распределнным по кластерам вычислениям, кроссплатформенной разработке, частому деплою и т.д… Сложность IT-инфраструктуры, необходимой для разработки и выпуска конечного продукта возросла многократно. Если раньше достаточно было написать игру/приложение под Windows, скомпилировать все это msvc-компилятором, протестировать, записать на диск и спокойно продавать, то сейчас для создания какой-нибудь простенькой Веселой фермы с возможностью играть в нее с телефона и из браузера придется развернуть:

1. Окружение для кроссплаформенной разработки (Android, iOS, браузер), с библиотеками для связи с БД, поддержкой API соц. сетей, графикой, нативными библиотеками на устройства и т.д.
2. Систему CI/CD с автоматической пересборкой, автотестами, какой-нибудь распределенной системой контроля версий, типа git'а, чтобы обеспечить работоспособность продукта как на стадии разработки, так и в продакшне.
3. Функционирование всего этого в облаке (как минимум БД + браузерная версия на каком-нибудь популярном фреймворке).

Если речь идет о чем-нибудь более сложном, чем веселая ферма (например, о каком-нибудь крутом вычислительном кластере или сервисе поиска, типа Яндекса, который разрабатывают тысячи людей по всему миру), то все становится еще сложнее.

Собственно, DevOps — это человек, который всем этим занимается. Это далеко не просто сисадмин, который может поднять и настроить какой-нибудь удаленный почтовый сервер по ssh, это человек создающий и поддерживающий всю цепочную инфраструктуру от окружения разработчика до автоматического деплоя всего этого на серверы или устройства пользователей.
А если компания экономит на специалистах и я один поддерживаю всю инфраструктуру включая AWS, программируемые маршрутизаторы и виртуальные сервера в офисе, иногда Active Directory, если в ней что-то ломается, готовлю сервера для программистов, которые так далеко от того, на чем кончается их код, что не особо понимают почему после「chmod +x」программа начинает запускаться, то я DevOps?

Очевидно, да

А я думал, что делаю то что должен делать обычный адекватный админ.
Не, ну в современном мире реально сложно назваться серверным специалистом, если не можешь набросать быстренько скрипт на баше или каком-нить скриптовом питоне/перле.
А вся работа девопса по сути и состоит из кучи таких скриптов, связанных с какими-нить кубернетесами и ансиблами.


А еще девопс должен быть подкован в ООП?

Эникей ver. 2.0.
До того, как начала развиваться парадигма DevOps, инновации и инструментарий пребывали в стагнации
Да ну! Серьёзно?
Бывают случаи в настоящее время, когда на прямой вопрос к человеку, представляющему какой бы то ни было программный продукт: «Какая у тебя роль в проекте?» — отвечает «Я DevOps»… И что бы то ни было другое, он пояснить не в состоянии…
В связи с этим, считаю, что подобная методология все же считается не более чем трендом нынешнего мира.
Универсальные солдаты всегда в почете, но рожденный летать — плавать не сможет. Как то так)))
Ценности

Любой инженер заточен на поиск решения, и такая устремленность порой выливается в неприятие новых технологий, нежелание экспериментировать с новыми вещами, что выражается по-разному: от синдрома «неприятия чужой разработки» до контрпродуктивных попыток защищать свою нишу. Чтобы по-настоящему перейти на DevOps, эти предубеждения нужно сначала признать, а затем преодолеть. Ни одна технология, ни Docker, Kubernetes или Amazon Web Services не решит ваших проблем, если вы не понимаете, в чем заключается ценностное предложение.


Так в чем ценности то? так и не прозвучало.

И не увидел про цели.
Увидел про управление изменениями, blablabla-as-code, быструю доставку, и прочее.
Про цели — ни слова.
НЛО прилетело и опубликовало эту надпись здесь
постоянно думаю как наладить больше циклов обратной связи
Зарегистрируйтесь на Хабре, чтобы оставить комментарий