Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
Заменяем слово devops на «сепульки», а agile на «сепуление» и смысл статьи не меняется.
Так можно всё что угодно поменять без риска для смысла — язык, он такой. Да и люди не глупые.
Нет. Если мы возьмём фразу «При написании юнит-тестов использование адаптеров к внешним зависимостям вместо мока самих зависимостей позволяет использовать стабы для фиксации внутреннего стабильного интерфейса, выделяя проверку соответствия внутреннего интерфейса внешнему в интеграционные тесты», и в этой фразе заменим любое непонятное слово на «сепулька», то фраза перестанет быть осмысленной.
А в этой статье если в фразе «Модель Agile предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности.» если мы напишем «Модель сепулек предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности.», то ничего не поменяется, потому что взаимодействие «плодотворное», имеет «общие цели и правила» и следует «общим критериям эффективности».
А в этой статье если в фразе «Модель Agile предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности.» если мы напишем «Модель сепулек предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности.», то ничего не поменяется, потому что взаимодействие «плодотворное», имеет «общие цели и правила» и следует «общим критериям эффективности».
Прочел статью и ничего не понял. Начал искать блог какой компании и не нашел. Странно.
Я знаю зачем и кому нужен DevOps, но из статьи это совсем не понятно. Вроде и круто, но не понятно зачем.
Я знаю зачем и кому нужен DevOps, но из статьи это совсем не понятно. Вроде и круто, но не понятно зачем.
Внятно объяснить, что же такое DevOps, по-моему, до сих пор никто не смог
Мне одному кажется странным такое количество статей по предмету, который никто даже не может внятно определить?
На помощь приходят методологии гибкой и стремительной, а иногда и экстремальной, разработки. Это действительно позволяет частично решить указанную проблему.
Хороший ряд. Прекрасно иллюстрирует непонимание термина XP. Ставлю за него заслуженный минус.
В продолжение ряда стоит добавить PP:
Есть экстремальное программирование (XP), а есть психопатическое (PP). Основные приемы и методы его:
- Проект всегда начинается в пятницу вечером и должен быть закончен к понедельнику
- Изменения в проект вносят тестировщики и админы
- Иногда еще уборщица и генеральный директор
- ТЗ отсутствует
- Выбор архитектуры происходит после написания кода
- И меняется не менее двух раз
- В день
- На продакшен-сервере стоит ПО пятилетней давности, а на тестировочном — последние версии
- День сдачи проекта — вчера и не может быть изменен
- Команда меняется каждую неделю
- Руководитель команды меняется каждый день
- Документация ведется на бумажках, приклеенных к монитору
На продакшен-сервере стоит ПО пятилетней давности, а на тестировочном — последние версии.
Бывали случаи, когда всё было наоборот. Производитель софта работает с окружением пятилетней давности, хотя могла уже поменяться даже не одна мажорная версия компонентов этого самого окружения.
Документация ведется на бумажках, приклеенных к мониторуАга, так она всё-таки ведётся!
На помощь приходят методологии гибкой и стремительной, а иногда и экстремальной, разработки. Это действительно позволяет частично решить указанную проблему.
Но это же ненормально! Самим загонять себя в рамки постоянного экстрима. Работа должна быть планомерной и постоянной.
Состояние экстрима, как по мне, это не решение проблемы. Это латание дыр. И на позиции постоянной методологии будет приводить к тому, что где-то у нас что-то прохудится, и опять понадобятся костыли. Тем более что внятно объяснить, что же такое DevOps, опять мало кто может. Получается эдакая многорукая шива. Эникей 80го лвла. Если эникеи занимались всем простым и плюс некоторым администрированием, то тут получается смесь занимается администрированием и плюс программированием и разработкой продукта на постоянной основе. Ну если я правильно понимаю суть этого самого DevOps. Тогда ошибки неизбежны.
Экстрим на то и экстрим, и, опять же, по моему разумению, не надо возводить его в практику, используемую на постоянной основе.
Эх...(всплакнул от наивности)
Каждое из подразделений выполняет собственные задачи и пользуется разными критериями оценки эффективности своей работы. Для разработчиков — это скорость написания и количество реализованных в программном коде функций, для тестировщиков — число выявленных ошибок, для отдела эксплуатации — стабильность функционирования систем и минимальное количество инцидентов.
Странные оценки. Для разработчиков разве что более-менее адекватно, если считать, что реализованной является функциональность не содержащая критических ошибок. Для чего нужно определение критических ошибок, скажем, непрохождение основных юзкейсов реальным пользователем
Для тестировщиков критерий эффективности должен быть: число багов, которые они не заметили, а заказчик/пользователи заметили. Меньше — лучше
Для эксплуатации: число инцидентов в их зоне ответственности (меньше — лучше) и точное распределение остальных инцидентов по другим подразделениям и(или) специалистам, когда назначенный на инцидент специалист решает проблему самостоятельно или переадресует её по иерархии или отбрасывает, а не тратит время на изучение, а потом понимает что это не его зона отвественности (меньше неверных назначений — лучше)
А вообще наблюдаю не в ИТ-компаниях со своими подразделениями разработки (пускай даже из одного человека) в странах бывшего СССР, что обычно эксплуатация не заинтересована во вникание в разработку, часто максимум взаимодействия «скажи какие пакеты поставить, а дальше сам настраивай и деплой» и «место на диске скоро кончится, разберись почему и лучше сам исправь». Грубо говоря, эксплуатация без разработчика не способна ни развернуть разработанное приложение, ни точно локализовать проблему — хотя бы в коде она, в железе, или в конфигах. А разработчики занимаются этим по принципу «если не я, то кто?» не сказать, что с большой мотивацией обычно, особенно когда общее руководство критикует что разработке мало времени в итоге уделяется.
Я ничего не понял.
Вот честное слово — руковожу немалой (по количеству человек-и-часов) разработкой — и не понял, о чем эта статья.
Причем тут вообще Agile? Как методика разработки относится к тому, что «админы должны быть частью команды» (а это и есть суть термина dev-ops)?
Виртуализация и контейнеризация — это dev-ops? Странно, а я всегда думал, что это просто полезные инструменты для администрирования и управления инфраструктурой…
Да всегда, блин. Всегда. Человек, отрицающий необходимость CI — эксперт?
Статья больше вводит в заблуждение, нежели рассказывает о действительном предназначении dev-ops: уменьшать себестоимость процесса разработки путем автоматизации, интеграции «сисдадминов» в общий флоу и избавления программистов от функций, несвязанных с программированием.
Вот честное слово — руковожу немалой (по количеству человек-и-часов) разработкой — и не понял, о чем эта статья.
Причем тут вообще Agile? Как методика разработки относится к тому, что «админы должны быть частью команды» (а это и есть суть термина dev-ops)?
Виртуализация и контейнеризация — это dev-ops? Странно, а я всегда думал, что это просто полезные инструменты для администрирования и управления инфраструктурой…
Да — иметь возможность часто обновлять код проекта — действительно важно, но как часто небольшому проекту надо иметь возможность выкладывать код ежедневно, десятки раз на дню?
Да всегда, блин. Всегда. Человек, отрицающий необходимость CI — эксперт?
Статья больше вводит в заблуждение, нежели рассказывает о действительном предназначении dev-ops: уменьшать себестоимость процесса разработки путем автоматизации, интеграции «сисдадминов» в общий флоу и избавления программистов от функций, несвязанных с программированием.
действительном предназначении dev-ops: уменьшать себестоимость процесса разработки путем автоматизации, интеграции «сисдадминов» в общий флоу и избавления программистов от функций, несвязанных с программированием.
Разве такое предназначение девопса? Мне казалось, что уменьшение срока реализации бизнес-требований (для многих бизнесов лучше внедрить фичу, увеличивающую входящий денежный поток, или исправить баг его уменьшающий, дороже, но быстрее, нормальный бизнес мало интересует себестоимость фичи или багфикса (в разумных пределах), если её реализация обеспечивает прибыль больше нормальной)
Всё остальное это средство. Причём избавление программистов от функций не связанных с программированием, это и ни необходимое, и ни недостаточное условие. Часто бизнесу выгоднее наложить именно на программистов как минимум часть ответственности, не связанной непосредственно с программированием, чем на других имеющихся специалистов, не говоря о найме новых.
Я считаю, что да, именно такое.
То, что вы пишете, про сокращение срока реализации — это и есть себестоимость. Себестоимость = рейт * время.
Любое управление производством в IT — это, имхо, управление себестоимостью. А для этого надо или резать косты (средний админ дешевле среднего разработчика, поэтому пусть именно он занимается задачами типа «обновить PHP на всех инстансах» и даже задачами «протестируй, что отвалится про обновлении PHP?»), либо резать время (и опять же мы приходим к тому же самому — программист должен только программировать, всё остальное либо автоматизируется, либо исполняется более дешевыми исполнителями)
То, что вы пишете, про сокращение срока реализации — это и есть себестоимость. Себестоимость = рейт * время.
Любое управление производством в IT — это, имхо, управление себестоимостью. А для этого надо или резать косты (средний админ дешевле среднего разработчика, поэтому пусть именно он занимается задачами типа «обновить PHP на всех инстансах» и даже задачами «протестируй, что отвалится про обновлении PHP?»), либо резать время (и опять же мы приходим к тому же самому — программист должен только программировать, всё остальное либо автоматизируется, либо исполняется более дешевыми исполнителями)
вам не нужен девопс — ибо это много дороже программиста :)
Да, себестоимость есть рейт * время, но бизнес часто согласен на больший рейт ради минимального времени. Бизнес минимизирует время, а рейт служит стоп-фактором. Грубо, бизнесу не нужна клевая фича через год бесплатно, не нужна через день за сто штук баксов, а между через месяц за десять и через два за пять выберет через месяц за десять. При условии, конечно, что по оценкам внедрении фичи на месяц раньше принесёт как минимум на 5 штук больше. И при условии, что есть эти десять штук, которые более выгодно вложить возможности нет.
Нет, имхо, главное — управление сроками (не человеко-часами, а календарными) при приемлемой для заказчика (внутреннего или внешнего) себестоимости. Практика качественного уменьшения себестоимости часто приводит к полному фейлу проекта, причём не только по срокам, но и вообще по функциональным и нефункциональным требованиям бизнеса.
Нет, имхо, главное — управление сроками (не человеко-часами, а календарными) при приемлемой для заказчика (внутреннего или внешнего) себестоимости. Практика качественного уменьшения себестоимости часто приводит к полному фейлу проекта, причём не только по срокам, но и вообще по функциональным и нефункциональным требованиям бизнеса.
бизнес часто согласен на больший рейт ради минимального времени
Это и есть управление себестоимостью.
Нет, имхо, главное — управление сроками
Сроками управлять невозможно, потому что любая фича нужна до того, как потребность в ней вербализуется. Любой поставленный срок — уже факап.
Практика качественного уменьшения себестоимости часто приводит к полному фейлу проекта
Не наблюдал такого. А вот полный фейл по причине «мы не заметили, как кончилось бабло» — видел и не раз.
Это и есть управление себестоимостью.
Нет, это управление временем. Крайне редко ставится задача «вписаться в фиксированный бюджет и не важно сколько времени займёт».
Сроками управлять невозможно
Очень спорно
Не наблюдал такого
«Зачем платить сеньору N денег, возьмём 5 джунов за N/10 денег каждому денег и получим тот же результат» — не знакомо?
Задача «вписаться в бюджет» не имеет никакого отношения к управлению проектом по себестоимости, о которой я говорю. Это вы что-то себе на ходу придумываете и на ходу же опровергаете.
Повторю еще раз.
Любая фича нужна вчера. Любые сроки срываются. Эти два утверждения делают управление по календарным срокам чем-то сродни шаманству или SEO — невозможно всерьез разговаривать со специалистом, который уверяет, что кнопка будет в понедельник и НИКОГДА не держит свои обещания.
Единственный приемлемый (имхо) способ управления разработкой — это управление от себестоимости. Сколько нам будет стоить эта фича? Ответ на этот вопрос отрезвляет бизнес, позволяет сразу и легко определить приоритеты, сформировать производственный план и управлять ресурсами в непрерывном режиме.
Задача же руководителя проекта — минимизировать себестоимость бизнес-value. В том числе и путем ускорения их разработки и внедрения.
Каждый час проведенный фичей в стеке задач — это чистый убыток. Как только приходит понимание этой простой истины — всё начинает вертеться со страшной скоростью, любители воткнуть везде mongodb, потому что «это модно и писали на хабре» с треском увольняются, а бизнес начинает видеть простой и понятный результат каждый день.
Я обычно с идиотами не работаю )))
Повторю еще раз.
Любая фича нужна вчера. Любые сроки срываются. Эти два утверждения делают управление по календарным срокам чем-то сродни шаманству или SEO — невозможно всерьез разговаривать со специалистом, который уверяет, что кнопка будет в понедельник и НИКОГДА не держит свои обещания.
Единственный приемлемый (имхо) способ управления разработкой — это управление от себестоимости. Сколько нам будет стоить эта фича? Ответ на этот вопрос отрезвляет бизнес, позволяет сразу и легко определить приоритеты, сформировать производственный план и управлять ресурсами в непрерывном режиме.
Задача же руководителя проекта — минимизировать себестоимость бизнес-value. В том числе и путем ускорения их разработки и внедрения.
Каждый час проведенный фичей в стеке задач — это чистый убыток. Как только приходит понимание этой простой истины — всё начинает вертеться со страшной скоростью, любители воткнуть везде mongodb, потому что «это модно и писали на хабре» с треском увольняются, а бизнес начинает видеть простой и понятный результат каждый день.
«Зачем платить сеньору N денег, возьмём 5 джунов за N/10 денег каждому денег и получим тот же результат» — не знакомо?
Я обычно с идиотами не работаю )))
Так в том-то и дело, что на вопрос «сколько нам будет стоить фича» ответить можно только после уточнения «а за какой (календарный) срок?». Себестоимость — функция от календарных сроков, в том числе определяющая каких специалистов и какой квалификации нужно привлекать, чтобы уложиться в нужный срок. Фича нужна вчера — будет завтра за 100 000, согласны подождать месяц — будет стоить 10 000, согласны подождать два месяца — будет стоить 5000, согласны подождать год — будет бесплатно.
Себестоимость — функция от календарных сроков
Именно в этом месте вы кардинально неправы.
Всё в реальности обстоит строго наоборот.
Срок — функция от себестоимости. Причем нелинейная. Есть предел, после которого увеличение рейта не приведет к сокращению времени, ровно как и есть предел, после которого увеличение времени на разработку не даст нового business-value.
Всё это
Фича нужна вчера — будет завтра за 100 000
— обычно фантастика, в которую верят начинающие PM-ы. Если индексирование базы длится трое суток, никто вам ни за какие деньги его за сутки не сделает ))
В моем понимании DevOps — это такой Software Any key, который знает как работает софт и знает как работает окружение и поддерживает работоспособность сервера.
Если брать по-старинке, то это отдел эксплуатации. В маленьких компаниях этим занимаются как правило админы+разработчики.
«Методология DevOps» — маркетинговый булшит.
Если брать по-старинке, то это отдел эксплуатации. В маленьких компаниях этим занимаются как правило админы+разработчики.
«Методология DevOps» — маркетинговый булшит.
Добавьте к вашему определению еще «знает, чем занимаются разработчики и что им нужно». И тогда будет почти идеально.
DevOps — это, упрощённо, «сисадмины разработки». В противопоставление классическим «сисадминам эксплуатации» Что, кстати, чётко следует из названия.
«Методология DevOps» означает декларирование отсутствия чёткой границы между зонами ответственности эксплуатации и разработки. Или путём создания «выделенных» ролей «девопсов», либо постоянной совместной работы эксплуатации и разработки.
непонятна четкая сфера… 20 лет в ИТ и не понимаю, какой % и какую нишу закрывает этот devops. Что нужно бизнесу? И какому бизнесу? Есть биз, который потребляет ПО — тут один devops — весь спрос с эксплуатантов, они точка контакта с бизом (работающим, а не заказывающим).
Есть биз по созданию ПО под заказчика. Второй вариант. Есть биз по созданию ПО, которое и есть суть твоего бизнеса (пример — Танки).
раз это слитно написали, то смысл в уменьшении издержек на коммуникации (всех видов: и косты и время и нервы и риски) между dev и ops. То есть это методология, которая увеличивает стоимость привносимую разными ИТ-подразделениями. В пределе это методолгия должна развиться в лучшие практики организации взаимодействия ВСЕХ тех.подразделений, таким образом, чтобы для биза — это было единым целым(во-первых), а во-вторых — не монстрообразным ит-департаментом с «неповоротливыми» процессами, а подобием настраиваемого (в идеале в любой момент) автомата.
Есть биз по созданию ПО под заказчика. Второй вариант. Есть биз по созданию ПО, которое и есть суть твоего бизнеса (пример — Танки).
раз это слитно написали, то смысл в уменьшении издержек на коммуникации (всех видов: и косты и время и нервы и риски) между dev и ops. То есть это методология, которая увеличивает стоимость привносимую разными ИТ-подразделениями. В пределе это методолгия должна развиться в лучшие практики организации взаимодействия ВСЕХ тех.подразделений, таким образом, чтобы для биза — это было единым целым(во-первых), а во-вторых — не монстрообразным ит-департаментом с «неповоротливыми» процессами, а подобием настраиваемого (в идеале в любой момент) автомата.
По какому принципу осуществлялся отбор экспертов для ответа на вопросы?
>Существуют развитые сообщества DevOps-специалистов
Забыли самые главные упомянуть
https://telegram.me/devops_ru — более 1000 человек!
https://telegram.me/devops_news
Забыли самые главные упомянуть
https://telegram.me/devops_ru — более 1000 человек!
https://telegram.me/devops_news
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О роли DevOps в ИТ — мнения экспертов